From owner-freebsd-current Sun Sep 21 00:20:43 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id AAA19036 for current-outgoing; Sun, 21 Sep 1997 00:20:43 -0700 (PDT) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id AAA19019 for ; Sun, 21 Sep 1997 00:20:36 -0700 (PDT) Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id JAA22343 for current@FreeBSD.ORG; Sun, 21 Sep 1997 09:20:34 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.8.7/8.8.5) id JAA07632; Sun, 21 Sep 1997 09:05:49 +0200 (MET DST) Message-ID: <19970921090549.CU01386@uriah.heep.sax.de> Date: Sun, 21 Sep 1997 09:05:49 +0200 From: j@uriah.heep.sax.de (J Wunsch) To: current@FreeBSD.ORG Subject: Re: Problems with -current ppp References: <19970920230953.49189@coladlp2.scsn.net> <29665.874815981@time.cdrom.com> X-Mailer: Mutt 0.60_p2-3,5,8-9 Mime-Version: 1.0 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <29665.874815981@time.cdrom.com>; from Jordan K. Hubbard on Sep 20, 1997 21:26:21 -0700 Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk As Jordan K. Hubbard wrote: > > Well, this is a one-user box, so that's not really a concern. In any case, > > Brian informed me in private mail of a neat little trick to accomplish what > > I wanted. > > Tell me your IP address and the hours when you're generally on and > surfing. I'll show you how "one user" that box is. ;-) Do you also accept the pathname of a local-domain socket, Jordan? :-) -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-current Sun Sep 21 03:50:55 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id DAA25556 for current-outgoing; Sun, 21 Sep 1997 03:50:55 -0700 (PDT) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id DAA25551; Sun, 21 Sep 1997 03:50:46 -0700 (PDT) Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id MAA23812; Sun, 21 Sep 1997 12:50:44 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.8.7/8.8.5) id MAA08389; Sun, 21 Sep 1997 12:26:11 +0200 (MET DST) Message-ID: <19970921122611.AG59280@uriah.heep.sax.de> Date: Sun, 21 Sep 1997 12:26:11 +0200 From: j@uriah.heep.sax.de (J Wunsch) To: stable@freebsd.org Cc: current@freebsd.org Subject: Re: rc.shutdown [was: Another NFS bogon in 2.2-stable?] References: <199709210751.RAA24163@godzilla.zeta.org.au> X-Mailer: Mutt 0.60_p2-3,5,8-9 Mime-Version: 1.0 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk As Bruce Evans wrote: > >Did anybody else notice that shutting down a 2.2-stable machine that > >has NFS file systems mounted never yields a clean shutdown? My 2.2 > > I notice it in -current for a nfs-mounted /usr. It is caused by > some daemons holding nfs files open and taking too long to die. > I use `umount -Af -t nfs' before rebooting. This tends to kill > the daemons early when their fd's go away. (Since you confirm it for -current, too, i've moved the discussion there. Please respect the reply-to.) In my case, it's probably the daemons running off the NFS-mounted /usr/local then. Should we ship an /etc/rc.shutdown by default, that kills off the daemons and unmounts NFS file systems? At least daemons that properly recorded their PID in /var/run/*pid could be killed easily. The following looks like a pretty good default rc.shutdown to me. The idea behind it is also that you can shutdown to single-user, and get an as clean as possible environment. (I didn't make up my mind about non-NFS filesystems, however. This might cause some LKMs to remain busy.) The mess to umount NFS filesystems could be replaced by `umount -Af -t nfs' in -current, but the -A option isn't available yet in 2.2-stable. Does -A correctly handle /etc/fstab reverse order, IOW, would it work if e.g. both /usr, and /usr/local were NFS-mounted? For some unknown reason, this script isn't really run on my 2.2 test machine when doing a `shutdown -h/-r', albeit it is run when doing a plain shutdown to single-user, as well as when typing Ctrl-Alt-Del. Looks like intention, but is IMHO bogus. If i type `shutdown -r', i expect it do perform a clean reboot. (This is the only way to do it when not sitting on the physical console.) Would anybody mind me committing the following script? #!/bin/sh stty status '^T' HOME=/; export HOME PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin export PATH echo -n "Stopping system daemons:" # # Stop by reverse PID order. Not ideal. for file in /var/run/*.pid; do if [ "$file" = "/var/run/*.pid" ]; then break fi pid=$(head -1 "$file") # sendmail needs head -1 name=$(expr "$file" : '/var/run/\(.*\)\.pid') pidlist="$pidlist$pid $name " done echo "$pidlist" | sort -n -r | while read pid name; do if [ "$pid" = "" ]; then break fi echo -n " $name" kill -TERM $pid && rm -f /var/run/$name.pid done echo '.' echo -n "Unloading kernel modules:" modstat | ( read junk # headline while read type id off loadaddr size info rev name; do echo -n " $name" modunload -i $id done ) echo '.' echo -n "Unmounting NFS filesystems:" nfslist=$( mount -t nfs | while read resource on mntpoint junk; do echo "$resource $mntpoint" done ) echo "$nfslist" | while read resource mntpoint; do if [ "$mntpoint" = ""]; then break fi echo -n " $resource" umount -f "$mntpoint" done echo '.' echo -n "Bringing down network interfaces:" ifconfig -a | while read line; do if iface=$(expr "$line" : '\([a-z][a-z]*[0-9][0-9]*\):'); then echo -n " $iface" ifconfig $iface down ifface="$iface" fi if ipaddr=$(expr "$line" : ' *inet \([0-9]*\.[0-9]*\.[0-9]*\.[0-9]*\)' then echo -n " $ipaddr" ifconfig $ifface $ipaddr delete fi done echo '.' -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-current Sun Sep 21 04:49:49 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id EAA27240 for current-outgoing; Sun, 21 Sep 1997 04:49:49 -0700 (PDT) Received: from smoke.marlboro.vt.us (smoke.marlboro.vt.us [198.206.215.91]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id EAA27235; Sun, 21 Sep 1997 04:49:41 -0700 (PDT) Received: (from cgull@localhost) by smoke.marlboro.vt.us (8.8.7/8.8.7/cgull) id HAA21311; Sun, 21 Sep 1997 07:49:38 -0400 (EDT) Date: Sun, 21 Sep 1997 07:49:38 -0400 (EDT) Message-Id: <199709211149.HAA21311@smoke.marlboro.vt.us> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: cgull+usenet-876050826@smoke.marlboro.vt.us (john hood) To: jkh@freebsd.org, current@freebsd.org Subject: 970919 snapshot install panic X-Mailer: VM 6.31 under Emacs 19.34.2 Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk So, I try an install of the 970919 snapshot, so I can get up and running with -current, and I get bitten by a kernel panic late in the install. The machine is a K5/90 with 32MB RAM on a VXPro motherboard with a VIA Apollo VP-1 chipset, S3 Trio64 on PCI, a real live Digital DE435 ethernet card as de0, and wd0, wd2, and wd3, all Quantum Fireballs. I boot into visual config and clean out all the ISA crap I'm not using. For the fun of it, sometimes I set 0xa0ffa0ff on wdc0 and wdc1, not that it makes any difference. I do an FTP or NFS install off a FreeBSD 2.2.2 box on the local network onto a single partition on wd0 on my crash box. The machine panics, apparently while showing the "Making device nodes" panel (depending on which VC I'm on, I can either get sysinstall's screen or the panic dump below), just after it's copied on kernel.GENERIC, and dies with something approximating this: [...] kernel.GENERIC 5038 blocks fatal trap 12: page fault while in kernel mode fault VA = 0x78 fault code = supervisor read, page not present IP 8:f0134ed4 SP 10:f423af40 FP 10:f423af58 code segment = base 0, limit 0xfffff, type 0x1b DPL 0 pres 1 def32 1 gran 1 EFLAGS = interrupt enabled, resume, IOPL 0 current process = 43 (sh) interrupt mask = (yup, that's blank) trap number = 12 It always panics exactly the same way, I think. (I've verified the panic message once, and it always panics at the same general point in the install.) BTW, kernel userconfig shows ide_pci0 as an unknown device under miscellaneous. Since I'm not running -current yet ;-), I have to do a bunch more work before I could debug this (make release, for one...), but if it's needed, I could do it. --jh -- Mr. Belliveau said, "the difference was the wise, John Hood, cgull intelligent look on the face of the cow." He was @ *so* right. --Ofer Inbar smoke.marlboro.vt.us From owner-freebsd-current Sun Sep 21 06:10:03 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id GAA00221 for current-outgoing; Sun, 21 Sep 1997 06:10:03 -0700 (PDT) Received: from awfulhak.demon.co.uk (awfulhak.demon.co.uk [158.152.17.1]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id GAA00174 for ; Sun, 21 Sep 1997 06:09:55 -0700 (PDT) Received: from gate.lan.awfulhak.org (localhost [127.0.0.1]) by awfulhak.demon.co.uk (8.8.5/8.8.5) with ESMTP id NAA27388; Sun, 21 Sep 1997 13:57:27 +0100 (BST) Message-Id: <199709211257.NAA27388@awfulhak.demon.co.uk> X-Mailer: exmh version 2.0zeta 7/24/97 To: Alex cc: Brian Somers , current@FreeBSD.ORG Subject: Re: Problems with -current ppp In-reply-to: Your message of "Sat, 20 Sep 1997 22:11:00 PDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 21 Sep 1997 13:57:27 +0100 From: Brian Somers Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > > On Sat, 20 Sep 1997, Brian Somers wrote: > > > > In your ppp.secret create a line like this > > > hostname password > > > once you telnet into port 3000 type passwd password, and you'll get access > > > to everything. Once I got past that, I've still had a lot of problem with > > > ppp -ddial. > > > > What sort of problems ? > > A while back after all this password (and other I guess) stuff was > commited, I would be getting unable to open port 3000 messages, and now > with the same script that I use, I must wait for ppp to dial my isp then > hit ctrl c to "kill" it, it will then be able to connect. If I don't it > the remote modem drops carrier after a while, and ppp hangs. I don't think I follow this. I assume ppp is being run interactively. Are you saying you have to "dial", then ^C, then dial again ? You may have been suffering from a Predictor1 bug that was recently fixed. This would cause the line to "hang" very soon after connection. The latest copy on http://www.freebsd.org/~brian has this fixed. > - alex > -- Brian , , Don't _EVER_ lose your sense of humour.... From owner-freebsd-current Sun Sep 21 07:04:30 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id HAA01699 for current-outgoing; Sun, 21 Sep 1997 07:04:30 -0700 (PDT) Received: from awfulhak.demon.co.uk (awfulhak.demon.co.uk [158.152.17.1]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id HAA01691 for ; Sun, 21 Sep 1997 07:04:25 -0700 (PDT) Received: from gate.lan.awfulhak.org (localhost [127.0.0.1]) by awfulhak.demon.co.uk (8.8.5/8.8.5) with ESMTP id OAA27879; Sun, 21 Sep 1997 14:55:08 +0100 (BST) Message-Id: <199709211355.OAA27879@awfulhak.demon.co.uk> X-Mailer: exmh version 2.0zeta 7/24/97 To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) cc: current@FreeBSD.ORG Subject: Re: Problems with -current ppp In-reply-to: Your message of "Sun, 21 Sep 1997 09:05:49 +0200." <19970921090549.CU01386@uriah.heep.sax.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 21 Sep 1997 14:55:08 +0100 From: Brian Somers Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > As Jordan K. Hubbard wrote: > > > > Well, this is a one-user box, so that's not really a concern. In any case, > > > Brian informed me in private mail of a neat little trick to accomplish what > > > I wanted. > > > > Tell me your IP address and the hours when you're generally on and > > surfing. I'll show you how "one user" that box is. ;-) > > Do you also accept the pathname of a local-domain socket, Jordan? :-) The "publishable" bit about the "trick" was to set up a script (say pppcmd) that's not readable/writable by anyone except you that does #! /bin/sh exec pppctl -v -p mypassword 3000 "$@" You can then start ppp -auto, and talk to it with things like $ pppcmd dial $ pppcmd close $ pppcmd set timeout 300 $ pppcmd show ipcp Of course making this a unix domain socket makes it even tighter (although on my LAN, I have many of these scripts that all talk to the gateway, therefore I need the tcp socket). > -- > cheers, J"org > > joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE > Never trust an operating system you don't have sources for. ;-) -- Brian , , Don't _EVER_ lose your sense of humour.... From owner-freebsd-current Sun Sep 21 07:21:50 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id HAA02180 for current-outgoing; Sun, 21 Sep 1997 07:21:50 -0700 (PDT) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id HAA02173; Sun, 21 Sep 1997 07:21:44 -0700 (PDT) Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.5/8.6.9) id AAA01820; Mon, 22 Sep 1997 00:20:37 +1000 Date: Mon, 22 Sep 1997 00:20:37 +1000 From: Bruce Evans Message-Id: <199709211420.AAA01820@godzilla.zeta.org.au> To: cgull+usenet-876050826@smoke.marlboro.vt.us, current@FreeBSD.ORG, jkh@FreeBSD.ORG Subject: Re: 970919 snapshot install panic Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >current process = 43 (sh) >interrupt mask = (yup, that's blank) I don't know about the other problems, but a blank mask means that something other than net, tty or bio is masked, probably just ASTs. This is normal for panics in kernel mode (except while processing interrupts of course). It is normal for panics in user mode too, since the current mask is printed, and SWI_AST_MASK is always set for trap handling. The "none" case in trap_fatal() is unreachable. Fixes: get the previous mask from the trap frame, and maybe print more masks. Some of the masks depend on the others (e.g., softclock interrupts are masked if any other interrupt is masked), but this is already a problem (e.g., "net" is usually equivalent to "tty", but printing of one does not prevent printing of the other). Bruce From owner-freebsd-current Sun Sep 21 08:01:02 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id IAA03333 for current-outgoing; Sun, 21 Sep 1997 08:01:02 -0700 (PDT) Received: from mail.scsn.net (scsn.net [206.25.246.12]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id IAA03326 for ; Sun, 21 Sep 1997 08:00:59 -0700 (PDT) Received: from rhiannon.scsn.net ([208.133.153.121]) by mail.scsn.net (Post.Office MTA v3.1 release PO203a ID# 0-41950U6000L1100S0) with ESMTP id AAA219; Sun, 21 Sep 1997 11:02:09 -0400 Received: (from root@localhost) by rhiannon.scsn.net (8.8.7/8.8.5) id LAA00550; Sun, 21 Sep 1997 11:00:55 -0400 (EDT) Message-ID: <19970921110054.48267@scsn.net> Date: Sun, 21 Sep 1997 11:00:54 -0400 From: "Donald J. Maddox" To: "Jordan K. Hubbard" Cc: current@FreeBSD.ORG Subject: Re: Problems with -current ppp Reply-To: dmaddox@scsn.net References: <19970920230953.49189@coladlp2.scsn.net> <29665.874815981@time.cdrom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.81 In-Reply-To: <29665.874815981@time.cdrom.com>; from Jordan K. Hubbard on Sat, Sep 20, 1997 at 09:26:21PM -0700 Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Sat, Sep 20, 1997 at 09:26:21PM -0700, Jordan K. Hubbard wrote: > > On Sat, Sep 20, 1997 at 07:36:13PM -0700, Jordan K. Hubbard wrote: > > > > Thanks. I was really hoping there was some magic that would make > > > > typing a password unnecessary, like before, but you can't win 'em all, eh > :-( > > > > > > Not and have any semblance of security on your ppp line, no. ;-) > > > > > > Jordan > > > > Well, this is a one-user box, so that's not really a concern. In any case, > > Brian informed me in private mail of a neat little trick to accomplish what > > I wanted. > > Tell me your IP address and the hours when you're generally on and > surfing. I'll show you how "one user" that box is. ;-) > > Jordan Ok. My IP addres is dynamically assigned by my ISP (scsn.net), so the most I can tell you is that it will be ppp???.coladlp?.scsn.net. I usually only use the PPP connection long enough to get my email, then kill it. Most incoming connections are denied by tcp wrappers. Good luck :-) Seriously, I understand the need for security in ppp, and I would rather have it secureable even if it means a little inconvenience (like having to type a password). However, since the window of insecurity is so small in this case, if I can trade security for convenience, I will. This is not an appeal to have ppp's security enhancements reverted. Clearly, making ppp more secure is a Good Thing. From owner-freebsd-current Sun Sep 21 08:34:48 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id IAA04403 for current-outgoing; Sun, 21 Sep 1997 08:34:48 -0700 (PDT) Received: from crlabs.com (CRLABS.COM [192.65.201.129]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id IAA04393; Sun, 21 Sep 1997 08:34:18 -0700 (PDT) Received: (from cwiener@localhost) by crlabs.com (8.8.7/8.7.3) id LAA18602; Sun, 21 Sep 1997 11:34:15 -0400 (EDT) From: Chris Wiener Message-Id: <199709211534.LAA18602@crlabs.com> Subject: problems with vm_zone, zlib, and PPP_DEFLATE To: freebsd-current@freebsd.org Date: Sun, 21 Sep 1997 11:34:15 -0400 (EDT) Cc: peter@freebsd.org X-Mailer: ELM [version 2.4ME+ PL35 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk The recent vm changes have caused a kernel build to fail due to an apparent conflict between the vm code's and the zlib code's usage of the following variables: /sys/net/ppp_deflate.c: (see also /usr/include/zlib.h) static void *zalloc __P((void *, u_int items, u_int size)); static void zfree __P((void *, void *ptr, u_int nb)); sys/vm/vm_zone.h: static void * zalloc __P((vm_zone_t z)); static void zfree __P((vm_zone_t z, void *item)); crlabs# make cc -c -O -Wreturn-type -Wcomment -Wredundant-decls -Wimplicit -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -nostdinc -I- -I. -I../.. -I../../../include -DPOWERFAIL_NMI -DINET -DMSDOSFS -DNFS -DFFS -DMD5 -DCOMPAT_43 -DKERNEL -include opt_global.h ../../net/ppp_deflate.c ../../net/ppp_deflate.c:63: conflicting types for `zalloc' ../../vm/vm_zone.h:122: previous declaration of `zalloc' ../../net/ppp_deflate.c:63: warning: redundant redeclaration of `zalloc' in same scope ../../vm/vm_zone.h:122: warning: previous declaration of `zalloc' ../../net/ppp_deflate.c:64: conflicting types for `zfree' ../../vm/vm_zone.h:132: previous declaration of `zfree' ../../net/ppp_deflate.c:64: warning: redundant redeclaration of `zfree' in same scope ../../vm/vm_zone.h:132: warning: previous declaration of `zfree' ../../net/ppp_deflate.c:107: redefinition of `zalloc' ../../net/ppp_deflate.c:63: `zalloc' previously defined here ../../net/ppp_deflate.c:118: redefinition of `zfree' ../../net/ppp_deflate.c:64: `zfree' previously defined here *** Error code 1 Stop. Script done on Sun Sep 21 11:19:59 1997 # # LAPTOP-SOUND # # $Id: LAPTOP-SOUND,v 1.362 1997/09/04 23:03:09 yokota Exp $ # # NB: You probably don't want to try running a kernel built from this # file. Instead, you should start from GENERIC, and add options from # this file as required. # machine "i386" ident LAPTOP-SOUND maxusers 10 config kernel root on wd0 dumps on wd0 cpu "I386_CPU" cpu "I486_CPU" cpu "I586_CPU" # aka Pentium(tm) options "CPU_FASTER_5X86_FPU" options GPL_MATH_EMULATE #Support for x87 emulation via #new math emulator options "COMPAT_43" options USER_LDT #allow user-level control of i386 ldt options SYSVSHM options SYSVSEM options SYSVMSG options "MD5" options "VM86" options PERFMON options UCONSOLE options PPP_BSDCOMP #PPP BSD-compress support options PPP_DEFLATE #PPP zlib/deflate/gzip support options MROUTING # Multicast routing options FFS #Fast filesystem options NFS #Network File System options "CD9660" #ISO 9660 filesystem options MSDOSFS #MS DOS File System options INET #InterNETworking options USERCONFIG #boot -c editor options VISUAL_USERCONFIG #visual boot -c editor options INCLUDE_CONFIG_FILE # Include this file in kernel pseudo-device ether #Generic Ethernet pseudo-device loop #Network loopback device pseudo-device sl 2 #Serial Line IP pseudo-device ppp 2 #Point-to-point protocol pseudo-device bpfilter 6 #Berkeley packet filter pseudo-device tun 1 #Tunnel driver(user process ppp) pseudo-device pty 16 #Pseudo ttys - can go as high as 256 pseudo-device log #Kernel syslog interface (/dev/klog) pseudo-device gzip #Exec gzipped a.out's pseudo-device vn #Vnode driver (turns a file into a device) pseudo-device snp 3 #Snoop device - to look at pty/vty/etc.. controller isa0 #device vt0 at isa? port "IO_KBD" tty irq 1 vector pcrint #options PCVT_FREEBSD=210 # pcvt running on FreeBSD >= 2.0.5 #options PCVT_NSCREENS=16 #options XSERVER # support for running an X server. #options FAT_CURSOR # start with block cursor # This PCVT option is for keyboards such as those used on IBM ThinkPad laptops #options PCVT_SCANSET=2 # IBM keyboards are non-std device sc0 at isa? port "IO_KBD" tty irq 1 vector scintr options MAXCONS=16 # number of virtual consoles #options SLOW_VGA # do byte-wide i/o's to TS and GDC regs #options "STD8X16FONT" # Compile font in #makeoptions "STD8X16FONT"="cp850" options SC_HISTORY_SIZE=200 # number of history buffer lines options ATAPI #Enable ATAPI support for IDE bus options ATAPI_STATIC #Don't do it as an LKM options POWERFAIL_NMI # make it beep instead of panicing options PSM_CHECKSYNC #checks the header byte for sync. options PSM_HOOKAPM #hook the APM resume event, useful #for some laptops options PSM_RESETAFTERSUSPEND #reset the device at the resume event device npx0 at isa? port "IO_NPX" iosiz 0x0 flags 0x0 irq 13 vector npxintr controller wdc0 at isa? port "IO_WD1" bio irq 14 vector wdintr disk wd0 at wdc0 drive 0 device wcd0 controller fdc0 at isa? port "IO_FD1" bio irq 6 drq 2 vector fdintr disk fd0 at fdc0 drive 0 device lpt0 at isa? port? tty irq 7 vector lptintr device psm0 at isa? port "IO_KBD" conflicts tty irq 12 vector psmintr device sio0 at isa? port "IO_COM1" tty flags 0x10 irq 4 vector siointr device ed0 at isa? port 0x300 net irq 9 iomem 0xd8000 vector edintr # # pcm: PCM audio through various sound cards. # # This is the work in progress from Luigi Rizzo. This has support for # CS423x based cards, OPTi931, SB16 PnP, GusPnP. For more information # about this driver, take a look at sys/i386/isa/snd/README. # # The flags of the device tells the device a bit more info about the # device that normally is obtained through the PnP interface. # bit 2..0 secondary DMA channel; # bit 4 set if the board uses two dma channels; # bit 15..8 board type, overrides autodetection; leave it # zero if don't know what to put in (and you don't, # since this is unsupported at the moment...). # # This driver will use the new PnP code if it's available. # # Luigi's snd code #device pcm0 at isa? port ? tty irq 5 drq 1 flags 0x00 vector pcmintr # sb: SoundBlaster PCM - SoundBlaster, SB Pro, SB16, ProAudioSpectrum # sbxvi: SoundBlaster 16 # sbmidi: SoundBlaster 16 MIDI interface # opl: Yamaha OPL-2 and OPL-3 FM - SB, SB Pro, SB 16, ProAudioSpectrum controller snd0 device sb0 at isa? port 0x220 irq 5 conflicts drq 1 vector sbintr device sbxvi0 at isa? irq? conflicts drq 5 device sbmidi0 at isa? port 0x330 irq? conflicts device awe0 at isa? port 0x620 device opl0 at isa? port 0x388 # Enable PnP support in the kernel. This allows you to automaticly # attach to PnP cards for drivers that support it and allows you to # configure cards from USERCONFIG. See pnp(4) for more info. controller pnp0 device apm0 at isa? device joy0 at isa? port "IO_GAME" controller pci0 controller crd0 controller pcic0 at crd? controller pcic1 at crd? -- Christopher Wiener N2CR CR Labs, Morris Plains, NJ DOMAIN: cwiener@CRLABS.COM "Live music is better ... bumper stickers should be issued." - Neil Young From owner-freebsd-current Sun Sep 21 08:51:49 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id IAA04884 for current-outgoing; Sun, 21 Sep 1997 08:51:49 -0700 (PDT) Received: from ox.ismi.net (root@ox.ismi.net [206.31.56.6]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id IAA04876 for ; Sun, 21 Sep 1997 08:51:43 -0700 (PDT) Received: from rhiannon.dyn.ml.org (mrr@pm2-11.ismi.net [206.31.56.51]) by ox.ismi.net (8.6.9/8.6.9) with SMTP id LAA28059; Sun, 21 Sep 1997 11:49:09 -0400 Date: Sun, 21 Sep 1997 11:54:13 -0400 (EDT) From: "Michael R. Rudel" To: dmaddox@scsn.net cc: "Jordan K. Hubbard" , current@FreeBSD.ORG Subject: Re: Problems with -current ppp In-Reply-To: <19970921110054.48267@scsn.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Sun, 21 Sep 1997, Donald J. Maddox wrote: [... SNIP ...] > > > > > > Well, this is a one-user box, so that's not really a concern. In any case, > > > Brian informed me in private mail of a neat little trick to accomplish what > > > I wanted. > > > > Tell me your IP address and the hours when you're generally on and > > surfing. I'll show you how "one user" that box is. ;-) > > > > Jordan > > Ok. My IP addres is dynamically assigned by my ISP (scsn.net), so the most > I can tell you is that it will be ppp???.coladlp?.scsn.net. I usually only > use the PPP connection long enough to get my email, then kill it. Most > incoming connections are denied by tcp wrappers. Good luck :-) > > Seriously, I understand the need for security in ppp, and I would rather have > it secureable even if it means a little inconvenience (like having to type a > password). However, since the window of insecurity is so small in this case, > if I can trade security for convenience, I will. > > This is not an appeal to have ppp's security enhancements reverted. Clearly, > making ppp more secure is a Good Thing. > TCP_WRAPPERS are very spoofable. I suggest using IPFW, even though it becomes a large pain to use FTP and such, if your worried about security. -- Michael R. Rudel -=- FreeBSD: There are no limits -=- mrr@aerosmith.dyn.ml.org FreeBSD aerosmith.dyn.ml.org 3.0-CURRENT Rhiannon rings like a star through the night ... and you wouldn't you love to love her? Takes to the sky like a bird in flight ... and who will be her lover? - Rhiannon (Fleetwood Mac) From owner-freebsd-current Sun Sep 21 11:05:13 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id LAA10396 for current-outgoing; Sun, 21 Sep 1997 11:05:13 -0700 (PDT) Received: from zippy.dyn.ml.org (garbanzo@tokyo-42.ppp.hooked.net [206.169.229.42]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id LAA10391 for ; Sun, 21 Sep 1997 11:05:08 -0700 (PDT) Received: from localhost (garbanzo@localhost) by zippy.dyn.ml.org (8.8.7/8.8.7) with SMTP id LAA00576; Sun, 21 Sep 1997 11:05:23 -0700 (PDT) X-Authentication-Warning: zippy.dyn.ml.org: garbanzo owned process doing -bs Date: Sun, 21 Sep 1997 11:05:22 -0700 (PDT) From: Alex X-Sender: garbanzo@zippy.dyn.ml.org To: dmaddox@scsn.net cc: current@FreeBSD.ORG Subject: Re: Problems with -current ppp In-Reply-To: <19970921110054.48267@scsn.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Sun, 21 Sep 1997, Donald J. Maddox wrote: > Ok. My IP addres is dynamically assigned by my ISP (scsn.net), so the most > I can tell you is that it will be ppp???.coladlp?.scsn.net. I usually only > use the PPP connection long enough to get my email, then kill it. Most > incoming connections are denied by tcp wrappers. Good luck :-) TCP Wrappers are kinda a moot point, as that's not where the hole lies. That's like putting a deadbolt on the back door, and leaving the front one wide open. > Seriously, I understand the need for security in ppp, and I would rather have > it secureable even if it means a little inconvenience (like having to type a > password). However, since the window of insecurity is so small in this case, > if I can trade security for convenience, I will. Uh, this isn't exactly a small hole, especially if you run it as root (not suid). > This is not an appeal to have ppp's security enhancements reverted. Clearly, > making ppp more secure is a Good Thing. Yes. - alex From owner-freebsd-current Sun Sep 21 11:17:07 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id LAA10793 for current-outgoing; Sun, 21 Sep 1997 11:17:07 -0700 (PDT) Received: from watcher.isl.net (ppp-51.isl.net [199.3.25.100]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id LAA10786 for ; Sun, 21 Sep 1997 11:17:01 -0700 (PDT) Received: (from ortmann@localhost) by watcher.isl.net (8.8.7/8.8.5) id NAA05205; Sun, 21 Sep 1997 13:10:56 -0500 (CDT) From: Daniel Ortmann Message-Id: <199709211810.NAA05205@watcher.isl.net> Subject: Re: Problems with -current ppp To: dmaddox@scsn.net Date: Sun, 21 Sep 1997 13:10:54 -0500 (CDT) Cc: jkh@time.cdrom.com, current@FreeBSD.ORG In-Reply-To: <19970921110054.48267@scsn.net> from "Donald J. Maddox" at "Sep 21, 97 11:00:54 am" X-Mailer: ELM [version 2.4ME+ PL17 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk ... > Seriously, I understand the need for security in ppp, and I would > rather have it secureable even if it means a little inconvenience > (like having to type a password). However, since the window of > insecurity is so small in this case, if I can trade security for > convenience, I will. > This is not an appeal to have ppp's security enhancements reverted. > Clearly, making ppp more secure is a Good Thing. Would there be any value in (or method for) a generalized mechanism tying the ipfw stuff into ppp and pppd? Perhaps a more dynamic mechanism encapsulating stuff now done in rc.firewall? (I suppose this is what ipfw.scripts was intended for?) Currently I spawn a while(1){ifconfig ppp0; sleep...} loop to setup ipfw. Icky, but it works. -- Daniel Ortmann 507.288.7732 (h) ortmann@isl.net 2414 30 av NW, #D 507.253.6795 (w) ortmann@vnet.ibm.com Rochester, MN 55901 "PERL: The Swiss Army Chainsaw" From owner-freebsd-current Sun Sep 21 11:37:29 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id LAA11742 for current-outgoing; Sun, 21 Sep 1997 11:37:29 -0700 (PDT) Received: from mail.scsn.net (scsn.net [206.25.246.12]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id LAA11737 for ; Sun, 21 Sep 1997 11:37:26 -0700 (PDT) Received: from rhiannon.scsn.net ([208.133.153.90]) by mail.scsn.net (Post.Office MTA v3.1 release PO203a ID# 0-41950U6000L1100S0) with ESMTP id AAA221; Sun, 21 Sep 1997 14:38:37 -0400 Received: (from root@localhost) by rhiannon.scsn.net (8.8.7/8.8.5) id OAA00982; Sun, 21 Sep 1997 14:36:58 -0400 (EDT) Message-ID: <19970921143658.25804@scsn.net> Date: Sun, 21 Sep 1997 14:36:58 -0400 From: "Donald J. Maddox" To: Alex Cc: current@FreeBSD.ORG Subject: Re: Problems with -current ppp Reply-To: dmaddox@scsn.net References: <19970921110054.48267@scsn.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.81 In-Reply-To: ; from Alex on Sun, Sep 21, 1997 at 11:05:22AM -0700 Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Sun, Sep 21, 1997 at 11:05:22AM -0700, Alex wrote: > > > On Sun, 21 Sep 1997, Donald J. Maddox wrote: > > > Ok. My IP addres is dynamically assigned by my ISP (scsn.net), so the most > > I can tell you is that it will be ppp???.coladlp?.scsn.net. I usually only > > use the PPP connection long enough to get my email, then kill it. Most > > incoming connections are denied by tcp wrappers. Good luck :-) > > TCP Wrappers are kinda a moot point, as that's not where the hole lies. > That's like putting a deadbolt on the back door, and leaving the front one > wide open. > > > Seriously, I understand the need for security in ppp, and I would rather have > > it secureable even if it means a little inconvenience (like having to type a > > password). However, since the window of insecurity is so small in this case, > > if I can trade security for convenience, I will. > > Uh, this isn't exactly a small hole, especially if you run it as root (not > suid). > > > This is not an appeal to have ppp's security enhancements reverted. Clearly, > > making ppp more secure is a Good Thing. > > Yes. You seem to be missing my point. I have almost _no need_ for security on this connection because I am the only one with physical access to it, and the network exposure it sees is extremely small. You may recall that this thread started because I was looking for a way to start ppp without having to type a password, and I found it. I was not looking for instructions on how to make this box C2-certified. From owner-freebsd-current Sun Sep 21 14:49:05 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id OAA19631 for current-outgoing; Sun, 21 Sep 1997 14:49:05 -0700 (PDT) Received: from peeper.my.domain ([208.128.8.69]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id OAA19623 for ; Sun, 21 Sep 1997 14:48:58 -0700 (PDT) Received: (from tom@localhost) by peeper.my.domain (8.8.7/8.7.3) id QAA04917; Sun, 21 Sep 1997 16:48:55 -0500 (CDT) Message-ID: <19970921164855.48382@my.domain> Date: Sun, 21 Sep 1997 16:48:55 -0500 From: Tom Jackson To: current@FreeBSD.ORG Subject: Re: Problems with -current ppp References: <199709211257.NAA27388@awfulhak.demon.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.81e In-Reply-To: <199709211257.NAA27388@awfulhak.demon.co.uk>; from Brian Somers on Sun, Sep 21, 1997 at 01:57:27PM +0100 Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Sun, Sep 21, 1997 at 01:57:27PM +0100, Brian Somers wrote: > > > > > > On Sat, 20 Sep 1997, Brian Somers wrote: > > [snip] > > > > A while back after all this password (and other I guess) stuff was > > commited, I would be getting unable to open port 3000 messages, and now > > with the same script that I use, I must wait for ppp to dial my isp then > > hit ctrl c to "kill" it, it will then be able to connect. If I don't it > > the remote modem drops carrier after a while, and ppp hangs. > > I don't think I follow this. I assume ppp is being run interactively. > Are you saying you have to "dial", then ^C, then dial again ? > > You may have been suffering from a Predictor1 bug that was recently > fixed. This would cause the line to "hang" very soon after > connection. The latest copy on http://www.freebsd.org/~brian has > this fixed. > > > - alex > > > > -- > Brian , , > > Don't _EVER_ lose your sense of humour.... > > I've been having this *exact* same problem of carrier being dropped and thought it was my ISP's fault. Will someone please elaborate. Tom From owner-freebsd-current Sun Sep 21 17:08:21 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id RAA26608 for current-outgoing; Sun, 21 Sep 1997 17:08:21 -0700 (PDT) Received: from pluto.plutotech.com (root@mail.plutotech.com [206.168.67.137]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id RAA26598 for ; Sun, 21 Sep 1997 17:08:17 -0700 (PDT) Received: from narnia.plutotech.com (narnia.plutotech.com [206.168.67.130]) by pluto.plutotech.com (8.8.5/8.8.5) with ESMTP id SAA29412 for ; Sun, 21 Sep 1997 18:08:16 -0600 (MDT) Message-Id: <199709220008.SAA29412@pluto.plutotech.com> X-Mailer: exmh version 2.0zeta 7/24/97 To: current@FreeBSD.org Subject: Re: cvs commit: src/sys/conf files src/sys/dev/vx if_vx.c if_vxreg.h src/sys/i386/apm apm.c src/sys/i386/conf GENERIC files.i386 src/sys/i386/eisa 3c5x9.c aha1742.c aic7770.c bt74x.c eisaconf.c eisaconf.h if_fea.c if_vx_eisa.c src/sys/i386/i386 autoconf.c ... In-reply-to: Your message of "Sun, 21 Sep 1997 15:10:56 PDT." <199709212210.PAA13470@freefall.freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 21 Sep 1997 18:08:06 -0600 From: "Justin T. Gibbs" Sender: owner-freebsd-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk This is just a "heads up" on the changes I just committed to current. Most of these are related to the CAM SCSI framework I've been working on, and getting them into the tree will facilitate those who want to test the CAM snapshots that I will start providing late next week. If you have any problems with these changes, please let me know, and I'll try to address and problems as quickly as possible. The changes include: 1) Interrupt driven config hook mechanism. This basically allows a kernel component to get called back once interrupts are available and to postpone full system startup until the hook is removed. The CAM system uses this so that all sub-device probing can occur in an interrupt driven fashion which greatly speeds up system boot time. Other device drivers may want to take advantage of this mechanism as it can often eliminate the need to busy loop during autoconfiguration. 2) New callout interface. This gives O(1) insertion and removal of callouts and an O(hash chain length) amount of work to be performed in softclock. As there is a change in the client interface to untimeout, I've updated all clients in the kernel (at least those in LINT) and tested all that I have hardware for. On my CCD array tests, this change really paid off. With CAM it's very easy to keep the controllers saturated with commands. On the Adaptecs, this translates into 255 callouts active per channel and constantly taking the O(n) hit on insertion and removal was painful. The networking code is another area that may want to make heavier use of callouts now that it is efficient to do so. If you are maintaining a driver outside of the tree, or need to update a driver I missed, see the timeout.9 man page for details on how the new interface works. For those who want to read more about the new implementation, here's a pointer to the original paper: http://www.cs.berkeley.edu/~amc/research/timer/ 3) Changes in driver buffer queuing to deal with ordered transactions. These changes modify the data structure of buf_queue_head and provide new inline functions for adding and removing entries from it. bufq_disksort replaces tqdisksort and takes advantage of some additional state in the buf_queue_head data structure to improve performance. The reason for this change is to finally allow for async ordered writes of meta-data in FreeBSD. This will happen as soon as the CAM SCSI code goes into the tree as the current SCSI code still does not honor the B_ORDERED buffer flag for tagged queuing devices. All clients of buf_queue_head have been updated. 4) The CAM software interrupt code. These changes add splcam, and splsoftcam. The changes to the interrupt code have been tested under SMP and now that they are in the tree, I don't have to update my changes every time Steve sneezes. 8-) The changes wont affect a system that doesn't have CAM code in it, but will make using CAM patches easier. 5) Changes to support EISA shared interrupts. Stefan did the brunt of the work here with his kern_intr.c code, I've just updated the EISA code to make use of it. -- Justin T. Gibbs =========================================== FreeBSD: Turning PCs into workstations =========================================== From owner-freebsd-current Sun Sep 21 17:21:25 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id RAA27285 for current-outgoing; Sun, 21 Sep 1997 17:21:25 -0700 (PDT) Received: from time.cdrom.com (root@time.cdrom.com [204.216.27.226]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id RAA27272 for ; Sun, 21 Sep 1997 17:21:19 -0700 (PDT) Received: from time.cdrom.com (jkh@localhost.cdrom.com [127.0.0.1]) by time.cdrom.com (8.8.7/8.6.9) with ESMTP id RAA01274 for ; Sun, 21 Sep 1997 17:21:48 -0700 (PDT) To: current@freebsd.org Subject: The 3.0-970920-SNAP CD has been cancelled. Date: Sun, 21 Sep 1997 17:21:46 -0700 Message-ID: <1268.874887706@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Sorry, we gave it our best shot but, when this date came and went, -current was found to be simply too broken to release on CD. For one thing, the new pnp changes appear to have severely broken sysinstall's save-kernel-changes-to-disk feature (e.g. the install now panics and dies) and dset appears to be none to happy either if other reports I've received are accurate. My -current machine running with Justin's latest changes is also no longer capable of even building a release - it resets itself spontaneously while building the boot floppy images so things don't look too bright for the immediate future, either. In any case, I've really got so much other stuff on my plate that I'm going to punt entirely on the idea of doing a 3.0 SNAPshot CD for now, concentrating instead on the 2.2 branch and the upcoming 2.2.5-BETA period. I'll try this little exercise again sometime in the November/December time-frame, assuming of course that conditions in -current look more favorable then and that 2.2.5 doesn't slip its schedule too much. :-) Just FYI. Since the previous 3.0 SNAP is from May 23rd, I think we'll also stop selling that one and simply put the SNAPshot product line to sleep for awhile. Jordan From owner-freebsd-current Sun Sep 21 17:44:00 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id RAA28172 for current-outgoing; Sun, 21 Sep 1997 17:44:00 -0700 (PDT) Received: from mail.webspan.net (root@mail.webspan.net [206.154.70.7]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id RAA28161 for ; Sun, 21 Sep 1997 17:43:55 -0700 (PDT) Received: from orion.webspan.net (orion.webspan.net [206.154.70.5]) by mail.webspan.net (WEBSPAN/970608) with ESMTP id UAA26162; Sun, 21 Sep 1997 20:43:53 -0400 (EDT) Received: from orion.webspan.net (localhost [127.0.0.1]) by orion.webspan.net (WEBSPAN/970608) with ESMTP id UAA01019; Sun, 21 Sep 1997 20:43:52 -0400 (EDT) To: "Jordan K. Hubbard" cc: "Daniel Sobral" , freebsd-current@FreeBSD.ORG From: "Gary Palmer" Subject: Re: Bug? In-reply-to: Your message of "Fri, 19 Sep 1997 06:32:05 PDT." <24003.874675925@time.cdrom.com> Date: Sun, 21 Sep 1997 20:43:52 -0400 Message-ID: <1000.874889032@orion.webspan.net> Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk "Jordan K. Hubbard" wrote in message ID <24003.874675925@time.cdrom.com>: > > I have noticed a very strange behavior with sysinstall. Whenever I select a > > custom distribution of XFree to be installed, 2.1 compatibility gets > > selected as well! Is this a bug or just an un(clearly)documented feature? > > Undocumented feature. Actually, unless I missed a commit somewhere, I think there needs to be a 2.2 compat dist for 3.0 now, with libtermcap and libtermlib version numbers being bumped, it creates problems with programs compiled under 2.2... Gary -- Gary Palmer FreeBSD Core Team Member FreeBSD: Turning PC's into workstations. See http://www.FreeBSD.ORG/ for info From owner-freebsd-current Sun Sep 21 17:52:09 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id RAA28722 for current-outgoing; Sun, 21 Sep 1997 17:52:09 -0700 (PDT) Received: from freebie.lemis.com (gregl1.lnk.telstra.net [139.130.136.133]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id RAA28701 for ; Sun, 21 Sep 1997 17:52:03 -0700 (PDT) Received: (from grog@localhost) by freebie.lemis.com (8.8.7/8.8.5) id KAA09069; Mon, 22 Sep 1997 10:21:51 +0930 (CST) Message-ID: <19970922102151.56679@lemis.com> Date: Mon, 22 Sep 1997 10:21:51 +0930 From: Greg Lehey To: "Jordan K. Hubbard" Cc: current@FreeBSD.ORG Subject: Re: The 3.0-970920-SNAP CD has been cancelled. References: <1268.874887706@time.cdrom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.81e In-Reply-To: <1268.874887706@time.cdrom.com>; from Jordan K. Hubbard on Sun, Sep 21, 1997 at 05:21:46PM -0700 Organisation: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8250 Fax: +61-8-8388-8250 Mobile: +61-41-739-7062 WWW-Home-Page: http://www.lemis.com/~grog Fight-Spam-Now: http://www.cauce.org Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Sun, Sep 21, 1997 at 05:21:46PM -0700, Jordan K. Hubbard wrote: > Sorry, we gave it our best shot [etc] > > Just FYI. Since the previous 3.0 SNAP is from May 23rd, I think we'll > also stop selling that one and simply put the SNAPshot product line to > sleep for awhile. Is this a recognition of what many of us have been suspecting, that -CURRENT is becoming less -STABLE? Wouldn't it be time to do a bit of thinking about how we can improve the situation? Greg From owner-freebsd-current Sun Sep 21 17:52:25 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id RAA28760 for current-outgoing; Sun, 21 Sep 1997 17:52:25 -0700 (PDT) Received: from awfulhak.demon.co.uk (awfulhak.demon.co.uk [158.152.17.1]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id RAA28747 for ; Sun, 21 Sep 1997 17:52:18 -0700 (PDT) Received: from gate.lan.awfulhak.org (localhost [127.0.0.1]) by awfulhak.demon.co.uk (8.8.5/8.8.5) with ESMTP id BAA05100; Mon, 22 Sep 1997 01:52:08 +0100 (BST) Message-Id: <199709220052.BAA05100@awfulhak.demon.co.uk> X-Mailer: exmh version 2.0zeta 7/24/97 To: Tom Jackson cc: current@FreeBSD.ORG Subject: Re: Problems with -current ppp In-reply-to: Your message of "Sun, 21 Sep 1997 16:48:55 CDT." <19970921164855.48382@my.domain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 22 Sep 1997 01:52:08 +0100 From: Brian Somers Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > I've been having this *exact* same problem of carrier being dropped > and thought it was my ISP's fault. Will someone please elaborate. Due to more than one problem, ppp was failing to hang up on loss of carrier. It also used to have a problem negotiating CCP with a peer that wanted a different sort of CCP. These problems are now fixed. A current version of ppp is available on http://www.freebsd.org/~brian. > Tom -- Brian , , Don't _EVER_ lose your sense of humour.... From owner-freebsd-current Sun Sep 21 18:21:42 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id SAA29985 for current-outgoing; Sun, 21 Sep 1997 18:21:42 -0700 (PDT) Received: from time.cdrom.com (root@time.cdrom.com [204.216.27.226]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id SAA29979 for ; Sun, 21 Sep 1997 18:21:38 -0700 (PDT) Received: from time.cdrom.com (jkh@localhost.cdrom.com [127.0.0.1]) by time.cdrom.com (8.8.7/8.6.9) with ESMTP id SAA16080; Sun, 21 Sep 1997 18:21:58 -0700 (PDT) To: Greg Lehey cc: current@FreeBSD.ORG Subject: Re: The 3.0-970920-SNAP CD has been cancelled. In-reply-to: Your message of "Mon, 22 Sep 1997 10:21:51 +0930." <19970922102151.56679@lemis.com> Date: Sun, 21 Sep 1997 18:21:58 -0700 Message-ID: <16076.874891318@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > On Sun, Sep 21, 1997 at 05:21:46PM -0700, Jordan K. Hubbard wrote: > > Sorry, we gave it our best shot [etc] > > > > Just FYI. Since the previous 3.0 SNAP is from May 23rd, I think we'll > > also stop selling that one and simply put the SNAPshot product line to > > sleep for awhile. > > Is this a recognition of what many of us have been suspecting, that > -CURRENT is becoming less -STABLE? Wouldn't it be time to do a bit of > thinking about how we can improve the situation? Well, while I think that we can always stand to improve our development methodologies, it's also fair to say that running things as a volunteer development effort will *always* impose certain penalties and limit what it's possible to achieve in a given time-frame. If we were a commercial software house with 30 developers working in a large office, for example, any significant release could always be preceded by a couple of weeks of ordering in pizza for the programmers and pulling late-nighters to fix bugs and do extra-aggressive regression testing in our PC test lab. Given the proper facilities and a bunch of developers with their paychecks indexed somewhat more solidly to product quality, you can accomplish a lot of things that it's just not possible to do any other way. But in any case, we don't have the luxury of that sort of development environment so there's really not much point in gritching about it. We just have to soldier on and do our best! In the case of 3.0, I think there are also some very aggressive features in the pipeline which are totally unsuitable for 2.2 and thus really have no place else to go. If we're going to get 3.0 released sometime within Q1 98, we're going to have to put these features in ASAP even if it means suffering from (hopefully) short-term instabilities and a -current which isn't a very fun place to be for awhile. My mistake was in thinking/hoping that I could make a meaningful snapshot of this progress any time before the end of the year, an error in judgment which I've now reevaluated and made appropriate adjustments to. I also think that most folks don't really appreciate how long 2.2 has left to run. If it's anything like our previous branch, it has around 12 more months to run before we can retire it in good conscience and that means that for a large number of folks, 3.0 won't even be remotely _relevant_ until sometime in late 1998 (the point at which it reaches "stability"). I think that gives us a little time to sort these problems out. ;) Jordan From owner-freebsd-current Sun Sep 21 19:11:28 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id TAA02637 for current-outgoing; Sun, 21 Sep 1997 19:11:28 -0700 (PDT) Received: from earth.mat.net (root@earth.mat.net [206.246.122.2]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id TAA02632 for ; Sun, 21 Sep 1997 19:11:22 -0700 (PDT) Received: from Journey2.mat.net (journey2.mat.net [206.246.122.116]) by earth.mat.net (8.8.7/8.6.12) with SMTP id WAA20104; Sun, 21 Sep 1997 22:10:41 -0400 (EDT) Date: Sun, 21 Sep 1997 22:10:27 -0400 (EDT) From: Chuck Robey X-Sender: chuckr@Journey2.mat.net To: "Jordan K. Hubbard" cc: Greg Lehey , current@FreeBSD.ORG Subject: Re: The 3.0-970920-SNAP CD has been cancelled. In-Reply-To: <16076.874891318@time.cdrom.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Sun, 21 Sep 1997, Jordan K. Hubbard wrote: > > On Sun, Sep 21, 1997 at 05:21:46PM -0700, Jordan K. Hubbard wrote: > > > Sorry, we gave it our best shot [etc] > > > > > > Just FYI. Since the previous 3.0 SNAP is from May 23rd, I think we'll > > > also stop selling that one and simply put the SNAPshot product line to > > > sleep for awhile. > > > > Is this a recognition of what many of us have been suspecting, that > > -CURRENT is becoming less -STABLE? Wouldn't it be time to do a bit of > > thinking about how we can improve the situation? > > Well, while I think that we can always stand to improve our > development methodologies, it's also fair to say that running things > as a volunteer development effort will *always* impose certain > penalties and limit what it's possible to achieve in a given > time-frame. I agree here. Look around at any other volunteer OS. You guys might be surprised, actually, at how many there are (most are tiny). I had to become aware of some more, while working on the educational OS I've been involved with. Anyhow, compare FreeBSD's development with anyone else's out there, and maybe you'd agree with me, that no one else even comes close to the right mix of active development and stability we have. If you force current to be more stable, you'd lose some of that, maybe a lot. If we relax the rules on current (going in the other direction), we'd lose our stability. As it is, current is, yes, broken a lot. It always has been, we all know that, it goes thru cycles, and this is another low points. We can all remember high points, too. Not that I mind anyone complaining, that's good negative feedback, let's hear more. Complaints are good, just let's not translate that too rapidly into concrete rules. ----------------------------+----------------------------------------------- Chuck Robey | Interests include any kind of voice or data chuckr@eng.umd.edu | communications topic, C programming, and Unix. 213 Lakeside Drive Apt T-1 | Greenbelt, MD 20770 | I run Journey2 and picnic, both FreeBSD (301) 220-2114 | version 3.0 current -- and great FUN! ----------------------------+----------------------------------------------- From owner-freebsd-current Sun Sep 21 19:12:27 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id TAA02715 for current-outgoing; Sun, 21 Sep 1997 19:12:27 -0700 (PDT) Received: from atlantis.nconnect.net (root@atlantis.nconnect.net [207.227.50.2]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id TAA02709 for ; Sun, 21 Sep 1997 19:12:23 -0700 (PDT) Received: from nconnect.net (randyd@dial171.nconnect.net [207.227.50.171]) by atlantis.nconnect.net (8.8.4/8.7.3) with ESMTP id VAA06118 for ; Sun, 21 Sep 1997 21:15:45 -0500 (CDT) Message-ID: <3425D354.EAAE577E@nconnect.net> Date: Sun, 21 Sep 1997 21:09:24 -0500 From: Randy DuCharme Organization: Astrolab Development X-Mailer: Mozilla 4.03b8 [en] (X11; I; FreeBSD 3.0-CURRENT i386) MIME-Version: 1.0 To: current@freebsd.org Subject: Latest code changes break SMP kernel Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Greetings, The latest commits seem to have hosed kernel builds. Tried to build an SMP kernel and... loading kernel isa.o: Undefined symbol `_isa_devtab_cam' referenced from text segment isa.o: Undefined symbol `_isa_devtab_cam' referenced from text segment isa.o: Undefined symbol `_isa_devtab_cam' referenced from text segment isa.o: Undefined symbol `_isa_devtab_cam' referenced from text segment isa.o: Undefined symbol `_isa_devtab_cam' referenced from text segment isa.o: Undefined symbol `_isa_devtab_cam' referenced from text segment isa.o: Undefined symbol `_isa_devtab_cam' referenced from text segment isa.o: Undefined symbol `_isa_devtab_cam' referenced from text segment I'm digging around a little more ( to see if I missed something :) ) -- Randall D DuCharme Systems Engineer Novell, Microsoft, and UNIX Networking Support Computer Specialists BSDI Internet Success Partners 414-253-9998 414-253-9919 (fax) BSD/OS Authorized Resellers From owner-freebsd-current Sun Sep 21 20:42:27 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id UAA06894 for current-outgoing; Sun, 21 Sep 1997 20:42:27 -0700 (PDT) Received: from pluto.plutotech.com (root@mail.plutotech.com [206.168.67.137]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id UAA06889 for ; Sun, 21 Sep 1997 20:42:25 -0700 (PDT) Received: from narnia.plutotech.com (narnia.plutotech.com [206.168.67.130]) by pluto.plutotech.com (8.8.5/8.8.5) with ESMTP id VAA07283; Sun, 21 Sep 1997 21:42:23 -0600 (MDT) Message-Id: <199709220342.VAA07283@pluto.plutotech.com> X-Mailer: exmh version 2.0zeta 7/24/97 To: Randy DuCharme cc: current@FreeBSD.ORG Subject: Re: Latest code changes break SMP kernel In-reply-to: Your message of "Sun, 21 Sep 1997 21:09:24 CDT." <3425D354.EAAE577E@nconnect.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 21 Sep 1997 21:42:13 -0600 From: "Justin T. Gibbs" Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >Greetings, > >The latest commits seem to have hosed kernel builds. Tried to build an >SMP kernel >and... Rebuild config. >-- >Randall D DuCharme >Systems Engineer Novell, Microsoft, and UNIX Networking Support >Computer Specialists BSDI Internet Success Partners >414-253-9998 414-253-9919 (fax) BSD/OS Authorized Resellers -- Justin T. Gibbs =========================================== FreeBSD: Turning PCs into workstations =========================================== From owner-freebsd-current Sun Sep 21 21:15:54 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id VAA08886 for current-outgoing; Sun, 21 Sep 1997 21:15:54 -0700 (PDT) Received: from dyson.iquest.net (dyson.iquest.net [198.70.144.127]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id VAA08878 for ; Sun, 21 Sep 1997 21:15:50 -0700 (PDT) Received: (from root@localhost) by dyson.iquest.net (8.8.6/8.8.5) id XAA00272; Sun, 21 Sep 1997 23:15:45 -0500 (EST) From: "John S. Dyson" Message-Id: <199709220415.XAA00272@dyson.iquest.net> Subject: Re: Latest code changes break SMP kernel In-Reply-To: <3425D354.EAAE577E@nconnect.net> from Randy DuCharme at "Sep 21, 97 09:09:24 pm" To: randyd@nconnect.net (Randy DuCharme) Date: Sun, 21 Sep 1997 23:15:44 -0500 (EST) Cc: current@FreeBSD.ORG Reply-To: dyson@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL31 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Randy DuCharme said: > Greetings, > > The latest commits seem to have hosed kernel builds. Tried to build an > SMP kernel > and... > > loading kernel > isa.o: Undefined symbol `_isa_devtab_cam' referenced from text segment > isa.o: Undefined symbol `_isa_devtab_cam' referenced from text segment > isa.o: Undefined symbol `_isa_devtab_cam' referenced from text segment > isa.o: Undefined symbol `_isa_devtab_cam' referenced from text segment > isa.o: Undefined symbol `_isa_devtab_cam' referenced from text segment > isa.o: Undefined symbol `_isa_devtab_cam' referenced from text segment > isa.o: Undefined symbol `_isa_devtab_cam' referenced from text segment > isa.o: Undefined symbol `_isa_devtab_cam' referenced from text segment > > I'm digging around a little more ( to see if I missed something :) ) > You need to recompile/reinstall config. (/usr/src/usr.sbin/config). It is a good idea to be prepared to recompile config -- it is the same as any other part of the kernel. One of these days, we'll move config to be under /sys, where it should be. John From owner-freebsd-current Sun Sep 21 21:35:37 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id VAA10191 for current-outgoing; Sun, 21 Sep 1997 21:35:37 -0700 (PDT) Received: from peeper.my.domain ([208.128.8.69]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id VAA10186 for ; Sun, 21 Sep 1997 21:35:33 -0700 (PDT) Received: (from tom@localhost) by peeper.my.domain (8.8.7/8.7.3) id XAA01111; Sun, 21 Sep 1997 23:35:20 -0500 (CDT) Message-ID: <19970921233450.07729@my.domain> Date: Sun, 21 Sep 1997 23:34:50 -0500 From: Tom Jackson To: Brian Somers Cc: current@FreeBSD.ORG Subject: Re: Problems with -current ppp References: <19970921164855.48382@my.domain> <199709220052.BAA05100@awfulhak.demon.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.81e In-Reply-To: <199709220052.BAA05100@awfulhak.demon.co.uk>; from Brian Somers on Mon, Sep 22, 1997 at 01:52:08AM +0100 Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Mon, Sep 22, 1997 at 01:52:08AM +0100, Brian Somers wrote: > > I've been having this *exact* same problem of carrier being dropped > > and thought it was my ISP's fault. Will someone please elaborate. > > Due to more than one problem, ppp was failing to hang up on loss of > carrier. It also used to have a problem negotiating CCP with a peer > that wanted a different sort of CCP. > > These problems are now fixed. A current version of ppp is available > on http://www.freebsd.org/~brian. > > > Tom > > -- > Brian , , > > Don't _EVER_ lose your sense of humour.... > > Well thanks for the effort Brian. Unfortunately, it had no effect on the problem. The reliable way for me to reproduce this is to call my shell account at the university and try to send a 69k msg, drops every time, here lately. I've always got a 'unknown protocol 0x803f' and show hdlc gives proto:1 but the connection has worked much better in the past. This is into a NT4.0 ISP if that makes a difference. btw, is this version of ppp different than the current version on 3.0? Maybe it is my ISP Tom From owner-freebsd-current Sun Sep 21 22:05:36 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id WAA12278 for current-outgoing; Sun, 21 Sep 1997 22:05:36 -0700 (PDT) Received: from ns.mt.sri.com (SRI-56K-FR.mt.net [206.127.65.42]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id WAA12273 for ; Sun, 21 Sep 1997 22:05:27 -0700 (PDT) Received: from rocky.mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.8.7/8.8.7) with ESMTP id XAA09334; Sun, 21 Sep 1997 23:05:22 -0600 (MDT) Received: (from nate@localhost) by rocky.mt.sri.com (8.7.5/8.7.3) id XAA29116; Sun, 21 Sep 1997 23:05:20 -0600 (MDT) Date: Sun, 21 Sep 1997 23:05:20 -0600 (MDT) Message-Id: <199709220505.XAA29116@rocky.mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: "Justin T. Gibbs" Cc: current@freebsd.org Subject: Re: cvs commit: src/sys/conf files src/sys/dev/vx if_vx.c if_vxreg.h src/sys/i386/apm apm.c src/sys/i386/conf GENERIC files.i386 src/sys/i386/eisa 3c5x9.c aha1742.c aic7770.c bt74x.c eisaconf.c eisaconf.h if_fea.c if_vx_eisa.c src/sys/i386/i386 autoconf.c ... In-Reply-To: <199709220008.SAA29412@pluto.plutotech.com> References: <199709212210.PAA13470@freefall.freebsd.org> <199709220008.SAA29412@pluto.plutotech.com> X-Mailer: VM 6.29 under 19.15 XEmacs Lucid Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > 2) New callout interface. This gives O(1) insertion and removal of > callouts and an O(hash chain length) amount of work to be performed > in softclock. ... > the O(n) hit on insertion and removal was painful. The networking > code is another area that may want to make heavier use of callouts > now that it is efficient to do so. If you are maintaining a driver > outside of the tree, or need to update a driver I missed, see the > timeout.9 man page for details on how the new interface works. For > those who want to read more about the new implementation, here's a > pointer to the original paper: > > http://www.cs.berkeley.edu/~amc/research/timer/ I just read the paper, and it's interesting, but they never give results based on what the kernel does now. Basically, it's pretty easy to say that registering/unregistering timers is now much faster, but given that things can take longer in softclock(), it's not obvious (at least to me) that this is a win overall, since we call softlock a *heck* of alot more than we register/de-register timeout/callouts. Does anyone have insight they're willing to share, since the author's did prove they accomplished what they set out to do, but it didn't really give me a warm-fuzzy that it would help improve performance. Nate From owner-freebsd-current Sun Sep 21 22:16:29 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id WAA13369 for current-outgoing; Sun, 21 Sep 1997 22:16:29 -0700 (PDT) Received: from weenix.guru.org (kmitch@weenix.guru.org [198.82.200.65]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id WAA13234 for ; Sun, 21 Sep 1997 22:15:18 -0700 (PDT) Received: (from kmitch@localhost) by weenix.guru.org (8.8.7/8.8.7) id BAA07589 for current@freebsd.org; Mon, 22 Sep 1997 01:14:12 -0400 (EDT) From: Keith Mitchell Message-Id: <199709220514.BAA07589@weenix.guru.org> Subject: rm -fr behavior changed? To: current@freebsd.org Date: Mon, 22 Sep 1997 01:14:12 -0400 (EDT) X-Mailer: ELM [version 2.4ME+ PL32 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I recently upgraded my system to -current and noticed that the behavior in rm -fr has changed in the past month. rm -fr /tmp/dir/ and rm -fr /tmp/dir Used to work just fine. Now, I get a Operation not Permitted error message on the top one for every file in the directory. The bottom one continues to work just fine though. -- Keith Mitchell Head Administrator: acm.vt.edu Email: kmitch@weenix.guru.org PGP key available upon request http://weenix.guru.org/~kmitch Address and URL (c) 1997 Keith Mitchell - All Rights Reserved Unauthorized use or duplication prohibited From owner-freebsd-current Sun Sep 21 22:49:03 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id WAA15361 for current-outgoing; Sun, 21 Sep 1997 22:49:03 -0700 (PDT) Received: from pluto.plutotech.com (root@mail.plutotech.com [206.168.67.137]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id WAA15355 for ; Sun, 21 Sep 1997 22:48:59 -0700 (PDT) Received: from narnia.plutotech.com (narnia.plutotech.com [206.168.67.130]) by pluto.plutotech.com (8.8.5/8.8.5) with ESMTP id XAA08824; Sun, 21 Sep 1997 23:48:53 -0600 (MDT) Message-Id: <199709220548.XAA08824@pluto.plutotech.com> To: Nate Williams cc: "Justin T. Gibbs" , current@freebsd.org Subject: Re: cvs commit: src/sys/conf files src/sys/dev/vx if_vx.c if_vxreg.h src/sys/i386/apm apm.c src/sys/i386/conf GENERIC files.i386 src/sys/i386/eisa 3c5x9.c aha1742.c aic7770.c bt74x.c eisaconf.c eisaconf.h if_fea.c if_vx_eisa.c src/sys/i386/i386 autoconf.c ... In-reply-to: Your message of "Sun, 21 Sep 1997 23:05:20 MDT." <199709220505.XAA29116@rocky.mt.sri.com> Date: Sun, 21 Sep 1997 23:48:42 -0600 From: "Justin T. Gibbs" Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >I just read the paper, and it's interesting, but they never give results >based on what the kernel does now. Basically, it's pretty easy to say >that registering/unregistering timers is now much faster, but given that >things can take longer in softclock(), it's not obvious (at least to me) >that this is a win overall, since we call softlock a *heck* of alot more >than we register/de-register timeout/callouts. The trick is determining what the largest hash chain length is and then you'll know your answer. As the hash table size is the same as the number of callouts initially allocated, and the hash function should offer a fairly good distribution, it seems that softclock shouldn't have that much extra work to do. In the case of SCSI disk I/O, the common case is that the timeout never expires and the I/O completes in less than 10 ticks, so softclock will decrement that callout's counter at most once before it's removed. In performing the conversion of all the client code, it became quite obvious that the common case is to schedule a timeout that will be canceled before it expires and that the lifetime of a timeout is quite short. If this continues to be the case, we'll be bounded by the insert and removal time, not by the work in softclock as a single callout entry will be inserted and removed multiple times during one rotation of the callwheel. >Does anyone have insight they're willing to share, since the author's >did prove they accomplished what they set out to do, but it didn't >really give me a warm-fuzzy that it would help improve performance. Take a server with 10 Seagate disks. Each one of these disks can handle 63 transactions at a time. If you split the disks across controllers correctly, you can readily keep them saturated with requests. Thats 630 pending callouts and an O(n) hit for insert and removal. Add to that any process alarm timers, the network stack's timer, the serial ports timeout or two, etc. It really adds up and it defenitly shows up in profiles. >Nate > -- Justin T. Gibbs =========================================== FreeBSD: Turning PCs into workstations =========================================== From owner-freebsd-current Sun Sep 21 23:47:51 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id XAA19433 for current-outgoing; Sun, 21 Sep 1997 23:47:51 -0700 (PDT) Received: from usr07.primenet.com (tlambert@usr07.primenet.com [206.165.6.207]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id XAA19428 for ; Sun, 21 Sep 1997 23:47:48 -0700 (PDT) Received: (from tlambert@localhost) by usr07.primenet.com (8.8.5/8.8.5) id XAA16869; Sun, 21 Sep 1997 23:47:44 -0700 (MST) From: Terry Lambert Message-Id: <199709220647.XAA16869@usr07.primenet.com> Subject: Re: cvs commit: src/sys/conf files src/sys/dev/vx if_vx.c if_vxreg.h src/sys/i386/apm apm.c src/sys/i386/conf GENERIC files.i386 To: gibbs@plutotech.com (Justin T. Gibbs) Date: Mon, 22 Sep 1997 06:47:44 +0000 (GMT) Cc: nate@mt.sri.com, gibbs@plutotech.com, current@FreeBSD.ORG In-Reply-To: <199709220548.XAA08824@pluto.plutotech.com> from "Justin T. Gibbs" at Sep 21, 97 11:48:42 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > >Does anyone have insight they're willing to share, since the author's > >did prove they accomplished what they set out to do, but it didn't > >really give me a warm-fuzzy that it would help improve performance. > > Take a server with 10 Seagate disks. Each one of these disks can > handle 63 transactions at a time. If you split the disks across > controllers correctly, you can readily keep them saturated with > requests. Thats 630 pending callouts and an O(n) hit for insert > and removal. Add to that any process alarm timers, the network stack's > timer, the serial ports timeout or two, etc. It really adds up and > it defenitly shows up in profiles. A more deterministic implementation would associate an absolute tick value (rather than a count) with each entry, and insert entries in sorted order. The tick value would be monotonically increasing, and a comparison need only occur with the list head (the smallest absolute value). When the timer fires, the entry is removed, and following the callout, subsequent entries are examined until such time that the absolute tick count is smaller than the list head entry's absolute tick count. This wins because it means your traversal time in the normal case is not variant based on the length of the list. Because of this, you can maintain an accurate soft clock based on how many cycles you know the timer code itself will take (it's deterministic, at this point). Finally, you don't need to maintain a constant timer frequency. The expiration of the head is all that matters, so you can set the timer to expire at some absolute time that matches the head entry... you don't need to kick the frequency up to match the interval resoloution for the highest resoloution entry, as you would for a ntry-tick-decrement based implementation. Finally, if you allowed a timer outcall to reschedule itslef, you could remove the HZ clock to a timer entry as well. Someone should look at the Linux 2.1 kernel; they have implemented the reschedulable one-shots that I first discussed in 1993, and can now probe devices concurrently instead of using delay buzz-loops (also as I first discussed in 1993). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-current Mon Sep 22 00:21:02 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id AAA21673 for current-outgoing; Mon, 22 Sep 1997 00:21:02 -0700 (PDT) Received: from schizo.dk.tfs.com (mail.trw.dk [195.8.133.123]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id AAA21659 for ; Mon, 22 Sep 1997 00:20:58 -0700 (PDT) Received: from critter.freebsd.dk (critter.dk.tfs.com [140.145.230.252]) by schizo.dk.tfs.com (8.8.7/8.7.3) with ESMTP id JAA07509; Mon, 22 Sep 1997 09:20:26 +0200 (MET DST) Received: from critter.freebsd.dk (localhost.dk.tfs.com [127.0.0.1]) by critter.freebsd.dk (8.8.7/8.8.7) with ESMTP id JAA00318; Mon, 22 Sep 1997 09:19:49 +0200 (CEST) To: Nate Williams cc: "Justin T. Gibbs" , current@FreeBSD.ORG Subject: Re: cvs commit: src/sys/conf files src/sys/dev/vx if_vx.c if_vxreg.h src/sys/i386/apm apm.c src/sys/i386/conf GENERIC files.i386 src/sys/i386/eisa 3c5x9.c aha1742.c aic7770.c bt74x.c eisaconf.c eisaconf.h if_fea.c if_vx_eisa.c src/sys/i386/i386 autoconf.c ... In-reply-to: Your message of "Sun, 21 Sep 1997 23:05:20 MDT." <199709220505.XAA29116@rocky.mt.sri.com> Date: Mon, 22 Sep 1997 09:19:48 +0200 Message-ID: <316.874912788@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk In message <199709220505.XAA29116@rocky.mt.sri.com>, Nate Williams writes: >> 2) New callout interface. This gives O(1) insertion and removal of >> callouts and an O(hash chain length) amount of work to be performed >> in softclock. >... >> the O(n) hit on insertion and removal was painful. The networking >> code is another area that may want to make heavier use of callouts >> now that it is efficient to do so. If you are maintaining a driver >> outside of the tree, or need to update a driver I missed, see the >> timeout.9 man page for details on how the new interface works. For >> those who want to read more about the new implementation, here's a >> pointer to the original paper: >> >> http://www.cs.berkeley.edu/~amc/research/timer/ > >I just read the paper, and it's interesting, but they never give results >based on what the kernel does now. Basically, it's pretty easy to say >that registering/unregistering timers is now much faster, but given that >things can take longer in softclock(), it's not obvious (at least to me) >that this is a win overall, since we call softlock a *heck* of alot more >than we register/de-register timeout/callouts. According to my measurements on my laptop, it's a wash. That means that it will be a win on any other machine I belive. -- Poul-Henning Kamp FreeBSD coreteam member phk@FreeBSD.ORG "Real hackers run -current on their laptop." From owner-freebsd-current Mon Sep 22 03:58:21 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id DAA05928 for current-outgoing; Mon, 22 Sep 1997 03:58:21 -0700 (PDT) Received: from mailbox.uq.edu.au (zzshocki.dialin.uq.net.au [203.101.242.9]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id DAA05920 for ; Mon, 22 Sep 1997 03:58:14 -0700 (PDT) Received: from bloop.craftncomp.com (localhost.craftncomp.com [127.0.0.1]) by mailbox.uq.edu.au (8.8.7/8.6.12) with ESMTP id VAA12467 for ; Mon, 22 Sep 1997 21:04:19 +1000 (EST) Message-Id: <199709221104.VAA12467@mailbox.uq.edu.au> X-Mailer: exmh version 2.0zeta 7/24/97 To: current@freebsd.org Subject: WABI & FreeBSD - need linux gdt-frobbing code Date: Mon, 22 Sep 1997 21:04:17 +1000 From: Stephen Hocking Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I'm trying to beat Linux WABI into working with FreeBSD, and as a result, need to find out exactly what Linux does with its system call arguments. Does anyone have a copy of the Linux syscall code for linux_modify_ldt? Stephen From owner-freebsd-current Mon Sep 22 05:58:19 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id FAA10645 for current-outgoing; Mon, 22 Sep 1997 05:58:19 -0700 (PDT) Received: from mail.cs.tu-berlin.de (root@mail.cs.tu-berlin.de [130.149.17.13]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id FAA10614 for ; Mon, 22 Sep 1997 05:58:09 -0700 (PDT) Received: from panke.panke.de (anonymous213.ppp.cs.tu-berlin.de [130.149.17.213]) by mail.cs.tu-berlin.de (8.8.6/8.8.6) with ESMTP id OAA09462; Mon, 22 Sep 1997 14:50:46 +0200 (MET DST) Received: (from wosch@localhost) by panke.panke.de (8.8.5/8.6.12) id NAA00542; Mon, 22 Sep 1997 13:59:46 +0200 (MET DST) To: Keith Mitchell Cc: current@freebsd.org Subject: Re: rm -fr behavior changed? References: <199709220514.BAA07589@weenix.guru.org> From: Wolfram Schneider Date: 22 Sep 1997 13:59:44 +0200 In-Reply-To: Keith Mitchell's message of Mon, 22 Sep 1997 01:14:12 -0400 (EDT) Message-ID: Lines: 28 Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Keith Mitchell writes: > I recently upgraded my system to -current and noticed that the > behavior in rm -fr has changed in the past month. Known problem. Bug id bin/4593 Wolfram > rm -fr /tmp/dir/ > > and > > rm -fr /tmp/dir > > Used to work just fine. Now, I get a Operation not Permitted error message > on the top one for every file in the directory. The bottom one continues > to work just fine though. > > -- > Keith Mitchell Head Administrator: acm.vt.edu > Email: kmitch@weenix.guru.org PGP key available upon request > http://weenix.guru.org/~kmitch > Address and URL (c) 1997 Keith Mitchell - All Rights Reserved > Unauthorized use or duplication prohibited > -- Wolfram Schneider http://www.apfel.de/~wosch/ From owner-freebsd-current Mon Sep 22 06:32:46 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id GAA12171 for current-outgoing; Mon, 22 Sep 1997 06:32:46 -0700 (PDT) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id GAA12162 for ; Mon, 22 Sep 1997 06:32:38 -0700 (PDT) Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.5/8.6.9) id XAA15020; Mon, 22 Sep 1997 23:23:57 +1000 Date: Mon, 22 Sep 1997 23:23:57 +1000 From: Bruce Evans Message-Id: <199709221323.XAA15020@godzilla.zeta.org.au> To: gibbs@plutotech.com, nate@mt.sri.com Subject: Re: cvs commit: src/sys/conf files src/sys/dev/vx if_vx.c if_vxreg.h src/sys/i386/apm apm.c src/sys/i386/conf GENERIC files.i386 src/sys/i386/eisa 3c5x9.c aha1742.c aic7770.c bt74x.c eisaconf.c eisaconf.h if_fea.c if_vx_eisa.c src/sys/i386/i386 autoconf.c ... Cc: current@FreeBSD.ORG Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >In performing the conversion of all the client code, it became quite >obvious that the common case is to schedule a timeout that will be >canceled before it expires and that the lifetime of a timeout is quite >short. If this continues to be the case, we'll be bounded by the >insert and removal time, not by the work in softclock as a single >callout entry will be inserted and removed multiple times during one >rotation of the callwheel. timeout() was not very suitable for that case. It was better to use a periodic timeout per subsystem and walk subsystem-specific timer queues. The queues can probably be optimized better than any general purpose queues. The cost of periodic timeouts and nested walking of queues is very small. >Take a server with 10 Seagate disks. Each one of these disks can >handle 63 transactions at a time. If you split the disks across >controllers correctly, you can readily keep them saturated with >requests. Thats 630 pending callouts and an O(n) hit for insert >and removal... Assuming that the timeout length is not very critical, and that timeouts rarely expire, this setup could be optimized well using "queues" consisting of two (pointers to) arrays of bits, and counters for the number of items set in each array: /* * a1 gives the transactions that will timeout on the next tick. * a2 gives the transactions that will timeout on the next+1 tick. * This is pseudocode. C doesn't have arrays of bits... */ insert(n): if (a2[n] == 0) { a2[n] = 1; ++count2; } delete(n): if (a1[n] == 1) { a1[n] = 0; --count1; } if (a2[n] == 1) { a2[n] = 0; --count2; } periodic timeout: if (count1 != 0) { /* * We expect that this case is rare, and it is only * moderately expensive when it occurs (we just have * to search 630 bits for set bits), so we optimized * for it not happening. */ for (n = 0; ; ++n) if (a1[n] == 1) { handle_problem(n); a1[n] = 0; if (--count1 == 0) break; } } tmpa = a1; a1 = a2; a2 = tmpa1; count1 = count2; count2 = 0; Bruce From owner-freebsd-current Mon Sep 22 06:47:56 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id GAA12948 for current-outgoing; Mon, 22 Sep 1997 06:47:56 -0700 (PDT) Received: from pluto.plutotech.com (root@mail.plutotech.com [206.168.67.137]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id GAA12940 for ; Mon, 22 Sep 1997 06:47:53 -0700 (PDT) Received: from narnia.plutotech.com (narnia.plutotech.com [206.168.67.130]) by pluto.plutotech.com (8.8.5/8.8.5) with ESMTP id HAA15157; Mon, 22 Sep 1997 07:47:36 -0600 (MDT) Message-Id: <199709221347.HAA15157@pluto.plutotech.com> To: Bruce Evans cc: gibbs@plutotech.com, nate@mt.sri.com, current@FreeBSD.ORG Subject: Re: cvs commit: src/sys/conf files src/sys/dev/vx if_vx.c if_vxreg.h src/sys/i386/apm apm.c src/sys/i386/conf GENERIC files.i386 src/sys/i386/eisa 3c5x9.c aha1742.c aic7770.c bt74x.c eisaconf.c eisaconf.h if_fea.c if_vx_eisa.c src/sys/i386/i386 autoconf.c ... In-reply-to: Your message of "Mon, 22 Sep 1997 23:23:57 +1000." <199709221323.XAA15020@godzilla.zeta.org.au> Date: Mon, 22 Sep 1997 07:47:26 -0600 From: "Justin T. Gibbs" Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >>Take a server with 10 Seagate disks. Each one of these disks can >>handle 63 transactions at a time. If you split the disks across >>controllers correctly, you can readily keep them saturated with >>requests. Thats 630 pending callouts and an O(n) hit for insert >>and removal... > >Assuming that the timeout length is not very critical, and that timeouts >rarely expire, this setup could be optimized well using "queues" >consisting of two (pointers to) arrays of bits, and counters for the >number of items set in each array: Now make it scale during usage. There are lots of schemes available, but very few are easily scalable by mallocing small chunks of free memory. >Bruce -- Justin T. Gibbs =========================================== FreeBSD: Turning PCs into workstations =========================================== From owner-freebsd-current Mon Sep 22 07:10:12 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id HAA14660 for current-outgoing; Mon, 22 Sep 1997 07:10:12 -0700 (PDT) Received: from atena.eurocontrol.fr (atena.uneec.eurocontrol.fr [147.196.69.10]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id HAA14550 for ; Mon, 22 Sep 1997 07:08:53 -0700 (PDT) Received: by atena.eurocontrol.fr; (5.65v3.2/1.3/10May95) id AA18332; Mon, 22 Sep 1997 16:06:05 +0200 Received: (from roberto@localhost) by caerdonn.eurocontrol.fr (8.8.7/caerdonn-1.3/nospam) id QAA24038; Mon, 22 Sep 1997 16:06:01 +0200 (CEST) Message-Id: <19970922160600.17406@caerdonn.eurocontrol.fr> Date: Mon, 22 Sep 1997 16:06:00 +0200 From: Ollivier Robert To: "FreeBSD Current Users' list" Subject: Netscape 4.03b8 doesn't work after poll/select changes Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84 X-Operating-System: FreeBSD 3.0-CURRENT Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk I have a problem with Netscape since the poll/select changes... It doesn't work at all. No window is displayed and the process seems to be sleeping in 1193 23985 232 35 2 0 8096 2896 select I+ p4 0:00.39 /usr/local/l 1193 23986 23985 12 2 0 7340 1908 select I+ p4 0:00.06 (dns helper) ktrace shows that the process is doing nothing: 263 [16:03] root@caerdonn:/build/trn4# ll ktra* -rw------- 1 roberto staff 165074 Sep 22 16:02 ktrace.out 23985 netscape.bin RET read 3072/0xc00 23985 netscape.bin CALL writev(0x8,0xefbfbc44,0x2) 23985 netscape.bin GIO fd 8 wrote 44 bytes ".\0\^B\0\a\0\M^@\b1\0 \0\M^?\M^?\^\\0-*-*-*-*-*-*-*-*-*-*-*-*-*-*" 23985 netscape.bin RET writev 44/0x2c 23985 netscape.bin CALL read(0x8,0xefbfbc88,0x20) 23985 netscape.bin RET read -1 errno 35 Resource temporarily unavailable 23985 netscape.bin CALL select(0x9,0xefbfbb70,0,0,0xefbfb6c0) 23985 netscape.bin RET select 0 23985 netscape.bin CALL sigprocmask(0x1,0) 23985 netscape.bin RET sigprocmask 0 23985 netscape.bin CALL gettimeofday(0xefbfb5b8,0) 23985 netscape.bin RET gettimeofday 0 23985 netscape.bin CALL sigprocmask(0x3,0) 23985 netscape.bin RET sigprocmask 0 23985 netscape.bin CALL sigprocmask(0x1,0x2000) 23985 netscape.bin RET sigprocmask 0 23985 netscape.bin CALL select(0x9,0x50011f48,0,0,0x50011eec) and doesn't return... Am I the only one ? -CURRENT from 9/16 around 3 PM. -- Ollivier ROBERT -=- Eurocontrol EEC/TS -=- Ollivier.Robert@eurocontrol.fr From owner-freebsd-current Mon Sep 22 07:42:03 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id HAA16666 for current-outgoing; Mon, 22 Sep 1997 07:42:03 -0700 (PDT) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id HAA16661 for ; Mon, 22 Sep 1997 07:42:00 -0700 (PDT) Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.5/8.6.9) id AAA18001; Tue, 23 Sep 1997 00:40:34 +1000 Date: Tue, 23 Sep 1997 00:40:34 +1000 From: Bruce Evans Message-Id: <199709221440.AAA18001@godzilla.zeta.org.au> To: bde@zeta.org.au, gibbs@plutotech.com Subject: Re: cvs commit: src/sys/conf files src/sys/dev/vx if_vx.c if_vxreg.h src/sys/i386/apm apm.c src/sys/i386/conf GENERIC files.i386 src/sys/i386/eisa 3c5x9.c aha1742.c aic7770.c bt74x.c eisaconf.c eisaconf.h if_fea.c if_vx_eisa.c src/sys/i386/i386 autoconf.c ... Cc: current@FreeBSD.ORG, nate@mt.sri.com Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >>>requests. Thats 630 pending callouts and an O(n) hit for insert >>>and removal... >> >>Assuming that the timeout length is not very critical, and that timeouts >>rarely expire, this setup could be optimized well using "queues" >>consisting of two (pointers to) arrays of bits, and counters for the >>number of items set in each array: > >Now make it scale during usage. There are lots of schemes available, >but very few are easily scalable by mallocing small chunks of free >memory. This one is: when attaching a drive, find a free drive number and malloc more storage if the new number is at the end. Rarely free anything. The main point is that it is easy to build a perfect hash function (drive_number, transaction_number) -> timeout_slot_number because we only need one timeout per (drive_number, transaction_number). Bruce From owner-freebsd-current Mon Sep 22 07:43:25 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id HAA16738 for current-outgoing; Mon, 22 Sep 1997 07:43:25 -0700 (PDT) Received: from earth.mat.net (root@earth.mat.net [206.246.122.2]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id HAA16732 for ; Mon, 22 Sep 1997 07:43:22 -0700 (PDT) Received: from Journey2.mat.net (journey2.mat.net [206.246.122.116]) by earth.mat.net (8.8.7/8.6.12) with SMTP id KAA17420 for ; Mon, 22 Sep 1997 10:43:12 -0400 (EDT) Date: Mon, 22 Sep 1997 10:42:55 -0400 (EDT) From: Chuck Robey X-Sender: chuckr@Journey2.mat.net To: FreeBSD current Subject: ctm blowup Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk I got a little behind in applying ctm updates (a day ago), and when I finally got to doing 3670 (immediately after 3669), here's what I found: ctm_rmail: cvs-cur.3669.gz applied ctm_rmail: ctm: DM: src/kerberosIV exists. ctm_rmail: ctm: Exit(80) Anyone know what that was, or how I could get ctm back on track? ----------------------------+----------------------------------------------- Chuck Robey | Interests include any kind of voice or data chuckr@eng.umd.edu | communications topic, C programming, and Unix. 213 Lakeside Drive Apt T-1 | Greenbelt, MD 20770 | I run Journey2 and picnic, both FreeBSD (301) 220-2114 | version 3.0 current -- and great FUN! ----------------------------+----------------------------------------------- From owner-freebsd-current Mon Sep 22 08:02:05 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id IAA17623 for current-outgoing; Mon, 22 Sep 1997 08:02:05 -0700 (PDT) Received: from pluto.plutotech.com (root@mail.plutotech.com [206.168.67.137]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id IAA17616 for ; Mon, 22 Sep 1997 08:02:01 -0700 (PDT) Received: from narnia.plutotech.com (narnia.plutotech.com [206.168.67.130]) by pluto.plutotech.com (8.8.5/8.8.5) with ESMTP id JAA16510; Mon, 22 Sep 1997 09:01:46 -0600 (MDT) Message-Id: <199709221501.JAA16510@pluto.plutotech.com> To: Bruce Evans cc: gibbs@plutotech.com, current@FreeBSD.ORG, nate@mt.sri.com Subject: Re: cvs commit: src/sys/conf files src/sys/dev/vx if_vx.c if_vxreg.h src/sys/i386/apm apm.c src/sys/i386/conf GENERIC files.i386 src/sys/i386/eisa 3c5x9.c aha1742.c aic7770.c bt74x.c eisaconf.c eisaconf.h if_fea.c if_vx_eisa.c src/sys/i386/i386 autoconf.c ... In-reply-to: Your message of "Tue, 23 Sep 1997 00:40:34 +1000." <199709221440.AAA18001@godzilla.zeta.org.au> Date: Mon, 22 Sep 1997 09:01:36 -0600 From: "Justin T. Gibbs" Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >>Now make it scale during usage. There are lots of schemes available, >>but very few are easily scalable by mallocing small chunks of free >>memory. > >This one is: when attaching a drive, find a free drive number and malloc >more storage if the new number is at the end. How much storage do I need in order to realloc the arrays? Is it bounded? The current implementation only needs to allocate a callout at a time if it wants to grow the number of callouts. It may, in fact be nice to add an interface for clients to add additional callouts if they are heavy users of them. For instance, the CAM system grows it's number of transactions dynamically and will simply stop growing if it can't malloc more. In your scenario, if you can't allocate space for a drive and it's transactions, you can't talk to the drive. >The main point is that it is easy to build a perfect hash function >(drive_number, transaction_number) -> timeout_slot_number because we >only need one timeout per (drive_number, transaction_number). I thought your point was that every client should make up their own solution to this problem instead of making the generic solution more efficient. 8-) >Bruce -- Justin T. Gibbs =========================================== FreeBSD: Turning PCs into workstations =========================================== From owner-freebsd-current Mon Sep 22 08:26:58 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id IAA19210 for current-outgoing; Mon, 22 Sep 1997 08:26:58 -0700 (PDT) Received: from awfulhak.demon.co.uk (awfulhak.demon.co.uk [158.152.17.1]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id IAA19198 for ; Mon, 22 Sep 1997 08:26:46 -0700 (PDT) Received: from gate.lan.awfulhak.org (localhost [127.0.0.1]) by awfulhak.demon.co.uk (8.8.5/8.8.5) with ESMTP id PAA11844; Mon, 22 Sep 1997 15:48:11 +0100 (BST) Message-Id: <199709221448.PAA11844@awfulhak.demon.co.uk> X-Mailer: exmh version 2.0zeta 7/24/97 To: Tom Jackson cc: Brian Somers , current@FreeBSD.ORG Subject: Re: Problems with -current ppp In-reply-to: Your message of "Sun, 21 Sep 1997 23:34:50 CDT." <19970921233450.07729@my.domain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 22 Sep 1997 15:48:10 +0100 From: Brian Somers Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > On Mon, Sep 22, 1997 at 01:52:08AM +0100, Brian Somers wrote: > > > I've been having this *exact* same problem of carrier being dropped > > > and thought it was my ISP's fault. Will someone please elaborate. > > > > Due to more than one problem, ppp was failing to hang up on loss of > > carrier. It also used to have a problem negotiating CCP with a peer > > that wanted a different sort of CCP. > > > > These problems are now fixed. A current version of ppp is available > > on http://www.freebsd.org/~brian. > > > > > Tom > > > > -- > > Brian , , > > > > Don't _EVER_ lose your sense of humour.... > > > > > > Well thanks for the effort Brian. Unfortunately, it had no effect on the > problem. > > The reliable way for me to reproduce this is to call my shell account at > the university and try to send a 69k msg, drops every time, here lately. Is this a mail message ? Maybe your ISPs MDA only does up to 64k messages. You could try splitting it into two. > I've always got a 'unknown protocol 0x803f' and show hdlc gives proto:1 > but the connection has worked much better in the past. This is into a NT4.0 > ISP if that makes a difference. >From rfc1700, protocol 0x803f is a NetBIOS Framing Control Protocol. Ppp doesn't understand NetBIOS, so it rejects it. > btw, is this version of ppp different than the current version on 3.0? Nope. It's the same with a couple of auto-hacks. Essentially, I have a script on freefall that modifies the -current ppp/pppctl/libalias/libutil code so that it builds on 2.1.5 and up. When I make a significant change, I run my script and it builds the archive. > Maybe it is my ISP It may reject messages >64k, but It's unlikely to drop the line on you. Try setting your logging with set log phase chat connect command lcp ccp ipcp tun and see if anything interesting is produced in the log. If you just see a "Disconnected", then you ISP is hanging up on you. I'd have a moan at them if that's the case. > Tom -- Brian , , Don't _EVER_ lose your sense of humour.... From owner-freebsd-current Mon Sep 22 08:56:26 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id IAA21701 for current-outgoing; Mon, 22 Sep 1997 08:56:26 -0700 (PDT) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id IAA21692 for ; Mon, 22 Sep 1997 08:56:22 -0700 (PDT) Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.5/8.6.9) id BAA20408; Tue, 23 Sep 1997 01:53:46 +1000 Date: Tue, 23 Sep 1997 01:53:46 +1000 From: Bruce Evans Message-Id: <199709221553.BAA20408@godzilla.zeta.org.au> To: bde@zeta.org.au, gibbs@plutotech.com Subject: Re: cvs commit: src/sys/conf files src/sys/dev/vx if_vx.c if_vxreg.h src/sys/i386/apm apm.c src/sys/i386/conf GENERIC files.i386 src/sys/i386/eisa 3c5x9.c aha1742.c aic7770.c bt74x.c eisaconf.c eisaconf.h if_fea.c if_vx_eisa.c src/sys/i386/i386 autoconf.c ... Cc: current@FreeBSD.ORG, nate@mt.sri.com Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >How much storage do I need in order to realloc the arrays? Is it bounded? No, but it is too small to matter. 63 transactions on each of 520 drives can be supported using just two blocks of size 4K. Each queue entry takes only 2 bits. This is 96 times denser than the current callout table. >>The main point is that it is easy to build a perfect hash function... >I thought your point was that every client should make up their own >solution to this problem instead of making the generic solution more >efficient. 8-) Only clients that need a large number of timeouts. I think there aren't many, and the ones that do can benefit from a special solutions. Bruce From owner-freebsd-current Mon Sep 22 08:59:18 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id IAA21900 for current-outgoing; Mon, 22 Sep 1997 08:59:18 -0700 (PDT) Received: from pluto.plutotech.com (root@mail.plutotech.com [206.168.67.137]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id IAA21887 for ; Mon, 22 Sep 1997 08:59:13 -0700 (PDT) Received: from narnia.plutotech.com (narnia.plutotech.com [206.168.67.130]) by pluto.plutotech.com (8.8.5/8.8.5) with ESMTP id JAA17865; Mon, 22 Sep 1997 09:59:04 -0600 (MDT) Message-Id: <199709221559.JAA17865@pluto.plutotech.com> X-Mailer: exmh version 2.0zeta 7/24/97 To: Terry Lambert cc: gibbs@plutotech.com (Justin T. Gibbs), nate@mt.sri.com, current@FreeBSD.ORG Subject: Re: cvs commit: src/sys/conf files src/sys/dev/vx if_vx.c if_vxreg.h src/sys/i386/apm apm.c src/sys/i386/conf GENERIC files.i386 In-reply-to: Your message of "Mon, 22 Sep 1997 06:47:44 -0000." <199709220647.XAA16869@usr07.primenet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 22 Sep 1997 09:58:54 -0600 From: "Justin T. Gibbs" Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >A more deterministic implementation would associate an absolute tick >value (rather than a count) with each entry, and insert entries in >sorted order. More deterministic for who? This trades O(1) insertion for O(hash chain length) insertion so that softclock will become O(timeouts for the current tick). As timeout often is called from an interrupt context it is not so clear where it is better to pay the price of non-determinism. Softclock has the luxury of lowering it's spl at deterministic intervals (see the implementation) while a caller from an interrupt context doesn't. the current implementation always blocks interrupts for a deterministic amount of time. What you propose doesn't. Even so, it is probably better to store an absolute tick value regardless so that you don't have to perform the subtraction. If and when we decide that we need higher resolution timer facilities, we can decide if a non-deterministic timeout() is an acceptable cost for that feature. > Terry Lambert > terry@lambert.org >--- >Any opinions in this posting are my own and not those of my present >or previous employers. -- Justin T. Gibbs =========================================== FreeBSD: Turning PCs into workstations =========================================== From owner-freebsd-current Mon Sep 22 09:07:57 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id JAA22524 for current-outgoing; Mon, 22 Sep 1997 09:07:57 -0700 (PDT) Received: from rah.star-gate.com (rah.star-gate.com [204.188.121.18]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id JAA22519 for ; Mon, 22 Sep 1997 09:07:54 -0700 (PDT) Received: from rah.star-gate.com (localhost.star-gate.com [127.0.0.1]) by rah.star-gate.com (8.8.7/8.8.5) with ESMTP id JAA05440; Mon, 22 Sep 1997 09:07:15 -0700 (PDT) Message-Id: <199709221607.JAA05440@rah.star-gate.com> To: Ollivier Robert cc: freebsd-current@FreeBSD.ORG Subject: Re: Netscape 4.03b8 doesn't work after poll/select changes In-reply-to: Your message of "Mon, 22 Sep 1997 16:06:00 +0200." <19970922160600.17406@caerdonn.eurocontrol.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 22 Sep 1997 09:07:15 -0700 From: Amancio Hasty Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk It seems to work over here . You may have to delete the preference's file in .netscape. My system is current as of yesterday. Cheers, Amancio >From The Desk Of Ollivier Robert : > I have a problem with Netscape since the poll/select changes... It doesn't > work at all. No window is displayed and the process seems to be sleeping in > > 1193 23985 232 35 2 0 8096 2896 select I+ p4 0:00.39 /usr/local /l > 1193 23986 23985 12 2 0 7340 1908 select I+ p4 0:00.06 (dns helpe r) > > ktrace shows that the process is doing nothing: > > 263 [16:03] root@caerdonn:/build/trn4# ll ktra* > -rw------- 1 roberto staff 165074 Sep 22 16:02 ktrace.out > > 23985 netscape.bin RET read 3072/0xc00 > 23985 netscape.bin CALL writev(0x8,0xefbfbc44,0x2) > 23985 netscape.bin GIO fd 8 wrote 44 bytes > ".\0\^B\0\a\0\M^@\b1\0 \0\M^?\M^?\^\\0-*-*-*-*-*-*-*-*-*-*-*-*-*-*" > 23985 netscape.bin RET writev 44/0x2c > 23985 netscape.bin CALL read(0x8,0xefbfbc88,0x20) > 23985 netscape.bin RET read -1 errno 35 Resource temporarily unavailable > 23985 netscape.bin CALL select(0x9,0xefbfbb70,0,0,0xefbfb6c0) > 23985 netscape.bin RET select 0 > 23985 netscape.bin CALL sigprocmask(0x1,0) > 23985 netscape.bin RET sigprocmask 0 > 23985 netscape.bin CALL gettimeofday(0xefbfb5b8,0) > 23985 netscape.bin RET gettimeofday 0 > 23985 netscape.bin CALL sigprocmask(0x3,0) > 23985 netscape.bin RET sigprocmask 0 > 23985 netscape.bin CALL sigprocmask(0x1,0x2000) > 23985 netscape.bin RET sigprocmask 0 > 23985 netscape.bin CALL select(0x9,0x50011f48,0,0,0x50011eec) > > and doesn't return... > > Am I the only one ? > > -CURRENT from 9/16 around 3 PM. > -- > Ollivier ROBERT -=- Eurocontrol EEC/TS -=- Ollivier.Robert@eurocontrol.fr > From owner-freebsd-current Mon Sep 22 09:10:29 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id JAA22716 for current-outgoing; Mon, 22 Sep 1997 09:10:29 -0700 (PDT) Received: from gratis.grondar.za (gratis.grondar.za [196.7.18.133]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id JAA22675 for ; Mon, 22 Sep 1997 09:10:00 -0700 (PDT) Received: from greenpeace.grondar.za (la/7kbB7gdMneJ+XJI8A/cGtfrNV5YCJ@greenpeace.grondar.za [196.7.18.132]) by gratis.grondar.za (8.8.7/8.8.7) with ESMTP id SAA00221; Mon, 22 Sep 1997 18:09:52 +0200 (SAT) Received: from greenpeace.grondar.za (eyiBOFDm3BQukCEHEhL6LgFILSlj5QxA@localhost [127.0.0.1]) by greenpeace.grondar.za (8.8.7/8.8.7) with ESMTP id SAA05626; Mon, 22 Sep 1997 18:09:59 +0200 (SAT) Message-Id: <199709221609.SAA05626@greenpeace.grondar.za> X-Mailer: exmh version 2.0zeta 7/24/97 To: Chuck Robey cc: FreeBSD current Subject: Re: ctm blowup Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 22 Sep 1997 18:09:58 +0200 From: Mark Murray Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Chuck Robey wrote: > I got a little behind in applying ctm updates (a day ago), and when I > finally got to doing 3670 (immediately after 3669), here's what I found: > > ctm_rmail: cvs-cur.3669.gz applied > ctm_rmail: ctm: DM: src/kerberosIV exists. > ctm_rmail: ctm: Exit(80) > > Anyone know what that was, or how I could get ctm back on track? Blow away your ncvs/src/kerberosIV before applying 3670. M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org From owner-freebsd-current Mon Sep 22 09:12:18 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id JAA22845 for current-outgoing; Mon, 22 Sep 1997 09:12:18 -0700 (PDT) Received: from time.cdrom.com (root@time.cdrom.com [204.216.27.226]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id JAA22835 for ; Mon, 22 Sep 1997 09:12:13 -0700 (PDT) Received: from time.cdrom.com (jkh@localhost.cdrom.com [127.0.0.1]) by time.cdrom.com (8.8.7/8.6.9) with ESMTP id JAA12598 for ; Mon, 22 Sep 1997 09:12:44 -0700 (PDT) To: current@freebsd.org Subject: Daily SNAPshots at current.freebsd.org shut down for now. Date: Mon, 22 Sep 1997 09:12:43 -0700 Message-ID: <12587.874944763@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk The SNAPshot server will not be producing 3.0 or 2.2 daily snapshots until the vn driver is fixed. It causes kernel panics on use now and this prevents the boot floppies from being made (nor is there much sense in having the machine crash once a day on this bug). This service is therefore discontinued until further notice. Jordan From owner-freebsd-current Mon Sep 22 09:16:31 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id JAA23235 for current-outgoing; Mon, 22 Sep 1997 09:16:31 -0700 (PDT) Received: from pluto.plutotech.com (root@mail.plutotech.com [206.168.67.137]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id JAA23222 for ; Mon, 22 Sep 1997 09:16:23 -0700 (PDT) Received: from narnia.plutotech.com (narnia.plutotech.com [206.168.67.130]) by pluto.plutotech.com (8.8.5/8.8.5) with ESMTP id KAA18273; Mon, 22 Sep 1997 10:16:01 -0600 (MDT) Message-Id: <199709221616.KAA18273@pluto.plutotech.com> X-Mailer: exmh version 2.0zeta 7/24/97 To: Bruce Evans cc: gibbs@plutotech.com, current@FreeBSD.ORG, nate@mt.sri.com Subject: Re: cvs commit: src/sys/conf files src/sys/dev/vx if_vx.c if_vxreg.h src/sys/i386/apm apm.c src/sys/i386/conf GENERIC files.i386 src/sys/i386/eisa 3c5x9.c aha1742.c aic7770.c bt74x.c eisaconf.c eisaconf.h if_fea.c if_vx_eisa.c src/sys/i386/i386 autoconf.c ... In-reply-to: Your message of "Tue, 23 Sep 1997 01:53:46 +1000." <199709221553.BAA20408@godzilla.zeta.org.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 22 Sep 1997 10:15:50 -0600 From: "Justin T. Gibbs" Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >>How much storage do I need in order to realloc the arrays? Is it bounded? > >No, but it is too small to matter. 63 transactions on each of 520 drives >can be supported using just two blocks of size 4K. Each queue entry takes >only 2 bits. This is 96 times denser than the current callout table. And runs in roughly O(n) time every time the interval timer expires. You also leave out the part about being able to index to transaction whose timer actually expired which will take additional space. If you have 520 drives, you can probably spare the 1MB that is used in the current scheme. >Only clients that need a large number of timeouts. I think there aren't >many, and the ones that do can benefit from a special solutions. We'll see. >Bruce -- Justin T. Gibbs =========================================== FreeBSD: Turning PCs into workstations =========================================== From owner-freebsd-current Mon Sep 22 09:31:05 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id JAA24657 for current-outgoing; Mon, 22 Sep 1997 09:31:05 -0700 (PDT) Received: from ns.mt.sri.com (SRI-56K-FR.mt.net [206.127.65.42]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id JAA24646 for ; Mon, 22 Sep 1997 09:30:53 -0700 (PDT) Received: from rocky.mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.8.7/8.8.7) with ESMTP id KAA13339; Mon, 22 Sep 1997 10:30:41 -0600 (MDT) Received: (from nate@localhost) by rocky.mt.sri.com (8.7.5/8.7.3) id KAA01072; Mon, 22 Sep 1997 10:30:40 -0600 (MDT) Date: Mon, 22 Sep 1997 10:30:40 -0600 (MDT) Message-Id: <199709221630.KAA01072@rocky.mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: "Justin T. Gibbs" Cc: Bruce Evans , current@freebsd.org, nate@mt.sri.com Subject: Re: cvs commit: src/sys/conf files src/sys/dev/vx if_vx.c if_vxreg.h src/sys/i386/apm apm.c src/sys/i386/conf GENERIC files.i386 src/sys/i386/eisa 3c5x9.c aha1742.c aic7770.c bt74x.c eisaconf.c eisaconf.h if_fea.c if_vx_eisa.c src/sys/i386/i386 autoconf.c ... In-Reply-To: <199709221616.KAA18273@pluto.plutotech.com> References: <199709221553.BAA20408@godzilla.zeta.org.au> <199709221616.KAA18273@pluto.plutotech.com> X-Mailer: VM 6.29 under 19.15 XEmacs Lucid Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > >>How much storage do I need in order to realloc the arrays? Is it bounded? > > > >No, but it is too small to matter. 63 transactions on each of 520 drives > >can be supported using just two blocks of size 4K. Each queue entry takes > >only 2 bits. This is 96 times denser than the current callout table. > > And runs in roughly O(n) time every time the interval timer expires. Except that processing a tick now runs O(n), where n is the # of elements in the callout wheel (which gets pretty big when you have 630 callouts in your example above, since the initial size of the callout wheel is set), so I still don't see a big win. I'm not saying that it's any worse/better than the existing scheme, in fact I don't see a win. Stating that it takes O(n) times to add/remove a callout and calling it a win when it takes O(n) time to process a tick isn't a win in my book. PHK answered by saying that on his laptop, it seemed to be a wash, so that's encouraging, but it seems to have the ability to make the system slower. (I'd like to see how PHK compared the two approaches.) Finally, you'll notice that I'm not proposing the we rip out the new solution (since I have nothing better to propose, although the original solution could be sped up by adding the setcallout()/unsetcallout() additions w/out the call wheel). I just want to understand *why* it's making things better for the average user, since the average user doesn't have > 10 drives running tags. Penalizing the 'extreme' user doesn't seem to be a big win in my book. In summary, all of the operations are called 'often'. 1) clock ticks 2) registering timeouts 3) de-registering timeouts I would like to see some #'s that show us the # & amount of time it takes in section on a 'normal' system, using both approaches. If someone has some good ideas how to do that, I'm willing to learn something and go do it. Nate From owner-freebsd-current Mon Sep 22 10:12:57 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id KAA29940 for current-outgoing; Mon, 22 Sep 1997 10:12:57 -0700 (PDT) Received: from mail.scsn.net (scsn.net [206.25.246.12]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id KAA29932 for ; Mon, 22 Sep 1997 10:12:54 -0700 (PDT) Received: from rhiannon.scsn.net ([208.133.153.152]) by mail.scsn.net (Post.Office MTA v3.1 release PO203a ID# 0-41950U6000L1100S0) with ESMTP id AAA220; Mon, 22 Sep 1997 13:13:19 -0400 Received: (from root@localhost) by rhiannon.scsn.net (8.8.7/8.8.5) id NAA00985; Mon, 22 Sep 1997 13:12:44 -0400 (EDT) Message-ID: <19970922131243.58643@scsn.net> Date: Mon, 22 Sep 1997 13:12:43 -0400 From: "Donald J. Maddox" To: Ollivier Robert Cc: current@FreeBSD.ORG Subject: Re: Netscape 4.03b8 doesn't work after poll/select changes Reply-To: dmaddox@scsn.net References: <19970922160600.17406@caerdonn.eurocontrol.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.81 In-Reply-To: <19970922160600.17406@caerdonn.eurocontrol.fr>; from Ollivier Robert on Mon, Sep 22, 1997 at 04:06:00PM +0200 Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Mon, Sep 22, 1997 at 04:06:00PM +0200, Ollivier Robert wrote: > I have a problem with Netscape since the poll/select changes... It doesn't > work at all. No window is displayed and the process seems to be sleeping in > > 1193 23985 232 35 2 0 8096 2896 select I+ p4 0:00.39 /usr/local/l > 1193 23986 23985 12 2 0 7340 1908 select I+ p4 0:00.06 (dns helper) > It works for me, but occaisonally hangs hard... At these times, top invariably shows that it is hung in poll(). From owner-freebsd-current Mon Sep 22 10:25:57 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id KAA01082 for current-outgoing; Mon, 22 Sep 1997 10:25:57 -0700 (PDT) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id KAA01052 for ; Mon, 22 Sep 1997 10:25:53 -0700 (PDT) Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.5/8.6.9) id DAA23286; Tue, 23 Sep 1997 03:23:55 +1000 Date: Tue, 23 Sep 1997 03:23:55 +1000 From: Bruce Evans Message-Id: <199709221723.DAA23286@godzilla.zeta.org.au> To: bde@zeta.org.au, gibbs@plutotech.com Subject: Re: cvs commit: src/sys/conf files src/sys/dev/vx if_vx.c if_vxreg.h src/sys/i386/apm apm.c src/sys/i386/conf GENERIC files.i386 src/sys/i386/eisa 3c5x9.c aha1742.c aic7770.c bt74x.c eisaconf.c eisaconf.h if_fea.c if_vx_eisa.c src/sys/i386/i386 autoconf.c ... Cc: current@FreeBSD.ORG, nate@mt.sri.com Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >>only 2 bits. This is 96 times denser than the current callout table. > >And runs in roughly O(n) time every time the interval timer expires. You No, it is O(1) in the usual case where the hardware has not timed out, and O(n/32) (sic) otherwise (the bitmap can be scanned 32 bits at a time, so 630 entries can be scanned in < 1us on a P5). >also leave out the part about being able to index to transaction whose >timer actually expired which will take additional space. Maybe. I know the drive number and the transaction number, and there's presumably at worst a linked list of transactions attached to the drive somehow (at best there's an array), and a linear search of this list shouldn't take too long for an exceptional action. Bruce From owner-freebsd-current Mon Sep 22 10:30:50 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id KAA01761 for current-outgoing; Mon, 22 Sep 1997 10:30:50 -0700 (PDT) Received: from pluto.plutotech.com (root@mail.plutotech.com [206.168.67.137]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id KAA01747 for ; Mon, 22 Sep 1997 10:30:45 -0700 (PDT) Received: from narnia.plutotech.com (narnia.plutotech.com [206.168.67.130]) by pluto.plutotech.com (8.8.5/8.8.5) with ESMTP id LAA21758; Mon, 22 Sep 1997 11:30:35 -0600 (MDT) Message-Id: <199709221730.LAA21758@pluto.plutotech.com> X-Mailer: exmh version 2.0zeta 7/24/97 To: Bruce Evans cc: gibbs@plutotech.com, current@FreeBSD.ORG, nate@mt.sri.com Subject: Re: cvs commit: src/sys/conf files src/sys/dev/vx if_vx.c if_vxreg.h src/sys/i386/apm apm.c src/sys/i386/conf GENERIC files.i386 src/sys/i386/eisa 3c5x9.c aha1742.c aic7770.c bt74x.c eisaconf.c eisaconf.h if_fea.c if_vx_eisa.c src/sys/i386/i386 autoconf.c ... In-reply-to: Your message of "Tue, 23 Sep 1997 03:23:55 +1000." <199709221723.DAA23286@godzilla.zeta.org.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 22 Sep 1997 11:30:24 -0600 From: "Justin T. Gibbs" Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >>>only 2 bits. This is 96 times denser than the current callout table. >> >>And runs in roughly O(n) time every time the interval timer expires. You > >No, it is O(1) in the usual case where the hardware has not timed out, >and O(n/32) (sic) otherwise (the bitmap can be scanned 32 bits at a time, >so 630 entries can be scanned in < 1us on a P5). Don't you have to look at each transaction when the interval timer goes off to see which, if any, of the transactions have expired? Remember that different transactions can have different timeout intervals. In the current SCSI system some tape operations have hour long timeouts while most disk activity is 10s, etc. >>also leave out the part about being able to index to transaction whose >>timer actually expired which will take additional space. > >Maybe. I know the drive number and the transaction number, and there's >presumably at worst a linked list of transactions attached to the drive >somehow (at best there's an array), and a linear search of this list >shouldn't take too long for an exceptional action. But it does take space. >Bruce -- Justin T. Gibbs =========================================== FreeBSD: Turning PCs into workstations =========================================== From owner-freebsd-current Mon Sep 22 10:37:23 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id KAA02550 for current-outgoing; Mon, 22 Sep 1997 10:37:23 -0700 (PDT) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id KAA02538 for ; Mon, 22 Sep 1997 10:37:18 -0700 (PDT) Received: (from daemon@localhost) by alpo.whistle.com (8.8.5/8.8.5) id KAA02955; Mon, 22 Sep 1997 10:01:29 -0700 (PDT) Received: from current1.whistle.com(207.76.205.22) via SMTP by alpo.whistle.com, id smtpd002951; Mon Sep 22 17:01:28 1997 Message-ID: <3426AA40.41C67EA6@whistle.com> Date: Mon, 22 Sep 1997 10:26:24 -0700 From: Julian Elischer Organization: Whistle Communications X-Mailer: Mozilla 3.0Gold (X11; I; FreeBSD 2.2-CURRENT i386) MIME-Version: 1.0 To: "Justin T. Gibbs" CC: Bruce Evans , nate@mt.sri.com, current@FreeBSD.ORG Subject: Re: cvs commit: src/sys/conf files src/sys/dev/vx if_vx.c if_vxreg.h src/sys/i386/apm apm.c src/sys/i386/conf GENERIC files.i386 src/sys/i386/eisa 3c5x9.c aha1742.c aic7770.c bt74x.c eisaconf.c eisaconf.h if_fea.c if_vx_eisa.c src/sys/i386/i386 a References: <199709221347.HAA15157@pluto.plutotech.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Justin T. Gibbs wrote: The thing I don't like abut what has been done is: It's changed a very standard and well understood service in the kernel. I think you should have left it the same and implimented a cam_timeout facility that runs separatly. all my drivers that are shared between various OS now need to be modified, with a new #if defined(__FreeBSD__) in them. > > >>Take a server with 10 Seagate disks. Each one of these disks can > >>handle 63 transactions at a time. If you split the disks across > >>controllers correctly, you can readily keep them saturated with > >>requests. Thats 630 pending callouts and an O(n) hit for insert > >>and removal... > > > >Assuming that the timeout length is not very critical, and that timeouts > >rarely expire, this setup could be optimized well using "queues" > >consisting of two (pointers to) arrays of bits, and counters for the > >number of items set in each array: > > Now make it scale during usage. There are lots of schemes available, > but very few are easily scalable by mallocing small chunks of free > memory. > > >Bruce > > -- > Justin T. Gibbs > =========================================== > FreeBSD: Turning PCs into workstations > =========================================== From owner-freebsd-current Mon Sep 22 10:45:44 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id KAA03430 for current-outgoing; Mon, 22 Sep 1997 10:45:44 -0700 (PDT) Received: from ns.mt.sri.com (SRI-56K-FR.mt.net [206.127.65.42]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id KAA03414 for ; Mon, 22 Sep 1997 10:45:38 -0700 (PDT) Received: from rocky.mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.8.7/8.8.7) with ESMTP id LAA13814; Mon, 22 Sep 1997 11:45:25 -0600 (MDT) Received: (from nate@localhost) by rocky.mt.sri.com (8.7.5/8.7.3) id LAA01369; Mon, 22 Sep 1997 11:45:24 -0600 (MDT) Date: Mon, 22 Sep 1997 11:45:24 -0600 (MDT) Message-Id: <199709221745.LAA01369@rocky.mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Julian Elischer Cc: "Justin T. Gibbs" , Bruce Evans , nate@mt.sri.com, current@freebsd.org Subject: Re: cvs commit: src/sys/conf files src/sys/dev/vx if_vx.c if_vxreg.h src/sys/i386/apm apm.c src/sys/i386/conf GENERIC files.i386 src/sys/i386/eisa 3c5x9.c aha1742.c aic7770.c bt74x.c eisaconf.c eisaconf.h if_fea.c if_vx_eisa.c src/sys/i386/i386 a In-Reply-To: <3426AA40.41C67EA6@whistle.com> References: <199709221347.HAA15157@pluto.plutotech.com> <3426AA40.41C67EA6@whistle.com> X-Mailer: VM 6.29 under 19.15 XEmacs Lucid Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > The thing I don't like abut what has been done is: > > It's changed a very standard and well understood service in the kernel. > I think you should have left it the same and implimented a cam_timeout > facility that runs separatly. In theory, I disagree. We can't 'move forward' w/out breaking device compatability with other systems, and if the changes allow to effeciently do things in the manner described in the paper, it's a step in the right direction. For example, making the VM system 'useful' required changing a standard kernel interface (although it was neither well documented nor well understood.) But, I want to know that it is indeed an improvement, and not merely a change that is needed to support Justin's CAM work, and something that could have been done in a manner that took the good ideas from the work but implemented them in a manner that was less intrusive. > all my drivers that are shared between various OS now need to > be modified, with a new #if defined(__FreeBSD__) in them. Actually, if Justin's work was the same as the original code, you should still be able to use the old 'timeout' functionality, it just doens't take advantage of some of the newer features. Nate From owner-freebsd-current Mon Sep 22 10:55:37 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id KAA04399 for current-outgoing; Mon, 22 Sep 1997 10:55:37 -0700 (PDT) Received: from pluto.plutotech.com (root@mail.plutotech.com [206.168.67.137]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id KAA04393 for ; Mon, 22 Sep 1997 10:55:34 -0700 (PDT) Received: from narnia.plutotech.com (narnia.plutotech.com [206.168.67.130]) by pluto.plutotech.com (8.8.5/8.8.5) with ESMTP id LAA25129; Mon, 22 Sep 1997 11:55:22 -0600 (MDT) Message-Id: <199709221755.LAA25129@pluto.plutotech.com> X-Mailer: exmh version 2.0zeta 7/24/97 To: Nate Williams cc: "Justin T. Gibbs" , Bruce Evans , current@freebsd.org Subject: Re: cvs commit: src/sys/conf files src/sys/dev/vx if_vx.c if_vxreg.h src/sys/i386/apm apm.c src/sys/i386/conf GENERIC files.i386 src/sys/i386/eisa 3c5x9.c aha1742.c aic7770.c bt74x.c eisaconf.c eisaconf.h if_fea.c if_vx_eisa.c src/sys/i386/i386 autoconf.c ... In-reply-to: Your message of "Mon, 22 Sep 1997 10:30:40 MDT." <199709221630.KAA01072@rocky.mt.sri.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 22 Sep 1997 11:55:12 -0600 From: "Justin T. Gibbs" Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >Except that processing a tick now runs O(n), where n is the # of >elements in the callout wheel (which gets pretty big when you have 630 >callouts in your example above, since the initial size of the callout >wheel is set), so I still don't see a big win. I'm not saying that it's >any worse/better than the existing scheme, in fact I don't see a win. Let's be more precise. n = number of active callouts h = length of a hash chain in a call wheel bucket x = number of callout expired on a given tick. Old implementation: timeout = O(n) untimeout = O(n) softclock = O(x) ~= O(1) New implemenation: timeout = O(1) untimeout = O(1) softclock = O(h) Now depending on how you size your callwheel, h << n. With a MAXUSERS of 32, the callwheel is 256 entries big if I recall correctly. But running time isn't the only thing to consider. As I mentioned before, untimeout/timeout are often called from an interrupt context and the old algorithm caused an indeterminate delay in this scenario, potentially causing problems for that device and any that share the same interrupt. You also have to consider that timeout/untimeout calls occur at indeterminate rates, but softclock runs at a fixed rate meaning that the amount of work it performs scales better than if that work was pushed off into either of timeout or untimeout. >Finally, you'll notice that I'm not proposing the we rip out the new >solution (since I have nothing better to propose, although the original >solution could be sped up by adding the setcallout()/unsetcallout() >additions w/out the call wheel). That only fixes untimeout. >I just want to understand *why* it's >making things better for the average user, since the average user >doesn't have > 10 drives running tags. Penalizing the 'extreme' user >doesn't seem to be a big win in my book. The typical user will have perhaps 30 callouts outstanding. In this scenario, both algorithms work fairly well. Although PHK's BB profiling did show that the new implementation was faster, he didn't perceive a difference in performance. Since he was using IDE devices, he had even fewer timeouts active than if he were using SCSI disks. The main difference between the two approaches is that one algorithm scales better than the other. >In summary, all of the operations are called 'often'. > >1) clock ticks >2) registering timeouts >3) de-registering timeouts > >I would like to see some #'s that show us the # & amount of time it >takes in section on a 'normal' system, using both approaches. If >someone has some good ideas how to do that, I'm willing to learn >something and go do it. Allocate an array of ints of size ncallout. In softclock, increment the array entry corresponding to the number of entries traversed in a softclock run. By periodically scanning this array, you'll get a good idea of the value of 'h' for you system. Add three more ints that count the number of invocations of softclock, untimeout, and timeout and you should be able to draw conclusions from that. You may also want to look at the other paper I mention in the timeout.9 man page. It may have some of the statistics you want, but I don't know for sure that they ever implemented their schemes in a real system. >Nate -- Justin T. Gibbs =========================================== FreeBSD: Turning PCs into workstations =========================================== From owner-freebsd-current Mon Sep 22 11:02:32 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id LAA04798 for current-outgoing; Mon, 22 Sep 1997 11:02:32 -0700 (PDT) Received: from pluto.plutotech.com (root@mail.plutotech.com [206.168.67.137]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id LAA04791 for ; Mon, 22 Sep 1997 11:02:27 -0700 (PDT) Received: from narnia.plutotech.com (narnia.plutotech.com [206.168.67.130]) by pluto.plutotech.com (8.8.5/8.8.5) with ESMTP id MAA25322; Mon, 22 Sep 1997 12:01:59 -0600 (MDT) Message-Id: <199709221801.MAA25322@pluto.plutotech.com> X-Mailer: exmh version 2.0zeta 7/24/97 To: Julian Elischer cc: "Justin T. Gibbs" , Bruce Evans , nate@mt.sri.com, current@FreeBSD.ORG Subject: Re: cvs commit: src/sys/conf files src/sys/dev/vx if_vx.c if_vxreg.h src/sys/i386/apm apm.c src/sys/i386/conf GENERIC files.i386 src/sys/i386/eisa 3c5x9.c aha1742.c aic7770.c bt74x.c eisaconf.c eisaconf.h if_fea.c if_vx_eisa.c src/sys/i386/i386 a In-reply-to: Your message of "Mon, 22 Sep 1997 10:26:24 PDT." <3426AA40.41C67EA6@whistle.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 22 Sep 1997 12:01:48 -0600 From: "Justin T. Gibbs" Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >Justin T. Gibbs wrote: > >The thing I don't like abut what has been done is: > >It's changed a very standard and well understood service in the kernel. >I think you should have left it the same and implimented a cam_timeout >facility that runs separatly. > >all my drivers that are shared between various OS now need to >be modified, with a new #if defined(__FreeBSD__) in them. Various BSDs. I chose not to implement a backwards compatibility interface as I'd have to allocate even more space to make it as efficient as the new one and updating client code is easy to do. It's a small price to pay for progress and it's not as though we haven't changed other interfaces in the kernel to differ from other BSDs. The proposed change was discussed in Core well in advance of my commit. -- Justin T. Gibbs =========================================== FreeBSD: Turning PCs into workstations =========================================== From owner-freebsd-current Mon Sep 22 11:13:13 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id LAA05580 for current-outgoing; Mon, 22 Sep 1997 11:13:13 -0700 (PDT) Received: from ns.mt.sri.com (SRI-56K-FR.mt.net [206.127.65.42]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id LAA05570 for ; Mon, 22 Sep 1997 11:13:08 -0700 (PDT) Received: from rocky.mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.8.7/8.8.7) with ESMTP id MAA14044; Mon, 22 Sep 1997 12:13:00 -0600 (MDT) Received: (from nate@localhost) by rocky.mt.sri.com (8.7.5/8.7.3) id MAA01622; Mon, 22 Sep 1997 12:12:59 -0600 (MDT) Date: Mon, 22 Sep 1997 12:12:59 -0600 (MDT) Message-Id: <199709221812.MAA01622@rocky.mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: "Justin T. Gibbs" Cc: Nate Williams , Bruce Evans , current@freebsd.org Subject: Re: cvs commit: src/sys/conf files src/sys/dev/vx if_vx.c if_vxreg.h src/sys/i386/apm apm.c src/sys/i386/conf GENERIC files.i386 src/sys/i386/eisa 3c5x9.c aha1742.c aic7770.c bt74x.c eisaconf.c eisaconf.h if_fea.c if_vx_eisa.c src/sys/i386/i386 autoconf.c ... In-Reply-To: <199709221755.LAA25129@pluto.plutotech.com> References: <199709221630.KAA01072@rocky.mt.sri.com> <199709221755.LAA25129@pluto.plutotech.com> X-Mailer: VM 6.29 under 19.15 XEmacs Lucid Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > >Except that processing a tick now runs O(n), where n is the # of > >elements in the callout wheel (which gets pretty big when you have 630 > >callouts in your example above, since the initial size of the callout > >wheel is set), so I still don't see a big win. I'm not saying that it's > >any worse/better than the existing scheme, in fact I don't see a win. > > Let's be more precise. > n = number of active callouts > h = length of a hash chain in a call wheel bucket > x = number of callout expired on a given tick. > > Old implementation: > timeout = O(n) > untimeout = O(n) > softclock = O(x) ~= O(1) > > New implemenation: > timeout = O(1) > untimeout = O(1) > softclock = O(h) > > Now depending on how you size your callwheel, h << n. With a MAXUSERS > of 32, the callwheel is 256 entries big if I recall correctly. What is it for a 'typical' workstation, which is the one shipped in GENERIC using 'maxusers 10'? > But running time isn't the only thing to consider. As I mentioned > before, untimeout/timeout are often called from an interrupt context > and the old algorithm caused an indeterminate delay in this scenario, > potentially causing problems for that device and any that share the > same interrupt. 'softclock()' is also called with some interrupt() masked as well, isn't it? > You also have to consider that timeout/untimeout calls occur at > indeterminate rates, but softclock runs at a fixed rate meaning that > the amount of work it performs scales better than if that work was > pushed off into either of timeout or untimeout. True, but if it's 'worst-case' time happens often enough, we're penalizing the system *alot* more than during timeout/untimeout, which happens much less rarely. The 'gotcha' is that I don't know if this is a 'normal' case, since the paper didn't test normal cases, but instead did lots of timeout/untimeouts in a user-land process, which stacks the test data in favor of the new implementation. > >Finally, you'll notice that I'm not proposing the we rip out the new > >solution (since I have nothing better to propose, although the original > >solution could be sped up by adding the setcallout()/unsetcallout() > >additions w/out the call wheel). > > That only fixes untimeout. True, but w/out any real numbers to show which one causes the biggest latency problems, it's hard to know *where* the bottleneck is. (Or, if there is a bottleneck at all...) > >I just want to understand *why* it's > >making things better for the average user, since the average user > >doesn't have > 10 drives running tags. Penalizing the 'extreme' user > >doesn't seem to be a big win in my book. > > The typical user will have perhaps 30 callouts outstanding. In this > scenario, both algorithms work fairly well. Although PHK's BB profiling > did show that the new implementation was faster, he didn't perceive > a difference in performance. Since he was using IDE devices, he had > even fewer timeouts active than if he were using SCSI disks. > > The main difference between the two approaches is that one algorithm > scales better than the other. Does it? If softclock() is now a bottleneck more often now than timeout/untimeout previously, it scales worse. It would be nice to see some real data that tells us how often each operation is called, and how long it takes to do each one. > >In summary, all of the operations are called 'often'. > > > >1) clock ticks > >2) registering timeouts > >3) de-registering timeouts > > > >I would like to see some #'s that show us the # & amount of time it > >takes in section on a 'normal' system, using both approaches. If > >someone has some good ideas how to do that, I'm willing to learn > >something and go do it. > > Allocate an array of ints of size ncallout. In softclock, increment the > array entry corresponding to the number of entries traversed in a softclock > run. By periodically scanning this array, you'll get a good idea of the > value of 'h' for you system. Add three more ints that count the number of > invocations of softclock, untimeout, and timeout and you should be able to > draw conclusions from that. But, that doesn't give me any latency #'s for any of the operations. Knowing how often they are called is one thing, and knowing how many entries are traversed is good, but *times* are the bigger issue. > You may also want to look at the other paper I mention in the timeout.9 > man page. It may have some of the statistics you want, but I don't know > for sure that they ever implemented their schemes in a real system. I'll do that, but the reason I'm a bit skeptical is because these schemes were never 'tested' in a real system, only in test systems stacked to show that their new scheme does do what it intended to do. (How well this affects real systems is still to be seen.) Nate From owner-freebsd-current Mon Sep 22 11:24:48 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id LAA06329 for current-outgoing; Mon, 22 Sep 1997 11:24:48 -0700 (PDT) Received: from critter.freebsd.dk (critter.freebsd.dk [195.8.129.26]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id LAA06314 for ; Mon, 22 Sep 1997 11:24:28 -0700 (PDT) Received: from critter.freebsd.dk (localhost.cybercity.dk [127.0.0.1]) by critter.freebsd.dk (8.8.7/8.8.7) with ESMTP id UAA00614; Mon, 22 Sep 1997 20:22:37 +0200 (CEST) To: Nate Williams cc: "Justin T. Gibbs" , Bruce Evans , current@FreeBSD.ORG Subject: Re: cvs commit: src/sys/conf files src/sys/dev/vx if_vx.c if_vxreg.h src/sys/i386/apm apm.c src/sys/i386/conf GENERIC files.i386 src/sys/i386/eisa 3c5x9.c aha1742.c aic7770.c bt74x.c eisaconf.c eisaconf.h if_fea.c if_vx_eisa.c src/sys/i386/i386 autoconf.c ... In-reply-to: Your message of "Mon, 22 Sep 1997 10:30:40 MDT." <199709221630.KAA01072@rocky.mt.sri.com> Date: Mon, 22 Sep 1997 20:22:37 +0200 Message-ID: <612.874952557@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk In message <199709221630.KAA01072@rocky.mt.sri.com>, Nate Williams writes: >Stating that it takes O(n) times to add/remove a callout and calling it >a win when it takes O(n) time to process a tick isn't a win in my book. > >PHK answered by saying that on his laptop, it seemed to be a wash, so >that's encouraging, but it seems to have the ability to make the system >slower. (I'd like to see how PHK compared the two approaches.) elapsed time for make world, including careful scrutinizing the basic- block profiling output. This is the kind of stuff my new "rover" setup is meant to be able to measure. I have a standard deviation of less than 1 part in thousand for real + user time, and less than 1 in 300 for system time, so very small changes can be measured rather reliably. Anyway, it shouldn't be to hard to make either of the old and the new implementations available under a compile option, the new calling API is a a superset of the old, isn't it ? -- Poul-Henning Kamp FreeBSD coreteam member phk@FreeBSD.ORG "Real hackers run -current on their laptop." From owner-freebsd-current Mon Sep 22 11:26:08 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id LAA06464 for current-outgoing; Mon, 22 Sep 1997 11:26:08 -0700 (PDT) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id LAA06454 for ; Mon, 22 Sep 1997 11:26:03 -0700 (PDT) Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.5/8.6.9) id EAA25174; Tue, 23 Sep 1997 04:22:12 +1000 Date: Tue, 23 Sep 1997 04:22:12 +1000 From: Bruce Evans Message-Id: <199709221822.EAA25174@godzilla.zeta.org.au> To: gibbs@plutotech.com, nate@mt.sri.com Subject: Re: cvs commit: src/sys/conf files src/sys/dev/vx if_vx.c if_vxreg.h src/sys/i386/apm apm.c src/sys/i386/conf GENERIC files.i386 src/sys/i386/eisa 3c5x9.c aha1742.c aic7770.c bt74x.c eisaconf.c eisaconf.h if_fea.c if_vx_eisa.c src/sys/i386/i386 autoconf.c ... Cc: bde@zeta.org.au, current@FreeBSD.ORG Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >> >only 2 bits. This is 96 times denser than the current callout table. >> >> And runs in roughly O(n) time every time the interval timer expires. But it doesn't. Since the point of the new method is to avoid O(n) behaviour, of course I presented a method that was O(1) in the usual case. >Except that processing a tick now runs O(n), where n is the # of >elements in the callout wheel (which gets pretty big when you have 630 >callouts in your example above, since the initial size of the callout Not great. My method uses a split queue to usually avoid having to look at the half expired timeouts. The old method used a delta list for similar reasons. I'm surprised that there is no trace of delta lists in the new method. >wheel is set), so I still don't see a big win. I'm not saying that it's >any worse/better than the existing scheme, in fact I don't see a win. However, it's only O(n). The old method was O(n^2) for each insertion and deletion, which makes it O(n^2) altogether. >Stating that it takes O(n) times to add/remove a callout and calling it >a win when it takes O(n) time to process a tick isn't a win in my book. The point is that the tick interval is fixed. >PHK answered by saying that on his laptop, it seemed to be a wash, so >that's encouraging, but it seems to have the ability to make the system >slower. (I'd like to see how PHK compared the two approaches.) timeout() probably doesn't get called enough to matter. >additions w/out the call wheel). I just want to understand *why* it's >making things better for the average user, since the average user >doesn't have > 10 drives running tags. Penalizing the 'extreme' user >doesn't seem to be a big win in my book. I expect it will make things slightly worse for the average user, but the difference will be too small to measure. >In summary, all of the operations are called 'often'. > >1) clock ticks No, they only occur every 10 ms, which is approximately eternity for a fast CPU :-). >2) registering timeouts >3) de-registering timeouts >I would like to see some #'s that show us the # & amount of time it >takes in section on a 'normal' system, using both approaches. If >someone has some good ideas how to do that, I'm willing to learn >something and go do it. Profiling should show completely accurate numbers. High-resolution profiling (config -pp and kgmon -B ... gprof4 ...) should show fairly accurate times. Bruce From owner-freebsd-current Mon Sep 22 11:37:18 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id LAA07576 for current-outgoing; Mon, 22 Sep 1997 11:37:18 -0700 (PDT) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id LAA07569 for ; Mon, 22 Sep 1997 11:37:15 -0700 (PDT) Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.5/8.6.9) id EAA25518; Tue, 23 Sep 1997 04:34:51 +1000 Date: Tue, 23 Sep 1997 04:34:51 +1000 From: Bruce Evans Message-Id: <199709221834.EAA25518@godzilla.zeta.org.au> To: bde@zeta.org.au, gibbs@plutotech.com Subject: Re: cvs commit: src/sys/conf files src/sys/dev/vx if_vx.c if_vxreg.h src/sys/i386/apm apm.c src/sys/i386/conf GENERIC files.i386 src/sys/i386/eisa 3c5x9.c aha1742.c aic7770.c bt74x.c eisaconf.c eisaconf.h if_fea.c if_vx_eisa.c src/sys/i386/i386 autoconf.c ... Cc: current@FreeBSD.ORG, nate@mt.sri.com Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >>>And runs in roughly O(n) time every time the interval timer expires. You >> >>No, it is O(1) in the usual case where the hardware has not timed out, >>and O(n/32) (sic) otherwise (the bitmap can be scanned 32 bits at a time, >>so 630 entries can be scanned in < 1us on a P5). > >Don't you have to look at each transaction when the interval timer goes >off to see which, if any, of the transactions have expired? Remember No, I kept 2 "queues" and expect all the transactions on the head queue to complete before their timeouts expire. >that different transactions can have different timeout intervals. In >the current SCSI system some tape operations have hour long timeouts >while most disk activity is 10s, etc. I cheated here by assuming only one timeout interval (and slop of one more timeout interval) . The pair of queues would have to be repeated for each timeout interval. SCSI timeout intervals are fairly arbitrary, so it might be enough to have timeouts for 1, 10, 100, 1000 and 10000 seconds. >>>also leave out the part about being able to index to transaction whose >>>timer actually expired which will take additional space. >> >>Maybe. I know the drive number and the transaction number, and there's >>presumably at worst a linked list of transactions attached to the drive >>somehow (at best there's an array), and a linear search of this list >>shouldn't take too long for an exceptional action. > >But it does take space. Don't you have to keep the transactions somewhere already? Bruce From owner-freebsd-current Mon Sep 22 11:38:45 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id LAA07685 for current-outgoing; Mon, 22 Sep 1997 11:38:45 -0700 (PDT) Received: from ns.mt.sri.com (SRI-56K-FR.mt.net [206.127.65.42]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id LAA07674 for ; Mon, 22 Sep 1997 11:38:39 -0700 (PDT) Received: from rocky.mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.8.7/8.8.7) with ESMTP id MAA14222; Mon, 22 Sep 1997 12:38:32 -0600 (MDT) Received: (from nate@localhost) by rocky.mt.sri.com (8.7.5/8.7.3) id MAA01799; Mon, 22 Sep 1997 12:38:31 -0600 (MDT) Date: Mon, 22 Sep 1997 12:38:31 -0600 (MDT) Message-Id: <199709221838.MAA01799@rocky.mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Bruce Evans Cc: gibbs@plutotech.com, nate@mt.sri.com, current@freebsd.org Subject: Re: cvs commit: src/sys/conf files src/sys/dev/vx if_vx.c if_vxreg.h src/sys/i386/apm apm.c src/sys/i386/conf GENERIC files.i386 src/sys/i386/eisa 3c5x9.c aha1742.c aic7770.c bt74x.c eisaconf.c eisaconf.h if_fea.c if_vx_eisa.c src/sys/i386/i386 autoconf.c ... In-Reply-To: <199709221822.EAA25174@godzilla.zeta.org.au> References: <199709221822.EAA25174@godzilla.zeta.org.au> X-Mailer: VM 6.29 under 19.15 XEmacs Lucid Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Bruce Evans writes: > >> >only 2 bits. This is 96 times denser than the current callout table. > >> > >> And runs in roughly O(n) time every time the interval timer expires. > > But it doesn't. Since the point of the new method is to avoid O(n) > behaviour, of course I presented a method that was O(1) in the usual > case. > > >Except that processing a tick now runs O(n), where n is the # of > >elements in the callout wheel (which gets pretty big when you have 630 > >callouts in your example above, since the initial size of the callout > > Not great. My method uses a split queue to usually avoid having to > look at the half expired timeouts. The old method used a delta list > for similar reasons. I'm surprised that there is no trace of delta > lists in the new method. I am as well. It *seems* to me that this is probably the biggest bottleneck in the softclock() handling, and wouldn't add that much overhead to the timeout registration code (since once you've got the correct hash entry, you could simply copy the head's value, or calculate the new value, neither of which would take that long.) > >wheel is set), so I still don't see a big win. I'm not saying that it's > >any worse/better than the existing scheme, in fact I don't see a win. > > However, it's only O(n). The old method was O(n^2) for each insertion > and deletion, which makes it O(n^2) altogether. Huh? How was O(n^2)? I see it as O(n) for insertion, and O(n) for deletion, which is still O(n). (I'm looking at the 4.3/4.4 books, and don't have the code handy.) > >Stating that it takes O(n) times to add/remove a callout and calling it > >a win when it takes O(n) time to process a tick isn't a win in my book. > > The point is that the tick interval is fixed. But, the time it takes to do softclock is not, and you can sometimes take too long in the softclock interrupt handler. > >PHK answered by saying that on his laptop, it seemed to be a wash, so > >that's encouraging, but it seems to have the ability to make the system > >slower. (I'd like to see how PHK compared the two approaches.) > > timeout() probably doesn't get called enough to matter. Umm, I would think there's a one-one match for timeout/untimeout, wouldn't there? > >additions w/out the call wheel). I just want to understand *why* it's > >making things better for the average user, since the average user > >doesn't have > 10 drives running tags. Penalizing the 'extreme' user > >doesn't seem to be a big win in my book. > > I expect it will make things slightly worse for the average user, but > the difference will be too small to measure. So do you think the new solution is a 'win' overall? > >In summary, all of the operations are called 'often'. > > > >1) clock ticks > > No, they only occur every 10 ms, which is approximately eternity for a > fast CPU :-). > > >2) registering timeouts > >3) de-registering timeouts How often are the above called (in comparison to clock ticks)? Nate From owner-freebsd-current Mon Sep 22 11:39:56 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id LAA07783 for current-outgoing; Mon, 22 Sep 1997 11:39:56 -0700 (PDT) Received: from ns.mt.sri.com (SRI-56K-FR.mt.net [206.127.65.42]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id LAA07778 for ; Mon, 22 Sep 1997 11:39:53 -0700 (PDT) Received: from rocky.mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.8.7/8.8.7) with ESMTP id MAA14230; Mon, 22 Sep 1997 12:39:45 -0600 (MDT) Received: (from nate@localhost) by rocky.mt.sri.com (8.7.5/8.7.3) id MAA01809; Mon, 22 Sep 1997 12:39:44 -0600 (MDT) Date: Mon, 22 Sep 1997 12:39:44 -0600 (MDT) Message-Id: <199709221839.MAA01809@rocky.mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: "Justin T. Gibbs" Cc: Nate Williams , current@freebsd.org Subject: Re: cvs commit: src/sys/conf files src/sys/dev/vx if_vx.c if_vxreg.h src/sys/i386/apm apm.c src/sys/i386/conf GENERIC files.i386 src/sys/i386/eisa 3c5x9.c aha1742.c aic7770.c bt74x.c eisaconf.c eisaconf.h if_fea.c if_vx_eisa.c src/sys/i386/i386 autoconf.c ... In-Reply-To: <199709220548.XAA08824@pluto.plutotech.com> References: <199709220505.XAA29116@rocky.mt.sri.com> <199709220548.XAA08824@pluto.plutotech.com> X-Mailer: VM 6.29 under 19.15 XEmacs Lucid Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > In performing the conversion of all the client code, it became quite > obvious that the common case is to schedule a timeout that will be > canceled before it expires and that the lifetime of a timeout is quite > short. Is 'short' shorter than a single softclock()? If not, then we still need to do more work than we used to do. And, if we have 2 ticks, 'assuming all things we're equal' the new code could be the same speed as the old code. (Obviously bogus explanation follows): Old code: 1) timeout = O(x) ~= 10 seconds 2) untimeout = O(x) ~= 10 seconds 3) softclock = O(1) ~= 1 second So, assuming we call a timeout, get 2 softclock updates, and then call untimeout we get: 10 + 1 + 1 + 10 = 22 seconds. New code: 1) timeout = O(1) ~= 1 seconds 2) untimeout = O(1) ~= 1 seconds 3) softclock = O(n) ~= 10 second The same as above: 1 + 10 + 10 + 1 = 22 seconds. Again, this is so obviously bogus that I hate to even mention it, but it explains what I'm trying to say. Depending on *how often* and *how long* each of the operations takes, the new solution may not be a win. I'll stop for now, since this is as much a learning experience for me as anything, and I don't want to wear out my welcome. :) :) Nate From owner-freebsd-current Mon Sep 22 12:02:05 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id MAA09542 for current-outgoing; Mon, 22 Sep 1997 12:02:05 -0700 (PDT) Received: from ishiboo.com (user20781@bleep.ishiboo.com [206.64.4.20]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id MAA09529 for ; Mon, 22 Sep 1997 12:02:00 -0700 (PDT) From: nirva@ishiboo.com Received: (qmail 21291 invoked by uid 1000); 22 Sep 1997 20:06:29 -0000 Message-ID: <19970922200629.10690.qmail@ishiboo.com> Subject: Re: Netscape 4.03b8 doesn't work after poll/select changes In-Reply-To: <199709221607.JAA05440@rah.star-gate.com> from Amancio Hasty at "Sep 22, 97 09:07:15 am" To: hasty@rah.star-gate.com (Amancio Hasty) Date: Mon, 22 Sep 1997 15:06:29 -0500 (EST) Cc: roberto@eurocontrol.fr, freebsd-current@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL32 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Amancio Hasty stands accused of saying: > It seems to work over here . You may have to delete the preference's file > in .netscape. My system is current as of yesterday. > > Cheers, > Amancio > >From The Desk Of Ollivier Robert : > > I have a problem with Netscape since the poll/select changes... It doesn't > > work at all. No window is displayed and the process seems to be sleeping in > > > > 1193 23985 232 35 2 0 8096 2896 select I+ p4 0:00.39 /usr/local > /l > > 1193 23986 23985 12 2 0 7340 1908 select I+ p4 0:00.06 (dns helpe > r) > > > > ktrace shows that the process is doing nothing: > > > > 263 [16:03] root@caerdonn:/build/trn4# ll ktra* > > -rw------- 1 roberto staff 165074 Sep 22 16:02 ktrace.out > > > > 23985 netscape.bin RET read 3072/0xc00 > > 23985 netscape.bin CALL writev(0x8,0xefbfbc44,0x2) > > 23985 netscape.bin GIO fd 8 wrote 44 bytes > > ".\0\^B\0\a\0\M^@\b1\0 \0\M^?\M^?\^\\0-*-*-*-*-*-*-*-*-*-*-*-*-*-*" > > 23985 netscape.bin RET writev 44/0x2c > > 23985 netscape.bin CALL read(0x8,0xefbfbc88,0x20) > > 23985 netscape.bin RET read -1 errno 35 Resource temporarily unavailable > > 23985 netscape.bin CALL select(0x9,0xefbfbb70,0,0,0xefbfb6c0) > > 23985 netscape.bin RET select 0 > > 23985 netscape.bin CALL sigprocmask(0x1,0) > > 23985 netscape.bin RET sigprocmask 0 > > 23985 netscape.bin CALL gettimeofday(0xefbfb5b8,0) > > 23985 netscape.bin RET gettimeofday 0 > > 23985 netscape.bin CALL sigprocmask(0x3,0) > > 23985 netscape.bin RET sigprocmask 0 > > 23985 netscape.bin CALL sigprocmask(0x1,0x2000) > > 23985 netscape.bin RET sigprocmask 0 > > 23985 netscape.bin CALL select(0x9,0x50011f48,0,0,0x50011eec) > > > > and doesn't return... > > > > Am I the only one ? > > > > -CURRENT from 9/16 around 3 PM. > > -- > > Ollivier ROBERT -=- Eurocontrol EEC/TS -=- Ollivier.Robert@eurocontrol.fr > > > Works for me as well, but it didn't work for me until I upgraded to XFree33 (I had same results as the lack of window with an older XFree) --------------------------------------------------------------------------- Danny Dulai Feet. Pumice. Lotion. http://www.ishiboo.com/~nirva/ nirva@ishiboo.com --------------------------------------------------------------------------- From owner-freebsd-current Mon Sep 22 12:07:27 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id MAA09935 for current-outgoing; Mon, 22 Sep 1997 12:07:27 -0700 (PDT) Received: from ns.mt.sri.com (SRI-56K-FR.mt.net [206.127.65.42]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id MAA09928 for ; Mon, 22 Sep 1997 12:07:22 -0700 (PDT) Received: from rocky.mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.8.7/8.8.7) with ESMTP id NAA14452; Mon, 22 Sep 1997 13:05:29 -0600 (MDT) Received: (from nate@localhost) by rocky.mt.sri.com (8.7.5/8.7.3) id NAA02100; Mon, 22 Sep 1997 13:05:28 -0600 (MDT) Date: Mon, 22 Sep 1997 13:05:28 -0600 (MDT) Message-Id: <199709221905.NAA02100@rocky.mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: "Justin T. Gibbs" Cc: Terry Lambert , nate@mt.sri.com, current@freebsd.org Subject: Re: cvs commit: src/sys/conf files src/sys/dev/vx if_vx.c if_vxreg.h src/sys/i386/apm apm.c src/sys/i386/conf GENERIC files.i386 In-Reply-To: <199709221559.JAA17865@pluto.plutotech.com> References: <199709220647.XAA16869@usr07.primenet.com> <199709221559.JAA17865@pluto.plutotech.com> X-Mailer: VM 6.29 under 19.15 XEmacs Lucid Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > >A more deterministic implementation would associate an absolute tick > >value (rather than a count) with each entry, and insert entries in > >sorted order. > > More deterministic for who? This trades O(1) insertion for O(hash chain > length) insertion so that softclock will become O(timeouts for the current > tick). As timeout often is called from an interrupt context > it is not so clear where it is better to pay the price of non-determinism. > Softclock has the luxury of lowering it's spl at deterministic intervals > (see the implementation) while a caller from an interrupt context doesn't. > the current implementation always blocks interrupts for a deterministic > amount of time. What you propose doesn't. >From reading the papers, the performance would be neglidgable (sp?) since they assume the hash chain length is <= 1. That's one of the performance gains they assume. > Even so, it is probably better to store an absolute tick value regardless > so that you don't have to perform the subtraction. A substraction is *dirt cheap* to do. Finding the element on the list is much more expensive than the subtraction. Nate From owner-freebsd-current Mon Sep 22 12:07:49 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id MAA09962 for current-outgoing; Mon, 22 Sep 1997 12:07:49 -0700 (PDT) Received: from ns.mt.sri.com (SRI-56K-FR.mt.net [206.127.65.42]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id MAA09951 for ; Mon, 22 Sep 1997 12:07:38 -0700 (PDT) Received: from rocky.mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.8.7/8.8.7) with ESMTP id NAA14458; Mon, 22 Sep 1997 13:07:24 -0600 (MDT) Received: (from nate@localhost) by rocky.mt.sri.com (8.7.5/8.7.3) id NAA02110; Mon, 22 Sep 1997 13:07:22 -0600 (MDT) Date: Mon, 22 Sep 1997 13:07:22 -0600 (MDT) Message-Id: <199709221907.NAA02110@rocky.mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: "Justin T. Gibbs" Cc: Bruce Evans , current@freebsd.org, nate@mt.sri.com Subject: Re: cvs commit: src/sys/conf files src/sys/dev/vx if_vx.c if_vxreg.h src/sys/i386/apm apm.c src/sys/i386/conf GENERIC files.i386 src/sys/i386/eisa 3c5x9.c aha1742.c aic7770.c bt74x.c eisaconf.c eisaconf.h if_fea.c if_vx_eisa.c src/sys/i386/i386 autoconf.c ... In-Reply-To: <199709221501.JAA16510@pluto.plutotech.com> References: <199709221440.AAA18001@godzilla.zeta.org.au> <199709221501.JAA16510@pluto.plutotech.com> X-Mailer: VM 6.29 under 19.15 XEmacs Lucid Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > The current implementation only needs to allocate a callout at a time if > it wants to grow the number of callouts. It may, in fact be nice to add > an interface for clients to add additional callouts if they are heavy > users of them. For instance, the CAM system grows it's number of > transactions dynamically and will simply stop growing if it can't malloc > more. In your scenario, if you can't allocate space for a drive and it's > transactions, you can't talk to the drive. Umm, how does the CAM system still talk to a drive if it can't establish a callout for it? If it can do that now, then it can certainly do it with the old solution. Nate From owner-freebsd-current Mon Sep 22 12:08:24 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id MAA10078 for current-outgoing; Mon, 22 Sep 1997 12:08:24 -0700 (PDT) Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id MAA10054 for ; Mon, 22 Sep 1997 12:08:19 -0700 (PDT) Received: from harmony [10.0.0.6] by rover.village.org with esmtp (Exim 1.71 #1) id 0xDDq1-0000f3-00; Mon, 22 Sep 1997 13:08:05 -0600 Received: from harmony.village.org (localhost [127.0.0.1]) by harmony.village.org (8.8.7/8.8.3) with ESMTP id NAA08467; Mon, 22 Sep 1997 13:08:06 -0600 (MDT) Message-Id: <199709221908.NAA08467@harmony.village.org> To: Wolfram Schneider Subject: Re: rm -fr behavior changed? Cc: Keith Mitchell , current@freebsd.org In-reply-to: Your message of "22 Sep 1997 13:59:44 +0200." References: <199709220514.BAA07589@weenix.guru.org> Date: Mon, 22 Sep 1997 13:08:06 -0600 From: Warner Losh Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In message Wolfram Schneider writes: : Known problem. Bug id bin/4593 Peter Wemm committed a change to this as well last night. Warner From owner-freebsd-current Mon Sep 22 12:10:41 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id MAA10284 for current-outgoing; Mon, 22 Sep 1997 12:10:41 -0700 (PDT) Received: from ns.mt.sri.com (SRI-56K-FR.mt.net [206.127.65.42]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id MAA10274 for ; Mon, 22 Sep 1997 12:10:34 -0700 (PDT) Received: from rocky.mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.8.7/8.8.7) with ESMTP id NAA14490; Mon, 22 Sep 1997 13:10:32 -0600 (MDT) Received: (from nate@localhost) by rocky.mt.sri.com (8.7.5/8.7.3) id NAA02147; Mon, 22 Sep 1997 13:10:31 -0600 (MDT) Date: Mon, 22 Sep 1997 13:10:31 -0600 (MDT) Message-Id: <199709221910.NAA02147@rocky.mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Poul-Henning Kamp Cc: Nate Williams , current@freebsd.org Subject: New timeout capability (was Re: cvs commit:....) In-Reply-To: <612.874952557@critter.freebsd.dk> References: <199709221630.KAA01072@rocky.mt.sri.com> <612.874952557@critter.freebsd.dk> X-Mailer: VM 6.29 under 19.15 XEmacs Lucid Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Poul-Henning Kamp writes: > In message <199709221630.KAA01072@rocky.mt.sri.com>, Nate Williams writes: > > >Stating that it takes O(n) times to add/remove a callout and calling it > >a win when it takes O(n) time to process a tick isn't a win in my book. > > > >PHK answered by saying that on his laptop, it seemed to be a wash, so > >that's encouraging, but it seems to have the ability to make the system > >slower. (I'd like to see how PHK compared the two approaches.) > > elapsed time for make world, including careful scrutinizing the basic- > block profiling output. > > This is the kind of stuff my new "rover" setup is meant to be able to > measure. I have a standard deviation of less than 1 part in thousand > for real + user time, and less than 1 in 300 for system time, so > very small changes can be measured rather reliably. Can you explain a bit more about your 'rover' setup, and how it's used? Thanks! Nate From owner-freebsd-current Mon Sep 22 12:11:03 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id MAA10318 for current-outgoing; Mon, 22 Sep 1997 12:11:03 -0700 (PDT) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id MAA10313 for ; Mon, 22 Sep 1997 12:10:57 -0700 (PDT) Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.5/8.6.9) id FAA26566; Tue, 23 Sep 1997 05:06:36 +1000 Date: Tue, 23 Sep 1997 05:06:36 +1000 From: Bruce Evans Message-Id: <199709221906.FAA26566@godzilla.zeta.org.au> To: gibbs@plutotech.com, julian@whistle.com Subject: Re: cvs commit: src/sys/conf files src/sys/dev/vx if_vx.c if_vxreg.h src/sys/i386/apm apm.c src/sys/i386/conf GENERIC files.i386 src/sys/i386/eisa 3c5x9.c aha1742.c aic7770.c bt74x.c eisaconf.c eisaconf.h if_fea.c if_vx_eisa.c src/sys/i386/i386 a Cc: bde@zeta.org.au, current@freebsd.org, nate@mt.sri.com Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >Various BSDs. I chose not to implement a backwards compatibility interface >as I'd have to allocate even more space to make it as efficient as the new >one and updating client code is easy to do. It's a small price to pay for Wouldn't using the old interface for everything and hashing on (ftn, arg) in untimeout() be efficient enough? I think it takes less space than now - clients wouldn't need space for cookies. Bruce From owner-freebsd-current Mon Sep 22 12:15:18 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id MAA10636 for current-outgoing; Mon, 22 Sep 1997 12:15:18 -0700 (PDT) Received: from ns.mt.sri.com (SRI-56K-FR.mt.net [206.127.65.42]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id MAA10628 for ; Mon, 22 Sep 1997 12:15:13 -0700 (PDT) Received: from rocky.mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.8.7/8.8.7) with ESMTP id NAA14523; Mon, 22 Sep 1997 13:15:05 -0600 (MDT) Received: (from nate@localhost) by rocky.mt.sri.com (8.7.5/8.7.3) id NAA02205; Mon, 22 Sep 1997 13:15:05 -0600 (MDT) Date: Mon, 22 Sep 1997 13:15:05 -0600 (MDT) Message-Id: <199709221915.NAA02205@rocky.mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Bruce Evans Cc: gibbs@plutotech.com, current@freebsd.org Subject: Re: cvs commit: src/sys/conf files src/sys/dev/vx if_vx.c if_vxreg.h src/sys/i386/apm apm.c src/sys/i386/conf GENERIC files.i386 src/sys/i386/eisa 3c5x9.c aha1742.c aic7770.c bt74x.c eisaconf.c eisaconf.h if_fea.c if_vx_eisa.c src/sys/i386/i386 a In-Reply-To: <199709221906.FAA26566@godzilla.zeta.org.au> References: <199709221906.FAA26566@godzilla.zeta.org.au> X-Mailer: VM 6.29 under 19.15 XEmacs Lucid Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Bruce Evans writes: > >Various BSDs. I chose not to implement a backwards compatibility interface > >as I'd have to allocate even more space to make it as efficient as the new > >one and updating client code is easy to do. It's a small price to pay for > > Wouldn't using the old interface for everything and hashing on (ftn, > arg) in untimeout() be efficient enough? I think it takes less space > than now - clients wouldn't need space for cookies. Setting the initial callouts would still be O(n), though how badly that effects things is still unknown. Nate ps. What I really would like to see if multiple timers/process. :) :) From owner-freebsd-current Mon Sep 22 12:21:12 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id MAA10989 for current-outgoing; Mon, 22 Sep 1997 12:21:12 -0700 (PDT) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id MAA10984 for ; Mon, 22 Sep 1997 12:21:06 -0700 (PDT) Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.5/8.6.9) id FAA26906; Tue, 23 Sep 1997 05:17:20 +1000 Date: Tue, 23 Sep 1997 05:17:20 +1000 From: Bruce Evans Message-Id: <199709221917.FAA26906@godzilla.zeta.org.au> To: nate@mt.sri.com, phk@critter.freebsd.dk Subject: Re: cvs commit: src/sys/conf files src/sys/dev/vx if_vx.c if_vxreg.h src/sys/i386/apm apm.c src/sys/i386/conf GENERIC files.i386 src/sys/i386/eisa 3c5x9.c aha1742.c aic7770.c bt74x.c eisaconf.c eisaconf.h if_fea.c if_vx_eisa.c src/sys/i386/i386 autoconf.c ... Cc: bde@zeta.org.au, current@FreeBSD.ORG, gibbs@plutotech.com Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >Anyway, it shouldn't be to hard to make either of the old and the new >implementations available under a compile option, the new calling >API is a a superset of the old, isn't it ? No, timeout() now passes back a cookie which is required for faster lookup in untimeout(), and managing the cookies is painful. Ifdefs would be required in about 41 files to optionally restore the old calling convention. However, it would be easy to test the new API with the old implementation by ignoring the cookies only in kern_clock.c. Bruce From owner-freebsd-current Mon Sep 22 12:27:08 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id MAA11415 for current-outgoing; Mon, 22 Sep 1997 12:27:08 -0700 (PDT) Received: from usr06.primenet.com (tlambert@usr06.primenet.com [206.165.6.206]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id MAA11402 for ; Mon, 22 Sep 1997 12:26:59 -0700 (PDT) Received: (from tlambert@localhost) by usr06.primenet.com (8.8.5/8.8.5) id MAA16814; Mon, 22 Sep 1997 12:26:40 -0700 (MST) From: Terry Lambert Message-Id: <199709221926.MAA16814@usr06.primenet.com> Subject: Re: cvs commit: src/sys/conf files src/sys/dev/vx if_vx.c if_vxreg.h src/sys/i386/apm apm.c src/sys/i386/conf GENERIC files.i386 To: gibbs@plutotech.com (Justin T. Gibbs) Date: Mon, 22 Sep 1997 19:26:39 +0000 (GMT) Cc: tlambert@primenet.com, gibbs@plutotech.com, nate@mt.sri.com, current@FreeBSD.ORG In-Reply-To: <199709221559.JAA17865@pluto.plutotech.com> from "Justin T. Gibbs" at Sep 22, 97 09:58:54 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > >A more deterministic implementation would associate an absolute tick > >value (rather than a count) with each entry, and insert entries in > >sorted order. > > More deterministic for who? This trades O(1) insertion for O(hash chain > length) insertion so that softclock will become O(timeouts for the current > tick). As timeout often is called from an interrupt context > it is not so clear where it is better to pay the price of non-determinism. I'm not so sure timeouts should be called from an interrupt context, ever. If they should, then they should really only be called for the fastintr code. Other interrupts should create a context record that identifies the processing information and queue it as if it were a "request for service" instead of treating it as a "demand for service". This architecture, since it requires the service function to restart acceptance of interrupts on the serviced device, also nicely provides a mechanism for forwarding interrupts to user space (per the strange request of the other day). > Softclock has the luxury of lowering it's spl at deterministic intervals > (see the implementation) while a caller from an interrupt context doesn't. > the current implementation always blocks interrupts for a deterministic > amount of time. What you propose doesn't. O(hash chain length) insertion and O(1) event identification beats O(1) insertion and O(total number of timeouts) event identification, which is what you get from an unordered list. You are assuming here that the softclock resoloution is higher frequency by at least one harmonic range than the interval for any event you wish to schedule. I submit that this is an invalid assumption. On a 586 or better (the only things with a high enough CPU clock frequency to make this worrisome), you can read the inctruction cycle counter, and use it to subtract out firing time. For non-586 hardware, you can multiply by 10 the frequency, and get a statisticaly close approximation using a drift-count (the current code uses a drift count for the time reported as the system clock anyway). > Even so, it is probably better to store an absolute tick value regardless > so that you don't have to perform the subtraction. Yes, at a minimum. Also, if the list is sorted, you do not have to traverse it in it's entirety. > If and when we decide that we need higher resolution timer facilities, we can > decide if a non-deterministic timeout() is an acceptable cost for that > feature. I think they are needed to replace all occurances of delay loops in the kernel. At the very least, this would mean that I could concurrently probe other hardware while probing IDE or "waiting for scsi devices to settle". 8-(. They are also a necessary component for an involuntary context switch of a non-RT process in favor of an RT process for hard RT services. Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-current Mon Sep 22 12:32:36 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id MAA11969 for current-outgoing; Mon, 22 Sep 1997 12:32:36 -0700 (PDT) Received: from ns.mt.sri.com (SRI-56K-FR.mt.net [206.127.65.42]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id MAA11961 for ; Mon, 22 Sep 1997 12:32:31 -0700 (PDT) Received: from rocky.mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.8.7/8.8.7) with ESMTP id NAA14648; Mon, 22 Sep 1997 13:32:20 -0600 (MDT) Received: (from nate@localhost) by rocky.mt.sri.com (8.7.5/8.7.3) id NAA02277; Mon, 22 Sep 1997 13:32:20 -0600 (MDT) Date: Mon, 22 Sep 1997 13:32:20 -0600 (MDT) Message-Id: <199709221932.NAA02277@rocky.mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Terry Lambert Cc: gibbs@plutotech.com (Justin T. Gibbs), nate@mt.sri.com, current@freebsd.org Subject: Re: cvs commit: src/sys/conf files src/sys/dev/vx if_vx.c if_vxreg.h src/sys/i386/apm apm.c src/sys/i386/conf GENERIC files.i386 In-Reply-To: <199709221926.MAA16814@usr06.primenet.com> References: <199709221559.JAA17865@pluto.plutotech.com> <199709221926.MAA16814@usr06.primenet.com> X-Mailer: VM 6.29 under 19.15 XEmacs Lucid Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > >A more deterministic implementation would associate an absolute tick > > >value (rather than a count) with each entry, and insert entries in > > >sorted order. > > > > More deterministic for who? This trades O(1) insertion for O(hash chain > > length) insertion so that softclock will become O(timeouts for the current > > tick). As timeout often is called from an interrupt context > > it is not so clear where it is better to pay the price of non-determinism. > > I'm not so sure timeouts should be called from an interrupt context, > ever. [ rest deleted ] We're talking reality here Terry, not theory. 'If the world were a perfect place, we wouldn't need interrupts since we could get everything done when we needed to and it wouldn't mess with anything else, but this isn't a perfect world.' The extra complexity required to do your above solution is *WAY* overkill. (I've done things such as it on a small-scale basis, and performance starts to drop off quickly due to data synchronization when you have lots of 'objects/drivers'.) Nate From owner-freebsd-current Mon Sep 22 12:38:36 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id MAA12510 for current-outgoing; Mon, 22 Sep 1997 12:38:36 -0700 (PDT) Received: from ns.mt.sri.com (SRI-56K-FR.mt.net [206.127.65.42]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id MAA12502 for ; Mon, 22 Sep 1997 12:38:30 -0700 (PDT) Received: from rocky.mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.8.7/8.8.7) with ESMTP id NAA14694; Mon, 22 Sep 1997 13:38:24 -0600 (MDT) Received: (from nate@localhost) by rocky.mt.sri.com (8.7.5/8.7.3) id NAA02352; Mon, 22 Sep 1997 13:38:24 -0600 (MDT) Date: Mon, 22 Sep 1997 13:38:24 -0600 (MDT) Message-Id: <199709221938.NAA02352@rocky.mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Nate Williams Cc: "Justin T. Gibbs" , Terry Lambert , current@freebsd.org Subject: Re: cvs commit: src/sys/conf files src/sys/dev/vx if_vx.c if_vxreg.h src/sys/i386/apm apm.c src/sys/i386/conf GENERIC files.i386 In-Reply-To: <199709221905.NAA02100@rocky.mt.sri.com> References: <199709220647.XAA16869@usr07.primenet.com> <199709221559.JAA17865@pluto.plutotech.com> <199709221905.NAA02100@rocky.mt.sri.com> X-Mailer: VM 6.29 under 19.15 XEmacs Lucid Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > Even so, it is probably better to store an absolute tick value regardless > > so that you don't have to perform the subtraction. > > A substraction is *dirt cheap* to do. Finding the element on the list > is much more expensive than the subtraction. Ignore this, I was confused. Of course this is a much better way of doing things than having to subtract every callout during softclock. Nate From owner-freebsd-current Mon Sep 22 12:40:54 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id MAA12715 for current-outgoing; Mon, 22 Sep 1997 12:40:54 -0700 (PDT) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id MAA12710 for ; Mon, 22 Sep 1997 12:40:50 -0700 (PDT) Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.5/8.6.9) id FAA27469; Tue, 23 Sep 1997 05:38:53 +1000 Date: Tue, 23 Sep 1997 05:38:53 +1000 From: Bruce Evans Message-Id: <199709221938.FAA27469@godzilla.zeta.org.au> To: bde@zeta.org.au, nate@mt.sri.com Subject: Re: cvs commit: src/sys/conf files src/sys/dev/vx if_vx.c if_vxreg.h src/sys/i386/apm apm.c src/sys/i386/conf GENERIC files.i386 src/sys/i386/eisa 3c5x9.c aha1742.c aic7770.c bt74x.c eisaconf.c eisaconf.h if_fea.c if_vx_eisa.c src/sys/i386/i386 autoconf.c ... Cc: current@freebsd.org, gibbs@plutotech.com Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >> Not great. My method uses a split queue to usually avoid having to >> look at the half expired timeouts. The old method used a delta list >> for similar reasons. I'm surprised that there is no trace of delta >> lists in the new method. > >I am as well. It *seems* to me that this is probably the biggest >bottleneck in the softclock() handling, and wouldn't add that much >overhead to the timeout registration code (since once you've got the >correct hash entry, you could simply copy the head's value, or calculate >the new value, neither of which would take that long.) A delta list is a time-ordered list cleverly scaled to be relative to the current time. Hashing doesn't mix well with sorting. I don't know how to insert in an ordered list faster than O(log n). Deletion could be done in O(1) without using cookies by building hash table on insertion. >> >wheel is set), so I still don't see a big win. I'm not saying that it's >> >any worse/better than the existing scheme, in fact I don't see a win. >> >> However, it's only O(n). The old method was O(n^2) for each insertion >> and deletion, which makes it O(n^2) altogether. > >Huh? How was O(n^2)? I see it as O(n) for insertion, and O(n) for >deletion, which is still O(n). (I'm looking at the 4.3/4.4 books, and >don't have the code handy.) I'm assuming that the size of the table (n) is proportional to the number of insertions per second. >> The point is that the tick interval is fixed. > >But, the time it takes to do softclock is not, and you can sometimes >take too long in the softclock interrupt handler. The time taken to traverse the wheel queue is insignificant compared with the tick interval. >> >PHK answered by saying that on his laptop, it seemed to be a wash, so >> >that's encouraging, but it seems to have the ability to make the system >> >slower. (I'd like to see how PHK compared the two approaches.) >> >> timeout() probably doesn't get called enough to matter. > >Umm, I would think there's a one-one match for timeout/untimeout, >wouldn't there? No (many timeouts expire naturally), but that doesn't affect the time spent calling timeout() or untimeout() by more than a factor of 2. (not enough to matter) * 2 = (not enough to matter). >> I expect it will make things slightly worse for the average user, but >> the difference will be too small to measure. > >So do you think the new solution is a 'win' overall? Average small loss, but large win on some systems. >> >2) registering timeouts >> >3) de-registering timeouts > >How often are the above called (in comparison to clock ticks)? It depends. :-) Bruce From owner-freebsd-current Mon Sep 22 12:43:32 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id MAA13002 for current-outgoing; Mon, 22 Sep 1997 12:43:32 -0700 (PDT) Received: from critter.freebsd.dk (critter.freebsd.dk [195.8.129.26]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id MAA12995 for ; Mon, 22 Sep 1997 12:43:26 -0700 (PDT) Received: from critter.freebsd.dk (localhost.cybercity.dk [127.0.0.1]) by critter.freebsd.dk (8.8.7/8.8.7) with ESMTP id VAA00901; Mon, 22 Sep 1997 21:42:04 +0200 (CEST) To: Nate Williams cc: current@freebsd.org Subject: Re: New timeout capability (was Re: cvs commit:....) In-reply-to: Your message of "Mon, 22 Sep 1997 13:10:31 MDT." <199709221910.NAA02147@rocky.mt.sri.com> Date: Mon, 22 Sep 1997 21:42:04 +0200 Message-ID: <899.874957324@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In message <199709221910.NAA02147@rocky.mt.sri.com>, Nate Williams writes: >Can you explain a bit more about your 'rover' setup, and how it's used? The "rover" in my lab is named after it's more adventurous namesake on Mars. Basically it's a machine (K6/233, 64M, Ahc, Quantum Atlas), which will repeatedly run through this (vastly simplified) loop: boot diskless dd if=/dev/rsd1a of=/dev/rsd0a bs=64k mount /dev/sd0a /mnt #setup /etc/rc to run experiment umount /mnt reboot from disk #run experiment in /etc/rc ifconfig gather_results | rsh server "mail phk@freebsd.org" reboot to diskless The trick is that the initial condition is as similar as I can possibly make it. That way I have gotten very low spread on my measurements and consequently often found that just one shot would be statistically significant, although I don't anticipate running less than three shots on any one experiment. The results gathered after the run includes the output of "time -l", "dmesg" output (to watch for errors) and a "sysctl -a" output. But any command can be run of course. My current reference measurement is a make world with the standard kernel.GENERIC as shipped in the snapshot distribution: 10 samples avg stddev stddev/avg min -stddev avg +stddev max --------------------------------------------------------------------------- 9011.84 6.11 0.000678 9003.66 9005.73 9011.84 9017.95 9023.14 4549.31 4.16 0.000915 4540.18 4545.15 4549.31 4553.48 4554.99 1305.56 3.90 0.002985 1300.22 1301.66 1305.56 1309.46 1311.60 5854.87 5.83 0.000996 5847.87 5849.04 5854.87 5860.71 5862.61 3156.97 4.79 0.001518 3149.34 3152.18 3156.97 3161.76 3165.07 --------------------------------------------------------------------------- The five rows of data are: real, user, sys, (user+sys), (real-user-sys) My current row of experiments are targeted at quantifying various features and variables impact on a make world. My general studylist looks like this at this time: Kernel = {kernel.GENERIC, kernel.tuned} MB Ram = {16 ... 64} __getcwd() = {enable, disable} debug.ncnegfactor = {2 ... 20} -pipe = {enable, disable} kern.maxvnodes = {2000 ... 8000} "vnode freelist relative size" mount /usr/obj -o async = {yes, no} APM = {On, Off} Statclock freq = {128, 256, 512, 1024} AHC_TAGENABLE = {yes, no} AHC_SCBPAGING = {yes, no} BIOS parameters. = {...} I also have a bunch of micro-benchmarks on the vnode/namecache to run, but those are not of very general interest I pressume. I hope to have a turnaround time of two experiments per day or so. If you have a change you want tested, I should be able to give the result back to you in one or two days. (I only ask in return that I may publish the results in case I write a paper on this experiment later on). If you're wondering how it works in practice: I have an EPROM emulator in a old wd8003 board hooked up to the parallel port of another computer. Since the network interface isn't even configured during the duration of the experiment, this old card does not negatively impact performance. -- Poul-Henning Kamp FreeBSD coreteam member phk@FreeBSD.ORG "Real hackers run -current on their laptop." From owner-freebsd-current Mon Sep 22 12:44:33 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id MAA13171 for current-outgoing; Mon, 22 Sep 1997 12:44:33 -0700 (PDT) Received: from pluto.plutotech.com (root@mail.plutotech.com [206.168.67.137]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id MAA13155 for ; Mon, 22 Sep 1997 12:44:26 -0700 (PDT) Received: from narnia.plutotech.com (narnia.plutotech.com [206.168.67.130]) by pluto.plutotech.com (8.8.5/8.8.5) with ESMTP id NAA29456; Mon, 22 Sep 1997 13:44:15 -0600 (MDT) Message-Id: <199709221944.NAA29456@pluto.plutotech.com> X-Mailer: exmh version 2.0zeta 7/24/97 To: Nate Williams cc: "Justin T. Gibbs" , Bruce Evans , current@freebsd.org Subject: Re: cvs commit: src/sys/conf files src/sys/dev/vx if_vx.c if_vxreg.h src/sys/i386/apm apm.c src/sys/i386/conf GENERIC files.i386 src/sys/i386/eisa 3c5x9.c aha1742.c aic7770.c bt74x.c eisaconf.c eisaconf.h if_fea.c if_vx_eisa.c src/sys/i386/i386 autoconf.c ... In-reply-to: Your message of "Mon, 22 Sep 1997 12:12:59 MDT." <199709221812.MAA01622@rocky.mt.sri.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 22 Sep 1997 13:44:05 -0600 From: "Justin T. Gibbs" Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >> Now depending on how you size your callwheel, h << n. With a MAXUSERS >> of 32, the callwheel is 256 entries big if I recall correctly. > >What is it for a 'typical' workstation, which is the one shipped in >GENERIC using 'maxusers 10'? My memory was failing me, from conf/param.c: #define NPROC (20 + 16 * MAXUSERS) int ncallout = 16 + NPROC; So for GENERIC, ncallout is 196 which is the same as the callwheel size. >> But running time isn't the only thing to consider. As I mentioned >> before, untimeout/timeout are often called from an interrupt context >> and the old algorithm caused an indeterminate delay in this scenario, >> potentially causing problems for that device and any that share the >> same interrupt. > >'softclock()' is also called with some interrupt() masked as well, isn't >it? It runs at splhigh() while traversing callout entries and splsoftclock() when calling timeouts. The new implemenatation will traverse at most 100 entries before lowering it's IPL from splhigh() so that other interrupt handlers can run. >> You also have to consider that timeout/untimeout calls occur at >> indeterminate rates, but softclock runs at a fixed rate meaning that >> the amount of work it performs scales better than if that work was >> pushed off into either of timeout or untimeout. > >True, but if it's 'worst-case' time happens often enough, we're >penalizing the system *alot* more than during timeout/untimeout, which >happens much less rarely. Although this may be true today, the point about it scaling still holds true. If you increase the frequency of untimeout/timeout calls, the new system scales very well in that the you will still encounter your 'worst-case' time at the same rate as you did originally. >The 'gotcha' is that I don't know if this is a 'normal' case, since the >paper didn't test normal cases, but instead did lots of >timeout/untimeouts in a user-land process, which stacks the test data in >favor of the new implementation. If you don't have lots of callouts outstanding, softclock has little to do. In the normal case, you don't have lots of callouts outstanding, so (say 30 out of 196), so the amount of difference in speed is at most (x * list entry traversal time) - list entry traversal time. Most of the time the list to traverse will be empty though. >> >I would like to see some #'s that show us the # & amount of time it >> >takes in section on a 'normal' system, using both approaches. If >> >someone has some good ideas how to do that, I'm willing to learn >> >something and go do it. >> >> Allocate an array of ints of size ncallout. In softclock, increment the >> array entry corresponding to the number of entries traversed in a softclock >> run. By periodically scanning this array, you'll get a good idea of the >> value of 'h' for you system. Add three more ints that count the number of >> invocations of softclock, untimeout, and timeout and you should be able to >> draw conclusions from that. > >But, that doesn't give me any latency #'s for any of the operations. >Knowing how often they are called is one thing, and knowing how many >entries are traversed is good, but *times* are the bigger issue. You can infer times from the other information. As the work performed in softclock is at most O(n), you only have to call either of timeout, or untimeout twice in each 10ms period to know that you've won. >Nate -- Justin T. Gibbs =========================================== FreeBSD: Turning PCs into workstations =========================================== From owner-freebsd-current Mon Sep 22 13:00:31 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id NAA14526 for current-outgoing; Mon, 22 Sep 1997 13:00:31 -0700 (PDT) Received: from ns.mt.sri.com (SRI-56K-FR.mt.net [206.127.65.42]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id NAA14511 for ; Mon, 22 Sep 1997 13:00:13 -0700 (PDT) Received: from rocky.mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.8.7/8.8.7) with ESMTP id OAA14854; Mon, 22 Sep 1997 14:00:11 -0600 (MDT) Received: (from nate@localhost) by rocky.mt.sri.com (8.7.5/8.7.3) id OAA02491; Mon, 22 Sep 1997 14:00:10 -0600 (MDT) Date: Mon, 22 Sep 1997 14:00:10 -0600 (MDT) Message-Id: <199709222000.OAA02491@rocky.mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Bruce Evans Cc: nate@mt.sri.com, current@freebsd.org, gibbs@plutotech.com Subject: Re: cvs commit: src/sys/conf files src/sys/dev/vx if_vx.c if_vxreg.h src/sys/i386/apm apm.c src/sys/i386/conf GENERIC files.i386 src/sys/i386/eisa 3c5x9.c aha1742.c aic7770.c bt74x.c eisaconf.c eisaconf.h if_fea.c if_vx_eisa.c src/sys/i386/i386 autoconf.c ... In-Reply-To: <199709221938.FAA27469@godzilla.zeta.org.au> References: <199709221938.FAA27469@godzilla.zeta.org.au> X-Mailer: VM 6.29 under 19.15 XEmacs Lucid Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > >> Not great. My method uses a split queue to usually avoid having to > >> look at the half expired timeouts. The old method used a delta list > >> for similar reasons. I'm surprised that there is no trace of delta > >> lists in the new method. > > > >I am as well. It *seems* to me that this is probably the biggest > >bottleneck in the softclock() handling, and wouldn't add that much > >overhead to the timeout registration code (since once you've got the > >correct hash entry, you could simply copy the head's value, or calculate > >the new value, neither of which would take that long.) > > A delta list is a time-ordered list cleverly scaled to be relative to > the current time. Hashing doesn't mix well with sorting. I don't know > how to insert in an ordered list faster than O(log n). Deletion could > be done in O(1) without using cookies by building hash table on insertion. Again, I was confused. I re-read the paper, and the 'buckets' aren't all for the same timeout value, but are for timeouts that are similar. (Unlike your 'specific' solution, which used timeouts that were all alike as I understand it.) > >> >wheel is set), so I still don't see a big win. I'm not saying that it's > >> >any worse/better than the existing scheme, in fact I don't see a win. > >> > >> However, it's only O(n). The old method was O(n^2) for each insertion > >> and deletion, which makes it O(n^2) altogether. > > > >Huh? How was O(n^2)? I see it as O(n) for insertion, and O(n) for > >deletion, which is still O(n). (I'm looking at the 4.3/4.4 books, and > >don't have the code handy.) > > I'm assuming that the size of the table (n) is proportional to the number > of insertions per second. But, the act of insertion/deletion is still O(n). > >> The point is that the tick interval is fixed. > > > >But, the time it takes to do softclock is not, and you can sometimes > >take too long in the softclock interrupt handler. > > The time taken to traverse the wheel queue is insignificant compared with > the tick interval. Even at splhigh(), when you have to look at *every* entry and decrement it's counter? > >> >PHK answered by saying that on his laptop, it seemed to be a wash, so > >> >that's encouraging, but it seems to have the ability to make the system > >> >slower. (I'd like to see how PHK compared the two approaches.) > >> > >> timeout() probably doesn't get called enough to matter. > > > >Umm, I would think there's a one-one match for timeout/untimeout, > >wouldn't there? > > No (many timeouts expire naturally), but that doesn't affect the time > spent calling timeout() or untimeout() by more than a factor of 2. > (not enough to matter) * 2 = (not enough to matter). I still don't understand. You are saying that we call untimeout() more often than timeout is called. How can that be? That makes no sense, since it appears to me that timeout() would be called more often than untimeout(), especially when you consider that the only time you call untimeout() is when the 'expected' data is aquired before the timer expires. Ie: #define MAX_RETRIES 10 static int retries = 0; try_work() { tell_something_to_get_data(got_data()); timeout(timed_out_getting_data()); return; } got_data() { untimeout(timed_out_getting_data()); do_work(); retries = 0; } timed_out_getting_data() { if (retries++ > MAX_RETRIES) panic("Augh, couldn't get data"); try_work(); } It seems to me that timeout is called slightly more often than untimeout, although the difference is minimal since one would hope that timeouts don't occur at all (or very often anyway) in the above code. Nate From owner-freebsd-current Mon Sep 22 13:05:23 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id NAA14902 for current-outgoing; Mon, 22 Sep 1997 13:05:23 -0700 (PDT) Received: from usr06.primenet.com (tlambert@usr06.primenet.com [206.165.6.206]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id NAA14890 for ; Mon, 22 Sep 1997 13:05:18 -0700 (PDT) Received: (from tlambert@localhost) by usr06.primenet.com (8.8.5/8.8.5) id NAA19844; Mon, 22 Sep 1997 13:05:04 -0700 (MST) From: Terry Lambert Message-Id: <199709222005.NAA19844@usr06.primenet.com> Subject: Re: cvs commit: src/sys/conf files src/sys/dev/vx if_vx.c if_vxreg.h src/sys/i386/apm apm.c src/sys/i386/conf GENERIC files.i386 To: nate@mt.sri.com (Nate Williams) Date: Mon, 22 Sep 1997 20:05:04 +0000 (GMT) Cc: julian@whistle.com, gibbs@plutotech.com, bde@zeta.org.au, nate@mt.sri.com, current@FreeBSD.ORG In-Reply-To: <199709221745.LAA01369@rocky.mt.sri.com> from "Nate Williams" at Sep 22, 97 11:45:24 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > In theory, I disagree. We can't 'move forward' w/out breaking device > compatability with other systems, and if the changes allow to > effeciently do things in the manner described in the paper, it's a step > in the right direction. For example, making the VM system 'useful' > required changing a standard kernel interface (although it was neither > well documented nor well understood.) For another, making the VFS useful required changes as well. Wait... those changes were never committed. 8-) 8-). > But, I want to know that it is indeed an improvement, and not merely a > change that is needed to support Justin's CAM work, and something that > could have been done in a manner that took the good ideas from the work > but implemented them in a manner that was less intrusive. This is still a good point. I want to see the timer code move toward RT support, meaning timer based involuntary preemption of non-RT processes for timers belonging to RT processes, and for removal of all buzz-loops in the kernel, and movement of the FT driver guarantees to the kernel istead of an FT device. To my mind, the new code moves at an oblique angle, and takes the kernel further away from these goals. While I admit that probably not everyone shares these goals, it is still possible to argue against making them architecturally harder to achieve, even if they aren't your goals. Any design which limits future work is broken (the statement of this principle shows the relevance of the VFS reference above). > > all my drivers that are shared between various OS now need to > > be modified, with a new #if defined(__FreeBSD__) in them. > > Actually, if Justin's work was the same as the original code, you should > still be able to use the old 'timeout' functionality, it just doens't > take advantage of some of the newer features. I think this was targetted at the bitmaps; I could be wrong. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-current Mon Sep 22 13:13:33 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id NAA15590 for current-outgoing; Mon, 22 Sep 1997 13:13:33 -0700 (PDT) Received: from usr06.primenet.com (tlambert@usr06.primenet.com [206.165.6.206]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id NAA15582 for ; Mon, 22 Sep 1997 13:13:14 -0700 (PDT) Received: (from tlambert@localhost) by usr06.primenet.com (8.8.5/8.8.5) id NAA20498; Mon, 22 Sep 1997 13:12:58 -0700 (MST) From: Terry Lambert Message-Id: <199709222012.NAA20498@usr06.primenet.com> Subject: Re: cvs commit: src/sys/conf files src/sys/dev/vx if_vx.c if_vxreg.h src/sys/i386/apm apm.c src/sys/i386/conf GENERIC files.i386 To: gibbs@plutotech.com (Justin T. Gibbs) Date: Mon, 22 Sep 1997 20:12:58 +0000 (GMT) Cc: nate@mt.sri.com, gibbs@plutotech.com, bde@zeta.org.au, current@FreeBSD.ORG In-Reply-To: <199709221755.LAA25129@pluto.plutotech.com> from "Justin T. Gibbs" at Sep 22, 97 11:55:12 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > But running time isn't the only thing to consider. As I mentioned > before, untimeout/timeout are often called from an interrupt context > and the old algorithm caused an indeterminate delay in this scenario, > potentially causing problems for that device and any that share the > same interrupt. I still don't agree that this is a good rationale; IMO, the interrupts should be virtualized. I personally would not permit memory allocations to occur at interrupt. The only place this issue is even marginally relevelent is the fastintr code. > You also have to consider that timeout/untimeout calls occur at > indeterminate rates, but softclock runs at a fixed rate meaning that > the amount of work it performs scales better than if that work was > pushed off into either of timeout or untimeout. The softclock code assumes a higher frequency than the relative interval between timer firings. This is bad, expecially if I want a timer of better than 122uS resoloution. I can concieve of valid uses for timers in the 1uS - 500nS range (valid == not just the pc speaker driver). You addreesed the "if an when we want high resoloution timers" issue in another posting, so I won't press a case for it here. Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-current Mon Sep 22 13:20:21 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id NAA16197 for current-outgoing; Mon, 22 Sep 1997 13:20:21 -0700 (PDT) Received: from mexico.brainstorm.eu.org (root@mexico.brainstorm.fr [193.56.58.253]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id NAA16186 for ; Mon, 22 Sep 1997 13:20:15 -0700 (PDT) Received: from brasil.brainstorm.eu.org (brasil.brainstorm.fr [193.56.58.33]) by mexico.brainstorm.eu.org (8.8.4/8.8.4) with ESMTP id WAA28047 for ; Mon, 22 Sep 1997 22:20:13 +0200 Received: (from uucp@localhost) by brasil.brainstorm.eu.org (8.8.6/brasil-1.2) with UUCP id WAA30576 for freebsd-current@freefall.FreeBSD.org; Mon, 22 Sep 1997 22:19:59 +0200 Received: (from roberto@localhost) by keltia.freenix.fr (8.8.7/keltia-2.10/nospam) id VAA09122; Mon, 22 Sep 1997 21:29:08 +0200 (CEST) Message-ID: <19970922212907.40124@keltia.freenix.fr> Date: Mon, 22 Sep 1997 21:29:07 +0200 From: Ollivier Robert To: FreeBSD current Subject: Re: ctm blowup References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84 In-Reply-To: ; from Chuck Robey on Mon, Sep 22, 1997 at 10:42:55AM -0400 X-Operating-System: FreeBSD 3.0-CURRENT Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk According to Chuck Robey: > Anyone know what that was, or how I could get ctm back on track? Surprising, I'm also at 3670 and didn't see this message... I have cvs-cur as usual and the crypto stuff from ftp.internat.freebsd.org. -- Ollivier ROBERT -=- FreeBSD: There are no limits -=- roberto@keltia.freenix.fr FreeBSD keltia.freenix.fr 3.0-CURRENT #35: Sun Sep 21 19:28:07 CEST 1997 From owner-freebsd-current Mon Sep 22 13:26:07 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id NAA16675 for current-outgoing; Mon, 22 Sep 1997 13:26:07 -0700 (PDT) Received: from ns.mt.sri.com (SRI-56K-FR.mt.net [206.127.65.42]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id NAA16669 for ; Mon, 22 Sep 1997 13:26:00 -0700 (PDT) Received: from rocky.mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.8.7/8.8.7) with ESMTP id OAA14994; Mon, 22 Sep 1997 14:25:47 -0600 (MDT) Received: (from nate@localhost) by rocky.mt.sri.com (8.7.5/8.7.3) id OAA02565; Mon, 22 Sep 1997 14:25:45 -0600 (MDT) Date: Mon, 22 Sep 1997 14:25:45 -0600 (MDT) Message-Id: <199709222025.OAA02565@rocky.mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: "Justin T. Gibbs" Cc: Nate Williams , Bruce Evans , current@freebsd.org Subject: Re: cvs commit: src/sys/conf files src/sys/dev/vx if_vx.c if_vxreg.h src/sys/i386/apm apm.c src/sys/i386/conf GENERIC files.i386 src/sys/i386/eisa 3c5x9.c aha1742.c aic7770.c bt74x.c eisaconf.c eisaconf.h if_fea.c if_vx_eisa.c src/sys/i386/i386 autoconf.c ... In-Reply-To: <199709221944.NAA29456@pluto.plutotech.com> References: <199709221812.MAA01622@rocky.mt.sri.com> <199709221944.NAA29456@pluto.plutotech.com> X-Mailer: VM 6.29 under 19.15 XEmacs Lucid Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > >> But running time isn't the only thing to consider. As I mentioned > >> before, untimeout/timeout are often called from an interrupt context > >> and the old algorithm caused an indeterminate delay in this scenario, > >> potentially causing problems for that device and any that share the > >> same interrupt. > > > >'softclock()' is also called with some interrupt() masked as well, isn't > >it? > > It runs at splhigh() while traversing callout entries and splsoftclock() > when calling timeouts. The new implemenatation will traverse at most > 100 entries before lowering it's IPL from splhigh() so that other interrupt > handlers can run. I need to look at the code. Hmm, seems kind of silly to me: ++steps; if (steps >= MAX_SOFTCLOCK_STEPS) { nextsoftcheck = c; splx(s); /* Give hardclock() a chance. */ s = splhigh(); c = nextsoftcheck; steps = 0; Does lowering the spl level in between those two lines *really* give anything a chance to get work done? > >> You also have to consider that timeout/untimeout calls occur at > >> indeterminate rates, but softclock runs at a fixed rate meaning that > >> the amount of work it performs scales better than if that work was > >> pushed off into either of timeout or untimeout. > > > >True, but if it's 'worst-case' time happens often enough, we're > >penalizing the system *alot* more than during timeout/untimeout, which > >happens much less rarely. > > Although this may be true today, the point about it scaling still holds > true. If you increase the frequency of untimeout/timeout calls, the > new system scales very well in that the you will still encounter your > 'worst-case' time at the same rate as you did originally. Assuming the frequency of the corresponding timeout/untimeout calls is greater than the clock frequence, yes. However, if the frequency of when you call timeout and the corresponding untimeout is less than the frequency of softclock, it's a lose compared to the original implementation. With the low frequency of softclock, I suspect it's now an 'overall' win. > >The 'gotcha' is that I don't know if this is a 'normal' case, since the > >paper didn't test normal cases, but instead did lots of > >timeout/untimeouts in a user-land process, which stacks the test data in > >favor of the new implementation. > > If you don't have lots of callouts outstanding, softclock has little to > do. In it's current implementation, doesn't it have to decrement every item on the list, thus is has to walk and modify *every* callout in the list? > >> Allocate an array of ints of size ncallout. In softclock, increment the > >> array entry corresponding to the number of entries traversed in a softclock > >> run. By periodically scanning this array, you'll get a good idea of the > >> value of 'h' for you system. Add three more ints that count the number of > >> invocations of softclock, untimeout, and timeout and you should be able to > >> draw conclusions from that. > > > >But, that doesn't give me any latency #'s for any of the operations. > >Knowing how often they are called is one thing, and knowing how many > >entries are traversed is good, but *times* are the bigger issue. > > You can infer times from the other information. As the work performed > in softclock is at most O(n), you only have to call either of timeout, > or untimeout twice in each 10ms period to know that you've won. With the current softclock() frequency of 100Hz, yes. When it gets faster, then maybe. :) Nate From owner-freebsd-current Mon Sep 22 13:29:47 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id NAA16949 for current-outgoing; Mon, 22 Sep 1997 13:29:47 -0700 (PDT) Received: from pluto.plutotech.com (root@mail.plutotech.com [206.168.67.137]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id NAA16944 for ; Mon, 22 Sep 1997 13:29:43 -0700 (PDT) Received: from narnia.plutotech.com (narnia.plutotech.com [206.168.67.130]) by pluto.plutotech.com (8.8.5/8.8.5) with ESMTP id OAA00790; Mon, 22 Sep 1997 14:29:23 -0600 (MDT) Message-Id: <199709222029.OAA00790@pluto.plutotech.com> X-Mailer: exmh version 2.0zeta 7/24/97 To: Terry Lambert cc: gibbs@plutotech.com (Justin T. Gibbs), nate@mt.sri.com, current@FreeBSD.ORG Subject: Re: cvs commit: src/sys/conf files src/sys/dev/vx if_vx.c if_vxreg.h src/sys/i386/apm apm.c src/sys/i386/conf GENERIC files.i386 In-reply-to: Your message of "Mon, 22 Sep 1997 19:26:39 -0000." <199709221926.MAA16814@usr06.primenet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 22 Sep 1997 14:29:13 -0600 From: "Justin T. Gibbs" Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >> More deterministic for who? This trades O(1) insertion for O(hash chain >> length) insertion so that softclock will become O(timeouts for the current >> tick). As timeout often is called from an interrupt context >> it is not so clear where it is better to pay the price of non-determinism. > >I'm not so sure timeouts should be called from an interrupt context, >ever. Timeouts aren't ever called from a hardware interrupt context, they are called from softclock at splsoftclock. If you re-read what I wrote, I said that timeout() and untimeout() are often called from within interrupt contexts (untimeout more often than timeout) and that for this reason, those two routines should have deterministic running times. >> Softclock has the luxury of lowering it's spl at deterministic intervals >> (see the implementation) while a caller from an interrupt context doesn't. >> the current implementation always blocks interrupts for a deterministic >> amount of time. What you propose doesn't. > >O(hash chain length) insertion and O(1) event identification beats >O(1) insertion and O(total number of timeouts) event identification, >which is what you get from an unordered list. Sure, assuming that's what you have, but the new scheme is O(hash chain length) event identification in softclock + O(1) insertion/removal. Go read the paper or the code. I maintain that softclock occurs lest often than insert/removal, so paying the price in softclock is better than doing so on insertion. >You are assuming here that the softclock resoloution is higher frequency >by at least one harmonic range than the interval for any event you wish >to schedule. I submit that this is an invalid assumption. Did I? I assumed that the resolution of softclock was <= to the interval of any event currently scheduled by the kernel. Softclock nominally happens hz times a second, but since it can be delayed by other interrupt processing, it's frequency can be somewhat less than hz. All timeouts are scheduled in terms of hz. Until we decide that higher resolution timers are required, this will continue to be the case. >On a 586 or better (the only things with a high enough CPU clock >frequency to make this worrisome), you can read the inctruction cycle >counter, and use it to subtract out firing time. So. >For non-586 hardware, you can multiply by 10 the frequency, and get a >statisticaly close approximation using a drift-count (the current code >uses a drift count for the time reported as the system clock anyway). So. The current implementation doesn't attempt to offer high resolution timing facilities, so this discussion is not relevant. >> Even so, it is probably better to store an absolute tick value regardless >> so that you don't have to perform the subtraction. > >Yes, at a minimum. Also, if the list is sorted, you do not have to >traverse it in it's entirety. You do during a call to timeout(). >> If and when we decide that we need higher resolution timer facilities, we ca >n >> decide if a non-deterministic timeout() is an acceptable cost for that >> feature. > >I think they are needed to replace all occurances of delay loops in the >kernel. At the very least, this would mean that I could concurrently >probe other hardware while probing IDE or "waiting for scsi devices to >settle". 8-(. Having high resolution timers has nothing to do with the ability to remove DELAYs from the kernel especially during device configuration. You simply cannot have interrupts enabled during the early stages of device configuration on all architectures. On the x86, yes, you could just not mask the clock interrupt and get this facility early at boot, but I would not suggest relying on it as on other hardware this may be impossible. Of course, if you don't want to wait for your SCSI devices to settle, you can start using the CAM SCSI code. It does this by postponing the probing of SCSI busses until interrupt services are available, probes all buses in parallel, then allows the mounting of root and the rest of the boot to proceed. Amazingly enough, I had this code working before I changed the callout interface and I didn't use a single high resolution timer to make it work either! I'm sure you're shocked. BTW, the code to do "interrupt driven configuration" was committed at the same time as the callout changes, but I guess you didn't read all of my commit message. > Regards, > Terry Lambert > terry@lambert.org >--- >Any opinions in this posting are my own and not those of my present >or previous employers. > -- Justin T. Gibbs =========================================== FreeBSD: Turning PCs into workstations =========================================== From owner-freebsd-current Mon Sep 22 13:32:31 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id NAA17249 for current-outgoing; Mon, 22 Sep 1997 13:32:31 -0700 (PDT) Received: from usr06.primenet.com (tlambert@usr06.primenet.com [206.165.6.206]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id NAA17110 for ; Mon, 22 Sep 1997 13:31:43 -0700 (PDT) Received: (from tlambert@localhost) by usr06.primenet.com (8.8.5/8.8.5) id NAA21421; Mon, 22 Sep 1997 13:31:32 -0700 (MST) From: Terry Lambert Message-Id: <199709222031.NAA21421@usr06.primenet.com> Subject: Re: cvs commit: src/sys/conf files src/sys/dev/vx if_vx.c if_vxreg.h src/sys/i386/apm apm.c src/sys/i386/conf GENERIC files.i386 To: nate@mt.sri.com (Nate Williams) Date: Mon, 22 Sep 1997 20:31:32 +0000 (GMT) Cc: gibbs@plutotech.com, tlambert@primenet.com, nate@mt.sri.com, current@freebsd.org In-Reply-To: <199709221905.NAA02100@rocky.mt.sri.com> from "Nate Williams" at Sep 22, 97 01:05:28 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > >A more deterministic implementation would associate an absolute tick > > >value (rather than a count) with each entry, and insert entries in > > >sorted order. > > > > More deterministic for who? This trades O(1) insertion for O(hash chain > > length) insertion so that softclock will become O(timeouts for the current > > tick). As timeout often is called from an interrupt context > > it is not so clear where it is better to pay the price of non-determinism. > > Softclock has the luxury of lowering it's spl at deterministic intervals > > (see the implementation) while a caller from an interrupt context doesn't. > > the current implementation always blocks interrupts for a deterministic > > amount of time. What you propose doesn't. > > From reading the papers, the performance would be neglidgable (sp?) > since they assume the hash chain length is <= 1. That's one of the > performance gains they assume. > > > Even so, it is probably better to store an absolute tick value regardless > > so that you don't have to perform the subtraction. > > A substraction is *dirt cheap* to do. Finding the element on the list > is much more expensive than the subtraction. This is why I suggested ordered insertion. For n elements, an ordered linear insertion of a perfectly random timeout is O(n/2). In reality, I would suggest maintaining a near-skiplist for some small number of entries. Since timers export off the head, in order, dividing the entries into, say, 8 ordered and equally spaced insertion vectors should work. Given the head-forward, these vectors could easily march forward through the list, as necessary to maintain spacing. This is O(log2(n)+(n/8)) in the average case. I think insertion can take a relatively "long time", in any case; it is the speed of expiration which is important. You can keep the doubly linked list so that removal is still O(1), and event processing is always O(number of events that expire), or ~= O(1). Better to take the hit when you have slack. If you use an absolute tick rather than a delta, then it doesn't matter how long the delay between "I want to insert" and "actual insertion", so long a the number of ticks it takes is less than the total number of ticks between the current time and the expiration time. Better to take the fuzz where you can afford fuzz, I say. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-current Mon Sep 22 13:37:39 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id NAA17684 for current-outgoing; Mon, 22 Sep 1997 13:37:39 -0700 (PDT) Received: from pluto.plutotech.com (root@mail.plutotech.com [206.168.67.137]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id NAA17679 for ; Mon, 22 Sep 1997 13:37:37 -0700 (PDT) Received: from narnia.plutotech.com (narnia.plutotech.com [206.168.67.130]) by pluto.plutotech.com (8.8.5/8.8.5) with ESMTP id OAA01057; Mon, 22 Sep 1997 14:37:21 -0600 (MDT) Message-Id: <199709222037.OAA01057@pluto.plutotech.com> X-Mailer: exmh version 2.0zeta 7/24/97 To: Nate Williams cc: "Justin T. Gibbs" , Bruce Evans , current@FreeBSD.ORG Subject: Re: cvs commit: src/sys/conf files src/sys/dev/vx if_vx.c if_vxreg.h src/sys/i386/apm apm.c src/sys/i386/conf GENERIC files.i386 src/sys/i386/eisa 3c5x9.c aha1742.c aic7770.c bt74x.c eisaconf.c eisaconf.h if_fea.c if_vx_eisa.c src/sys/i386/i386 autoconf.c ... In-reply-to: Your message of "Mon, 22 Sep 1997 13:07:22 MDT." <199709221907.NAA02110@rocky.mt.sri.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 22 Sep 1997 14:37:10 -0600 From: "Justin T. Gibbs" Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >> The current implementation only needs to allocate a callout at a time if >> it wants to grow the number of callouts. It may, in fact be nice to add >> an interface for clients to add additional callouts if they are heavy >> users of them. For instance, the CAM system grows it's number of >> transactions dynamically and will simply stop growing if it can't malloc >> more. In your scenario, if you can't allocate space for a drive and it's >> transactions, you can't talk to the drive. > >Umm, how does the CAM system still talk to a drive if it can't establish >a callout for it? If it can do that now, then it can certainly do it >with the old solution. I assume that I can allocate a single CCB/callout at boot time. If this is the case, I can talk to any number of devices by serializing the transactions. It won't be fast, but it won't fail either. CCB = CAM Control Block - a structure used to encapsulate a CAM transaction. >Nate -- Justin T. Gibbs =========================================== FreeBSD: Turning PCs into workstations =========================================== From owner-freebsd-current Mon Sep 22 13:39:06 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id NAA17817 for current-outgoing; Mon, 22 Sep 1997 13:39:06 -0700 (PDT) Received: from pluto.plutotech.com (root@mail.plutotech.com [206.168.67.137]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id NAA17808 for ; Mon, 22 Sep 1997 13:39:02 -0700 (PDT) Received: from narnia.plutotech.com (narnia.plutotech.com [206.168.67.130]) by pluto.plutotech.com (8.8.5/8.8.5) with ESMTP id OAA01103; Mon, 22 Sep 1997 14:38:47 -0600 (MDT) Message-Id: <199709222038.OAA01103@pluto.plutotech.com> X-Mailer: exmh version 2.0zeta 7/24/97 To: Nate Williams cc: "Justin T. Gibbs" , Bruce Evans , current@freebsd.org Subject: Re: cvs commit: src/sys/conf files src/sys/dev/vx if_vx.c if_vxreg.h src/sys/i386/apm apm.c src/sys/i386/conf GENERIC files.i386 src/sys/i386/eisa 3c5x9.c aha1742.c aic7770.c bt74x.c eisaconf.c eisaconf.h if_fea.c if_vx_eisa.c src/sys/i386/i386 autoconf.c ... In-reply-to: Your message of "Mon, 22 Sep 1997 14:25:45 MDT." <199709222025.OAA02565@rocky.mt.sri.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 22 Sep 1997 14:38:37 -0600 From: "Justin T. Gibbs" Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >> It runs at splhigh() while traversing callout entries and splsoftclock() >> when calling timeouts. The new implemenatation will traverse at most >> 100 entries before lowering it's IPL from splhigh() so that other interrupt >> handlers can run. > >I need to look at the code. Hmm, seems kind of silly to me: > > ++steps; > if (steps >= MAX_SOFTCLOCK_STEPS) { > nextsoftcheck = c; > splx(s); > /* Give hardclock() a chance. */ > s = splhigh(); > c = nextsoftcheck; > steps = 0; > >Does lowering the spl level in between those two lines *really* give >anything a chance to get work done? If there are pending hardware interrupts, they will fire at the point of splx(). >> Although this may be true today, the point about it scaling still holds >> true. If you increase the frequency of untimeout/timeout calls, the >> new system scales very well in that the you will still encounter your >> 'worst-case' time at the same rate as you did originally. > >Assuming the frequency of the corresponding timeout/untimeout calls is >greater than the clock frequence, yes. However, if the frequency of >when you call timeout and the corresponding untimeout is less than the >frequency of softclock, it's a lose compared to the original >implementation. With the low frequency of softclock, I suspect it's now >an 'overall' win. The timeout and untimeout calls do not need to be paired for this to be the case. >> If you don't have lots of callouts outstanding, softclock has little to >> do. > >In it's current implementation, doesn't it have to decrement every item >on the list, thus is has to walk and modify *every* callout in the list? But what is in the list if few callouts are outstanding? >Nate -- Justin T. Gibbs =========================================== FreeBSD: Turning PCs into workstations =========================================== From owner-freebsd-current Mon Sep 22 13:40:14 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id NAA18018 for current-outgoing; Mon, 22 Sep 1997 13:40:14 -0700 (PDT) Received: from ns.mt.sri.com (SRI-56K-FR.mt.net [206.127.65.42]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id NAA18012 for ; Mon, 22 Sep 1997 13:40:11 -0700 (PDT) Received: from rocky.mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.8.7/8.8.7) with ESMTP id OAA15127; Mon, 22 Sep 1997 14:40:06 -0600 (MDT) Received: (from nate@localhost) by rocky.mt.sri.com (8.7.5/8.7.3) id OAA02694; Mon, 22 Sep 1997 14:40:03 -0600 (MDT) Date: Mon, 22 Sep 1997 14:40:03 -0600 (MDT) Message-Id: <199709222040.OAA02694@rocky.mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: "Justin T. Gibbs" Cc: Nate Williams , Bruce Evans , current@freebsd.org Subject: callouts in CAM (was Re: cvs commit:) In-Reply-To: <199709222037.OAA01057@pluto.plutotech.com> References: <199709221907.NAA02110@rocky.mt.sri.com> <199709222037.OAA01057@pluto.plutotech.com> X-Mailer: VM 6.29 under 19.15 XEmacs Lucid Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Justin T. Gibbs writes: > >> The current implementation only needs to allocate a callout at a time if > >> it wants to grow the number of callouts. It may, in fact be nice to add > >> an interface for clients to add additional callouts if they are heavy > >> users of them. For instance, the CAM system grows it's number of > >> transactions dynamically and will simply stop growing if it can't malloc > >> more. In your scenario, if you can't allocate space for a drive and it's > >> transactions, you can't talk to the drive. > > > >Umm, how does the CAM system still talk to a drive if it can't establish > >a callout for it? If it can do that now, then it can certainly do it > >with the old solution. > > I assume that I can allocate a single CCB/callout at boot time. If this > is the case, I can talk to any number of devices by serializing the > transactions. It won't be fast, but it won't fail either. > > CCB = CAM Control Block - a structure used to encapsulate a CAM > transaction. Couldn't you do this with the old setup as well, since you have access to the callouts at boot time in both schemes? Nate From owner-freebsd-current Mon Sep 22 13:41:25 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id NAA18078 for current-outgoing; Mon, 22 Sep 1997 13:41:25 -0700 (PDT) Received: from usr06.primenet.com (tlambert@usr06.primenet.com [206.165.6.206]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id NAA18073 for ; Mon, 22 Sep 1997 13:41:23 -0700 (PDT) Received: (from tlambert@localhost) by usr06.primenet.com (8.8.5/8.8.5) id NAA22085; Mon, 22 Sep 1997 13:41:12 -0700 (MST) From: Terry Lambert Message-Id: <199709222041.NAA22085@usr06.primenet.com> Subject: Re: cvs commit: src/sys/conf files src/sys/dev/vx if_vx.c if_vxreg.h src/sys/i386/apm apm.c src/sys/i386/conf GENERIC files.i386 To: nate@mt.sri.com (Nate Williams) Date: Mon, 22 Sep 1997 20:41:11 +0000 (GMT) Cc: tlambert@primenet.com, gibbs@plutotech.com, nate@mt.sri.com, current@FreeBSD.ORG In-Reply-To: <199709221932.NAA02277@rocky.mt.sri.com> from "Nate Williams" at Sep 22, 97 01:32:20 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > > More deterministic for who? This trades O(1) insertion for O(hash chain > > > length) insertion so that softclock will become O(timeouts for the current > > > tick). As timeout often is called from an interrupt context > > > it is not so clear where it is better to pay the price of non-determinism. > > > > I'm not so sure timeouts should be called from an interrupt context, > > ever. > > [ rest deleted ] > > We're talking reality here Terry, not theory. > > 'If the world were a perfect place, we wouldn't need interrupts since we > could get everything done when we needed to and it wouldn't mess with > anything else, but this isn't a perfect world.' This is not what I'm saying. I'm saying virtualize the interrupts to reduce the time between when I can want to context switch, and when I can context switch. The more time I spend at interrupt, the less useful work I can do, and the higher my overall latency to get from what I am doing to what I need to be doing instead because of hard time constraints. Most modern UNIX OS's virtualize interrupts as part of supporting RT scheduling. > The extra complexity required to do your above solution is *WAY* > overkill. (I've done things such as it on a small-scale basis, and > performance starts to drop off quickly due to data synchronization when > you have lots of 'objects/drivers'.) Concurrency is only a big win for really cruddy hardware, like QIC-40/80 tape drives and the floppy controller, or anthing that needs PIO'ed. I admit a lot of PC hardware falls in this category. For the SVR3.2 ft driver, fully 40% of the CPU time was sucked up by buzz-loops. The win here is that you can make the CPU available to those devices "in time". This allows you to go off and do other stuff "less important" than buzz-looping in a floppy tape driver. The real win is the ability to set hard deadlines for a context switch for a deadlined event: a move toward hard RT. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-current Mon Sep 22 13:47:09 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id NAA18459 for current-outgoing; Mon, 22 Sep 1997 13:47:09 -0700 (PDT) Received: from ns.mt.sri.com (SRI-56K-FR.mt.net [206.127.65.42]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id NAA18452 for ; Mon, 22 Sep 1997 13:47:05 -0700 (PDT) Received: from rocky.mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.8.7/8.8.7) with ESMTP id OAA15169; Mon, 22 Sep 1997 14:46:59 -0600 (MDT) Received: (from nate@localhost) by rocky.mt.sri.com (8.7.5/8.7.3) id OAA02778; Mon, 22 Sep 1997 14:46:57 -0600 (MDT) Date: Mon, 22 Sep 1997 14:46:57 -0600 (MDT) Message-Id: <199709222046.OAA02778@rocky.mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: "Justin T. Gibbs" Cc: Nate Williams , Bruce Evans , current@freebsd.org Subject: Re: cvs commit: src/sys/conf files src/sys/dev/vx if_vx.c if_vxreg.h src/sys/i386/apm apm.c src/sys/i386/conf GENERIC files.i386 src/sys/i386/eisa 3c5x9.c aha1742.c aic7770.c bt74x.c eisaconf.c eisaconf.h if_fea.c if_vx_eisa.c src/sys/i386/i386 autoconf.c ... In-Reply-To: <199709222038.OAA01103@pluto.plutotech.com> References: <199709222025.OAA02565@rocky.mt.sri.com> <199709222038.OAA01103@pluto.plutotech.com> X-Mailer: VM 6.29 under 19.15 XEmacs Lucid Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > >> Although this may be true today, the point about it scaling still holds > >> true. If you increase the frequency of untimeout/timeout calls, the > >> new system scales very well in that the you will still encounter your > >> 'worst-case' time at the same rate as you did originally. > > > >Assuming the frequency of the corresponding timeout/untimeout calls is > >greater than the clock frequence, yes. However, if the frequency of > >when you call timeout and the corresponding untimeout is less than the > >frequency of softclock, it's a lose compared to the original > >implementation. With the low frequency of softclock, I suspect it's now > >an 'overall' win. > > The timeout and untimeout calls do not need to be paired for this to be > the case. Sure they do. If you have a bunch of timeout calls, and the untimeouts for them don't occur until *after* softclock, you have lots of entries to walk through. > >> If you don't have lots of callouts outstanding, softclock has little to > >> do. > > > >In it's current implementation, doesn't it have to decrement every item > >on the list, thus is has to walk and modify *every* callout in the list? > > But what is in the list if few callouts are outstanding? The whole assumption of this code is that the frequency of paird timeout/untimeout calls happen *much* more frequently than the frequency of softclocks, right? If that isn't the case (the clock frequency is increased, or timeouts are long), then the new system is a lose, because the # of callouts in the list at softclock() time starts to effect the effeciency of the system. Is this a correct assumption? If so, then Terry's concerns about high-resolution timers is still valid, even though the design wasn't designed for this, it negatively affects it *IF* high-resolution timers are a future goal. Nate From owner-freebsd-current Mon Sep 22 13:49:02 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id NAA18592 for current-outgoing; Mon, 22 Sep 1997 13:49:02 -0700 (PDT) Received: from pluto.plutotech.com (root@mail.plutotech.com [206.168.67.137]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id NAA18582 for ; Mon, 22 Sep 1997 13:48:58 -0700 (PDT) Received: from narnia.plutotech.com (narnia.plutotech.com [206.168.67.130]) by pluto.plutotech.com (8.8.5/8.8.5) with ESMTP id OAA01438; Mon, 22 Sep 1997 14:48:46 -0600 (MDT) Message-Id: <199709222048.OAA01438@pluto.plutotech.com> X-Mailer: exmh version 2.0zeta 7/24/97 To: Nate Williams cc: "Justin T. Gibbs" , Bruce Evans , current@freebsd.org Subject: Re: callouts in CAM (was Re: cvs commit:) In-reply-to: Your message of "Mon, 22 Sep 1997 14:40:03 MDT." <199709222040.OAA02694@rocky.mt.sri.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 22 Sep 1997 14:48:36 -0600 From: "Justin T. Gibbs" Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >Couldn't you do this with the old setup as well, since you have access >to the callouts at boot time in both schemes? Sure. You can dynamically add callouts in both the old and new schemes, but the difference between Bruce's proposal and the current one is that it is more expensive/difficult to add callouts incrementally after the system is up (essentially on demand) since you have to reallocate whole arrays. >Nate -- Justin T. Gibbs =========================================== FreeBSD: Turning PCs into workstations =========================================== From owner-freebsd-current Mon Sep 22 13:51:48 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id NAA18842 for current-outgoing; Mon, 22 Sep 1997 13:51:48 -0700 (PDT) Received: from ns.mt.sri.com (SRI-56K-FR.mt.net [206.127.65.42]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id NAA18828 for ; Mon, 22 Sep 1997 13:51:41 -0700 (PDT) Received: from rocky.mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.8.7/8.8.7) with ESMTP id OAA15203; Mon, 22 Sep 1997 14:51:27 -0600 (MDT) Received: (from nate@localhost) by rocky.mt.sri.com (8.7.5/8.7.3) id OAA02828; Mon, 22 Sep 1997 14:51:25 -0600 (MDT) Date: Mon, 22 Sep 1997 14:51:25 -0600 (MDT) Message-Id: <199709222051.OAA02828@rocky.mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: "Justin T. Gibbs" Cc: Nate Williams , Bruce Evans , current@freebsd.org Subject: Re: callouts in CAM (was Re: cvs commit:) In-Reply-To: <199709222048.OAA01438@pluto.plutotech.com> References: <199709222040.OAA02694@rocky.mt.sri.com> <199709222048.OAA01438@pluto.plutotech.com> X-Mailer: VM 6.29 under 19.15 XEmacs Lucid Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > >Couldn't you do this with the old setup as well, since you have access > >to the callouts at boot time in both schemes? > > Sure. You can dynamically add callouts in both the old and new schemes, > but the difference between Bruce's proposal and the current one is > that it is more expensive/difficult to add callouts incrementally after > the system is up (essentially on demand) since you have to reallocate > whole arrays. Fair enough. Does the new scheme allow for dynamic allocation of callouts? I noticed that was on the TODO list for the original authors. Nate From owner-freebsd-current Mon Sep 22 13:53:51 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id NAA18980 for current-outgoing; Mon, 22 Sep 1997 13:53:51 -0700 (PDT) Received: from ns.mt.sri.com (SRI-56K-FR.mt.net [206.127.65.42]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id NAA18975 for ; Mon, 22 Sep 1997 13:53:46 -0700 (PDT) Received: from rocky.mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.8.7/8.8.7) with ESMTP id OAA15225; Mon, 22 Sep 1997 14:53:40 -0600 (MDT) Received: (from nate@localhost) by rocky.mt.sri.com (8.7.5/8.7.3) id OAA02847; Mon, 22 Sep 1997 14:53:38 -0600 (MDT) Date: Mon, 22 Sep 1997 14:53:38 -0600 (MDT) Message-Id: <199709222053.OAA02847@rocky.mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: "Justin T. Gibbs" Cc: Terry Lambert , nate@mt.sri.com, current@freebsd.org Subject: Re: cvs commit: src/sys/conf files src/sys/dev/vx if_vx.c if_vxreg.h src/sys/i386/apm apm.c src/sys/i386/conf GENERIC files.i386 In-Reply-To: <199709222029.OAA00790@pluto.plutotech.com> References: <199709221926.MAA16814@usr06.primenet.com> <199709222029.OAA00790@pluto.plutotech.com> X-Mailer: VM 6.29 under 19.15 XEmacs Lucid Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > >O(hash chain length) insertion and O(1) event identification beats > >O(1) insertion and O(total number of timeouts) event identification, > >which is what you get from an unordered list. > > Sure, assuming that's what you have, but the new scheme is > O(hash chain length) event identification in softclock + O(1) > insertion/removal. Not quite. It's really "O(hash chain length) event identification + O(n) callout overhead processing + O(1) insertion/removal" in the new scheme. > >> Even so, it is probably better to store an absolute tick value regardless > >> so that you don't have to perform the subtraction. > > > >Yes, at a minimum. Also, if the list is sorted, you do not have to > >traverse it in it's entirety. > > You do during a call to timeout(). True. There's really no way around higher costs at timeout() with the old scheme (although it would be trivial to optimize untimeout() with hashtables). Any other solution I can come up with ends up looking alot like the new scheme. :) Nate From owner-freebsd-current Mon Sep 22 14:01:17 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id OAA19438 for current-outgoing; Mon, 22 Sep 1997 14:01:17 -0700 (PDT) Received: from earth.mat.net (root@earth.mat.net [206.246.122.2]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id OAA19429 for ; Mon, 22 Sep 1997 14:01:09 -0700 (PDT) Received: from Journey2.mat.net (journey2.mat.net [206.246.122.116]) by earth.mat.net (8.8.7/8.6.12) with SMTP id RAA13478; Mon, 22 Sep 1997 17:00:33 -0400 (EDT) Date: Mon, 22 Sep 1997 17:00:14 -0400 (EDT) From: Chuck Robey X-Sender: chuckr@Journey2.mat.net To: Ollivier Robert cc: FreeBSD current Subject: Re: ctm blowup In-Reply-To: <19970922212907.40124@keltia.freenix.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Mon, 22 Sep 1997, Ollivier Robert wrote: > According to Chuck Robey: > > Anyone know what that was, or how I could get ctm back on track? > > Surprising, I'm also at 3670 and didn't see this message... I have cvs-cur > as usual and the crypto stuff from ftp.internat.freebsd.org. Mark told me to blow away my ncvs/src/kerberosIV. I really hate touching my archive with anything but ctm, but since I was dead in the water, I took the risk. At least so far, it seems to have worked. I am up to 3673 and going ok so far. I have an update of /usr/src in progress right now, about half thru, and it seems ok so far. > -- > Ollivier ROBERT -=- FreeBSD: There are no limits -=- roberto@keltia.freenix.fr > FreeBSD keltia.freenix.fr 3.0-CURRENT #35: Sun Sep 21 19:28:07 CEST 1997 > > ----------------------------+----------------------------------------------- Chuck Robey | Interests include any kind of voice or data chuckr@eng.umd.edu | communications topic, C programming, and Unix. 213 Lakeside Drive Apt T-1 | Greenbelt, MD 20770 | I run Journey2 and picnic, both FreeBSD (301) 220-2114 | version 3.0 current -- and great FUN! ----------------------------+----------------------------------------------- From owner-freebsd-current Mon Sep 22 14:02:41 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id OAA19526 for current-outgoing; Mon, 22 Sep 1997 14:02:41 -0700 (PDT) Received: from usr06.primenet.com (tlambert@usr06.primenet.com [206.165.6.206]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id OAA19517 for ; Mon, 22 Sep 1997 14:02:36 -0700 (PDT) Received: (from tlambert@localhost) by usr06.primenet.com (8.8.5/8.8.5) id OAA23943; Mon, 22 Sep 1997 14:02:27 -0700 (MST) From: Terry Lambert Message-Id: <199709222102.OAA23943@usr06.primenet.com> Subject: Re: cvs commit: src/sys/conf files src/sys/dev/vx if_vx.c if_vxreg.h src/sys/i386/apm apm.c src/sys/i386/conf GENERIC files.i386 To: gibbs@plutotech.com (Justin T. Gibbs) Date: Mon, 22 Sep 1997 21:02:27 +0000 (GMT) Cc: tlambert@primenet.com, gibbs@plutotech.com, nate@mt.sri.com, current@FreeBSD.ORG In-Reply-To: <199709222029.OAA00790@pluto.plutotech.com> from "Justin T. Gibbs" at Sep 22, 97 02:29:13 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > >Yes, at a minimum. Also, if the list is sorted, you do not have to > >traverse it in it's entirety. > > You do during a call to timeout(). This depends on whether I want timeouts to be "hard". If I want them to be hard, than this is unacceptable: a hard timeout needs to occur in expiration order. To get that with an unsorted list is O(n^2). > >I think they are needed to replace all occurances of delay loops in the > >kernel. At the very least, this would mean that I could concurrently > >probe other hardware while probing IDE or "waiting for scsi devices to > >settle". 8-(. > > Having high resolution timers has nothing to do with the ability to > remove DELAYs from the kernel especially during device configuration. HRT services or LRT services are irrelevent; I haven't made a strict frequency requirement so far (though I did note that I could see use for HRT). The question is how "hard" the timeout is when it does occur. See my other posting on how to reduce the insertion time further. I agree that insertion time is a factor based on frequency of insertion relative to timer scheduling frequency (it actually get worse, the higher the timer resoloution). So I agree with you that insertion and deletion are "more important" in that case. However. For a timer that is not going to expire, and has been scheduled for some 'n' ticks in the future, and will be removed some 'm' ticks in the future without firing, I can take up to 'n-m' ticks, at the absolute outside, to schedule the thing. Further, if I do not schedule deltas, then the time it takes to get it on the list is absolutely irrelevant. I am saying "timer, fire at this tick". So long as it's on the list before "this tick", I'm fine. Going back to the non-expiration case, so long as the number of ticks from the firing tick calculation time to the time it is removed as "never going to fire" is more the the time it takes to insert, act, and remove, I'm fine. Generally, all this means is that you make the potentially "lost" call that is timing out before you enqueue the timer. > You simply cannot have interrupts enabled during the early stages of > device configuration on all architectures. On the x86, yes, you could > just not mask the clock interrupt and get this facility early at boot, > but I would not suggest relying on it as on other hardware this may be > impossible. Agreed. However, there is no definite requirement on such architectures that the clock fire; you could just as easily delay-poll (which you will have to do anyway) to implement timing. > Of course, if you don't want to wait for your SCSI devices to settle, > you can start using the CAM SCSI code. It does this by postponing > the probing of SCSI busses until interrupt services are available, > probes all buses in parallel, then allows the mounting of root and > the rest of the boot to proceed. Amazingly enough, I had this code > working before I changed the callout interface and I didn't use > a single high resolution timer to make it work either! I'm sure > you're shocked. I'm not. The only HRT issue is the resoloution of the delay between when a timeout is scheduled to fire and when it actually runs. > BTW, the code to do "interrupt driven configuration" > was committed at the same time as the callout changes, but I guess > you didn't read all of my commit message. Nope, sorry. I read CVS logs for files that impact me, and generally let whoever do whatever behind my back so long as it doesn't affect me. Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-current Mon Sep 22 14:04:40 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id OAA19719 for current-outgoing; Mon, 22 Sep 1997 14:04:40 -0700 (PDT) Received: from gratis.grondar.za (gratis.grondar.za [196.7.18.133]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id OAA19678 for ; Mon, 22 Sep 1997 14:04:19 -0700 (PDT) Received: from greenpeace.grondar.za (RCNI9D7untniR+SF8uD3TFbSWdR4DS0d@greenpeace.grondar.za [196.7.18.132]) by gratis.grondar.za (8.8.7/8.8.7) with ESMTP id XAA00825; Mon, 22 Sep 1997 23:04:28 +0200 (SAT) Received: from greenpeace.grondar.za (5Jy6CIkAqaBsXHWkzYwvo2rCLQ72AJuL@localhost [127.0.0.1]) by greenpeace.grondar.za (8.8.7/8.8.7) with ESMTP id XAA23950; Mon, 22 Sep 1997 23:04:40 +0200 (SAT) Message-Id: <199709222104.XAA23950@greenpeace.grondar.za> X-Mailer: exmh version 2.0zeta 7/24/97 To: Ollivier Robert cc: FreeBSD current Subject: Re: ctm blowup Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 22 Sep 1997 23:04:39 +0200 From: Mark Murray Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Ollivier Robert wrote: > According to Chuck Robey: > > Anyone know what that was, or how I could get ctm back on track? > > Surprising, I'm also at 3670 and didn't see this message... I have cvs-cur > as usual and the crypto stuff from ftp.internat.freebsd.org. He's got some old cruft left over from ages ago. M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org From owner-freebsd-current Mon Sep 22 14:04:53 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id OAA19754 for current-outgoing; Mon, 22 Sep 1997 14:04:53 -0700 (PDT) Received: from pluto.plutotech.com (root@mail.plutotech.com [206.168.67.137]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id OAA19742 for ; Mon, 22 Sep 1997 14:04:47 -0700 (PDT) Received: from narnia.plutotech.com (narnia.plutotech.com [206.168.67.130]) by pluto.plutotech.com (8.8.5/8.8.5) with ESMTP id PAA01993; Mon, 22 Sep 1997 15:04:30 -0600 (MDT) Message-Id: <199709222104.PAA01993@pluto.plutotech.com> X-Mailer: exmh version 2.0zeta 7/24/97 To: Nate Williams cc: "Justin T. Gibbs" , Bruce Evans , current@freebsd.org Subject: Re: cvs commit: src/sys/conf files src/sys/dev/vx if_vx.c if_vxreg.h src/sys/i386/apm apm.c src/sys/i386/conf GENERIC files.i386 src/sys/i386/eisa 3c5x9.c aha1742.c aic7770.c bt74x.c eisaconf.c eisaconf.h if_fea.c if_vx_eisa.c src/sys/i386/i386 autoconf.c ... In-reply-to: Your message of "Mon, 22 Sep 1997 14:46:57 MDT." <199709222046.OAA02778@rocky.mt.sri.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 22 Sep 1997 15:04:20 -0600 From: "Justin T. Gibbs" Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >> The timeout and untimeout calls do not need to be paired for this to be >> the case. > >Sure they do. If you have a bunch of timeout calls, and the untimeouts >for them don't occur until *after* softclock, you have lots of entries >to walk through. And timeout and untimeout would have just as many (most likely more since the hash table isn't very full) to walk through each time. I was comparing the new softclock with time O(n) (which is worse than it really is) and that of the original timeout and untimeout, O(n). The calls don't need to be paired for this analysis to be valid. >> But what is in the list if few callouts are outstanding? > >The whole assumption of this code is that the frequency of paird >timeout/untimeout calls happen *much* more frequently than the frequency >of softclocks, right? If that isn't the case (the clock frequency is >increased, or timeouts are long), then the new system is a lose, because >the # of callouts in the list at softclock() time starts to effect the >effeciency of the system. > >Is this a correct assumption? If so, then Terry's concerns about >high-resolution timers is still valid, even though the design wasn't >designed for this, it negatively affects it *IF* high-resolution timers >are a future goal. The code assumes nothing of the sort. My analysis of running time assumes that the frequency of calls to timeout or untimeout is >= the number of calls to softclock. If we decide to do high resolution timers, the analysis may change as will most likely the implementation although probably not by much. >Nate -- Justin T. Gibbs =========================================== FreeBSD: Turning PCs into workstations =========================================== From owner-freebsd-current Mon Sep 22 14:06:41 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id OAA19995 for current-outgoing; Mon, 22 Sep 1997 14:06:41 -0700 (PDT) Received: from pluto.plutotech.com (root@mail.plutotech.com [206.168.67.137]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id OAA19989 for ; Mon, 22 Sep 1997 14:06:38 -0700 (PDT) Received: from narnia.plutotech.com (narnia.plutotech.com [206.168.67.130]) by pluto.plutotech.com (8.8.5/8.8.5) with ESMTP id PAA02060; Mon, 22 Sep 1997 15:06:32 -0600 (MDT) Message-Id: <199709222106.PAA02060@pluto.plutotech.com> X-Mailer: exmh version 2.0zeta 7/24/97 To: Nate Williams cc: "Justin T. Gibbs" , Bruce Evans , current@freebsd.org Subject: Re: callouts in CAM (was Re: cvs commit:) In-reply-to: Your message of "Mon, 22 Sep 1997 14:51:25 MDT." <199709222051.OAA02828@rocky.mt.sri.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 22 Sep 1997 15:06:21 -0600 From: "Justin T. Gibbs" Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >Fair enough. Does the new scheme allow for dynamic allocation of >callouts? I noticed that was on the TODO list for the original authors. Yes, but it's still not implemented. I think that we should push this onto the client instead of attempting to do some kind of low water-mark early allocation. In other words, allocate a fairly small initial pool for most applications and then have systems like CAM allocate a callout on an as-needed basis. >Nate -- Justin T. Gibbs =========================================== FreeBSD: Turning PCs into workstations =========================================== From owner-freebsd-current Mon Sep 22 14:12:51 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id OAA20467 for current-outgoing; Mon, 22 Sep 1997 14:12:51 -0700 (PDT) Received: from mhub2.tc.umn.edu (0@mhub2.tc.umn.edu [128.101.131.52]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id OAA20447 for ; Mon, 22 Sep 1997 14:12:47 -0700 (PDT) Received: from gold.tc.umn.edu by mhub2.tc.umn.edu; Mon, 22 Sep 97 15:31:28 -0500 Received: from pub-30-a-137.dialup.umn.edu by gold.tc.umn.edu; Mon, 22 Sep 97 15:31:27 -0500 Date: Mon, 22 Sep 1997 15:31:37 -0500 (CDT) From: dave adkins To: current@freebsd.org Subject: is wcd.c missing a bufq_init call in wcdattach Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi, I panic'd in bufqdisksort during mount_cd9660 (current 970922). It looks like the it's a result of an uninitialized queue. I noticed that the wcd stuff didn't seem to initialize the queue (wcd[unit]->buf_queue). Adding a bufq_init call to wdcstrategy seemed to fix the problem. dave adkins From owner-freebsd-current Mon Sep 22 14:14:09 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id OAA20585 for current-outgoing; Mon, 22 Sep 1997 14:14:09 -0700 (PDT) Received: from ns.mt.sri.com (SRI-56K-FR.mt.net [206.127.65.42]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id OAA20572 for ; Mon, 22 Sep 1997 14:14:02 -0700 (PDT) Received: from rocky.mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.8.7/8.8.7) with ESMTP id PAA15382; Mon, 22 Sep 1997 15:13:54 -0600 (MDT) Received: (from nate@localhost) by rocky.mt.sri.com (8.7.5/8.7.3) id PAA03063; Mon, 22 Sep 1997 15:13:52 -0600 (MDT) Date: Mon, 22 Sep 1997 15:13:52 -0600 (MDT) Message-Id: <199709222113.PAA03063@rocky.mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: "Justin T. Gibbs" Cc: Nate Williams , Bruce Evans , current@freebsd.org Subject: Re: cvs commit: src/sys/conf files src/sys/dev/vx if_vx.c if_vxreg.h src/sys/i386/apm apm.c src/sys/i386/conf GENERIC files.i386 src/sys/i386/eisa 3c5x9.c aha1742.c aic7770.c bt74x.c eisaconf.c eisaconf.h if_fea.c if_vx_eisa.c src/sys/i386/i386 autoconf.c ... In-Reply-To: <199709222104.PAA01993@pluto.plutotech.com> References: <199709222046.OAA02778@rocky.mt.sri.com> <199709222104.PAA01993@pluto.plutotech.com> X-Mailer: VM 6.29 under 19.15 XEmacs Lucid Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > >> The timeout and untimeout calls do not need to be paired for this to be > >> the case. > > > >Sure they do. If you have a bunch of timeout calls, and the untimeouts > >for them don't occur until *after* softclock, you have lots of entries > >to walk through. > > And timeout and untimeout would have just as many (most likely more since > the hash table isn't very full) to walk through each time. Not quite, because in the old scheme, they are sorted. It's really O(n/2) on average. The new scheme is forced to walk every element at softclock. > I was comparing > the new softclock with time O(n) (which is worse than it really is) and that > of the original timeout and untimeout, O(n). The calls don't need to > be paired for this analysis to be valid. Again, it would be nice to get some 'Real(tm)' #'s so all of us could quit guessing at things, and have something to point out other than the code. > >The whole assumption of this code is that the frequency of paird > >timeout/untimeout calls happen *much* more frequently than the frequency > >of softclocks, right? If that isn't the case (the clock frequency is > >increased, or timeouts are long), then the new system is a lose, because > >the # of callouts in the list at softclock() time starts to effect the > >effeciency of the system. > > > >Is this a correct assumption? If so, then Terry's concerns about > >high-resolution timers is still valid, even though the design wasn't > >designed for this, it negatively affects it *IF* high-resolution timers > >are a future goal. > > The code assumes nothing of the sort. My analysis of running time assumes > that the frequency of calls to timeout or untimeout is >= the number of > calls to softclock. If that changes, then my analysis of the code suggests that the current scheme could be a deteriment, rather than a help if we implement high resolution timers, because the time in softclock() becomes dominant instead of the time in timeout/untimeout. Simply put, if softclock is called more than timeout/untimeout, then the new system is a lose. (No matter how many callouts are outstanding.) Nate From owner-freebsd-current Mon Sep 22 14:15:21 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id OAA20768 for current-outgoing; Mon, 22 Sep 1997 14:15:21 -0700 (PDT) Received: from sos.freebsd.dk (sos.freebsd.dk [195.8.129.33]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id OAA20752; Mon, 22 Sep 1997 14:15:13 -0700 (PDT) Received: (from sos@localhost) by sos.freebsd.dk (8.8.7/8.7.3) id XAA00327; Mon, 22 Sep 1997 23:15:12 +0200 (MEST) From: Søren Schmidt Message-Id: <199709222115.XAA00327@sos.freebsd.dk> Subject: Anybody tried to mount a CD lately ?? To: current@freebsd.org (FreeBSD current), gibbs@freebsd.org Date: Mon, 22 Sep 1997 23:15:11 +0200 (MEST) X-Mailer: ELM [version 2.4ME+ PL30 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Gets you a nice panic in bufq_disksort :( Oh, well... -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Søren Schmidt (sos@FreeBSD.org) FreeBSD Core Team Even more code to hack -- will it ever end .. From owner-freebsd-current Mon Sep 22 14:29:29 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id OAA21846 for current-outgoing; Mon, 22 Sep 1997 14:29:29 -0700 (PDT) Received: from pluto.plutotech.com (root@mail.plutotech.com [206.168.67.137]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id OAA21831 for ; Mon, 22 Sep 1997 14:29:27 -0700 (PDT) Received: from narnia.plutotech.com (narnia.plutotech.com [206.168.67.130]) by pluto.plutotech.com (8.8.5/8.8.5) with ESMTP id PAA02701; Mon, 22 Sep 1997 15:29:16 -0600 (MDT) Message-Id: <199709222129.PAA02701@pluto.plutotech.com> X-Mailer: exmh version 2.0zeta 7/24/97 To: Nate Williams cc: "Justin T. Gibbs" , Bruce Evans , current@freebsd.org Subject: Re: cvs commit: src/sys/conf files src/sys/dev/vx if_vx.c if_vxreg.h src/sys/i386/apm apm.c src/sys/i386/conf GENERIC files.i386 src/sys/i386/eisa 3c5x9.c aha1742.c aic7770.c bt74x.c eisaconf.c eisaconf.h if_fea.c if_vx_eisa.c src/sys/i386/i386 autoconf.c ... In-reply-to: Your message of "Mon, 22 Sep 1997 15:13:52 MDT." <199709222113.PAA03063@rocky.mt.sri.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 22 Sep 1997 15:29:05 -0600 From: "Justin T. Gibbs" Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >> And timeout and untimeout would have just as many (most likely more since >> the hash table isn't very full) to walk through each time. > >Not quite, because in the old scheme, they are sorted. It's really >O(n/2) on average. The new scheme is forced to walk every element at >softclock. And softclock will most likely be something approaching O(1). Remeber it doesn't walk everything, only the entries in the current bucket. But, I'll give you O(n) if you want which is worst case running time, and even allow you to use the average running time for the old code, which means you need only three calls in order to make the new scheme superior. >> I was comparing >> the new softclock with time O(n) (which is worse than it really is) and that >> of the original timeout and untimeout, O(n). The calls don't need to >> be paired for this analysis to be valid. > >Again, it would be nice to get some 'Real(tm)' #'s so all of us could >quit guessing at things, and have something to point out other than the >code. Build the array and measure the call frequency. I'm already convinced it's better, so I don't have much reason do to more measurements today. >> The code assumes nothing of the sort. My analysis of running time assumes >> that the frequency of calls to timeout or untimeout is >= the number of >> calls to softclock. > >If that changes, then my analysis of the code suggests that the current >scheme could be a deteriment, rather than a help if we implement high >resolution timers, because the time in softclock() becomes dominant >instead of the time in timeout/untimeout. Simply put, if softclock is >called more than timeout/untimeout, then the new system is a lose. (No >matter how many callouts are outstanding.) If we implement high resolution timers, we will probably pay the O(hash chain length) insertion sort price in timeout and schedule a one shot timer for the next event that needs to run meaning that softclock is no longer tied to hz. >Nate -- Justin T. Gibbs =========================================== FreeBSD: Turning PCs into workstations =========================================== From owner-freebsd-current Mon Sep 22 14:31:25 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id OAA22000 for current-outgoing; Mon, 22 Sep 1997 14:31:25 -0700 (PDT) Received: from mexico.brainstorm.eu.org (root@mexico.brainstorm.fr [193.56.58.253]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id OAA21981 for ; Mon, 22 Sep 1997 14:31:18 -0700 (PDT) Received: from brasil.brainstorm.eu.org (brasil.brainstorm.fr [193.56.58.33]) by mexico.brainstorm.eu.org (8.8.4/8.8.4) with ESMTP id XAA28317 for ; Mon, 22 Sep 1997 23:31:13 +0200 Received: (from uucp@localhost) by brasil.brainstorm.eu.org (8.8.6/brasil-1.2) with UUCP id XAA31444 for freebsd-current@FreeBSD.ORG; Mon, 22 Sep 1997 23:30:55 +0200 Received: (from roberto@localhost) by keltia.freenix.fr (8.8.7/keltia-2.10/nospam) id XAA15682; Mon, 22 Sep 1997 23:06:19 +0200 (CEST) Message-ID: <19970922230618.13112@keltia.freenix.fr> Date: Mon, 22 Sep 1997 23:06:18 +0200 From: Ollivier Robert To: "FreeBSD Current Users' list" Subject: Assertion failed in ncr driver Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84 X-Operating-System: FreeBSD 3.0-CURRENT Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk I get the following errors when I use dump to back up my machine. I thought it is was the tags and sets the tags for my disks to 0 in the script but it doesn't seem to make any difference. I have a SC-875 for both sd0 and sd2 (DCAS-34330W & DORS-32160). 203 [22:55] root@keltia:/build/xemacs-20.2# ncrcontrol -i T:L Vendor Device Rev Speed Max Wide Tags 0:0 IBM DCAS-34330W S65A 20.0 20.0 16 8 2:0 IBM DORS-32160 WA6A 20.0 20.0 8 8 4:0 TANDBERG TDC 3600 =08: ? 20.0 ? - ncr0: rev 0x03 int a irq 12 on pci0.11.0 ncr0: minsync=12, maxsync=137, maxoffs=16, 128 dwords burst, large dma fifo ncr0: single-ended, open drain IRQ driver, using on-chip SRAM ncr0: restart (scsi reset). ncr0 scanning for targets 0..6 and 8..15 (V2 pl24 96/12/14) Choosing drivers for scbus configured at 0 scbus0 at ncr0 bus 0 sd is configured at 0 sd0 at scbus0 target 0 lun 0 sd0: type 0 fixed SCSI 2 sd0: Direct-Access sd0: NCR quirks=0x2 sd0: WIDE SCSI (16 bit) enabled sd0: 40.0 MB/s (50 ns, offset 15) 4134MB (8467200 512 byte sectors) sd0: with 8205 cyls, 6 heads, and an average 171 sectors/track sd is configured at 2 sd2 at scbus0 target 2 lun 0 sd2: type 0 fixed SCSI 2 sd2: Direct-Access sd2: NCR quirks=0x2 sd2: 20.0 MB/s (50 ns, offset 15) 2063MB (4226725 512 byte sectors) sd2: with 6703 cyls, 5 heads, and an average 126 sectors/track Any idea why I get these ? assertion "cp" failed: file "../../pci/ncr.c", line 6227 sd0: COMMAND FAILED (4 28) @f0765800. assertion "cp" failed: file "../../pci/ncr.c", line 6227 sd0: COMMAND FAILED (4 28) @f0765c00. DUMP: Date of this level 0 dump: Mon Sep 22 22:54:44 1997 DUMP: Date of last level 0 dump: the epoch DUMP: Dumping /dev/rsd0a (/) to /dev/nrst0 DUMP: mapping (Pass I) [regular files] DUMP: mapping (Pass II) [directories] DUMP: estimated 16777 tape blocks on 0.01 tape(s). DUMP: dumping (Pass III) [directories] DUMP: read error from /dev/rsd0a: Input/output error: [block 716]: count=1024 DUMP: read error from /dev/rsd0a: Input/output error: [sector 716]: count=512 DUMP: read error from /dev/rsd0a: Input/output error: [sector 717]: count=512 DUMP: dumping (Pass IV) [regular files] DUMP: DUMP: 16814 tape blocks on 1 volumes(s) DUMP: finished in 56 seconds, throughput 300 KBytes/sec DUMP: level 0 dump on Mon Sep 22 22:54:44 1997 DUMP: Closing /dev/nrst0 DUMP: DUMP IS DONE DUMP: Date of this level 0 dump: Mon Sep 22 22:55:48 1997 DUMP: Date of last level 0 dump: the epoch DUMP: Dumping /dev/rsd0s2e (/usr) to /dev/nrst0 DUMP: mapping (Pass I) [regular files] DUMP: mapping (Pass II) [directories] DUMP: estimated 92597 tape blocks on 0.07 tape(s). DUMP: dumping (Pass III) [directories] DUMP: read error from /dev/rsd0s2e: Input/output error: [block 1524]: count=1024 DUMP: dumping (Pass IV) [regular files] It fails here: void ncr_int_sir (ncb_p np) { u_char scntl3; u_char chg, ofs, per, fak, wide; u_char num = INB (nc_dsps); ccb_p cp=0; u_long dsa; u_char target = INB (nc_ctest0) & 0x0f; tcb_p tp = &np->target[target]; int i; if (DEBUG_FLAGS & DEBUG_TINY) printf ("I#%d", num); switch (num) { case SIR_SENSE_RESTART: case SIR_STALL_RESTART: break; default: /* ** lookup the ccb */ dsa = INL (nc_dsa); cp = np->ccb; while (cp && (CCB_PHYS (cp, phys) != dsa)) cp = cp->link_ccb; assert (cp); <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< if (!cp) goto out; assert (cp == np->header.cp); if (cp != np->header.cp) goto out; } -- Ollivier ROBERT -=- FreeBSD: There are no limits -=- roberto@keltia.freenix.fr FreeBSD keltia.freenix.fr 3.0-CURRENT #35: Sun Sep 21 19:28:07 CEST 1997 From owner-freebsd-current Mon Sep 22 14:31:54 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id OAA22070 for current-outgoing; Mon, 22 Sep 1997 14:31:54 -0700 (PDT) Received: from mexico.brainstorm.eu.org (mexico.brainstorm.fr [193.56.58.253]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id OAA22063 for ; Mon, 22 Sep 1997 14:31:47 -0700 (PDT) Received: from brasil.brainstorm.eu.org (brasil.brainstorm.fr [193.56.58.33]) by mexico.brainstorm.eu.org (8.8.4/8.8.4) with ESMTP id XAA28314 for ; Mon, 22 Sep 1997 23:31:13 +0200 Received: (from uucp@localhost) by brasil.brainstorm.eu.org (8.8.6/brasil-1.2) with UUCP id XAA31443 for freebsd-current@FreeBSD.ORG; Mon, 22 Sep 1997 23:30:55 +0200 Received: (from roberto@localhost) by keltia.freenix.fr (8.8.7/keltia-2.10/nospam) id WAA15517; Mon, 22 Sep 1997 22:31:33 +0200 (CEST) Message-ID: <19970922223133.65496@keltia.freenix.fr> Date: Mon, 22 Sep 1997 22:31:33 +0200 From: Ollivier Robert To: freebsd-current@FreeBSD.ORG Subject: Re: Netscape 4.03b8 doesn't work after poll/select changes References: <199709221607.JAA05440@rah.star-gate.com> <19970922200629.10690.qmail@ishiboo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84 In-Reply-To: <19970922200629.10690.qmail@ishiboo.com>; from nirva@ishiboo.com on Mon, Sep 22, 1997 at 03:06:29PM -0500 X-Operating-System: FreeBSD 3.0-CURRENT Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk According to nirva@ishiboo.com: > Works for me as well, but it didn't work for me until I upgraded to > XFree33 (I had same results as the lack of window with an older XFree) I'm using 3.3.1... :-) -- Ollivier ROBERT -=- FreeBSD: There are no limits -=- roberto@keltia.freenix.fr FreeBSD keltia.freenix.fr 3.0-CURRENT #35: Sun Sep 21 19:28:07 CEST 1997 From owner-freebsd-current Mon Sep 22 14:32:07 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id OAA22122 for current-outgoing; Mon, 22 Sep 1997 14:32:07 -0700 (PDT) Received: from pluto.plutotech.com (root@mail.plutotech.com [206.168.67.137]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id OAA22006; Mon, 22 Sep 1997 14:31:25 -0700 (PDT) Received: from narnia.plutotech.com (narnia.plutotech.com [206.168.67.130]) by pluto.plutotech.com (8.8.5/8.8.5) with ESMTP id PAA02751; Mon, 22 Sep 1997 15:30:47 -0600 (MDT) Message-Id: <199709222130.PAA02751@pluto.plutotech.com> X-Mailer: exmh version 2.0zeta 7/24/97 To: S ren Schmidt cc: current@freebsd.org (FreeBSD current), gibbs@freebsd.org Subject: Re: Anybody tried to mount a CD lately ?? In-reply-to: Your message of "Mon, 22 Sep 1997 23:15:11 +0200." <199709222115.XAA00327@sos.freebsd.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Date: Mon, 22 Sep 1997 15:30:36 -0600 From: "Justin T. Gibbs" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by hub.freebsd.org id OAA22062 Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > >Gets you a nice panic in bufq_disksort :( > >Oh, well... More information might be helpful assuming you want someone else to fix the bug. >-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- >Søren Schmidt (sos@FreeBSD.org) FreeBSD Core Team > Even more code to hack -- will it ever end >.. -- Justin T. Gibbs =========================================== FreeBSD: Turning PCs into workstations =========================================== From owner-freebsd-current Mon Sep 22 14:32:52 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id OAA22211 for current-outgoing; Mon, 22 Sep 1997 14:32:52 -0700 (PDT) Received: from gratis.grondar.za (gratis.grondar.za [196.7.18.133]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id OAA22204 for ; Mon, 22 Sep 1997 14:32:48 -0700 (PDT) Received: from greenpeace.grondar.za (xdV2BK0v8MoDlHGd5H/x3aO+V+TlKP+/@greenpeace.grondar.za [196.7.18.132]) by gratis.grondar.za (8.8.7/8.8.7) with ESMTP id XAA00900; Mon, 22 Sep 1997 23:30:30 +0200 (SAT) Received: from greenpeace.grondar.za (Mup35OhW4Ellw0Zvej/L8UFWgnevm2op@localhost [127.0.0.1]) by greenpeace.grondar.za (8.8.7/8.8.7) with ESMTP id XAA24125; Mon, 22 Sep 1997 23:30:42 +0200 (SAT) Message-Id: <199709222130.XAA24125@greenpeace.grondar.za> X-Mailer: exmh version 2.0zeta 7/24/97 To: Chuck Robey cc: Ollivier Robert , FreeBSD current Subject: Re: ctm blowup Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 22 Sep 1997 23:30:41 +0200 From: Mark Murray Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Chuck Robey wrote: > Mark told me to blow away my ncvs/src/kerberosIV. I really hate touching > my archive with anything but ctm, but since I was dead in the water, I > took the risk. I've been running a repository and making CTM's for a year or two now. Nice to see I'm getting it right :-). > At least so far, it seems to have worked. I am up to 3673 and going ok so > far. I have an update of /usr/src in progress right now, about half thru, > and it seems ok so far. There was obviously some old cruft (left over from 2.0-R days. That has now been removed from the repository (by Peter). I Will be bringing in some other stuff soon. M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org From owner-freebsd-current Mon Sep 22 14:34:21 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id OAA22363 for current-outgoing; Mon, 22 Sep 1997 14:34:21 -0700 (PDT) Received: from ns.mt.sri.com (SRI-56K-FR.mt.net [206.127.65.42]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id OAA22355 for ; Mon, 22 Sep 1997 14:34:17 -0700 (PDT) Received: from rocky.mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.8.7/8.8.7) with ESMTP id PAA15552; Mon, 22 Sep 1997 15:34:05 -0600 (MDT) Received: (from nate@localhost) by rocky.mt.sri.com (8.7.5/8.7.3) id PAA03250; Mon, 22 Sep 1997 15:34:03 -0600 (MDT) Date: Mon, 22 Sep 1997 15:34:03 -0600 (MDT) Message-Id: <199709222134.PAA03250@rocky.mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: "Justin T. Gibbs" Cc: Nate Williams , Bruce Evans , current@freebsd.org Subject: Re: cvs commit: src/sys/conf files src/sys/dev/vx if_vx.c if_vxreg.h src/sys/i386/apm apm.c src/sys/i386/conf GENERIC files.i386 src/sys/i386/eisa 3c5x9.c aha1742.c aic7770.c bt74x.c eisaconf.c eisaconf.h if_fea.c if_vx_eisa.c src/sys/i386/i386 autoconf.c ... In-Reply-To: <199709222129.PAA02701@pluto.plutotech.com> References: <199709222113.PAA03063@rocky.mt.sri.com> <199709222129.PAA02701@pluto.plutotech.com> X-Mailer: VM 6.29 under 19.15 XEmacs Lucid Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > >If that changes, then my analysis of the code suggests that the current > >scheme could be a deteriment, rather than a help if we implement high > >resolution timers, because the time in softclock() becomes dominant > >instead of the time in timeout/untimeout. Simply put, if softclock is > >called more than timeout/untimeout, then the new system is a lose. (No > >matter how many callouts are outstanding.) > > If we implement high resolution timers, we will probably pay the O(hash > chain length) insertion sort price in timeout and schedule a one shot > timer for the next event that needs to run meaning that softclock is no > longer tied to hz. Then, why implement the darn thing at all, when we could simply add a hash-table to make untimeout more effecient, and not lose backwards compatability with all of the BSD code? I don't see what else the new code buys us that couldn't be done simply and with less overhead (in terms of code and new structure overhead)? Then, we'd be O(n) for timeout, O(1) for softclock, and O(1) for untimeout, which would be the same but with complete backwards compatability. The best of both worlds. :) Nate From owner-freebsd-current Mon Sep 22 14:46:00 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id OAA23319 for current-outgoing; Mon, 22 Sep 1997 14:46:00 -0700 (PDT) Received: from pluto.plutotech.com (root@mail.plutotech.com [206.168.67.137]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id OAA23301 for ; Mon, 22 Sep 1997 14:45:49 -0700 (PDT) Received: from narnia.plutotech.com (narnia.plutotech.com [206.168.67.130]) by pluto.plutotech.com (8.8.5/8.8.5) with ESMTP id PAA03221; Mon, 22 Sep 1997 15:45:28 -0600 (MDT) Message-Id: <199709222145.PAA03221@pluto.plutotech.com> X-Mailer: exmh version 2.0zeta 7/24/97 To: Nate Williams cc: "Justin T. Gibbs" , Bruce Evans , current@freebsd.org Subject: Re: cvs commit: src/sys/conf files src/sys/dev/vx if_vx.c if_vxreg.h src/sys/i386/apm apm.c src/sys/i386/conf GENERIC files.i386 src/sys/i386/eisa 3c5x9.c aha1742.c aic7770.c bt74x.c eisaconf.c eisaconf.h if_fea.c if_vx_eisa.c src/sys/i386/i386 autoconf.c ... In-reply-to: Your message of "Mon, 22 Sep 1997 15:34:03 MDT." <199709222134.PAA03250@rocky.mt.sri.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 22 Sep 1997 15:45:17 -0600 From: "Justin T. Gibbs" Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >> If we implement high resolution timers, we will probably pay the O(hash >> chain length) insertion sort price in timeout and schedule a one shot >> timer for the next event that needs to run meaning that softclock is no >> longer tied to hz. > >Then, why implement the darn thing at all, when we could simply add a >hash-table to make untimeout more effecient, and not lose backwards >compatability with all of the BSD code? I don't see what else the new >code buys us that couldn't be done simply and with less overhead (in >terms of code and new structure overhead)? > >Then, we'd be O(n) for timeout, O(1) for softclock, and O(1) for >untimeout, which would be the same but with complete backwards >compatability. The best of both worlds. :) I don't want to pay O(n) for anything. Perhaps I'm greedy. I can perform upwards of 200 (real life, seek bound) transactions a second with bonnie on a single Atlas II with the CAM code. I can perform even more if I'm doing sequential reads. I can pretty much sustain that rate to multiple drives meaning even a higher rate of timeout/ untimeout calls. Going from 2 * O(n) to O(n) is not anywhere near the same as going to 2 * O(1). Even in the high resolution timer case, the overhead is still much smaller: O(hash chain) + O(1) ~= 2 * O(1) >Nate -- Justin T. Gibbs =========================================== FreeBSD: Turning PCs into workstations =========================================== From owner-freebsd-current Mon Sep 22 14:51:23 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id OAA23800 for current-outgoing; Mon, 22 Sep 1997 14:51:23 -0700 (PDT) Received: from ns.mt.sri.com (SRI-56K-FR.mt.net [206.127.65.42]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id OAA23789 for ; Mon, 22 Sep 1997 14:51:17 -0700 (PDT) Received: from rocky.mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.8.7/8.8.7) with ESMTP id PAA15650; Mon, 22 Sep 1997 15:51:05 -0600 (MDT) Received: (from nate@localhost) by rocky.mt.sri.com (8.7.5/8.7.3) id PAA03325; Mon, 22 Sep 1997 15:51:03 -0600 (MDT) Date: Mon, 22 Sep 1997 15:51:03 -0600 (MDT) Message-Id: <199709222151.PAA03325@rocky.mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: "Justin T. Gibbs" Cc: Nate Williams , Bruce Evans , current@freebsd.org Subject: Re: cvs commit: src/sys/conf files src/sys/dev/vx if_vx.c if_vxreg.h src/sys/i386/apm apm.c src/sys/i386/conf GENERIC files.i386 src/sys/i386/eisa 3c5x9.c aha1742.c aic7770.c bt74x.c eisaconf.c eisaconf.h if_fea.c if_vx_eisa.c src/sys/i386/i386 autoconf.c ... In-Reply-To: <199709222145.PAA03221@pluto.plutotech.com> References: <199709222134.PAA03250@rocky.mt.sri.com> <199709222145.PAA03221@pluto.plutotech.com> X-Mailer: VM 6.29 under 19.15 XEmacs Lucid Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > >> If we implement high resolution timers, we will probably pay the O(hash > >> chain length) insertion sort price in timeout and schedule a one shot > >> timer for the next event that needs to run meaning that softclock is no > >> longer tied to hz. > > > >Then, why implement the darn thing at all, when we could simply add a > >hash-table to make untimeout more effecient, and not lose backwards > >compatability with all of the BSD code? I don't see what else the new > >code buys us that couldn't be done simply and with less overhead (in > >terms of code and new structure overhead)? > > > >Then, we'd be O(n) for timeout, O(1) for softclock, and O(1) for > >untimeout, which would be the same but with complete backwards > >compatability. The best of both worlds. :) > > I don't want to pay O(n) for anything. O(hash chain length) ~= O(n). > Perhaps I'm greedy. I can > perform upwards of 200 (real life, seek bound) transactions a second > with bonnie on a single Atlas II with the CAM code. I can perform > even more if I'm doing sequential reads. I can pretty much sustain > that rate to multiple drives meaning even a higher rate of timeout/ > untimeout calls. Going from 2 * O(n) to O(n) is not anywhere near > the same as going to 2 * O(1). See above. You aren't paying anything more for the 'high-resolution' timer case with the old code (with untimeout hash-table, not yet implemented) vs. the new code (with ordered insertion in the hash-table list, not yet implemented). Nate From owner-freebsd-current Mon Sep 22 14:56:25 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id OAA24229 for current-outgoing; Mon, 22 Sep 1997 14:56:25 -0700 (PDT) Received: from pluto.plutotech.com (root@mail.plutotech.com [206.168.67.137]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id OAA24215 for ; Mon, 22 Sep 1997 14:56:11 -0700 (PDT) Received: from narnia.plutotech.com (narnia.plutotech.com [206.168.67.130]) by pluto.plutotech.com (8.8.5/8.8.5) with ESMTP id PAA03743; Mon, 22 Sep 1997 15:55:57 -0600 (MDT) Message-Id: <199709222155.PAA03743@pluto.plutotech.com> X-Mailer: exmh version 2.0zeta 7/24/97 To: Nate Williams cc: "Justin T. Gibbs" , Bruce Evans , current@freebsd.org Subject: Re: cvs commit: src/sys/conf files src/sys/dev/vx if_vx.c if_vxreg.h src/sys/i386/apm apm.c src/sys/i386/conf GENERIC files.i386 src/sys/i386/eisa 3c5x9.c aha1742.c aic7770.c bt74x.c eisaconf.c eisaconf.h if_fea.c if_vx_eisa.c src/sys/i386/i386 autoconf.c ... In-reply-to: Your message of "Mon, 22 Sep 1997 15:51:03 MDT." <199709222151.PAA03325@rocky.mt.sri.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 22 Sep 1997 15:55:46 -0600 From: "Justin T. Gibbs" Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >> I don't want to pay O(n) for anything. > >O(hash chain length) ~= O(n). Nope. It has worst case running time of O(n) but average running time of O(h) where h << n. Perform the measurements to prove this to yourself if you want. >See above. You aren't paying anything more for the 'high-resolution' >timer case with the old code (with untimeout hash-table, not yet >implemented) vs. the new code (with ordered insertion in the hash-table >list, not yet implemented). With ordered insertion in timeout() (which is what I'd guess we'd do to support HRTs), softclock becomes O(callouts due), the same as the old scheme, which means the new implementation is always faster than the old one. >Nate -- Justin T. Gibbs =========================================== FreeBSD: Turning PCs into workstations =========================================== From owner-freebsd-current Mon Sep 22 15:25:12 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id PAA25692 for current-outgoing; Mon, 22 Sep 1997 15:25:12 -0700 (PDT) Received: from critter.freebsd.dk (critter.freebsd.dk [195.8.129.26]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id PAA25684 for ; Mon, 22 Sep 1997 15:25:07 -0700 (PDT) Received: from critter.freebsd.dk (localhost.cybercity.dk [127.0.0.1]) by critter.freebsd.dk (8.8.7/8.8.7) with ESMTP id XAA01350; Mon, 22 Sep 1997 23:59:05 +0200 (CEST) To: Terry Lambert cc: nate@mt.sri.com (Nate Williams), gibbs@plutotech.com, current@FreeBSD.ORG Subject: Re: cvs commit: src/sys/conf files src/sys/dev/vx if_vx.c if_vxreg.h src/sys/i386/apm apm.c src/sys/i386/conf GENERIC files.i386 In-reply-to: Your message of "Mon, 22 Sep 1997 20:31:32 -0000." <199709222031.NAA21421@usr06.primenet.com> Date: Mon, 22 Sep 1997 23:59:05 +0200 Message-ID: <1348.874965545@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk In message <199709222031.NAA21421@usr06.primenet.com>, Terry Lambert writes: >[lots deleted] > >Better to take the fuzz where you can afford fuzz, I say. > > Terry Lambert > terry@lambert.org On this last item you're right, we take it in the mailing lists, rather than in our sources ;-) -- Poul-Henning Kamp FreeBSD coreteam member phk@FreeBSD.ORG "Real hackers run -current on their laptop." From owner-freebsd-current Mon Sep 22 15:33:21 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id PAA26463 for current-outgoing; Mon, 22 Sep 1997 15:33:21 -0700 (PDT) Received: from cabri.obs-besancon.fr (cabri.obs-besancon.fr [193.52.184.3]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id PAA26447 for ; Mon, 22 Sep 1997 15:33:12 -0700 (PDT) Received: by cabri.obs-besancon.fr (5.57/Ultrix3.0-C) id AA07603; Tue, 23 Sep 97 00:34:07 +0100 Date: Tue, 23 Sep 97 00:34:07 +0100 Message-Id: <9709222334.AA07603@cabri.obs-besancon.fr> From: Jean-Marc Zucconi To: roberto@keltia.freenix.fr Cc: freebsd-current@freefall.freebsd.org In-Reply-To: <19970922212907.40124@keltia.freenix.fr> (message from Ollivier Robert on Mon, 22 Sep 1997 21:29:07 +0200) Subject: Re: ctm blowup X-Mailer: Emacs Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >>>>> Ollivier Robert writes: > According to Chuck Robey: >> Anyone know what that was, or how I could get ctm back on track? > Surprising, I'm also at 3670 and didn't see this message... I have cvs-cur > as usual and the crypto stuff from ftp.internat.freebsd.org. Very, very surprising, because I got the message, using "normal" cvs-cur and int-cvs-cur (I am at #87)!! Jean-Marc _____________________________________________________________________________ Jean-Marc Zucconi Observatoire de Besancon F 25010 Besancon cedex PGP Key: finger jmz@cabri.obs-besancon.fr From owner-freebsd-current Mon Sep 22 15:41:32 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id PAA27104 for current-outgoing; Mon, 22 Sep 1997 15:41:32 -0700 (PDT) Received: from ns.mt.sri.com (SRI-56K-FR.mt.net [206.127.65.42]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id PAA27094 for ; Mon, 22 Sep 1997 15:41:27 -0700 (PDT) Received: from rocky.mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.8.7/8.8.7) with ESMTP id QAA16029; Mon, 22 Sep 1997 16:41:07 -0600 (MDT) Received: (from nate@localhost) by rocky.mt.sri.com (8.7.5/8.7.3) id QAA04073; Mon, 22 Sep 1997 16:41:04 -0600 (MDT) Date: Mon, 22 Sep 1997 16:41:04 -0600 (MDT) Message-Id: <199709222241.QAA04073@rocky.mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: "Justin T. Gibbs" Cc: Nate Williams , Bruce Evans , current@freebsd.org Subject: Re: cvs commit: src/sys/conf files src/sys/dev/vx if_vx.c if_vxreg.h src/sys/i386/apm apm.c src/sys/i386/conf GENERIC files.i386 src/sys/i386/eisa 3c5x9.c aha1742.c aic7770.c bt74x.c eisaconf.c eisaconf.h if_fea.c if_vx_eisa.c src/sys/i386/i386 autoconf.c ... In-Reply-To: <199709222155.PAA03743@pluto.plutotech.com> References: <199709222151.PAA03325@rocky.mt.sri.com> <199709222155.PAA03743@pluto.plutotech.com> X-Mailer: VM 6.29 under 19.15 XEmacs Lucid Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > >> I don't want to pay O(n) for anything. > > > >O(hash chain length) ~= O(n). > > Nope. It has worst case running time of O(n) but average running time of > O(h) where h << n. Assuming that the average is one element on the list, yes. > >See above. You aren't paying anything more for the 'high-resolution' > >timer case with the old code (with untimeout hash-table, not yet > >implemented) vs. the new code (with ordered insertion in the hash-table > >list, not yet implemented). > > With ordered insertion in timeout() (which is what I'd guess we'd do to > support HRTs), softclock becomes O(callouts due), the same as the old > scheme, which means the new implementation is always faster than the > old one. Only for scheduling timeouts, and I still don't buy that the advantage is *that* great to make us completely un-backwards compatible with old BSD systems. But, I'll shutup now until I have a better solution. Nate From owner-freebsd-current Mon Sep 22 15:46:03 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id PAA27345 for current-outgoing; Mon, 22 Sep 1997 15:46:03 -0700 (PDT) Received: from pluto.plutotech.com (root@mail.plutotech.com [206.168.67.137]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id PAA27339 for ; Mon, 22 Sep 1997 15:45:57 -0700 (PDT) Received: from narnia.plutotech.com (narnia.plutotech.com [206.168.67.130]) by pluto.plutotech.com (8.8.5/8.8.5) with ESMTP id QAA05197; Mon, 22 Sep 1997 16:45:41 -0600 (MDT) Message-Id: <199709222245.QAA05197@pluto.plutotech.com> X-Mailer: exmh version 2.0zeta 7/24/97 To: Nate Williams cc: "Justin T. Gibbs" , Bruce Evans , current@freebsd.org Subject: Re: cvs commit: src/sys/conf files src/sys/dev/vx if_vx.c if_vxreg.h src/sys/i386/apm apm.c src/sys/i386/conf GENERIC files.i386 src/sys/i386/eisa 3c5x9.c aha1742.c aic7770.c bt74x.c eisaconf.c eisaconf.h if_fea.c if_vx_eisa.c src/sys/i386/i386 autoconf.c ... In-reply-to: Your message of "Mon, 22 Sep 1997 16:41:04 MDT." <199709222241.QAA04073@rocky.mt.sri.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 22 Sep 1997 16:45:30 -0600 From: "Justin T. Gibbs" Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >> Nope. It has worst case running time of O(n) but average running time of >> O(h) where h << n. > >Assuming that the average is one element on the list, yes. No, assuming that h is smaller than n by a bit. Even if it's 10 or 20, or 50 that's not much work to do. >Only for scheduling timeouts, and I still don't buy that the advantage >is *that* great to make us completely un-backwards compatible with old >BSD systems. But, I'll shutup now until I have a better solution. Fair enough. >Nate -- Justin T. Gibbs =========================================== FreeBSD: Turning PCs into workstations =========================================== From owner-freebsd-current Mon Sep 22 16:08:53 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id QAA28720 for current-outgoing; Mon, 22 Sep 1997 16:08:53 -0700 (PDT) Received: from pluto.plutotech.com (root@mail.plutotech.com [206.168.67.137]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id QAA28698 for ; Mon, 22 Sep 1997 16:08:45 -0700 (PDT) Received: from narnia.plutotech.com (narnia.plutotech.com [206.168.67.130]) by pluto.plutotech.com (8.8.5/8.8.5) with ESMTP id RAA05833; Mon, 22 Sep 1997 17:08:34 -0600 (MDT) Message-Id: <199709222308.RAA05833@pluto.plutotech.com> X-Mailer: exmh version 2.0zeta 7/24/97 To: dave adkins cc: current@FreeBSD.ORG Subject: Re: is wcd.c missing a bufq_init call in wcdattach In-reply-to: Your message of "Mon, 22 Sep 1997 15:31:37 CDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 22 Sep 1997 17:08:23 -0600 From: "Justin T. Gibbs" Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > >Hi, > >I panic'd in bufqdisksort during mount_cd9660 (current 970922). It looks >like the it's a result of an uninitialized queue. I noticed that the wcd >stuff didn't seem to initialize the queue (wcd[unit]->buf_queue). Adding a >bufq_init call to wdcstrategy seemed to fix the problem. > >dave adkins I just committed a fix for this. Thanks for pointing out the problem. I don't happen to have any ATAPI cdrom drives here. -- Justin T. Gibbs =========================================== FreeBSD: Turning PCs into workstations =========================================== From owner-freebsd-current Mon Sep 22 16:26:22 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id QAA29839 for current-outgoing; Mon, 22 Sep 1997 16:26:22 -0700 (PDT) Received: from Kitten.mcs.com (Kitten.mcs.com [192.160.127.90]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id QAA29830 for ; Mon, 22 Sep 1997 16:26:17 -0700 (PDT) Received: from Mars.mcs.net (karl@Mars.mcs.net [192.160.127.85]) by Kitten.mcs.com (8.8.5/8.8.2) with ESMTP id SAA05582 for ; Mon, 22 Sep 1997 18:26:16 -0500 (CDT) Received: (from karl@localhost) by Mars.mcs.net (8.8.7/8.8.2) id SAA00991; Mon, 22 Sep 1997 18:26:16 -0500 (CDT) Message-ID: <19970922182615.37607@Mars.Mcs.Net> Date: Mon, 22 Sep 1997 18:26:15 -0500 From: Karl Denninger To: current@freebsd.org Subject: DE driver changes Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.64 Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi folks, Remember me asking about the funky de driver messages having to do with transmitter underflows? Well, something has definitely changed. I just updated a system which had DE cards in it (2) which was *NOT* giving these messages from a kernel which was built in mid-June to one which is current. The messages started. In fact, I'm getting these now on both cards. I looked quickly at the de driver revision history, and it looks like major changes were made to the code -- and somewhere in there, this started. Anyone got any ideas what's going on? This is a Natoma chipset board, by the way. -- -- Karl Denninger (karl@MCS.Net)| MCSNet - Serving Chicagoland and Wisconsin http://www.mcs.net/~karl | T1's from $600 monthly to FULL DS-3 Service | NEW! K56Flex modem support is now available Voice: [+1 312 803-MCS1 x219]| 56kbps DIGITAL ISDN DOV on analog lines! Fax: [+1 312 803-4929] | 2 FULL DS-3 Internet links; 400Mbps B/W Internal From owner-freebsd-current Mon Sep 22 16:52:27 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id QAA01468 for current-outgoing; Mon, 22 Sep 1997 16:52:27 -0700 (PDT) Received: from time.cdrom.com (root@time.cdrom.com [204.216.27.226]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id QAA01460 for ; Mon, 22 Sep 1997 16:52:23 -0700 (PDT) Received: from time.cdrom.com (jkh@localhost.cdrom.com [127.0.0.1]) by time.cdrom.com (8.8.7/8.6.9) with ESMTP id QAA02830; Mon, 22 Sep 1997 16:52:15 -0700 (PDT) To: Nate Williams cc: "Justin T. Gibbs" , Bruce Evans , current@FreeBSD.ORG Subject: Re: cvs commit: src/sys/conf files src/sys/dev/vx if_vx.c if_vxreg.h src/sys/i386/apm apm.c src/sys/i386/conf GENERIC files.i386 src/sys/i386/eisa 3c5x9.c aha1742.c aic7770.c bt74x.c eisaconf.c eisaconf.h if_fea.c if_vx_eisa.c src/sys/i386/i386 autoconf.c ... In-reply-to: Your message of "Mon, 22 Sep 1997 16:41:04 MDT." <199709222241.QAA04073@rocky.mt.sri.com> Date: Mon, 22 Sep 1997 16:52:15 -0700 Message-ID: <2826.874972335@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > BSD systems. But, I'll shutup now until I have a better solution. Oh gosh, really? I was so looking forward to seeing this discussion drag out over another 300 messages or so. :-) Jordan From owner-freebsd-current Mon Sep 22 17:42:37 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id RAA04509 for current-outgoing; Mon, 22 Sep 1997 17:42:37 -0700 (PDT) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id RAA04502 for ; Mon, 22 Sep 1997 17:42:35 -0700 (PDT) Received: (from daemon@localhost) by alpo.whistle.com (8.8.5/8.8.5) id QAA21362; Mon, 22 Sep 1997 16:59:15 -0700 (PDT) Received: from current1.whistle.com(207.76.205.22) via SMTP by alpo.whistle.com, id smtpd021360; Mon Sep 22 23:59:11 1997 Message-ID: <34270EA7.1CFBAE39@whistle.com> Date: Mon, 22 Sep 1997 17:34:47 -0700 From: Julian Elischer Organization: Whistle Communications X-Mailer: Mozilla 3.0Gold (X11; I; FreeBSD 2.2-CURRENT i386) MIME-Version: 1.0 To: Poul-Henning Kamp CC: Nate Williams , "Justin T. Gibbs" , Bruce Evans , current@FreeBSD.ORG Subject: Re: cvs commit: src/sys/conf files src/sys/dev/vx if_vx.c if_vxreg.h src/sys/i386/apm apm.c src/sys/i386/conf GENERIC files.i386 src/sys/i386/eisa 3c5x9.c aha1742.c aic7770.c bt74x.c eisaconf.c eisaconf.h if_fea.c if_vx_eisa.c src/sys/i386/i386 a References: <612.874952557@critter.freebsd.dk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Poul-Henning Kamp wrote: > > Anyway, it shouldn't be to hard to make either of the old and the new > implementations available under a compile option, the new calling > API is a a superset of the old, isn't it ? > NO, which is what I'm complaining about.. I thonk it's a good idea, but since it would ha ve been so simple to keep a compatible API and extend, it, it seems a foolish thing to do to NOT do that.. julian From owner-freebsd-current Mon Sep 22 18:45:18 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id SAA07007 for current-outgoing; Mon, 22 Sep 1997 18:45:18 -0700 (PDT) Received: from usr01.primenet.com (tlambert@usr01.primenet.com [206.165.6.201]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id SAA07000 for ; Mon, 22 Sep 1997 18:45:12 -0700 (PDT) Received: (from tlambert@localhost) by usr01.primenet.com (8.8.5/8.8.5) id SAA27671; Mon, 22 Sep 1997 18:42:06 -0700 (MST) From: Terry Lambert Message-Id: <199709230142.SAA27671@usr01.primenet.com> Subject: Re: cvs commit: src/sys/conf files src/sys/dev/vx if_vx.c if_vxreg.h src/sys/i386/apm apm.c src/sys/i386/conf GENERIC files.i386 To: phk@critter.freebsd.dk (Poul-Henning Kamp) Date: Tue, 23 Sep 1997 01:42:05 +0000 (GMT) Cc: tlambert@primenet.com, nate@mt.sri.com, gibbs@plutotech.com, current@FreeBSD.ORG In-Reply-To: <1348.874965545@critter.freebsd.dk> from "Poul-Henning Kamp" at Sep 22, 97 11:59:05 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > >[lots deleted] > > > >Better to take the fuzz where you can afford fuzz, I say. > > On this last item you're right, we take it in the mailing lists, > rather than in our sources ;-) Heh. But seriously, timers care when they expire, not when they are enqueued. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-current Mon Sep 22 18:58:14 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id SAA07641 for current-outgoing; Mon, 22 Sep 1997 18:58:14 -0700 (PDT) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id SAA07636 for ; Mon, 22 Sep 1997 18:58:10 -0700 (PDT) Received: (from daemon@localhost) by alpo.whistle.com (8.8.5/8.8.5) id SAA23467; Mon, 22 Sep 1997 18:15:32 -0700 (PDT) Received: from current1.whistle.com(207.76.205.22) via SMTP by alpo.whistle.com, id smtpd023459; Tue Sep 23 01:15:21 1997 Message-ID: <342720B5.3F54BC7E@whistle.com> Date: Mon, 22 Sep 1997 18:51:49 -0700 From: Julian Elischer Organization: Whistle Communications X-Mailer: Mozilla 3.0Gold (X11; I; FreeBSD 2.2-CURRENT i386) MIME-Version: 1.0 To: "Justin T. Gibbs" CC: Nate Williams , Bruce Evans , current@FreeBSD.ORG Subject: Re: cvs commit: src/sys/conf files src/sys/dev/vx if_vx.c if_vxreg.h src/sys/i386/apm apm.c src/sys/i386/conf GENERIC files.i386 src/sys/i386/eisa 3c5x9.c aha1742.c aic7770.c bt74x.c eisaconf.c eisaconf.h if_fea.c if_vx_eisa.c src/sys/i386/i386 a References: <199709222145.PAA03221@pluto.plutotech.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Justin T. Gibbs wrote: > > I don't want to pay O(n) for anything. Perhaps I'm greedy. wow what a fight. best fun I 've had all week, I think that the internal organisation is an improvement, and could probably be improved further. there should be compatible O(n)(or better) interfaces kept. for 3rd party software for at least a while. The new interfaces should have different names. From owner-freebsd-current Mon Sep 22 19:15:02 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id TAA08392 for current-outgoing; Mon, 22 Sep 1997 19:15:02 -0700 (PDT) Received: from usr01.primenet.com (tlambert@usr01.primenet.com [206.165.6.201]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id TAA08378 for ; Mon, 22 Sep 1997 19:14:58 -0700 (PDT) Received: (from tlambert@localhost) by usr01.primenet.com (8.8.5/8.8.5) id TAA29871; Mon, 22 Sep 1997 19:14:33 -0700 (MST) From: Terry Lambert Message-Id: <199709230214.TAA29871@usr01.primenet.com> Subject: Re: cvs commit: src/sys/conf files src/sys/dev/vx if_vx.c if_vxreg.h src/sys/i386/apm apm.c src/sys/i386/conf GENERIC files.i386 To: gibbs@plutotech.com (Justin T. Gibbs) Date: Tue, 23 Sep 1997 02:14:32 +0000 (GMT) Cc: nate@mt.sri.com, gibbs@plutotech.com, bde@zeta.org.au, current@FreeBSD.ORG In-Reply-To: <199709222104.PAA01993@pluto.plutotech.com> from "Justin T. Gibbs" at Sep 22, 97 03:04:20 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > >Sure they do. If you have a bunch of timeout calls, and the untimeouts > >for them don't occur until *after* softclock, you have lots of entries > >to walk through. > > And timeout and untimeout would have just as many (most likely more since > the hash table isn't very full) to walk through each time. The untimeout can easily be made O(1); just keep a backlink. This is what you are doing, isn't it? For timeouts that live across softclock calls, as Nate is suggesting, the list is traversed and the entry counts against the implementation based on how many softclocks it lives across, on average. For ordered insertion, the entry is counted against, once, at insertion time. So the question to as is "how many softclocks does the average timer entry live across?". If the answer is more than one, then it is a net loss. If the answer is less than one, it's a net gain. From a cursory perusal, it seems to me that the answer must be "more than one". As far as non-deterministic insertion tine, as I said before, unless you are using delta intervals, the value for the timeout will be invariant across the list length. Since this is true, then it doesn't matter how long it takes: insertion can *be* indeterminate without ill effects. > The code assumes nothing of the sort. My analysis of running time assumes > that the frequency of calls to timeout or untimeout is >= the number of > calls to softclock. You mean "the frequency of calls to timeout minus the calls untimeout is < the number of calls to softclock". The point is to obtain a relatively empty list at softclock, right? > If we decide to do high resolution timers, the > analysis may change as will most likely the implementation although > probably not by much. I agree. The implementation is very close to whats needed for either approaches model. Can you explain the insertion indeterminancy problem? Is it simply that you want to take the hit at softclock rather than whereever the timeout() is scheduled? If so, I have a compromise suggestion, since the implication is that timers *will* live across multiple softclocks (that they are, indeed, measured in units of "number of softclocks"): Queue the entry for ordered insertion when timeout() is called, but delay the ordered insertion until softclock(). This allows you to take the traversal hit once: at the same time you are timing out timers, in fact, so it's a non-hit relative to your current algorithm. In fact it's O(n/2) instead of O(n), and then only in the case that you have timers to insert. This returns your insertion to O(1), removal is O(1), and timer list traversal is O(1) for most cases, where the timer inerval is some multiple of the softclock interval. Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-current Mon Sep 22 19:16:46 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id TAA08506 for current-outgoing; Mon, 22 Sep 1997 19:16:46 -0700 (PDT) Received: from usr01.primenet.com (tlambert@usr01.primenet.com [206.165.6.201]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id TAA08501 for ; Mon, 22 Sep 1997 19:16:44 -0700 (PDT) Received: (from tlambert@localhost) by usr01.primenet.com (8.8.5/8.8.5) id TAA00163; Mon, 22 Sep 1997 19:16:25 -0700 (MST) From: Terry Lambert Message-Id: <199709230216.TAA00163@usr01.primenet.com> Subject: Re: callouts in CAM (was Re: cvs commit:) To: gibbs@plutotech.com (Justin T. Gibbs) Date: Tue, 23 Sep 1997 02:16:24 +0000 (GMT) Cc: nate@mt.sri.com, gibbs@plutotech.com, bde@zeta.org.au, current@FreeBSD.ORG In-Reply-To: <199709222106.PAA02060@pluto.plutotech.com> from "Justin T. Gibbs" at Sep 22, 97 03:06:21 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > >Fair enough. Does the new scheme allow for dynamic allocation of > >callouts? I noticed that was on the TODO list for the original authors. > > Yes, but it's still not implemented. I think that we should push this > onto the client instead of attempting to do some kind of low water-mark > early allocation. In other words, allocate a fairly small initial pool > for most applications and then have systems like CAM allocate a callout > on an as-needed basis. You don't think it should be watermarked? I am a fan of low watermark based allocation scheduling (not necessarily immediate allocation, unless the pool empties). Mostly, I like this because the pools can be per CPU, and thus you don't take a global resource lock in the SMP case. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-current Mon Sep 22 19:19:05 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id TAA08588 for current-outgoing; Mon, 22 Sep 1997 19:19:05 -0700 (PDT) Received: from usr01.primenet.com (tlambert@usr01.primenet.com [206.165.6.201]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id TAA08583 for ; Mon, 22 Sep 1997 19:19:02 -0700 (PDT) Received: (from tlambert@localhost) by usr01.primenet.com (8.8.5/8.8.5) id TAA00259; Mon, 22 Sep 1997 19:18:48 -0700 (MST) From: Terry Lambert Message-Id: <199709230218.TAA00259@usr01.primenet.com> Subject: Re: cvs commit: src/sys/conf files src/sys/dev/vx if_vx.c if_vxreg.h src/sys/i386/apm apm.c src/sys/i386/conf GENERIC files.i386 To: nate@mt.sri.com (Nate Williams) Date: Tue, 23 Sep 1997 02:18:47 +0000 (GMT) Cc: gibbs@plutotech.com, nate@mt.sri.com, bde@zeta.org.au, current@FreeBSD.ORG In-Reply-To: <199709222113.PAA03063@rocky.mt.sri.com> from "Nate Williams" at Sep 22, 97 03:13:52 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > The code assumes nothing of the sort. My analysis of running time assumes > > that the frequency of calls to timeout or untimeout is >= the number of > > calls to softclock. > > If that changes, then my analysis of the code suggests that the current > scheme could be a deteriment, rather than a help if we implement high > resolution timers, because the time in softclock() becomes dominant > instead of the time in timeout/untimeout. Simply put, if softclock is > called more than timeout/untimeout, then the new system is a lose. (No > matter how many callouts are outstanding.) I think queueing the sorted insertion handles all of these cases (see other posting). It makes calling timeout() O(1), calling untimeout O(1), and leaves the traversal O(1 + (number of new timers)/2). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-current Mon Sep 22 19:21:24 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id TAA08721 for current-outgoing; Mon, 22 Sep 1997 19:21:24 -0700 (PDT) Received: from usr01.primenet.com (tlambert@usr01.primenet.com [206.165.6.201]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id TAA08712 for ; Mon, 22 Sep 1997 19:21:18 -0700 (PDT) Received: (from tlambert@localhost) by usr01.primenet.com (8.8.5/8.8.5) id TAA00363; Mon, 22 Sep 1997 19:20:55 -0700 (MST) From: Terry Lambert Message-Id: <199709230220.TAA00363@usr01.primenet.com> Subject: Re: cvs commit: src/sys/conf files src/sys/dev/vx if_vx.c if_vxreg.h src/sys/i386/apm apm.c src/sys/i386/conf GENERIC files.i386 To: gibbs@plutotech.com (Justin T. Gibbs) Date: Tue, 23 Sep 1997 02:20:53 +0000 (GMT) Cc: nate@mt.sri.com, gibbs@plutotech.com, bde@zeta.org.au, current@FreeBSD.ORG In-Reply-To: <199709222129.PAA02701@pluto.plutotech.com> from "Justin T. Gibbs" at Sep 22, 97 03:29:05 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > If we implement high resolution timers, we will probably pay the O(hash > chain length) insertion sort price in timeout and schedule a one shot > timer for the next event that needs to run meaning that softclock is no > longer tied to hz. Yes. This is a happy circumstance, in my book, as it will abstract the idea of timer services from the underlying hardware providing the timing events... does wonders for cFreeBSD console code portability to other platforms. 8-). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-current Mon Sep 22 19:27:08 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id TAA09057 for current-outgoing; Mon, 22 Sep 1997 19:27:08 -0700 (PDT) Received: from usr01.primenet.com (tlambert@usr01.primenet.com [206.165.6.201]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id TAA09050 for ; Mon, 22 Sep 1997 19:27:06 -0700 (PDT) Received: (from tlambert@localhost) by usr01.primenet.com (8.8.5/8.8.5) id TAA00690; Mon, 22 Sep 1997 19:24:22 -0700 (MST) From: Terry Lambert Message-Id: <199709230224.TAA00690@usr01.primenet.com> Subject: Re: cvs commit: src/sys/conf files src/sys/dev/vx if_vx.c if_vxreg.h src/sys/i386/apm apm.c src/sys/i386/conf GENERIC files.i386 To: julian@whistle.com (Julian Elischer) Date: Tue, 23 Sep 1997 02:24:21 +0000 (GMT) Cc: phk@critter.freebsd.dk, nate@mt.sri.com, gibbs@plutotech.com, bde@zeta.org.au, current@FreeBSD.ORG In-Reply-To: <34270EA7.1CFBAE39@whistle.com> from "Julian Elischer" at Sep 22, 97 05:34:47 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > Anyway, it shouldn't be to hard to make either of the old and the new > > implementations available under a compile option, the new calling > > API is a a superset of the old, isn't it ? > > NO, which is what I'm complaining about.. > I thonk it's a good idea, but since it would ha ve been so simple to > keep a compatible API and extend, it, it seems a foolish thing to do > to NOT do that.. I am now in favor of the new API, now that I believe it can be taken to, effectively, O(1), O(1), O(1) for the most common cases. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-current Mon Sep 22 19:32:34 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id TAA09404 for current-outgoing; Mon, 22 Sep 1997 19:32:34 -0700 (PDT) Received: from pluto.plutotech.com (root@mail.plutotech.com [206.168.67.137]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id TAA09399 for ; Mon, 22 Sep 1997 19:32:32 -0700 (PDT) Received: from narnia.plutotech.com (narnia.plutotech.com [206.168.67.130]) by pluto.plutotech.com (8.8.5/8.8.5) with ESMTP id UAA09928; Mon, 22 Sep 1997 20:32:10 -0600 (MDT) Message-Id: <199709230232.UAA09928@pluto.plutotech.com> X-Mailer: exmh version 2.0zeta 7/24/97 To: Terry Lambert cc: gibbs@plutotech.com (Justin T. Gibbs), nate@mt.sri.com, bde@zeta.org.au, current@FreeBSD.ORG Subject: Re: cvs commit: src/sys/conf files src/sys/dev/vx if_vx.c if_vxreg.h src/sys/i386/apm apm.c src/sys/i386/conf GENERIC files.i386 In-reply-to: Your message of "Tue, 23 Sep 1997 02:14:32 -0000." <199709230214.TAA29871@usr01.primenet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 22 Sep 1997 20:31:59 -0600 From: "Justin T. Gibbs" Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >> And timeout and untimeout would have just as many (most likely more since >> the hash table isn't very full) to walk through each time. > >The untimeout can easily be made O(1); just keep a backlink. This >is what you are doing, isn't it? Go read the code. >For timeouts that live across softclock calls, as Nate is suggesting, >the list is traversed and the entry counts against the implementation >based on how many softclocks it lives across, on average. For ordered >insertion, the entry is counted against, once, at insertion time. > >So the question to as is "how many softclocks does the average timer >entry live across?". Go read the code. An entry will only have it's count decremented if, during it's lifetime, softclock traverses the list of callouts in it's hash bucket. It may take numerous calls to softclock before it touches the bucket where a particular callout is placed. >If the answer is more than one, then it is a net loss. If the answer >is less than one, it's a net gain. From a cursory perusal, it seems to >me that the answer must be "more than one". What cursory perusal? You obviously haven't read the code or the paper. >> The code assumes nothing of the sort. My analysis of running time assumes >> that the frequency of calls to timeout or untimeout is >= the number of >> calls to softclock. > >You mean "the frequency of calls to timeout minus the calls untimeout >is < the number of calls to softclock". The point is to obtain a >relatively empty list at softclock, right? Nope. >Can you explain the insertion indeterminancy problem? Is it simply >that you want to take the hit at softclock rather than whereever the >timeout() is scheduled? Yup. >If so, I have a compromise suggestion, since the implication is that >timers *will* live across multiple softclocks (that they are, indeed, >measured in units of "number of softclocks"): > >Queue the entry for ordered insertion when timeout() is called, but >delay the ordered insertion until softclock(). Sounds like it will take additional space. >This allows you to take the traversal hit once: at the same time you >are timing out timers, in fact, so it's a non-hit relative to your >current algorithm. In fact it's O(n/2) instead of O(n), and then >only in the case that you have timers to insert. Nope. It's usually O(n) and not O(n/2) as most of the timeouts will be for the same amount of time in the future meaning a necessary tail insertion. If we keep the tail pointer, we can cut out this case though. > Regards, > Terry Lambert > terry@lambert.org >--- >Any opinions in this posting are my own and not those of my present >or previous employers. -- Justin T. Gibbs =========================================== FreeBSD: Turning PCs into workstations =========================================== From owner-freebsd-current Mon Sep 22 19:45:51 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id TAA10035 for current-outgoing; Mon, 22 Sep 1997 19:45:51 -0700 (PDT) Received: from pluto.plutotech.com (root@mail.plutotech.com [206.168.67.137]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id TAA10030 for ; Mon, 22 Sep 1997 19:45:47 -0700 (PDT) Received: from narnia.plutotech.com (narnia.plutotech.com [206.168.67.130]) by pluto.plutotech.com (8.8.5/8.8.5) with ESMTP id UAA10200; Mon, 22 Sep 1997 20:45:28 -0600 (MDT) Message-Id: <199709230245.UAA10200@pluto.plutotech.com> X-Mailer: exmh version 2.0zeta 7/24/97 To: Terry Lambert cc: gibbs@plutotech.com (Justin T. Gibbs), nate@mt.sri.com, bde@zeta.org.au, current@FreeBSD.ORG Subject: Re: callouts in CAM (was Re: cvs commit:) In-reply-to: Your message of "Tue, 23 Sep 1997 02:16:24 -0000." <199709230216.TAA00163@usr01.primenet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 22 Sep 1997 20:45:12 -0600 From: "Justin T. Gibbs" Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >> Yes, but it's still not implemented. I think that we should push this >> onto the client instead of attempting to do some kind of low water-mark >> early allocation. In other words, allocate a fairly small initial pool >> for most applications and then have systems like CAM allocate a callout >> on an as-needed basis. > >You don't think it should be watermarked? I am a fan of low watermark >based allocation scheduling (not necessarily immediate allocation, unless >the pool empties). Mostly, I like this because the pools can be per >CPU, and thus you don't take a global resource lock in the SMP case. My point is that clients can allocate or request for allocation deterministically as they know what their usage will be. If there is an interface to do this, then the client can deal with a failure gracefully. If you rely on watermark based allocation and for some reason cannot keep up with demand, there is little you can do other than panic. > Terry Lambert > terry@lambert.org > --- > Any opinions in this posting are my own and not those of my present > or previous employers. -- Justin T. Gibbs =========================================== FreeBSD: Turning PCs into workstations =========================================== From owner-freebsd-current Mon Sep 22 20:52:02 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id UAA12964 for current-outgoing; Mon, 22 Sep 1997 20:52:02 -0700 (PDT) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id UAA12935 for ; Mon, 22 Sep 1997 20:51:58 -0700 (PDT) Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id FAA17278; Tue, 23 Sep 1997 05:51:47 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.8.7/8.8.5) id FAA07832; Tue, 23 Sep 1997 05:33:31 +0200 (MET DST) Message-ID: <19970923053330.QX53740@uriah.heep.sax.de> Date: Tue, 23 Sep 1997 05:33:30 +0200 From: j@uriah.heep.sax.de (J Wunsch) To: freebsd-current@FreeBSD.ORG (FreeBSD Current Users' list) Cc: roberto@keltia.freenix.fr (Ollivier Robert) Subject: Re: Assertion failed in ncr driver References: <19970922230618.13112@keltia.freenix.fr> X-Mailer: Mutt 0.60_p2-3,5,8-9 Mime-Version: 1.0 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <19970922230618.13112@keltia.freenix.fr>; from Ollivier Robert on Sep 22, 1997 23:06:18 +0200 Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk As Ollivier Robert wrote: > Any idea why I get these ? > > assertion "cp" failed: file "../../pci/ncr.c", line 6227 > sd0: COMMAND FAILED (4 28) @f0765800. > assertion "cp" failed: file "../../pci/ncr.c", line 6227 > sd0: COMMAND FAILED (4 28) @f0765c00. I'm seeing the same errors occasionally for the IBM DCAS-34330 (not the `W' in my case, and only a NCR 53c810), also when dump(8)ing. Wrote this to Stefan in private mail, but it seems he didn't have enough time to read his mail since. -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-current Mon Sep 22 21:17:33 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id VAA14102 for current-outgoing; Mon, 22 Sep 1997 21:17:33 -0700 (PDT) Received: from usr08.primenet.com (tlambert@usr08.primenet.com [206.165.6.208]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id VAA14097 for ; Mon, 22 Sep 1997 21:17:29 -0700 (PDT) Received: (from tlambert@localhost) by usr08.primenet.com (8.8.5/8.8.5) id VAA07549; Mon, 22 Sep 1997 21:15:49 -0700 (MST) From: Terry Lambert Message-Id: <199709230415.VAA07549@usr08.primenet.com> Subject: Re: cvs commit: src/sys/conf files src/sys/dev/vx if_vx.c if_vxreg.h src/sys/i386/apm apm.c src/sys/i386/conf GENERIC files.i386 To: gibbs@plutotech.com (Justin T. Gibbs) Date: Tue, 23 Sep 1997 04:15:49 +0000 (GMT) Cc: tlambert@primenet.com, gibbs@plutotech.com, nate@mt.sri.com, bde@zeta.org.au, current@FreeBSD.ORG In-Reply-To: <199709230232.UAA09928@pluto.plutotech.com> from "Justin T. Gibbs" at Sep 22, 97 08:31:59 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > >The untimeout can easily be made O(1); just keep a backlink. This > >is what you are doing, isn't it? > > Go read the code. It was a rhetorical question. > >For timeouts that live across softclock calls, as Nate is suggesting, > >the list is traversed and the entry counts against the implementation > >based on how many softclocks it lives across, on average. For ordered > >insertion, the entry is counted against, once, at insertion time. > > > >So the question to as is "how many softclocks does the average timer > >entry live across?". > > Go read the code. This one was less rhetorical, and required an empirical judgement on your part to get the same conclusion I had already made. It's called a Socratic Dialectic. The real answer is "it depends on what timer intervals you use and with what frequency a timer is dequeud before it fires" to answer the question. It seems the answer is "a given entry is traversed by many softclock() events; how many depends on the expected duration of the entry divided by the number of hash buckets". For 10 users, this is much less than 256. You still haven't stated how amny timers are expected to be enqueued in all buckets, on average, when a softclock hits, in common usage. > An entry will only have it's count decremented if, during it's lifetime, > softclock traverses the list of callouts in it's hash bucket. It may > take numerous calls to softclock before it touches the bucket where > a particular callout is placed. Nate's point was that this assumes one entry per hash bucket, on average. For the default of 10 users in GENERIC, I think this is a bad assumption. Even for 32 users (256 buckets), it's stretching things if the timers see any real use at all. > >If so, I have a compromise suggestion, since the implication is that > >timers *will* live across multiple softclocks (that they are, indeed, > >measured in units of "number of softclocks"): > > > >Queue the entry for ordered insertion when timeout() is called, but > >delay the ordered insertion until softclock(). > > Sounds like it will take additional space. No. It will take two additional pointers and a trivial amount of code identical to the code you would need anyway. > >This allows you to take the traversal hit once: at the same time you > >are timing out timers, in fact, so it's a non-hit relative to your > >current algorithm. In fact it's O(n/2) instead of O(n), and then > >only in the case that you have timers to insert. > > Nope. It's usually O(n) and not O(n/2) as most of the timeouts will > be for the same amount of time in the future meaning a necessary tail > insertion. If we keep the tail pointer, we can cut out this case though. Which you would, if you had an inverse pointer. That's the second of the two pointers, above. The first of them is the head for the list of "queued-but-not-yet-order-inserted" entries that you will insert (in order) at the first softclock after they are enqueued. The enqueuing itself is O(1), returning your insertion back down to the required O(1) to make it determinant for interrupt routines. Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-current Mon Sep 22 21:19:10 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id VAA14209 for current-outgoing; Mon, 22 Sep 1997 21:19:10 -0700 (PDT) Received: from usr08.primenet.com (tlambert@usr08.primenet.com [206.165.6.208]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id VAA14201 for ; Mon, 22 Sep 1997 21:19:07 -0700 (PDT) Received: (from tlambert@localhost) by usr08.primenet.com (8.8.5/8.8.5) id VAA07673; Mon, 22 Sep 1997 21:17:37 -0700 (MST) From: Terry Lambert Message-Id: <199709230417.VAA07673@usr08.primenet.com> Subject: Re: callouts in CAM (was Re: cvs commit:) To: gibbs@plutotech.com (Justin T. Gibbs) Date: Tue, 23 Sep 1997 04:17:37 +0000 (GMT) Cc: tlambert@primenet.com, gibbs@plutotech.com, nate@mt.sri.com, bde@zeta.org.au, current@FreeBSD.ORG In-Reply-To: <199709230245.UAA10200@pluto.plutotech.com> from "Justin T. Gibbs" at Sep 22, 97 08:45:12 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > >You don't think it should be watermarked? I am a fan of low watermark > >based allocation scheduling (not necessarily immediate allocation, unless > >the pool empties). Mostly, I like this because the pools can be per > >CPU, and thus you don't take a global resource lock in the SMP case. > > My point is that clients can allocate or request for allocation > deterministically as they know what their usage will be. If there is an > interface to do this, then the client can deal with a failure gracefully. > If you rely on watermark based allocation and for some reason cannot keep > up with demand, there is little you can do other than panic. ? You stated before that you could simply block the request that would have made use of a newly allocated resource until such time as one of the existing entries becomes availble. I'd hate to see max allocation up front in all cases. 8-(. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-current Mon Sep 22 21:32:14 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id VAA14968 for current-outgoing; Mon, 22 Sep 1997 21:32:14 -0700 (PDT) Received: from lamb.sas.com (uucp@lamb.sas.com [192.35.83.8]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id VAA14963 for ; Mon, 22 Sep 1997 21:32:11 -0700 (PDT) Received: from mozart by lamb.sas.com (5.65c/SAS/Gateway/01-23-95) id AA26554; Tue, 23 Sep 1997 00:32:06 -0400 Received: from iluvatar.unx.sas.com by mozart (5.65c/SAS/Domains/5-6-90) id AA00428; Tue, 23 Sep 1997 00:31:53 -0400 From: "John W. DeBoskey" Received: by iluvatar.unx.sas.com (5.65c/SAS/Generic 9.01/3-26-93) id AA06255; Tue, 23 Sep 1997 00:31:52 -0400 Message-Id: <199709230431.AA06255@iluvatar.unx.sas.com> Subject: Memory auto detect & bounce buffer panic To: freebsd-current@freebsd.org Date: Tue, 23 Sep 1997 00:31:51 -0400 (EDT) X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi, I just tried to install the 3.0-970911-SNAP on a machine with 2 gig of memory installed. The boot process spit the following out after the config screen: panic: bounce memory out of range Automatic reboot in 15 seconds: Press any key on the console to abort I removed all but 256Meg and the machine booted ok, and I then removed options BOUNCE_BUFFERS and it now boots just fine... Question: I seem to remember an npx0 flag that could set the amount of usable memory in the system that can only be used in cli mode... But, I can't find any reference to it in the doc or the code... Anyone got a pointer? Thanks, John -- jwd@unx.sas.com (w) John W. De Boskey (919) 677-8000 x6915 From owner-freebsd-current Mon Sep 22 22:14:53 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id WAA17747 for current-outgoing; Mon, 22 Sep 1997 22:14:53 -0700 (PDT) Received: from bunyip.cc.uq.edu.au (daemon@bunyip.cc.uq.edu.au [130.102.2.1]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id WAA17738 for ; Mon, 22 Sep 1997 22:14:36 -0700 (PDT) Received: (from daemon@localhost) by bunyip.cc.uq.edu.au (8.8.7/8.8.7) id PAA24541 for freebsd-current@freebsd.org; Tue, 23 Sep 1997 15:14:27 +1000 Received: from localhost.dtir.qld.gov.au (localhost.dtir.qld.gov.au [127.0.0.1]) by ogre.dtir.qld.gov.au (8.8.7/8.8.7) with SMTP id PAA18083; Tue, 23 Sep 1997 15:13:29 +1000 (EST) Message-Id: <199709230513.PAA18083@ogre.dtir.qld.gov.au> X-Authentication-Warning: ogre.dtir.qld.gov.au: localhost.dtir.qld.gov.au [127.0.0.1] didn't use HELO protocol To: freebsd-current@freebsd.org cc: syssgm@dtir.qld.gov.au Subject: Re: Assertion failed in ncr driver References: <19970922230618.13112@keltia.freenix.fr> <19970923053330.QX53740@uriah.heep.sax.de> In-Reply-To: <19970923053330.QX53740@uriah.heep.sax.de> from J Wunsch at "Tue, 23 Sep 1997 03:33:30 +0000" Date: Tue, 23 Sep 1997 15:13:29 +1000 From: Stephen McKay Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Tuesday, 23rd September 1997, J Wunsch wrote: >As Ollivier Robert wrote: > >> Any idea why I get these ? >> >> assertion "cp" failed: file "../../pci/ncr.c", line 6227 >> sd0: COMMAND FAILED (4 28) @f0765800. >> assertion "cp" failed: file "../../pci/ncr.c", line 6227 >> sd0: COMMAND FAILED (4 28) @f0765c00. > >I'm seeing the same errors occasionally for the IBM DCAS-34330 (not >the `W' in my case, and only a NCR 53c810), also when dump(8)ing. >Wrote this to Stefan in private mail, but it seems he didn't have >enough time to read his mail since. Me too! I occasionally see these errors with my Diamond FirePort 40 (53c875j based) and IBM DCAS-34330W. I have exchanged a bit of mail with Stefan already, but no promising leads developed. I have no way of reliably reproducing the problem, but I do know it has been there a long time because it was happening when I ran 2.2.2 (slightly modified to recognise the 875j). Could the disk be a rogue after all the praise we've heaped on it? Stephen. From owner-freebsd-current Mon Sep 22 22:40:29 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id WAA19433 for current-outgoing; Mon, 22 Sep 1997 22:40:29 -0700 (PDT) Received: from sendero-ppp.i-connect.net (sendero-ppp.i-Connect.Net [206.190.143.100]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id WAA19428 for ; Mon, 22 Sep 1997 22:40:27 -0700 (PDT) Received: (qmail 18156 invoked by uid 1000); 23 Sep 1997 05:40:50 -0000 Message-ID: X-Mailer: XFMail 1.2-alpha-091897 [p0] on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit MIME-Version: 1.0 Date: Mon, 22 Sep 1997 22:40:50 -0700 (PDT) Organization: Atlas Telecom From: Simon Shapiro To: freebsd-current@freebsd.org Subject: Compile failure on today's current kernel Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Any particular reason I am getting the following? loading kernel isa.o: Undefined symbol `_isa_devtab_cam' referenced from text segment isa.o: Undefined symbol `_isa_devtab_cam' referenced from text segment isa.o: Undefined symbol `_isa_devtab_cam' referenced from text segment isa.o: Undefined symbol `_isa_devtab_cam' referenced from text segment isa.o: Undefined symbol `_isa_devtab_cam' referenced from text segment isa.o: Undefined symbol `_isa_devtab_cam' referenced from text segment isa.o: Undefined symbol `_isa_devtab_cam' referenced from text segment isa.o: Undefined symbol `_isa_devtab_cam' referenced from text segment --- Sincerely Yours, (Sent on 22-Sep-97, 22:38:39 by XF-Mail) Simon Shapiro Atlas Telecom Senior Architect 14355 SW Allen Blvd., Suite 130 Beaverton OR 97005 Shimon@i-Connect.Net Voice: 503.643.5559, Emergency: 503.799.2313 From owner-freebsd-current Mon Sep 22 23:08:48 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id XAA20947 for current-outgoing; Mon, 22 Sep 1997 23:08:48 -0700 (PDT) Received: from gratis.grondar.za (gratis.grondar.za [196.7.18.133]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id XAA20940 for ; Mon, 22 Sep 1997 23:08:35 -0700 (PDT) Received: from greenpeace.grondar.za (Cx7AOWvdjH8T3/ZcB1JM9VJmNIE3+Dfj@greenpeace.grondar.za [196.7.18.132]) by gratis.grondar.za (8.8.7/8.8.7) with ESMTP id IAA01718; Tue, 23 Sep 1997 08:08:44 +0200 (SAT) Received: from greenpeace.grondar.za (2JUESIhpO0yYLwYM7v1oxtfcpl3c/akF@localhost [127.0.0.1]) by greenpeace.grondar.za (8.8.7/8.8.7) with ESMTP id IAA25787; Tue, 23 Sep 1997 08:09:04 +0200 (SAT) Message-Id: <199709230609.IAA25787@greenpeace.grondar.za> X-Mailer: exmh version 2.0zeta 7/24/97 To: Jean-Marc Zucconi cc: roberto@keltia.freenix.fr, freebsd-current@freefall.freebsd.org Subject: Re: ctm blowup Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 23 Sep 1997 08:09:03 +0200 From: Mark Murray Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Jean-Marc Zucconi wrote: > Very, very surprising, because I got the message, using "normal" > cvs-cur and int-cvs-cur (I am at #87)!! Not at all surprising. You are not in USA, ans so would never have been sent the kerberosIV directory. It is (was) filtered at source. M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org From owner-freebsd-current Mon Sep 22 23:16:36 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id XAA21402 for current-outgoing; Mon, 22 Sep 1997 23:16:36 -0700 (PDT) Received: from gratis.grondar.za (gratis.grondar.za [196.7.18.133]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id XAA21393 for ; Mon, 22 Sep 1997 23:16:27 -0700 (PDT) Received: from greenpeace.grondar.za (AFHRL7X7uzVUwgKAh0JoZ4meESo3BRhC@greenpeace.grondar.za [196.7.18.132]) by gratis.grondar.za (8.8.7/8.8.7) with ESMTP id IAA01738; Tue, 23 Sep 1997 08:16:35 +0200 (SAT) Received: from greenpeace.grondar.za (rbfxeBKcNJajCkWmSB5HUCdA/sODAW4z@localhost [127.0.0.1]) by greenpeace.grondar.za (8.8.7/8.8.7) with ESMTP id IAA25861; Tue, 23 Sep 1997 08:16:56 +0200 (SAT) Message-Id: <199709230616.IAA25861@greenpeace.grondar.za> X-Mailer: exmh version 2.0zeta 7/24/97 To: Simon Shapiro cc: freebsd-current@FreeBSD.ORG Subject: Re: Compile failure on today's current kernel Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 23 Sep 1997 08:16:56 +0200 From: Mark Murray Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Rebuild config(8). _Always_ rebuild config(8). M Simon Shapiro wrote: > Any particular reason I am getting the following? > > loading kernel > isa.o: Undefined symbol `_isa_devtab_cam' referenced from text segment > isa.o: Undefined symbol `_isa_devtab_cam' referenced from text segment > isa.o: Undefined symbol `_isa_devtab_cam' referenced from text segment > isa.o: Undefined symbol `_isa_devtab_cam' referenced from text segment > isa.o: Undefined symbol `_isa_devtab_cam' referenced from text segment > isa.o: Undefined symbol `_isa_devtab_cam' referenced from text segment > isa.o: Undefined symbol `_isa_devtab_cam' referenced from text segment > isa.o: Undefined symbol `_isa_devtab_cam' referenced from text segment > > --- > > > Sincerely Yours, (Sent on 22-Sep-97, 22:38:39 > by XF-Mail) > > Simon Shapiro Atlas Telecom > Senior Architect 14355 SW Allen Blvd., Suite 130 Beaverton OR 97005 > Shimon@i-Connect.Net Voice: 503.643.5559, Emergency: 503.799.2313 -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org From owner-freebsd-current Mon Sep 22 23:21:01 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id XAA21641 for current-outgoing; Mon, 22 Sep 1997 23:21:01 -0700 (PDT) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id XAA21635 for ; Mon, 22 Sep 1997 23:20:56 -0700 (PDT) Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id IAA18393; Tue, 23 Sep 1997 08:20:53 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.8.7/8.8.5) id IAA00368; Tue, 23 Sep 1997 08:15:18 +0200 (MET DST) Message-ID: <19970923081517.JL04004@uriah.heep.sax.de> Date: Tue, 23 Sep 1997 08:15:17 +0200 From: j@uriah.heep.sax.de (J Wunsch) To: freebsd-current@FreeBSD.ORG Cc: jwd@unx.sas.com (John W. DeBoskey) Subject: Re: Memory auto detect & bounce buffer panic References: <199709230431.AA06255@iluvatar.unx.sas.com> X-Mailer: Mutt 0.60_p2-3,5,8-9 Mime-Version: 1.0 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199709230431.AA06255@iluvatar.unx.sas.com>; from John W. DeBoskey on Sep 23, 1997 00:31:51 -0400 Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk As John W. DeBoskey wrote: > Question: I seem to remember an npx0 flag that could set the > amount of usable memory in the system that can only > be used in cli mode... But, I can't find any reference > to it in the doc or the code... > > Anyone got a pointer? /sys/i386/conf/LINT Device flags should be documented in section 4 man pages, not in LINT. -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-current Mon Sep 22 23:21:17 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id XAA21667 for current-outgoing; Mon, 22 Sep 1997 23:21:17 -0700 (PDT) Received: from bunyip.cc.uq.edu.au (bunyip.cc.uq.edu.au [130.102.2.1]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id XAA21640 for ; Mon, 22 Sep 1997 23:20:59 -0700 (PDT) Received: (from daemon@localhost) by bunyip.cc.uq.edu.au (8.8.7/8.8.7) id QAA02547; Tue, 23 Sep 1997 16:17:40 +1000 Received: from localhost.dtir.qld.gov.au (localhost.dtir.qld.gov.au [127.0.0.1]) by ogre.dtir.qld.gov.au (8.8.7/8.8.7) with SMTP id QAA20746; Tue, 23 Sep 1997 16:19:00 +1000 (EST) Message-Id: <199709230619.QAA20746@ogre.dtir.qld.gov.au> X-Authentication-Warning: ogre.dtir.qld.gov.au: localhost.dtir.qld.gov.au [127.0.0.1] didn't use HELO protocol To: Poul-Henning Kamp cc: freebsd-current@freebsd.org, syssgm@dtir.qld.gov.au Subject: Re: New timeout capability (was Re: cvs commit:....) References: <899.874957324@critter.freebsd.dk> In-Reply-To: <899.874957324@critter.freebsd.dk> from Poul-Henning Kamp at "Mon, 22 Sep 1997 19:42:04 +0000" Date: Tue, 23 Sep 1997 16:19:00 +1000 From: Stephen McKay Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Monday, 22nd September 1997, Poul-Henning Kamp wrote: >In message <199709221910.NAA02147@rocky.mt.sri.com>, Nate Williams writes: > >>Can you explain a bit more about your 'rover' setup, and how it's used? > >The "rover" in my lab is named after it's more adventurous namesake >on Mars... [Fun workbench elided] Sounds like an excellent setup! Wow, hard facts! >If you have a change you want tested, I should be able to give >the result back to you in one or two days. (I only ask in return >that I may publish the results in case I write a paper on this >experiment later on). I've always wanted to know how much it costs to run with 4Kb file system blocks vs 8Kb or now even 16Kb. Oh, and the real cost of various minfree percentages. No obligation, of course, but you might be interested too... Stephen. From owner-freebsd-current Mon Sep 22 23:23:18 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id XAA21768 for current-outgoing; Mon, 22 Sep 1997 23:23:18 -0700 (PDT) Received: from critter.freebsd.dk (critter.freebsd.dk [195.8.129.26]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id XAA21761 for ; Mon, 22 Sep 1997 23:23:12 -0700 (PDT) Received: from critter.freebsd.dk (localhost.cybercity.dk [127.0.0.1]) by critter.freebsd.dk (8.8.7/8.8.7) with ESMTP id IAA02495; Tue, 23 Sep 1997 08:22:16 +0200 (CEST) To: Stephen McKay cc: freebsd-current@freebsd.org Subject: Re: New timeout capability (was Re: cvs commit:....) In-reply-to: Your message of "Tue, 23 Sep 1997 16:19:00 +1000." <199709230619.QAA20746@ogre.dtir.qld.gov.au> Date: Tue, 23 Sep 1997 08:22:16 +0200 Message-ID: <2493.874995736@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In message <199709230619.QAA20746@ogre.dtir.qld.gov.au>, Stephen McKay writes: >On Monday, 22nd September 1997, Poul-Henning Kamp wrote: > >>In message <199709221910.NAA02147@rocky.mt.sri.com>, Nate Williams writes: >> >>>Can you explain a bit more about your 'rover' setup, and how it's used? >> >>The "rover" in my lab is named after it's more adventurous namesake >>on Mars... > >[Fun workbench elided] > >Sounds like an excellent setup! Wow, hard facts! > >>If you have a change you want tested, I should be able to give >>the result back to you in one or two days. (I only ask in return >>that I may publish the results in case I write a paper on this >>experiment later on). > >I've always wanted to know how much it costs to run with 4Kb file system >blocks vs 8Kb or now even 16Kb. Oh, and the real cost of various minfree >percentages. No obligation, of course, but you might be interested too... This would require a slightly different setup, I would need to newfs the filesystem and do for instance a restore(8) onto it for each experiment. This would undoubtedly introduce more uncertainty into the equation, but I'm sure we can sample our way out of that. I'll put it on my list. -- Poul-Henning Kamp FreeBSD coreteam member phk@FreeBSD.ORG "Real hackers run -current on their laptop." From owner-freebsd-current Mon Sep 22 23:30:56 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id XAA22491 for current-outgoing; Mon, 22 Sep 1997 23:30:56 -0700 (PDT) Received: from pluto.plutotech.com (root@mail.plutotech.com [206.168.67.137]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id XAA22483 for ; Mon, 22 Sep 1997 23:30:52 -0700 (PDT) Received: from narnia.plutotech.com (narnia.plutotech.com [206.168.67.130]) by pluto.plutotech.com (8.8.5/8.8.5) with ESMTP id AAA13505; Tue, 23 Sep 1997 00:30:36 -0600 (MDT) Message-Id: <199709230630.AAA13505@pluto.plutotech.com> To: Terry Lambert cc: gibbs@plutotech.com (Justin T. Gibbs), nate@mt.sri.com, bde@zeta.org.au, current@FreeBSD.ORG Subject: Re: cvs commit: src/sys/conf files src/sys/dev/vx if_vx.c if_vxreg.h src/sys/i386/apm apm.c src/sys/i386/conf GENERIC files.i386 In-reply-to: Your message of "Tue, 23 Sep 1997 04:15:49 -0000." <199709230415.VAA07549@usr08.primenet.com> Date: Tue, 23 Sep 1997 00:30:25 -0600 From: "Justin T. Gibbs" Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >> >So the question to as is "how many softclocks does the average timer >> >entry live across?". >> >> Go read the code. > >This one was less rhetorical, and required an empirical judgement on >your part to get the same conclusion I had already made. It's called >a Socratic Dialectic. Bullshit. You stated that every entry would be touched on each softtick. This simply isn't how it works and would have been obvious to you if you had either read the paper or read the code. Of course, now that you've read this piece of mail that explains to you how it works, you pretend that the misunderstanding was on my part and that I don't seem to be able to understand your plain english. I love it! >The real answer is "it depends on what timer >intervals you use and with what frequency a timer is dequeud before it >fires" to answer the question. It seems the answer is "a given entry >is traversed by many softclock() events; how many depends on the >expected duration of the entry divided by the number of hash buckets". Which is pretty obvious. >For 10 users, this is much less than 256. Go read the code and also go really read my posts on this thread. Did you miss the message where I showed that the number of callouts allocated for a 10 user system is 196? Or are we supposed to believe that 196 is much less than 256? Did you also miss the fact that this is a power of 2 hash table so that even on a 10 user system the size is rounded up to 256? >You still haven't stated how >amny timers are expected to be enqueued in all buckets, on average, when >a softclock hits, in common usage. Sure I have. On each softclock, the number of timers enqueued in all buckets is the number of callouts outstanding which I've said is around 30 for a typical workstation. Of course you probably meant to ask what the average length of a hash chain is and to answer that question for the loads I'm interested in, I'd have to instrument the code. I expect it to be h where h << n and n is the total number of callouts outstanding. >> An entry will only have it's count decremented if, during it's lifetime, >> softclock traverses the list of callouts in it's hash bucket. It may >> take numerous calls to softclock before it touches the bucket where >> a particular callout is placed. > >Nate's point was that this assumes one entry per hash bucket, on average. No it doesn't. For example, here is a 4 bucket call wheel: 1 2 3 4 + + + + x a b d + + + y c f + + z e Lets say that softclock is currently at bucket 2. When will entries x, y, and z next be referenced? During the call to softclock 3 ticks in the future. If any of x, y, or z are removed before that time, they will not be referenced. The average hash chain length in this callwheel is a little over 2. >For the default of 10 users in GENERIC, I think this is a bad assumption. >Even for 32 users (256 buckets), it's stretching things if the timers >see any real use at all. The hash table size is still larger than the total number of callouts that can be outstanding. >> >Queue the entry for ordered insertion when timeout() is called, but >> >delay the ordered insertion until softclock(). >> >> Sounds like it will take additional space. > >No. It will take two additional pointers and a trivial amount of >code identical to the code you would need anyway. Two pointers is additional space. It also makes softclock become q * O(h) + O(c) where q is the number of defered insertion entries, h is the hash chain length and c is the number of empty buckets that are traversed to find the next timeout for scheduling the next one shot. Then there is the additional code in softclock to ensure that none of the timeouts queued while softclock is running are supposed to expire in the current tick which you would need to check every time softclock drops from splhigh to let other interrupts run as there is nothing to prevent a timeout handler or interrupt handler from scheduling such an entry. Sure, it's do-able, but the current implementation doesn't have any of this mess and still gets the O(1) insertion and softclock pays a single O(h). > Regards, > Terry Lambert > terry@lambert.org >--- >Any opinions in this posting are my own and not those of my present >or previous employers. > -- Justin T. Gibbs =========================================== FreeBSD: Turning PCs into workstations =========================================== From owner-freebsd-current Mon Sep 22 23:34:56 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id XAA22886 for current-outgoing; Mon, 22 Sep 1997 23:34:56 -0700 (PDT) Received: from pluto.plutotech.com (root@mail.plutotech.com [206.168.67.137]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id XAA22877 for ; Mon, 22 Sep 1997 23:34:52 -0700 (PDT) Received: from narnia.plutotech.com (narnia.plutotech.com [206.168.67.130]) by pluto.plutotech.com (8.8.5/8.8.5) with ESMTP id AAA13555; Tue, 23 Sep 1997 00:34:43 -0600 (MDT) Message-Id: <199709230634.AAA13555@pluto.plutotech.com> To: Terry Lambert cc: gibbs@plutotech.com (Justin T. Gibbs), nate@mt.sri.com, bde@zeta.org.au, current@FreeBSD.org Subject: Re: callouts in CAM (was Re: cvs commit:) In-reply-to: Your message of "Tue, 23 Sep 1997 04:17:37 -0000." <199709230417.VAA07673@usr08.primenet.com> Date: Tue, 23 Sep 1997 00:34:32 -0600 From: "Justin T. Gibbs" Sender: owner-freebsd-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk >> >You don't think it should be watermarked? I am a fan of low watermark >> >based allocation scheduling (not necessarily immediate allocation, unless >> >the pool empties). Mostly, I like this because the pools can be per >> >CPU, and thus you don't take a global resource lock in the SMP case. >> >> My point is that clients can allocate or request for allocation >> deterministically as they know what their usage will be. If there is an >> interface to do this, then the client can deal with a failure gracefully. >> If you rely on watermark based allocation and for some reason cannot keep >> up with demand, there is little you can do other than panic. > >? > >You stated before that you could simply block the request that would >have made use of a newly allocated resource until such time as one of >the existing entries becomes availble. I'd hate to see max allocation >up front in all cases. 8-(. New work comes in. There are no CCBs/callouts available in the free pool. An attempt is made to allocate a CCB and it's corresponding callout. If that fails (malloc failure), I wait for an existing CCB/callout to come free. Where does this contradict what I said above? Where is the max allocation up front? I allocate on demand. > Terry Lambert > terry@lambert.org >--- >Any opinions in this posting are my own and not those of my present >or previous employers. -- Justin T. Gibbs =========================================== FreeBSD: Turning PCs into workstations =========================================== From owner-freebsd-current Mon Sep 22 23:39:46 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id XAA23357 for current-outgoing; Mon, 22 Sep 1997 23:39:46 -0700 (PDT) Received: from hydrogen.nike.efn.org (resnet.uoregon.edu [128.223.170.28]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id XAA23350 for ; Mon, 22 Sep 1997 23:39:42 -0700 (PDT) Received: (from jmg@localhost) by hydrogen.nike.efn.org (8.8.7/8.8.7) id XAA28674; Mon, 22 Sep 1997 23:39:30 -0700 (PDT) Message-ID: <19970922233930.12159@hydrogen.nike.efn.org> Date: Mon, 22 Sep 1997 23:39:30 -0700 From: John-Mark Gurney To: Nate Williams Cc: "Justin T. Gibbs" , current@FreeBSD.ORG Subject: Re: cvs commit: src/sys/conf files src/sys/dev/vx if_vx.c if_vxreg.h src/sys/i386/apm apm.c src/sys/i386/conf GENERIC files.i386 src/sys/i386/eisa 3c5x9.c aha1742.c aic7770.c bt74x.c eisaconf.c eisaconf.h if_fea.c if_vx_eisa.c src/sys/i386/i386 autoconf. References: <199709220505.XAA29116@rocky.mt.sri.com> <199709220548.XAA08824@pluto.plutotech.com> <199709221839.MAA01809@rocky.mt.sri.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.69 In-Reply-To: <199709221839.MAA01809@rocky.mt.sri.com>; from Nate Williams on Mon, Sep 22, 1997 at 12:39:44PM -0600 Reply-To: John-Mark Gurney Organization: Cu Networking X-Operating-System: FreeBSD 2.2.1-RELEASE i386 X-PGP-Fingerprint: B7 EC EF F8 AE ED A7 31 96 7A 22 B3 D8 56 36 F4 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Nate Williams scribbled this message on Sep 22: > > In performing the conversion of all the client code, it became quite > > obvious that the common case is to schedule a timeout that will be > > canceled before it expires and that the lifetime of a timeout is quite > > short. > > Is 'short' shorter than a single softclock()? If not, then we still > need to do more work than we used to do. And, if we have 2 ticks, > 'assuming all things we're equal' the new code could be the same speed > as the old code. > > (Obviously bogus explanation follows): > > Old code: > 1) timeout = O(x) ~= 10 seconds > 2) untimeout = O(x) ~= 10 seconds > 3) softclock = O(1) ~= 1 second > > So, assuming we call a timeout, get 2 softclock updates, and then call > untimeout we get: > > 10 + 1 + 1 + 10 = 22 seconds. > > New code: > 1) timeout = O(1) ~= 1 seconds > 2) untimeout = O(1) ~= 1 seconds > 3) softclock = O(n) ~= 10 second > > The same as above: > > 1 + 10 + 10 + 1 = 22 seconds. > > Again, this is so obviously bogus that I hate to even mention it, but it > explains what I'm trying to say. Depending on *how often* and *how > long* each of the operations takes, the new solution may not be a win. > > I'll stop for now, since this is as much a learning experience for me as > anything, and I don't want to wear out my welcome. :) :) now... I want to know why something more effecient isn't used.. something like a Fibonacci heap... this will provide amortized constant time for insert and minimum (find what is min)... then for actually deleting a key (performed once for each key when either expired or removed) it performs in O(lgn) time... from the sounds of it.. this will be a VERY big win... as then softclock will run at worst O(xlgn) when x elements expires... and O(1) when there isn't anything to expire... for more info, look up Fibonacci heaps in a Data structures book like, Introduction to Algorithms, by Cormen, Leiserson, and Rivest... ISBN 0-07-013143-0... I was surprised that something like this isn't already implemented genericly in the kernel... I was thinking about working on implementing this in the near future once I found out that such a thing doesn't exist already in FreeBSD... -- John-Mark Gurney Modem/FAX: +1 541 683 6954 Cu Networking Live in Peace, destroy Micro$oft, support free software, run FreeBSD From owner-freebsd-current Mon Sep 22 23:46:37 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id XAA23976 for current-outgoing; Mon, 22 Sep 1997 23:46:37 -0700 (PDT) Received: from sendero-ppp.i-connect.net (sendero-ppp.i-Connect.Net [206.190.143.100]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id XAA23969 for ; Mon, 22 Sep 1997 23:46:32 -0700 (PDT) Received: (qmail 20129 invoked by uid 1000); 23 Sep 1997 06:46:56 -0000 Message-ID: X-Mailer: XFMail 1.2-alpha-091897 [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: <199709230616.IAA25861@greenpeace.grondar.za> Date: Mon, 22 Sep 1997 23:46:56 -0700 (PDT) Organization: Atlas Telecom From: Simon Shapiro To: Mark Murray Subject: Re: Compile failure on today's current kernel Cc: freebsd-current@FreeBSD.ORG Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hi Mark Murray; On 23-Sep-97 you wrote: > Rebuild config(8). > > _Always_ rebuild config(8). Sorry about that. complicated story, but I found it out 10 minutes ago. thanx! > > M > > Simon Shapiro wrote: > > Any particular reason I am getting the following? > > > > loading kernel > > isa.o: Undefined symbol `_isa_devtab_cam' referenced from text segment > > isa.o: Undefined symbol `_isa_devtab_cam' referenced from text segment > > isa.o: Undefined symbol `_isa_devtab_cam' referenced from text segment > > isa.o: Undefined symbol `_isa_devtab_cam' referenced from text segment > > isa.o: Undefined symbol `_isa_devtab_cam' referenced from text segment > > isa.o: Undefined symbol `_isa_devtab_cam' referenced from text segment > > isa.o: Undefined symbol `_isa_devtab_cam' referenced from text segment > > isa.o: Undefined symbol `_isa_devtab_cam' referenced from text segment > > > > --- > > > > > > Sincerely Yours, (Sent on 22-Sep-97, > > 22:38:39 > > by XF-Mail) > > > > Simon Shapiro Atlas > > Telecom > > Senior Architect 14355 SW Allen Blvd., Suite 130 Beaverton OR > > 97005 > > Shimon@i-Connect.Net Voice: 503.643.5559, Emergency: > > 503.799.2313 > -- > Mark Murray > Join the anti-SPAM movement: http://www.cauce.org > > --- Sincerely Yours, (Sent on 22-Sep-97, 23:32:48 by XF-Mail) Simon Shapiro Atlas Telecom Senior Architect 14355 SW Allen Blvd., Suite 130 Beaverton OR 97005 Shimon@i-Connect.Net Voice: 503.643.5559, Emergency: 503.799.2313 From owner-freebsd-current Mon Sep 22 23:48:41 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id XAA24096 for current-outgoing; Mon, 22 Sep 1997 23:48:41 -0700 (PDT) Received: from dyson.iquest.net (dyson.iquest.net [198.70.144.127]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id XAA24089 for ; Mon, 22 Sep 1997 23:48:36 -0700 (PDT) Received: (from root@localhost) by dyson.iquest.net (8.8.6/8.8.5) id BAA03313; Tue, 23 Sep 1997 01:48:23 -0500 (EST) From: "John S. Dyson" Message-Id: <199709230648.BAA03313@dyson.iquest.net> Subject: Re: Compile failure on today's current kernel In-Reply-To: from Simon Shapiro at "Sep 22, 97 10:40:50 pm" To: Shimon@i-Connect.Net (Simon Shapiro) Date: Tue, 23 Sep 1997 01:48:23 -0500 (EST) Cc: freebsd-current@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL31 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Simon Shapiro said: > Any particular reason I am getting the following? > > loading kernel > isa.o: Undefined symbol `_isa_devtab_cam' referenced from text segment > isa.o: Undefined symbol `_isa_devtab_cam' referenced from text segment > isa.o: Undefined symbol `_isa_devtab_cam' referenced from text segment > isa.o: Undefined symbol `_isa_devtab_cam' referenced from text segment > isa.o: Undefined symbol `_isa_devtab_cam' referenced from text segment > isa.o: Undefined symbol `_isa_devtab_cam' referenced from text segment > isa.o: Undefined symbol `_isa_devtab_cam' referenced from text segment > isa.o: Undefined symbol `_isa_devtab_cam' referenced from text segment > This kind of thing used to be much more common than it is now -- you need to rebuild the config program. -- John dyson@freebsd.org jdyson@nc.com From owner-freebsd-current Mon Sep 22 23:51:29 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id XAA24223 for current-outgoing; Mon, 22 Sep 1997 23:51:29 -0700 (PDT) Received: from pluto.plutotech.com (root@mail.plutotech.com [206.168.67.137]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id XAA24218 for ; Mon, 22 Sep 1997 23:51:23 -0700 (PDT) Received: from narnia.plutotech.com (narnia.plutotech.com [206.168.67.130]) by pluto.plutotech.com (8.8.5/8.8.5) with ESMTP id AAA13934; Tue, 23 Sep 1997 00:51:15 -0600 (MDT) Message-Id: <199709230651.AAA13934@pluto.plutotech.com> To: John-Mark Gurney cc: Nate Williams , "Justin T. Gibbs" , current@FreeBSD.ORG Subject: Re: cvs commit: src/sys/conf files src/sys/dev/vx if_vx.c if_vxreg.h src/sys/i386/apm apm.c src/sys/i386/conf GENERIC files.i386 src/sys/i386/eisa 3c5x9.c aha1742.c aic7770.c bt74x.c eisaconf.c eisaconf.h if_fea.c if_vx_eisa.c src/sys/i386/i386 autoconf. In-reply-to: Your message of "Mon, 22 Sep 1997 23:39:30 PDT." <19970922233930.12159@hydrogen.nike.efn.org> Date: Tue, 23 Sep 1997 00:51:04 -0600 From: "Justin T. Gibbs" Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >> I'll stop for now, since this is as much a learning experience for me as >> anything, and I don't want to wear out my welcome. :) :) > >now... I want to know why something more effecient isn't used.. something >like a Fibonacci heap... this will provide amortized constant time for >insert and minimum (find what is min)... then for actually deleting a >key (performed once for each key when either expired or removed) it >performs in O(lgn) time... I considered using a standard heap, but heaps are expensive/difficult to grow on demand as it requires reallocating an array. I'm not familiar with Fibonacci heaps though and perhaps this isn't a problem with them. >-- > John-Mark Gurney Modem/FAX: +1 541 683 6954 > Cu Networking > > Live in Peace, destroy Micro$oft, support free software, run FreeBSD -- Justin T. Gibbs =========================================== FreeBSD: Turning PCs into workstations =========================================== From owner-freebsd-current Mon Sep 22 23:52:29 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id XAA24321 for current-outgoing; Mon, 22 Sep 1997 23:52:29 -0700 (PDT) Received: from pluto.plutotech.com (root@mail.plutotech.com [206.168.67.137]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id XAA24316 for ; Mon, 22 Sep 1997 23:52:25 -0700 (PDT) Received: from narnia.plutotech.com (narnia.plutotech.com [206.168.67.130]) by pluto.plutotech.com (8.8.5/8.8.5) with ESMTP id AAA13964; Tue, 23 Sep 1997 00:52:21 -0600 (MDT) Message-Id: <199709230652.AAA13964@pluto.plutotech.com> To: Simon Shapiro cc: freebsd-current@FreeBSD.ORG Subject: Re: Compile failure on today's current kernel In-reply-to: Your message of "Mon, 22 Sep 1997 22:40:50 PDT." Date: Tue, 23 Sep 1997 00:52:10 -0600 From: "Justin T. Gibbs" Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >Any particular reason I am getting the following? You didn't rebuild config. If you're going to run current, read the current mailing list. This is not the first time this question was asked and answered. >loading kernel >isa.o: Undefined symbol `_isa_devtab_cam' referenced from text segment ... >--- > > >Sincerely Yours, (Sent on 22-Sep-97, 22:38:39 >by XF-Mail) > >Simon Shapiro Atlas Telecom >Senior Architect 14355 SW Allen Blvd., Suite 130 Beaverton OR 97005 >Shimon@i-Connect.Net Voice: 503.643.5559, Emergency: 503.799.2313 > -- Justin T. Gibbs =========================================== FreeBSD: Turning PCs into workstations =========================================== From owner-freebsd-current Tue Sep 23 00:01:36 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id AAA24638 for current-outgoing; Tue, 23 Sep 1997 00:01:36 -0700 (PDT) Received: from sendero-ppp.i-connect.net (sendero-ppp.i-Connect.Net [206.190.143.100]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id AAA24633 for ; Tue, 23 Sep 1997 00:01:33 -0700 (PDT) Received: (qmail 25604 invoked by uid 1000); 23 Sep 1997 07:01:57 -0000 Message-ID: X-Mailer: XFMail 1.2-alpha-091897 [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: <199709230652.AAA13964@pluto.plutotech.com> Date: Tue, 23 Sep 1997 00:01:56 -0700 (PDT) Organization: Atlas Telecom From: Simon Shapiro To: "Justin T. Gibbs" Subject: Re: Compile failure on today's current kernel Cc: freebsd-current@FreeBSD.ORG Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hi "Justin T. Gibbs"; On 23-Sep-97 you wrote: > >Any particular reason I am getting the following? > > You didn't rebuild config. I found that out and was told already. My apologies and my thanks. > If you're going to run current, read the current mailing list. Is there a presumption i do not read this mailing list? Because I do and never saw this before. Some of us are newer to FreeBSD than others. That, in and by itself is not an indication of degraded intelligence, you know. > This is not the first time this question was asked and answered. > > >loading kernel > >isa.o: Undefined symbol `_isa_devtab_cam' referenced from text segment > > ... > > >--- > > > > > >Sincerely Yours, (Sent on 22-Sep-97, > >22:38:39 > >by XF-Mail) > > > >Simon Shapiro Atlas > >Telecom > >Senior Architect 14355 SW Allen Blvd., Suite 130 Beaverton OR > >97005 > >Shimon@i-Connect.Net Voice: 503.643.5559, Emergency: > >503.799.2313 > > > > -- > Justin T. Gibbs > =========================================== > FreeBSD: Turning PCs into workstations > =========================================== --- Sincerely Yours, (Sent on 22-Sep-97, 23:58:28 by XF-Mail) Simon Shapiro Atlas Telecom Senior Architect 14355 SW Allen Blvd., Suite 130 Beaverton OR 97005 Shimon@i-Connect.Net Voice: 503.643.5559, Emergency: 503.799.2313 From owner-freebsd-current Tue Sep 23 00:13:10 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id AAA25285 for current-outgoing; Tue, 23 Sep 1997 00:13:10 -0700 (PDT) Received: from zibbi.mikom.csir.co.za (zibbi.mikom.csir.co.za [146.64.24.58]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id AAA25279 for ; Tue, 23 Sep 1997 00:13:02 -0700 (PDT) Received: (from jhay@localhost) by zibbi.mikom.csir.co.za (8.8.7/8.8.7) id JAA10963; Tue, 23 Sep 1997 09:12:19 +0200 (SAT) From: John Hay Message-Id: <199709230712.JAA10963@zibbi.mikom.csir.co.za> Subject: Re: ctm blowup In-Reply-To: <199709230609.IAA25787@greenpeace.grondar.za> from Mark Murray at "Sep 23, 97 08:09:03 am" To: mark@grondar.za (Mark Murray) Date: Tue, 23 Sep 1997 09:12:18 +0200 (SAT) Cc: freebsd-current@freebsd.org X-Mailer: ELM [version 2.4ME+ PL31 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > Jean-Marc Zucconi wrote: > > Very, very surprising, because I got the message, using "normal" > > cvs-cur and int-cvs-cur (I am at #87)!! > > Not at all surprising. You are not in USA, ans so would never have been > sent the kerberosIV directory. It is (was) filtered at source. > Except that there was a slip one time and the kerberosIV stuff got out and we were asked to remove it from our own trees. Perhaps some people didn't? John -- John Hay -- John.Hay@mikom.csir.co.za From owner-freebsd-current Tue Sep 23 00:46:20 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id AAA26679 for current-outgoing; Tue, 23 Sep 1997 00:46:20 -0700 (PDT) Received: from gratis.grondar.za (gratis.grondar.za [196.7.18.133]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id AAA26656 for ; Tue, 23 Sep 1997 00:46:12 -0700 (PDT) Received: from greenpeace.grondar.za (0oHJXLwr+wN545b1lAtd/cKeNHUfIxoM@greenpeace.grondar.za [196.7.18.132]) by gratis.grondar.za (8.8.7/8.8.7) with ESMTP id JAA01905; Tue, 23 Sep 1997 09:46:29 +0200 (SAT) Received: from greenpeace.grondar.za (z4OwKMDuDZ26wcE5hE6HyLweDJiQ2eAW@localhost [127.0.0.1]) by greenpeace.grondar.za (8.8.7/8.8.7) with ESMTP id JAA26259; Tue, 23 Sep 1997 09:46:52 +0200 (SAT) Message-Id: <199709230746.JAA26259@greenpeace.grondar.za> To: John Hay cc: freebsd-current@freebsd.org Subject: Re: ctm blowup Date: Tue, 23 Sep 1997 09:46:46 +0200 From: Mark Murray Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk John Hay wrote: > > Jean-Marc Zucconi wrote: > > > Very, very surprising, because I got the message, using "normal" > > > cvs-cur and int-cvs-cur (I am at #87)!! > > > > Not at all surprising. You are not in USA, ans so would never have been > > sent the kerberosIV directory. It is (was) filtered at source. > > > > Except that there was a slip one time and the kerberosIV stuff got out > and we were asked to remove it from our own trees. Perhaps some people > didn't? This is true. M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org From owner-freebsd-current Tue Sep 23 00:48:59 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id AAA26982 for current-outgoing; Tue, 23 Sep 1997 00:48:59 -0700 (PDT) Received: from hydrogen.nike.efn.org (resnet.uoregon.edu [128.223.170.28]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id AAA26961 for ; Tue, 23 Sep 1997 00:48:53 -0700 (PDT) Received: (from jmg@localhost) by hydrogen.nike.efn.org (8.8.7/8.8.7) id AAA28901; Tue, 23 Sep 1997 00:48:48 -0700 (PDT) Message-ID: <19970923004848.31356@hydrogen.nike.efn.org> Date: Tue, 23 Sep 1997 00:48:48 -0700 From: John-Mark Gurney To: "Justin T. Gibbs" Cc: current@FreeBSD.ORG Subject: Re: cvs commit: src/sys/conf files src/sys/dev/vx if_vx.c if_vxreg.h src/sys/i386/apm apm.c src/sys/i386/conf GENERIC files.i386 src/sys/i386/eisa 3c5x9.c aha1742.c aic7770.c bt74x.c eisaconf.c eisaconf.h if_fea.c if_vx_eisa.c src/sys/i386/i386 autoconf. References: <19970922233930.12159@hydrogen.nike.efn.org> <199709230651.AAA13934@pluto.plutotech.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.69 In-Reply-To: <199709230651.AAA13934@pluto.plutotech.com>; from Justin T. Gibbs on Tue, Sep 23, 1997 at 12:51:04AM -0600 Reply-To: John-Mark Gurney Organization: Cu Networking X-Operating-System: FreeBSD 2.2.1-RELEASE i386 X-PGP-Fingerprint: B7 EC EF F8 AE ED A7 31 96 7A 22 B3 D8 56 36 F4 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Justin T. Gibbs scribbled this message on Sep 23: > >> I'll stop for now, since this is as much a learning experience for me as > >> anything, and I don't want to wear out my welcome. :) :) > > > >now... I want to know why something more effecient isn't used.. something > >like a Fibonacci heap... this will provide amortized constant time for > >insert and minimum (find what is min)... then for actually deleting a > >key (performed once for each key when either expired or removed) it > >performs in O(lgn) time... > > I considered using a standard heap, but heaps are expensive/difficult > to grow on demand as it requires reallocating an array. I'm not > familiar with Fibonacci heaps though and perhaps this isn't a problem > with them. the Fibonacci heap still has that problem.. i.e. you actually have to allocate the space for each element... and it is actually slightly larger than most standard heaps as current data space for a node (with a void *data element) is 28bytes (assuming 4byts for poitners and ints) and an overhead of 16bytes (same assumption) for the base storage... but as I mentioned... the performance over amortized time is VERY nice... and there is no performance difference (none that is significant) if you remote an entry before it expires... all significant work is done when you remove the minimum element... and to remove a element early, you simply decrese the key to -inf (which can be done in O(1)) and then extract it... in order to get this performance... you still need the new calling method else you won't be able to find the key to remove unless you spend O(n) searching for it... ttyl.. -- John-Mark Gurney Modem/FAX: +1 541 683 6954 Cu Networking Live in Peace, destroy Micro$oft, support free software, run FreeBSD From owner-freebsd-current Tue Sep 23 01:18:06 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id BAA28155 for current-outgoing; Tue, 23 Sep 1997 01:18:06 -0700 (PDT) Received: from bunyip.cc.uq.edu.au (daemon@bunyip.cc.uq.edu.au [130.102.2.1]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id BAA28149 for ; Tue, 23 Sep 1997 01:17:55 -0700 (PDT) Received: (from daemon@localhost) by bunyip.cc.uq.edu.au (8.8.7/8.8.7) id SAA16236; Tue, 23 Sep 1997 18:17:44 +1000 Received: from troll.dtir.qld.gov.au (troll.dtir.qld.gov.au [167.123.8.1]) by ogre.dtir.qld.gov.au (8.8.7/8.8.7) with ESMTP id SAA28491; Tue, 23 Sep 1997 18:19:03 +1000 (EST) Received: from localhost (syssgm@localhost) by troll.dtir.qld.gov.au (8.8.5/8.8.5) with SMTP id SAA07263; Tue, 23 Sep 1997 18:18:59 +1000 (EST) Message-Id: <199709230818.SAA07263@troll.dtir.qld.gov.au> X-Authentication-Warning: troll.dtir.qld.gov.au: syssgm@localhost didn't use HELO protocol To: "John S. Dyson" cc: freebsd-current@FreeBSD.ORG, syssgm@dtir.qld.gov.au Subject: Re: New timeout capability (was Re: cvs commit:....) References: <199709230809.DAA06787@dyson.iquest.net> In-Reply-To: <199709230809.DAA06787@dyson.iquest.net> from "John S. Dyson" at "Tue, 23 Sep 1997 03:09:50 -0500" Date: Tue, 23 Sep 1997 18:18:58 +1000 From: Stephen McKay Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Tuesday, 23rd September 1997, "John S. Dyson" wrote: >Stephen McKay said: >> I've always wanted to know how much it costs to run with 4Kb file system >> blocks vs 8Kb or now even 16Kb. Oh, and the real cost of various minfree >> percentages. No obligation, of course, but you might be interested too... >> >32K or even 64K should work :-). With our upcoming dynamic buffer size >allocation, we could even do 256K? :-). Gods! What for? (Ok, that's just an initial exclamation.) My curiosity about the 4Kb vs 8Kb derives from the good job the clustering code does. If we have good clustering, then why have big block sizes? They just move the breakpoints for max file size before indirect blocks are needed (and similarly the max file size that can have fragments). Or at least, that's what my simplistic analysis suggests. Hard numbers would be much more useful. Hmm, with 64Kb blocks, we would have 8Kb frags. Even windoze 95 can do better than that! Stephen. From owner-freebsd-current Tue Sep 23 01:45:36 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id BAA29668 for current-outgoing; Tue, 23 Sep 1997 01:45:36 -0700 (PDT) Received: from time.cdrom.com (root@time.cdrom.com [204.216.27.226]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id BAA29663 for ; Tue, 23 Sep 1997 01:45:32 -0700 (PDT) Received: from time.cdrom.com (jkh@localhost.cdrom.com [127.0.0.1]) by time.cdrom.com (8.8.7/8.6.9) with ESMTP id BAA06279; Tue, 23 Sep 1997 01:46:00 -0700 (PDT) To: Simon Shapiro cc: "Justin T. Gibbs" , freebsd-current@FreeBSD.ORG Subject: Re: Compile failure on today's current kernel In-reply-to: Your message of "Tue, 23 Sep 1997 00:01:56 PDT." Date: Tue, 23 Sep 1997 01:45:59 -0700 Message-ID: <6275.875004359@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > Is there a presumption i do not read this mailing list? Because I do and > never saw this before. Some of us are newer to FreeBSD than others. That, > in and by itself is not an indication of degraded intelligence, you know. True. There probably needs to be a "-current rules of the road" document somewhere, culled from our years of experience with this entity called -current. Any takers? I'm kinda busy. ;-) Jordan From owner-freebsd-current Tue Sep 23 02:12:13 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id CAA00898 for current-outgoing; Tue, 23 Sep 1997 02:12:13 -0700 (PDT) Received: from freebie.lemis.com (gregl1.lnk.telstra.net [139.130.136.133]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id CAA00893 for ; Tue, 23 Sep 1997 02:12:08 -0700 (PDT) Received: (from grog@localhost) by freebie.lemis.com (8.8.7/8.8.5) id SAA27496; Tue, 23 Sep 1997 18:41:53 +0930 (CST) Message-ID: <19970923184153.23718@lemis.com> Date: Tue, 23 Sep 1997 18:41:53 +0930 From: Greg Lehey To: "Jordan K. Hubbard" Cc: Simon Shapiro , "Justin T. Gibbs" , freebsd-current@FreeBSD.ORG Subject: Re: Compile failure on today's current kernel References: <6275.875004359@time.cdrom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.81e In-Reply-To: <6275.875004359@time.cdrom.com>; from Jordan K. Hubbard on Tue, Sep 23, 1997 at 01:45:59AM -0700 Organisation: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8250 Fax: +61-8-8388-8250 Mobile: +61-41-739-7062 WWW-Home-Page: http://www.lemis.com/~grog Fight-Spam-Now: http://www.cauce.org Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Tue, Sep 23, 1997 at 01:45:59AM -0700, Jordan K. Hubbard wrote: >> Is there a presumption i do not read this mailing list? Because I do and >> never saw this before. Some of us are newer to FreeBSD than others. That, >> in and by itself is not an indication of degraded intelligence, you know. > > True. There probably needs to be a "-current rules of the road" > document somewhere, culled from our years of experience with this > entity called -current. > > Any takers? I'm kinda busy. ;-) From owner-freebsd-current Tue Sep 23 02:13:13 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id CAA00954 for current-outgoing; Tue, 23 Sep 1997 02:13:13 -0700 (PDT) Received: from freebie.lemis.com (gregl1.lnk.telstra.net [139.130.136.133]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id CAA00946 for ; Tue, 23 Sep 1997 02:13:08 -0700 (PDT) Received: (from grog@localhost) by freebie.lemis.com (8.8.7/8.8.5) id SAA27508; Tue, 23 Sep 1997 18:42:58 +0930 (CST) Message-ID: <19970923184258.06528@lemis.com> Date: Tue, 23 Sep 1997 18:42:58 +0930 From: Greg Lehey To: "Jordan K. Hubbard" Cc: Simon Shapiro , "Justin T. Gibbs" , freebsd-current@FreeBSD.ORG Subject: Re: Compile failure on today's current kernel References: <6275.875004359@time.cdrom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.81e In-Reply-To: <6275.875004359@time.cdrom.com>; from Jordan K. Hubbard on Tue, Sep 23, 1997 at 01:45:59AM -0700 Organisation: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8250 Fax: +61-8-8388-8250 Mobile: +61-41-739-7062 WWW-Home-Page: http://www.lemis.com/~grog Fight-Spam-Now: http://www.cauce.org Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Tue, Sep 23, 1997 at 01:45:59AM -0700, Jordan K. Hubbard wrote: >> Is there a presumption i do not read this mailing list? Because I do and >> never saw this before. Some of us are newer to FreeBSD than others. That, >> in and by itself is not an indication of degraded intelligence, you know. > > True. There probably needs to be a "-current rules of the road" > document somewhere, culled from our years of experience with this > entity called -current. > > Any takers? I'm kinda busy. ;-) Aaargh. Finger trouble. Yes, I'd like to, but I don't know how I can manage, so I really wanted to delete that last message. Sorry. Greg From owner-freebsd-current Tue Sep 23 02:17:01 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id CAA01126 for current-outgoing; Tue, 23 Sep 1997 02:17:01 -0700 (PDT) Received: from dyson.iquest.net (dyson.iquest.net [198.70.144.127]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id CAA01121 for ; Tue, 23 Sep 1997 02:16:58 -0700 (PDT) Received: (from root@localhost) by dyson.iquest.net (8.8.6/8.8.5) id DAA06787; Tue, 23 Sep 1997 03:09:50 -0500 (EST) From: "John S. Dyson" Message-Id: <199709230809.DAA06787@dyson.iquest.net> Subject: Re: New timeout capability (was Re: cvs commit:....) In-Reply-To: <199709230619.QAA20746@ogre.dtir.qld.gov.au> from Stephen McKay at "Sep 23, 97 04:19:00 pm" To: syssgm@dtir.qld.gov.au (Stephen McKay) Date: Tue, 23 Sep 1997 03:09:50 -0500 (EST) Cc: phk@critter.freebsd.dk, freebsd-current@FreeBSD.ORG, syssgm@dtir.qld.gov.au X-Mailer: ELM [version 2.4ME+ PL31 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Stephen McKay said: > On Monday, 22nd September 1997, Poul-Henning Kamp wrote: > > >In message <199709221910.NAA02147@rocky.mt.sri.com>, Nate Williams writes: > > > >>Can you explain a bit more about your 'rover' setup, and how it's used? > > > >The "rover" in my lab is named after it's more adventurous namesake > >on Mars... > > [Fun workbench elided] > > Sounds like an excellent setup! Wow, hard facts! > > >If you have a change you want tested, I should be able to give > >the result back to you in one or two days. (I only ask in return > >that I may publish the results in case I write a paper on this > >experiment later on). > > I've always wanted to know how much it costs to run with 4Kb file system > blocks vs 8Kb or now even 16Kb. Oh, and the real cost of various minfree > percentages. No obligation, of course, but you might be interested too... > 32K or even 64K should work :-). With our upcoming dynamic buffer size allocation, we could even do 256K? :-). -- John dyson@freebsd.org jdyson@nc.com From owner-freebsd-current Tue Sep 23 02:20:12 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id CAA01252 for current-outgoing; Tue, 23 Sep 1997 02:20:12 -0700 (PDT) Received: from dyson.iquest.net (dyson.iquest.net [198.70.144.127]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id CAA01247 for ; Tue, 23 Sep 1997 02:20:08 -0700 (PDT) Received: (from root@localhost) by dyson.iquest.net (8.8.6/8.8.5) id EAA00190; Tue, 23 Sep 1997 04:20:00 -0500 (EST) From: "John S. Dyson" Message-Id: <199709230920.EAA00190@dyson.iquest.net> Subject: Re: New timeout capability (was Re: cvs commit:....) In-Reply-To: <199709230818.SAA07263@troll.dtir.qld.gov.au> from Stephen McKay at "Sep 23, 97 06:18:58 pm" To: syssgm@dtir.qld.gov.au (Stephen McKay) Date: Tue, 23 Sep 1997 04:20:00 -0500 (EST) Cc: freebsd-current@FreeBSD.ORG, syssgm@dtir.qld.gov.au Reply-To: dyson@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL31 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Stephen McKay said: > >> > >32K or even 64K should work :-). With our upcoming dynamic buffer size > >allocation, we could even do 256K? :-). > > Gods! What for? (Ok, that's just an initial exclamation.) > > My curiosity about the 4Kb vs 8Kb derives from the good job the clustering > code does. If we have good clustering, then why have big block sizes? They > just move the breakpoints for max file size before indirect blocks are > needed (and similarly the max file size that can have fragments). > Actually, it is mostly a matter of minimizing the amount of accounting the system does building up the "big buffers" on the fly with clustering. Actually, I was very much jesting :-). I could possibly imagine a reasonable use for a 16K basic allocation size. I think that 4K performs pretty darned well anyway though. In the real world, I wouldn't think that one would see much of a performance difference between 4K and 16K. I am sure that iozone will measure a few percent better performance though. 256K is borderline silly, but would be interesting to try just once. It would waste one hell of a lot of space on most often U**X filesystem distributions. Now, all this said, it will be helpful to support 256K or bigger clusters, esp on writes. But, the userland visible block size shouldn't often have to be bigger than 4-16K. -- John dyson@freebsd.org jdyson@nc.com From owner-freebsd-current Tue Sep 23 02:41:43 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id CAA01806 for current-outgoing; Tue, 23 Sep 1997 02:41:43 -0700 (PDT) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id CAA01801 for ; Tue, 23 Sep 1997 02:41:40 -0700 (PDT) Received: (from daemon@localhost) by alpo.whistle.com (8.8.5/8.8.5) id BAA02627; Tue, 23 Sep 1997 01:53:36 -0700 (PDT) Received: from current1.whistle.com(207.76.205.22) via SMTP by alpo.whistle.com, id smtpd002625; Tue Sep 23 08:53:35 1997 Date: Tue, 23 Sep 1997 02:33:39 -0700 (PDT) From: Julian Elischer To: "Justin T. Gibbs" cc: Terry Lambert , nate@mt.sri.com, bde@zeta.org.au, current@FreeBSD.ORG Subject: Re: cvs commit: src/sys/conf files src/sys/dev/vx if_vx.c if_vxreg.h src/sys/i386/apm apm.c src/sys/i386/conf GENERIC files.i386 In-Reply-To: <199709230630.AAA13505@pluto.plutotech.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Tue, 23 Sep 1997, Justin T. Gibbs wrote: > >> >Queue the entry for ordered insertion when timeout() is called, but > >> >delay the ordered insertion until softclock(). his was one of the things I have been wondering about. if each spoke of the wheel had an orderd and an unordered queue, then items would USUALLY be removed before their bucket was accessed. Any remaining ones could be moved to the ordered "long term" queue. In fact it might be arguable that they could be removed from the wheel entirely after surviving a full rotation of the softclock. They could be inserted into a timeout queue not disimilar to that we already run. The point is that there are several distinct usage models for the timeout facility. They have differnt characteristics.. HARDWARE FAILURE TIMEOUTS: nearly ALWAYS expected to be removed very quickly. Ordering these is a complete waste of time. PERIODIC EVENTS: nearly always time out. These tend to be of duration of a large fraction of a second. Possibly it might be more efficient to have a different mechanism for periodic events. LONG TERM EVENT timing: These tend to be longer in duration, but are not recuring. These will be hit by the softclock several times. This could be considered a waste of resources, if we could hold them off for a while we should. > >> > >> Sounds like it will take additional space. I guess that's unarguable. But a large wheel implies a lot of processes which implies a lot of RAM :) > Two pointers is additional space. It also makes softclock become > q * O(h) + O(c) where q is the number of defered insertion entries, > h is the hash chain length and c is the number of empty buckets > that are traversed to find the next timeout for scheduling the next > one shot. I see it as being (on each softclock) O(H x C)+1 where H is the unexpired (remaining) unorderd entries and C is the length of the unordered queue for that bucket. The hope is that MOST short term items are removed BEFORE the softclock gets to them, and that any remaining items are probably long term items that should not be examined at every following rotation. I would even consider that there should be 3 (!) entries at each bucket. Items move in un-sorted order from 1 to 2 and are then inserted in order into 3. Items going into 3 are Guarenteed to have survived at LEAST one full rotation, and can be assumed to be long-term. If the wheel is very sparcely populated it doesn't gain much, but then again it isn't that much more expensive than what you have now. When the wheel get's heavily populated, or when there are a lot of long-term entries it saves time. > Then there is the additional code in softclock to ensure > that none of the timeouts queued while softclock is running are > supposed to expire in the current tick which you would need to > check every time softclock drops from splhigh to let other interrupts > run as there is nothing to prevent a timeout handler or interrupt > handler from scheduling such an entry. Sure, it's do-able, but > the current implementation doesn't have any of this mess and still > gets the O(1) insertion and softclock pays a single O(h). Moving the items from queue 1 to queue 2 to queue 3 can make the whole thing less susceptible to spl issues. first, check the ordered queue. O(1) Then move items from 2 into the orderded queue (3). (hopefully few) Then move items from the head of 1 to the tail of 2. (moving being not much more expensive than checking) These were my thoughts while reading the paper. I was a little dissapointed that you didn't implement the compatible interface that they originally wrote. WHat is the right answer will depend greatly on the particular usage model. A method of trying to handle these different models is probably worth working for. Especialy as networking code switches to using more generic timeouts. If you disconnect a network, we suddenly get hundreds of actual networking timeouts..... > > > Regards, > > Terry Lambert > > terry@lambert.org > >--- > >Any opinions in this posting are my own and not those of my present > >or previous employers. > > > > -- > Justin T. Gibbs > =========================================== > FreeBSD: Turning PCs into workstations > =========================================== > From owner-freebsd-current Tue Sep 23 03:10:35 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id DAA02653 for current-outgoing; Tue, 23 Sep 1997 03:10:35 -0700 (PDT) Received: from rah.star-gate.com (rah.star-gate.com [204.188.121.18]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id DAA02647 for ; Tue, 23 Sep 1997 03:10:31 -0700 (PDT) Received: from rah.star-gate.com (localhost.star-gate.com [127.0.0.1]) by rah.star-gate.com (8.8.7/8.8.5) with ESMTP id DAA04493; Tue, 23 Sep 1997 03:10:14 -0700 (PDT) Message-Id: <199709231010.DAA04493@rah.star-gate.com> To: Simon Shapiro cc: "Justin T. Gibbs" , freebsd-current@FreeBSD.ORG Subject: Re: Compile failure on today's current kernel In-reply-to: Your message of "Tue, 23 Sep 1997 00:01:56 PDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 23 Sep 1997 03:10:14 -0700 From: Amancio Hasty Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Don't worry there ought to be a mechanism for forcing the users to use the new config if it is required. Maybe a shell wrapper that before invoking the real config it rebuilds config and then runs the newly built config program . The config program if people care to make it interesting it could compile in the appropiate kernel version which can be specificy from an include file -- that is if people don't want to recompile config every time. To avoid hazzles config could be incorporated into the kernel sources yet another way of ensuring that the right config is compile for the respective kernel. As for the style of the response, is more like, Unix Sergeant to a Private: "Private, have you re-built config?!!!!" "For heaven's sake please read the mailing list, if you don't systems die!!" I guess that approach is okay however there ought to be a better mechanism perhaps a "web page" which states interesting gotchas. Nothing formal of course, I am not interested in the philosophical merits of the Web in HyperSpace 8) To be honest , I guess is a whole lot more fun to play the "Unix Sergeant" 8) Cheers, Amancio >From The Desk Of Simon Shapiro : > > Hi "Justin T. Gibbs"; On 23-Sep-97 you wrote: > > >Any particular reason I am getting the following? > > > > You didn't rebuild config. > > I found that out and was told already. > My apologies and my thanks. > > > > If you're going to run current, read the current mailing list. > > Is there a presumption i do not read this mailing list? Because I do and > never saw this before. Some of us are newer to FreeBSD than others. That, > in and by itself is not an indication of degraded intelligence, you know. > > > This is not the first time this question was asked and answered. > > > > >loading kernel > > >isa.o: Undefined symbol `_isa_devtab_cam' referenced from text segment > > > > ... > > > > >--- > > > > > > > > >Sincerely Yours, (Sent on 22-Sep-97, > > >22:38:39 > > >by XF-Mail) > > > > > >Simon Shapiro Atlas > > >Telecom > > >Senior Architect 14355 SW Allen Blvd., Suite 130 Beaverton OR > > >97005 > > >Shimon@i-Connect.Net Voice: 503.643.5559, Emergency: > > >503.799.2313 > > > > > > > -- > > Justin T. Gibbs > > =========================================== > > FreeBSD: Turning PCs into workstations > > =========================================== > > --- > > > Sincerely Yours, (Sent on 22-Sep-97, 23:58:28 > by XF-Mail) > > Simon Shapiro Atlas Telecom > Senior Architect 14355 SW Allen Blvd., Suite 130 Beaverton OR 97005 > Shimon@i-Connect.Net Voice: 503.643.5559, Emergency: 503.799.2313 From owner-freebsd-current Tue Sep 23 06:25:39 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id GAA10661 for current-outgoing; Tue, 23 Sep 1997 06:25:39 -0700 (PDT) Received: from morse.satech.net.au (morse.satech.net.au [203.56.210.66]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id GAA10653 for ; Tue, 23 Sep 1997 06:25:33 -0700 (PDT) Received: from matte.box.net.au (matte.satech.net.au [203.1.91.219]) by morse.satech.net.au (8.8.5/8.8.5.SAT.GJR.970426) with ESMTP id WAA13959; Tue, 23 Sep 1997 22:55:37 +0930 Received: from box.net.au (localhost.satech.net.au [127.0.0.1]) by matte.box.net.au (8.8.7/8.7.3) with ESMTP id WAA01407; Tue, 23 Sep 1997 22:56:18 +0930 (CST) Message-ID: <3427C377.A89A2A38@box.net.au> Date: Tue, 23 Sep 1997 22:56:15 +0930 From: Matthew Thyer X-Mailer: Mozilla 4.03b8 [en] (X11; I; FreeBSD 3.0-CURRENT i386) MIME-Version: 1.0 To: Ollivier Robert CC: freebsd-current@FreeBSD.ORG Subject: Re: Netscape 4.03b8 doesn't work after poll/select changes References: <19970922160600.17406@caerdonn.eurocontrol.fr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Me too... it just sits there using all the CPU. no window comes up. this happens most of the time unless I am connected to the net through my ppp link. I'm using 3.3.1 too. Ollivier Robert wrote: > > I have a problem with Netscape since the poll/select changes... It doesn't > work at all. No window is displayed and the process seems to be sleeping in [snip] > > Am I the only one ? > > -CURRENT from 9/16 around 3 PM. > -- > Ollivier ROBERT -=- Eurocontrol EEC/TS -=- Ollivier.Robert@eurocontrol.fr -- /=====================================================================\ | Work: Matthew.Thyer@dsto.defence.gov.au | Home: thyerm@box.net.au | \=====================================================================/ "If it is true that our Universe has a zero net value for all conserved quantities, then it may simply be a fluctuation of the vacuum of some larger space in which our Universe is imbedded. In answer to the question of why it happened, I offer the modest proposal that our Universe is simply one of those things which happen from time to time." E. P. Tryon from "Nature" Vol.246 Dec.14, 1973 From owner-freebsd-current Tue Sep 23 06:59:15 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id GAA12136 for current-outgoing; Tue, 23 Sep 1997 06:59:15 -0700 (PDT) Received: from pluto.plutotech.com (root@mail.plutotech.com [206.168.67.137]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id GAA12129 for ; Tue, 23 Sep 1997 06:59:07 -0700 (PDT) Received: from narnia.plutotech.com (narnia.plutotech.com [206.168.67.130]) by pluto.plutotech.com (8.8.5/8.8.5) with ESMTP id HAA20804; Tue, 23 Sep 1997 07:59:01 -0600 (MDT) Message-Id: <199709231359.HAA20804@pluto.plutotech.com> To: Simon Shapiro cc: "Justin T. Gibbs" , freebsd-current@FreeBSD.ORG Subject: Re: Compile failure on today's current kernel In-reply-to: Your message of "Tue, 23 Sep 1997 00:01:56 PDT." Date: Tue, 23 Sep 1997 07:58:49 -0600 From: "Justin T. Gibbs" Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > >> If you're going to run current, read the current mailing list. > >Is there a presumption i do not read this mailing list? Because I do and >never saw this before. Some of us are newer to FreeBSD than others. That, >in and by itself is not an indication of degraded intelligence, you know. Okay. How about this. If you have a problem with current, catch up on reading the current mailing list before posting about your problem. There is a good chance that it's already been discussed. I wasn't implying anything about your inteligence, but if you really did miss the three messages about this topic that came before yours, you should read current a little more carefully. 8-) >--- > > >Sincerely Yours, (Sent on 22-Sep-97, 23:58:28 >by XF-Mail) > >Simon Shapiro Atlas Telecom >Senior Architect 14355 SW Allen Blvd., Suite 130 Beaverton OR 97005 >Shimon@i-Connect.Net Voice: 503.643.5559, Emergency: 503.799.2313 > -- Justin T. Gibbs =========================================== FreeBSD: Turning PCs into workstations =========================================== From owner-freebsd-current Tue Sep 23 07:40:57 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id HAA14241 for current-outgoing; Tue, 23 Sep 1997 07:40:57 -0700 (PDT) Received: from mail.cs.tu-berlin.de (root@mail.cs.tu-berlin.de [130.149.17.13]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id HAA14234 for ; Tue, 23 Sep 1997 07:40:52 -0700 (PDT) Received: from panke.panke.de (anonymous213.ppp.cs.tu-berlin.de [130.149.17.213]) by mail.cs.tu-berlin.de (8.8.6/8.8.6) with ESMTP id QAA24154 for ; Tue, 23 Sep 1997 16:39:43 +0200 (MET DST) Received: (from wosch@localhost) by panke.panke.de (8.8.5/8.6.12) id QAA03153; Tue, 23 Sep 1997 16:37:41 +0200 (MET DST) Date: Tue, 23 Sep 1997 16:37:41 +0200 (MET DST) Message-Id: <199709231437.QAA03153@panke.panke.de> From: Wolfram Schneider To: current@freebsd.org Subject: realtime priority support for top(1) MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk The patch print the real/idle time priority in the nice field. normal time -> nice value -20 - +20 real time 0 - 31 -> nice value -52 - -21 idle time 0 - 31 -> nice value +21 - +52 [-stable patch] Index: machine.c =================================================================== RCS file: /usr/cvs/src/usr.bin/top/machine.c,v retrieving revision 1.3.2.1 diff -u -r1.3.2.1 machine.c --- machine.c 1997/05/31 03:18:12 1.3.2.1 +++ machine.c 1997/09/23 14:36:04 @@ -38,6 +38,8 @@ #include #include #include +#include +#include /* Swap */ #include @@ -584,7 +586,17 @@ PP(pp, p_pid), (*get_userid)(EP(pp, e_pcred.p_ruid)), PP(pp, p_priority) - PZERO, - PP(pp, p_nice) - NZERO, + + /* + * normal time -> nice value -20 - +20 + * real time 0 - 31 -> nice value -52 - -21 + * idle time 0 - 31 -> nice value +21 - +52 + */ + (PP(pp, p_rtprio.type) == RTP_PRIO_NORMAL ? + PP(pp, p_nice) - NZERO : + (PP(pp, p_rtprio.type) == RTP_PRIO_REALTIME ? + (PRIO_MIN - 1 - RTP_PRIO_MAX + PP(pp, p_rtprio.prio)) : + (PRIO_MAX + 1 + PP(pp, p_rtprio.prio)))), format_k2(pagetok(PROCSIZE(pp))), format_k2(pagetok(VP(pp, vm_rssize))), status, -- Wolfram Schneider http://www.apfel.de/~wosch/ From owner-freebsd-current Tue Sep 23 07:53:19 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id HAA14764 for current-outgoing; Tue, 23 Sep 1997 07:53:19 -0700 (PDT) Received: from ns.mt.sri.com (SRI-56K-FR.mt.net [206.127.65.42]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id HAA14758 for ; Tue, 23 Sep 1997 07:53:08 -0700 (PDT) Received: from rocky.mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.8.7/8.8.7) with ESMTP id IAA21887; Tue, 23 Sep 1997 08:52:56 -0600 (MDT) Received: (from nate@localhost) by rocky.mt.sri.com (8.7.5/8.7.3) id IAA07122; Tue, 23 Sep 1997 08:52:51 -0600 (MDT) Date: Tue, 23 Sep 1997 08:52:51 -0600 (MDT) Message-Id: <199709231452.IAA07122@rocky.mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Julian Elischer Cc: "Justin T. Gibbs" , Terry Lambert , nate@mt.sri.com, bde@zeta.org.au, current@freebsd.org Subject: new timeout routines In-Reply-To: References: <199709230630.AAA13505@pluto.plutotech.com> X-Mailer: VM 6.29 under 19.15 XEmacs Lucid Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > >> >Queue the entry for ordered insertion when timeout() is called, but > > >> >delay the ordered insertion until softclock(). > > his was one of the things I have been wondering about. > if each spoke of the wheel had an orderd and an unordered queue, > then items would USUALLY be removed before their > bucket was accessed. Any remaining ones could be > moved to the ordered "long term" queue. The issue is will the entries in the "long term" queue now be accessed enough times to make inserting them in an ordered list to make it wortwhile to insert them into the ordered list. We'd be now getting a much smaller speedup, since softclock() would still have to walk the un-ordered list (which would contain the majority of the items), and now we're taken some (how many?) of those items off the unordered list and put them on an ordered list. My gut feeling is that if we don't take the hit up front (at timeout), then don't bother at all since we're only getting a minimal gain. > They could be inserted into a timeout queue not disimilar to that we > already run. The point is that there are several distinct usage models for > the timeout facility. They have differnt characteristics.. > HARDWARE FAILURE TIMEOUTS: nearly ALWAYS expected to be removed very > quickly. Ordering these is a complete waste of time. But, they will tend to go away. > PERIODIC EVENTS: nearly always time out. These tend to be of duration of > a large fraction of a second. Possibly it might be more efficient > to have a different mechanism for periodic events. > > LONG TERM EVENT timing: These tend to be longer in duration, but are not > recuring. These will be hit by the softclock several times. This > could be considered a waste of resources, if we could hold them off for a > while we should. How many of the bottom 2 types are there, and will searching for them in an un-ordered list make *that* much difference given the number of first type that are on an un-ordered list. > If the wheel is very sparcely populated it doesn't gain much, but then > again it isn't that much more expensive than what you have now. It doesn't gain much, but neither does it cost much. Now there's some logic. :) > When the wheel get's heavily populated, or when there are a lot of > long-term entries it saves time. I suspect that when the wheels' heavily populated, most of the entries will be of the short-term type, so ordering the long-term values is a non-win. > These were my thoughts while reading the paper. I was a little > dissapointed that you didn't implement the compatible interface that > they originally wrote. Now, this is something I don't understand. Why the need for the 'cookies' in the drivers, since I don't see what it gains us? (Time to go re-read the code and paper again.) Nate From owner-freebsd-current Tue Sep 23 09:13:48 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id JAA18692 for current-outgoing; Tue, 23 Sep 1997 09:13:48 -0700 (PDT) Received: from usr01.primenet.com (tlambert@usr01.primenet.com [206.165.6.201]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id JAA18685 for ; Tue, 23 Sep 1997 09:13:25 -0700 (PDT) Received: (from tlambert@localhost) by usr01.primenet.com (8.8.5/8.8.5) id JAA09972; Tue, 23 Sep 1997 09:13:08 -0700 (MST) From: Terry Lambert Message-Id: <199709231613.JAA09972@usr01.primenet.com> Subject: Re: cvs commit: src/sys/conf files src/sys/dev/vx if_vx.c if_vxreg.h src/sys/i386/apm apm.c src/sys/i386/conf GENERIC files.i386 To: gibbs@plutotech.com (Justin T. Gibbs) Date: Tue, 23 Sep 1997 16:13:06 +0000 (GMT) Cc: tlambert@primenet.com, gibbs@plutotech.com, nate@mt.sri.com, bde@zeta.org.au, current@FreeBSD.ORG In-Reply-To: <199709230630.AAA13505@pluto.plutotech.com> from "Justin T. Gibbs" at Sep 23, 97 00:30:25 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > >> >So the question to as is "how many softclocks does the average timer > >> >entry live across?". > >> > >> Go read the code. > > > >This one was less rhetorical, and required an empirical judgement on > >your part to get the same conclusion I had already made. It's called > >a Socratic Dialectic. > > Bullshit. You stated that every entry would be touched on each softtick. No I did not. Look at my sentence you quote in your response: > >> >So the question to as is "how many softclocks does the average timer > >> >entry live across?". This has nothing to do with claiming that every entry would be touched on every softclock. It has to do with an entry living, on average, 8 or more softclocks. This is being generous, since it accepts your number of users (32) instead of the GENERIC number of users (10) to obtain a total of 256 buckets. > Sure I have. On each softclock, the number of timers enqueued in > all buckets is the number of callouts outstanding which I've said > is around 30 for a typical workstation. Of course you probably > meant to ask what the average length of a hash chain is and to > answer that question for the loads I'm interested in, I'd have to > instrument the code. I expect it to be h where h << n and n is > the total number of callouts outstanding. Well duh, or it wouldn't be a hash; the actual *average* would be 256/30 assuming a *perfect* hash. If an entry lives greater than 8.53 ticks, it will get hit twice. On average, gor the algorithm to be less than O(n), any single entry must live 8 or less softclock ticks. > > >> An entry will only have it's count decremented if, during it's lifetime, > >> softclock traverses the list of callouts in it's hash bucket. It may > >> take numerous calls to softclock before it touches the bucket where > >> a particular callout is placed. > > > >Nate's point was that this assumes one entry per hash bucket, on average. > > No it doesn't. For example, here is a 4 bucket call wheel: > > 1 2 3 4 > + + + + > x a b d > + + + > y c f > + + > z e > > Lets say that softclock is currently at bucket 2. When will entries > x, y, and z next be referenced? During the call to softclock 3 ticks > in the future. If any of x, y, or z are removed before that time, > they will not be referenced. The average hash chain length in this > callwheel is a little over 2. 2.25. Even I can accurately divide 9 by 4. You still haven't answered the question about the expected average lifetime of an entry. Is an entry expected to be hit by one or more softclocks in its lifetime? *THAT* is the question. The x in O(x) is the average number of times that any given entry can expect to be hit by a softclock. > >For the default of 10 users in GENERIC, I think this is a bad assumption. > >Even for 32 users (256 buckets), it's stretching things if the timers > >see any real use at all. > > The hash table size is still larger than the total number of callouts > that can be outstanding. Do the callouts that are outstanding live more than 8 ticks? > >> >Queue the entry for ordered insertion when timeout() is called, but > >> >delay the ordered insertion until softclock(). > >> > >> Sounds like it will take additional space. > > > >No. It will take two additional pointers and a trivial amount of > >code identical to the code you would need anyway. > > Two pointers is additional space. Now who is really picking nits? It's a hell of a lot less space than you are already using, and it's statically allocated. > It also makes softclock become q * O(h) + O(c) where q is the number > of defered insertion entries, h is the hash chain length and c is > the number of empty buckets that are traversed to find the next > timeout for scheduling the next one shot. This calculation is incorrect, since I am suggesting not using a hash in the case of an ordered list. If you will remember, this was a compromise for your complaint that insertion at interrupt was not O(1). You weren't worried about time in softclock until I figured out how to move the overhead there. Even so, you're still not worried about determinism in softclock; one indeterminate value is as good as any other. > Then there is the additional code in softclock to ensure > that none of the timeouts queued while softclock is running are > supposed to expire in the current tick which you would need to > check every time softclock drops from splhigh to let other interrupts > run as there is nothing to prevent a timeout handler or interrupt > handler from scheduling such an entry. Softclock need only check the tick values from the head, and may stop when it hits the first entry whose tick value exceeds the current tick value; remember, the list under discussion is ordered? You were also the one that argued that insertion and deletion were relatively rare. > Sure, it's do-able, but > the current implementation doesn't have any of this mess and still > gets the O(1) insertion and softclock pays a single O(h). O(h * (avg lifetime in ticks of any entry / 8)) If you can show the average lifetime to be less than 8, then this means your algorithm is even better than you initially claimed... Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-current Tue Sep 23 11:57:11 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id LAA27448 for current-outgoing; Tue, 23 Sep 1997 11:57:11 -0700 (PDT) Received: from watermarkgroup.com (lor.watermarkgroup.com [38.246.139.30]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id LAA27442 for ; Tue, 23 Sep 1997 11:57:07 -0700 (PDT) Received: by watermarkgroup.com (4.1/SMI-4.1) id AA28682; Tue, 23 Sep 97 14:56:31 EDT Date: Tue, 23 Sep 97 14:56:31 EDT From: luoqi@watermarkgroup.com (Luoqi Chen) Message-Id: <9709231856.AA28682@watermarkgroup.com> To: roberto@eurocontrol.fr, thyerm@box.net.au Subject: Re: Netscape 4.03b8 doesn't work after poll/select changes Cc: freebsd-current@FreeBSD.ORG Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Try adding this line to /usr/local/bin/netscape, export XCMSDB; XCMSDB=/dev/null XF86 3.3.x uses CMS to do color lookup, and because of some FPE related bugs it would go into an infinite loop. Disable the CMS lookup seems to circumvent this problem, but it might surface later at some other part of the code. -lq From owner-freebsd-current Tue Sep 23 12:19:52 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id MAA28563 for current-outgoing; Tue, 23 Sep 1997 12:19:52 -0700 (PDT) Received: from pluto.plutotech.com (root@mail.plutotech.com [206.168.67.137]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id MAA28558 for ; Tue, 23 Sep 1997 12:19:50 -0700 (PDT) Received: from narnia.plutotech.com (narnia.plutotech.com [206.168.67.130]) by pluto.plutotech.com (8.8.5/8.8.5) with ESMTP id NAA28306; Tue, 23 Sep 1997 13:19:26 -0600 (MDT) Message-Id: <199709231919.NAA28306@pluto.plutotech.com> X-Mailer: exmh version 2.0zeta 7/24/97 To: Terry Lambert cc: gibbs@plutotech.com (Justin T. Gibbs), nate@mt.sri.com, bde@zeta.org.au, current@FreeBSD.ORG Subject: Re: cvs commit: src/sys/conf files src/sys/dev/vx if_vx.c if_vxreg.h src/sys/i386/apm apm.c src/sys/i386/conf GENERIC files.i386 In-reply-to: Your message of "Tue, 23 Sep 1997 17:32:12 -0000." <199709231732.KAA15236@usr01.primenet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 23 Sep 1997 13:19:15 -0600 From: "Justin T. Gibbs" Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >256 hash buckets divided by 30 expected entries is 8.53 softclocks >before a given entry is hit. Not "before a given entry is hit", "before any entries are hit". Your argument is that every 8.53 softclocks the hash chain will not be empty. So, just because a callout lives longer than 8.53 softclocks, does not mean that this callout will be the one touched by softclock. The assertion that a particular callout must live callwheel size ticks in order to be touched more than once still holds. >> A MAXUSERS of 32 creates a callwheel size of 1024. A MAXUSERS of 10 >> creates a callwheel size of 256. > >GENERIC results in 10. I was actually going by what you said to Nate >here, and not the code. Then you missed the post where I actually posted the code correcting my first comment on the size to Nate. I posted the correction almost immediately after I said the size for MAXUSERS of 32 was 256. >> >If an entry lives greater than 8.53 ticks, it will get hit twice. >> >On average, for the algorithm to be less than O(n), any single entry >> >must live 8 or less softclock ticks. >> >> You're digging a hole Terry. An entry must live for callwheel size >> ticks in order to be touched twice during it's lifetime. > >The "twice" here refers to the number of entries that will be hit in a >given bucket on average. On average, if I have 30 entries with an >expected lifetime of 8.53 softclocks with a 256 bucket hash, then I >have one lifetime per hash bucket. I don't understand what you are trying to say. If I have 30 entries outstanding, then there are 30 entries outstanding when softclock runs regardless of the frequency of insertion or removal, or their lifetime. >> The question should be, do they live longer than 256 ticks. > >No. The question is "do they live longer than 256/number_outstanding"; >for 30 entries, that's still 8. You still have the question wrong. >> >This calculation is incorrect, since I am suggesting not using a hash >> >in the case of an ordered list. >> >> So you want softclock to become q * O(n) and ditch the hash table. > >For n entries queued since the last softclock, yes. Let's not confuse >this with the number of entries, total, in the ordered list. My calculation was for q being the numbered of entries queued since the last softclock and n outstanding entries already in the sorted list. I don't see how you can make this O(q) instead of O(n). >When you say "an unordered queue for each head in the hash table", >do you mean that if there is an entry in both the ordered and unordered >lists, the unordered list entries will be inserted into the ordered >list on a per bucket basis? If there are entries in the unordered list, they are insertion sorted into the ordered list. Whether there are entries in the ordered list or not has no effect on whether the insertions are made. If you don't do the insertion, you may miss the proper next entry to schedule the one shot for as it may be in the unordered list. >This is the O(n/256) (again, assuming perfect hash) degradation, but >at softclock instead of at insertion; insertion is still O(1). Right. >> >You were also the one that argued that insertion and deletion were >> >relatively rare. >> >> I argued exactly the opposite. Insertion and deletion are the common >> case, expiration is rare. > >Ugh. What I meant to say was that the number of entries outstanding >at one time relative to the number of insertions and deletions that >take place is small in proportion to the number of hash buckets. This >would make it relatively rare that a softclock would ever hit an entry. >It was this rarity I meant to reference, but my fingers were too fast. I don't know how rare it is really. You'd have to do some statistics relating which bucket softclock is currently looking at and the likelihood of a new timeout being scheduled "close" to that position. I do know that it is going to be quite rare to have a callout touched more than once during it's lifetime. 256 ticks is a long time. 1024 ticks is even longer. > Regards, > Terry Lambert > terry@lambert.org >--- >Any opinions in this posting are my own and not those of my present >or previous employers. -- Justin T. Gibbs =========================================== FreeBSD: Turning PCs into workstations =========================================== From owner-freebsd-current Tue Sep 23 09:22:11 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id JAA19255 for current-outgoing; Tue, 23 Sep 1997 09:22:11 -0700 (PDT) Received: from usr01.primenet.com (tlambert@usr01.primenet.com [206.165.6.201]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id JAA19248 for ; Tue, 23 Sep 1997 09:22:01 -0700 (PDT) Received: (from tlambert@localhost) by usr01.primenet.com (8.8.5/8.8.5) id JAA10443; Tue, 23 Sep 1997 09:20:32 -0700 (MST) From: Terry Lambert Message-Id: <199709231620.JAA10443@usr01.primenet.com> Subject: Re: callouts in CAM (was Re: cvs commit:) To: gibbs@plutotech.com (Justin T. Gibbs) Date: Tue, 23 Sep 1997 16:20:31 +0000 (GMT) Cc: tlambert@primenet.com, gibbs@plutotech.com, nate@mt.sri.com, bde@zeta.org.au, current@FreeBSD.org In-Reply-To: <199709230634.AAA13555@pluto.plutotech.com> from "Justin T. Gibbs" at Sep 23, 97 00:34:32 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > >You stated before that you could simply block the request that would > >have made use of a newly allocated resource until such time as one of > >the existing entries becomes availble. I'd hate to see max allocation > >up front in all cases. 8-(. > > New work comes in. There are no CCBs/callouts available in the > free pool. An attempt is made to allocate a CCB and it's corresponding > callout. If that fails (malloc failure), I wait for an existing > CCB/callout to come free. Where does this contradict what I said > above? Nowhere. You didn't quote your original anti-watermarking sentiment when you quoted me. ;-). > Where is the max allocation up front? I allocate on demand. There is no reason not to watermark the free pool. It has the advantage that you can return memory to the system, and allocations can occur in page units. A failed allocation at a low watermark can be ignored until the pool is truly empty, at which time you can fail using the mthod you are already using. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-current Tue Sep 23 11:36:02 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id LAA26208 for current-outgoing; Tue, 23 Sep 1997 11:36:02 -0700 (PDT) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id LAA26170 for ; Tue, 23 Sep 1997 11:35:57 -0700 (PDT) Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.5/8.6.9) id EAA17215; Wed, 24 Sep 1997 04:34:51 +1000 Date: Wed, 24 Sep 1997 04:34:51 +1000 From: Bruce Evans Message-Id: <199709231834.EAA17215@godzilla.zeta.org.au> To: freebsd-current@freebsd.org, j@uriah.heep.sax.de Subject: Re: Assertion failed in ncr driver Cc: roberto@keltia.freenix.fr Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >> Any idea why I get these ? >> >> assertion "cp" failed: file "../../pci/ncr.c", line 6227 >> sd0: COMMAND FAILED (4 28) @f0765800. >> assertion "cp" failed: file "../../pci/ncr.c", line 6227 >> sd0: COMMAND FAILED (4 28) @f0765c00. > >I'm seeing the same errors occasionally for the IBM DCAS-34330 (not >the `W' in my case, and only a NCR 53c810), also when dump(8)ing. I get these for an IBM DORS-32160 WA6A. They are apparently a feature of IBM firmware :-). They are almost reproducible using lmdd and lm's `fileblocks' in a loop. They never seem to cause file system problems. Bruce From owner-freebsd-current Tue Sep 23 11:27:41 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id LAA25639 for current-outgoing; Tue, 23 Sep 1997 11:27:41 -0700 (PDT) Received: from sendero-ppp.i-connect.net (sendero-ppp.i-Connect.Net [206.190.143.100]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id LAA25632 for ; Tue, 23 Sep 1997 11:27:38 -0700 (PDT) Received: (qmail 1365 invoked by uid 1000); 23 Sep 1997 18:27:54 -0000 Message-ID: X-Mailer: XFMail 1.2-alpha-091897 [p0] on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit MIME-Version: 1.0 Date: Tue, 23 Sep 1997 11:27:54 -0700 (PDT) Organization: Atlas Telecom From: Simon Shapiro To: freebsd-current@freebsd.org, freebsd-scsi@freebsd.org Subject: DPT Driver for FreeBSD Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi Y'all I apologize for the cross-posting, but really wanted to make sure all interested parties see this brief note. I have applied the DPT driver to the latest -current kernel. This was done to reflect the splcam changes. The patch, now available on ftp://sendero-ppp.i-connect..net/crash as dpt_1.2.5-current.patch was tested by running it on sendero for 24 hours and running it through our normal regression suite. It passed with flying colors. We have not applied any metrics yet. Performance testing will come later this week. IMPORTANT AVAILABILITY NOTE: As both myself and my employer are going through a review process, evaluating our policy in regards to the FreeBSD project, please note and respect the following: The availability of the driver on an anonymous FTP server, without password checking (or other security measures), is not to be interpreted as publishing the software, nor donating it to the FreeBSD project, nor relinquishing any right to it. Those of you who have an interest in this software, please drop me a note and I will make it available to you. If you have any comments on this issue, please contact me directly. Thanx! --- Sincerely Yours, (Sent on 23-Sep-97, 10:47:38 by XF-Mail) Simon Shapiro Atlas Telecom Senior Architect 14355 SW Allen Blvd., Suite 130 Beaverton OR 97005 Shimon@i-Connect.Net Voice: 503.643.5559, Emergency: 503.799.2313 From owner-freebsd-current Tue Sep 23 10:35:58 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id KAA22908 for current-outgoing; Tue, 23 Sep 1997 10:35:58 -0700 (PDT) Received: from usr01.primenet.com (tlambert@usr01.primenet.com [206.165.6.201]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id KAA22900 for ; Tue, 23 Sep 1997 10:35:52 -0700 (PDT) Received: (from tlambert@localhost) by usr01.primenet.com (8.8.5/8.8.5) id KAA15342; Tue, 23 Sep 1997 10:35:40 -0700 (MST) From: Terry Lambert Message-Id: <199709231735.KAA15342@usr01.primenet.com> Subject: Re: callouts in CAM (was Re: cvs commit:) To: gibbs@plutotech.com (Justin T. Gibbs) Date: Tue, 23 Sep 1997 17:35:39 +0000 (GMT) Cc: tlambert@primenet.com, gibbs@plutotech.com, nate@mt.sri.com, bde@zeta.org.au, current@FreeBSD.org In-Reply-To: <199709231658.KAA25032@pluto.plutotech.com> from "Justin T. Gibbs" at Sep 23, 97 10:57:56 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > >There is no reason not to watermark the free pool. It has the advantage > >that you can return memory to the system, and allocations can occur in > >page units. > > Sure, but that is not the case for the timeout and untimeout interface, > which, if you recall is what we are talking about. If a client calls > timeout and there are not entries left, and a new one cannot be allocated, > the interface does not allow this error to be propagated to the client. > If, on the other hand, the client is responsible for allocating it's > entry before it is used, the client can be smart about the failure. > > I don't want to change all of the clients of the timeout interface to make > them handle a resource failure. OK. My feeling was "in for a penny, in for a pound", meaning that if you change the interface, you might as well do everything you could want to it at once. Including propagating resource failure to the client. > I only want to modify the "heavy users" > and leave a common pool for other users of the interface. This is kind of at odds with the lack of a compatability interface... which isn't a terribly large problem, in itself. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-current Tue Sep 23 10:32:41 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id KAA22807 for current-outgoing; Tue, 23 Sep 1997 10:32:41 -0700 (PDT) Received: from usr01.primenet.com (tlambert@usr01.primenet.com [206.165.6.201]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id KAA22800 for ; Tue, 23 Sep 1997 10:32:36 -0700 (PDT) Received: (from tlambert@localhost) by usr01.primenet.com (8.8.5/8.8.5) id KAA15236; Tue, 23 Sep 1997 10:32:13 -0700 (MST) From: Terry Lambert Message-Id: <199709231732.KAA15236@usr01.primenet.com> Subject: Re: cvs commit: src/sys/conf files src/sys/dev/vx if_vx.c if_vxreg.h src/sys/i386/apm apm.c src/sys/i386/conf GENERIC files.i386 To: gibbs@plutotech.com (Justin T. Gibbs) Date: Tue, 23 Sep 1997 17:32:12 +0000 (GMT) Cc: tlambert@primenet.com, gibbs@plutotech.com, nate@mt.sri.com, bde@zeta.org.au, current@FreeBSD.ORG In-Reply-To: <199709231653.KAA24904@pluto.plutotech.com> from "Justin T. Gibbs" at Sep 23, 97 10:53:11 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > Actually lets look at the full context: Thanks! > >>For timeouts that live across softclock calls, as Nate is suggesting, > >>the list is traversed and the entry counts against the implementation > >>based on how many softclocks it lives across, on average. For ordered > >>insertion, the entry is counted against, once, at insertion time. > >> > >>So the question to as is "how many softclocks does the average timer > >>entry live across?". > > >This has nothing to do with claiming that every entry would be touched > >on every softclock. It has to do with an entry living, on average, 8 > >or more softclocks. > > That's not how I read it. And where do you come up with 8? 256 hash buckets divided by 30 expected entries is 8.53 softclocks before a given entry is hit. > >This is being generous, since it accepts your number of users (32) instead > >of the GENERIC number of users (10) to obtain a total of 256 buckets. > > A MAXUSERS of 32 creates a callwheel size of 1024. A MAXUSERS of 10 > creates a callwheel size of 256. GENERIC results in 10. I was actually going by what you said to Nate here, and not the code. > >> meant to ask what the average length of a hash chain is and to > >> answer that question for the loads I'm interested in, I'd have to > >> instrument the code. I expect it to be h where h << n and n is > >> the total number of callouts outstanding. > > > >Well duh, or it wouldn't be a hash; the actual *average* would be > >256/30 assuming a *perfect* hash. > > How can my average be 256/30 if 256 * 256 / 30 != 30? Total number of callouts outstanding. > >If an entry lives greater than 8.53 ticks, it will get hit twice. > >On average, for the algorithm to be less than O(n), any single entry > >must live 8 or less softclock ticks. > > You're digging a hole Terry. An entry must live for callwheel size > ticks in order to be touched twice during it's lifetime. The "twice" here refers to the number of entries that will be hit in a given bucket on average. On average, if I have 30 entries with an expected lifetime of 8.53 softclocks with a 256 bucket hash, then I have one lifetime per hash bucket. > Wow! Of course the point is that in the example, the hash chain length > is greater than 1 which nullifies your assertion. It nullifies it only if the timeout is used for 30 or less entries of 8.53 sofclocks diration or less for a 256 bucket hash. I think both yout duration and the number of events you expect to be outstanding at one time are low estimates based on who you think will be using the code. Julian actually made a number of good arguments for higher persistance timers. I think we have been arguing based on our own expected use of timers, so we haven't really been communicating very effectively because our initial conditions are different. Sorry. 8-(. > >You still haven't answered the question about the expected average > >lifetime of an entry. > > Yes I have. I said earlier that I expect most callouts to live only for > one or two ticks for my application. Here is the key: what about for other applications? For select() and poll() timeouts, or for FIN_2_WAIT, etc.? I think our expected usages are different. > >Do the callouts that are outstanding live more than 8 ticks? > > The question should be, do they live longer than 256 ticks. No. The question is "do they live longer than 256/number_outstanding"; for 30 entries, that's still 8. You actually answered this above with your expectation that the average lifetime is only one or two ticks. > >This calculation is incorrect, since I am suggesting not using a hash > >in the case of an ordered list. > > So you want softclock to become q * O(n) and ditch the hash table. For n entries queued since the last softclock, yes. Let's not confuse this with the number of entries, total, in the ordered list. > I think I'd rather pay the space to have an unordered queue for each > head in the hash table which means that only the current bucket and > the next non-empty bucket must have it's entries insertion sorted > in order to schedule the next one shot instead of all new entries that > have come in since the last softclock regardless of how they would be > distributed. This is more true to your desire to perform lazy > scheduling of timeouts. Hm. If on average, a hash bucket is empty (which it would be if you have 30 out of 256 entries), insertion is O(1). If on the other hand, you're wrong, and the usage is much higher (as I expect it will be), then you degrade to O(n/256) ordered insertion on a collision. I'm not sure I like my original insertion degradation enough to want to degrade to it during enqueueing. 8-). When you say "an unordered queue for each head in the hash table", do you mean that if there is an entry in both the ordered and unordered lists, the unordered list entries will be inserted into the ordered list on a per bucket basis? This is the O(n/256) (again, assuming perfect hash) degradation, but at softclock instead of at insertion; insertion is still O(1). This is probably the best we can hope for, unless we take Julian up on full queue migration, or pre-qualify by adding an expectation value for when we thing it will be dequeued to the call. I like it. I reserve the right to not like it later when there are a very large number of timer entries enqueued relative to the number of buckets and/or timers live agorss a larger number of softclocks. ;-). > I'm not worried about time in softclock as long as it isn't unnecessarily > excessive (O(n) is excessive) and it drops from splhigh at deterministic > intervals. Cool. I agree. > >Softclock need only check the tick values from the head, and may stop > >when it hits the first entry whose tick value exceeds the current > >tick value; remember, the list under discussion is ordered? > > But the calls to timeout and untimeout during softclock execution would > not be putting those entries into the ordered list; remember, we're > delaying all ordered insertion until softclock runs. I think this is only a problem for timeouts of 0; everything else should expect to be delayed 0-1 softclocks. If this isn't high enough resoloution, then we need to increase the softclock frequency. > >You were also the one that argued that insertion and deletion were > >relatively rare. > > I argued exactly the opposite. Insertion and deletion are the common > case, expiration is rare. Ugh. What I meant to say was that the number of entries outstanding at one time relative to the number of insertions and deletions that take place is small in proportion to the number of hash buckets. This would make it relatively rare that a softclock would ever hit an entry. It was this rarity I meant to reference, but my fingers were too fast. Hitting an unexpired entry is a bigger problem for me, with unordered lists per hash bucket, than hitting an expired entry. For the ordered list case, it's O(e + 1) compares (e == number of expored timers) vs. O(n). Again, we're talking persistant timers, so the argument isn't really applicable to your expected usage. Man, this is work. 8-(... Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-current Tue Sep 23 09:58:39 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id JAA21189 for current-outgoing; Tue, 23 Sep 1997 09:58:39 -0700 (PDT) Received: from pluto.plutotech.com (root@mail.plutotech.com [206.168.67.137]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id JAA21167 for ; Tue, 23 Sep 1997 09:58:27 -0700 (PDT) Received: from narnia.plutotech.com (narnia.plutotech.com [206.168.67.130]) by pluto.plutotech.com (8.8.5/8.8.5) with ESMTP id KAA25032; Tue, 23 Sep 1997 10:58:08 -0600 (MDT) Message-Id: <199709231658.KAA25032@pluto.plutotech.com> X-Mailer: exmh version 2.0zeta 7/24/97 To: Terry Lambert cc: gibbs@plutotech.com (Justin T. Gibbs), nate@mt.sri.com, bde@zeta.org.au, current@FreeBSD.org Subject: Re: callouts in CAM (was Re: cvs commit:) In-reply-to: Your message of "Tue, 23 Sep 1997 16:20:31 -0000." <199709231620.JAA10443@usr01.primenet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 23 Sep 1997 10:57:56 -0600 From: "Justin T. Gibbs" Sender: owner-freebsd-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk >> Where is the max allocation up front? I allocate on demand. > >There is no reason not to watermark the free pool. It has the advantage >that you can return memory to the system, and allocations can occur in >page units. Sure, but that is not the case for the timeout and untimeout interface, which, if you recall is what we are talking about. If a client calls timeout and there are not entries left, and a new one cannot be allocated, the interface does not allow this error to be propagated to the client. If, on the other hand, the client is responsible for allocating it's entry before it is used, the client can be smart about the failure. I don't want to change all of the clients of the timeout interface to make them handle a resource failure. I only want to modify the "heavy users" and leave a common pool for other users of the interface. > Terry Lambert > terry@lambert.org >--- >Any opinions in this posting are my own and not those of my present >or previous employers. > -- Justin T. Gibbs =========================================== FreeBSD: Turning PCs into workstations =========================================== From owner-freebsd-current Tue Sep 23 09:56:51 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id JAA21049 for current-outgoing; Tue, 23 Sep 1997 09:56:51 -0700 (PDT) Received: from pluto.plutotech.com (root@mail.plutotech.com [206.168.67.137]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id JAA20924 for ; Tue, 23 Sep 1997 09:54:51 -0700 (PDT) Received: from narnia.plutotech.com (narnia.plutotech.com [206.168.67.130]) by pluto.plutotech.com (8.8.5/8.8.5) with ESMTP id KAA24904; Tue, 23 Sep 1997 10:53:23 -0600 (MDT) Message-Id: <199709231653.KAA24904@pluto.plutotech.com> X-Mailer: exmh version 2.0zeta 7/24/97 To: Terry Lambert cc: gibbs@plutotech.com (Justin T. Gibbs), nate@mt.sri.com, bde@zeta.org.au, current@FreeBSD.ORG Subject: Re: cvs commit: src/sys/conf files src/sys/dev/vx if_vx.c if_vxreg.h src/sys/i386/apm apm.c src/sys/i386/conf GENERIC files.i386 In-reply-to: Your message of "Tue, 23 Sep 1997 16:13:06 -0000." <199709231613.JAA09972@usr01.primenet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 23 Sep 1997 10:53:11 -0600 From: "Justin T. Gibbs" Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >> Bullshit. You stated that every entry would be touched on each softtick. > >No I did not. Look at my sentence you quote in your response: > >> >> >So the question to as is "how many softclocks does the average timer >> >> >entry live across?". Actually lets look at the full context: >>For timeouts that live across softclock calls, as Nate is suggesting, >>the list is traversed and the entry counts against the implementation >>based on how many softclocks it lives across, on average. For ordered >>insertion, the entry is counted against, once, at insertion time. >> >>So the question to as is "how many softclocks does the average timer >>entry live across?". >This has nothing to do with claiming that every entry would be touched >on every softclock. It has to do with an entry living, on average, 8 >or more softclocks. That's not how I read it. And where do you come up with 8? >This is being generous, since it accepts your number of users (32) instead >of the GENERIC number of users (10) to obtain a total of 256 buckets. A MAXUSERS of 32 creates a callwheel size of 1024. A MAXUSERS of 10 creates a callwheel size of 256. >> Sure I have. On each softclock, the number of timers enqueued in >> all buckets is the number of callouts outstanding which I've said >> is around 30 for a typical workstation. Of course you probably >> meant to ask what the average length of a hash chain is and to >> answer that question for the loads I'm interested in, I'd have to >> instrument the code. I expect it to be h where h << n and n is >> the total number of callouts outstanding. > >Well duh, or it wouldn't be a hash; the actual *average* would be >256/30 assuming a *perfect* hash. How can my average be 256/30 if 256 * 256 / 30 != 30? >If an entry lives greater than 8.53 ticks, it will get hit twice. >On average, for the algorithm to be less than O(n), any single entry >must live 8 or less softclock ticks. You're digging a hole Terry. An entry must live for callwheel size ticks in order to be touched twice during it's lifetime. >> Lets say that softclock is currently at bucket 2. When will entries >> x, y, and z next be referenced? During the call to softclock 3 ticks >> in the future. If any of x, y, or z are removed before that time, >> they will not be referenced. The average hash chain length in this >> callwheel is a little over 2. > >2.25. Even I can accurately divide 9 by 4. Wow! Of course the point is that in the example, the hash chain length is greater than 1 which nullifies your assertion. >You still haven't answered the question about the expected average >lifetime of an entry. Yes I have. I said earlier that I expect most callouts to live only for one or two ticks for my application. >Is an entry expected to be hit by one or more softclocks in its >lifetime? *THAT* is the question. The x in O(x) is the average >number of times that any given entry can expect to be hit by a >softclock. I already answered this. >> >For the default of 10 users in GENERIC, I think this is a bad assumption. >> >Even for 32 users (256 buckets), it's stretching things if the timers >> >see any real use at all. >> >> The hash table size is still larger than the total number of callouts >> that can be outstanding. > >Do the callouts that are outstanding live more than 8 ticks? The question should be, do they live longer than 256 ticks. >> >No. It will take two additional pointers and a trivial amount of >> >code identical to the code you would need anyway. >> >> Two pointers is additional space. > >Now who is really picking nits? It's a hell of a lot less space >than you are already using, and it's statically allocated. It depends. I don't think that using only two pointers would be the right way to implement that algorithm. See below. >> It also makes softclock become q * O(h) + O(c) where q is the number >> of defered insertion entries, h is the hash chain length and c is >> the number of empty buckets that are traversed to find the next >> timeout for scheduling the next one shot. > >This calculation is incorrect, since I am suggesting not using a hash >in the case of an ordered list. So you want softclock to become q * O(n) and ditch the hash table. I think I'd rather pay the space to have an unordered queue for each head in the hash table which means that only the current bucket and the next non-empty bucket must have it's entries insertion sorted in order to schedule the next one shot instead of all new entries that have come in since the last softclock regardless of how they would be distributed. This is more true to your desire to perform lazy scheduling of timeouts. >If you will remember, this was a compromise for your complaint that >insertion at interrupt was not O(1). You weren't worried about time >in softclock until I figured out how to move the overhead there. Even >so, you're still not worried about determinism in softclock; one >indeterminate value is as good as any other. I'm not worried about time in softclock as long as it isn't unnecessarily excessive (O(n) is excessive) and it drops from splhigh at deterministic intervals. >> Then there is the additional code in softclock to ensure >> that none of the timeouts queued while softclock is running are >> supposed to expire in the current tick which you would need to >> check every time softclock drops from splhigh to let other interrupts >> run as there is nothing to prevent a timeout handler or interrupt >> handler from scheduling such an entry. > >Softclock need only check the tick values from the head, and may stop >when it hits the first entry whose tick value exceeds the current >tick value; remember, the list under discussion is ordered? But the calls to timeout and untimeout during softclock execution would not be putting those entries into the ordered list; remember, we're delaying all ordered insertion until softclock runs. >You were also the one that argued that insertion and deletion were >relatively rare. I argued exactly the opposite. Insertion and deletion are the common case, expiration is rare. > Terry Lambert > terry@lambert.org >--- >Any opinions in this posting are my own and not those of my present >or previous employers. -- Justin T. Gibbs =========================================== FreeBSD: Turning PCs into workstations =========================================== From owner-freebsd-current Tue Sep 23 09:52:47 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id JAA20819 for current-outgoing; Tue, 23 Sep 1997 09:52:47 -0700 (PDT) Received: from usr01.primenet.com (tlambert@usr01.primenet.com [206.165.6.201]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id JAA20814 for ; Tue, 23 Sep 1997 09:52:41 -0700 (PDT) Received: (from tlambert@localhost) by usr01.primenet.com (8.8.5/8.8.5) id JAA12392; Tue, 23 Sep 1997 09:52:17 -0700 (MST) From: Terry Lambert Message-Id: <199709231652.JAA12392@usr01.primenet.com> Subject: Re: cvs commit: src/sys/conf files src/sys/dev/vx if_vx.c if_vxreg.h src/sys/i386/apm apm.c src/sys/i386/conf GENERIC files.i386 To: julian@whistle.com (Julian Elischer) Date: Tue, 23 Sep 1997 16:52:16 +0000 (GMT) Cc: gibbs@plutotech.com, tlambert@primenet.com, nate@mt.sri.com, bde@zeta.org.au, current@FreeBSD.ORG In-Reply-To: from "Julian Elischer" at Sep 23, 97 02:33:39 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > >> >Queue the entry for ordered insertion when timeout() is called, but > > >> >delay the ordered insertion until softclock(). > > This was one of the things I have been wondering about. > if each spoke of the wheel had an orderd and an unordered queue, > then items would USUALLY be removed before their > bucket was accessed. Any remaining ones could be > moved to the ordered "long term" queue. > In fact it might be arguable that they could be removed from > the wheel entirely after surviving a full rotation of the softclock. > They could be inserted into a timeout queue not disimilar to that we > already run. The point is that there are several distinct usage models for > the timeout facility. They have differnt characteristics.. > HARDWARE FAILURE TIMEOUTS: nearly ALWAYS expected to be removed very > quickly. Ordering these is a complete waste of time. > PERIODIC EVENTS: nearly always time out. These tend to be of duration of > a large fraction of a second. Possibly it might be more efficient > to have a different mechanism for periodic events. > LONG TERM EVENT timing: These tend to be longer in duration, but are not > recuring. These will be hit by the softclock several times. This > could be considered a waste of resources, if we could hold them off for a > while we should. Hmmmm. This echos my arguments about kernel memory object persistance: there are low, medium, and high persistance timer events, just as there are low, medium, and high persistance memory objects, which should be kept seperate to avoid KVM fragmentation (LKM vs. mbuf vs. nameibuf, etc.). This might be better handled with ( ..., timeout, expected removal) parameters. If I expect my event to complete in M softclocks, but want a callback if it doesn't in N softclocks, where N > M, then I can categorize the request based on the number of hash buckets (in Justin's scheme), or an arbitrary categorization value in the original scheme, or in my adaptation to mee Justin's O(1) enqueueing requirements. Call this value H. 1) If H > N > M, it's a short duration event. 2) If N > H > M, it's a medium duration event. 3) If N > M > H, it's a long term event. Cases where N == M collapse to case 1 or case 3. For Justin's scheme: 1) The softclock is not expected to hit the event. 2) The softclock is not expected to hit the event, but it might. 3) The softclock is expected to hit the event one or more times. I suspect that Justin is primarily worried about things in category (1); thing in this category, for a 256 entry hash size and his expected event count of 30 may not live more than 8.53 ticks before O(h) is damaged (assuming a perfect hash). I'm concerned about things in category (2), which is where I would class most (non-floppy) hardware failure timeouts. I'm also concerned about user scheduled timers via itimer(), select(), and poll(), as well as reschedulable one-shots used by the system to implement drivers for slow hardware with strict timing requirments; these are things I expect will live in category (3). It seems to me that Justin's algorithm works best for category (1) items, goes to a slightly higher order for category (2) items, and fails miserably for category (3) items. My suggested delayed ordered insertion mechanism works well for category (1) items, so long as I have a back-pointer to allow O(1) dequeueing, works more poorly than his for category (2) items (but hardware failures are rare), and works better for category (3) items. Your suggestion about split algorithms actually resolves my (2) problems and Justin's (3) problems. ...With more code 8-). > > Two pointers is additional space. It also makes softclock become > > q * O(h) + O(c) where q is the number of defered insertion entries, > > h is the hash chain length and c is the number of empty buckets > > that are traversed to find the next timeout for scheduling the next > > one shot. > > I see it as being (on each softclock) O(H x C)+1 where H is the > unexpired (remaining) unorderd entries and C is the length of the > unordered queue for that bucket. The hope is that MOST short term > items are removed BEFORE the softclock gets to them, and that any > remaining items are probably long term items that should not be examined > at every following rotation. This was the calculation I had arrived at as well; the value of C is not obviously > 1 if you accept Justin's 30 items in the queue, unless a given entry is queued for 8.53 or more softclocks on a kernel compiled with sufficient users to cause 256 hash buckets to be allocated. > I would even consider that there should be 3 (!) entries at each > bucket. > Items move in un-sorted order from 1 to 2 and are then inserted in > order into 3. Items going into 3 are Guarenteed to have survived at LEAST > one full rotation, and can be assumed to be long-term. You could preclassify them with an expectation-of-removal parameter, or you could do this, and take a one softclock examination for each category transition (ie: 1 hit for category (2), two hits for category (3). > If the wheel is very sparcely populated it doesn't gain much, but then > again it isn't that much more expensive than what you have now. > > When the wheel get's heavily populated, or when there are a lot of > long-term entries it saves time. I think the number of entries is going to get relatively large compared to the number of entries times the average lifetime divided by the number of hash buckets. I think this ratio number is going to get much larger than one. Potentially much, much larger. If this happens, the hash chain length will get larger, fast, quickly devaluing the hash. > WHat is the right answer will depend greatly on the particular usage > model. A method of trying to handle these different models is probably > worth working for. I think this is where we are arguing at cross-purposes. Each of us sees generic timer code as solving our own timeout problems, and we ignore the fact that the problems are of differernt character. Thanks for adding some categorization! > Especialy as networking code switches to using more generic > timeouts. If you disconnect a network, we suddenly get hundreds > of actual networking timeouts..... Yep. And don't forget FIN_2_WAIT even without network disconnects; DOS network application programmers seldom call shutdown( s, 2) like they need to... Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-current Tue Sep 23 12:30:02 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id MAA29339 for current-outgoing; Tue, 23 Sep 1997 12:30:02 -0700 (PDT) Received: from ns.mt.sri.com (SRI-56K-FR.mt.net [206.127.65.42]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id MAA29304; Tue, 23 Sep 1997 12:29:40 -0700 (PDT) Received: from rocky.mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.8.7/8.8.7) with ESMTP id NAA23638; Tue, 23 Sep 1997 13:29:37 -0600 (MDT) Received: (from nate@localhost) by rocky.mt.sri.com (8.7.5/8.7.3) id NAA08312; Tue, 23 Sep 1997 13:29:37 -0600 (MDT) Date: Tue, 23 Sep 1997 13:29:37 -0600 (MDT) Message-Id: <199709231929.NAA08312@rocky.mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: mobile@freebsd.org, current@freebsd.org CC: se@freebsd.org Subject: PCCARD in -current broken X-Mailer: VM 6.29 under 19.15 XEmacs Lucid Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk [ Forgive the cross-posting, the information is of interest to a number of folks. ] It has been for some time (May). If it works on your box, you're lucky! (PHK is one of the lucky ones, and it may be related to using more PCI-like machines, unlike older 'straight-ISA' laptops). The change to the 'generic' shared interrupt code broke some assumptions I had about 'register_intr()' and 'unregister_intr()' in /sys/pccard/pcic.c. Basically, I had assumed the register_intr() would fail if I wanted access to an interrupt that was already taken, and now it succeeds so I add it to my list of 'available' IRQ's (I'd give it back, but at this point the freemask is really hosed). This assumption leads to all sorts of problems, of which I haven't completely thought about. In any case, until the code in /sys/kern/kern_intr.c ifdef'd out by 'RESOURCE_CHECK' is finished, or something else is done to make sure that 'ISA/Exclusive' interrupts are not allowed to be registered as 'shared' resources, I think there are potential problems with the current scheme, and may even effect 'normal' (non-laptop) systems who use ISA devices, though it's doubtful they do silly things like I'm doing in the PCCARD code. I don't have any solutions in the short-term, but I wanted to let folks know about the possible problems. Nate ps. The code in 2.2.* is not affected, since the new interrupt code only lives in -current. From owner-freebsd-current Tue Sep 23 15:32:39 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id PAA09550 for current-outgoing; Tue, 23 Sep 1997 15:32:39 -0700 (PDT) Received: from Octopussy.MI.Uni-Koeln.DE (Octopussy.MI.Uni-Koeln.DE [134.95.166.20]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id PAA09517; Tue, 23 Sep 1997 15:32:25 -0700 (PDT) Received: from x14.mi.uni-koeln.de ([134.95.219.124]) by Octopussy.MI.Uni-Koeln.DE with SMTP id AA18845 (5.67b/IDA-1.5); Wed, 24 Sep 1997 00:32:15 +0200 Received: (from se@localhost) by x14.mi.uni-koeln.de (8.8.7/8.6.9) id AAA04387; Wed, 24 Sep 1997 00:24:58 +0200 (CEST) X-Face: " Date: Wed, 24 Sep 1997 00:24:57 +0200 From: Stefan Esser To: Stephen McKay Cc: freebsd-current@FreeBSD.ORG, Stefan Esser Subject: Re: Assertion failed in ncr driver References: <19970922230618.13112@keltia.freenix.fr> <19970923053330.QX53740@uriah.heep.sax.de> <199709230513.PAA18083@ogre.dtir.qld.gov.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.74 In-Reply-To: <199709230513.PAA18083@ogre.dtir.qld.gov.au>; from Stephen McKay on Tue, Sep 23, 1997 at 03:13:29PM +1000 Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Sep 23, Stephen McKay wrote: > >> sd0: COMMAND FAILED (4 28) @f0765800. > I occasionally see these errors with my Diamond FirePort 40 (53c875j based) > and IBM DCAS-34330W. I have exchanged a bit of mail with Stefan already, > but no promising leads developed. I have no way of reliably reproducing > the problem, but I do know it has been there a long time because it was > happening when I ran 2.2.2 (slightly modified to recognise the 875j). > > Could the disk be a rogue after all the praise we've heaped on it? No, not a rogue, but a little picky about tagged commands, at times. This should become a non-issue when the new CAM SCSI code is commited by Justin Gibbs, since he offers support for tagged commands and that code will understand the QUEUE_FULL status from a drive that does not want to accept another tagged command ... Regards, STefan From owner-freebsd-current Tue Sep 23 15:32:51 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id PAA09594 for current-outgoing; Tue, 23 Sep 1997 15:32:51 -0700 (PDT) Received: from Octopussy.MI.Uni-Koeln.DE (Octopussy.MI.Uni-Koeln.DE [134.95.166.20]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id PAA09564; Tue, 23 Sep 1997 15:32:42 -0700 (PDT) Received: from x14.mi.uni-koeln.de ([134.95.219.124]) by Octopussy.MI.Uni-Koeln.DE with SMTP id AA18866 (5.67b/IDA-1.5); Wed, 24 Sep 1997 00:32:39 +0200 Received: (from se@localhost) by x14.mi.uni-koeln.de (8.8.7/8.6.9) id XAA04079; Tue, 23 Sep 1997 23:00:19 +0200 (CEST) X-Face: " Date: Tue, 23 Sep 1997 23:00:18 +0200 From: Stefan Esser To: Nate Williams Cc: mobile@FreeBSD.ORG, current@FreeBSD.ORG, Stefan Esser Subject: Re: PCCARD in -current broken References: <199709231929.NAA08312@rocky.mt.sri.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.74 In-Reply-To: <199709231929.NAA08312@rocky.mt.sri.com>; from Nate Williams on Tue, Sep 23, 1997 at 01:29:37PM -0600 Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Sep 23, Nate Williams wrote: > It has been for some time (May). If it works on your box, you're > lucky! (PHK is one of the lucky ones, and it may be related to using > more PCI-like machines, unlike older 'straight-ISA' laptops). Hmmm, I'm surprised to hear that ... You are the first to report such a problem. > The change to the 'generic' shared interrupt code broke some assumptions > I had about 'register_intr()' and 'unregister_intr()' in > /sys/pccard/pcic.c. Basically, I had assumed the register_intr() would > fail if I wanted access to an interrupt that was already taken, and now > it succeeds so I add it to my list of 'available' IRQ's (I'd give it > back, but at this point the freemask is really hosed). This assumption > leads to all sorts of problems, of which I haven't completely thought > about. There should not be a problem. ISA does not (should not, I didn't check the sources recently) register the handler as shared, and this will prevent another handler (both shared or exclusive) to be registered. I assume this does not work for you ? > In any case, until the code in /sys/kern/kern_intr.c ifdef'd out by > 'RESOURCE_CHECK' is finished, or something else is done to make sure The code is finished, but I did not commit it to -current, since I was waiting for the new ISA device probe/attach code to become available. Several concepts have been discussed, with the "extent registration" of NetBSD being mentioned very often. My concept is quite different, in that I'd rather have a functional interface, which works on bus-dependent data structures that have to exist anyway, while the extent data does exist independently of device data. I have outlined this before ... > that 'ISA/Exclusive' interrupts are not allowed to be registered as > 'shared' resources, I think there are potential problems with the Well, ISA interrupts should be registered in a way that guarantees they are not shared. > current scheme, and may even effect 'normal' (non-laptop) systems who > use ISA devices, though it's doubtful they do silly things like I'm > doing in the PCCARD code. > > I don't have any solutions in the short-term, but I wanted to let folks > know about the possible problems. Hmmm, I just checked the sources and I can't see what's wrong. Please tell me why the following is not sufficient: config_isadev_c() calls register_intr() register_intr() contains the following lines: flags |= INTR_EXCL; idesc = intr_create((void *)device_id, intr, handler, (void*)unit, maskptr, flags); return (intr_connect(idesc)); intr_create() just stores the flag in the interrupt descriptor, intr_connect() calls add_intrdesc(), which has: if ((idesc->flags & INTR_EXCL) != 0 || (head->flags & INTR_EXCL) != 0) { /* * can't append new handler, if either list head or * new handler do not allow interrupts to be shared */ printf("\tdevice combination doesn't support shared irq%d\n", irq); return (-1); } As soon as some ISA device got an interrupt registered, no second handler will be added. I've checked, that pccard.c also uses the register_intr() compatibility call, and thus it will also get INTR_EXCL added to the flags value supplied (which is a constant "0"). Please tell me what's wrong with this ... Regards, STefan From owner-freebsd-current Tue Sep 23 15:32:56 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id PAA09627 for current-outgoing; Tue, 23 Sep 1997 15:32:56 -0700 (PDT) Received: from Octopussy.MI.Uni-Koeln.DE (Octopussy.MI.Uni-Koeln.DE [134.95.166.20]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id PAA09583; Tue, 23 Sep 1997 15:32:46 -0700 (PDT) Received: from x14.mi.uni-koeln.de ([134.95.219.124]) by Octopussy.MI.Uni-Koeln.DE with SMTP id AA18872 (5.67b/IDA-1.5); Wed, 24 Sep 1997 00:32:42 +0200 Received: (from se@localhost) by x14.mi.uni-koeln.de (8.8.7/8.6.9) id XAA04127; Tue, 23 Sep 1997 23:15:10 +0200 (CEST) X-Face: " Date: Tue, 23 Sep 1997 23:15:09 +0200 From: Stefan Esser To: Ollivier Robert Cc: "FreeBSD Current Users' list" , Stefan Esser Subject: Re: Assertion failed in ncr driver References: <19970922230618.13112@keltia.freenix.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.74 In-Reply-To: <19970922230618.13112@keltia.freenix.fr>; from Ollivier Robert on Mon, Sep 22, 1997 at 11:06:18PM +0200 Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Sep 22, Ollivier Robert wrote: > I get the following errors when I use dump to back up my machine. I thought > it is was the tags and sets the tags for my disks to 0 in the script but it > doesn't seem to make any difference. > > I have a SC-875 for both sd0 and sd2 (DCAS-34330W & DORS-32160). > > 203 [22:55] root@keltia:/build/xemacs-20.2# ncrcontrol -i > T:L Vendor Device Rev Speed Max Wide Tags > 0:0 IBM DCAS-34330W S65A 20.0 20.0 16 8 > 2:0 IBM DORS-32160 WA6A 20.0 20.0 8 8 > 4:0 TANDBERG TDC 3600 =08: ? 20.0 ? - > > ncr0: rev 0x03 int a irq 12 on pci0.11.0 > ncr0: minsync=12, maxsync=137, maxoffs=16, 128 dwords burst, large dma fifo > ncr0: single-ended, open drain IRQ driver, using on-chip SRAM > ncr0: restart (scsi reset). > ncr0 scanning for targets 0..6 and 8..15 (V2 pl24 96/12/14) > Choosing drivers for scbus configured at 0 > scbus0 at ncr0 bus 0 > sd is configured at 0 > sd0 at scbus0 target 0 lun 0 > sd0: type 0 fixed SCSI 2 > sd0: Direct-Access > sd0: NCR quirks=0x2 > > sd0: WIDE SCSI (16 bit) enabled > sd0: 40.0 MB/s (50 ns, offset 15) > 4134MB (8467200 512 byte sectors) > sd0: with 8205 cyls, 6 heads, and an average 171 sectors/track > sd is configured at 2 > sd2 at scbus0 target 2 lun 0 > sd2: type 0 fixed SCSI 2 > sd2: Direct-Access > sd2: NCR quirks=0x2 > > sd2: 20.0 MB/s (50 ns, offset 15) > 2063MB (4226725 512 byte sectors) > sd2: with 6703 cyls, 5 heads, and an average 126 sectors/track > > Any idea why I get these ? > > assertion "cp" failed: file "../../pci/ncr.c", line 6227 > sd0: COMMAND FAILED (4 28) @f0765800. > assertion "cp" failed: file "../../pci/ncr.c", line 6227 > sd0: COMMAND FAILED (4 28) @f0765c00. The command fails, since the drive returns a QUEUE_FULL status, which is the correct way to tell the drive can't deal with another tagged command, currently. (And, BTW, I found that drive to be faster without tags in a number of micro benchmarks I performed.) The problem with those IBM drives is, that they usually support a reasonable number of tagged commands, but in certain situations return QUEUE_FULL if less than 4 commands are issued at a time. The current generic SCSI code does not offer much support for this situation. If the driver just let the generic code issue a retry, then the command would fail again, since it will take the drive a few tens of milli-seconds before it is able to accept another command. The IBM drives often had problems with tagged START_STOP_UNIT commands, which are issued at the time a raw partition is opened (which is the case in dump). You may want to try with the call of scsi_start_unit() removed from /sys/scsi/sd.c. Justin Gibbs' new generic CAM SCSI layer will take care of this and other problems. If you are seeing this problem only in certain situations (e.g. while writing a backup), you may want to temporarily disable tagged commands for that drive. Regards, STefan From owner-freebsd-current Tue Sep 23 15:47:49 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id PAA10638 for current-outgoing; Tue, 23 Sep 1997 15:47:49 -0700 (PDT) Received: from ns.mt.sri.com (SRI-56K-FR.mt.net [206.127.65.42]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id PAA10615; Tue, 23 Sep 1997 15:47:30 -0700 (PDT) Received: from rocky.mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.8.7/8.8.7) with ESMTP id QAA24930; Tue, 23 Sep 1997 16:46:58 -0600 (MDT) Received: (from nate@localhost) by rocky.mt.sri.com (8.7.5/8.7.3) id QAA09189; Tue, 23 Sep 1997 16:46:56 -0600 (MDT) Date: Tue, 23 Sep 1997 16:46:56 -0600 (MDT) Message-Id: <199709232246.QAA09189@rocky.mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Stefan Esser Cc: Nate Williams , mobile@freebsd.org, current@freebsd.org Subject: Re: PCCARD in -current broken In-Reply-To: <19970923230018.00034@mi.uni-koeln.de> References: <199709231929.NAA08312@rocky.mt.sri.com> <19970923230018.00034@mi.uni-koeln.de> X-Mailer: VM 6.29 under 19.15 XEmacs Lucid Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > It has been for some time (May). If it works on your box, you're > > lucky! (PHK is one of the lucky ones, and it may be related to using > > more PCI-like machines, unlike older 'straight-ISA' laptops). > > Hmmm, I'm surprised to hear that ... > You are the first to report such a problem. Most folks don't use current on their laptops. :) > > The change to the 'generic' shared interrupt code broke some assumptions > > I had about 'register_intr()' and 'unregister_intr()' in > > /sys/pccard/pcic.c. Basically, I had assumed the register_intr() would > > fail if I wanted access to an interrupt that was already taken, and now > > it succeeds so I add it to my list of 'available' IRQ's (I'd give it > > back, but at this point the freemask is really hosed). This assumption > > leads to all sorts of problems, of which I haven't completely thought > > about. > > There should not be a problem. ISA does not > (should not, I didn't check the sources > recently) register the handler as shared, > and this will prevent another handler (both > shared or exclusive) to be registered. register_intr() sets the INTR_EXCL flag just before it calls intr_create() (so far so good), but in intr_connect(), the code to check for that flag is ifdef's out: int intr_connect(intrec *idesc) { ... #ifdef RESOURCE_CHECK int resflag; #endif /* RESOURCE_CHECK */ .... #ifdef RESOURCE_CHECK resflag = (idesc->flags & INTR_EXCL) ? RESF_NONE : RESF_SHARED; if (resource_claim(idesc->devdata, REST_INT, resflag, irq, irq) == 0) #endif /* RESOURCE_CHECK */ { So, we don't even check to see if INTR_EXCL is used. > I assume this does not work for you ? See above. > > In any case, until the code in /sys/kern/kern_intr.c ifdef'd out by > > 'RESOURCE_CHECK' is finished, or something else is done to make sure > > The code is finished, but I did not commit > it to -current, since I was waiting for the > new ISA device probe/attach code to become > available. How does the new code realize that the interrupt is exclusive then? > > that 'ISA/Exclusive' interrupts are not allowed to be registered as > > 'shared' resources, I think there are potential problems with the > > Well, ISA interrupts should be registered in > a way that guarantees they are not shared. How? > Hmmm, I just checked the sources and I can't > see what's wrong. Please tell me why the > following is not sufficient: Hmm, never mind. I never walked enough down into the sources to see what's going on. So, can I rely on register_intr() return a negative # for failure? (Here's the code in question.) static u_int build_freelist(u_int pcic_mask) { inthand2_t *nullfunc; int irq; u_int mask, freemask; /* No free IRQs (yet). */ freemask = 0; /* Walk through all of the IRQ's and find any that aren't allocated. */ for (irq = 0; irq < ICU_LEN; irq++) { /* * If the PCIC controller can't generate it, don't * bother checking to see if it it's free. */ mask = 1 << irq; if (!(mask & pcic_mask)) continue; /* See if the IRQ is free. */ if (register_intr(irq, 0, 0, nullfunc, NULL, irq) == 0) { /* Give it back, but add it to the mask */ INTRMASK(freemask, mask); unregister_intr(irq, nullfunc); } } #ifdef PCIC_DEBUG printf("Freelist of IRQ's <0x%x>\n", freemask); #endif return freemask; } > Please tell me what's wrong with this ... Maybe nothing, and maybe I'm a geek who likes to blame everyone else for my problems! :( Nate From owner-freebsd-current Tue Sep 23 17:26:10 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id RAA16315 for current-outgoing; Tue, 23 Sep 1997 17:26:10 -0700 (PDT) Received: from sendero-ppp.i-connect.net (sendero-ppp.i-Connect.Net [206.190.143.100]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id RAA16309 for ; Tue, 23 Sep 1997 17:26:08 -0700 (PDT) Received: (qmail 7862 invoked by uid 1000); 24 Sep 1997 00:26:25 -0000 Message-ID: X-Mailer: XFMail 1.2-alpha-091897 [p0] on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit MIME-Version: 1.0 Date: Tue, 23 Sep 1997 17:26:25 -0700 (PDT) Organization: Atlas Telecom From: Simon Shapiro To: freebsd-current@freebsd.org Subject: Help Requested - system Panic in __getcwd() Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Ladies and Gentlemen, May I please solicit your assistance in solving a difficulty I am experiencing with FreeBSD kernel, in the last day or so. The version of the doftware in question is 3.0-current. The CVS update of the source tree is current as of last night (The 22nd of September). The symptoms are a panic, in idle systems, in __getcwd. There is a reference to a virtual address 0x78 which appears to be invalid. I have searched the freebsd-current mailing list dilligently and found no mention of this problem. In case this was already reported, please accept my apologies and view this message as a confirmation of the problem's existance. If there is any way in which I can be of assistance in expediting a solution, please let me know. I will be happy to help. [ I hope the language in this message is meek and polite enough as to not offend any of you which I apparently have offended in the past - an offense I deeply regret ] --- Sincerely Yours, (Sent on 23-Sep-97, 17:07:11 by XF-Mail) Simon Shapiro Atlas Telecom Senior Architect 14355 SW Allen Blvd., Suite 130 Beaverton OR 97005 Shimon@i-Connect.Net Voice: 503.643.5559, Emergency: 503.799.2313 From owner-freebsd-current Tue Sep 23 18:00:28 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id SAA17924 for current-outgoing; Tue, 23 Sep 1997 18:00:28 -0700 (PDT) Received: from gneiss.eps.nagoya-u.ac.jp (gneiss.eps.nagoya-u.ac.jp [133.6.57.99]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id SAA17917 for ; Tue, 23 Sep 1997 18:00:20 -0700 (PDT) Received: from marble.eps.nagoya-u.ac.jp (localhost [127.0.0.1]) by gneiss.eps.nagoya-u.ac.jp (8.8.7/3.5Wpl3) with ESMTP id JAA02534; Wed, 24 Sep 1997 09:59:17 +0900 (JST) Message-Id: <199709240059.JAA02534@gneiss.eps.nagoya-u.ac.jp> To: jkh@time.cdrom.com Cc: current@FreeBSD.ORG Subject: Re: Daily SNAPshots at current.freebsd.org shut down for now. From: KATO Takenori In-Reply-To: Your message of "Mon, 22 Sep 1997 09:12:43 -0700" References: <12587.874944763@time.cdrom.com> X-Mailer: Mew version 1.70 on Emacs 19.28.1 / Mule 2.3 X-PGP-Fingerprint: 03 72 85 36 62 46 23 03 52 B1 10 22 44 10 0D 9E Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Wed, 24 Sep 1997 09:59:17 +0900 Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > until the vn driver is fixed. It causes kernel panics on use now To undo the change in 1.49/1.41.2.1 of /sys/dev/vn/vn.c may hide the panic. But, I think this is NOT real fix. ---- KATO Takenori Dept. Earth Planet. Sci., Nagoya Univ., Nagoya, 464-01, Japan PGP public key: finger kato@eclogite.eps.nagoya-u.ac.jp ------------------- Powered by FreeBSD(98) ------------------- From owner-freebsd-current Tue Sep 23 18:22:28 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id SAA19213 for current-outgoing; Tue, 23 Sep 1997 18:22:28 -0700 (PDT) Received: from earth.mat.net (root@earth.mat.net [206.246.122.2]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id SAA19202 for ; Tue, 23 Sep 1997 18:22:19 -0700 (PDT) Received: from Journey2.mat.net (journey2.mat.net [206.246.122.116]) by earth.mat.net (8.8.7/8.6.12) with SMTP id VAA07660; Tue, 23 Sep 1997 21:21:51 -0400 (EDT) Date: Tue, 23 Sep 1997 21:21:25 -0400 (EDT) From: Chuck Robey X-Sender: chuckr@Journey2.mat.net To: Simon Shapiro cc: freebsd-current@FreeBSD.ORG Subject: Re: Help Requested - system Panic in __getcwd() In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Tue, 23 Sep 1997, Simon Shapiro wrote: > Ladies and Gentlemen, > > May I please solicit your assistance in solving a difficulty I am > experiencing with FreeBSD kernel, in the last day or so. > > The version of the doftware in question is 3.0-current. The CVS update of > the source tree is current as of last night (The 22nd of September). > > The symptoms are a panic, in idle systems, in __getcwd. There is a > reference to a virtual address 0x78 which appears to be invalid. > > I have searched the freebsd-current mailing list dilligently and found no > mention of this problem. > > In case this was already reported, please accept my apologies and view this > message as a confirmation of the problem's existance. > > If there is any way in which I can be of assistance in expediting a > solution, please let me know. I will be happy to help. > > [ I hope the language in this message is meek and polite enough as to not > offend any of you which I apparently have offended in the past - an offense > I deeply regret ] I think maybe you caught Justin at a bad time, when he was arguing with Terry (apparently a regular thing). Anyhow, Poul did a little tweaking with getcwd a little while back, warning that it was a little experimental at the time, I think. Maybe you're tweaking his tweak now? > > > --- > > > Sincerely Yours, (Sent on 23-Sep-97, 17:07:11 > by XF-Mail) > > Simon Shapiro Atlas Telecom > Senior Architect 14355 SW Allen Blvd., Suite 130 Beaverton OR 97005 > Shimon@i-Connect.Net Voice: 503.643.5559, Emergency: 503.799.2313 > > ----------------------------+----------------------------------------------- Chuck Robey | Interests include any kind of voice or data chuckr@eng.umd.edu | communications topic, C programming, and Unix. 213 Lakeside Drive Apt T-1 | Greenbelt, MD 20770 | I run Journey2 and picnic, both FreeBSD (301) 220-2114 | version 3.0 current -- and great FUN! ----------------------------+----------------------------------------------- From owner-freebsd-current Tue Sep 23 19:17:23 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id TAA22151 for current-outgoing; Tue, 23 Sep 1997 19:17:23 -0700 (PDT) Received: from hydrogen.nike.efn.org (resnet.uoregon.edu [128.223.170.28]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id TAA22122; Tue, 23 Sep 1997 19:17:12 -0700 (PDT) Received: (from jmg@localhost) by hydrogen.nike.efn.org (8.8.7/8.8.7) id TAA05504; Tue, 23 Sep 1997 19:17:11 -0700 (PDT) Message-ID: <19970923191710.61639@hydrogen.nike.efn.org> Date: Tue, 23 Sep 1997 19:17:10 -0700 From: John-Mark Gurney To: Stefan Esser Cc: Nate Williams , mobile@FreeBSD.ORG, current@FreeBSD.ORG Subject: Re: PCCARD in -current broken References: <199709231929.NAA08312@rocky.mt.sri.com> <19970923230018.00034@mi.uni-koeln.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.69 In-Reply-To: <19970923230018.00034@mi.uni-koeln.de>; from Stefan Esser on Tue, Sep 23, 1997 at 11:00:18PM +0200 Reply-To: John-Mark Gurney Organization: Cu Networking X-Operating-System: FreeBSD 2.2.1-RELEASE i386 X-PGP-Fingerprint: B7 EC EF F8 AE ED A7 31 96 7A 22 B3 D8 56 36 F4 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Stefan Esser scribbled this message on Sep 23: > > In any case, until the code in /sys/kern/kern_intr.c ifdef'd out by > > 'RESOURCE_CHECK' is finished, or something else is done to make sure > > The code is finished, but I did not commit > it to -current, since I was waiting for the > new ISA device probe/attach code to become > available. oh... if your waiting for the work that I'm working on.. commit the changes now.. I don't think that I'll have anything workable in the next month... as next monday is the first day of classes, and I've been working this week... so I haven't made any progress yet... > Several concepts have been discussed, with > the "extent registration" of NetBSD being > mentioned very often. > > My concept is quite different, in that I'd > rather have a functional interface, which > works on bus-dependent data structures that > have to exist anyway, while the extent data > does exist independently of device data. have you actually looked at the extent stuff from NetBSD?? you still have to write the wrappers around the extent to use the resources, it's just that it provides a way to do mapping of sections of units... > I have outlined this before ... > > > that 'ISA/Exclusive' interrupts are not allowed to be registered as > > 'shared' resources, I think there are potential problems with the > > Well, ISA interrupts should be registered in > a way that guarantees they are not shared. I agree.. but this should be on a bus dependant side... and with the new isa_device stuff I have invisioned.... we will be able to do more dynamic sharing of irqs... suchs as marking irqs as only used when device is active... so you can share irqs between devices... i.e. the common com1/com3 problem... ttyl.. -- John-Mark Gurney Modem/FAX: +1 541 683 6954 Cu Networking Live in Peace, destroy Micro$oft, support free software, run FreeBSD From owner-freebsd-current Tue Sep 23 19:23:28 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id TAA22553 for current-outgoing; Tue, 23 Sep 1997 19:23:28 -0700 (PDT) Received: from sendero-ppp.i-connect.net (sendero-ppp.i-Connect.Net [206.190.143.100]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id TAA22539 for ; Tue, 23 Sep 1997 19:23:24 -0700 (PDT) Received: (qmail 14865 invoked by uid 1000); 24 Sep 1997 02:23:47 -0000 Message-ID: X-Mailer: XFMail 1.2-alpha-091897 [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: Date: Tue, 23 Sep 1997 19:23:47 -0700 (PDT) Organization: Atlas Telecom From: Simon Shapiro To: Chuck Robey Subject: Re: Help Requested - system Panic in __getcwd() Cc: freebsd-current@FreeBSD.ORG Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hi Chuck Robey; On 24-Sep-97 you wrote: > On Tue, 23 Sep 1997, Simon Shapiro wrote: > > > Ladies and Gentlemen, > > > > May I please solicit your assistance in solving a difficulty I am > > experiencing with FreeBSD kernel, in the last day or so. > > > > The version of the doftware in question is 3.0-current. The CVS update > > of > > the source tree is current as of last night (The 22nd of September). > > > > The symptoms are a panic, in idle systems, in __getcwd. There is a > > reference to a virtual address 0x78 which appears to be invalid. > > > > I have searched the freebsd-current mailing list dilligently and found > > no > > mention of this problem. > > > > In case this was already reported, please accept my apologies and view > > this > > message as a confirmation of the problem's existance. > > > > If there is any way in which I can be of assistance in expediting a > > solution, please let me know. I will be happy to help. > > > > [ I hope the language in this message is meek and polite enough as to > > not > > offend any of you which I apparently have offended in the past - an > > offense > > I deeply regret ] > > I think maybe you caught Justin at a bad time, when he was arguing with > Terry (apparently a regular thing). Anyhow, Poul did a little tweaking > with getcwd a little while back, warning that it was a little > experimental > at the time, I think. Maybe you're tweaking his tweak now? Justin? He has nothing to with the note above. Although much of his argument with Terry escaped me, it was a boost for my morale in some strange way (here I go again :-) The crash is very easy to induce; Just ftp into the machine in question. I am still trying to isolate it. --- Sincerely Yours, (Sent on 23-Sep-97, 19:16:44 by XF-Mail) Simon Shapiro Atlas Telecom Senior Architect 14355 SW Allen Blvd., Suite 130 Beaverton OR 97005 Shimon@i-Connect.Net Voice: 503.643.5559, Emergency: 503.799.2313 From owner-freebsd-current Tue Sep 23 21:05:53 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id VAA27867 for current-outgoing; Tue, 23 Sep 1997 21:05:53 -0700 (PDT) Received: from gneiss.eps.nagoya-u.ac.jp (gneiss.eps.nagoya-u.ac.jp [133.6.57.99]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id VAA27853 for ; Tue, 23 Sep 1997 21:05:45 -0700 (PDT) Received: from marble.eps.nagoya-u.ac.jp (localhost [127.0.0.1]) by gneiss.eps.nagoya-u.ac.jp (8.8.7/3.5Wpl3) with ESMTP id MAA04770; Wed, 24 Sep 1997 12:58:32 +0900 (JST) Message-Id: <199709240358.MAA04770@gneiss.eps.nagoya-u.ac.jp> To: jkh@time.cdrom.com Cc: current@freebsd.org Subject: Re: Daily SNAPshots at current.freebsd.org shut down for now. From: KATO Takenori In-Reply-To: Your message of "Wed, 24 Sep 1997 09:59:17 +0900" References: <199709240059.JAA02534@gneiss.eps.nagoya-u.ac.jp> X-Mailer: Mew version 1.70 on Emacs 19.28.1 / Mule 2.3 X-PGP-Fingerprint: 03 72 85 36 62 46 23 03 52 B1 10 22 44 10 0D 9E Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Wed, 24 Sep 1997 12:58:32 +0900 Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > To undo the change in 1.49/1.41.2.1 of /sys/dev/vn/vn.c may hide the > panic. But, I think this is NOT real fix. I made patches for current and 2.2. They are better than undoing. Should they be committed? ---------- PATCH FOR 2.2 ---------- *** vn.c.ORIG Wed Sep 24 10:33:10 1997 --- vn.c Wed Sep 24 11:39:25 1997 *************** *** 234,239 **** --- 234,240 ---- long sz; struct uio auio; struct iovec aiov; + int vnodelocked = 0; IFOPT(vn, VN_DEBUG) printf("vnstrategy(%p): unit %d\n", bp, unit); *************** *** 279,290 **** auio.uio_rw = UIO_WRITE; auio.uio_resid = bp->b_bcount; auio.uio_procp = curproc; ! VOP_LOCK(vn->sc_vp); if( bp->b_flags & B_READ) error = VOP_READ(vn->sc_vp, &auio, 0, vn->sc_cred); else error = VOP_WRITE(vn->sc_vp, &auio, 0, vn->sc_cred); ! VOP_UNLOCK(vn->sc_vp); bp->b_resid = auio.uio_resid; --- 280,297 ---- auio.uio_rw = UIO_WRITE; auio.uio_resid = bp->b_bcount; auio.uio_procp = curproc; ! if (!VOP_ISLOCKED(vn->sc_vp)) { ! vnodelocked = 1; ! VOP_LOCK(vn->sc_vp); ! } if( bp->b_flags & B_READ) error = VOP_READ(vn->sc_vp, &auio, 0, vn->sc_cred); else error = VOP_WRITE(vn->sc_vp, &auio, 0, vn->sc_cred); ! if (vnodelocked) { ! VOP_UNLOCK(vn->sc_vp); ! vnodelocked = 0; /* vnodelocked will be reused bellow. */ ! } bp->b_resid = auio.uio_resid; *************** *** 309,318 **** int off, s, nra; nra = 0; ! VOP_LOCK(vn->sc_vp); error = VOP_BMAP(vn->sc_vp, (daddr_t)(byten / bsize), &vp, &nbn, &nra, NULL); ! VOP_UNLOCK(vn->sc_vp); if (error == 0 && nbn == -1) error = EIO; --- 316,329 ---- int off, s, nra; nra = 0; ! if (!VOP_ISLOCKED(vn->sc_vp)) { ! vnodelocked = 1; ! VOP_LOCK(vn->sc_vp); ! } error = VOP_BMAP(vn->sc_vp, (daddr_t)(byten / bsize), &vp, &nbn, &nra, NULL); ! if (vnodelocked) ! VOP_UNLOCK(vn->sc_vp); if (error == 0 && nbn == -1) error = EIO; ---------- END ---------- ---------- PATCH FOR CURRENT ---------- *** vn.c.ORIG Wed Sep 24 12:49:09 1997 --- vn.c Wed Sep 24 12:52:13 1997 *************** *** 231,236 **** --- 231,237 ---- long sz; struct uio auio; struct iovec aiov; + int vnodelocked = 0; IFOPT(vn, VN_DEBUG) printf("vnstrategy(%p): unit %d\n", bp, unit); *************** *** 276,287 **** auio.uio_rw = UIO_WRITE; auio.uio_resid = bp->b_bcount; auio.uio_procp = curproc; ! vn_lock(vn->sc_vp, LK_EXCLUSIVE | LK_RETRY, curproc); if( bp->b_flags & B_READ) error = VOP_READ(vn->sc_vp, &auio, 0, vn->sc_cred); else error = VOP_WRITE(vn->sc_vp, &auio, 0, vn->sc_cred); ! VOP_UNLOCK(vn->sc_vp, 0, curproc); bp->b_resid = auio.uio_resid; if( error ) --- 277,294 ---- auio.uio_rw = UIO_WRITE; auio.uio_resid = bp->b_bcount; auio.uio_procp = curproc; ! if (!VOP_ISLOCKED(vn->sc_vp)) { ! vnodelocked = 1; ! vn_lock(vn->sc_vp, LK_EXCLUSIVE | LK_RETRY, curproc); ! } if( bp->b_flags & B_READ) error = VOP_READ(vn->sc_vp, &auio, 0, vn->sc_cred); else error = VOP_WRITE(vn->sc_vp, &auio, 0, vn->sc_cred); ! if (vnodelocked) { ! VOP_UNLOCK(vn->sc_vp, 0, curproc); ! vnodelocked = 0; /* vnodelocked will be reused bellow. */ ! } bp->b_resid = auio.uio_resid; if( error ) *************** *** 305,314 **** int off, s, nra; nra = 0; ! vn_lock(vn->sc_vp, LK_EXCLUSIVE | LK_RETRY, curproc); error = VOP_BMAP(vn->sc_vp, (daddr_t)(byten / bsize), &vp, &nbn, &nra, NULL); ! VOP_UNLOCK(vn->sc_vp, 0, curproc); if (error == 0 && nbn == -1) error = EIO; --- 312,327 ---- int off, s, nra; nra = 0; ! if (!VOP_ISLOCKED(vn->sc_vp)) { ! vnodelocked = 1; ! vn_lock(vn->sc_vp, LK_EXCLUSIVE | LK_RETRY, curproc); ! } error = VOP_BMAP(vn->sc_vp, (daddr_t)(byten / bsize), &vp, &nbn, &nra, NULL); ! if (vnodelocked) { ! VOP_UNLOCK(vn->sc_vp, 0, curproc); ! vnodelocked = 0; ! } if (error == 0 && nbn == -1) error = EIO; ---------- END ---------- ---- KATO Takenori Dept. Earth Planet. Sci., Nagoya Univ., Nagoya, 464-01, Japan PGP public key: finger kato@eclogite.eps.nagoya-u.ac.jp ------------------- Powered by FreeBSD(98) ------------------- From owner-freebsd-current Tue Sep 23 21:31:51 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id VAA28932 for current-outgoing; Tue, 23 Sep 1997 21:31:51 -0700 (PDT) Received: from mexico.brainstorm.eu.org (root@mexico.brainstorm.fr [193.56.58.253]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id VAA28926 for ; Tue, 23 Sep 1997 21:31:47 -0700 (PDT) Received: from brasil.brainstorm.eu.org (brasil.brainstorm.fr [193.56.58.33]) by mexico.brainstorm.eu.org (8.8.4/8.8.4) with ESMTP id GAA03562 for ; Wed, 24 Sep 1997 06:31:47 +0200 Received: (from uucp@localhost) by brasil.brainstorm.eu.org (8.8.6/brasil-1.2) with UUCP id GAA18440 for freebsd-current@FreeBSD.ORG; Wed, 24 Sep 1997 06:31:35 +0200 Received: (from roberto@localhost) by keltia.freenix.fr (8.8.7/keltia-2.10/nospam) id CAA20481; Wed, 24 Sep 1997 02:20:19 +0200 (CEST) Message-ID: <19970924022018.26175@keltia.freenix.fr> Date: Wed, 24 Sep 1997 02:20:18 +0200 From: Ollivier Robert To: freebsd-current@FreeBSD.ORG Subject: Re: Netscape 4.03b8 doesn't work after poll/select changes References: <9709231856.AA28682@watermarkgroup.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84 In-Reply-To: <9709231856.AA28682@watermarkgroup.com>; from Luoqi Chen on Tue, Sep 23, 1997 at 02:56:31PM -0400 X-Operating-System: FreeBSD 3.0-CURRENT Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk According to Luoqi Chen: > Try adding this line to /usr/local/bin/netscape, > export XCMSDB; XCMSDB=/dev/null I don't understand why but it works. I'll test it tomorrow at work but it makes Netscape 4.03b7 appear and work here. Why the bloody thing was apparently waiting for select(2) before and is not now is a mistery. Thanks a lot ! -- Ollivier ROBERT -=- FreeBSD: There are no limits -=- roberto@keltia.freenix.fr FreeBSD keltia.freenix.fr 3.0-CURRENT #35: Sun Sep 21 19:28:07 CEST 1997 From owner-freebsd-current Tue Sep 23 21:31:56 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id VAA28964 for current-outgoing; Tue, 23 Sep 1997 21:31:56 -0700 (PDT) Received: from mexico.brainstorm.eu.org (root@mexico.brainstorm.fr [193.56.58.253]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id VAA28933 for ; Tue, 23 Sep 1997 21:31:51 -0700 (PDT) Received: from brasil.brainstorm.eu.org (brasil.brainstorm.fr [193.56.58.33]) by mexico.brainstorm.eu.org (8.8.4/8.8.4) with ESMTP id GAA03568 for ; Wed, 24 Sep 1997 06:31:47 +0200 Received: (from uucp@localhost) by brasil.brainstorm.eu.org (8.8.6/brasil-1.2) with UUCP id GAA18441 for freebsd-current@FreeBSD.ORG; Wed, 24 Sep 1997 06:31:35 +0200 Received: (from roberto@localhost) by keltia.freenix.fr (8.8.7/keltia-2.10/nospam) id CAA20492; Wed, 24 Sep 1997 02:22:25 +0200 (CEST) Message-ID: <19970924022224.06262@keltia.freenix.fr> Date: Wed, 24 Sep 1997 02:22:24 +0200 From: Ollivier Robert To: freebsd-current@FreeBSD.ORG Subject: Re: Assertion failed in ncr driver References: <19970922230618.13112@keltia.freenix.fr> <19970923053330.QX53740@uriah.heep.sax.de> <199709230513.PAA18083@ogre.dtir.qld.gov.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84 In-Reply-To: <199709230513.PAA18083@ogre.dtir.qld.gov.au>; from Stephen McKay on Tue, Sep 23, 1997 at 03:13:29PM +1000 X-Operating-System: FreeBSD 3.0-CURRENT Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk According to Stephen McKay: > but no promising leads developed. I have no way of reliably reproducing > the problem, but I do know it has been there a long time because it was As for "reliably reproducing", it is very easy. Run dum(8) on /dev/sd0a and I'll see the messages. -- Ollivier ROBERT -=- FreeBSD: There are no limits -=- roberto@keltia.freenix.fr FreeBSD keltia.freenix.fr 3.0-CURRENT #35: Sun Sep 21 19:28:07 CEST 1997 From owner-freebsd-current Tue Sep 23 21:57:26 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id VAA00560 for current-outgoing; Tue, 23 Sep 1997 21:57:26 -0700 (PDT) Received: from nemesis.lonestar.org ([204.178.74.200]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id VAA00554 for ; Tue, 23 Sep 1997 21:57:21 -0700 (PDT) Received: by nemesis.lonestar.org (Smail3.1.27.1 #22) id m0xDjU6-000twnC; Tue, 23 Sep 97 23:55 CDT Message-Id: Date: Tue, 23 Sep 97 23:55 CDT To: current@freebsd.org From: uhclem@nemesis.lonestar.org (Frank Durda IV) Sent: Tue Sep 23 1997, 23:55:34 CDT Subject: Is the SCSI "timed out while idle" bug supposed to be fixed? Cc: uhclem.ds3@nemesis.lonestar.org Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk With all of the recent shift to tinkering with the kernel callout architecture, I must ask if everybody believes the "timed out while idle" class of SCSI errors have been fixed. The reason I ask is that I am still getting them, every few hours, on three different boxes, using the 2.2.2-RELENG-970921 kernel tree. The most recent (copied off the screen a few minutes ago since the system usually dies for good when this happens) sd3(ahc0:3:0) SCB 0x3 - timed out while idle, LASTPHASE ==0x01, SCSISIGI==0x00, sd3(ahc0:3:0) SEQADDR=0x6 SCSISEQ=0x12 SSTAT=0x05 SSTAT1=0xA sd3(ahc0:3:0) Queuing an Abort SCB sd3(ahc0:3:0) Abort Message Sent sd3(ahc0:3:0) SCB 3 - Abort Completed sd3(ahc0:3:0) no longer in timeout ----and the system dies here--- The system is still pingable, sometimes fools SNMP monitors and will even open a telnet session that hangs, but the system is not usable and there is no subsequent disk activity. I've been getting these for two months now, and have updated the kernel a couple times when I saw what appeared to be changes that purported to fix the problem go into the tree. The volume of "events" has gone down slightly on the newer kernels, and sometimes it is able to recover and keep going (although apps start dumping core, indicating to me that things didn't really come back sane), but they have not gone away. The hardware in question is three different Pentium 133 systems, all three with Intel motherboards of the same make. All systems have 128Meg of RAM and a cache module. The kernel is as distributed, except for the inclusion of the CCD driver, and the insertion of full duplex ethernet code for the DE driver (amazing this isn't in the distribution yet). Most non-present peripherals have their drivers omitted from the kernel config. (Config file available on request.) All three systems have four SCSI drives. With one exception on one system, all four drives are Quantum Fireball 4.3GB drives. SCSI controllers are Adaptec 2940U or 2940s. Drives are configured as logical units 0-3 and there are no tapes, CD-ROMs or other peripherals, apart from one 1.44Meg floppy. The one odd-system has a Seagate Baracuda for Drive 0. Drives 1 thru 3 are always Quantum 4.3GBs. Of the drives the SCSI driver decides to blame when an event occurs, 100% of the time it is a Quantum, almost always it complains about a problem with drive two or three. If you take drives two and three and put them at different positions on the SCSI cable (correcting termination), the next time you get an error, it will still complain about drive two or three. If you replace drives two and three with brand new drives, you will eventually get errors again, blaming drive two of three, mainly drive 3. Once in a while, it spits out not ready errors for all four drives before reporting the "timed out while idle" error. We bought 16 new Fireballs and have gradually gone through all of them, swapping out drives that reported these and other read-type errors. The problems sometimes go away on that drive number, or they may come right back. There is no obvious pattern. The only application is Diablo. There are no users. We have run Diablo 9, 10 and 11 on these boxes (with local enhancements we wrote to implement cancel flood feeds and a better history database) and the volume of errors did not really change as we moved from one version to the next. Drives 1-3 form a CCD stripe set (12GB) for /news and its spool directories. Drive 0 normally contains 150M root, 260M swap and the rest for /usr. Each box is connected with one or two 21140 ether cards, running in FDX mode (using the driver directly from the author to get FDX). These are connected to a full-duplex switch connected to a 100Mbit FDX link to a 7513 router. The 7513 shows each box doing about 4Mbit/sec of data. Each box has at least five full news feeds, and a half-dozen partial feeds. There is also a vertical feed to another box that combines the sum from each box, cross-feeds between first two boxes and pass that sum on to another box running inn, all over FDX links. These systems are beating on the spool drives very hard. The boxes run anywhere from 20 minutes to two days before encountering a SCSI error, with the average life around two hours (although when awakened in the dead of night, it seems more frequent than that). Sometimes we can't even get through the cleanup-after-crash before getting another error, a time when there is minimal load on the system. NONE of the messages end up getting logged, unless it is one of those VERY RARE events where the system somewhat recovers and keeps running. Once in a while, they are accompanied by a panic which does not get logged. To attempt to isolate/eliminate all these problems, we have: o Replaced SCSI controller boards, not just moved them from one box to the other. o Tried disabling the drive termination and using a real terminating pack. o Tried running the 2940Us in non-Ultra mode. o Replaced all SCSI cables with Ultra-compliant cables (<1.5M). o Replaced drives repeatedly. Also reformatted several and re-tried them. o Tried running drives in ASYNC mode, slowest mode available. o Removed half of main memory and after another error, swapped the other o 64Meg in, in case of a memory flaw. Note all memory is parity memory. o Removed and run without cache module. o Since we found the four chips on the fireballs live up to the name and become too hot to touch during active operation, we installed 100CFM fans blowing directly across the drive boards at a distance of 3". o Concerned about power glitches, we added as much as 500 watts of power supply to one units, the other units increased to 300 and 400watts. These supplies are connected to a 50KVA UPS system. o Operated drives in horizontal, vertical and upside-down positions. o Measured vibration. Nowhere near the 1G operating limit. o Put a logic analyzer on the SCSI bus, looking for glitches and noise. Found some glitches which were resolved by replacing cables some weeks back. Also found the adapter (perhaps at drivers direction) apparently issues resets from time to time, some occurring at the failure point. At other times, signals were well within noise and voltage specs. o Monitored +5 and +12 for excessive jitter or undervolts. Replaced two supplies that had more than 0.06 volt ripple, well under the allowed spec. Supplies currently being used have under 0.035 volt ripple when drives are active. o Since the driver also sometimes spits out one or more Drive Not Ready errors at or near the "timed out while idle" error, tried wire-wrapping the drive selects on the drives, in case the jumper blocks were not making good contact. Two months of isolating and trial and it still fails. Now, all of that said, if I build a box with two Seagate drives (a 2GB and a 9GB was all I had handy), I don't get anymore errors, at least not over the one week period this was tried. Now, there are a lot of other variables here, and I plan to re-test this config with the same two drives using the 970921 kernel, but it was an interesting point. Also, I can take these Quantum drives that get these errors and stick them in a DECstation running NetBSD and I don't get any errors, but I can't load them down the same way for various reasons. It seems unlikely that Quantum managed to send us 16 crappy drives that have a built-in personal grudge against FreeBSD. Granted, that out of the 16, we have had two completely fail to date and won't format under the Adaptec BIOS, but even so, the fact that they work on different platforms suggest that there might be some timing issue in the within SCSI driver that hasn't been stamped out yet. The continuing appearance of the illogical-sounding "timed out while idle" message, makes us think there is still a driver problem that Quantum drives tickle perhaps more frequently than other brands. Quantum support doesn't seem to be aware of any problems like this, at least none that the low-level tech I reached would admit to. There doesn't appear to be any newer firmware for these drives either. I didn't get much of a warm fuzzy from these guys, probably because I wasn't running Windows '95, and that seems to be all they know about. I'll be happy to file this as a send-PR, but if the SCSI driver is known to still be broken on this point, I won't waste the effort. Any feedback would be appreciated. Frank Durda IV - only these addresses work:| | or | These Anti-spam addresses expire Oct. 15th | From owner-freebsd-current Tue Sep 23 22:13:26 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id WAA01182 for current-outgoing; Tue, 23 Sep 1997 22:13:26 -0700 (PDT) Received: from implode.root.com (implode.root.com [198.145.90.17]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id WAA01175 for ; Tue, 23 Sep 1997 22:13:22 -0700 (PDT) Received: from implode.root.com (localhost [127.0.0.1]) by implode.root.com (8.8.5/8.8.5) with ESMTP id WAA20124; Tue, 23 Sep 1997 22:15:22 -0700 (PDT) Message-Id: <199709240515.WAA20124@implode.root.com> To: KATO Takenori cc: current@FreeBSD.ORG Subject: Re: Daily SNAPshots at current.freebsd.org shut down for now. In-reply-to: Your message of "Wed, 24 Sep 1997 12:58:32 +0900." <199709240358.MAA04770@gneiss.eps.nagoya-u.ac.jp> From: David Greenman Reply-To: dg@root.com Date: Tue, 23 Sep 1997 22:15:22 -0700 Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >> To undo the change in 1.49/1.41.2.1 of /sys/dev/vn/vn.c may hide the >> panic. But, I think this is NOT real fix. > >I made patches for current and 2.2. They are better than undoing. >Should they be committed? What is wrong with using LK_CANRECURSE ? In any case, the exact cause of the recursive locking needs to be understood before this sort of change is made. -DG David Greenman Core-team/Principal Architect, The FreeBSD Project From owner-freebsd-current Tue Sep 23 22:34:24 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id WAA02425 for current-outgoing; Tue, 23 Sep 1997 22:34:24 -0700 (PDT) Received: from usr07.primenet.com (tlambert@usr07.primenet.com [206.165.6.207]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id WAA02420 for ; Tue, 23 Sep 1997 22:34:22 -0700 (PDT) Received: (from tlambert@localhost) by usr07.primenet.com (8.8.5/8.8.5) id WAA03106; Tue, 23 Sep 1997 22:34:01 -0700 (MST) From: Terry Lambert Message-Id: <199709240534.WAA03106@usr07.primenet.com> Subject: Re: cvs commit: src/sys/conf files src/sys/dev/vx if_vx.c if_vxreg.h src/sys/i386/apm apm.c src/sys/i386/conf GENERIC files.i386 To: gibbs@plutotech.com (Justin T. Gibbs) Date: Wed, 24 Sep 1997 05:34:01 +0000 (GMT) Cc: tlambert@primenet.com, gibbs@plutotech.com, nate@mt.sri.com, bde@zeta.org.au, current@FreeBSD.ORG In-Reply-To: <199709231919.NAA28306@pluto.plutotech.com> from "Justin T. Gibbs" at Sep 23, 97 01:19:15 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > >Ugh. What I meant to say was that the number of entries outstanding > >at one time relative to the number of insertions and deletions that > >take place is small in proportion to the number of hash buckets. This > >would make it relatively rare that a softclock would ever hit an entry. > >It was this rarity I meant to reference, but my fingers were too fast. > > I don't know how rare it is really. You'd have to do some statistics > relating which bucket softclock is currently looking at and the likelihood > of a new timeout being scheduled "close" to that position. I do know that > it is going to be quite rare to have a callout touched more than once > during it's lifetime. 256 ticks is a long time. 1024 ticks is even > longer. Except if I want to up the rate at which softclock fires, which would make the wheel spin faster and the entries live for more softclock ticks, but no more absolute time. 8-(. I suppose you could up the hash size for this, but I like the idea of a sorted and unsorted queue head per bucket better. It solved both problems at the same time, and still lets me up softclock at some later time to get HRT without a massive penalty. All in all, I'd say that this has been a very productive discussion; it would have been a hell of a lot more productive if everyone was in the same room with a whiteboard (8-)), but it's a hell of a lot better than the "inane let's pick a new name for tetris" discussion that resulted from my unfortunate use of an example name in my suggested Makefile fix. Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-current Tue Sep 23 22:51:42 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id WAA03488 for current-outgoing; Tue, 23 Sep 1997 22:51:42 -0700 (PDT) Received: from sendero-ppp.i-connect.net (sendero-ppp.i-Connect.Net [206.190.143.100]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id WAA03483 for ; Tue, 23 Sep 1997 22:51:39 -0700 (PDT) Received: (qmail 24026 invoked by uid 1000); 24 Sep 1997 05:52:02 -0000 Message-ID: X-Mailer: XFMail 1.2-alpha-092397 [p0] on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit MIME-Version: 1.0 Date: Tue, 23 Sep 1997 22:52:02 -0700 (PDT) Organization: Atlas Telecom From: Simon Shapiro To: freebsd-current@freebsd.org Subject: __getcwd() Panic - I give up... Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi Y'all, I gave it all I've got. Ran out of time. On very current -current (tonight), if I connect via ftp, the machine where the ftp server is crashes. It panics inside the __getcwd loop in the end of sys/kern/vfs_syscalls.c Where I am stomped is tht it looks like the fdp pointer gets nulled between the end of the loop and the head. I know we did not have this problem a week ago. Any help will be appreciated very much. --- Sincerely Yours, (Sent on 23-Sep-97, 21:39:46 by XF-Mail) Simon Shapiro Atlas Telecom Senior Architect 14355 SW Allen Blvd., Suite 130 Beaverton OR 97005 Shimon@i-Connect.Net Voice: 503.643.5559, Emergency: 503.799.2313 From owner-freebsd-current Tue Sep 23 22:59:11 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id WAA03942 for current-outgoing; Tue, 23 Sep 1997 22:59:11 -0700 (PDT) Received: from usr07.primenet.com (tlambert@usr07.primenet.com [206.165.6.207]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id WAA03937 for ; Tue, 23 Sep 1997 22:59:09 -0700 (PDT) Received: (from tlambert@localhost) by usr07.primenet.com (8.8.5/8.8.5) id WAA04014; Tue, 23 Sep 1997 22:59:02 -0700 (MST) From: Terry Lambert Message-Id: <199709240559.WAA04014@usr07.primenet.com> Subject: Re: Compile failure on today's current kernel To: Shimon@i-Connect.Net (Simon Shapiro) Date: Wed, 24 Sep 1997 05:59:01 +0000 (GMT) Cc: gibbs@plutotech.com, freebsd-current@FreeBSD.ORG In-Reply-To: from "Simon Shapiro" at Sep 23, 97 00:01:56 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > If you're going to run current, read the current mailing list. > > Is there a presumption i do not read this mailing list? Because I do and > never saw this before. Some of us are newer to FreeBSD than others. That, > in and by itself is not an indication of degraded intelligence, you know. I always rebuild my config because of hard lessons in the past. But other than a response someone complaining, I didn't see a "rebuild config" notification to the list either... I was just lucky that when config files come in, ny shell script automatically cvs log's for the log messages on the delata (config is one of the things it does this for; libkvm is another, libc is another, and the kernel tree is another... save reading the commit list). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-current Tue Sep 23 23:17:35 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id XAA05242 for current-outgoing; Tue, 23 Sep 1997 23:17:35 -0700 (PDT) Received: from usr07.primenet.com (tlambert@usr07.primenet.com [206.165.6.207]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id XAA05230; Tue, 23 Sep 1997 23:17:29 -0700 (PDT) Received: (from tlambert@localhost) by usr07.primenet.com (8.8.5/8.8.5) id XAA04899; Tue, 23 Sep 1997 23:17:23 -0700 (MST) From: Terry Lambert Message-Id: <199709240617.XAA04899@usr07.primenet.com> Subject: Re: New timeout capability (was Re: cvs commit:....) To: dyson@FreeBSD.ORG Date: Wed, 24 Sep 1997 06:17:23 +0000 (GMT) Cc: syssgm@dtir.qld.gov.au, freebsd-current@FreeBSD.ORG In-Reply-To: <199709230920.EAA00190@dyson.iquest.net> from "John S. Dyson" at Sep 23, 97 04:20:00 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > I could possibly imagine a reasonable use for a 16K basic allocation size. 8k is where I typically stop, mostly because of frag size. 1k frags are about my limit. 8-). > I think that 4K performs pretty darned well anyway though. In the > real world, I wouldn't think that one would see much of a performance > difference between 4K and 16K. For 8k, there used to be about a 40% improvement over 4k for iozone; I haven't really tried this for about 5 moths now, though. I expect a bit of a drop for 16k because of the 2k frags, actually. I'd thing that 32k would go back up -- perhaps way up -- because of 4k page aligned frags being good for you. It really matters how sequentially you are accessing your files. For random writes less not equal to 4k, there is a requirement of read-before-write. Technically, you could take this down to 512b, since the VM has the bitmap for it. If so, block sizes over 4k (with frags larger than a disk block) would get relatively more expensive *fast*, as long as you were doing I/O on block boundries. I'm not sure whether I/O on a block boundry for a page causes a read before write or not. It probably does; this is technically not needed, so theres a tiny optimization there for better iozone numbers. 8-). If the read-before-write could be done on a block basis using a block bitmap to indicate which 512b chunks had been read and which hadn't, and you were guaranteed read-before-write, and if you wrote a whole block, you'd map it read without reading, and you respected this bitmap when responding to the dirty bit, well... that'd be a lot of work. 8-). It would also give a more uniform win for block aligned accesses in block increments (ndbm?), and certainly make IOZONE happier, as well as making MSDOS FS happier. So to recap, a 512b aligned write of block 3 in a new 4k page would result in b00001000 in the bitmap, and the dirty bit set on the page. A 43b write in block 5 not crossing a block boundry would result in b00100000 in the bitmap, a 512b read of that block from disk, and a 43b write somewhere in the block, with the dirty bit set on the page. Probably a usesful optimization for fixed size record based random record I/O for records 2k or smaller (so page locality is less of an issue, and so that you shouldn't just read the whole page anyway). I don't know what the impact would be on the pager in the general case; probably not pretty at all, actually. Maybe John could comment (probably to csay I'm insane ;-)). Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-current Tue Sep 23 23:21:45 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id XAA05517 for current-outgoing; Tue, 23 Sep 1997 23:21:45 -0700 (PDT) Received: from usr07.primenet.com (tlambert@usr07.primenet.com [206.165.6.207]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id XAA05512 for ; Tue, 23 Sep 1997 23:21:43 -0700 (PDT) Received: (from tlambert@localhost) by usr07.primenet.com (8.8.5/8.8.5) id XAA05226; Tue, 23 Sep 1997 23:21:04 -0700 (MST) From: Terry Lambert Message-Id: <199709240621.XAA05226@usr07.primenet.com> Subject: Re: new timeout routines To: nate@mt.sri.com (Nate Williams) Date: Wed, 24 Sep 1997 06:21:04 +0000 (GMT) Cc: julian@whistle.com, gibbs@plutotech.com, tlambert@primenet.com, nate@mt.sri.com, bde@zeta.org.au, current@freebsd.org In-Reply-To: <199709231452.IAA07122@rocky.mt.sri.com> from "Nate Williams" at Sep 23, 97 08:52:51 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > These were my thoughts while reading the paper. I was a little > > dissapointed that you didn't implement the compatible interface that > > they originally wrote. > > Now, this is something I don't understand. Why the need for the > 'cookies' in the drivers, since I don't see what it gains us? (Time to > go re-read the code and paper again.) Untimeout this particular timeout without traversing the whole list of possible timeouts. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-current Tue Sep 23 23:24:49 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id XAA05796 for current-outgoing; Tue, 23 Sep 1997 23:24:49 -0700 (PDT) Received: from gneiss.eps.nagoya-u.ac.jp (gneiss.eps.nagoya-u.ac.jp [133.6.57.99]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id XAA05366 for ; Tue, 23 Sep 1997 23:20:02 -0700 (PDT) Received: from marble.eps.nagoya-u.ac.jp (localhost [127.0.0.1]) by gneiss.eps.nagoya-u.ac.jp (8.8.7/3.5Wpl3) with ESMTP id PAA05018; Wed, 24 Sep 1997 15:17:42 +0900 (JST) Message-Id: <199709240617.PAA05018@gneiss.eps.nagoya-u.ac.jp> To: dg@root.com Cc: current@FreeBSD.ORG Subject: Re: Daily SNAPshots at current.freebsd.org shut down for now. From: KATO Takenori In-Reply-To: Your message of "Tue, 23 Sep 1997 22:15:22 -0700" References: <199709240515.WAA20124@implode.root.com> X-Mailer: Mew version 1.70 on Emacs 19.28.1 / Mule 2.3 X-PGP-Fingerprint: 03 72 85 36 62 46 23 03 52 B1 10 22 44 10 0D 9E Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Wed, 24 Sep 1997 15:17:42 +0900 Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > What is wrong with using LK_CANRECURSE ? In any case, the exact cause > of the recursive locking needs to be understood before this sort of change > is made. I agree. We need to understand what happens. ---- KATO Takenori Dept. Earth Planet. Sci., Nagoya Univ., Nagoya, 464-01, Japan PGP public key: finger kato@eclogite.eps.nagoya-u.ac.jp ------------------- Powered by FreeBSD(98) ------------------- From owner-freebsd-current Tue Sep 23 23:31:07 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id XAA06207 for current-outgoing; Tue, 23 Sep 1997 23:31:07 -0700 (PDT) Received: from usr07.primenet.com (tlambert@usr07.primenet.com [206.165.6.207]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id XAA06202 for ; Tue, 23 Sep 1997 23:31:04 -0700 (PDT) Received: (from tlambert@localhost) by usr07.primenet.com (8.8.5/8.8.5) id XAA05589; Tue, 23 Sep 1997 23:30:35 -0700 (MST) From: Terry Lambert Message-Id: <199709240630.XAA05589@usr07.primenet.com> Subject: Re: Help Requested - system Panic in __getcwd() To: chuckr@glue.umd.edu (Chuck Robey) Date: Wed, 24 Sep 1997 06:30:35 +0000 (GMT) Cc: Shimon@i-Connect.Net, freebsd-current@FreeBSD.ORG In-Reply-To: from "Chuck Robey" at Sep 23, 97 09:21:25 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > I think maybe you caught Justin at a bad time, when he was arguing with > Terry (apparently a regular thing). Anyhow, Poul did a little tweaking > with getcwd a little while back, warning that it was a little experimental > at the time, I think. Maybe you're tweaking his tweak now? 1) It's not that regular... 2) We're discussing, not arguing. Arguing would require that one of us call the other a "Scruffy Looking Nerf Herder"... We've managed to keep the discussion civil, and, at least for me, productive: I want HRT at some point, and so far it's helped me immensely to see what would and wouldn't be a friendly way of doing it. Before the discussion, I wouldn't have put a lot of consideration into the issues of "timers which are dequeued before they fire", and could have really mucked things up badly. 8-). Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-current Tue Sep 23 23:41:32 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id XAA07112 for current-outgoing; Tue, 23 Sep 1997 23:41:32 -0700 (PDT) Received: from usr07.primenet.com (tlambert@usr07.primenet.com [206.165.6.207]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id XAA07107 for ; Tue, 23 Sep 1997 23:41:30 -0700 (PDT) Received: (from tlambert@localhost) by usr07.primenet.com (8.8.5/8.8.5) id XAA06060; Tue, 23 Sep 1997 23:39:41 -0700 (MST) From: Terry Lambert Message-Id: <199709240639.XAA06060@usr07.primenet.com> Subject: Re: Daily SNAPshots at current.freebsd.org shut down for now. To: kato@migmatite.eps.nagoya-u.ac.jp (KATO Takenori) Date: Wed, 24 Sep 1997 06:39:41 +0000 (GMT) Cc: jkh@time.cdrom.com, current@FreeBSD.ORG In-Reply-To: <199709240358.MAA04770@gneiss.eps.nagoya-u.ac.jp> from "KATO Takenori" at Sep 24, 97 12:58:32 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > > To undo the change in 1.49/1.41.2.1 of /sys/dev/vn/vn.c may hide the > > panic. But, I think this is NOT real fix. > > I made patches for current and 2.2. They are better than undoing. > Should they be committed? Aiiiiiiiieeeeeee!!!!! The old version of the patch!!!! This is in a for loop! > ! if (vnodelocked) { > ! VOP_UNLOCK(vn->sc_vp); vnodelocked = 0; } You can't leave it set to 1!!!! You do the right thing in the -current patch: [ ... ] > ! if (vnodelocked) { > ! VOP_UNLOCK(vn->sc_vp, 0, curproc); > ! vnodelocked = 0; > ! } Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-current Tue Sep 23 23:43:31 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id XAA07226 for current-outgoing; Tue, 23 Sep 1997 23:43:31 -0700 (PDT) Received: from time.cdrom.com (root@time.cdrom.com [204.216.27.226]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id XAA07219 for ; Tue, 23 Sep 1997 23:43:27 -0700 (PDT) Received: from time.cdrom.com (jkh@localhost.cdrom.com [127.0.0.1]) by time.cdrom.com (8.8.7/8.6.9) with ESMTP id XAA25179 for ; Tue, 23 Sep 1997 23:44:04 -0700 (PDT) To: current@freebsd.org Subject: A correction on my earlier statements concerning the PnP code. Date: Tue, 23 Sep 1997 23:44:03 -0700 Message-ID: <25173.875083443@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Further examination reveals that it was NOT the PnP changes which broke the installion in -current and, as my earlier identification of them as such was in error, I just wanted to take this opportunity to note that fact that also apologise to Luigi and John-Mark for pointing the finger in the wrong direction. It looks like the problem is somewhere else, in the kernel. Jordan From owner-freebsd-current Tue Sep 23 23:46:23 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id XAA07551 for current-outgoing; Tue, 23 Sep 1997 23:46:23 -0700 (PDT) Received: from usr07.primenet.com (tlambert@usr07.primenet.com [206.165.6.207]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id XAA07545 for ; Tue, 23 Sep 1997 23:46:19 -0700 (PDT) Received: (from tlambert@localhost) by usr07.primenet.com (8.8.5/8.8.5) id XAA06352; Tue, 23 Sep 1997 23:45:46 -0700 (MST) From: Terry Lambert Message-Id: <199709240645.XAA06352@usr07.primenet.com> Subject: Re: Daily SNAPshots at current.freebsd.org shut down for now. To: dg@root.com Date: Wed, 24 Sep 1997 06:45:46 +0000 (GMT) Cc: kato@migmatite.eps.nagoya-u.ac.jp, current@FreeBSD.ORG In-Reply-To: <199709240515.WAA20124@implode.root.com> from "David Greenman" at Sep 23, 97 10:15:22 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > >> To undo the change in 1.49/1.41.2.1 of /sys/dev/vn/vn.c may hide the > >> panic. But, I think this is NOT real fix. > > > >I made patches for current and 2.2. They are better than undoing. > >Should they be committed? > > What is wrong with using LK_CANRECURSE ? You have to unlock the same number of times as you lock. The flag tells you when to unlock again (which in true recursion would have been done by the caller after the recursive call completed). > In any case, the exact cause of the recursive locking needs to be > understood before this sort of change is made. I think it's OK (except for the bug in the non-current patch; see other message). You may wish to have someone else code-review it, though. I think it's actually a kludge to a kludge, but I don't see a terrifically clean way of doing what needs to be done that caused the problem in the first place. If you could *know* the lock was held, and hold it on subsequent vp's in all cases, that might be a better fix. But there might be a real need for it to be unlocked (I'm thinking multiple accessors racing on simultaneous parent/child directory traversals). Anyway, someone else should definitely look at it to vet. the code. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-current Wed Sep 24 00:11:51 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id AAA09941 for current-outgoing; Wed, 24 Sep 1997 00:11:51 -0700 (PDT) Received: from schizo.dk.tfs.com (mail.trw.dk [195.8.133.123]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id AAA09922 for ; Wed, 24 Sep 1997 00:11:46 -0700 (PDT) Received: from critter.freebsd.dk (critter.dk.tfs.com [140.145.230.252]) by schizo.dk.tfs.com (8.8.7/8.7.3) with ESMTP id JAA27080; Wed, 24 Sep 1997 09:11:14 +0200 (MET DST) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.8.7/8.8.7) with ESMTP id IAA00463; Wed, 24 Sep 1997 08:26:10 +0200 (CEST) To: Simon Shapiro cc: freebsd-current@freebsd.org Subject: Re: Help Requested - system Panic in __getcwd() In-reply-to: Your message of "Tue, 23 Sep 1997 17:26:25 PDT." Date: Wed, 24 Sep 1997 08:26:09 +0200 Message-ID: <461.875082369@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >The symptoms are a panic, in idle systems, in __getcwd. There is a >reference to a virtual address 0x78 which appears to be invalid. Hi Simon, __getcwd is my baby. Can you give me all the details from the panic ? -- Poul-Henning Kamp FreeBSD coreteam member phk@FreeBSD.ORG "Real hackers run -current on their laptop." From owner-freebsd-current Wed Sep 24 00:11:57 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id AAA09971 for current-outgoing; Wed, 24 Sep 1997 00:11:57 -0700 (PDT) Received: from schizo.dk.tfs.com (mail.trw.dk [195.8.133.123]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id AAA09923; Wed, 24 Sep 1997 00:11:46 -0700 (PDT) Received: from critter.freebsd.dk (critter.dk.tfs.com [140.145.230.252]) by schizo.dk.tfs.com (8.8.7/8.7.3) with ESMTP id JAA27083; Wed, 24 Sep 1997 09:11:14 +0200 (MET DST) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.8.7/8.8.7) with ESMTP id IAA00234; Wed, 24 Sep 1997 08:09:59 +0200 (CEST) To: Nate Williams cc: mobile@freebsd.org, current@freebsd.org, se@freebsd.org Subject: Re: PCCARD in -current broken In-reply-to: Your message of "Tue, 23 Sep 1997 13:29:37 MDT." <199709231929.NAA08312@rocky.mt.sri.com> Date: Wed, 24 Sep 1997 08:09:59 +0200 Message-ID: <232.875081399@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In message <199709231929.NAA08312@rocky.mt.sri.com>, Nate Williams writes: >[ >Forgive the cross-posting, the information is of interest to a number >of folks. >] > >It has been for some time (May). If it works on your box, you're >lucky! (PHK is one of the lucky ones, and it may be related to using >more PCI-like machines, unlike older 'straight-ISA' laptops). Maybe I'm just suffering from from luck and too much knowledge: This is how it works for me: in pccard.conf: #IBM PCMCIA Ethernet I/II card "IBM Corp." "Ethernet" config 0x1 "ed0" 9 ^^^^^ As you can see I hardcode the irq of my card. from dmesg: pcic0: rev 0x04 int a irq 255 on pci0.4.0 pcic1: rev 0x04 int b irq 255 on pci0.4.1 [...] PC-Card VLSI 82C146 (5 mem & 2 I/O windows) pcic: controller irq 3 irq 3 happens to be free... -- Poul-Henning Kamp FreeBSD coreteam member phk@FreeBSD.ORG "Real hackers run -current on their laptop." From owner-freebsd-current Wed Sep 24 00:35:43 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id AAA11327 for current-outgoing; Wed, 24 Sep 1997 00:35:43 -0700 (PDT) Received: from schizo.dk.tfs.com (mail.trw.dk [195.8.133.123]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id AAA11320; Wed, 24 Sep 1997 00:35:37 -0700 (PDT) Received: from critter.freebsd.dk (critter.dk.tfs.com [140.145.230.252]) by schizo.dk.tfs.com (8.8.7/8.7.3) with ESMTP id JAA27163; Wed, 24 Sep 1997 09:35:05 +0200 (MET DST) Received: from critter.freebsd.dk (localhost.dk.tfs.com [127.0.0.1]) by critter.freebsd.dk (8.8.7/8.8.7) with ESMTP id JAA00396; Wed, 24 Sep 1997 09:34:24 +0200 (CEST) To: dyson@freebsd.org, current@freebsd.org Subject: wd.c version 1.138 -> 1.139 broke wdreset ? From: Poul-Henning Kamp Date: Wed, 24 Sep 1997 09:34:22 +0200 Message-ID: <394.875086462@critter.freebsd.dk> Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk It looks to me like the 1.138 to 1.139 commit broke wdreset() ? -- Poul-Henning Kamp FreeBSD coreteam member phk@FreeBSD.ORG "Real hackers run -current on their laptop." From owner-freebsd-current Wed Sep 24 00:38:47 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id AAA11584 for current-outgoing; Wed, 24 Sep 1997 00:38:47 -0700 (PDT) Received: from gneiss.eps.nagoya-u.ac.jp (gneiss.eps.nagoya-u.ac.jp [133.6.57.99]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id AAA11490 for ; Wed, 24 Sep 1997 00:37:05 -0700 (PDT) Received: from marble.eps.nagoya-u.ac.jp (localhost [127.0.0.1]) by gneiss.eps.nagoya-u.ac.jp (8.8.7/3.5Wpl3) with ESMTP id QAA00371; Wed, 24 Sep 1997 16:32:08 +0900 (JST) Message-Id: <199709240732.QAA00371@gneiss.eps.nagoya-u.ac.jp> To: dg@root.com Cc: current@FreeBSD.ORG Subject: Re: Daily SNAPshots at current.freebsd.org shut down for now. From: KATO Takenori In-Reply-To: Your message of "Tue, 23 Sep 1997 22:15:22 -0700" References: <199709240515.WAA20124@implode.root.com> X-Mailer: Mew version 1.70 on Emacs 19.28.1 / Mule 2.3 X-PGP-Fingerprint: 03 72 85 36 62 46 23 03 52 B1 10 22 44 10 0D 9E Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Wed, 24 Sep 1997 16:32:08 +0900 Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > What is wrong with using LK_CANRECURSE ? In any case, the exact cause > of the recursive locking needs to be understood before this sort of change > is made. I received kgdb log (that is, I don't have vmcore). The backtrace shows that vnstrategy is called twice: 1. vnstrategy() locks the vnode. 2. vnstrategy() calls ffs_write(). 3. cluster write stuff calls vnstrategy() again. 4. Because the vnode has been already locked, VOP_LOCK/vn_lock causes recursive lock. I think problem is in cluster write stuff. It may expect fs stuff supports reentrance, but vnode fs expect it is not reentered. So, possible fixes are: 1. revise cluster write stuff. 2. revise vn.c. ----- kgdb log ---- #0 boot (howto=260) at ../../kern/kern_shutdown.c:266 266 dumppcb.pcb_cr3 = rcr3(); (kgdb) bt #0 boot (howto=260) at ../../kern/kern_shutdown.c:266 #1 0xf010162e in db_fncall (dummy1=-272631644, dummy2=0, dummy3=-266585388, dummy4=0xefbff860 "\n") at ../../ddb/db_command.c:539 #2 0xf0101365 in db_command (last_cmdp=0xf01bbb24, cmd_table=0xf01bb974, aux_cmd_tablep=0xf01cd0f8) at ../../ddb/db_command.c:337 #3 0xf01014e2 in db_command_loop () at ../../ddb/db_command.c:462 #4 0xf0103c28 in db_trap (type=3, code=0) at ../../ddb/db_trap.c:73 #5 0xf019ccbb in kdb_trap (type=3, code=0, regs=0xefbff950) at ../../i386/i386/db_interface.c:126 #6 0xf01a6164 in trap (frame={tf_es = 16, tf_ds = 16, tf_edi = -262329344, tf_esi = -266824827, tf_ebp = -272631404, tf_isp = -272631432, tf_ebx = 256, tf_edx = -266744191, tf_ecx = 1017, tf_eax = 18, tf_trapno = 3, tf_err = 0, tf_eip = -266744135, tf_cs = -272695288, tf_eflags = 582, tf_esp = -266744207, tf_ss = -267318696}) at ../../i386/i386/trap.c:403 #7 0xf019ceb9 in Debugger (msg=0xf0110a58 "panic") at ../../i386/i386/db_interface.c:254 #8 0xf0110aba in panic ( fmt=0xf0189385 "ufs_lock: recursive lock not expected, pid: %d\n") at ../../kern/kern_shutdown.c:388 #9 0xf018941e in ufs_lock (ap=0xefbffa24) at ../../ufs/ufs/ufs_vnops.c:1715 #10 0xf010463e in vnstrategy (bp=0xf250c2e8) at vnode_if.h:731 #11 0xf0134e5e in spec_strategy (ap=0xefbffab0) at ../../miscfs/specfs/spec_vnops.c:511 #12 0xf01895ea in ufs_strategy (ap=0xefbffab0) at ../../ufs/ufs/ufs_vnops.c:1839 #13 0xf01274f0 in bwrite (bp=0xf250c2e8) at vnode_if.h:1116 #14 0xf01275ba in vn_bwrite (ap=0xefbffaec) at ../../kern/vfs_bio.c:386 #15 0xf0127f8c in vfs_bio_awrite (bp=0xf250c2e8) at vnode_if.h:1133 #16 0xf01281a0 in getnewbuf (slpflag=0, slptimeo=0, size=4096, maxsize=4096) at ../../kern/vfs_bio.c:924 #17 0xf01286d5 in getblk (vp=0xf05a7180, blkno=219, size=4096, slpflag=0, slptimeo=0) at ../../kern/vfs_bio.c:1197 #18 0xf0180479 in ffs_balloc (ip=0xf0597200, bn=219, size=4096, cred=0xf05a1e80, bpp=0xefbffc90, flags=0) at ../../ufs/ffs/ffs_balloc.c:286 #19 0xf018338d in ffs_write (ap=0xefbffce4) at ../../ufs/ufs/ufs_readwrite.c:260 #20 0xf01046a4 in vnstrategy (bp=0xf24e40f4) at vnode_if.h:283 #21 0xf0134e5e in spec_strategy (ap=0xefbffd84) at ../../miscfs/specfs/spec_vnops.c:511 #22 0xf01895ea in ufs_strategy (ap=0xefbffd84) at ../../ufs/ufs/ufs_vnops.c:1839 #23 0xf01274f0 in bwrite (bp=0xf24e40f4) at vnode_if.h:1116 #24 0xf01275ba in vn_bwrite (ap=0xefbffda4) at ../../kern/vfs_bio.c:386 #25 0xf01276c8 in bawrite (bp=0xf24e40f4) at vnode_if.h:1133 #26 0xf012af17 in cluster_wbuild (vp=0xf059bb00, size=4096, start_lbn=188, len=16) at ../../kern/vfs_cluster.c:705 #27 0xf012ab21 in cluster_write (bp=0xf250e0fc, filesize=770048) at ../../kern/vfs_cluster.c:555 #28 0xf0183584 in ffs_write (ap=0xefbffee8) at ../../ufs/ufs/ufs_readwrite.c:291 #29 0xf0131597 in vn_write (fp=0xf05da400, uio=0xefbfff34, cred=0xf058ad80) at vnode_if.h:283 #30 0xf0117c83 in write (p=0xf04f9a00, uap=0xefbfff94, retval=0xefbfff84) at ../../kern/sys_generic.c:263 #31 0xf01a6ba7 in syscall (frame={tf_es = 39, tf_ds = -272695257, tf_edi = 73728, tf_esi = 4, tf_ebp = -272640220, tf_isp = -272629788, tf_ebx = 0, tf_edx = 512, tf_ecx = 0, tf_eax = 4, tf_trapno = 0, tf_err = 7, tf_eip = 134708913, tf_cs = 31, tf_eflags = 582, tf_esp = -272640244, tf_ss = 39}) at ../../i386/i386/trap.c:890 #32 0x8077eb1 in ?? () #33 0x9741 in ?? () #34 0x9c29 in ?? () #35 0x4c2c in ?? () #36 0x7b89 in ?? () #37 0x1095 in ?? () ----- end ----- ---- KATO Takenori Dept. Earth Planet. Sci., Nagoya Univ., Nagoya, 464-01, Japan PGP public key: finger kato@eclogite.eps.nagoya-u.ac.jp ------------------- Powered by FreeBSD(98) ------------------- From owner-freebsd-current Wed Sep 24 00:57:26 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id AAA12867 for current-outgoing; Wed, 24 Sep 1997 00:57:26 -0700 (PDT) Received: from dyson.iquest.net (dyson.iquest.net [198.70.144.127]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id AAA12852; Wed, 24 Sep 1997 00:56:55 -0700 (PDT) Received: (from root@localhost) by dyson.iquest.net (8.8.6/8.8.5) id CAA03553; Wed, 24 Sep 1997 02:56:34 -0500 (EST) From: "John S. Dyson" Message-Id: <199709240756.CAA03553@dyson.iquest.net> Subject: Re: wd.c version 1.138 -> 1.139 broke wdreset ? In-Reply-To: <394.875086462@critter.freebsd.dk> from Poul-Henning Kamp at "Sep 24, 97 09:34:22 am" To: phk@freebsd.org (Poul-Henning Kamp) Date: Wed, 24 Sep 1997 02:56:34 -0500 (EST) Cc: dyson@freebsd.org, current@freebsd.org X-Mailer: ELM [version 2.4ME+ PL31 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Poul-Henning Kamp said: > > It looks to me like the 1.138 to 1.139 commit broke wdreset() ? > Shouldn't have. The only substantial change that I made was to support a different mechanism for the alternate port address. Maybe, if it doesn't work for you, try printing out the value of the alt port addr. I'll be in town until about 13 hr from now, so I can probably help. I will also try turning APM mode on my drives, and see if that works. -- John dyson@freebsd.org jdyson@nc.com From owner-freebsd-current Wed Sep 24 01:07:39 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id BAA13449 for current-outgoing; Wed, 24 Sep 1997 01:07:39 -0700 (PDT) Received: from schizo.dk.tfs.com (mail.trw.dk [195.8.133.123]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id BAA13442; Wed, 24 Sep 1997 01:07:33 -0700 (PDT) Received: from critter.freebsd.dk (critter.dk.tfs.com [140.145.230.252]) by schizo.dk.tfs.com (8.8.7/8.7.3) with ESMTP id KAA27249; Wed, 24 Sep 1997 10:07:01 +0200 (MET DST) Received: from critter.freebsd.dk (localhost.dk.tfs.com [127.0.0.1]) by critter.freebsd.dk (8.8.7/8.8.7) with ESMTP id KAA00659; Wed, 24 Sep 1997 10:06:21 +0200 (CEST) To: "John S. Dyson" cc: dyson@freebsd.org, current@freebsd.org Subject: Re: wd.c version 1.138 -> 1.139 broke wdreset ? In-reply-to: Your message of "Wed, 24 Sep 1997 02:56:34 CDT." <199709240756.CAA03553@dyson.iquest.net> Date: Wed, 24 Sep 1997 10:06:20 +0200 Message-ID: <657.875088380@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In message <199709240756.CAA03553@dyson.iquest.net>, "John S. Dyson" writes: >Poul-Henning Kamp said: >> >> It looks to me like the 1.138 to 1.139 commit broke wdreset() ? >> >Shouldn't have. The only substantial change that I made was to support >a different mechanism for the alternate port address. Maybe, if it doesn't >work for you, try printing out the value of the alt port addr. I'll be in >town until about 13 hr from now, so I can probably help. I will also try >turning APM mode on my drives, and see if that works. Well, I couldn't resume my laptops disk until I backed this out. Soren complained about lack of recovery the other evening in case of a bad block, I belive it is the same problem. I'm unfortunately at work, so I cannot tweak it now :-( -- Poul-Henning Kamp FreeBSD coreteam member phk@FreeBSD.ORG "Real hackers run -current on their laptop." From owner-freebsd-current Wed Sep 24 01:51:12 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id BAA16501 for current-outgoing; Wed, 24 Sep 1997 01:51:12 -0700 (PDT) Received: from schizo.dk.tfs.com (mail.trw.dk [195.8.133.123]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id BAA16495 for ; Wed, 24 Sep 1997 01:51:07 -0700 (PDT) Received: from critter.freebsd.dk (critter.dk.tfs.com [140.145.230.252]) by schizo.dk.tfs.com (8.8.7/8.7.3) with ESMTP id KAA27471; Wed, 24 Sep 1997 10:50:35 +0200 (MET DST) Received: from critter.freebsd.dk (localhost.dk.tfs.com [127.0.0.1]) by critter.freebsd.dk (8.8.7/8.8.7) with ESMTP id KAA00981; Wed, 24 Sep 1997 10:49:55 +0200 (CEST) To: KATO Takenori cc: dg@root.com, current@FreeBSD.ORG Subject: Re: Daily SNAPshots at current.freebsd.org shut down for now. In-reply-to: Your message of "Wed, 24 Sep 1997 16:32:08 +0900." <199709240732.QAA00371@gneiss.eps.nagoya-u.ac.jp> Date: Wed, 24 Sep 1997 10:49:55 +0200 Message-ID: <979.875090995@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk In message <199709240732.QAA00371@gneiss.eps.nagoya-u.ac.jp>, KATO Takenori wri tes: >I think problem is in cluster write stuff. It may expect fs stuff >supports reentrance, but vnode fs expect it is not reentered. > >So, possible fixes are: > > 1. revise cluster write stuff. > 2. revise vn.c. disable clustering on a per filesystem or mount point basis and disallow it for vn devices. If you think about it, it doesn't make sense in the first place. Poul-Henning -- Poul-Henning Kamp FreeBSD coreteam member phk@FreeBSD.ORG "Real hackers run -current on their laptop." From owner-freebsd-current Wed Sep 24 02:34:19 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id CAA18677 for current-outgoing; Wed, 24 Sep 1997 02:34:19 -0700 (PDT) Received: from silvia.HIP.Berkeley.EDU (ala-ca32-10.ix.netcom.com [199.35.209.74]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id CAA18666 for ; Wed, 24 Sep 1997 02:34:15 -0700 (PDT) Received: (from asami@localhost) by silvia.HIP.Berkeley.EDU (8.8.7/8.6.9) id CAA10986; Wed, 24 Sep 1997 02:34:08 -0700 (PDT) Date: Wed, 24 Sep 1997 02:34:08 -0700 (PDT) Message-Id: <199709240934.CAA10986@silvia.HIP.Berkeley.EDU> To: tlambert@primenet.com CC: tlambert@primenet.com, gurney_j@resnet.uoregon.edu, dima@tejblum.dnttm.rssi.ru, freebsd-current@freebsd.org In-reply-to: <199709191441.HAA05896@usr07.primenet.com> (message from Terry Lambert on Fri, 19 Sep 1997 14:41:17 +0000 (GMT)) Subject: Re: Yet Another bug in src/Makefile From: asami@cs.berkeley.edu (Satoshi Asami) Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk * I am not talking about ports. I know. I'm talking about the modifications I made, after a few months of testing both here and on various other lists. * I sure as hell do not want to rebuild "more", or even do a make install * in /usr/src/include. I want to buildd the *absolute* minimum for the * delta I am playing with -- and not *one file* more or less than that. I suggest you go read the new src/Makefile. Nothing is built by installing stuff in /usr/src/include anymore. There is no target to do exactly what you want, but it is very easy to add a target that will build any subset you want and put it in a separate subdirectory tree as this is essentially what's done in the first few steps of "buildworld". * I find it really surprising that you can in any way believe a * reference to a file can be in any way satisfied by the * contents of /usr/src/sys/i386/include, save for me doing a rebuild * of my /usr/include directory. That's what DESTDIR is for. The framework was already mostly there, we only needed to fix some little stuff other than the big patch to src/Makefile. Satoshi From owner-freebsd-current Wed Sep 24 02:55:21 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id CAA19622 for current-outgoing; Wed, 24 Sep 1997 02:55:21 -0700 (PDT) Received: from hydrogen.nike.efn.org (resnet.uoregon.edu [128.223.170.28]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id CAA19617 for ; Wed, 24 Sep 1997 02:55:18 -0700 (PDT) Received: (from jmg@localhost) by hydrogen.nike.efn.org (8.8.7/8.8.7) id CAA07361; Wed, 24 Sep 1997 02:55:16 -0700 (PDT) Message-ID: <19970924025515.60364@hydrogen.nike.efn.org> Date: Wed, 24 Sep 1997 02:55:15 -0700 From: John-Mark Gurney To: current@FreeBSD.ORG Subject: timeout management (was: Re: cvs commit: ...) References: <199709220505.XAA29116@rocky.mt.sri.com> <199709220548.XAA08824@pluto.plutotech.com> <199709221839.MAA01809@rocky.mt.sri.com> <19970922233930.12159@hydrogen.nike.efn.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.69 In-Reply-To: <19970922233930.12159@hydrogen.nike.efn.org>; from John-Mark Gurney on Mon, Sep 22, 1997 at 11:39:30PM -0700 Reply-To: John-Mark Gurney Organization: Cu Networking X-Operating-System: FreeBSD 2.2.1-RELEASE i386 X-PGP-Fingerprint: B7 EC EF F8 AE ED A7 31 96 7A 22 B3 D8 56 36 F4 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk well... I proposed that we used a fibonacci heap as a solution to this problem... the fibonacci heap will do: FUNCTION TIMING (amortized) add new timeout O(1) check for timeout O(1) expire x timeouts O(x lg n) for n = number of timeouts remove a timeout O(lg n) for n = number of timeouts now, you have to take into account that this is amortized time... so at points in time, they may take longer.. but all the major work is actually done when you remove a timeout... I have preliminaty code that will implement a generic fibonacci heap, but it would not be ideal for something like this (to many function calls in my option)... it also doesn't support inital static storage or a free list so it doesn't allocate/deallocate elements unneccessarly I ran some tests.. on my amd k5/90 running tests on my k5, these are the number I come up with: Number Elements Max Heap Size User Time (adv over three runs) 1,000,000 1,000 29.2 1,000,000 100 23.9 1,000,000 10 21.6 as you can see, as the heap grows, the time to process isn't very significant.. and you can probably assume that most of this overhead is in the actual allocation and freeing of the elements.. which adding a freelist would actually help this numbers tremendously... as I stated earlier.. the largest part of this code is the data overhead per element which is currently at 28 bytes.. this includes a void * ptr for your "key", which means with small modification, we can get the data per timeout into 32bytes... that means it would take 16k to store 512 timeouts plus heap overhead (right now 24bytes) plus freelist overhead... if you would like a copy of the code, I'm willing to make it available (under BSD copyright of course) but I still would like to clean and comment the code some more... plus some more regression tests of the code is in order too... -- John-Mark Gurney Modem/FAX: +1 541 683 6954 Cu Networking Live in Peace, destroy Micro$oft, support free software, run FreeBSD From owner-freebsd-current Wed Sep 24 03:22:47 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id DAA20912 for current-outgoing; Wed, 24 Sep 1997 03:22:47 -0700 (PDT) Received: from gneiss.eps.nagoya-u.ac.jp (gneiss.eps.nagoya-u.ac.jp [133.6.57.99]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id DAA20904 for ; Wed, 24 Sep 1997 03:22:34 -0700 (PDT) Received: from marble.eps.nagoya-u.ac.jp (localhost [127.0.0.1]) by gneiss.eps.nagoya-u.ac.jp (8.8.7/3.5Wpl3) with ESMTP id TAA01768; Wed, 24 Sep 1997 19:17:41 +0900 (JST) Message-Id: <199709241017.TAA01768@gneiss.eps.nagoya-u.ac.jp> To: phk@critter.freebsd.dk Cc: current@FreeBSD.ORG Subject: Re: Daily SNAPshots at current.freebsd.org shut down for now. From: KATO Takenori In-Reply-To: Your message of "Wed, 24 Sep 1997 10:49:55 +0200" References: <979.875090995@critter.freebsd.dk> X-Mailer: Mew version 1.70 on Emacs 19.28.1 / Mule 2.3 X-PGP-Fingerprint: 03 72 85 36 62 46 23 03 52 B1 10 22 44 10 0D 9E Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Wed, 24 Sep 1997 19:17:40 +0900 Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > disable clustering on a per filesystem or mount point basis and disallow > it for vn devices. If you think about it, it doesn't make sense in the > first place. How about following following patch? ---------- BEGIN ---------- *** sys/vnode.h.ORIG Wed Sep 24 18:47:16 1997 --- sys/vnode.h Wed Sep 24 18:49:46 1997 *************** *** 111,129 **** /* * Vnode flags. */ ! #define VROOT 0x0001 /* root of its file system */ ! #define VTEXT 0x0002 /* vnode is a pure text prototype */ ! #define VSYSTEM 0x0004 /* vnode being used by kernel */ ! #define VOLOCK 0x0008 /* vnode is locked waiting for an object */ ! #define VOWANT 0x0010 /* a process is waiting for VOLOCK */ ! #define VXLOCK 0x0100 /* vnode is locked to change underlying type */ ! #define VXWANT 0x0200 /* process is waiting for vnode */ ! #define VBWAIT 0x0400 /* waiting for output to complete */ ! #define VALIASED 0x0800 /* vnode has an alias */ ! #define VDIROP 0x1000 /* LFS: vnode is involved in a directory op */ ! #define VVMIO 0x2000 /* VMIO flag */ ! #define VNINACT 0x4000 /* LFS: skip ufs_inactive() in lfs_vunref */ ! #define VAGE 0x8000 /* Insert vnode at head of free list */ /* * Vnode attributes. A field value of VNOVAL represents a field whose value --- 111,130 ---- /* * Vnode flags. */ ! #define VROOT 0x00001 /* root of its file system */ ! #define VTEXT 0x00002 /* vnode is a pure text prototype */ ! #define VSYSTEM 0x00004 /* vnode being used by kernel */ ! #define VOLOCK 0x00008 /* vnode is locked waiting for an object */ ! #define VOWANT 0x00010 /* a process is waiting for VOLOCK */ ! #define VXLOCK 0x00100 /* vnode is locked to change underlying type */ ! #define VXWANT 0x00200 /* process is waiting for vnode */ ! #define VBWAIT 0x00400 /* waiting for output to complete */ ! #define VALIASED 0x00800 /* vnode has an alias */ ! #define VDIROP 0x01000 /* LFS: vnode is involved in a directory op */ ! #define VVMIO 0x02000 /* VMIO flag */ ! #define VNINACT 0x04000 /* LFS: skip ufs_inactive() in lfs_vunref */ ! #define VAGE 0x08000 /* Insert vnode at head of free list */ ! #define VNOCLUSTER 0x10000 /* Disable cluster read and write */ /* * Vnode attributes. A field value of VNOVAL represents a field whose value *** dev/vn/vn.c.ORIG Wed Sep 24 18:59:07 1997 --- dev/vn/vn.c Wed Sep 24 19:00:42 1997 *************** *** 467,472 **** --- 467,473 ---- } VOP_UNLOCK(nd.ni_vp); vn->sc_vp = nd.ni_vp; + vn->sc_vp->v_flag |= VNOCLUSTER; /* disable cluster read write */ vn->sc_size = btodb(vattr.va_size); /* note truncation */ error = vnsetcred(vn, p->p_ucred); if (error) { *** ufs/ufs/ufs_readwrite.c.ORIG Wed Sep 24 18:51:04 1997 --- ufs/ufs/ufs_readwrite.c Wed Sep 24 18:52:38 1997 *************** *** 120,126 **** #else if (lblktosize(fs, nextlbn) >= ip->i_size) error = bread(vp, lbn, size, NOCRED, &bp); ! else if (doclusterread) error = cluster_read(vp, ip->i_size, lbn, size, NOCRED, &bp); else if (lbn - 1 == vp->v_lastr) { --- 120,126 ---- #else if (lblktosize(fs, nextlbn) >= ip->i_size) error = bread(vp, lbn, size, NOCRED, &bp); ! else if (doclusterread && !(vp->v_flag & VNOCLUSTER)) error = cluster_read(vp, ip->i_size, lbn, size, NOCRED, &bp); else if (lbn - 1 == vp->v_lastr) { *************** *** 286,292 **** if (ioflag & IO_SYNC) { (void)bwrite(bp); } else if (xfersize + blkoffset == fs->fs_bsize) { ! if (doclusterwrite) { bp->b_flags |= B_CLUSTEROK; cluster_write(bp, ip->i_size); } else { --- 286,292 ---- if (ioflag & IO_SYNC) { (void)bwrite(bp); } else if (xfersize + blkoffset == fs->fs_bsize) { ! if (doclusterwrite && !(vp->v_flag & VNOCLUSTER)) { bp->b_flags |= B_CLUSTEROK; cluster_write(bp, ip->i_size); } else { *** isofs/cd9660/cd9660_vnops.c.ORIG Wed Sep 24 18:54:59 1997 --- isofs/cd9660/cd9660_vnops.c Wed Sep 24 18:55:38 1997 *************** *** 341,347 **** n = diff; size = iso_blksize(imp, ip, lbn); rablock = lbn + 1; ! if (doclusterread) { if (iso_lblktosize(imp, rablock) <= ip->i_size) error = cluster_read(vp, ip->i_size, lbn, size, NOCRED, &bp); --- 341,347 ---- n = diff; size = iso_blksize(imp, ip, lbn); rablock = lbn + 1; ! if (doclusterread && !(vp->v_flag & VNOCLUSTER)) { if (iso_lblktosize(imp, rablock) <= ip->i_size) error = cluster_read(vp, ip->i_size, lbn, size, NOCRED, &bp); *** gnu/ext2fs/ext2_readwrite.c.ORIG Wed Sep 24 18:53:10 1997 --- gnu/ext2fs/ext2_readwrite.c Wed Sep 24 18:54:24 1997 *************** *** 112,118 **** if (lblktosize(fs, nextlbn) >= ip->i_size) error = bread(vp, lbn, size, NOCRED, &bp); ! else if (doclusterread) error = cluster_read(vp, ip->i_size, lbn, size, NOCRED, &bp); else if (lbn - 1 == vp->v_lastr) { --- 112,118 ---- if (lblktosize(fs, nextlbn) >= ip->i_size) error = bread(vp, lbn, size, NOCRED, &bp); ! else if (doclusterread && !(vp->v_flag & VNOCLUSTER)) error = cluster_read(vp, ip->i_size, lbn, size, NOCRED, &bp); else if (lbn - 1 == vp->v_lastr) { *************** *** 284,290 **** if (ioflag & IO_SYNC) { (void)bwrite(bp); } else if (xfersize + blkoffset == fs->s_frag_size) { ! if (doclusterwrite) { #if defined(__FreeBSD__) bp->b_flags |= B_CLUSTEROK; #endif --- 284,290 ---- if (ioflag & IO_SYNC) { (void)bwrite(bp); } else if (xfersize + blkoffset == fs->s_frag_size) { ! if (doclusterwrite && !(vp->v_flag & VNOCLUSTER)) { #if defined(__FreeBSD__) bp->b_flags |= B_CLUSTEROK; #endif ---- ---- KATO Takenori Dept. Earth Planet. Sci., Nagoya Univ., Nagoya, 464-01, Japan PGP public key: finger kato@eclogite.eps.nagoya-u.ac.jp ------------------- Powered by FreeBSD(98) ------------------- From owner-freebsd-current Wed Sep 24 03:26:55 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id DAA21057 for current-outgoing; Wed, 24 Sep 1997 03:26:55 -0700 (PDT) Received: from schizo.dk.tfs.com (mail.trw.dk [195.8.133.123]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id DAA21052 for ; Wed, 24 Sep 1997 03:26:47 -0700 (PDT) Received: from critter.freebsd.dk (critter.dk.tfs.com [140.145.230.252]) by schizo.dk.tfs.com (8.8.7/8.7.3) with ESMTP id MAA27717; Wed, 24 Sep 1997 12:26:13 +0200 (MET DST) Received: from critter.freebsd.dk (localhost.dk.tfs.com [127.0.0.1]) by critter.freebsd.dk (8.8.7/8.8.7) with ESMTP id MAA01239; Wed, 24 Sep 1997 12:25:32 +0200 (CEST) To: KATO Takenori cc: current@freebsd.org Subject: Re: Daily SNAPshots at current.freebsd.org shut down for now. In-reply-to: Your message of "Wed, 24 Sep 1997 19:17:40 +0900." <199709241017.TAA01768@gneiss.eps.nagoya-u.ac.jp> Date: Wed, 24 Sep 1997 12:25:31 +0200 Message-ID: <1237.875096731@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In message <199709241017.TAA01768@gneiss.eps.nagoya-u.ac.jp>, KATO Takenori wri tes: >> disable clustering on a per filesystem or mount point basis and disallow >> it for vn devices. If you think about it, it doesn't make sense in the >> first place. > >How about following following patch? Looks good. I would suggest you make a mount option for it so you can decide for other filesystems if you want clustering or not. Go for it! Poul-Henning. > >---------- BEGIN ---------- >*** sys/vnode.h.ORIG Wed Sep 24 18:47:16 1997 >--- sys/vnode.h Wed Sep 24 18:49:46 1997 >*************** >*** 111,129 **** > /* > * Vnode flags. > */ >! #define VROOT 0x0001 /* root of its file system */ >! #define VTEXT 0x0002 /* vnode is a pure text prototype */ >! #define VSYSTEM 0x0004 /* vnode being used by kernel */ >! #define VOLOCK 0x0008 /* vnode is locked waiting for an objec >t */ >! #define VOWANT 0x0010 /* a process is waiting for VOLOCK */ >! #define VXLOCK 0x0100 /* vnode is locked to change underlying > type */ >! #define VXWANT 0x0200 /* process is waiting for vnode */ >! #define VBWAIT 0x0400 /* waiting for output to complete */ >! #define VALIASED 0x0800 /* vnode has an alias */ >! #define VDIROP 0x1000 /* LFS: vnode is involved in a director >y op */ >! #define VVMIO 0x2000 /* VMIO flag */ >! #define VNINACT 0x4000 /* LFS: skip ufs_inactive() in lfs_vunr >ef */ >! #define VAGE 0x8000 /* Insert vnode at head of free list */ > > /* > * Vnode attributes. A field value of VNOVAL represents a field whose value >--- 111,130 ---- > /* > * Vnode flags. > */ >! #define VROOT 0x00001 /* root of its file system */ >! #define VTEXT 0x00002 /* vnode is a pure text prototype */ >! #define VSYSTEM 0x00004 /* vnode being used by kernel */ >! #define VOLOCK 0x00008 /* vnode is locked waiting for an objec >t */ >! #define VOWANT 0x00010 /* a process is waiting for VOLOCK */ >! #define VXLOCK 0x00100 /* vnode is locked to change underlying > type */ >! #define VXWANT 0x00200 /* process is waiting for vnode */ >! #define VBWAIT 0x00400 /* waiting for output to complete */ >! #define VALIASED 0x00800 /* vnode has an alias */ >! #define VDIROP 0x01000 /* LFS: vnode is involved in a director >y op */ >! #define VVMIO 0x02000 /* VMIO flag */ >! #define VNINACT 0x04000 /* LFS: skip ufs_inactive() in lfs_vunr >ef */ >! #define VAGE 0x08000 /* Insert vnode at head of free list */ >! #define VNOCLUSTER 0x10000 /* Disable cluster read and write */ > > /* > * Vnode attributes. A field value of VNOVAL represents a field whose value >*** dev/vn/vn.c.ORIG Wed Sep 24 18:59:07 1997 >--- dev/vn/vn.c Wed Sep 24 19:00:42 1997 >*************** >*** 467,472 **** >--- 467,473 ---- > } > VOP_UNLOCK(nd.ni_vp); > vn->sc_vp = nd.ni_vp; >+ vn->sc_vp->v_flag |= VNOCLUSTER; /* disable cluster read > write */ > vn->sc_size = btodb(vattr.va_size); /* note truncation */ > error = vnsetcred(vn, p->p_ucred); > if (error) { >*** ufs/ufs/ufs_readwrite.c.ORIG Wed Sep 24 18:51:04 1997 >--- ufs/ufs/ufs_readwrite.c Wed Sep 24 18:52:38 1997 >*************** >*** 120,126 **** > #else > if (lblktosize(fs, nextlbn) >= ip->i_size) > error = bread(vp, lbn, size, NOCRED, &bp); >! else if (doclusterread) > error = cluster_read(vp, > ip->i_size, lbn, size, NOCRED, &bp); > else if (lbn - 1 == vp->v_lastr) { >--- 120,126 ---- > #else > if (lblktosize(fs, nextlbn) >= ip->i_size) > error = bread(vp, lbn, size, NOCRED, &bp); >! else if (doclusterread && !(vp->v_flag & VNOCLUSTER)) > error = cluster_read(vp, > ip->i_size, lbn, size, NOCRED, &bp); > else if (lbn - 1 == vp->v_lastr) { >*************** >*** 286,292 **** > if (ioflag & IO_SYNC) { > (void)bwrite(bp); > } else if (xfersize + blkoffset == fs->fs_bsize) { >! if (doclusterwrite) { > bp->b_flags |= B_CLUSTEROK; > cluster_write(bp, ip->i_size); > } else { >--- 286,292 ---- > if (ioflag & IO_SYNC) { > (void)bwrite(bp); > } else if (xfersize + blkoffset == fs->fs_bsize) { >! if (doclusterwrite && !(vp->v_flag & VNOCLUSTER)) { > bp->b_flags |= B_CLUSTEROK; > cluster_write(bp, ip->i_size); > } else { >*** isofs/cd9660/cd9660_vnops.c.ORIG Wed Sep 24 18:54:59 1997 >--- isofs/cd9660/cd9660_vnops.c Wed Sep 24 18:55:38 1997 >*************** >*** 341,347 **** > n = diff; > size = iso_blksize(imp, ip, lbn); > rablock = lbn + 1; >! if (doclusterread) { > if (iso_lblktosize(imp, rablock) <= ip->i_size) > error = cluster_read(vp, ip->i_size, > lbn, size, NOCRED, &bp); >--- 341,347 ---- > n = diff; > size = iso_blksize(imp, ip, lbn); > rablock = lbn + 1; >! if (doclusterread && !(vp->v_flag & VNOCLUSTER)) { > if (iso_lblktosize(imp, rablock) <= ip->i_size) > error = cluster_read(vp, ip->i_size, > lbn, size, NOCRED, &bp); >*** gnu/ext2fs/ext2_readwrite.c.ORIG Wed Sep 24 18:53:10 1997 >--- gnu/ext2fs/ext2_readwrite.c Wed Sep 24 18:54:24 1997 >*************** >*** 112,118 **** > > if (lblktosize(fs, nextlbn) >= ip->i_size) > error = bread(vp, lbn, size, NOCRED, &bp); >! else if (doclusterread) > error = cluster_read(vp, > ip->i_size, lbn, size, NOCRED, &bp); > else if (lbn - 1 == vp->v_lastr) { >--- 112,118 ---- > > if (lblktosize(fs, nextlbn) >= ip->i_size) > error = bread(vp, lbn, size, NOCRED, &bp); >! else if (doclusterread && !(vp->v_flag & VNOCLUSTER)) > error = cluster_read(vp, > ip->i_size, lbn, size, NOCRED, &bp); > else if (lbn - 1 == vp->v_lastr) { >*************** >*** 284,290 **** > if (ioflag & IO_SYNC) { > (void)bwrite(bp); > } else if (xfersize + blkoffset == fs->s_frag_size) { >! if (doclusterwrite) { > #if defined(__FreeBSD__) > bp->b_flags |= B_CLUSTEROK; > #endif >--- 284,290 ---- > if (ioflag & IO_SYNC) { > (void)bwrite(bp); > } else if (xfersize + blkoffset == fs->s_frag_size) { >! if (doclusterwrite && !(vp->v_flag & VNOCLUSTER)) { > #if defined(__FreeBSD__) > bp->b_flags |= B_CLUSTEROK; > #endif >---- > > >---- >KATO Takenori >Dept. Earth Planet. Sci., Nagoya Univ., Nagoya, 464-01, Japan >PGP public key: finger kato@eclogite.eps.nagoya-u.ac.jp >------------------- Powered by FreeBSD(98) ------------------- -- Poul-Henning Kamp FreeBSD coreteam member phk@FreeBSD.ORG "Real hackers run -current on their laptop." From owner-freebsd-current Wed Sep 24 07:15:10 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id HAA00568 for current-outgoing; Wed, 24 Sep 1997 07:15:10 -0700 (PDT) Received: from Octopussy.MI.Uni-Koeln.DE (Octopussy.MI.Uni-Koeln.DE [134.95.166.20]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id HAA00553; Wed, 24 Sep 1997 07:15:01 -0700 (PDT) Received: from x14.mi.uni-koeln.de ([134.95.219.124]) by Octopussy.MI.Uni-Koeln.DE with SMTP id AA16883 (5.67b/IDA-1.5); Wed, 24 Sep 1997 16:12:11 +0200 Received: (from se@localhost) by x14.mi.uni-koeln.de (8.8.7/8.6.9) id QAA01331; Wed, 24 Sep 1997 16:00:22 +0200 (CEST) X-Face: " Date: Wed, 24 Sep 1997 16:00:22 +0200 From: Stefan Esser To: Terry Lambert Cc: dyson@FreeBSD.ORG, syssgm@dtir.qld.gov.au, freebsd-current@FreeBSD.ORG Subject: Re: New timeout capability (was Re: cvs commit:....) References: <199709230920.EAA00190@dyson.iquest.net> <199709240617.XAA04899@usr07.primenet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.74 In-Reply-To: <199709240617.XAA04899@usr07.primenet.com>; from Terry Lambert on Wed, Sep 24, 1997 at 06:17:23AM +0000 Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Sep 24, Terry Lambert wrote: > > I think that 4K performs pretty darned well anyway though. In the > > real world, I wouldn't think that one would see much of a performance > > difference between 4K and 16K. > > For 8k, there used to be about a 40% improvement over 4k for iozone; I > haven't really tried this for about 5 moths now, though. Hmmm, did you measure accesses to the char device, block device, or a file ??? If you used the character device, then the difference is due to processing overhead in the drive. But because of the cluster code, requests for small data transfers are only sent to the drive if the data is fragmented, both with 4KB and larger block sizes ... Accesses to the block device should be mostly independent of the request size. 2KB requests are sent to the drive in any case ... I'd be very surprised, if your IOZONE results were different by 40% for file accesses (were clustering helps). Regards, STefan From owner-freebsd-current Wed Sep 24 07:15:33 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id HAA00612 for current-outgoing; Wed, 24 Sep 1997 07:15:33 -0700 (PDT) Received: from Octopussy.MI.Uni-Koeln.DE (Octopussy.MI.Uni-Koeln.DE [134.95.166.20]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id HAA00599 for ; Wed, 24 Sep 1997 07:15:30 -0700 (PDT) Received: from x14.mi.uni-koeln.de ([134.95.219.124]) by Octopussy.MI.Uni-Koeln.DE with SMTP id AA16905 (5.67b/IDA-1.5 for ); Wed, 24 Sep 1997 16:13:06 +0200 Received: (from se@localhost) by x14.mi.uni-koeln.de (8.8.7/8.6.9) id NAA00850; Wed, 24 Sep 1997 13:27:08 +0200 (CEST) X-Face: " Date: Wed, 24 Sep 1997 13:27:07 +0200 From: Stefan Esser To: Ollivier Robert Cc: freebsd-current@FreeBSD.ORG Subject: Re: Assertion failed in ncr driver References: <19970922230618.13112@keltia.freenix.fr> <19970923053330.QX53740@uriah.heep.sax.de> <199709230513.PAA18083@ogre.dtir.qld.gov.au> <19970924022224.06262@keltia.freenix.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.74 In-Reply-To: <19970924022224.06262@keltia.freenix.fr>; from Ollivier Robert on Wed, Sep 24, 1997 at 02:22:24AM +0200 Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Sep 24, Ollivier Robert wrote: > According to Stephen McKay: > > but no promising leads developed. I have no way of reliably reproducing > > the problem, but I do know it has been there a long time because it was > > As for "reliably reproducing", it is very easy. Run dum(8) on /dev/sd0a and > I'll see the messages. Well, then you may want to try without the scsi_start_unit() call in the raw device open function ... Best if you enable SCSI debugging for that target in the generic SCSI code. This will show the command that is responsible for the QUEUE_FULL status, and will let you verify, that in fact no START_STOP_UNIT command is sent anymore, when dump opens the partition to backup. Regards, STefan From owner-freebsd-current Wed Sep 24 07:15:37 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id HAA00632 for current-outgoing; Wed, 24 Sep 1997 07:15:37 -0700 (PDT) Received: from Octopussy.MI.Uni-Koeln.DE (Octopussy.MI.Uni-Koeln.DE [134.95.166.20]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id HAA00598; Wed, 24 Sep 1997 07:15:30 -0700 (PDT) Received: from x14.mi.uni-koeln.de ([134.95.219.124]) by Octopussy.MI.Uni-Koeln.DE with SMTP id AA16896 (5.67b/IDA-1.5); Wed, 24 Sep 1997 16:12:57 +0200 Received: (from se@localhost) by x14.mi.uni-koeln.de (8.8.7/8.6.9) id OAA01092; Wed, 24 Sep 1997 14:47:45 +0200 (CEST) X-Face: " Date: Wed, 24 Sep 1997 14:47:44 +0200 From: Stefan Esser To: Nate Williams Cc: mobile@FreeBSD.ORG, current@FreeBSD.ORG Subject: Re: PCCARD in -current broken References: <199709231929.NAA08312@rocky.mt.sri.com> <19970923230018.00034@mi.uni-koeln.de> <199709232246.QAA09189@rocky.mt.sri.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.74 In-Reply-To: <199709232246.QAA09189@rocky.mt.sri.com>; from Nate Williams on Tue, Sep 23, 1997 at 04:46:56PM -0600 Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Sep 23, Nate Williams wrote: > > There should not be a problem. ISA does not > > (should not, I didn't check the sources > > recently) register the handler as shared, > > and this will prevent another handler (both > > shared or exclusive) to be registered. > > register_intr() sets the INTR_EXCL flag just before it calls > intr_create() (so far so good), but in intr_connect(), the code to check > for that flag is ifdef's out: Well, I have implemented experimental resource registration and check code, but come to the conclusion, that it should be done quite differently ... > int > intr_connect(intrec *idesc) > { > .... > #ifdef RESOURCE_CHECK > resflag = (idesc->flags & INTR_EXCL) ? RESF_NONE : RESF_SHARED; > if (resource_claim(idesc->devdata, REST_INT, resflag, irq, irq) == 0) > #endif /* RESOURCE_CHECK */ > { > > So, we don't even check to see if INTR_EXCL is used. Well, you don't. I do, but I don't rely on that check :) > How does the new code realize that the interrupt is exclusive then? I have implemented a very simple set of functions to claim and check resource usage, and you see the resource_claim() call above. (The code does know resource types (e.g. REST_INT is interrupt), the minimum and maximum value (both passed as "irq" in the example), and a flag that currently only takes the value RESF_SHARED, if a resource may be shared with other uses, as long as all of them have RESF_SHARED set. > > Well, ISA interrupts should be registered in > > a way that guarantees they are not shared. > > How? But the code in -current does not use this function, and to make sure, that no other interrupt is added in combination with an exclusive interrupt, there is the test in add_intrdesc(), which I outlined in my previous reply. > So, can I rely on register_intr() return a negative # for failure? Well, if it fails for you, then there definitely is a bug in the check I added to add_intrdesc(), which is there to avoid just this situation. I assume you are sure that the PCCARD code is only called after the ISA devices are attached ? > (Here's the code in question.) > static u_int > build_freelist(u_int pcic_mask) > { > inthand2_t *nullfunc; > int irq; > u_int mask, freemask; > > /* No free IRQs (yet). */ > freemask = 0; > > /* Walk through all of the IRQ's and find any that aren't allocated. */ > for (irq = 0; irq < ICU_LEN; irq++) { > /* > * If the PCIC controller can't generate it, don't > * bother checking to see if it it's free. > */ > mask = 1 << irq; > if (!(mask & pcic_mask)) continue; > > /* See if the IRQ is free. */ > if (register_intr(irq, 0, 0, nullfunc, NULL, irq) == 0) { > /* Give it back, but add it to the mask */ > INTRMASK(freemask, mask); > unregister_intr(irq, nullfunc); > } > } > #ifdef PCIC_DEBUG > printf("Freelist of IRQ's <0x%x>\n", freemask); > #endif > return freemask; > } Looks fine to me. Lets see what happens after you call register_intr(): [ Much simplified extract from /sys/kern/kern_intr.c ! ] /** INTR_EXCL is added to flags and passed to intr_create(). **/ int register_intr(int intr, int device_id, u_int flags, inthand2_t handler, u_int *maskptr, int unit) { flags |= INTR_EXCL; idesc = intr_create((void *)device_id, intr, handler, (void*)unit, maskptr, flags); return (intr_connect(idesc)); } /** The flags parameter is put into the idesc structure. **/ intrec * intr_create(void *dev_instance, int irq, inthand2_t handler, void *arg, intrmask_t *maskptr, int flags) { idesc = malloc(sizeof *idesc, M_DEVBUF, M_WAITOK); if (idesc) { idesc->flags = flags; } return (idesc); } /** Return the error code from add_intrdesc (rest of code not shown). **/ int intr_connect(intrec *idesc) { errcode = add_intrdesc(idesc); return (errcode); } /** If this is the first handler for this irq, just register it. **/ /** If another handler has been registered before, then make sure, **/ /** that both the old and new handler are for a device that supports **/ /** shared interrupts (does not have INTR_EXCL set). Only the first **/ /** handler can have INTR_EXCL set, since no second one could have **/ /** been added ... **/ static int add_intrdesc(intrec *idesc) { if (head == NULL) { /* first handler for this irq, just install it */ if (icu_setup(irq, idesc->handler, idesc->argument, idesc->maskptr, idesc->flags) != 0) return (-1); } else { if ((idesc->flags & INTR_EXCL) != 0 || (head->flags & INTR_EXCL) != 0) { /* * can't append new handler, if either list head or * new handler do not allow interrupts to be shared */ printf("\tdevice combination doesn't support shared irq%d\n", irq); return (-1); } /* DO REAL WORK */ } return (0); } Well, in fact you should see the "device combination doesn't support ..." message printed, when you call register_intr() to check for the interrupt to be available. If you don't then there is a good chance, that you perform this test, before the ISA devices are attached, and there is no collision reported until the PCCARD attach tries to register a handler for an assumed free IRQ, which has been claimed by an ISA driver in between ... Regards, Stefan From owner-freebsd-current Wed Sep 24 07:15:53 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id HAA00675 for current-outgoing; Wed, 24 Sep 1997 07:15:53 -0700 (PDT) Received: from Octopussy.MI.Uni-Koeln.DE (Octopussy.MI.Uni-Koeln.DE [134.95.166.20]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id HAA00605; Wed, 24 Sep 1997 07:15:31 -0700 (PDT) Received: from x14.mi.uni-koeln.de ([134.95.219.124]) by Octopussy.MI.Uni-Koeln.DE with SMTP id AA16893 (5.67b/IDA-1.5); Wed, 24 Sep 1997 16:12:54 +0200 Received: (from se@localhost) by x14.mi.uni-koeln.de (8.8.7/8.6.9) id PAA01285; Wed, 24 Sep 1997 15:53:02 +0200 (CEST) X-Face: " Date: Wed, 24 Sep 1997 15:53:02 +0200 From: Stefan Esser To: John-Mark Gurney Cc: Nate Williams , mobile@FreeBSD.ORG, current@FreeBSD.ORG, Stefan Esser Subject: Re: PCCARD in -current broken References: <199709231929.NAA08312@rocky.mt.sri.com> <19970923230018.00034@mi.uni-koeln.de> <19970923191710.61639@hydrogen.nike.efn.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.74 In-Reply-To: <19970923191710.61639@hydrogen.nike.efn.org>; from John-Mark Gurney on Tue, Sep 23, 1997 at 07:17:10PM -0700 Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Sep 23, John-Mark Gurney wrote: > > The code is finished, but I did not commit > > it to -current, since I was waiting for the > > new ISA device probe/attach code to become > > available. > > oh... if your waiting for the work that I'm working on.. commit the > changes now.. I don't think that I'll have anything workable in the > next month... as next monday is the first day of classes, and I've been > working this week... so I haven't made any progress yet... Well, as I wrote before, I do not intend to commit that resource check code, since I do no longer consider it the correct approach. I rather want to have a "generic" device struct, which is common to all device types (including, for example, SCSI drives), and which offers a few pointers to methods, upper data structures (i.e. driver and bus specific) and device parameters. (Very much like the Ethernet drivers do, BTW.) I'd expect to be able to call a bus-specific function that allows me to check the resource usage of a device. A function prototype might be: res_check(gendev *dev, int res_type, int flags) This function could redirect the call through a function pointer obtained from dev->xxx and that function could for PCI support res_type values of memory range, port range, IRQ set and DRQ set. The SCSI code should provide a function that checked the SCSI ID. The flags parameter could be used to mark a registration as "shared", or to allow to check for not yet registered but prefered resources of some ISA PnP card. The "extent" registration code from NetBSD is quite generic, and could be used to register the resource usage. But I prefer to query the device data directly, instead of duplicating the information in some generic data base. The device private data contains all the information about the resource usage in a way that allows to represent sparse data (like the set of IRQs or DMA channels used). It is also easy to check for resources this device would use, if it was attached. This may be of use in code that plans address ranges for ISA PnP devices that can be mapped to certain addresses. No need to register a resource, BTW. As soon as the device struct is available to the probe code (either as a DATA_SET or the isa_devtab_xxx array), the device's data is available to the resource check functions. Only the device state has to be set (unused, attached, possibly intermediate states). The test for resource usage would search through the bus and device tree, but in many cases the search of a subtree can be avoided (e.g. a PCI to PCI bridge will claim all address ranges it maps to the secondary side, and thus only devices on a PCI bus directly connected to the CPU have to be checked. This reduces the number of tests that have to be performed in a system with lots of devices. I do not expect the checking against device private data to be much more inefficient than a extent registry, and it is done at driver probe/attach time only, anyway. Other information in this generic device struct should be a unit number and an up pointer to the driver structure (again at least partially generic), which among function pointers contains the driver name. This would allow to build device names for all devices in a uniform way, for example for the reservation conflict message in res_check() ... :) I have put some effort in working out the details, but those changes are of no big use, if they are not applied to all device types (i.e. ISA/EISA/ PCI-Buses, card drivers for these buses, SCSI device drivers, SCSI device structures). > have you actually looked at the extent stuff from NetBSD?? you still > have to write the wrappers around the extent to use the resources, it's > just that it provides a way to do mapping of sections of units... Yes, sure. And I have a simple registration data base in my kernel, which does just register the resource usage. What I do not like about it is: 1) I have to register all resources at attach time and to unregister them when the device is shutdown. I'd rather flip just a single bit in the device data structure, which has to contain all the information anyway. 2) The extent code is "tagged on to the side", and I'd rather just define the prototype of the check function and let each bus driver provide an implementation that complies with the definition. > > Well, ISA interrupts should be registered in > > a way that guarantees they are not shared. > I agree.. but this should be on a bus dependant side... and with the > new isa_device stuff I have invisioned.... we will be able to do more > dynamic sharing of irqs... suchs as marking irqs as only used when > device is active... so you can share irqs between devices... i.e. the > common com1/com3 problem... But the code that makes ISA interrupts exclusive is in a bus dependent function (at least I consider the old register_intr() function to be ISA specific). All new code should only use intr_create(), which creates an interrupt descriptor, and intr_connect() and intr_disconnect() which (in)activates the handler according to the information in that descriptor. (BTW: Connecting or disconnecting the handler does not require a check for conflicts, since the function that manages the shared interrupt handler chain does check for conflicts whenever a handler is added.) The new ISA code definitely should use that interface, and no longer call register_intr() ... Regards, STefan From owner-freebsd-current Wed Sep 24 07:50:45 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id HAA02644 for current-outgoing; Wed, 24 Sep 1997 07:50:45 -0700 (PDT) Received: from gneiss.eps.nagoya-u.ac.jp (gneiss.eps.nagoya-u.ac.jp [133.6.57.99]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id HAA02379 for ; Wed, 24 Sep 1997 07:46:29 -0700 (PDT) Received: from marble.eps.nagoya-u.ac.jp (localhost [127.0.0.1]) by gneiss.eps.nagoya-u.ac.jp (8.8.7/3.5Wpl3) with ESMTP id XAA04074; Wed, 24 Sep 1997 23:39:05 +0900 (JST) Message-Id: <199709241439.XAA04074@gneiss.eps.nagoya-u.ac.jp> To: phk@critter.freebsd.dk Cc: current@freebsd.org Subject: Re: Daily SNAPshots at current.freebsd.org shut down for now. From: KATO Takenori In-Reply-To: Your message of "Wed, 24 Sep 1997 12:25:31 +0200" References: <1237.875096731@critter.freebsd.dk> X-Mailer: Mew version 1.70 on Emacs 19.28.1 / Mule 2.3 X-PGP-Fingerprint: 03 72 85 36 62 46 23 03 52 B1 10 22 44 10 0D 9E Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Wed, 24 Sep 1997 23:39:04 +0900 Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > I would suggest you make a mount option for it so you can decide for > other filesystems if you want clustering or not. I don't have enough time, so what I can do now is to add vnconfig option to disable clustering. (I also think mount option is good mechanism and I need it to use union fs safely.) Followings is patch to add vnconfig option. New option is `n'. Please review. ---------- BEGIN --------- diff -arcN sys.old/dev/vn/vn.c sys/dev/vn/vn.c *** sys.old/dev/vn/vn.c Wed Sep 24 20:27:51 1997 --- sys/dev/vn/vn.c Wed Sep 24 22:41:09 1997 *************** *** 407,413 **** struct nameidata nd; int error; u_long *f; ! IFOPT(vn,VN_FOLLOW) printf("vnioctl(0x%lx, 0x%x, %p, 0x%x, %p): unit %d\n", --- 407,413 ---- struct nameidata nd; int error; u_long *f; ! u_long vflag = 0; IFOPT(vn,VN_FOLLOW) printf("vnioctl(0x%lx, 0x%x, %p, 0x%x, %p): unit %d\n", *************** *** 415,420 **** --- 415,421 ---- switch (cmd) { case VNIOCATTACH: + case VNIOCATTACHNCLUSTER: case VNIOCDETACH: case VNIOCGSET: case VNIOCGCLEAR: *************** *** 446,451 **** --- 447,455 ---- f = (u_long*)data; switch (cmd) { + case VNIOCATTACHNCLUSTER: + vflag = VNOCLUSTER; + /* FALLTHROUGH */ case VNIOCATTACH: if (vn->sc_flags & VNF_INITED) return(EBUSY); *************** *** 467,472 **** --- 471,477 ---- } VOP_UNLOCK(nd.ni_vp); vn->sc_vp = nd.ni_vp; + vn->sc_vp->v_flag |= vflag; vn->sc_size = btodb(vattr.va_size); /* note truncation */ error = vnsetcred(vn, p->p_ucred); if (error) { diff -arcN sys.old/gnu/ext2fs/ext2_readwrite.c sys/gnu/ext2fs/ext2_readwrite.c *** sys.old/gnu/ext2fs/ext2_readwrite.c Wed Sep 24 20:27:46 1997 --- sys/gnu/ext2fs/ext2_readwrite.c Wed Sep 24 22:44:01 1997 *************** *** 112,118 **** if (lblktosize(fs, nextlbn) >= ip->i_size) error = bread(vp, lbn, size, NOCRED, &bp); ! else if (doclusterread) error = cluster_read(vp, ip->i_size, lbn, size, NOCRED, &bp); else if (lbn - 1 == vp->v_lastr) { --- 112,118 ---- if (lblktosize(fs, nextlbn) >= ip->i_size) error = bread(vp, lbn, size, NOCRED, &bp); ! else if (doclusterread && !(vp->v_flag & VNOCLUSTER)) error = cluster_read(vp, ip->i_size, lbn, size, NOCRED, &bp); else if (lbn - 1 == vp->v_lastr) { *************** *** 284,290 **** if (ioflag & IO_SYNC) { (void)bwrite(bp); } else if (xfersize + blkoffset == fs->s_frag_size) { ! if (doclusterwrite) { #if defined(__FreeBSD__) bp->b_flags |= B_CLUSTEROK; #endif --- 284,290 ---- if (ioflag & IO_SYNC) { (void)bwrite(bp); } else if (xfersize + blkoffset == fs->s_frag_size) { ! if (doclusterwrite && !(vp->v_flag & VNOCLUSTER)) { #if defined(__FreeBSD__) bp->b_flags |= B_CLUSTEROK; #endif diff -arcN sys.old/isofs/cd9660/cd9660_vnops.c sys/isofs/cd9660/cd9660_vnops.c *** sys.old/isofs/cd9660/cd9660_vnops.c Wed Sep 24 20:27:09 1997 --- sys/isofs/cd9660/cd9660_vnops.c Wed Sep 24 22:44:40 1997 *************** *** 341,347 **** n = diff; size = iso_blksize(imp, ip, lbn); rablock = lbn + 1; ! if (doclusterread) { if (iso_lblktosize(imp, rablock) <= ip->i_size) error = cluster_read(vp, ip->i_size, lbn, size, NOCRED, &bp); --- 341,347 ---- n = diff; size = iso_blksize(imp, ip, lbn); rablock = lbn + 1; ! if (doclusterread && !(vp->v_flag & VNOCLUSTER)) { if (iso_lblktosize(imp, rablock) <= ip->i_size) error = cluster_read(vp, ip->i_size, lbn, size, NOCRED, &bp); diff -arcN sys.old/sys/vnioctl.h sys/sys/vnioctl.h *** sys.old/sys/vnioctl.h Wed Sep 24 20:26:36 1997 --- sys/sys/vnioctl.h Wed Sep 24 23:24:18 1997 *************** *** 66,71 **** --- 66,73 ---- #define VNIOCGCLEAR _IOWR('F', 3, u_long ) /* reset --//-- */ #define VNIOCUSET _IOWR('F', 4, u_long ) /* set unit option */ #define VNIOCUCLEAR _IOWR('F', 5, u_long ) /* reset --//-- */ + #define VNIOCATTACHNCLUSTER _IOWR('F', 6, struct vn_ioctl) + /* attach file, disable cluster read/write */ #define VN_LABELS 0x1 /* Use disk(/slice) labels */ #define VN_FOLLOW 0x2 /* Debug flow in vn driver */ diff -arcN sys.old/sys/vnode.h sys/sys/vnode.h *** sys.old/sys/vnode.h Wed Sep 24 20:26:36 1997 --- sys/sys/vnode.h Wed Sep 24 22:37:44 1997 *************** *** 111,129 **** /* * Vnode flags. */ ! #define VROOT 0x0001 /* root of its file system */ ! #define VTEXT 0x0002 /* vnode is a pure text prototype */ ! #define VSYSTEM 0x0004 /* vnode being used by kernel */ ! #define VOLOCK 0x0008 /* vnode is locked waiting for an object */ ! #define VOWANT 0x0010 /* a process is waiting for VOLOCK */ ! #define VXLOCK 0x0100 /* vnode is locked to change underlying type */ ! #define VXWANT 0x0200 /* process is waiting for vnode */ ! #define VBWAIT 0x0400 /* waiting for output to complete */ ! #define VALIASED 0x0800 /* vnode has an alias */ ! #define VDIROP 0x1000 /* LFS: vnode is involved in a directory op */ ! #define VVMIO 0x2000 /* VMIO flag */ ! #define VNINACT 0x4000 /* LFS: skip ufs_inactive() in lfs_vunref */ ! #define VAGE 0x8000 /* Insert vnode at head of free list */ /* * Vnode attributes. A field value of VNOVAL represents a field whose value --- 111,130 ---- /* * Vnode flags. */ ! #define VROOT 0x00001 /* root of its file system */ ! #define VTEXT 0x00002 /* vnode is a pure text prototype */ ! #define VSYSTEM 0x00004 /* vnode being used by kernel */ ! #define VOLOCK 0x00008 /* vnode is locked waiting for an object */ ! #define VOWANT 0x00010 /* a process is waiting for VOLOCK */ ! #define VXLOCK 0x00100 /* vnode is locked to change underlying type */ ! #define VXWANT 0x00200 /* process is waiting for vnode */ ! #define VBWAIT 0x00400 /* waiting for output to complete */ ! #define VALIASED 0x00800 /* vnode has an alias */ ! #define VDIROP 0x01000 /* LFS: vnode is involved in a directory op */ ! #define VVMIO 0x02000 /* VMIO flag */ ! #define VNINACT 0x04000 /* LFS: skip ufs_inactive() in lfs_vunref */ ! #define VAGE 0x08000 /* Insert vnode at head of free list */ ! #define VNOCLUSTER 0x10000 /* disable cluster read / write */ /* * Vnode attributes. A field value of VNOVAL represents a field whose value diff -arcN sys.old/ufs/ufs/ufs_readwrite.c sys/ufs/ufs/ufs_readwrite.c *** sys.old/ufs/ufs/ufs_readwrite.c Wed Sep 24 20:26:34 1997 --- sys/ufs/ufs/ufs_readwrite.c Wed Sep 24 22:45:48 1997 *************** *** 120,126 **** #else if (lblktosize(fs, nextlbn) >= ip->i_size) error = bread(vp, lbn, size, NOCRED, &bp); ! else if (doclusterread) error = cluster_read(vp, ip->i_size, lbn, size, NOCRED, &bp); else if (lbn - 1 == vp->v_lastr) { --- 120,126 ---- #else if (lblktosize(fs, nextlbn) >= ip->i_size) error = bread(vp, lbn, size, NOCRED, &bp); ! else if (doclusterread && !(vp->v_flag & VNOCLUSTER)) error = cluster_read(vp, ip->i_size, lbn, size, NOCRED, &bp); else if (lbn - 1 == vp->v_lastr) { *************** *** 286,292 **** if (ioflag & IO_SYNC) { (void)bwrite(bp); } else if (xfersize + blkoffset == fs->fs_bsize) { ! if (doclusterwrite) { bp->b_flags |= B_CLUSTEROK; cluster_write(bp, ip->i_size); } else { --- 286,292 ---- if (ioflag & IO_SYNC) { (void)bwrite(bp); } else if (xfersize + blkoffset == fs->fs_bsize) { ! if (doclusterwrite && !(vp->v_flag & VNOCLUSTER)) { bp->b_flags |= B_CLUSTEROK; cluster_write(bp, ip->i_size); } else { diff -arcN usr.sbin/vnconfig.old/vnconfig.8 usr.sbin/vnconfig/vnconfig.8 *** usr.sbin/vnconfig.old/vnconfig.8 Wed Sep 24 20:42:31 1997 --- usr.sbin/vnconfig/vnconfig.8 Wed Sep 24 22:52:53 1997 *************** *** 81,86 **** --- 81,88 ---- .Fl c . .It Fl d Disables (if possible) the specified feature. + .It Fl n + Disables cluster read and write. .It Fl u Disables and ``unconfigures'' the device. .It Fl v diff -arcN usr.sbin/vnconfig.old/vnconfig.c usr.sbin/vnconfig/vnconfig.c *** usr.sbin/vnconfig.old/vnconfig.c Wed Sep 24 20:42:31 1997 --- usr.sbin/vnconfig/vnconfig.c Wed Sep 24 22:52:13 1997 *************** *** 68,73 **** --- 68,74 ---- #define VN_IGNORE 0x80 #define VN_SET 0x100 #define VN_RESET 0x200 + #define VN_NOCLUSTER 0x400 int nvndisks; *************** *** 158,163 **** --- 159,169 ---- verbose++; break; + /* disable cluster read / write */ + case 'n': + flags |= VN_NOCLUSTER; + break; + default: fprintf(stderr, "invalid option '%c'\n", optopt); usage(); *************** *** 259,271 **** * Configure the device */ if (flags & VN_CONFIG) { ! rv = ioctl(fileno(f), VNIOCATTACH, &vnio); ! if (rv) { ! perror("VNIOCATTACH"); ! flags &= ~VN_ENABLE; ! } else if (verbose) ! printf("%s: %d bytes on %s\n", ! dev, vnio.vn_size, file); } /* * Set an option --- 265,287 ---- * Configure the device */ if (flags & VN_CONFIG) { ! if (flags & VN_NOCLUSTER) { ! rv = ioctl(fileno(f), VNIOCATTACHNCLUSTER, &vnio); ! if (rv) { ! perror("VNIOCATTACHNCLUSTER"); ! flags &= ~VN_ENABLE; ! } else if (verbose) ! printf("%s: %d bytes on %s\n", ! dev, vnio.vn_size, file); ! } else { ! rv = ioctl(fileno(f), VNIOCATTACH, &vnio); ! if (rv) { ! perror("VNIOCATTACH"); ! flags &= ~VN_ENABLE; ! } else if (verbose) ! printf("%s: %d bytes on %s\n", ! dev, vnio.vn_size, file); ! } } /* * Set an option ---------- END --------- ---- KATO Takenori Dept. Earth Planet. Sci., Nagoya Univ., Nagoya, 464-01, Japan PGP public key: finger kato@eclogite.eps.nagoya-u.ac.jp ------------------- Powered by FreeBSD(98) ------------------- From owner-freebsd-current Wed Sep 24 08:23:35 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id IAA04546 for current-outgoing; Wed, 24 Sep 1997 08:23:35 -0700 (PDT) Received: from ns.mt.sri.com (SRI-56K-FR.mt.net [206.127.65.42]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id IAA04541 for ; Wed, 24 Sep 1997 08:23:31 -0700 (PDT) Received: from rocky.mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.8.7/8.8.7) with ESMTP id JAA00986; Wed, 24 Sep 1997 09:23:16 -0600 (MDT) Received: (from nate@localhost) by rocky.mt.sri.com (8.7.5/8.7.3) id JAA12165; Wed, 24 Sep 1997 09:23:14 -0600 (MDT) Date: Wed, 24 Sep 1997 09:23:14 -0600 (MDT) Message-Id: <199709241523.JAA12165@rocky.mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Terry Lambert Cc: nate@mt.sri.com (Nate Williams), julian@whistle.com, gibbs@plutotech.com, bde@zeta.org.au, current@freebsd.org Subject: Re: new timeout routines In-Reply-To: <199709240621.XAA05226@usr07.primenet.com> References: <199709231452.IAA07122@rocky.mt.sri.com> <199709240621.XAA05226@usr07.primenet.com> X-Mailer: VM 6.29 under 19.15 XEmacs Lucid Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > > These were my thoughts while reading the paper. I was a little > > > dissapointed that you didn't implement the compatible interface that > > > they originally wrote. > > > > Now, this is something I don't understand. Why the need for the > > 'cookies' in the drivers, since I don't see what it gains us? (Time to > > go re-read the code and paper again.) > > Untimeout this particular timeout without traversing the whole list > of possible timeouts. Build a hash list that uses the (fn, args) parameter at timeout time (which is what the result of the cookie is), and then get to the timeout via hashing back on this with untimeout(fn, args). No need for the drivers to hold onto the cookie, since you have all the necessary information. Nate From owner-freebsd-current Wed Sep 24 08:27:11 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id IAA04710 for current-outgoing; Wed, 24 Sep 1997 08:27:11 -0700 (PDT) Received: from ns.mt.sri.com (SRI-56K-FR.mt.net [206.127.65.42]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id IAA04700; Wed, 24 Sep 1997 08:27:03 -0700 (PDT) Received: from rocky.mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.8.7/8.8.7) with ESMTP id JAA01010; Wed, 24 Sep 1997 09:27:01 -0600 (MDT) Received: (from nate@localhost) by rocky.mt.sri.com (8.7.5/8.7.3) id JAA12203; Wed, 24 Sep 1997 09:26:59 -0600 (MDT) Date: Wed, 24 Sep 1997 09:26:59 -0600 (MDT) Message-Id: <199709241526.JAA12203@rocky.mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Stefan Esser Cc: Nate Williams , mobile@freebsd.org, current@freebsd.org Subject: Re: PCCARD in -current broken In-Reply-To: <19970924144744.47293@mi.uni-koeln.de> References: <199709231929.NAA08312@rocky.mt.sri.com> <19970923230018.00034@mi.uni-koeln.de> <199709232246.QAA09189@rocky.mt.sri.com> <19970924144744.47293@mi.uni-koeln.de> X-Mailer: VM 6.29 under 19.15 XEmacs Lucid Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > I assume you are sure that the PCCARD code is only > called after the ISA devices are attached ? In autoconf.c/configure: #if NEISA > 0 eisa_configure(); #endif #if NPCI > 0 pci_configure(); #endif #if NISA > 0 isa_configure(); #endif #if NCRD > 0 /* After everyone else has a chance at grabbing resources */ pccard_configure(); #endif > Well, in fact you should see the "device combination doesn't support ..." > message printed, when you call register_intr() to check for the interrupt > to be available. Hmm, do mobile users see these messages who run -current? > If you don't then there is a good chance, that you perform > this test, before the ISA devices are attached, and there is no collision > reported until the PCCARD attach tries to register a handler for an assumed > free IRQ, which has been claimed by an ISA driver in between ... That shouldn't happen (given the code in autoconf.) Sorry for the false alarm, back to the drawing board. Nate From owner-freebsd-current Wed Sep 24 08:36:03 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id IAA05323 for current-outgoing; Wed, 24 Sep 1997 08:36:03 -0700 (PDT) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id IAA05285; Wed, 24 Sep 1997 08:35:55 -0700 (PDT) Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.5/8.6.9) id BAA01330; Thu, 25 Sep 1997 01:33:16 +1000 Date: Thu, 25 Sep 1997 01:33:16 +1000 From: Bruce Evans Message-Id: <199709241533.BAA01330@godzilla.zeta.org.au> To: nate@mt.sri.com, se@FreeBSD.ORG Subject: Re: PCCARD in -current broken Cc: current@FreeBSD.ORG, mobile@FreeBSD.ORG Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >On Sep 23, Nate Williams wrote: >>... >> So, can I rely on register_intr() return a negative # for failure? No, it sometimes returns > 0 for failure, sometimes -1. This is incompatible with the old register_intr(), which always returned > 0 (e.g., EBUSY) for failure. >Well, if it fails for you, then there definitely is >a bug in the check I added to add_intrdesc(), which >is there to avoid just this situation. pccard arctually checks for != 0 for failure, so it should have no problems with this incompatibilty. >Looks fine to me. Lets see what happens after you call >register_intr(): >... >Well, in fact you should see the "device combination doesn't support ..." >message printed, when you call register_intr() to check for the interrupt >to be available. If you don't then there is a good chance, that you perform This part works fine :-). I see these messages a lot because I register some interrupts in drivers and isa_configure() attempts to register them again. Bruce From owner-freebsd-current Wed Sep 24 08:44:15 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id IAA05765 for current-outgoing; Wed, 24 Sep 1997 08:44:15 -0700 (PDT) Received: from bmccane.uit.net (bmccane.uit.net [209.83.205.48]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id IAA05759 for ; Wed, 24 Sep 1997 08:44:10 -0700 (PDT) Received: from bmccane.uit.net (localhost.mccane.com [127.0.0.1]) by bmccane.uit.net (8.8.7/8.8.5) with ESMTP id KAA25118 for ; Wed, 24 Sep 1997 10:44:08 -0500 (CDT) Message-Id: <199709241544.KAA25118@bmccane.uit.net> X-Mailer: exmh version 2.0gamma 1/27/96 To: current@freebsd.org Subject: 2940U broken Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 24 Sep 1997 10:44:07 -0500 From: Wm Brian McCane Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Greetings, I have an interesting problem. I have a Adaptec 2940U controller in my computer. I also have a JVC CD-R in the machine, attached to the 2940U. If I boot FreeBSD with the drive attached the machine crashes in scsi_device_attach according to the panic information. From what I see on the screen, it is trying to read or write to a memory address, and the address it is trying to access is always ASCII "text" values. It would appear that one of the scsi routines is writing a string that is longer than the allocated buffer and killing the stack. Anyone know anything about this? brian From owner-freebsd-current Wed Sep 24 09:11:58 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id JAA07345 for current-outgoing; Wed, 24 Sep 1997 09:11:58 -0700 (PDT) Received: from pluto.plutotech.com (root@mail.plutotech.com [206.168.67.137]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id JAA07337 for ; Wed, 24 Sep 1997 09:11:49 -0700 (PDT) Received: from narnia.plutotech.com (narnia.plutotech.com [206.168.67.130]) by pluto.plutotech.com (8.8.5/8.8.5) with ESMTP id KAA22907; Wed, 24 Sep 1997 10:11:13 -0600 (MDT) Message-Id: <199709241611.KAA22907@pluto.plutotech.com> X-Mailer: exmh version 2.0zeta 7/24/97 To: Nate Williams cc: Terry Lambert , julian@whistle.com, gibbs@plutotech.com, bde@zeta.org.au, current@freebsd.org Subject: Re: new timeout routines In-reply-to: Your message of "Wed, 24 Sep 1997 09:23:14 MDT." <199709241523.JAA12165@rocky.mt.sri.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 24 Sep 1997 10:11:01 -0600 From: "Justin T. Gibbs" Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >Build a hash list that uses the (fn, args) parameter at timeout time >(which is what the result of the cookie is), and then get to the timeout >via hashing back on this with untimeout(fn, args). No need for the >drivers to hold onto the cookie, since you have all the necessary >information. No-one said this wasn't possible. It just takes additional space and makes untimeout's running time non-deterministic. I decided it was an unacceptable tradeoff. >Nate -- Justin T. Gibbs =========================================== FreeBSD: Turning PCs into workstations =========================================== From owner-freebsd-current Wed Sep 24 09:28:31 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id JAA08370 for current-outgoing; Wed, 24 Sep 1997 09:28:31 -0700 (PDT) Received: from relay3.jaring.my (relay3.jaring.my [192.228.128.13]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id JAA08231; Wed, 24 Sep 1997 09:26:29 -0700 (PDT) Received: from localhost. (j2.ptl7.jaring.my [161.142.1.192]) by relay3.jaring.my (8.8.7/8.8.7) with ESMTP id AAA26693; Thu, 25 Sep 1997 00:18:16 +0800 (MYT) Message-Id: <199709241618.AAA26693@relay3.jaring.my> Received: from localhost (localhost [127.0.0.1]) by localhost. (8.8.7/3.4W3) with ESMTP id AAA02877; Thu, 25 Sep 1997 00:15:27 +0800 (MYT) To: current@FreeBSD.ORG, cvs-all@FreeBSD.ORG Cc: luigi@iet.unipi.it, jmg@FreeBSD.ORG, kato@migmatite.eps.nagoya-u.ac.jp, iwasaki@pc.jaring.my Subject: pcm device has a conflict with FreeBSD(98)? (Re: cvs commit: src/sys/i386/isa/snd sound.c) Reply-To: current@FreeBSD.ORG X-Mailer: Mew version 1.06 on Emacs 19.28.1, Mule 2.3 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Date: Thu, 25 Sep 1997 00:15:27 +0800 From: Mitsuru IWASAKI Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hi. > From: John-Mark Gurney > Date: Sun, 14 Sep 1997 23:35:13 -0700 (PDT) > Subject: cvs commit: src/sys/i386/isa/snd sound.c > > jmg 1997/09/14 23:35:13 PDT > > Modified files: > sys/i386/isa/snd sound.c > Log: > add some preprocessor lines to prevent both controler snd0 and > device pcm0 from being loaded into the kernel at the same time. As I've just found that another pcm device driver is in /sys/i386/isa/sound/pcm86.c which is for FreeBSD(98). Does it cause any problems for FreeBSD(98)? # FreeBSD(98) is for NEC PC-98 architecture based PCs. IIRC, config command of FreeBSD(98) has different behavior from original one, and architecture depending codes were separated into /sys/i386 and /sys/pc98. However, I'm not sure whether config of 98 version can handle it well if the pcm device is specified in kernel configuration file. Please look at this; /sys/pc98/conf/files.pc98 ---- pc98/pc98/sio.c optional sio device-driver i386/isa/snd/sound.c optional pcm device-driver i386/isa/snd/dmabuf.c optional pcm device-driver i386/isa/snd/ad1848.c optional pcm device-driver i386/isa/snd/sb_dsp.c optional pcm device-driver i386/isa/snd/clones.c optional pcm device-driver i386/isa/sound/pcm86.c optional pcm device-driver i386/isa/sound/dev_table.c optional snd device-driver /sys/pc98/conf/GENERIC98---- #device pcm0 at isa? port 0xa460 irq 12 vector pcmintr /sys/i386/conf/LINT---- # Luigi's snd code # device pcm0 at isa? port ? tty irq 10 drq 1 flags 0x0 vector pcmintr I suggest that we had better change the name for new pcm driver which developed by Luigi (thanks a lot!), because; - The name "pcm" has been already in used for FreeBSD(98) for long time. - Luckily new pcm driver has just integrated in -current, not in any RELEASEes. # I think alot of FreeBSD(98) users can be confused :-( PS. Sorry, I'm not a FreeBSD(98) user, so cannot test it. -- o [=] O (.~.)_P +=======================oooO==( )//Oooo======================+ | --- Mitsuru IWASAKI ---- | |15A-1-3, Scots Tower, MONT' KIARA CONDOMINIUM, Jalan 1/70C, | |Off Bikit Kiara, 50480 Kuala Lumpur, Malaysia | |TEL/FAX: +60-3-2538579 _/_/_/ _/ | |e-mail: iwasaki@sirim.my(OFFICE) _/ _/ _/ _/ | | iwasaki@pc.jaring.my(HOME) iwasaki@jp.FreeBSD.ORG(FreeBSD) | +============================================================+ From owner-freebsd-current Wed Sep 24 09:44:09 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id JAA09515 for current-outgoing; Wed, 24 Sep 1997 09:44:09 -0700 (PDT) Received: from dyson.iquest.net (dyson.iquest.net [198.70.144.127]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id JAA09509 for ; Wed, 24 Sep 1997 09:44:02 -0700 (PDT) Received: (from root@localhost) by dyson.iquest.net (8.8.6/8.8.5) id LAA04789; Wed, 24 Sep 1997 11:40:43 -0500 (EST) From: "John S. Dyson" Message-Id: <199709241640.LAA04789@dyson.iquest.net> Subject: Re: Daily SNAPshots at current.freebsd.org shut down for now. In-Reply-To: <979.875090995@critter.freebsd.dk> from Poul-Henning Kamp at "Sep 24, 97 10:49:55 am" To: phk@critter.freebsd.dk (Poul-Henning Kamp) Date: Wed, 24 Sep 1997 11:40:42 -0500 (EST) Cc: kato@migmatite.eps.nagoya-u.ac.jp, dg@root.com, current@FreeBSD.ORG Reply-To: dyson@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL31 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Poul-Henning Kamp said: > In message <199709240732.QAA00371@gneiss.eps.nagoya-u.ac.jp>, KATO Takenori wri > tes: > > >I think problem is in cluster write stuff. It may expect fs stuff > >supports reentrance, but vnode fs expect it is not reentered. > > > >So, possible fixes are: > > > > 1. revise cluster write stuff. > > 2. revise vn.c. > > disable clustering on a per filesystem or mount point basis and disallow > it for vn devices. If you think about it, it doesn't make sense in the > first place. > You all are on exactly the right track (IMO.) -- John dyson@freebsd.org jdyson@nc.com From owner-freebsd-current Wed Sep 24 09:45:05 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id JAA09618 for current-outgoing; Wed, 24 Sep 1997 09:45:05 -0700 (PDT) Received: from ns.mt.sri.com (SRI-56K-FR.mt.net [206.127.65.42]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id JAA09612 for ; Wed, 24 Sep 1997 09:45:02 -0700 (PDT) Received: from rocky.mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.8.7/8.8.7) with ESMTP id KAA01542; Wed, 24 Sep 1997 10:44:18 -0600 (MDT) Received: (from nate@localhost) by rocky.mt.sri.com (8.7.5/8.7.3) id KAA12667; Wed, 24 Sep 1997 10:44:16 -0600 (MDT) Date: Wed, 24 Sep 1997 10:44:16 -0600 (MDT) Message-Id: <199709241644.KAA12667@rocky.mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: "Justin T. Gibbs" Cc: Nate Williams , Terry Lambert , julian@whistle.com, bde@zeta.org.au, current@freebsd.org Subject: Re: new timeout routines In-Reply-To: <199709241611.KAA22907@pluto.plutotech.com> References: <199709241523.JAA12165@rocky.mt.sri.com> <199709241611.KAA22907@pluto.plutotech.com> X-Mailer: VM 6.29 under 19.15 XEmacs Lucid Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Justin T. Gibbs writes: > >Build a hash list that uses the (fn, args) parameter at timeout time > >(which is what the result of the cookie is), and then get to the timeout > >via hashing back on this with untimeout(fn, args). No need for the > >drivers to hold onto the cookie, since you have all the necessary > >information. > > No-one said this wasn't possible. It just takes additional space and > makes untimeout's running time non-deterministic. I decided it was > an unacceptable tradeoff. How do you figure? untimeout is now the same as it was before, or aren't the cookies based on a hash table? Nate From owner-freebsd-current Wed Sep 24 09:51:38 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id JAA10028 for current-outgoing; Wed, 24 Sep 1997 09:51:38 -0700 (PDT) Received: from pluto.plutotech.com (root@mail.plutotech.com [206.168.67.137]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id JAA10023 for ; Wed, 24 Sep 1997 09:51:34 -0700 (PDT) Received: from narnia.plutotech.com (narnia.plutotech.com [206.168.67.130]) by pluto.plutotech.com (8.8.5/8.8.5) with ESMTP id KAA23972; Wed, 24 Sep 1997 10:51:24 -0600 (MDT) Message-Id: <199709241651.KAA23972@pluto.plutotech.com> X-Mailer: exmh version 2.0zeta 7/24/97 To: Nate Williams cc: "Justin T. Gibbs" , Terry Lambert , julian@whistle.com, bde@zeta.org.au, current@freebsd.org Subject: Re: new timeout routines In-reply-to: Your message of "Wed, 24 Sep 1997 10:44:16 MDT." <199709241644.KAA12667@rocky.mt.sri.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 24 Sep 1997 10:51:13 -0600 From: "Justin T. Gibbs" Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >> No-one said this wasn't possible. It just takes additional space and >> makes untimeout's running time non-deterministic. I decided it was >> an unacceptable tradeoff. > >How do you figure? untimeout is now the same as it was before, or >aren't the cookies based on a hash table? The cookie is essentially a direct pointer to the entry that needs to be removed. So, removal takes constant time. In your scheme, you need to allocate an additional hash table and add a set of links to each callout entry so it can live both in the callwheel and in the hash table. Then, in untimeout, you must traverse a hash chain of indeterminate length in order to find the entry, hence it is no longer a constant time operation. This wouldn't be a problem if untimeout wasn't called from interrupt contexts, but it is. >Nate -- Justin T. Gibbs =========================================== FreeBSD: Turning PCs into workstations =========================================== From owner-freebsd-current Wed Sep 24 09:55:54 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id JAA10222 for current-outgoing; Wed, 24 Sep 1997 09:55:54 -0700 (PDT) Received: from time.cdrom.com (root@time.cdrom.com [204.216.27.226]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id JAA10214 for ; Wed, 24 Sep 1997 09:55:52 -0700 (PDT) Received: from time.cdrom.com (jkh@localhost.cdrom.com [127.0.0.1]) by time.cdrom.com (8.8.7/8.6.9) with ESMTP id JAA28871; Wed, 24 Sep 1997 09:53:42 -0700 (PDT) To: KATO Takenori cc: phk@critter.freebsd.dk, current@FreeBSD.ORG Subject: Re: Daily SNAPshots at current.freebsd.org shut down for now. In-reply-to: Your message of "Wed, 24 Sep 1997 19:17:40 +0900." <199709241017.TAA01768@gneiss.eps.nagoya-u.ac.jp> Date: Wed, 24 Sep 1997 09:53:42 -0700 Message-ID: <28867.875120022@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > disable clustering on a per filesystem or mount point basis and disallow > > it for vn devices. If you think about it, it doesn't make sense in the > > first place. > > How about following following patch? What's this relative to? It sure doesn't apply to -current. :-( Jordan From owner-freebsd-current Wed Sep 24 09:56:34 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id JAA10299 for current-outgoing; Wed, 24 Sep 1997 09:56:34 -0700 (PDT) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id JAA10293 for ; Wed, 24 Sep 1997 09:56:31 -0700 (PDT) Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.5/8.6.9) id CAA03721; Thu, 25 Sep 1997 02:53:40 +1000 Date: Thu, 25 Sep 1997 02:53:40 +1000 From: Bruce Evans Message-Id: <199709241653.CAA03721@godzilla.zeta.org.au> To: gibbs@plutotech.com, nate@mt.sri.com Subject: Re: new timeout routines Cc: bde@zeta.org.au, current@freebsd.org, julian@whistle.com, tlambert@primenet.com Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >>Build a hash list that uses the (fn, args) parameter at timeout time >>(which is what the result of the cookie is), and then get to the timeout >>via hashing back on this with untimeout(fn, args). No need for the >>drivers to hold onto the cookie, since you have all the necessary >>information. > >No-one said this wasn't possible. It just takes additional space and >makes untimeout's running time non-deterministic. I decided it was >an unacceptable tradeoff. Actually, it could take less space since it wouldn't take any space for cookies (use a non-chained hash table to take no more space in the callout table or a chained hash table to give less non-determinacy). Bruce From owner-freebsd-current Wed Sep 24 09:56:52 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id JAA10319 for current-outgoing; Wed, 24 Sep 1997 09:56:52 -0700 (PDT) Received: from ns.mt.sri.com (SRI-56K-FR.mt.net [206.127.65.42]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id JAA10314 for ; Wed, 24 Sep 1997 09:56:49 -0700 (PDT) Received: from rocky.mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.8.7/8.8.7) with ESMTP id KAA01636; Wed, 24 Sep 1997 10:56:46 -0600 (MDT) Received: (from nate@localhost) by rocky.mt.sri.com (8.7.5/8.7.3) id KAA12715; Wed, 24 Sep 1997 10:56:45 -0600 (MDT) Date: Wed, 24 Sep 1997 10:56:45 -0600 (MDT) Message-Id: <199709241656.KAA12715@rocky.mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: "Justin T. Gibbs" Cc: Nate Williams , current@freebsd.org Subject: Re: new timeout routines In-Reply-To: <199709241651.KAA23972@pluto.plutotech.com> References: <199709241644.KAA12667@rocky.mt.sri.com> <199709241651.KAA23972@pluto.plutotech.com> X-Mailer: VM 6.29 under 19.15 XEmacs Lucid Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Justin T. Gibbs writes: > >> No-one said this wasn't possible. It just takes additional space and > >> makes untimeout's running time non-deterministic. I decided it was > >> an unacceptable tradeoff. > > > >How do you figure? untimeout is now the same as it was before, or > >aren't the cookies based on a hash table? > > The cookie is essentially a direct pointer to the entry that needs to > be removed. So, removal takes constant time. So far so good. (It would be the same length as the number of callouts, or something like it.) > In your scheme, you need > to allocate an additional hash table So far so good. > and add a set of links to each > callout entry so it can live both in the callwheel and in the hash > table. Huh? Why? The hash table contains a direct pointer to the entry which is the same as the cookie. Then, it's the exact same code used with the cookie solution, but w/out requiring changes to the code and drivers. No traversing the hash chain (assuming a perfect hash, which should be pretty easy), and things are still constant time. Seems pretty obvious/simple to me. Nate From owner-freebsd-current Wed Sep 24 09:58:19 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id JAA10416 for current-outgoing; Wed, 24 Sep 1997 09:58:19 -0700 (PDT) Received: from gneiss.eps.nagoya-u.ac.jp (gneiss.eps.nagoya-u.ac.jp [133.6.57.99]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id JAA10396 for ; Wed, 24 Sep 1997 09:58:10 -0700 (PDT) Received: from marble.eps.nagoya-u.ac.jp (localhost [127.0.0.1]) by gneiss.eps.nagoya-u.ac.jp (8.8.7/3.5Wpl3) with ESMTP id BAA04833; Thu, 25 Sep 1997 01:54:55 +0900 (JST) Message-Id: <199709241654.BAA04833@gneiss.eps.nagoya-u.ac.jp> To: jkh@time.cdrom.com Cc: kato@migmatite.eps.nagoya-u.ac.jp, phk@critter.freebsd.dk, current@FreeBSD.ORG Subject: Re: Daily SNAPshots at current.freebsd.org shut down for now. From: KATO Takenori In-Reply-To: Your message of "Wed, 24 Sep 1997 09:53:42 -0700" References: <28867.875120022@time.cdrom.com> X-Mailer: Mew version 1.70 on Emacs 19.28.1 / Mule 2.3 X-PGP-Fingerprint: 03 72 85 36 62 46 23 03 52 B1 10 22 44 10 0D 9E Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Thu, 25 Sep 1997 01:54:55 +0900 Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > What's this relative to? It sure doesn't apply to -current. :-( Sorry, it is for RELENG_2_2. ---- KATO Takenori Dept. Earth Planet. Sci., Nagoya Univ., Nagoya, 464-01, Japan PGP public key: finger kato@eclogite.eps.nagoya-u.ac.jp ------------------- Powered by FreeBSD(98) ------------------- From owner-freebsd-current Wed Sep 24 10:06:17 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id KAA10925 for current-outgoing; Wed, 24 Sep 1997 10:06:17 -0700 (PDT) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id KAA10914 for ; Wed, 24 Sep 1997 10:06:13 -0700 (PDT) Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.5/8.6.9) id DAA04019; Thu, 25 Sep 1997 03:00:55 +1000 Date: Thu, 25 Sep 1997 03:00:55 +1000 From: Bruce Evans Message-Id: <199709241700.DAA04019@godzilla.zeta.org.au> To: gibbs@plutotech.com, nate@mt.sri.com Subject: Re: new timeout routines Cc: bde@zeta.org.au, current@freebsd.org, julian@whistle.com, tlambert@primenet.com Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >> No-one said this wasn't possible. It just takes additional space and >> makes untimeout's running time non-deterministic. I decided it was >> an unacceptable tradeoff. > >How do you figure? untimeout is now the same as it was before, or >aren't the cookies based on a hash table? Hash lookup is non-deterministic, since searching is required to handlle collisions . This wouldn't be important, since hashing is usually fast, except for the small point about untimeout() being called from interrupt handlers where we would prefer deterministic behaviour. Note that hash lookup is not required for timeout() since we don't care about duplicates. Bruce From owner-freebsd-current Wed Sep 24 10:09:57 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id KAA11078 for current-outgoing; Wed, 24 Sep 1997 10:09:57 -0700 (PDT) Received: from pluto.plutotech.com (root@mail.plutotech.com [206.168.67.137]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id KAA11073 for ; Wed, 24 Sep 1997 10:09:49 -0700 (PDT) Received: from narnia.plutotech.com (narnia.plutotech.com [206.168.67.130]) by pluto.plutotech.com (8.8.5/8.8.5) with ESMTP id LAA24417; Wed, 24 Sep 1997 11:09:45 -0600 (MDT) Message-Id: <199709241709.LAA24417@pluto.plutotech.com> X-Mailer: exmh version 2.0zeta 7/24/97 To: Nate Williams cc: "Justin T. Gibbs" , current@freebsd.org Subject: Re: new timeout routines In-reply-to: Your message of "Wed, 24 Sep 1997 10:56:45 MDT." <199709241656.KAA12715@rocky.mt.sri.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 24 Sep 1997 11:09:33 -0600 From: "Justin T. Gibbs" Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >> In your scheme, you need >> to allocate an additional hash table > >So far so good. > >> and add a set of links to each >> callout entry so it can live both in the callwheel and in the hash >> table. > >Huh? Why? The hash table contains a direct pointer to the entry which >is the same as the cookie. Then, it's the exact same code used with >the cookie solution, but w/out requiring changes to the code and >drivers. So you assume that regardless of what pointers the client gives you, even if they give you the same pair twice without an intervening expiration or untimeout call, that there will be no collisions in the hash table? >No traversing the hash chain (assuming a perfect hash, which should be >pretty easy), and things are still constant time. > >Seems pretty obvious/simple to me. It's not obvious to me. Please explain. >Nate > -- Justin T. Gibbs =========================================== FreeBSD: Turning PCs into workstations =========================================== From owner-freebsd-current Wed Sep 24 10:11:35 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id KAA11175 for current-outgoing; Wed, 24 Sep 1997 10:11:35 -0700 (PDT) Received: from ns.mt.sri.com (SRI-56K-FR.mt.net [206.127.65.42]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id KAA11167 for ; Wed, 24 Sep 1997 10:11:32 -0700 (PDT) Received: from rocky.mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.8.7/8.8.7) with ESMTP id LAA01731; Wed, 24 Sep 1997 11:11:19 -0600 (MDT) Received: (from nate@localhost) by rocky.mt.sri.com (8.7.5/8.7.3) id LAA12805; Wed, 24 Sep 1997 11:11:18 -0600 (MDT) Date: Wed, 24 Sep 1997 11:11:18 -0600 (MDT) Message-Id: <199709241711.LAA12805@rocky.mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Bruce Evans Cc: gibbs@plutotech.com, nate@mt.sri.com, current@freebsd.org Subject: Re: new timeout routines In-Reply-To: <199709241700.DAA04019@godzilla.zeta.org.au> References: <199709241700.DAA04019@godzilla.zeta.org.au> X-Mailer: VM 6.29 under 19.15 XEmacs Lucid Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > >> an unacceptable tradeoff. > > > >How do you figure? untimeout is now the same as it was before, or > >aren't the cookies based on a hash table? > > Hash lookup is non-deterministic, since searching is required to handlle > collisions. You had stated earlier that it would be easy to build a perfect hash generator. It would seem to me that using either solution is still fairly predictable 'on average'. > handlers where we would prefer deterministic behaviour. Note that hash > lookup is not required for timeout() since we don't care about duplicates. Right, but hash insertion in the case of duplicates is still non-deterministic. Nate From owner-freebsd-current Wed Sep 24 10:13:33 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id KAA11380 for current-outgoing; Wed, 24 Sep 1997 10:13:33 -0700 (PDT) Received: from ns.mt.sri.com (SRI-56K-FR.mt.net [206.127.65.42]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id KAA11375 for ; Wed, 24 Sep 1997 10:13:30 -0700 (PDT) Received: from rocky.mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.8.7/8.8.7) with ESMTP id LAA01753; Wed, 24 Sep 1997 11:13:28 -0600 (MDT) Received: (from nate@localhost) by rocky.mt.sri.com (8.7.5/8.7.3) id LAA12839; Wed, 24 Sep 1997 11:13:27 -0600 (MDT) Date: Wed, 24 Sep 1997 11:13:27 -0600 (MDT) Message-Id: <199709241713.LAA12839@rocky.mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: "Justin T. Gibbs" Cc: Nate Williams , current@freebsd.org Subject: Re: new timeout routines In-Reply-To: <199709241709.LAA24417@pluto.plutotech.com> References: <199709241656.KAA12715@rocky.mt.sri.com> <199709241709.LAA24417@pluto.plutotech.com> X-Mailer: VM 6.29 under 19.15 XEmacs Lucid Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > So you assume that regardless of what pointers the client gives you, > even if they give you the same pair twice without an intervening > expiration or untimeout call, that there will be no collisions in > the hash table? How did the original code in untimeout() determine what to pull off the table? Obviously there is enough information in the untimeout() call to uniquely determine which entry to use, and that same information was used in timeout(), so we must be able to build a perfect hash function. Nate From owner-freebsd-current Wed Sep 24 10:15:06 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id KAA11512 for current-outgoing; Wed, 24 Sep 1997 10:15:06 -0700 (PDT) Received: from labinfo.iet.unipi.it (labinfo.iet.unipi.it [131.114.9.5]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id KAA11454; Wed, 24 Sep 1997 10:14:35 -0700 (PDT) Received: from localhost (luigi@localhost) by labinfo.iet.unipi.it (8.6.5/8.6.5) id SAA21966; Wed, 24 Sep 1997 18:02:02 +0200 From: Luigi Rizzo Message-Id: <199709241602.SAA21966@labinfo.iet.unipi.it> Subject: Re: pcm device has a conflict with FreeBSD(98)? (Re: cvs commit: src/sys/i386/isa/snd To: current@FreeBSD.ORG Date: Wed, 24 Sep 1997 18:02:02 +0200 (MET DST) Cc: cvs-all@FreeBSD.ORG, luigi@iet.unipi.it, jmg@FreeBSD.ORG, kato@migmatite.eps.nagoya-u.ac.jp, iwasaki@pc.jaring.my In-Reply-To: <199709241618.AAA26693@relay3.jaring.my> from "Mitsuru IWASAKI" at Sep 25, 97 00:15:08 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > Hi. ... > I've just found that another pcm device driver is in > /sys/i386/isa/sound/pcm86.c which is for FreeBSD(98). > Does it cause any problems for FreeBSD(98)? ... > IIRC, config command of FreeBSD(98) has different behavior from > original one, and architecture depending codes were separated into > /sys/i386 and /sys/pc98. However, I'm not sure whether config of 98 > version can handle it well if the pcm device is specified in kernel > configuration file. probably it does not give problems since the only reference to this other pcm device is in /sys/pc98/conf/files.pc98 as you mention. I am sorry for the name clash. If someone has a better name I have no objection. I have picked up "pcm" because "snd" was already in use (and to be honest, the old sound driver really pollutes the name space with all these different devices). The following reasons suggest that the name for the new sound driver be changed: * pc98 pcm was there before The following reasons suggest that the name for the PC98 pcm device is changed: * a potentially smaller user base for the PC98 than for the new sound driver; * the new sound driver is meant to have a single device, named "pcm" (or whatever) which incorporates the functionalities of all subdevices; so "sb", "wss", "gus", "trix", etc are going to disappear anyways; The actual name has not much importance in both cases since it is really a name known only to the kernel (and the config file), there is no other reference in user space or in usual device names. I do not lean for any of the two solutions, provided the new name is reasonable and reminds the functionality of the device (i.e. I would not like to call it "yapcm"!) Cheers Luigi -----------------------------+-------------------------------------- Luigi Rizzo | Dip. di Ingegneria dell'Informazione email: luigi@iet.unipi.it | Universita' di Pisa tel: +39-50-568533 | via Diotisalvi 2, 56126 PISA (Italy) fax: +39-50-568522 | http://www.iet.unipi.it/~luigi/ _____________________________|______________________________________ From owner-freebsd-current Wed Sep 24 10:16:58 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id KAA11702 for current-outgoing; Wed, 24 Sep 1997 10:16:58 -0700 (PDT) Received: from pluto.plutotech.com (root@mail.plutotech.com [206.168.67.137]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id KAA11681 for ; Wed, 24 Sep 1997 10:16:45 -0700 (PDT) Received: from narnia.plutotech.com (narnia.plutotech.com [206.168.67.130]) by pluto.plutotech.com (8.8.5/8.8.5) with ESMTP id LAA24576; Wed, 24 Sep 1997 11:16:27 -0600 (MDT) Message-Id: <199709241716.LAA24576@pluto.plutotech.com> X-Mailer: exmh version 2.0zeta 7/24/97 To: Nate Williams cc: "Justin T. Gibbs" , current@freebsd.org Subject: Re: new timeout routines In-reply-to: Your message of "Wed, 24 Sep 1997 11:13:27 MDT." <199709241713.LAA12839@rocky.mt.sri.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 24 Sep 1997 11:16:15 -0600 From: "Justin T. Gibbs" Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >> So you assume that regardless of what pointers the client gives you, >> even if they give you the same pair twice without an intervening >> expiration or untimeout call, that there will be no collisions in >> the hash table? > >How did the original code in untimeout() determine what to pull off the >table? Obviously there is enough information in the untimeout() call to >uniquely determine which entry to use, and that same information was >used in timeout(), so we must be able to build a perfect hash function. It took the first entry off the list. The NetBSD timeout.9 page lists this as a bug. >Nate -- Justin T. Gibbs =========================================== FreeBSD: Turning PCs into workstations =========================================== From owner-freebsd-current Wed Sep 24 10:19:08 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id KAA11883 for current-outgoing; Wed, 24 Sep 1997 10:19:08 -0700 (PDT) Received: from ns.mt.sri.com (SRI-56K-FR.mt.net [206.127.65.42]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id KAA11865 for ; Wed, 24 Sep 1997 10:19:03 -0700 (PDT) Received: from rocky.mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.8.7/8.8.7) with ESMTP id LAA01794; Wed, 24 Sep 1997 11:19:01 -0600 (MDT) Received: (from nate@localhost) by rocky.mt.sri.com (8.7.5/8.7.3) id LAA12880; Wed, 24 Sep 1997 11:19:00 -0600 (MDT) Date: Wed, 24 Sep 1997 11:19:00 -0600 (MDT) Message-Id: <199709241719.LAA12880@rocky.mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: "Justin T. Gibbs" Cc: Nate Williams , current@freebsd.org Subject: Re: new timeout routines In-Reply-To: <199709241716.LAA24576@pluto.plutotech.com> References: <199709241713.LAA12839@rocky.mt.sri.com> <199709241716.LAA24576@pluto.plutotech.com> X-Mailer: VM 6.29 under 19.15 XEmacs Lucid Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > >> So you assume that regardless of what pointers the client gives you, > >> even if they give you the same pair twice without an intervening > >> expiration or untimeout call, that there will be no collisions in > >> the hash table? > > > >How did the original code in untimeout() determine what to pull off the > >table? Obviously there is enough information in the untimeout() call to > >uniquely determine which entry to use, and that same information was > >used in timeout(), so we must be able to build a perfect hash function. > > It took the first entry off the list. The NetBSD timeout.9 page lists > this as a bug. So, the old behavior (that we've all grown to love now that it's gone. :) was used for this many years, yet was full of bugs? Do hash collisions not ever occur 'in the current pre-CAM system'? Nate From owner-freebsd-current Wed Sep 24 10:31:17 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id KAA12489 for current-outgoing; Wed, 24 Sep 1997 10:31:17 -0700 (PDT) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id KAA12481 for ; Wed, 24 Sep 1997 10:31:14 -0700 (PDT) Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.5/8.6.9) id DAA04836; Thu, 25 Sep 1997 03:26:09 +1000 Date: Thu, 25 Sep 1997 03:26:09 +1000 From: Bruce Evans Message-Id: <199709241726.DAA04836@godzilla.zeta.org.au> To: bde@zeta.org.au, nate@mt.sri.com Subject: Re: new timeout routines Cc: current@freebsd.org, gibbs@plutotech.com Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >> Hash lookup is non-deterministic, since searching is required to handlle >> collisions. > >You had stated earlier that it would be easy to build a perfect hash >generator. Only for a special case. >> handlers where we would prefer deterministic behaviour. Note that hash >> lookup is not required for timeout() since we don't care about duplicates. > >Right, but hash insertion in the case of duplicates is still >non-deterministic. No it isn't, at least for STAILQ chained hash tables. Since we don't care about duplicates, we can just add to the end of the queue. Bruce From owner-freebsd-current Wed Sep 24 10:36:55 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id KAA13013 for current-outgoing; Wed, 24 Sep 1997 10:36:55 -0700 (PDT) Received: from ns.mt.sri.com (SRI-56K-FR.mt.net [206.127.65.42]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id KAA13004 for ; Wed, 24 Sep 1997 10:36:52 -0700 (PDT) Received: from rocky.mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.8.7/8.8.7) with ESMTP id LAA01911; Wed, 24 Sep 1997 11:36:41 -0600 (MDT) Received: (from nate@localhost) by rocky.mt.sri.com (8.7.5/8.7.3) id LAA12962; Wed, 24 Sep 1997 11:36:39 -0600 (MDT) Date: Wed, 24 Sep 1997 11:36:39 -0600 (MDT) Message-Id: <199709241736.LAA12962@rocky.mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Bruce Evans Cc: nate@mt.sri.com, current@freebsd.org, gibbs@plutotech.com Subject: Re: new timeout routines In-Reply-To: <199709241726.DAA04836@godzilla.zeta.org.au> References: <199709241726.DAA04836@godzilla.zeta.org.au> X-Mailer: VM 6.29 under 19.15 XEmacs Lucid Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > >> Hash lookup is non-deterministic, since searching is required to handlle > >> collisions. > > > >You had stated earlier that it would be easy to build a perfect hash > >generator. > > Only for a special case. > > >> handlers where we would prefer deterministic behaviour. Note that hash > >> lookup is not required for timeout() since we don't care about duplicates. > > > >Right, but hash insertion in the case of duplicates is still > >non-deterministic. > > No it isn't, at least for STAILQ chained hash tables. Since we don't care > about duplicates, we can just add to the end of the queue. For an open hash table, yes, for a closed hash table, no. But, that's splitting hairs. (I was thinking of using a closed hash-table.) Nate From owner-freebsd-current Wed Sep 24 11:24:44 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id LAA16200 for current-outgoing; Wed, 24 Sep 1997 11:24:44 -0700 (PDT) Received: from Kitten.mcs.com (Kitten.mcs.com [192.160.127.90]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id LAA16165; Wed, 24 Sep 1997 11:24:28 -0700 (PDT) Received: from Mercury.mcs.net (fredriks@Mercury.mcs.net [192.160.127.80]) by Kitten.mcs.com (8.8.5/8.8.2) with ESMTP id NAA24414; Wed, 24 Sep 1997 13:24:26 -0500 (CDT) Received: (from fredriks@localhost) by Mercury.mcs.net (8.8.7/8.8.2) id NAA19380; Wed, 24 Sep 1997 13:24:26 -0500 (CDT) From: Lars Fredriksen Message-Id: <199709241824.NAA19380@Mercury.mcs.net> Subject: Re: PCCARD in -current broken To: nate@mt.sri.com (Nate Williams) Date: Wed, 24 Sep 1997 13:24:24 -0500 (CDT) Cc: se@FreeBSD.ORG, nate@mt.sri.com, mobile@FreeBSD.ORG, current@FreeBSD.ORG In-Reply-To: <199709241526.JAA12203@rocky.mt.sri.com> from "Nate Williams" at Sep 24, 97 09:26:59 am X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Nate Williams writes: > > > I assume you are sure that the PCCARD code is only > > called after the ISA devices are attached ? > > In autoconf.c/configure: > #if NEISA > 0 > eisa_configure(); > #endif > > #if NPCI > 0 > pci_configure(); > #endif > > #if NISA > 0 > isa_configure(); > #endif > > #if NCRD > 0 > /* After everyone else has a chance at grabbing resources */ > pccard_configure(); > #endif > > > Well, in fact you should see the "device combination doesn't support ..." > > message printed, when you call register_intr() to check for the interrupt > > to be available. > > Hmm, do mobile users see these messages who run -current? Yes, I do see that message. That is when I decided that the interrupt registration is handeled correctly, but that the intrnames array seems not to be maintained correctly. This is where the clk0 gets associated with the irq of the driver that pcic registered when it detected a card and found a driver match. I do probably need to mention that this is on a i486 laptop..... Lars -- ------------------------------------------------------------------- Lars Fredriksen fredriks@mcs.com (home) lars@fredriks-2.pr.mcs.net (home-home) From owner-freebsd-current Wed Sep 24 11:42:09 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id LAA17413 for current-outgoing; Wed, 24 Sep 1997 11:42:09 -0700 (PDT) Received: from news1.gtn.com (news1.gtn.com [192.109.159.3]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id LAA17406 for ; Wed, 24 Sep 1997 11:42:01 -0700 (PDT) Received: (from uucp@localhost) by news1.gtn.com (8.8.6/8.8.6) with UUCP id UAA07344 for current@FreeBSD.ORG; Wed, 24 Sep 1997 20:30:26 +0200 (MET DST) Received: (from andreas@localhost) by klemm.gtn.com (8.8.7/8.8.7) id UAA17030; Wed, 24 Sep 1997 20:21:32 +0200 (CEST) Message-ID: <19970924202132.12490@klemm.gtn.com> Date: Wed, 24 Sep 1997 20:21:32 +0200 From: Andreas Klemm To: current@FreeBSD.ORG Subject: make world fails with conflicting types for `malloc' Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.81 X-Disclaimer: A free society is one where it is safe to be unpopular X-Operating-System: FreeBSD 3.0-CURRENT SMP Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk ===> games/arithmetic cc -nostdinc -O -pipe -I/usr/obj/home/src/tmp/usr/include -c /home/src/games/a rithmetic/arithmetic.c /home/src/games/arithmetic/arithmetic.c: In function `penalise': /home/src/games/arithmetic/arithmetic.c:295: conflicting types for `malloc' /usr/obj/home/src/tmp/usr/include/stdlib.h:100: previous declaration of `malloc' *** Error code 1 Stop. *** Error code 1 Will try to update cvs repository and start over. Just wanted to let you know .... BTW, building a kernel isn't also possible. I rebuild config first and during compilation this error message: root{182} /bisdn/compile/BISDNSMP make cc -c -O -pipe -Wreturn-type -Wcomment -Wredundant-decls -Wimplicit -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -nostdinc -I- -I. -I../.. -I/usr/include -DTELES_HAS_MEMCPYB -DMD5 -DCOMPAT_43 -DNSWAPDEV=3 -DMSDOSFS -DFFS -DINET -DKERNEL -include opt_global.h ../../kern/kern_acct.c ../../kern/kern_acct.c:83: warning: implicit declaration of function `CALLOUT_HANDLE_INITIALIZER' ../../kern/kern_acct.c:83: invalid initializer ../../kern/kern_acct.c: In function `acct': ../../kern/kern_acct.c:149: too many arguments to function `untimeout' ../../kern/kern_acct.c: In function `acctwatch': ../../kern/kern_acct.c:320: void value not ignored as it ought to be *** Error code 1 It's the SMP kernel FYWI. -- Andreas Klemm | klemm.gtn.com - powered by Symmetric MultiProcessor FreeBSD http://www.freebsd.org/~fsmp/SMP/SMP.html http://www.freebsd.org/~fsmp/SMP/benches.html From owner-freebsd-current Wed Sep 24 12:02:10 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id MAA18496 for current-outgoing; Wed, 24 Sep 1997 12:02:10 -0700 (PDT) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id MAA18485 for ; Wed, 24 Sep 1997 12:02:05 -0700 (PDT) Received: (from daemon@localhost) by alpo.whistle.com (8.8.5/8.8.5) id MAA06036; Wed, 24 Sep 1997 12:00:18 -0700 (PDT) Received: from current1.whistle.com(207.76.205.22) via SMTP by alpo.whistle.com, id smtpd006027; Wed Sep 24 19:00:09 1997 Message-ID: <3429630C.167EB0E7@whistle.com> Date: Wed, 24 Sep 1997 11:59:24 -0700 From: Julian Elischer Organization: Whistle Communications X-Mailer: Mozilla 3.0Gold (X11; I; FreeBSD 2.2-CURRENT i386) MIME-Version: 1.0 To: "Justin T. Gibbs" CC: Nate Williams , Terry Lambert , bde@zeta.org.au, current@FreeBSD.ORG Subject: Re: new timeout routines References: <199709241651.KAA23972@pluto.plutotech.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Justin T. Gibbs wrote: > > >> No-one said this wasn't possible. It just takes additional space and > >> makes untimeout's running time non-deterministic. I decided it was > >> an unacceptable tradeoff. > > > >How do you figure? untimeout is now the same as it was before, or > >aren't the cookies based on a hash table? > > The cookie is essentially a direct pointer to the entry that needs to > be removed. So, removal takes constant time. In your scheme, you need > to allocate an additional hash table and add a set of links to each > callout entry so it can live both in the callwheel and in the hash > table. Then, in untimeout, you must traverse a hash chain of indeterminate > length in order to find the entry, hence it is no longer a constant time > operation. This wouldn't be a problem if untimeout wasn't called from > interrupt contexts, but it is. > so what happens if I call untimeout twice? there is an assumption in a lot of code that untimeout is idempotent (did I get that right?). It can be called whenever you are recovering from unknown situations with the sure knowledge that the appropriate timeout will be removed. 1/ there is no way to do this without lots of work now. 2/ old code will break. do you check for a NULL pointer? (I have read the paper but not the code (yet) > >Nate > > -- > Justin T. Gibbs > =========================================== > FreeBSD: Turning PCs into workstations > =========================================== From owner-freebsd-current Wed Sep 24 12:07:53 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id MAA18904 for current-outgoing; Wed, 24 Sep 1997 12:07:53 -0700 (PDT) Received: from ns.mt.sri.com (SRI-56K-FR.mt.net [206.127.65.42]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id MAA18896 for ; Wed, 24 Sep 1997 12:07:47 -0700 (PDT) Received: from rocky.mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.8.7/8.8.7) with ESMTP id NAA02537; Wed, 24 Sep 1997 13:07:32 -0600 (MDT) Received: (from nate@localhost) by rocky.mt.sri.com (8.7.5/8.7.3) id NAA13477; Wed, 24 Sep 1997 13:07:28 -0600 (MDT) Date: Wed, 24 Sep 1997 13:07:28 -0600 (MDT) Message-Id: <199709241907.NAA13477@rocky.mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Julian Elischer Cc: "Justin T. Gibbs" , Nate Williams , Terry Lambert , bde@zeta.org.au, current@freebsd.org Subject: Re: new timeout routines In-Reply-To: <3429630C.167EB0E7@whistle.com> References: <199709241651.KAA23972@pluto.plutotech.com> <3429630C.167EB0E7@whistle.com> X-Mailer: VM 6.29 under 19.15 XEmacs Lucid Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > so what happens if I call untimeout twice? It does the right thing, since we you 'untimeout the function pointer is NULL'd out. > there is an assumption in a lot of code that untimeout is idempotent > (did I get that right?). It can be called whenever you are recovering > from unknown situations with the sure knowledge that the appropriate > timeout will be removed. According to Justin, the old only removed a timeout with the same function/arguements, which may/may not have been the right one, if multiple timeouts with the same function/arguements were created. Nate From owner-freebsd-current Wed Sep 24 12:41:21 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id MAA21376 for current-outgoing; Wed, 24 Sep 1997 12:41:21 -0700 (PDT) Received: from hydrogen.nike.efn.org (resnet.uoregon.edu [128.223.170.28]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id MAA21349; Wed, 24 Sep 1997 12:41:09 -0700 (PDT) Received: (from jmg@localhost) by hydrogen.nike.efn.org (8.8.7/8.8.7) id MAA09270; Wed, 24 Sep 1997 12:41:06 -0700 (PDT) Message-ID: <19970924124106.61317@hydrogen.nike.efn.org> Date: Wed, 24 Sep 1997 12:41:06 -0700 From: John-Mark Gurney To: Stefan Esser Cc: Nate Williams , mobile@freebsd.org, current@freebsd.org Subject: Re: PCCARD in -current broken References: <199709231929.NAA08312@rocky.mt.sri.com> <19970923230018.00034@mi.uni-koeln.de> <19970923191710.61639@hydrogen.nike.efn.org> <19970924155302.35730@mi.uni-koeln.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.69 In-Reply-To: <19970924155302.35730@mi.uni-koeln.de>; from Stefan Esser on Wed, Sep 24, 1997 at 03:53:02PM +0200 Reply-To: John-Mark Gurney Organization: Cu Networking X-Operating-System: FreeBSD 2.2.1-RELEASE i386 X-PGP-Fingerprint: B7 EC EF F8 AE ED A7 31 96 7A 22 B3 D8 56 36 F4 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Stefan Esser scribbled this message on Sep 24: > On Sep 23, John-Mark Gurney wrote: > > > The code is finished, but I did not commit > > > it to -current, since I was waiting for the > > > new ISA device probe/attach code to become > > > available. > > > > oh... if your waiting for the work that I'm working on.. commit the > > changes now.. I don't think that I'll have anything workable in the > > next month... as next monday is the first day of classes, and I've been > > working this week... so I haven't made any progress yet... > > Well, as I wrote before, I do not intend to > commit that resource check code, since I do > no longer consider it the correct approach. > > I rather want to have a "generic" device > struct, which is common to all device types > (including, for example, SCSI drives), and > which offers a few pointers to methods, upper > data structures (i.e. driver and bus specific) > and device parameters. (Very much like the > Ethernet drivers do, BTW.) > > I'd expect to be able to call a bus-specific > function that allows me to check the resource > usage of a device. A function prototype might > be: > > res_check(gendev *dev, int res_type, int flags) > > This function could redirect the call through > a function pointer obtained from dev->xxx and > that function could for PCI support res_type > values of memory range, port range, IRQ set > and DRQ set. The SCSI code should provide a > function that checked the SCSI ID. The flags > parameter could be used to mark a registration > as "shared", or to allow to check for not yet > registered but prefered resources of some ISA > PnP card. > > The "extent" registration code from NetBSD is > quite generic, and could be used to register > the resource usage. But I prefer to query the > device data directly, instead of duplicating > the information in some generic data base. you haven't looked at the extent stuff from NetBSD... all it does is allows you to "mark" used portions of a number set (say [0,15] for IRQs) then you can quickly check to see if a resource is used... not who owns the resource... extent keeps no info on who owns a resource... just that a resource is used... > The device private data contains all the > information about the resource usage in a way > that allows to represent sparse data (like the > set of IRQs or DMA channels used). It is also yes.. it will... > easy to check for resources this device would > use, if it was attached. This may be of use in > code that plans address ranges for ISA PnP > devices that can be mapped to certain addresses. > > No need to register a resource, BTW. As soon as > the device struct is available to the probe code > (either as a DATA_SET or the isa_devtab_xxx array), > the device's data is available to the resource > check functions. Only the device state has to be > set (unused, attached, possibly intermediate > states). > > The test for resource usage would search through > the bus and device tree, but in many cases the > search of a subtree can be avoided (e.g. a PCI > to PCI bridge will claim all address ranges it > maps to the secondary side, and thus only devices > on a PCI bus directly connected to the CPU have > to be checked. This reduces the number of tests > that have to be performed in a system with lots > of devices. I do not expect the checking against > device private data to be much more inefficient > than a extent registry, and it is done at driver > probe/attach time only, anyway. yes.. but with the new dynamic loading code... the driver probe/attach will be done at any time.. plus.. the current implementation can have the conflicts to be double checked (i.e. it read the irq off the card and it didn't match the irq passed, so it puts in the new irq, tells it to reconfig the device)... plus.. how do you handle the finding of resources for a device?? say you need to memory map something in the 384k isa whole, want is aligned to some boundary, and don't want it to cross another boundary?? extent will handle this automaticly for you... > Other information in this generic device struct > should be a unit number and an up pointer to the > driver structure (again at least partially generic), > which among function pointers contains the driver > name. This would allow to build device names for > all devices in a uniform way, for example for the > reservation conflict message in res_check() ... :) this is one thing you couldn't do with extent is find who owns the resource... it would be nice.. you could do that once you've found that there is a conflict though... > I have put some effort in working out the details, > but those changes are of no big use, if they are > not applied to all device types (i.e. ISA/EISA/ > PCI-Buses, card drivers for these buses, SCSI > device drivers, SCSI device structures). > > > have you actually looked at the extent stuff from NetBSD?? you still > > have to write the wrappers around the extent to use the resources, it's > > just that it provides a way to do mapping of sections of units... > > Yes, sure. And I have a simple registration data > base in my kernel, which does just register the > resource usage. What I do not like about it is: > > 1) I have to register all resources at attach > time and to unregister them when the device > is shutdown. I'd rather flip just a single > bit in the device data structure, which has > to contain all the information anyway. > > 2) The extent code is "tagged on to the side", > and I'd rather just define the prototype of > the check function and let each bus driver > provide an implementation that complies with > the definition. umm... you do this.. it's just that the bus driver creates a private extent map for it's resources... extent doesn't do that much for you, it's just a set of functions that make writing the bus driver function all that much easier... > > > Well, ISA interrupts should be registered in > > > a way that guarantees they are not shared. > > > I agree.. but this should be on a bus dependant side... and with the > > new isa_device stuff I have invisioned.... we will be able to do more > > dynamic sharing of irqs... suchs as marking irqs as only used when > > device is active... so you can share irqs between devices... i.e. the > > common com1/com3 problem... > > But the code that makes ISA interrupts exclusive > is in a bus dependent function (at least I consider > the old register_intr() function to be ISA specific). > > All new code should only use intr_create(), which > creates an interrupt descriptor, and intr_connect() > and intr_disconnect() which (in)activates the handler > according to the information in that descriptor. > > (BTW: Connecting or disconnecting the handler does > not require a check for conflicts, since the function > that manages the shared interrupt handler chain does > check for conflicts whenever a handler is added.) hmm... I'll look at this code... > The new ISA code definitely should use that interface, > and no longer call register_intr() ... do you have any prototype structs of what you want things to look like.. one thing I'm lacking is experience with different bus designes... so making a truely generic structure is a bit more difficult for me... ttyl.. -- John-Mark Gurney Modem/FAX: +1 541 683 6954 Cu Networking Live in Peace, destroy Micro$oft, support free software, run FreeBSD From owner-freebsd-current Wed Sep 24 13:16:56 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id NAA23722 for current-outgoing; Wed, 24 Sep 1997 13:16:56 -0700 (PDT) Received: from pluto.plutotech.com (root@mail.plutotech.com [206.168.67.137]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id NAA23714 for ; Wed, 24 Sep 1997 13:16:48 -0700 (PDT) Received: from narnia.plutotech.com (narnia.plutotech.com [206.168.67.130]) by pluto.plutotech.com (8.8.5/8.8.5) with ESMTP id OAA08138; Wed, 24 Sep 1997 14:16:17 -0600 (MDT) Message-Id: <199709242016.OAA08138@pluto.plutotech.com> X-Mailer: exmh version 2.0zeta 7/24/97 To: Julian Elischer cc: "Justin T. Gibbs" , Nate Williams , Terry Lambert , bde@zeta.org.au, current@FreeBSD.ORG Subject: Re: new timeout routines In-reply-to: Your message of "Wed, 24 Sep 1997 11:59:24 PDT." <3429630C.167EB0E7@whistle.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 24 Sep 1997 14:16:05 -0600 From: "Justin T. Gibbs" Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >> The cookie is essentially a direct pointer to the entry that needs to >> be removed. So, removal takes constant time. In your scheme, you need >> to allocate an additional hash table and add a set of links to each >> callout entry so it can live both in the callwheel and in the hash >> table. Then, in untimeout, you must traverse a hash chain of indeterminate >> length in order to find the entry, hence it is no longer a constant time >> operation. This wouldn't be a problem if untimeout wasn't called from >> interrupt contexts, but it is. >> >so what happens if I call untimeout twice? Absolutely nothing. >there is an assumption in a lot of code that untimeout is idempotent >(did I get that right?). It can be called whenever you are recovering >from unknown situations with the sure knowledge that the appropriate >timeout will be removed. And it will. >1/ there is no way to do this without lots of work now. Not true. Read the code and the man page. >2/ old code will break. Nope. >do you check for a NULL pointer? (I have read the paper but not the code >(yet) You should read the code. 8-) -- Justin T. Gibbs =========================================== FreeBSD: Turning PCs into workstations =========================================== From owner-freebsd-current Wed Sep 24 13:29:02 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id NAA24752 for current-outgoing; Wed, 24 Sep 1997 13:29:02 -0700 (PDT) Received: from pluto.plutotech.com (root@mail.plutotech.com [206.168.67.137]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id NAA24672 for ; Wed, 24 Sep 1997 13:27:39 -0700 (PDT) Received: from narnia.plutotech.com (narnia.plutotech.com [206.168.67.130]) by pluto.plutotech.com (8.8.5/8.8.5) with ESMTP id OAA08517; Wed, 24 Sep 1997 14:27:35 -0600 (MDT) Message-Id: <199709242027.OAA08517@pluto.plutotech.com> X-Mailer: exmh version 2.0zeta 7/24/97 To: Nate Williams cc: "Justin T. Gibbs" , current@FreeBSD.ORG Subject: Re: new timeout routines In-reply-to: Your message of "Wed, 24 Sep 1997 11:19:00 MDT." <199709241719.LAA12880@rocky.mt.sri.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 24 Sep 1997 14:27:23 -0600 From: "Justin T. Gibbs" Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >> It took the first entry off the list. The NetBSD timeout.9 page lists >> this as a bug. > >So, the old behavior (that we've all grown to love now that it's >gone. :) was used for this many years, yet was full of bugs? It could be argued that client code that scheduled multiple timeouts with the same function and argument pointer had the bug in it, but, yes, this "bug" has existed for a long time. >Do hash >collisions not ever occur 'in the current pre-CAM system'? There were one or two of the clients that didn't have proper protection from scheduling the same timeout more than once by mistake, but I fixed that when I put in the new callout interface. The case where you usually see this problem is a driver that schedules a timeout everytime condition X occurs, but it is only required that the timeout expire once even if X occurs multiple times before the timeout expires. So long as untimeouts aren't involved, the only problem with this is that you can consume all the timeouts in the system. If you want to untimeout the event, well, you would lose. Of course this really isn't a "hash collision" as the old untimeout simply traversed the list matching the func and arg pointers to every entry until it found one or the list was exausted. >Nate -- Justin T. Gibbs =========================================== FreeBSD: Turning PCs into workstations =========================================== From owner-freebsd-current Wed Sep 24 14:23:30 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id OAA28412 for current-outgoing; Wed, 24 Sep 1997 14:23:30 -0700 (PDT) Received: from Octopussy.MI.Uni-Koeln.DE (Octopussy.MI.Uni-Koeln.DE [134.95.166.20]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id OAA28401; Wed, 24 Sep 1997 14:23:18 -0700 (PDT) Received: from x14.mi.uni-koeln.de ([134.95.219.124]) by Octopussy.MI.Uni-Koeln.DE with SMTP id AA23089 (5.67b/IDA-1.5); Wed, 24 Sep 1997 23:23:08 +0200 Received: (from se@localhost) by x14.mi.uni-koeln.de (8.8.7/8.6.9) id XAA00666; Wed, 24 Sep 1997 23:11:30 +0200 (CEST) X-Face: " Date: Wed, 24 Sep 1997 23:11:29 +0200 From: Stefan Esser To: John-Mark Gurney Cc: Nate Williams , mobile@FreeBSD.ORG, current@FreeBSD.ORG, Stefan Esser Subject: Re: PCCARD in -current broken References: <199709231929.NAA08312@rocky.mt.sri.com> <19970923230018.00034@mi.uni-koeln.de> <19970923191710.61639@hydrogen.nike.efn.org> <19970924155302.35730@mi.uni-koeln.de> <19970924124106.61317@hydrogen.nike.efn.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.74 In-Reply-To: <19970924124106.61317@hydrogen.nike.efn.org>; from John-Mark Gurney on Wed, Sep 24, 1997 at 12:41:06PM -0700 Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Sep 24, John-Mark Gurney wrote: > > The "extent" registration code from NetBSD is > > quite generic, and could be used to register > > the resource usage. But I prefer to query the > > device data directly, instead of duplicating > > the information in some generic data base. > > you haven't looked at the extent stuff from NetBSD... all it does is Sure did I look at that code! It has been a few months ago, though. > allows you to "mark" used portions of a number set (say [0,15] for IRQs) > then you can quickly check to see if a resource is used... not who > owns the resource... extent keeps no info on who owns a resource... > just that a resource is used... Yes, I know this. It couldn't coalesce ranges, else. It offers faster lookup for a conflict, but I want to know what's causing a conflict, and for that reason I do not want to have resources registered anonymously. And before duplicating the information present in the driver in some registry, I prefer to directly use the information present in the driver private data. As I said before, the extent registration code allows for a faster check for a collision, but I'd rather be which driver conflicts with another one. Since the check will be performed at device attach time only, this should not cause problems. > yes.. but with the new dynamic loading code... the driver probe/attach > will be done at any time.. plus.. the current implementation can have > the conflicts to be double checked (i.e. it read the irq off the card > and it didn't match the irq passed, so it puts in the new irq, tells > it to reconfig the device)... plus.. how do you handle the finding of > resources for a device?? say you need to memory map something in the > 384k isa whole, want is aligned to some boundary, and don't want it to > cross another boundary?? extent will handle this automaticly for you... If a device has certain restrictions for addresses or other parameters, then the attach code should know about them. I agree, that the extent code simplifies finding a suitable address range in such a case. I was more interested in avoiding conflicts, and I'm willing to make the scan for an address region check all supported ranges against all registered devices. (Most ISA devices support only a very limited set of addresses, not as regular as you suggest above. The restrictions need not be (alignment, boundary to avoid), but often are some discrete tuples of values. IMHO, PnP ISA cards will actually be configured by the BIOS, if present. Else I expect a user land program to exist, which is able to query and calculate parameters to use for that card. The results should be stored in "boot.config" in text form. > > Other information in this generic device struct > > should be a unit number and an up pointer to the > > driver structure (again at least partially generic), > > which among function pointers contains the driver > > name. This would allow to build device names for > > all devices in a uniform way, for example for the > > reservation conflict message in res_check() ... :) > > this is one thing you couldn't do with extent is find who owns the > resource... it would be nice.. you could do that once you've found > that there is a conflict though... Hmmm, seems we approach these questions from quite opposite directions: You assume there is an extent registry, and see that per device resource checking could help identify the conflicting parties. I start with a desire to identify conflicting parties, if there are any, and think this is sufficient also if some address (or IRQ) has to be choosen to not conflict. (It may take several iterations, until a value is tried, that does not conflict, but I think this will take at most a few milliseconds per device that is attached and needs to find some non-conflicting value.) > umm... you do this.. it's just that the bus driver creates a private > extent map for it's resources... extent doesn't do that much for you, > it's just a set of functions that make writing the bus driver function > all that much easier... Well, in case of the PCI code, the PCI to PCI bridge provides "windows" from the primary to the secondary side. In a way, this is like an extent registration for the devices behind the bridge, but in fact, the windows are much more "real": They are stored in the "base" and "limit" registers of the bridge chip, and make the bridge appear as a device that decodes those addresses on the primary bus. A generic set of extent registration functions does not help here at all. And I doubt it does in other situations. Do you have "real" examples to the contrary ? > > The new ISA code definitely should use that interface, > > and no longer call register_intr() ... > > do you have any prototype structs of what you want things to look like.. > one thing I'm lacking is experience with different bus designes... so > making a truely generic structure is a bit more difficult for me... Well, I have a lot of details on paper, and I could start typing it in. I started looking at a device: - it is an instance with private variables - it is controlled by a driver, which has its own set of methods - it is attached in a bus specific way, the bus may be considered to be a "class" A bus may be considered as a device, which controls dependent devices. I'll need some time to find my notes about this, since they are in a big pile of papers and data books, about one meter in height :) One of my concerns was to find data structures, that are space efficient. I could make the PCI code use such structures, but as long as there is no support in the code for other buses, it doesn't provide any actual advantage. I'll forward an article I posted to the -current list in May to you in a seperate message. It is not what I ended with, though, but I do not have anything else in electronic form, right now ... Regards, STefan From owner-freebsd-current Wed Sep 24 14:36:41 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id OAA29407 for current-outgoing; Wed, 24 Sep 1997 14:36:41 -0700 (PDT) Received: from whistle.com (s205m131.whistle.com [207.76.205.131]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id OAA29398 for ; Wed, 24 Sep 1997 14:36:38 -0700 (PDT) Received: (from smap@localhost) by whistle.com (8.7.5/8.6.12) id OAA00961; Wed, 24 Sep 1997 14:36:07 -0700 (PDT) Received: from bubba.whistle.com(207.76.205.7) by whistle.com via smap (V1.3) id sma000957; Wed Sep 24 14:35:52 1997 Received: (from archie@localhost) by bubba.whistle.com (8.8.5/8.6.12) id OAA11785; Wed, 24 Sep 1997 14:35:51 -0700 (PDT) From: Archie Cobbs Message-Id: <199709242135.OAA11785@bubba.whistle.com> Subject: Re: timeout management (was: Re: cvs commit: ...) In-Reply-To: <19970924025515.60364@hydrogen.nike.efn.org> from John-Mark Gurney at "Sep 24, 97 02:55:15 am" To: gurney_j@resnet.uoregon.edu Date: Wed, 24 Sep 1997 14:35:51 -0700 (PDT) Cc: current@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL31 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > well... I proposed that we used a fibonacci heap as a solution to this > problem... the fibonacci heap will do: > FUNCTION TIMING (amortized) > add new timeout O(1) > check for timeout O(1) > expire x timeouts O(x lg n) for n = number of timeouts > remove a timeout O(lg n) for n = number of timeouts > > now, you have to take into account that this is amortized time... so > at points in time, they may take longer.. but all the major work is > actually done when you remove a timeout... Another algorithm that Julian and I discussed the other day has these properties: FUNCTION TIMING (amortized) add new timeout O(1) check for timeout O(1) remove a timeout O(1) (requires a handle) process one timeout O(lg T) for T = number of ticks alive That is, if a timeout event lives for T ticks (whether it's cancelled or expires after T ticks), it requires O(lg T) total work. Therefore, any event that is cancelled before 1/2 of it's timeout period has expired only requires O(1) work. The disadvantage is that you can do a lot of work duiring a single tick: O(N), where N is the number of timeout events still alive in the queue after 1/2 of their timeout periods. So if 99% of timeouts expire within the first half of their timeout period, then this algorithm is "optimal". The larger point is that given some assumption about what kind of behavior to expect, and what restrictions are required, you can design the "best" algorithm for those conditions. I agree with Julian's original point that we should have more than one timeout() function -- one for each "type" of timeout, e.g. the "high probability of being cancelled quickly" timeout() for disk errors, the "medium probability of timing but low granularity" for TCP retransmissions, etc... Some parameters are: - Are their lots of timeouts expected or just a few? - What is the probability distribution of the cancellation time as a percentage of total time (e.g., how far along the timeout period is an event likely to be cancelled?) Here 100% means the timeout event occurred. - What is sufficient granularity for the timeout? I'd be interested to see a catalog of all the clients of timeout() in the code, and what they look like in terms of the above questions. -Archie ___________________________________________________________________________ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com From owner-freebsd-current Wed Sep 24 15:12:03 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id PAA01985 for current-outgoing; Wed, 24 Sep 1997 15:12:03 -0700 (PDT) Received: from usr03.primenet.com (tlambert@usr03.primenet.com [206.165.6.203]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id PAA01950 for ; Wed, 24 Sep 1997 15:11:58 -0700 (PDT) Received: (from tlambert@localhost) by usr03.primenet.com (8.8.5/8.8.5) id PAA17346; Wed, 24 Sep 1997 15:11:22 -0700 (MST) From: Terry Lambert Message-Id: <199709242211.PAA17346@usr03.primenet.com> Subject: Re: Yet Another bug in src/Makefile To: asami@cs.berkeley.edu (Satoshi Asami) Date: Wed, 24 Sep 1997 22:11:21 +0000 (GMT) Cc: tlambert@primenet.com, gurney_j@resnet.uoregon.edu, dima@tejblum.dnttm.rssi.ru, freebsd-current@freebsd.org In-Reply-To: <199709240934.CAA10986@silvia.HIP.Berkeley.EDU> from "Satoshi Asami" at Sep 24, 97 02:34:08 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > * I sure as hell do not want to rebuild "more", or even do a make install > * in /usr/src/include. I want to buildd the *absolute* minimum for the > * delta I am playing with -- and not *one file* more or less than that. > > I suggest you go read the new src/Makefile. Nothing is built by > installing stuff in /usr/src/include anymore. I should probably clarify: I want to rebuild things which depend on the headers which were touchesd in the source tree, not the headers that were touched by the install. Short of checking the headers out from the source tree to the installed location, the dates are munged. > There is no target to do exactly what you want, but it is very easy to > add a target that will build any subset you want and put it in a > separate subdirectory tree as this is essentially what's done in the > first few steps of "buildworld". This is close, but not quite. I'm most interested in /usr/include/sys and similar header changes, obviously. The current build stuff is not quite there without a duplication of certain parts of the source tree. Ideally, I'd be able to run a tail-chasing build, where after I build something, install it, and recover the space needed to build it; further, I would only do this for things which were impacted by changes I found interesting -- for me, the kernel. Having a copy of the proposed post-install include directory doesn't really cut it. > That's what DESTDIR is for. The framework was already mostly there, > we only needed to fix some little stuff other than the big patch to > src/Makefile. Well, I think the problem is probably the assumption that the system component include directories are the same as the non-system component (ports, user programs) include directories. Machine is one big problem that I don't see being fixed by anything short of an architecturally specific symbolic link (so one can be i386, another can be ppc6xx, another alpha, and so on) witout it needing to be varient. Anything less, and I must either conduct builds sequentially instead of concurrently, or allocate more disk space than I want to the task. 8-(. Don't feel bad; USL is all buggered up in this department, too; so is Sun and just about everyone else. Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-current Wed Sep 24 15:28:17 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id PAA03105 for current-outgoing; Wed, 24 Sep 1997 15:28:17 -0700 (PDT) Received: from whistle.com (s205m131.whistle.com [207.76.205.131]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id PAA03100 for ; Wed, 24 Sep 1997 15:28:10 -0700 (PDT) Received: (from smap@localhost) by whistle.com (8.7.5/8.6.12) id PAA01427; Wed, 24 Sep 1997 15:27:08 -0700 (PDT) Received: from bubba.whistle.com(207.76.205.7) by whistle.com via smap (V1.3) id sma001425; Wed Sep 24 15:27:07 1997 Received: (from archie@localhost) by bubba.whistle.com (8.8.5/8.6.12) id PAA17373; Wed, 24 Sep 1997 15:27:07 -0700 (PDT) From: Archie Cobbs Message-Id: <199709242227.PAA17373@bubba.whistle.com> Subject: Re: timeout management (was: Re: cvs commit: ...) In-Reply-To: <199709242135.OAA11785@bubba.whistle.com> from Archie Cobbs at "Sep 24, 97 02:35:51 pm" To: current@FreeBSD.ORG Date: Wed, 24 Sep 1997 15:27:07 -0700 (PDT) Cc: gurney_j@resnet.uoregon.edu X-Mailer: ELM [version 2.4ME+ PL31 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk I wrote: > > Another algorithm that Julian and I discussed the other day has > these properties: > > FUNCTION TIMING (amortized) > add new timeout O(1) > check for timeout O(1) > remove a timeout O(1) (requires a handle) > process one timeout O(lg T) for T = number of ticks alive > > That is, if a timeout event lives for T ticks (whether it's cancelled > or expires after T ticks), it requires O(lg T) total work. > > Therefore, any event that is cancelled before 1/2 of it's timeout > period has expired only requires O(1) work. Oops.. what I meant was that if a timeout event was scheduled for T ticks, and it lives for R ticks, then the amount of work spent on the event is O( lg T ) if R == T, else O( lg T - lg (T - R) ) (which makes that last sentence true again :-). -Archie ___________________________________________________________________________ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com From owner-freebsd-current Wed Sep 24 16:03:22 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id QAA05304 for current-outgoing; Wed, 24 Sep 1997 16:03:22 -0700 (PDT) Received: from usr03.primenet.com (tlambert@usr03.primenet.com [206.165.6.203]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id QAA05281 for ; Wed, 24 Sep 1997 16:03:13 -0700 (PDT) Received: (from tlambert@localhost) by usr03.primenet.com (8.8.5/8.8.5) id QAA22758; Wed, 24 Sep 1997 16:03:01 -0700 (MST) From: Terry Lambert Message-Id: <199709242303.QAA22758@usr03.primenet.com> Subject: Re: new timeout routines To: julian@whistle.com (Julian Elischer) Date: Wed, 24 Sep 1997 23:02:59 +0000 (GMT) Cc: gibbs@plutotech.com, nate@mt.sri.com, tlambert@primenet.com, bde@zeta.org.au, current@FreeBSD.ORG In-Reply-To: <3429630C.167EB0E7@whistle.com> from "Julian Elischer" at Sep 24, 97 11:59:24 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > there is an assumption in a lot of code that untimeout is idempotent > (did I get that right?). It can be called whenever you are recovering > from unknown situations with the sure knowledge that the appropriate > timeout will be removed. This is kind of a bad assumption; it assumes no kernel preemption. It also probably means that the timeout is being scheduled way earlier than it should be in the code (before parameter checks, etc.). > 1/ there is no way to do this without lots of work now. > 2/ old code will break. The new code is actually expecting to be called reflexively. This is not a bad thing. All the lock code works this way (for example). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-current Wed Sep 24 17:13:24 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id RAA09733 for current-outgoing; Wed, 24 Sep 1997 17:13:24 -0700 (PDT) Received: from usr03.primenet.com (tlambert@usr03.primenet.com [206.165.6.203]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id RAA09712; Wed, 24 Sep 1997 17:13:08 -0700 (PDT) Received: (from tlambert@localhost) by usr03.primenet.com (8.8.5/8.8.5) id RAA01816; Wed, 24 Sep 1997 17:13:01 -0700 (MST) From: Terry Lambert Message-Id: <199709250013.RAA01816@usr03.primenet.com> Subject: Re: New timeout capability (was Re: cvs commit:....) To: se@FreeBSD.ORG (Stefan Esser) Date: Thu, 25 Sep 1997 00:13:00 +0000 (GMT) Cc: tlambert@primenet.com, dyson@FreeBSD.ORG, syssgm@dtir.qld.gov.au, freebsd-current@FreeBSD.ORG In-Reply-To: <19970924160022.50021@mi.uni-koeln.de> from "Stefan Esser" at Sep 24, 97 04:00:22 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > > I think that 4K performs pretty darned well anyway though. In the > > > real world, I wouldn't think that one would see much of a performance > > > difference between 4K and 16K. > > > > For 8k, there used to be about a 40% improvement over 4k for iozone; I > > haven't really tried this for about 5 moths now, though. > > Hmmm, did you measure accesses to the > char device, block device, or a file ??? What? Huh? File... nothing else makes sense considering it's an FS blcok size, and the other two aren't FS-based accesses. 8-). > I'd be very surprised, if your IOZONE > results were different by 40% for file > accesses (were clustering helps). Well, they were. Like I said, it was about 5 months ago. I have the results squirrelled away somewhere, and could find them if I absolutely had to (it would probably take using my tap drive, though 8-(). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-current Wed Sep 24 17:14:02 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id RAA09775 for current-outgoing; Wed, 24 Sep 1997 17:14:02 -0700 (PDT) Received: from usr03.primenet.com (tlambert@usr03.primenet.com [206.165.6.203]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id RAA09770 for ; Wed, 24 Sep 1997 17:14:00 -0700 (PDT) Received: (from tlambert@localhost) by usr03.primenet.com (8.8.5/8.8.5) id RAA01429; Wed, 24 Sep 1997 17:10:56 -0700 (MST) From: Terry Lambert Message-Id: <199709250010.RAA01429@usr03.primenet.com> Subject: Re: Daily SNAPshots at current.freebsd.org shut down for now. To: kato@migmatite.eps.nagoya-u.ac.jp (KATO Takenori) Date: Thu, 25 Sep 1997 00:10:55 +0000 (GMT) Cc: phk@critter.freebsd.dk, current@FreeBSD.ORG In-Reply-To: <199709241017.TAA01768@gneiss.eps.nagoya-u.ac.jp> from "KATO Takenori" at Sep 24, 97 07:17:40 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > disable clustering on a per filesystem or mount point basis and disallow > > it for vn devices. If you think about it, it doesn't make sense in the > > first place. > > How about following following patch? [ ... ] [ ... ] > ! else if (doclusterread && !(vp->v_flag & VNOCLUSTER)) Poul's right... this needs to be per FS type instead (and maybe a mount option, like he suggested, though it shouldn't be allowed to override "on", and "off" is only marginally useful at best. I would think you'd be able to roll it into per fs "doclusterread" and "doclusterwrite" and save the extra comparisons, for the most part, as well. It *does* look like this is the right way out of the kludge, however. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-current Wed Sep 24 17:17:46 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id RAA10052 for current-outgoing; Wed, 24 Sep 1997 17:17:46 -0700 (PDT) Received: from usr03.primenet.com (tlambert@usr03.primenet.com [206.165.6.203]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id RAA10047 for ; Wed, 24 Sep 1997 17:17:45 -0700 (PDT) Received: (from tlambert@localhost) by usr03.primenet.com (8.8.5/8.8.5) id RAA02618; Wed, 24 Sep 1997 17:17:28 -0700 (MST) From: Terry Lambert Message-Id: <199709250017.RAA02618@usr03.primenet.com> Subject: Re: new timeout routines To: nate@mt.sri.com (Nate Williams) Date: Thu, 25 Sep 1997 00:17:27 +0000 (GMT) Cc: tlambert@primenet.com, nate@mt.sri.com, julian@whistle.com, gibbs@plutotech.com, bde@zeta.org.au, current@freebsd.org In-Reply-To: <199709241523.JAA12165@rocky.mt.sri.com> from "Nate Williams" at Sep 24, 97 09:23:14 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > Untimeout this particular timeout without traversing the whole list > > of possible timeouts. > > Build a hash list that uses the (fn, args) parameter at timeout time > (which is what the result of the cookie is), and then get to the timeout > via hashing back on this with untimeout(fn, args). No need for the > drivers to hold onto the cookie, since you have all the necessary > information. Which bucket is an 8 tick timeout in? It's going to be in the current bucket or any one of the 7 following it, depending on how many sofclocks have happenend since the queue. That's still potentially a lot of entries to look at. Besides, O(1) removal has merit independent of the other arguments; I'd want a cookie if I was doing something where I expected it to be removed (like writing a CAM layer 8-)). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-current Wed Sep 24 17:22:05 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id RAA10319 for current-outgoing; Wed, 24 Sep 1997 17:22:05 -0700 (PDT) Received: from usr03.primenet.com (tlambert@usr03.primenet.com [206.165.6.203]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id RAA10314 for ; Wed, 24 Sep 1997 17:22:00 -0700 (PDT) Received: (from tlambert@localhost) by usr03.primenet.com (8.8.5/8.8.5) id RAA03046; Wed, 24 Sep 1997 17:21:56 -0700 (MST) From: Terry Lambert Message-Id: <199709250021.RAA03046@usr03.primenet.com> Subject: Re: new timeout routines To: nate@mt.sri.com (Nate Williams) Date: Thu, 25 Sep 1997 00:21:55 +0000 (GMT) Cc: gibbs@plutotech.com, nate@mt.sri.com, current@FreeBSD.ORG In-Reply-To: <199709241713.LAA12839@rocky.mt.sri.com> from "Nate Williams" at Sep 24, 97 11:13:27 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > So you assume that regardless of what pointers the client gives you, > > even if they give you the same pair twice without an intervening > > expiration or untimeout call, that there will be no collisions in > > the hash table? > > How did the original code in untimeout() determine what to pull off the > table? Obviously there is enough information in the untimeout() call to > uniquely determine which entry to use, and that same information was > used in timeout(), so we must be able to build a perfect hash function. A given process can only block on one timeout address at a time; as long as it has a pointer to the curproc, it can traverse the entire list looking for the curproc and be sure that that's the one. It can do the same thing (and not fail) in the case of multiple calls. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-current Wed Sep 24 17:24:22 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id RAA10459 for current-outgoing; Wed, 24 Sep 1997 17:24:22 -0700 (PDT) Received: from usr03.primenet.com (tlambert@usr03.primenet.com [206.165.6.203]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id RAA10454 for ; Wed, 24 Sep 1997 17:24:16 -0700 (PDT) Received: (from tlambert@localhost) by usr03.primenet.com (8.8.5/8.8.5) id RAA03253; Wed, 24 Sep 1997 17:24:09 -0700 (MST) From: Terry Lambert Message-Id: <199709250024.RAA03253@usr03.primenet.com> Subject: Re: new timeout routines To: gibbs@plutotech.com (Justin T. Gibbs) Date: Thu, 25 Sep 1997 00:24:08 +0000 (GMT) Cc: nate@mt.sri.com, gibbs@plutotech.com, current@FreeBSD.ORG In-Reply-To: <199709241716.LAA24576@pluto.plutotech.com> from "Justin T. Gibbs" at Sep 24, 97 11:16:15 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > >> So you assume that regardless of what pointers the client gives you, > >> even if they give you the same pair twice without an intervening > >> expiration or untimeout call, that there will be no collisions in > >> the hash table? > > > >How did the original code in untimeout() determine what to pull off the > >table? Obviously there is enough information in the untimeout() call to > >uniquely determine which entry to use, and that same information was > >used in timeout(), so we must be able to build a perfect hash function. > > It took the first entry off the list. The NetBSD timeout.9 page lists > this as a bug. The "cure" is worse than the disease, in this case; see my other posting on looking for your curproc. In reality, in the NetBSD code it's not a bug, as long as the interface is called reflexively. This is because there is no kernel preemption to cause it to interleave requests. Requests run either to completion or to blocking. If they block, they are not removed. If they do not block, then they are the head entry. No problems. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-current Wed Sep 24 18:19:33 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id SAA13587 for current-outgoing; Wed, 24 Sep 1997 18:19:33 -0700 (PDT) Received: from hydrogen.nike.efn.org (resnet.uoregon.edu [128.223.170.28]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id SAA13580 for ; Wed, 24 Sep 1997 18:19:29 -0700 (PDT) Received: (from jmg@localhost) by hydrogen.nike.efn.org (8.8.7/8.8.7) id SAA10247; Wed, 24 Sep 1997 18:19:23 -0700 (PDT) Message-ID: <19970924181922.06828@hydrogen.nike.efn.org> Date: Wed, 24 Sep 1997 18:19:22 -0700 From: John-Mark Gurney To: Archie Cobbs Cc: current@FreeBSD.ORG Subject: Re: timeout management (was: Re: cvs commit: ...) References: <19970924025515.60364@hydrogen.nike.efn.org> <199709242135.OAA11785@bubba.whistle.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.69 In-Reply-To: <199709242135.OAA11785@bubba.whistle.com>; from Archie Cobbs on Wed, Sep 24, 1997 at 02:35:51PM -0700 Reply-To: John-Mark Gurney Organization: Cu Networking X-Operating-System: FreeBSD 2.2.1-RELEASE i386 X-PGP-Fingerprint: B7 EC EF F8 AE ED A7 31 96 7A 22 B3 D8 56 36 F4 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Archie Cobbs scribbled this message on Sep 24: > > > well... I proposed that we used a fibonacci heap as a solution to this > > problem... the fibonacci heap will do: > > FUNCTION TIMING (amortized) > > add new timeout O(1) > > check for timeout O(1) > > expire x timeouts O(x lg n) for n = number of timeouts > > remove a timeout O(lg n) for n = number of timeouts > > > > now, you have to take into account that this is amortized time... so > > at points in time, they may take longer.. but all the major work is > > actually done when you remove a timeout... > > Another algorithm that Julian and I discussed the other day has > these properties: > > FUNCTION TIMING (amortized) > add new timeout O(1) > check for timeout O(1) > remove a timeout O(1) (requires a handle) > process one timeout O(lg T) for T = number of ticks alive > > That is, if a timeout event lives for T ticks (whether it's cancelled > or expires after T ticks), it requires O(lg T) total work. > > Therefore, any event that is cancelled before 1/2 of it's timeout > period has expired only requires O(1) work. > > The disadvantage is that you can do a lot of work duiring a single > tick: O(N), where N is the number of timeout events still alive > in the queue after 1/2 of their timeout periods. so, do you still have to do some work after each tick?? or were does this come into play?? > So if 99% of timeouts expire within the first half of their timeout > period, then this algorithm is "optimal". hmm.. if you have something typed up about the design of this algo, could you send it to me in private mail... > The larger point is that given some assumption about what kind of > behavior to expect, and what restrictions are required, you can > design the "best" algorithm for those conditions. I agree with > Julian's original point that we should have more than one timeout() > function -- one for each "type" of timeout, e.g. the "high probability > of being cancelled quickly" timeout() for disk errors, the "medium > probability of timing but low granularity" for TCP retransmissions, > etc... I agree... it makes the different algorithms do what they were designed to do... I was quite surprised when I looked at my Fibonacci heap code and noticed that the current compiled object is only 2688 bytes large.. and this includes the new freelist code which drops 100,000/10 from 2.35 down to 1.9.. so about a 1/5th improvement.. it wasn't as much as I had hopped though... > Some parameters are: > > - Are their lots of timeouts expected or just a few? > > - What is the probability distribution of the cancellation > time as a percentage of total time (e.g., how far along > the timeout period is an event likely to be cancelled?) > Here 100% means the timeout event occurred. > > - What is sufficient granularity for the timeout? > > I'd be interested to see a catalog of all the clients of timeout() in > the code, and what they look like in terms of the above questions. this is the true way to do it... I only proposed fibonacci heaps as a solution because I knew that they had good amortized times, and eliminated most of the work from softclock... of course this doesn't allow you from doing interesting things like keeping long term timeouts in a seperate queue.. then merge that queue when the time comes (by scheduling a callback for that event :) )... this is very possible because fibonacci heaps can be combined in O(1)... -- John-Mark Gurney Modem/FAX: +1 541 683 6954 Cu Networking Live in Peace, destroy Micro$oft, support free software, run FreeBSD From owner-freebsd-current Wed Sep 24 19:23:04 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id TAA17117 for current-outgoing; Wed, 24 Sep 1997 19:23:04 -0700 (PDT) Received: from ns.mt.sri.com (SRI-56K-FR.mt.net [206.127.65.42]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id TAA17109 for ; Wed, 24 Sep 1997 19:22:57 -0700 (PDT) Received: from rocky.mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.8.7/8.8.7) with ESMTP id UAA05484; Wed, 24 Sep 1997 20:22:27 -0600 (MDT) Received: (from nate@localhost) by rocky.mt.sri.com (8.7.5/8.7.3) id UAA16284; Wed, 24 Sep 1997 20:22:22 -0600 (MDT) Date: Wed, 24 Sep 1997 20:22:22 -0600 (MDT) Message-Id: <199709250222.UAA16284@rocky.mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Terry Lambert Cc: nate@mt.sri.com (Nate Williams), julian@whistle.com, gibbs@plutotech.com, bde@zeta.org.au, current@freebsd.org Subject: Re: new timeout routines In-Reply-To: <199709250017.RAA02618@usr03.primenet.com> References: <199709241523.JAA12165@rocky.mt.sri.com> <199709250017.RAA02618@usr03.primenet.com> X-Mailer: VM 6.29 under 19.15 XEmacs Lucid Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > > Untimeout this particular timeout without traversing the whole list > > > of possible timeouts. > > > > Build a hash list that uses the (fn, args) parameter at timeout time > > (which is what the result of the cookie is), and then get to the timeout > > via hashing back on this with untimeout(fn, args). No need for the > > drivers to hold onto the cookie, since you have all the necessary > > information. > > Which bucket is an 8 tick timeout in? It's going to be in the current > bucket or any one of the 7 following it, depending on how many sofclocks > have happenend since the queue. We're not hashing on the tick, we're hashing on the function/arguements. The result of the hash gives us a pointer to the exact element. Nate From owner-freebsd-current Wed Sep 24 19:30:31 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id TAA17570 for current-outgoing; Wed, 24 Sep 1997 19:30:31 -0700 (PDT) Received: from whistle.com (s205m131.whistle.com [207.76.205.131]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id TAA17565 for ; Wed, 24 Sep 1997 19:30:29 -0700 (PDT) Received: (from smap@localhost) by whistle.com (8.7.5/8.6.12) id TAA03145; Wed, 24 Sep 1997 19:29:58 -0700 (PDT) Received: from bubba.whistle.com(207.76.205.7) by whistle.com via smap (V1.3) id sma003143; Wed Sep 24 19:29:54 1997 Received: (from archie@localhost) by bubba.whistle.com (8.8.5/8.6.12) id TAA16784; Wed, 24 Sep 1997 19:29:54 -0700 (PDT) From: Archie Cobbs Message-Id: <199709250229.TAA16784@bubba.whistle.com> Subject: Re: timeout management (was: Re: cvs commit: ...) In-Reply-To: <19970924181922.06828@hydrogen.nike.efn.org> from John-Mark Gurney at "Sep 24, 97 06:19:22 pm" To: gurney_j@resnet.uoregon.edu Date: Wed, 24 Sep 1997 19:29:53 -0700 (PDT) Cc: current@freebsd.org X-Mailer: ELM [version 2.4ME+ PL31 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > > well... I proposed that we used a fibonacci heap as a solution to this > > > problem... the fibonacci heap will do: > > > FUNCTION TIMING (amortized) > > > add new timeout O(1) > > > check for timeout O(1) > > > expire x timeouts O(x lg n) for n = number of timeouts > > > remove a timeout O(lg n) for n = number of timeouts > > > > > > now, you have to take into account that this is amortized time... so > > > at points in time, they may take longer.. but all the major work is > > > actually done when you remove a timeout... > > > > Another algorithm that Julian and I discussed the other day has > > these properties: > > > > FUNCTION TIMING (amortized) > > add new timeout O(1) > > check for timeout O(1) > > remove a timeout O(1) (requires a handle) > > process one timeout O(lg T) for T = number of ticks alive > > > > That is, if a timeout event lives for T ticks (whether it's cancelled > > or expires after T ticks), it requires O(lg T) total work. > > > > Therefore, any event that is cancelled before 1/2 of it's timeout > > period has expired only requires O(1) work. > > > > The disadvantage is that you can do a lot of work duiring a single > > tick: O(N), where N is the number of timeout events still alive > > in the queue after 1/2 of their timeout periods. > > so, do you still have to do some work after each tick?? or were does this > come into play?? Yes.. each tick you do up to O(N) work (N defined as above). > > So if 99% of timeouts expire within the first half of their timeout > > period, then this algorithm is "optimal". > > hmm.. if you have something typed up about the design of this algo, > could you send it to me in private mail... I don't, but here's the general idea: for every range of ticks of the form 2^n .. 2^(n+1) - 1 you split the range into two halves and create a doubly linked list ("box") for each half. This is the situation at t=0. The two halves are 2^n .. 2^n + 2^(n-1) - 1 2^n + 2^(n-1) .. 2^(n+1) - 1. When any event is scheduled, you put it in the linked list corrsponding to the range into which it's timeout value falls. Now here's where it starts getting complicated... As ticks go by, the 2^n .. 2^n + 2^(n-1) - 1 box shifts "left", that is, it becomes the 2^n - 1 .. 2^n + 2^(n-1) - 2 box, and similarly the 2^n + 2^(n-1) .. 2^(n+1) - 1 box becomes the 2^n + 2^(n-1) - 1 .. 2^(n+1) - 2 box. When the left edge of the first box (ie, 2^n .. 2^n + 2^(n-1) - 1) reaches 2^(n-1) + 2^(n-2), it's time to "rotate". Take this box and put it aside. Nothing in it will expire for another 2^(n-1) ticks at least. Replace it with two new empty boxes of half the size. 2^(n-1) ticks later (or now, if referring to the same box 2^(n-1) ago), it's time to deal with this box we put aside because the 2^(n-1) has now gone to zero. So take everything left in the box and reinsert it into the structure based on it's new, updated, now-at-most-half-as-big-as-it-originally-was timeout value. Rinse & repeat. At time t=X, you are rotating the boxes corresponding to the bit transitions of X. Now you can see that sometimes lots of boxes will rotate at the same time, requiring a lot of work on a single tick. But if you look at any single element with original expiry T, it gets reinserted at most lg T times.. So maybe you could do the "rotation" at a lower priority. -Archie ___________________________________________________________________________ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com From owner-freebsd-current Wed Sep 24 20:40:46 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id UAA21503 for current-outgoing; Wed, 24 Sep 1997 20:40:46 -0700 (PDT) Received: from lucifer.guardian.no (gate.guardian.no [195.1.254.2]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id UAA21498 for ; Wed, 24 Sep 1997 20:40:42 -0700 (PDT) Received: (qmail 28959 invoked by uid 21574); 25 Sep 1997 03:39:49 -0000 Date: Thu, 25 Sep 1997 05:39:49 +0200 (MET DST) From: Finn Arne Gangstad To: Archie Cobbs cc: current@FreeBSD.ORG Subject: Re: timeout management (was: Re: cvs commit: ...) In-Reply-To: <199709250229.TAA16784@bubba.whistle.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Wed, 24 Sep 1997, Archie Cobbs wrote: > > > Another algorithm that Julian and I discussed the other day has > > > these properties: > > > > > > FUNCTION TIMING (amortized) > > > add new timeout O(1) > > > check for timeout O(1) > > > remove a timeout O(1) (requires a handle) > > > process one timeout O(lg T) for T = number of ticks alive > > > > > > That is, if a timeout event lives for T ticks (whether it's cancelled > > > or expires after T ticks), it requires O(lg T) total work. > > > > > > Therefore, any event that is cancelled before 1/2 of it's timeout > > > period has expired only requires O(1) work. > > > > > > The disadvantage is that you can do a lot of work duiring a single > > > tick: O(N), where N is the number of timeout events still alive > > > in the queue after 1/2 of their timeout periods. > > > > so, do you still have to do some work after each tick?? or were does this > > come into play?? > > Yes.. each tick you do up to O(N) work (N defined as above). > > > > So if 99% of timeouts expire within the first half of their timeout > > > period, then this algorithm is "optimal". > > > > hmm.. if you have something typed up about the design of this algo, > > could you send it to me in private mail... > > I don't, but here's the general idea: for every range of ticks > of the form 2^n .. 2^(n+1) - 1 you split the range into two > halves and create a doubly linked list ("box") for each half. This is > the situation at t=0. The two halves are 2^n .. 2^n + 2^(n-1) - 1 > 2^n + 2^(n-1) .. 2^(n+1) - 1. > > When any event is scheduled, you put it in the linked list corrsponding > to the range into which it's timeout value falls. > > Now here's where it starts getting complicated... > Have you guys looked at the timer code in Linux? It basically is a small variation of this, which makes all operations O(1) for almost every timer. The idea is that instead of splitting each range into 2, you split each range into 256 (for the first range) and 32 for all other ranges. Most timers will be less than 256 ticks into the future, so they will never be moved, and 99% of the rest will in the 32 * 256 ticks range, and will, if they are not cancelled (which around 90% seem to be), only be moved once. It's in kernel/sched.c if you're unfamiliar with Linux :) - Finn Arne From owner-freebsd-current Wed Sep 24 20:48:45 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id UAA21863 for current-outgoing; Wed, 24 Sep 1997 20:48:45 -0700 (PDT) Received: from gneiss.eps.nagoya-u.ac.jp (gneiss.eps.nagoya-u.ac.jp [133.6.57.99]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id UAA21730 for ; Wed, 24 Sep 1997 20:45:28 -0700 (PDT) Received: from marble.eps.nagoya-u.ac.jp (localhost [127.0.0.1]) by gneiss.eps.nagoya-u.ac.jp (8.8.7/3.5Wpl3) with ESMTP id MAA05717; Thu, 25 Sep 1997 12:15:33 +0900 (JST) Message-Id: <199709250315.MAA05717@gneiss.eps.nagoya-u.ac.jp> To: jkh@time.cdrom.com Cc: current@FreeBSD.org Subject: Re: Daily SNAPshots at current.freebsd.org shut down for now. From: KATO Takenori In-Reply-To: Your message of "Wed, 24 Sep 1997 10:32:57 -0700" References: <29170.875122377@time.cdrom.com> X-Mailer: Mew version 1.70 on Emacs 19.28.1 / Mule 2.3 X-PGP-Fingerprint: 03 72 85 36 62 46 23 03 52 B1 10 22 44 10 0D 9E Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Thu, 25 Sep 1997 12:15:33 +0900 Sender: owner-freebsd-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk I Cc'ed to current. > Can you give me a -current patch? That's actually what matters Here is a patch which I don't perform compile test (sorry). ---------- BEGIN ---------- *** sys/dev/vn/vn.c.ORIG Thu Sep 25 09:10:44 1997 --- sys/dev/vn/vn.c Thu Sep 25 09:31:01 1997 *************** *** 403,409 **** struct nameidata nd; int error; u_long *f; ! IFOPT(vn,VN_FOLLOW) printf("vnioctl(0x%lx, 0x%x, %p, 0x%x, %p): unit %d\n", --- 403,409 ---- struct nameidata nd; int error; u_long *f; ! u_long vflag = 0; IFOPT(vn,VN_FOLLOW) printf("vnioctl(0x%lx, 0x%x, %p, 0x%x, %p): unit %d\n", *************** *** 411,416 **** --- 411,417 ---- switch (cmd) { case VNIOCATTACH: + case VNIOCATTACHNCLUSTER: case VNIOCDETACH: case VNIOCGSET: case VNIOCGCLEAR: *************** *** 442,447 **** --- 443,451 ---- f = (u_long*)data; switch (cmd) { + case VNIOCATTACHNCLUSTER: + vflag = VNOCLUSTER; + /* FALLTHROUGH */ case VNIOCATTACH: if (vn->sc_flags & VNF_INITED) return(EBUSY); *************** *** 463,468 **** --- 467,473 ---- } VOP_UNLOCK(nd.ni_vp, 0, p); vn->sc_vp = nd.ni_vp; + vn->sc_vp->v_flag |= vflag; vn->sc_size = btodb(vattr.va_size); /* note truncation */ error = vnsetcred(vn, p->p_ucred); if (error) { *** sys/gnu/ext2fs/ext2_readwrite.c.ORIG Thu Sep 25 09:25:09 1997 --- sys/gnu/ext2fs/ext2_readwrite.c Thu Sep 25 09:34:25 1997 *************** *** 112,118 **** if (lblktosize(fs, nextlbn) >= ip->i_size) error = bread(vp, lbn, size, NOCRED, &bp); ! else if (ext2_doclusterread) error = cluster_read(vp, ip->i_size, lbn, size, NOCRED, uio->uio_resid, (ap->a_ioflag >> 16), &bp); --- 112,118 ---- if (lblktosize(fs, nextlbn) >= ip->i_size) error = bread(vp, lbn, size, NOCRED, &bp); ! else if (ext2_doclusterread && !(vp->v_flag & VNOCLUSTER)) error = cluster_read(vp, ip->i_size, lbn, size, NOCRED, uio->uio_resid, (ap->a_ioflag >> 16), &bp); *************** *** 277,283 **** if (ioflag & IO_SYNC) { (void)bwrite(bp); } else if (xfersize + blkoffset == fs->s_frag_size) { ! if (ext2_doclusterwrite) { #if defined(__FreeBSD__) bp->b_flags |= B_CLUSTEROK; #endif --- 277,283 ---- if (ioflag & IO_SYNC) { (void)bwrite(bp); } else if (xfersize + blkoffset == fs->s_frag_size) { ! if (ext2_doclusterwrite && !(vp->v_flag & VNOCLUSTER)) { #if defined(__FreeBSD__) bp->b_flags |= B_CLUSTEROK; #endif *** sys/isofs/cd9660/cd9660_vnops.c.ORIG Thu Sep 25 09:35:11 1997 --- sys/isofs/cd9660/cd9660_vnops.c Thu Sep 25 09:36:30 1997 *************** *** 344,350 **** n = diff; size = blksize(imp, ip, lbn); rablock = lbn + 1; ! if (cd9660_doclusterread) { if (lblktosize(imp, rablock) <= ip->i_size) error = cluster_read(vp, (off_t)ip->i_size, lbn, size, NOCRED, uio->uio_resid, --- 344,350 ---- n = diff; size = blksize(imp, ip, lbn); rablock = lbn + 1; ! if (cd9660_doclusterread && !(vp->v_flag & VNOCLUSTER)) { if (lblktosize(imp, rablock) <= ip->i_size) error = cluster_read(vp, (off_t)ip->i_size, lbn, size, NOCRED, uio->uio_resid, *** sys/sys/vnioctl.h.ORIG Thu Sep 25 09:24:42 1997 --- sys/sys/vnioctl.h Thu Sep 25 09:30:28 1997 *************** *** 66,71 **** --- 66,73 ---- #define VNIOCGCLEAR _IOWR('F', 3, u_long ) /* reset --//-- */ #define VNIOCUSET _IOWR('F', 4, u_long ) /* set unit option */ #define VNIOCUCLEAR _IOWR('F', 5, u_long ) /* reset --//-- */ + #define VNIOCATTACHNCLUSTER _IOWR('F', 6, struct vn_ioctl) + /* attach file, disable cluster read/write */ #define VN_LABELS 0x1 /* Use disk(/slice) labels */ #define VN_FOLLOW 0x2 /* Debug flow in vn driver */ *** sys/sys/vnode.h.ORIG Thu Sep 25 09:28:11 1997 --- sys/sys/vnode.h Thu Sep 25 09:29:54 1997 *************** *** 127,148 **** /* * Vnode flags. */ ! #define VROOT 0x00001 /* root of its file system */ ! #define VTEXT 0x00002 /* vnode is a pure text prototype */ ! #define VSYSTEM 0x00004 /* vnode being used by kernel */ ! #define VISTTY 0x00008 /* vnode represents a tty */ ! #define VXLOCK 0x00100 /* vnode is locked to change underlying type */ ! #define VXWANT 0x00200 /* process is waiting for vnode */ ! #define VBWAIT 0x00400 /* waiting for output to complete */ ! #define VALIASED 0x00800 /* vnode has an alias */ ! #define VDIROP 0x01000 /* LFS: vnode is involved in a directory op */ ! #define VVMIO 0x02000 /* VMIO flag */ ! #define VNINACT 0x04000 /* LFS: skip ufs_inactive() in lfs_vunref */ ! #define VAGE 0x08000 /* Insert vnode at head of free list */ ! #define VOLOCK 0x10000 /* vnode is locked waiting for an object */ ! #define VOWANT 0x20000 /* a process is waiting for VOLOCK */ ! #define VDOOMED 0x40000 /* This vnode is being recycled */ ! #define VFREE 0x80000 /* This vnode is on the freelist */ /* * Vnode attributes. A field value of VNOVAL represents a field whose value --- 127,149 ---- /* * Vnode flags. */ ! #define VROOT 0x000001 /* root of its file system */ ! #define VTEXT 0x000002 /* vnode is a pure text prototype */ ! #define VSYSTEM 0x000004 /* vnode being used by kernel */ ! #define VISTTY 0x000008 /* vnode represents a tty */ ! #define VXLOCK 0x000100 /* vnode is locked to change underlying type */ ! #define VXWANT 0x000200 /* process is waiting for vnode */ ! #define VBWAIT 0x000400 /* waiting for output to complete */ ! #define VALIASED 0x000800 /* vnode has an alias */ ! #define VDIROP 0x001000 /* LFS: vnode is involved in a directory op */ ! #define VVMIO 0x002000 /* VMIO flag */ ! #define VNINACT 0x004000 /* LFS: skip ufs_inactive() in lfs_vunref */ ! #define VAGE 0x008000 /* Insert vnode at head of free list */ ! #define VOLOCK 0x010000 /* vnode is locked waiting for an object */ ! #define VOWANT 0x020000 /* a process is waiting for VOLOCK */ ! #define VDOOMED 0x040000 /* This vnode is being recycled */ ! #define VFREE 0x080000 /* This vnode is on the freelist */ ! #define VNOCLUSTER 0x100000 /* This vnode is on the freelist */ /* * Vnode attributes. A field value of VNOVAL represents a field whose value *** sys/ufs/ufs/ufs_readwrite.c.ORIG Thu Sep 25 09:24:52 1997 --- sys/ufs/ufs/ufs_readwrite.c Thu Sep 25 09:33:06 1997 *************** *** 123,129 **** #else if (lblktosize(fs, nextlbn) >= ip->i_size) error = bread(vp, lbn, size, NOCRED, &bp); ! else if (ffs_doclusterread) error = cluster_read(vp, ip->i_size, lbn, size, NOCRED, uio->uio_resid, seqcount, &bp); else if (lbn - 1 == vp->v_lastr) { --- 123,129 ---- #else if (lblktosize(fs, nextlbn) >= ip->i_size) error = bread(vp, lbn, size, NOCRED, &bp); ! else if (ffs_doclusterread && !(vp->v_flag & VNOCLUSTER)) error = cluster_read(vp, ip->i_size, lbn, size, NOCRED, uio->uio_resid, seqcount, &bp); else if (lbn - 1 == vp->v_lastr) { *************** *** 281,287 **** if (ioflag & IO_SYNC) { (void)bwrite(bp); } else if (xfersize + blkoffset == fs->fs_bsize) { ! if (ffs_doclusterwrite) { bp->b_flags |= B_CLUSTEROK; cluster_write(bp, ip->i_size); } else { --- 281,287 ---- if (ioflag & IO_SYNC) { (void)bwrite(bp); } else if (xfersize + blkoffset == fs->fs_bsize) { ! if (ffs_doclusterwrite && !(vp->v_flag & VNOCLUSTER)) { bp->b_flags |= B_CLUSTEROK; cluster_write(bp, ip->i_size); } else { *** usr.sbin/vnconfig/vnconfig.8.orig Thu Sep 25 09:40:55 1997 --- usr.sbin/vnconfig/vnconfig.8 Thu Sep 25 09:41:50 1997 *************** *** 81,86 **** --- 81,88 ---- .Fl c . .It Fl d Disables (if possible) the specified feature. + .It Fl n + Disables cluster read and write. .It Fl u Disables and ``unconfigures'' the device. .It Fl v *** usr.sbin/vnconfig/vnconfig.c.orig Thu Sep 25 09:40:55 1997 --- usr.sbin/vnconfig/vnconfig.c Thu Sep 25 09:41:50 1997 *************** *** 69,74 **** --- 69,75 ---- #define VN_IGNORE 0x80 #define VN_SET 0x100 #define VN_RESET 0x200 + #define VN_NOCLUSTER 0x400 int nvndisks; *************** *** 159,164 **** --- 160,170 ---- verbose++; break; + /* disable cluster read / write */ + case 'n': + flags |= VN_NOCLUSTER; + break; + default: fprintf(stderr, "invalid option '%c'\n", optopt); usage(); *************** *** 260,272 **** * Configure the device */ if (flags & VN_CONFIG) { ! rv = ioctl(fileno(f), VNIOCATTACH, &vnio); ! if (rv) { ! perror("VNIOCATTACH"); ! flags &= ~VN_ENABLE; ! } else if (verbose) ! printf("%s: %d bytes on %s\n", ! dev, vnio.vn_size, file); } /* * Set an option --- 266,288 ---- * Configure the device */ if (flags & VN_CONFIG) { ! if (flags & VN_NOCLUSTER) { ! rv = ioctl(fileno(f), VNIOCATTACHNCLUSTER, &vnio); ! if (rv) { ! perror("VNIOCATTACHNCLUSTER"); ! flags &= ~VN_ENABLE; ! } else if (verbose) ! printf("%s: %d bytes on %s\n", ! dev, vnio.vn_size, file); ! } else { ! rv = ioctl(fileno(f), VNIOCATTACH, &vnio); ! if (rv) { ! perror("VNIOCATTACH"); ! flags &= ~VN_ENABLE; ! } else if (verbose) ! printf("%s: %d bytes on %s\n", ! dev, vnio.vn_size, file); ! } } /* * Set an option ---------- END ---------- ---- KATO Takenori Dept. Earth Planet. Sci., Nagoya Univ., Nagoya, 464-01, Japan PGP public key: finger kato@eclogite.eps.nagoya-u.ac.jp ------------------- Powered by FreeBSD(98) ------------------- From owner-freebsd-current Wed Sep 24 21:51:18 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id VAA24735 for current-outgoing; Wed, 24 Sep 1997 21:51:18 -0700 (PDT) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id VAA24725 for ; Wed, 24 Sep 1997 21:51:12 -0700 (PDT) Received: (from daemon@localhost) by alpo.whistle.com (8.8.5/8.8.5) id VAA26747; Wed, 24 Sep 1997 21:50:05 -0700 (PDT) Received: from current1.whistle.com(207.76.205.22) via SMTP by alpo.whistle.com, id smtpd026739; Thu Sep 25 04:50:02 1997 Date: Wed, 24 Sep 1997 21:49:11 -0700 (PDT) From: Julian Elischer To: Finn Arne Gangstad cc: Archie Cobbs , current@FreeBSD.ORG Subject: Re: timeout management (was: Re: cvs commit: ...) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > > > Have you guys looked at the timer code in Linux? It basically is a small > variation of this, which makes all operations O(1) for almost > every timer. > > The idea is that instead of splitting each range into 2, you split each > range into 256 (for the first range) and 32 for all other ranges. > > Most timers will be less than 256 ticks into the future, so they will > never be moved, and 99% of the rest will in the 32 * 256 ticks range, and > will, if they are not cancelled (which around 90% seem to be), only be > moved once. > > It's in kernel/sched.c if you're unfamiliar with Linux :) the first set of 256 is similar to the new system in FreeBSD The second one could be sonsidered as similar, but just repeated. > > - Finn Arne > > From owner-freebsd-current Wed Sep 24 22:12:20 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id WAA25617 for current-outgoing; Wed, 24 Sep 1997 22:12:20 -0700 (PDT) Received: from pluto.plutotech.com (root@mail.plutotech.com [206.168.67.137]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id WAA25612 for ; Wed, 24 Sep 1997 22:12:15 -0700 (PDT) Received: from narnia.plutotech.com (narnia.plutotech.com [206.168.67.130]) by pluto.plutotech.com (8.8.5/8.8.5) with ESMTP id XAA19962; Wed, 24 Sep 1997 23:12:10 -0600 (MDT) Message-Id: <199709250512.XAA19962@pluto.plutotech.com> To: Finn Arne Gangstad cc: Archie Cobbs , current@FreeBSD.ORG Subject: Re: timeout management (was: Re: cvs commit: ...) In-reply-to: Your message of "Thu, 25 Sep 1997 05:39:49 +0200." Date: Wed, 24 Sep 1997 23:11:58 -0600 From: "Justin T. Gibbs" Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >Have you guys looked at the timer code in Linux? It basically is a small >variation of this, which makes all operations O(1) for almost >every timer. It looks like a 5 level hierarchical timing wheel to me. FreeBSD currently has a one level timing wheel. Cascade_timers should enable interrupts at deterministic intervals so that interrupts are defered a deterministic amount of time. > >- Finn Arne > -- Justin T. Gibbs =========================================== FreeBSD: Turning PCs into workstations =========================================== From owner-freebsd-current Wed Sep 24 22:47:27 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id WAA27168 for current-outgoing; Wed, 24 Sep 1997 22:47:27 -0700 (PDT) Received: from lucifer.guardian.no (gate.guardian.no [195.1.254.2]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id WAA27162 for ; Wed, 24 Sep 1997 22:47:20 -0700 (PDT) Received: (qmail 29669 invoked by uid 21574); 25 Sep 1997 05:47:14 -0000 Date: Thu, 25 Sep 1997 07:47:14 +0200 (MET DST) From: Finn Arne Gangstad To: "Justin T. Gibbs" cc: Archie Cobbs , current@FreeBSD.ORG Subject: Re: timeout management (was: Re: cvs commit: ...) In-Reply-To: <199709250512.XAA19962@pluto.plutotech.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Wed, 24 Sep 1997, Justin T. Gibbs wrote: > >Have you guys looked at the timer code in Linux? It basically is a small > >variation of this, which makes all operations O(1) for almost > >every timer. > > It looks like a 5 level hierarchical timing wheel to me. FreeBSD currently > has a one level timing wheel. Cascade_timers should enable interrupts > at deterministic intervals so that interrupts are defered a deterministic > amount of time. In 2.1.X it just grabs the timer spinlock. 2.0.X is pretty much set in stone really (the new timer code was actually put in in 2.1.23 i think, but applied to 2.0.30 for efficiency reasons). There was a lot of discussion on the kernel list about cascace_timers enabling timers now and then, in practice cascade_timers never move many timers so it's not really a problem, even less of a problem when it just grabs the timer lock. - Finn Arne From owner-freebsd-current Wed Sep 24 22:54:23 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id WAA27460 for current-outgoing; Wed, 24 Sep 1997 22:54:23 -0700 (PDT) Received: from pluto.plutotech.com (root@mail.plutotech.com [206.168.67.137]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id WAA27452 for ; Wed, 24 Sep 1997 22:54:20 -0700 (PDT) Received: from narnia.plutotech.com (narnia.plutotech.com [206.168.67.130]) by pluto.plutotech.com (8.8.5/8.8.5) with ESMTP id XAA20672; Wed, 24 Sep 1997 23:54:15 -0600 (MDT) Message-Id: <199709250554.XAA20672@pluto.plutotech.com> To: Finn Arne Gangstad cc: "Justin T. Gibbs" , Archie Cobbs , current@FreeBSD.ORG Subject: Re: timeout management (was: Re: cvs commit: ...) In-reply-to: Your message of "Thu, 25 Sep 1997 07:47:14 +0200." Date: Wed, 24 Sep 1997 23:54:02 -0600 From: "Justin T. Gibbs" Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >There was a lot of discussion on the kernel list about cascace_timers >enabling timers now and then, in practice cascade_timers never move many >timers so it's not really a problem, even less of a problem when it just >grabs the timer lock. > >- Finn Arne If the granularity of the timer interval is large when compared to the speed with which a given application generates timers for the same interval, you could have a problem. If you want to do RT, I think you have to enable timers periodically, or you may miss a deadline. -- Justin T. Gibbs =========================================== FreeBSD: Turning PCs into workstations =========================================== From owner-freebsd-current Wed Sep 24 22:56:42 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id WAA27558 for current-outgoing; Wed, 24 Sep 1997 22:56:42 -0700 (PDT) Received: from pluto.plutotech.com (root@mail.plutotech.com [206.168.67.137]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id WAA27550 for ; Wed, 24 Sep 1997 22:56:38 -0700 (PDT) Received: from narnia.plutotech.com (narnia.plutotech.com [206.168.67.130]) by pluto.plutotech.com (8.8.5/8.8.5) with ESMTP id XAA20716; Wed, 24 Sep 1997 23:56:32 -0600 (MDT) Message-Id: <199709250556.XAA20716@pluto.plutotech.com> To: "Justin T. Gibbs" cc: Finn Arne Gangstad , Archie Cobbs , current@FreeBSD.ORG Subject: Re: timeout management (was: Re: cvs commit: ...) In-reply-to: Your message of "Wed, 24 Sep 1997 23:54:02 MDT." <199709250554.XAA20672@pluto.plutotech.com> Date: Wed, 24 Sep 1997 23:56:20 -0600 From: "Justin T. Gibbs" Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk I should also mention that: http://dworkin.wustl.edu/~varghese/PAPERS/twheel.ps.Z contains a good discussion of these issues. -- Justin T. Gibbs =========================================== FreeBSD: Turning PCs into workstations =========================================== From owner-freebsd-current Thu Sep 25 00:17:03 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id AAA01810 for current-outgoing; Thu, 25 Sep 1997 00:17:03 -0700 (PDT) Received: from relay13.jaring.my (relay13.jaring.my [192.228.128.124]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id AAA01798 for ; Thu, 25 Sep 1997 00:16:49 -0700 (PDT) Received: from pc.jaring.my ([202.190.19.56]) by relay13.jaring.my (8.8.7/8.8.7) with ESMTP id PAA23074; Thu, 25 Sep 1997 15:15:25 +0800 (MYT) Message-ID: <342A1180.39FC0D16@pc.jaring.my> Date: Thu, 25 Sep 1997 15:23:44 +0800 From: Mitsuru IWASAKI Reply-To: current@FreeBSD.ORG Organization: AISDEL; SIRIM X-Mailer: Mozilla 4.02b7 [en] (X11; I; FreeBSD 2.2-STABLE i386) MIME-Version: 1.0 To: current@FreeBSD.ORG CC: iwasaki@pc.jaring.my Subject: Re: pcm device has a conflict with FreeBSD(98)? (Re: cvs commit: src/sys/i386/isa/snd Content-Type: text/plain; charset=iso-2022-jp Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hi, thanks for your reply and kato-san's quick fix for /sys/pc98/conf/files.pc98 in -current. Luigi Rizzo wrote: > I am sorry for the name clash. If someone has a better name I have no > objection. I have picked up "pcm" because "snd" was already in use (and ... > The actual name has not much importance in both cases since it Agreed. > I do not lean for any of the two solutions, provided the new name is > reasonable and reminds the functionality of the device > (i.e. I would not like to call it "yapcm"!) How about these? - iss (Integrated (or Improved) Sound System) - msnd (Multi-snd) - nsnd (New snd) - yasnd (Yet Another snd) - isnd - xsnd - ipcm - xpcm I prefer the first one :) --- o [=] O (.~.)_P +=======================oooO==( )//Oooo======================+ | --- Mitsuru IWASAKI ---- | |15A-1-3, Scots Tower, MONT' KIARA CONDOMINIUM, Jalan 1/70C, | |Off Bikit Kiara, 50480 Kuala Lumpur, Malaysia | |TEL/FAX: +60-3-2538579 _/_/_/ _/ | |e-mail: iwasaki@sirim.my(OFFICE) _/ _/ _/ _/ | | iwasaki@pc.jaring.my(HOME) iwasaki@jp.FreeBSD.ORG(FreeBSD) | +============================================================+ From owner-freebsd-current Thu Sep 25 00:46:40 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id AAA03154 for current-outgoing; Thu, 25 Sep 1997 00:46:40 -0700 (PDT) Received: from usr03.primenet.com (tlambert@usr03.primenet.com [206.165.6.203]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id AAA03148 for ; Thu, 25 Sep 1997 00:46:34 -0700 (PDT) Received: (from tlambert@localhost) by usr03.primenet.com (8.8.5/8.8.5) id AAA10463; Thu, 25 Sep 1997 00:44:42 -0700 (MST) From: Terry Lambert Message-Id: <199709250744.AAA10463@usr03.primenet.com> Subject: Re: new timeout routines To: nate@mt.sri.com (Nate Williams) Date: Thu, 25 Sep 1997 07:44:41 +0000 (GMT) Cc: tlambert@primenet.com, nate@mt.sri.com, julian@whistle.com, gibbs@plutotech.com, bde@zeta.org.au, current@freebsd.org In-Reply-To: <199709250222.UAA16284@rocky.mt.sri.com> from "Nate Williams" at Sep 24, 97 08:22:22 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > Which bucket is an 8 tick timeout in? It's going to be in the current > > bucket or any one of the 7 following it, depending on how many sofclocks > > have happenend since the queue. > > We're not hashing on the tick, we're hashing on the function/arguements. > The result of the hash gives us a pointer to the exact element. It occurs to me that this will not be O(1). The cookie soloution is O(1). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-current Thu Sep 25 00:47:35 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id AAA03200 for current-outgoing; Thu, 25 Sep 1997 00:47:35 -0700 (PDT) Received: from usr03.primenet.com (tlambert@usr03.primenet.com [206.165.6.203]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id AAA03193 for ; Thu, 25 Sep 1997 00:47:31 -0700 (PDT) Received: (from tlambert@localhost) by usr03.primenet.com (8.8.5/8.8.5) id AAA10520; Thu, 25 Sep 1997 00:47:26 -0700 (MST) From: Terry Lambert Message-Id: <199709250747.AAA10520@usr03.primenet.com> Subject: Re: timeout management (was: Re: cvs commit: ...) To: gibbs@plutotech.com (Justin T. Gibbs) Date: Thu, 25 Sep 1997 07:47:25 +0000 (GMT) Cc: finnag@guardian.no, archie@whistle.com, current@FreeBSD.ORG In-Reply-To: <199709250512.XAA19962@pluto.plutotech.com> from "Justin T. Gibbs" at Sep 24, 97 11:11:58 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > >Have you guys looked at the timer code in Linux? It basically is a small > >variation of this, which makes all operations O(1) for almost > >every timer. > > It looks like a 5 level hierarchical timing wheel to me. FreeBSD currently > has a one level timing wheel. Cascade_timers should enable interrupts > at deterministic intervals so that interrupts are defered a deterministic > amount of time. I agree with Justin on this. The Linux code is insufficient, in this case. BTW, it's linux/kernel/sched.c, not just kernel/sched.c. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-current Thu Sep 25 00:50:11 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id AAA03508 for current-outgoing; Thu, 25 Sep 1997 00:50:11 -0700 (PDT) Received: from usr03.primenet.com (tlambert@usr03.primenet.com [206.165.6.203]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id AAA03494 for ; Thu, 25 Sep 1997 00:50:05 -0700 (PDT) Received: (from tlambert@localhost) by usr03.primenet.com (8.8.5/8.8.5) id AAA10623; Thu, 25 Sep 1997 00:49:54 -0700 (MST) From: Terry Lambert Message-Id: <199709250749.AAA10623@usr03.primenet.com> Subject: Re: timeout management (was: Re: cvs commit: ...) To: gibbs@plutotech.com (Justin T. Gibbs) Date: Thu, 25 Sep 1997 07:49:54 +0000 (GMT) Cc: finnag@guardian.no, gibbs@plutotech.com, archie@whistle.com, current@FreeBSD.ORG In-Reply-To: <199709250554.XAA20672@pluto.plutotech.com> from "Justin T. Gibbs" at Sep 24, 97 11:54:02 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > >There was a lot of discussion on the kernel list about cascace_timers > >enabling timers now and then, in practice cascade_timers never move many > >timers so it's not really a problem, even less of a problem when it just > >grabs the timer lock. > > > >- Finn Arne > > If the granularity of the timer interval is large when compared to > the speed with which a given application generates timers for the same > interval, you could have a problem. > > If you want to do RT, I think you have to enable timers periodically, > or you may miss a deadline. It's worse than that. If the timer fires, and the timer was scheduled by a process with a higher RT priority than the current process, you have to involuntary context switch the current process. Running a floppy tape drive is probably at the highest RT priority you can manage, actually, in order to ensure coorect operation with a kernel based driver. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-current Thu Sep 25 00:51:47 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id AAA03598 for current-outgoing; Thu, 25 Sep 1997 00:51:47 -0700 (PDT) Received: from labinfo.iet.unipi.it (labinfo.iet.unipi.it [131.114.9.5]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id AAA03589 for ; Thu, 25 Sep 1997 00:51:38 -0700 (PDT) Received: from localhost (luigi@localhost) by labinfo.iet.unipi.it (8.6.5/8.6.5) id IAA23519; Thu, 25 Sep 1997 08:38:23 +0200 From: Luigi Rizzo Message-Id: <199709250638.IAA23519@labinfo.iet.unipi.it> Subject: Re: pcm device has a conflict with FreeBSD(98)? (Re: cvs commit: src/sys/i386/isa/snd To: current@FreeBSD.ORG Date: Thu, 25 Sep 1997 08:38:22 +0200 (MET DST) Cc: iwasaki@pc.jaring.my In-Reply-To: <342A1180.39FC0D16@pc.jaring.my> from "Mitsuru IWASAKI" at Sep 25, 97 03:23:25 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > Luigi Rizzo wrote: > > I am sorry for the name clash. If someone has a better name I have no > > objection. I have picked up "pcm" because "snd" was already in use (and > ... > > The actual name has not much importance in both cases since it > > Agreed. > > > I do not lean for any of the two solutions, provided the new name is > > reasonable and reminds the functionality of the device > > (i.e. I would not like to call it "yapcm"!) > > How about these? > - iss (Integrated (or Improved) Sound System) > - msnd (Multi-snd) > - nsnd (New snd) > - yasnd (Yet Another snd) > - isnd > - xsnd > - ipcm > - xpcm > > I prefer the first one :) it is not "sound" because it does not support midi/synth devices, really just pcm stuff. As I was telling someone else, "audio" could be a suitable name in my opinion. Cheers Luigi From owner-freebsd-current Thu Sep 25 01:48:08 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id BAA06015 for current-outgoing; Thu, 25 Sep 1997 01:48:08 -0700 (PDT) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id BAA06010 for ; Thu, 25 Sep 1997 01:48:03 -0700 (PDT) Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.5/8.6.9) id SAA05852; Thu, 25 Sep 1997 18:25:38 +1000 Date: Thu, 25 Sep 1997 18:25:38 +1000 From: Bruce Evans Message-Id: <199709250825.SAA05852@godzilla.zeta.org.au> To: julian@whistle.com, nate@mt.sri.com Subject: Re: new timeout routines Cc: bde@zeta.org.au, current@FreeBSD.ORG, gibbs@plutotech.com, tlambert@primenet.com Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >> so what happens if I call untimeout twice? > >It does the right thing, since we you 'untimeout the function pointer is >NULL'd out. It's subtler than that. The cookie becomes stale after untimeout(). Stale cookies are not much of a problem since the function pointer (in the object pointed to by the cookie) is "NULL'd out" and the space referenced by the cookie is never freed. If the space is reused, then: case 1: if the space is reused for the same (ftn, arg), then untimeout() with the old cookie will clear the new timeout. This causes the same problems as calling the old version of untimeout() one too many times after a new timeout has been started. Drivers shouldn't do it. case 2: if the space is reused for a different (ftn, arg), then untimeout() withe the old cookie will do nothing. No problem. >> there is an assumption in a lot of code that untimeout is idempotent >> (did I get that right?). It can be called whenever you are recovering >> from unknown situations with the sure knowledge that the appropriate >> timeout will be removed. > >According to Justin, the old only removed a timeout with the same >function/arguements, which may/may not have been the right one, if >multiple timeouts with the same function/arguements were created. It made no difference which one was removed, since timeouts with the same (ftn, arg) are equivalent. The problem (if any) was that untimeout() didn't remove all timeouts with the specified (ftn, arg), and it didn't tell you if it did anything, so there was no way to be sure of removing all timeouts without keeping track of the timeouts that you have set. This isn't a real problem. You must keep track of the timeouts that you have set anyway, since setting too many timeouts would exhaust the callout table. The new interface can remove a particular timeout, but this isn't important since timeouts with the same (ftn, arg) are equivalent. It forces you to keep track of timeouts more explicitly to manage the cookies. Code like foo_ch = timeout(foo_handler, 0, hz); in a loop without a corresponding untimeout() is usually wrong because assignment too foo_ch clobbers the previous value. However, it was usually also wrong with the old interface, since it might have exhausted the callout table. OTOH, code like (void)timeout(foo_handler, 0, hz); in a loop without a corresponding untimeout() is correct if the loop only runs once per timeout. Bruce From owner-freebsd-current Thu Sep 25 02:08:06 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id CAA06791 for current-outgoing; Thu, 25 Sep 1997 02:08:06 -0700 (PDT) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id CAA06761 for ; Thu, 25 Sep 1997 02:07:59 -0700 (PDT) Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.5/8.6.9) id SAA06295; Thu, 25 Sep 1997 18:38:01 +1000 Date: Thu, 25 Sep 1997 18:38:01 +1000 From: Bruce Evans Message-Id: <199709250838.SAA06295@godzilla.zeta.org.au> To: gibbs@plutotech.com, julian@whistle.com Subject: Re: new timeout routines Cc: bde@zeta.org.au, current@FreeBSD.ORG, nate@mt.sri.com, tlambert@primenet.com Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >there is an assumption in a lot of code that untimeout is idempotent >(did I get that right?). It can be called whenever you are recovering >from unknown situations with the sure knowledge that the appropriate >timeout will be removed. This was an invalid assumption, since timeout() was only (almost) nilpotent (calling it N+1 times has the same effect as calling it N times for some value of N, provided there are no calls to timeout() mixed with the calls to untimeout()). Now it is (almost) idempotent (N = 1 in the above), provided the cookies are managed properly. Correct cookie management corresponds to using the correct value of N in the old version. Bruce From owner-freebsd-current Thu Sep 25 02:51:02 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id CAA08707 for current-outgoing; Thu, 25 Sep 1997 02:51:02 -0700 (PDT) Received: from freebie.lemis.com (gregl1.lnk.telstra.net [139.130.136.133]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id CAA08651 for ; Thu, 25 Sep 1997 02:49:54 -0700 (PDT) Received: (from grog@localhost) by freebie.lemis.com (8.8.7/8.8.5) id TAA04763; Thu, 25 Sep 1997 19:18:04 +0930 (CST) Message-ID: <19970925191804.00720@lemis.com> Date: Thu, 25 Sep 1997 19:18:04 +0930 From: Greg Lehey To: FreeBSD current users Subject: find still broken - is this only happening to me? Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.81e Organisation: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8250 Fax: +61-8-8388-8250 Mobile: +61-41-739-7062 WWW-Home-Page: http://www.lemis.com/~grog Fight-Spam-Now: http://www.cauce.org Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk I reported this a couple of weeks ago. Has nobody else experienced it? $ find /sys -follow -name "*.[csh]" | xargs grep ENFILE|less ): no beginning '(' I keep removing /usr/bin/find and replacing it with GNU find, but every time I do a CVSup, it comes back. Greg From owner-freebsd-current Thu Sep 25 03:41:03 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id DAA10496 for current-outgoing; Thu, 25 Sep 1997 03:41:03 -0700 (PDT) Received: from usr03.primenet.com (tlambert@usr03.primenet.com [206.165.6.203]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id DAA10491 for ; Thu, 25 Sep 1997 03:41:00 -0700 (PDT) Received: (from tlambert@localhost) by usr03.primenet.com (8.8.5/8.8.5) id DAA16218; Thu, 25 Sep 1997 03:40:33 -0700 (MST) From: Terry Lambert Message-Id: <199709251040.DAA16218@usr03.primenet.com> Subject: Re: new timeout routines To: bde@zeta.org.au (Bruce Evans) Date: Thu, 25 Sep 1997 10:40:33 +0000 (GMT) Cc: gibbs@plutotech.com, julian@whistle.com, bde@zeta.org.au, current@FreeBSD.ORG, nate@mt.sri.com, tlambert@primenet.com In-Reply-To: <199709250838.SAA06295@godzilla.zeta.org.au> from "Bruce Evans" at Sep 25, 97 06:38:01 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk This is getting quoted a lot... otherwise I won't try to correct it. > >there is an assumption in a lot of code that untimeout is idempotent > >(did I get that right?). It can be called whenever you are recovering > >from unknown situations with the sure knowledge that the appropriate > >timeout will be removed. > > This was an invalid assumption, since timeout() was only (almost) > nilpotent (calling it N+1 times has the same effect as calling it N > times for some value of N, provided there are no calls to timeout() > mixed with the calls to untimeout()). > > Now it is (almost) idempotent (N = 1 in the above), provided the > cookies are managed properly. Correct cookie management corresponds > to using the correct value of N in the old version. Actually, this is "called reflexively". Idempotence refers to the property of an operation wherein the operation may encapsulate multiple atomic operations as if it were itself atomic; it's more of an identity function for the set of operations that it encapsulates. A file rename operation may be idempotent, without there being only a single atomic operation involved. Main Entry: idempotent Pronunciation: 'I-d&m-"pO-t&nt Function: adjective Etymology: Latin idem same + potent-, potens having power -- more at POTENT Date: 1870 : relating to or being a mathematical quantity which when applied to itself under a given binary operation (as multiplication) equals itself; also : relating to or being an operation under which a mathematical quantity is idempotent - idempotent noun I don't think the code is assumed to be idempotent. I think it is assumed to be called reflexively (ie: one and only one deregistration called per registration). As others have pointed out, this is not a requirement, since you can sense stale cookies in the new scheme, and you can see the nulled out function entries in the old. It's more a rule of thumb. I don't think it's a bad thing for reflexive calling to become a requirement, where there is only a single deregister per register, or a single implicit deregister as a result of the timer firing (my "reschedulable one-shots" require an idempotent implicit deregister followed by explicit register in order to simulate a periodically scheduled event ;-)). All of the current lock code is reflexive, for example. The vnode lookup code in namei() is not (for another example). The vnode locking is not idempotent because of the possibility recursion (for yet another). If you want to be a real propeller-head (like me ;-)), you can read about Godel's Theorem and the mathematical definition of "completeness"; most of my whining about interfaces has to do with provability of "completeness" in the rigorous mathematical sense. Look up "+branch +path +analysis" on AltaVista, or read the book "code complete" for a higher level overview. If you do the AltaVista thing, you will at least get a useful tool in C++ for processing C code and producing test code out of it. 8-). Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-current Thu Sep 25 04:48:36 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id EAA12518 for current-outgoing; Thu, 25 Sep 1997 04:48:36 -0700 (PDT) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id EAA12502 for ; Thu, 25 Sep 1997 04:48:30 -0700 (PDT) Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.5/8.6.9) id VAA13138; Thu, 25 Sep 1997 21:44:49 +1000 Date: Thu, 25 Sep 1997 21:44:49 +1000 From: Bruce Evans Message-Id: <199709251144.VAA13138@godzilla.zeta.org.au> To: bde@zeta.org.au, tlambert@primenet.com Subject: Re: new timeout routines Cc: current@FreeBSD.ORG, gibbs@plutotech.com, julian@whistle.com, nate@mt.sri.com Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk I wrote: >> This was an invalid assumption, since timeout() was only (almost) >> nilpotent (calling it N+1 times has the same effect as calling it N >> times for some value of N, provided there are no calls to timeout() >> mixed with the calls to untimeout()). Oops. Nilpotence (for an element x in a ring) is actually x^N == 0, not x^(N+1) == x^N. >> Now it is (almost) idempotent (N = 1 in the above), provided the This is correct. Idempotence (for an element x in a set with a binary operation '*') is x*x = x. >Actually, this is "called reflexively". Wrong. Reflexivity (for an element x in a set with a binary relation R to itself) is xRx. > Main Entry: idempotent > Pronunciation: 'I-d&m-"pO-t&nt > Function: adjective > Etymology: Latin idem same + potent-, potens having power -- more at > POTENT > Date: 1870 > : relating to or being a mathematical quantity which when applied to > itself under a given binary operation (as multiplication) equals > itself; also : relating to or being an operation under which a > mathematical quantity is idempotent > - idempotent noun This is correct :-). There must be a binary operation (i.e., a mapping SxS -> S), not just a self-relation (i.e., a mapping SxS -> {0, 1}) to define idempotence. Bruce From owner-freebsd-current Thu Sep 25 06:19:55 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id GAA15879 for current-outgoing; Thu, 25 Sep 1997 06:19:55 -0700 (PDT) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id GAA15871 for ; Thu, 25 Sep 1997 06:19:44 -0700 (PDT) Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.5/8.6.9) id XAA16478; Thu, 25 Sep 1997 23:11:44 +1000 Date: Thu, 25 Sep 1997 23:11:44 +1000 From: Bruce Evans Message-Id: <199709251311.XAA16478@godzilla.zeta.org.au> To: kato@migmatite.eps.nagoya-u.ac.jp, phk@critter.freebsd.dk Subject: Re: Daily SNAPshots at current.freebsd.org shut down for now. Cc: current@FreeBSD.ORG Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >> I would suggest you make a mount option for it so you can decide for >> other filesystems if you want clustering or not. > >I don't have enough time, so what I can do now is to add vnconfig >option to disable clustering. (I also think mount option is good >mechanism and I need it to use union fs safely.) There's always time to do it again? :-) I think this has a major problem - it disables clustering in the wrong layer. I/O to the vn file must be clustered for efficiency. The mount option would automatically apply to the correct layer. >diff -arcN sys.old/gnu/ext2fs/ext2_readwrite.c sys/gnu/ext2fs/ext2_readwrite.c >*** sys.old/gnu/ext2fs/ext2_readwrite.c Wed Sep 24 20:27:46 1997 >--- sys/gnu/ext2fs/ext2_readwrite.c Wed Sep 24 22:44:01 1997 >*************** >*** 112,118 **** > > if (lblktosize(fs, nextlbn) >= ip->i_size) > error = bread(vp, lbn, size, NOCRED, &bp); >! else if (doclusterread) > error = cluster_read(vp, > ip->i_size, lbn, size, NOCRED, &bp); > else if (lbn - 1 == vp->v_lastr) { >--- 112,118 ---- > > if (lblktosize(fs, nextlbn) >= ip->i_size) > error = bread(vp, lbn, size, NOCRED, &bp); >! else if (doclusterread && !(vp->v_flag & VNOCLUSTER)) > error = cluster_read(vp, > ip->i_size, lbn, size, NOCRED, &bp); > else if (lbn - 1 == vp->v_lastr) { For the current version, I think the test needs to be something like else if (doclusterread && !(vp->v_mount->mnt_vnodecovered & VNOCLUSTER)) Perhaps the mount-option version should eliminate doclusterread and doclusterwrite (this requires a mount option for each) and move the tests into cluster_read() and cluster_write(). >diff -arcN sys.old/sys/vnode.h sys/sys/vnode.h >*** sys.old/sys/vnode.h Wed Sep 24 20:26:36 1997 >--- sys/sys/vnode.h Wed Sep 24 22:37:44 1997 >*************** >*** 111,129 **** > /* > * Vnode flags. > */ >! #define VROOT 0x0001 /* root of its file system */ >! #define VTEXT 0x0002 /* vnode is a pure text prototype */ >! #define VSYSTEM 0x0004 /* vnode being used by kernel */ >! #define VOLOCK 0x0008 /* vnode is locked waiting for an object */ >! #define VOWANT 0x0010 /* a process is waiting for VOLOCK */ >! #define VXLOCK 0x0100 /* vnode is locked to change underlying type */ >! #define VXWANT 0x0200 /* process is waiting for vnode */ >! #define VBWAIT 0x0400 /* waiting for output to complete */ >! #define VALIASED 0x0800 /* vnode has an alias */ >! #define VDIROP 0x1000 /* LFS: vnode is involved in a directory op */ >! #define VVMIO 0x2000 /* VMIO flag */ >! #define VNINACT 0x4000 /* LFS: skip ufs_inactive() in lfs_vunref */ >! #define VAGE 0x8000 /* Insert vnode at head of free list */ > > /* > * Vnode attributes. A field value of VNOVAL represents a field whose value >--- 111,130 ---- > /* > * Vnode flags. > */ >! #define VROOT 0x00001 /* root of its file system */ >! #define VTEXT 0x00002 /* vnode is a pure text prototype */ >! #define VSYSTEM 0x00004 /* vnode being used by kernel */ >! #define VOLOCK 0x00008 /* vnode is locked waiting for an object */ >! #define VOWANT 0x00010 /* a process is waiting for VOLOCK */ >! #define VXLOCK 0x00100 /* vnode is locked to change underlying type */ >! #define VXWANT 0x00200 /* process is waiting for vnode */ >! #define VBWAIT 0x00400 /* waiting for output to complete */ >! #define VALIASED 0x00800 /* vnode has an alias */ >! #define VDIROP 0x01000 /* LFS: vnode is involved in a directory op */ >! #define VVMIO 0x02000 /* VMIO flag */ >! #define VNINACT 0x04000 /* LFS: skip ufs_inactive() in lfs_vunref */ >! #define VAGE 0x08000 /* Insert vnode at head of free list */ >! #define VNOCLUSTER 0x10000 /* disable cluster read / write */ > > /* > * Vnode attributes. A field value of VNOVAL represents a field whose value I don't like large essentially-null changes just to keep 0x numbers lined up. Rev.1.49 has already added another digit to all the numbers. You would need to change them all again. Bruce From owner-freebsd-current Thu Sep 25 08:34:10 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id IAA22694 for current-outgoing; Thu, 25 Sep 1997 08:34:10 -0700 (PDT) Received: from gneiss.eps.nagoya-u.ac.jp (gneiss.eps.nagoya-u.ac.jp [133.6.57.99]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id IAA22684 for ; Thu, 25 Sep 1997 08:33:51 -0700 (PDT) Received: from marble.eps.nagoya-u.ac.jp (localhost [127.0.0.1]) by gneiss.eps.nagoya-u.ac.jp (8.8.7/3.5Wpl3) with ESMTP id AAA07045; Fri, 26 Sep 1997 00:26:11 +0900 (JST) Message-Id: <199709251526.AAA07045@gneiss.eps.nagoya-u.ac.jp> To: bde@zeta.org.au Cc: current@FreeBSD.ORG Subject: Re: Daily SNAPshots at current.freebsd.org shut down for now. From: KATO Takenori In-Reply-To: Your message of "Thu, 25 Sep 1997 23:11:44 +1000" References: <199709251311.XAA16478@godzilla.zeta.org.au> X-Mailer: Mew version 1.70 on Emacs 19.28.1 / Mule 2.3 X-PGP-Fingerprint: 03 72 85 36 62 46 23 03 52 B1 10 22 44 10 0D 9E Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Fri, 26 Sep 1997 00:26:11 +0900 Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > The mount option would automatically apply to the correct layer. Ok, I will add preliminary path bellow. > Perhaps the mount-option version should eliminate doclusterread and > doclusterwrite (this requires a mount option for each) and move the > tests into cluster_read() and cluster_write(). I think doclusterreadn and doclusterwrite is useful. IMO, we should not expect every user always mount with correct mount-option. If doclusterread and doclusterwrite can be controled with sysctl and root disables them, non-root user cannot enable them. ---------- BEGIN ---------- *** sys/sys/mount.h.ORIG Thu Sep 25 23:33:00 1997 --- sys/sys/mount.h Fri Sep 26 00:00:35 1997 *************** *** 166,171 **** --- 166,172 ---- #define MNT_UNION 0x00000020 /* union with underlying filesystem */ #define MNT_ASYNC 0x00000040 /* file system written asynchronously */ #define MNT_NOATIME 0x10000000 /* Disable update of file access times */ + #define MNT_NOCLUSTER 0x40000000 /* Disable cluster read and write */ /* * exported mount flags. *** sys/kern/vfs_syscalls.c.ORIG Thu Sep 25 23:57:47 1997 --- sys/kern/vfs_syscalls.c Fri Sep 26 00:01:49 1997 *************** *** 253,262 **** else if (mp->mnt_flag & MNT_RDONLY) mp->mnt_flag |= MNT_WANTRDWR; mp->mnt_flag &=~ (MNT_NOSUID | MNT_NOEXEC | MNT_NODEV | ! MNT_SYNCHRONOUS | MNT_UNION | MNT_ASYNC | MNT_NOATIME); mp->mnt_flag |= SCARG(uap, flags) & (MNT_NOSUID | MNT_NOEXEC | MNT_NODEV | MNT_SYNCHRONOUS | MNT_UNION | MNT_ASYNC | MNT_FORCE | ! MNT_NOATIME); /* * Mount the filesystem. */ --- 253,263 ---- else if (mp->mnt_flag & MNT_RDONLY) mp->mnt_flag |= MNT_WANTRDWR; mp->mnt_flag &=~ (MNT_NOSUID | MNT_NOEXEC | MNT_NODEV | ! MNT_SYNCHRONOUS | MNT_UNION | MNT_ASYNC | MNT_NOATIME | ! MNT_NOCLUSTER); mp->mnt_flag |= SCARG(uap, flags) & (MNT_NOSUID | MNT_NOEXEC | MNT_NODEV | MNT_SYNCHRONOUS | MNT_UNION | MNT_ASYNC | MNT_FORCE | ! MNT_NOATIME | MNT_NOCLUSTER); /* * Mount the filesystem. */ *** sys/ufs/ufs/ufs_readwrite.c.ORIG Fri Sep 26 00:18:23 1997 --- sys/ufs/ufs/ufs_readwrite.c Fri Sep 26 00:22:16 1997 *************** *** 123,129 **** #else if (lblktosize(fs, nextlbn) >= ip->i_size) error = bread(vp, lbn, size, NOCRED, &bp); ! else if (ffs_doclusterread) error = cluster_read(vp, ip->i_size, lbn, size, NOCRED, uio->uio_resid, seqcount, &bp); else if (lbn - 1 == vp->v_lastr) { --- 123,130 ---- #else if (lblktosize(fs, nextlbn) >= ip->i_size) error = bread(vp, lbn, size, NOCRED, &bp); ! else if (ffs_doclusterread && ! !(vp->v_mount->mnt_flag & MNT_NOCLUSTER)) error = cluster_read(vp, ip->i_size, lbn, size, NOCRED, uio->uio_resid, seqcount, &bp); else if (lbn - 1 == vp->v_lastr) { *************** *** 281,287 **** if (ioflag & IO_SYNC) { (void)bwrite(bp); } else if (xfersize + blkoffset == fs->fs_bsize) { ! if (ffs_doclusterwrite) { bp->b_flags |= B_CLUSTEROK; cluster_write(bp, ip->i_size); } else { --- 282,289 ---- if (ioflag & IO_SYNC) { (void)bwrite(bp); } else if (xfersize + blkoffset == fs->fs_bsize) { ! if (ffs_doclusterwrite && ! !(vp->v_mount->mnt_flag & MNT_NOCLUSTER)) { bp->b_flags |= B_CLUSTEROK; cluster_write(bp, ip->i_size); } else { ---------- END ---------- ---- KATO Takenori Dept. Earth Planet. Sci., Nagoya Univ., Nagoya, 464-01, Japan PGP public key: finger kato@eclogite.eps.nagoya-u.ac.jp ------------------- Powered by FreeBSD(98) ------------------- From owner-freebsd-current Thu Sep 25 08:50:59 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id IAA23754 for current-outgoing; Thu, 25 Sep 1997 08:50:59 -0700 (PDT) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id IAA23747 for ; Thu, 25 Sep 1997 08:50:54 -0700 (PDT) Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.5/8.6.9) id BAA22623; Fri, 26 Sep 1997 01:50:08 +1000 Date: Fri, 26 Sep 1997 01:50:08 +1000 From: Bruce Evans Message-Id: <199709251550.BAA22623@godzilla.zeta.org.au> To: bde@zeta.org.au, kato@migmatite.eps.nagoya-u.ac.jp Subject: Re: Daily SNAPshots at current.freebsd.org shut down for now. Cc: current@FreeBSD.ORG Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >> Perhaps the mount-option version should eliminate doclusterread and >> doclusterwrite (this requires a mount option for each) and move the >> tests into cluster_read() and cluster_write(). > >I think doclusterreadn and doclusterwrite is useful. IMO, we should >not expect every user always mount with correct mount-option. If I think they aren't useful except for debugging. Having 2 ways to control clustering is 2 too many for a production system :-) (non-clustering for /dev/vn must be forced independently of any mount options and sysctls, except possibly for debugging). Bruce From owner-freebsd-current Thu Sep 25 08:57:50 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id IAA24284 for current-outgoing; Thu, 25 Sep 1997 08:57:50 -0700 (PDT) Received: from ns.mt.sri.com (SRI-56K-FR.mt.net [206.127.65.42]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id IAA24277 for ; Thu, 25 Sep 1997 08:57:44 -0700 (PDT) Received: from rocky.mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.8.7/8.8.7) with ESMTP id JAA10116; Thu, 25 Sep 1997 09:57:43 -0600 (MDT) Received: (from nate@localhost) by rocky.mt.sri.com (8.7.5/8.7.3) id JAA18142; Thu, 25 Sep 1997 09:57:41 -0600 (MDT) Date: Thu, 25 Sep 1997 09:57:41 -0600 (MDT) Message-Id: <199709251557.JAA18142@rocky.mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Greg Lehey Cc: FreeBSD current users Subject: Re: find still broken - is this only happening to me? In-Reply-To: <19970925191804.00720@lemis.com> References: <19970925191804.00720@lemis.com> X-Mailer: VM 6.29 under 19.15 XEmacs Lucid Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > I reported this a couple of weeks ago. Has nobody else experienced it? > > $ find /sys -follow -name "*.[csh]" | xargs grep ENFILE|less > ): no beginning '(' Works for me (w/out less, since I don't have it installed). No errors. I even tried creating a file named ')', and still no errors. (This is on a -current system about 4 hours old. :) Nate From owner-freebsd-current Thu Sep 25 09:15:42 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id JAA25227 for current-outgoing; Thu, 25 Sep 1997 09:15:42 -0700 (PDT) Received: from gratis.grondar.za (gratis.grondar.za [196.7.18.133]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id JAA25216 for ; Thu, 25 Sep 1997 09:15:30 -0700 (PDT) Received: from greenpeace.grondar.za (greenpeace.grondar.za [196.7.18.132]) by gratis.grondar.za (8.8.7/8.8.7) with ESMTP id SAA07327; Thu, 25 Sep 1997 18:15:48 +0200 (SAT) Received: from greenpeace.grondar.za (localhost [127.0.0.1]) by greenpeace.grondar.za (8.8.7/8.8.7) with ESMTP id SAA04793; Thu, 25 Sep 1997 18:15:37 +0200 (SAT) Message-Id: <199709251615.SAA04793@greenpeace.grondar.za> X-Mailer: exmh version 2.0zeta 7/24/97 To: Nate Williams cc: Greg Lehey , FreeBSD current users Subject: Re: find still broken - is this only happening to me? Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 25 Sep 1997 18:15:30 +0200 From: Mark Murray Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Nate Williams wrote: > > I reported this a couple of weeks ago. Has nobody else experienced it? > > > > $ find /sys -follow -name "*.[csh]" | xargs grep ENFILE|less > > ): no beginning '(' > > Works for me (w/out less, since I don't have it installed). No errors. This chap (Greg?) most likely has a funny file somewhere. Make the command line: $ find /sys -follow -name '*.[csh]' | xargs grep ENFILE|less (singe quotes, not double), and it should work. The *.[csh] is being allowed to glob by the "". M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org From owner-freebsd-current Thu Sep 25 09:46:39 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id JAA27689 for current-outgoing; Thu, 25 Sep 1997 09:46:39 -0700 (PDT) Received: from gneiss.eps.nagoya-u.ac.jp (gneiss.eps.nagoya-u.ac.jp [133.6.57.99]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id JAA27672 for ; Thu, 25 Sep 1997 09:46:31 -0700 (PDT) Received: from marble.eps.nagoya-u.ac.jp (localhost [127.0.0.1]) by gneiss.eps.nagoya-u.ac.jp (8.8.7/3.5Wpl3) with ESMTP id BAA07216; Fri, 26 Sep 1997 01:45:50 +0900 (JST) Message-Id: <199709251645.BAA07216@gneiss.eps.nagoya-u.ac.jp> To: bde@zeta.org.au Cc: current@FreeBSD.ORG Subject: Re: Daily SNAPshots at current.freebsd.org shut down for now. From: KATO Takenori In-Reply-To: Your message of "Fri, 26 Sep 1997 01:50:08 +1000" References: <199709251550.BAA22623@godzilla.zeta.org.au> X-Mailer: Mew version 1.70 on Emacs 19.28.1 / Mule 2.3 X-PGP-Fingerprint: 03 72 85 36 62 46 23 03 52 B1 10 22 44 10 0D 9E Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Fri, 26 Sep 1997 01:45:50 +0900 Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > clustering is 2 too many for a production system :-) (non-clustering for > /dev/vn must be forced independently of any mount options and sysctls, > except possibly for debugging). How does mount() in vfs_syscall.c know special device is /dev/vn? When mount() can know specical device is /dev/vn, then if (special device is /dev/vn) mp->mnt_flag |= MNT_NOCLUSTER; works, and doclusterread and doclusterwrite can be eliminated. ---- KATO Takenori Dept. Earth Planet. Sci., Nagoya Univ., Nagoya, 464-01, Japan PGP public key: finger kato@eclogite.eps.nagoya-u.ac.jp ------------------- Powered by FreeBSD(98) ------------------- From owner-freebsd-current Thu Sep 25 11:13:19 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id LAA02881 for current-outgoing; Thu, 25 Sep 1997 11:13:19 -0700 (PDT) Received: from news1.gtn.com (news1.gtn.com [194.77.0.15]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id LAA02865 for ; Thu, 25 Sep 1997 11:13:10 -0700 (PDT) Received: (from uucp@localhost) by news1.gtn.com (8.8.6/8.8.6) with UUCP id UAA03550; Thu, 25 Sep 1997 20:00:26 +0200 (MET DST) Received: (from andreas@localhost) by klemm.gtn.com (8.8.7/8.8.7) id TAA13717; Thu, 25 Sep 1997 19:47:59 +0200 (CEST) Message-ID: <19970925194759.09823@klemm.gtn.com> Date: Thu, 25 Sep 1997 19:47:59 +0200 From: Andreas Klemm To: Mark Murray Cc: Nate Williams , Greg Lehey , FreeBSD current users Subject: Re: find still broken - is this only happening to me? References: <199709251615.SAA04793@greenpeace.grondar.za> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.81 In-Reply-To: <199709251615.SAA04793@greenpeace.grondar.za>; from Mark Murray on Thu, Sep 25, 1997 at 06:15:30PM +0200 X-Disclaimer: A free society is one where it is safe to be unpopular X-Operating-System: FreeBSD 3.0-CURRENT SMP Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Thu, Sep 25, 1997 at 06:15:30PM +0200, Mark Murray wrote: > Nate Williams wrote: > > > I reported this a couple of weeks ago. Has nobody else experienced it? > > > > > > $ find /sys -follow -name "*.[csh]" | xargs grep ENFILE|less > > > ): no beginning '(' > > > > Works for me (w/out less, since I don't have it installed). No errors. > > This chap (Greg?) most likely has a funny file somewhere. Make the command > line: > $ find /sys -follow -name '*.[csh]' | xargs grep ENFILE|less > > (singe quotes, not double), and it should work. The *.[csh] is being > allowed to glob by the "". I had such strange messages with a certain language environment. I suggest trying this command with /bin/csh and a standard root environment. Just for reference ! -- Andreas Klemm | klemm.gtn.com - powered by Symmetric MultiProcessor FreeBSD http://www.freebsd.org/~fsmp/SMP/SMP.html http://www.freebsd.org/~fsmp/SMP/benches.html From owner-freebsd-current Thu Sep 25 11:16:36 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id LAA03177 for current-outgoing; Thu, 25 Sep 1997 11:16:36 -0700 (PDT) Received: from roguetrader.com (brandon@cold.org [206.81.134.103]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id LAA03166 for ; Thu, 25 Sep 1997 11:16:30 -0700 (PDT) Received: from localhost (brandon@localhost) by roguetrader.com (8.8.5/8.8.5) with SMTP id MAA11146 for ; Thu, 25 Sep 1997 12:17:08 -0600 (MDT) Date: Thu, 25 Sep 1997 12:17:08 -0600 (MDT) From: Brandon Gillespie To: freebsd-current@freebsd.org Subject: where to place new crypt() files? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Currently, we maintain two seperate copies of the crypt library files, specifically at: Non-DES (i.e. MD5): lib/libcrypt/Makefile lib/libcrypt/crypt.c With-DES: secure/src/lib/libcrypt/Makefile secure/src/lib/libcrypt/README secure/src/lib/libcrypt/README.FreeBSD secure/src/lib/libcrypt/crypt-md5.c secure/src/lib/libcrypt/crypt.3 secure/src/lib/libcrypt/crypt.c secure/src/lib/libcrypt/test/ This is mainly because in the current code, the actual crypt() function varies. My new code wraps this, however, and calls sub-functions based off which crypt modules are available (i.e. crypt_des(), crypt_md5(), etc), so the tree is now: lib/libcrypt/Makefile lib/libcrypt/README lib/libcrypt/arc4random.3 lib/libcrypt/arc4random.c lib/libcrypt/blf.h lib/libcrypt/blowfish.3 lib/libcrypt/blowfish.c lib/libcrypt/crypt-blf.c lib/libcrypt/crypt-md5.c lib/libcrypt/crypt-shs.c lib/libcrypt/crypt.3 lib/libcrypt/crypt.c lib/libcrypt/crypt.h lib/libcrypt/des.3 lib/libcrypt/shs.3 lib/libcrypt/shs.c lib/libcrypt/shs.h lib/libcrypt/test/ And the file: lib/libcrypt/crypt-des.c In addition to the -DDES_CRYPT flag to make is all that is required to include DES crypt in the brew. I really don't think duplicating all of the above files in both lib/libcrypt and secure/src/lib/libcrypt is a good idea... Any suggestions? The cleanest solution (imho) would be to have secure/src/lib/libcrypt/[Makefile|crypt-des.c], and have the Makefile create a softlink from secure/src/lib/libcrypt/crypt-des.c to lib/libcrypt, then move to the lib/libcrypt directory and 'make -DDES_CRYPT' (the makefile in lib/libcrypt includes crypt-des.c and builds libdescrypt if the DES_CRYPT option is specified, otherwise it excludes crypt-des.c and builds libscrypt instead). -Brandon Gillespie (also for note... after I wrap this up I may go back and move the blowfish and shs code outside of the crypt library) From owner-freebsd-current Thu Sep 25 11:56:43 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id LAA05129 for current-outgoing; Thu, 25 Sep 1997 11:56:43 -0700 (PDT) Received: from gratis.grondar.za (gratis.grondar.za [196.7.18.133]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id LAA05104 for ; Thu, 25 Sep 1997 11:56:26 -0700 (PDT) Received: from greenpeace.grondar.za (greenpeace.grondar.za [196.7.18.132]) by gratis.grondar.za (8.8.7/8.8.7) with ESMTP id UAA07638; Thu, 25 Sep 1997 20:56:29 +0200 (SAT) Received: from greenpeace.grondar.za (localhost [127.0.0.1]) by greenpeace.grondar.za (8.8.7/8.8.7) with ESMTP id UAA09180; Thu, 25 Sep 1997 20:56:18 +0200 (SAT) Message-Id: <199709251856.UAA09180@greenpeace.grondar.za> X-Mailer: exmh version 2.0zeta 7/24/97 To: Brandon Gillespie cc: freebsd-current@FreeBSD.ORG Subject: Re: where to place new crypt() files? Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 25 Sep 1997 20:56:11 +0200 From: Mark Murray Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Brandon Gillespie wrote: > lib/libcrypt/blowfish.c Isn't Blowfish export-restricted? > And the file: > > lib/libcrypt/crypt-des.c Also? > In addition to the -DDES_CRYPT flag to make is all that is required to > include DES crypt in the brew. I really don't think duplicating all of > the above files in both lib/libcrypt and secure/src/lib/libcrypt is a good > idea... Good point. > Any suggestions? The cleanest solution (imho) would be to have > secure/src/lib/libcrypt/[Makefile|crypt-des.c], and have the Makefile > create a softlink from secure/src/lib/libcrypt/crypt-des.c to > lib/libcrypt, then move to the lib/libcrypt directory and 'make > -DDES_CRYPT' Symlinks are not a good idea. Why do you not (ab)use .PATH: to find either the real or failing that a dummy crypt-des.c routine? M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org From owner-freebsd-current Thu Sep 25 12:32:40 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id MAA07713 for current-outgoing; Thu, 25 Sep 1997 12:32:40 -0700 (PDT) Received: from bob.scl.ameslab.gov (bob.scl.ameslab.gov [147.155.137.254]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id MAA07699 for ; Thu, 25 Sep 1997 12:32:36 -0700 (PDT) Received: from bob.scl.ameslab.gov (localhost [127.0.0.1]) by bob.scl.ameslab.gov (8.8.7/8.8.5) with ESMTP id OAA09328 for ; Thu, 25 Sep 1997 14:33:25 -0500 (CDT) Message-Id: <199709251933.OAA09328@bob.scl.ameslab.gov> X-Mailer: exmh version 2.0zeta 7/24/97 To: current@FreeBSD.ORG Subject: TCP timers (Was: Re: new timeout routines) Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 25 Sep 1997 14:33:25 -0500 From: Chris Csanady Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Now that we have a scalable timer implementation, perhaps it is time to replace TCP's fast and slow timeout queues with regular timers.. Is anyone interested in doing this? If not, it seems fairly straight forward, and I might have a stab at it when time permits. Chris Csanady From owner-freebsd-current Thu Sep 25 12:32:42 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id MAA07733 for current-outgoing; Thu, 25 Sep 1997 12:32:42 -0700 (PDT) Received: from papagaio.voga.com.br (papagaio.voga.com.br [200.239.39.2]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id MAA07701 for ; Thu, 25 Sep 1997 12:32:37 -0700 (PDT) Received: by papagaio.voga.com.br(Lotus SMTP MTA v1.06 (346.7 3-18-1997)) id 0325651D.006BCB42 ; Thu, 25 Sep 1997 16:37:23 -0300 X-Lotus-FromDomain: VOGA From: "Daniel Sobral" To: current@FreeBSD.ORG Message-ID: <0325651D.006B33EB.00@papagaio.voga.com.br> Date: Thu, 25 Sep 1997 16:33:51 -0300 Subject: The 3.0-970920-SNAP CD has been canceled Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Sigh... I happen to slip on current reading a few days and... Jordan, the last snapshot is way too old, and not having a reasonably recent snapshot on CD can be very inconvenient. So... why not making an *OLDER* snap? It seems snaps from the beginning of this month are reasonably ok, couldn't you make CDs out of one of them? From owner-freebsd-current Thu Sep 25 13:00:36 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id NAA09597 for current-outgoing; Thu, 25 Sep 1997 13:00:36 -0700 (PDT) Received: from roguetrader.com (brandon@cold.org [206.81.134.103]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id NAA09588 for ; Thu, 25 Sep 1997 13:00:28 -0700 (PDT) Received: from localhost (brandon@localhost) by roguetrader.com (8.8.5/8.8.5) with SMTP id OAA11690; Thu, 25 Sep 1997 14:01:14 -0600 (MDT) Date: Thu, 25 Sep 1997 14:01:13 -0600 (MDT) From: Brandon Gillespie To: Mark Murray cc: freebsd-current@FreeBSD.ORG Subject: Re: where to place new crypt() files? In-Reply-To: <199709251856.UAA09180@greenpeace.grondar.za> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Thu, 25 Sep 1997, Mark Murray wrote: > Brandon Gillespie wrote: > > lib/libcrypt/blowfish.c > > Isn't Blowfish export-restricted? I dont believe so, but I am still trying to dig up concrete information on it and SHS (any help would be appreciated :) > > And the file: > > > > lib/libcrypt/crypt-des.c > > Also? Yes, it is.. I was just including it in the same listing. > > In addition to the -DDES_CRYPT flag to make is all that is required to > > include DES crypt in the brew. I really don't think duplicating all of > > the above files in both lib/libcrypt and secure/src/lib/libcrypt is a good > > idea... > > Good point. > > > Any suggestions? The cleanest solution (imho) would be to have > > secure/src/lib/libcrypt/[Makefile|crypt-des.c], and have the Makefile > > create a softlink from secure/src/lib/libcrypt/crypt-des.c to > > lib/libcrypt, then move to the lib/libcrypt directory and 'make > > -DDES_CRYPT' > > Symlinks are not a good idea. Why do you not (ab)use .PATH: to find > either the real or failing that a dummy crypt-des.c routine? Hmm.... Actually, now that I look at your code again (as the makefile changes are yours--but I have rewritten/cleaned up most of the other code (again) since you last saw it) it looks as if this is what you _are_ doing... (I was just a mite bit thrown off somewhere... hrm...) *shrug* Ok, i'll look into that.. From owner-freebsd-current Thu Sep 25 13:23:10 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id NAA10750 for current-outgoing; Thu, 25 Sep 1997 13:23:10 -0700 (PDT) Received: from time.cdrom.com (root@time.cdrom.com [204.216.27.226]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id NAA10745 for ; Thu, 25 Sep 1997 13:23:06 -0700 (PDT) Received: from time.cdrom.com (jkh@localhost.cdrom.com [127.0.0.1]) by time.cdrom.com (8.8.7/8.6.9) with ESMTP id NAA03748; Thu, 25 Sep 1997 13:22:11 -0700 (PDT) To: "Daniel Sobral" cc: current@FreeBSD.ORG Subject: Re: The 3.0-970920-SNAP CD has been canceled In-reply-to: Your message of "Thu, 25 Sep 1997 16:33:51 -0300." <0325651D.006B33EB.00@papagaio.voga.com.br> Date: Thu, 25 Sep 1997 13:22:10 -0700 Message-ID: <3744.875218930@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Sorry, I've simply put this aside for now - I have way to much other work to do. As I said in my earlier email, we'll see about revisiting this in November or December. Jordan > Sigh... I happen to slip on current reading a few days and... > > Jordan, the last snapshot is way too old, and not having a reasonably > recent snapshot on CD can be very inconvenient. So... why not making an > *OLDER* snap? It seems snaps from the beginning of this month are > reasonably ok, couldn't you make CDs out of one of them? > > > From owner-freebsd-current Thu Sep 25 13:52:10 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id NAA12536 for current-outgoing; Thu, 25 Sep 1997 13:52:10 -0700 (PDT) Received: from implode.root.com (implode.root.com [198.145.90.17]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id NAA12523 for ; Thu, 25 Sep 1997 13:52:04 -0700 (PDT) Received: from implode.root.com (localhost [127.0.0.1]) by implode.root.com (8.8.5/8.8.5) with ESMTP id NAA15471; Thu, 25 Sep 1997 13:53:24 -0700 (PDT) Message-Id: <199709252053.NAA15471@implode.root.com> To: Chris Csanady cc: current@FreeBSD.ORG Subject: Re: TCP timers (Was: Re: new timeout routines) In-reply-to: Your message of "Thu, 25 Sep 1997 14:33:25 CDT." <199709251933.OAA09328@bob.scl.ameslab.gov> From: David Greenman Reply-To: dg@root.com Date: Thu, 25 Sep 1997 13:53:23 -0700 Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >Now that we have a scalable timer implementation, perhaps it is time >to replace TCP's fast and slow timeout queues with regular timers.. >Is anyone interested in doing this? If not, it seems fairly straight >forward, and I might have a stab at it when time permits. I've been thinking about this for about a year. Justin's changes don't have a significant impact on the planned way of dealing with delayed-acks. Basically, construct a del-ack queue, timestamp the PCB for 200ms into the future, and put it on the end of the del-ack queue. If the queue was previously empty, schedule a timeout for 200ms in the future. In the del-ack timeout/timer processing function, start at the head of the del-ack queue and send acks to all connections that are >= the current time. When an entry is encountered that isn't old enough yet, calculate a proper timeout delta, schedule the timeout, and exit. This scheme gives del-ack accuracy to 200ms + 1tick (as opposed to the old scheme's variable 0-200ms), and gets rid of the lengthy, non-scaling linear search of the old scheme. This particular implementation takes advantage of the fixed-interval nature of the fastimeo timer which allows us to easily create a time sorted list as well as only needing a single timeout entry in the system's timer queues. I haven't thought about the slow timeout yet...that might be a bit more difficult problem to solve. -DG David Greenman Core-team/Principal Architect, The FreeBSD Project From owner-freebsd-current Thu Sep 25 14:20:23 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id OAA14389 for current-outgoing; Thu, 25 Sep 1997 14:20:23 -0700 (PDT) Received: from Vorlon.odc.net (nwestfal@Vorlon.odc.net [207.137.42.6]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id OAA14382 for ; Thu, 25 Sep 1997 14:20:19 -0700 (PDT) Received: from localhost (nwestfal@localhost) by Vorlon.odc.net (8.8.5/8.8.5) with SMTP id OAA12719; Thu, 25 Sep 1997 14:18:33 -0700 Date: Thu, 25 Sep 1997 14:18:33 -0700 (PDT) From: Neal Westfall To: "Jordan K. Hubbard" cc: Daniel Sobral , current@FreeBSD.ORG Subject: Re: The 3.0-970920-SNAP CD has been canceled In-Reply-To: <3744.875218930@time.cdrom.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Does anyone know when the last good snapshot was? I want to install a fairly current snapshot on my machine that is newer than the last "official" snapshot. Neal Westfall nwestfal@odc.net On Thu, 25 Sep 1997, Jordan K. Hubbard wrote: > Sorry, I've simply put this aside for now - I have way to much > other work to do. As I said in my earlier email, we'll see about > revisiting this in November or December. > > Jordan > > > Sigh... I happen to slip on current reading a few days and... > > > > Jordan, the last snapshot is way too old, and not having a reasonably > > recent snapshot on CD can be very inconvenient. So... why not making an > > *OLDER* snap? It seems snaps from the beginning of this month are > > reasonably ok, couldn't you make CDs out of one of them? > > > > > > > From owner-freebsd-current Thu Sep 25 14:24:32 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id OAA14603 for current-outgoing; Thu, 25 Sep 1997 14:24:32 -0700 (PDT) Received: from whistle.com (s205m131.whistle.com [207.76.205.131]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id OAA14597 for ; Thu, 25 Sep 1997 14:24:29 -0700 (PDT) Received: (from smap@localhost) by whistle.com (8.7.5/8.6.12) id OAA09426 for ; Thu, 25 Sep 1997 14:23:53 -0700 (PDT) Received: from bubba.whistle.com(207.76.205.7) by whistle.com via smap (V1.3) id sma009422; Thu Sep 25 14:23:35 1997 Received: (from archie@localhost) by bubba.whistle.com (8.8.5/8.6.12) id OAA18665 for current@FreeBSD.ORG; Thu, 25 Sep 1997 14:23:35 -0700 (PDT) From: Archie Cobbs Message-Id: <199709252123.OAA18665@bubba.whistle.com> Subject: Re: timeout management (was: Re: cvs commit: ...) In-Reply-To: <199709242227.PAA17373@bubba.whistle.com> from Archie Cobbs at "Sep 24, 97 03:27:07 pm" To: current@FreeBSD.ORG Date: Thu, 25 Sep 1997 14:23:35 -0700 (PDT) X-Mailer: ELM [version 2.4ME+ PL31 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > Another algorithm that Julian and I discussed the other day has > > these properties: > > > > FUNCTION TIMING (amortized) > > add new timeout O(1) > > check for timeout O(1) > > remove a timeout O(1) (requires a handle) > > process one timeout O(lg T) for T = number of ticks alive > > > > That is, if a timeout event lives for T ticks (whether it's cancelled > > or expires after T ticks), it requires O(lg T) total work. > > > > Therefore, any event that is cancelled before 1/2 of it's timeout > > period has expired only requires O(1) work. > > Oops.. what I meant was that if a timeout event was scheduled for > T ticks, and it lives for R ticks, then the amount of work spent > on the event is O( lg T ) if R == T, else O( lg T - lg (T - R) ) > (which makes that last sentence true again :-). (If anyone is still interested...) It occurs to me that if a function can tolerate a large granularity, it would be easy to take advantage of that in this algorithm. Just define T' to be T/G, where T is the (original) total number of ticks, and G is the maximum inaccurracy (measured in ticks) that the function can tolerate. Then you do only O( lg T' ) work per event. To acomplish this, when a timer event reaches the point at which the time remaining is less than G, you simply make the event happen immediately. -Archie ___________________________________________________________________________ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com From owner-freebsd-current Thu Sep 25 14:24:54 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id OAA14640 for current-outgoing; Thu, 25 Sep 1997 14:24:54 -0700 (PDT) Received: from alpha.xerox.com (alpha.Xerox.COM [13.1.64.93]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id OAA14632 for ; Thu, 25 Sep 1997 14:24:51 -0700 (PDT) Received: from mailhost.sdsp.mc.xerox.com ([13.231.132.18]) by alpha.xerox.com with SMTP id <52475(5)>; Thu, 25 Sep 1997 14:24:16 PDT Received: from gnu.sdsp.mc.xerox.com (gnu.sdsp.mc.xerox.com [13.231.133.90]) by mailhost.sdsp.mc.xerox.com (8.8.5/8.8.5) with SMTP id RAA15295; Thu, 25 Sep 1997 17:23:13 -0400 (EDT) Received: by gnu.sdsp.mc.xerox.com (4.1/client-1.3) id AA29437; Thu, 25 Sep 97 17:23:12 EDT Message-Id: <9709252123.AA29437@gnu.sdsp.mc.xerox.com> To: S ren Schmidt Cc: freebsd-current@freebsd.org Subject: Re: running binutils 2.8, elf support? In-Reply-To: Your message of "Sat, 20 Sep 1997 13:39:35 PDT." <199709202039.WAA04762@sos.freebsd.dk> Date: Thu, 25 Sep 1997 14:23:11 PDT From: "Marty Leisner" Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > >Not really, but there is work underways to make FreeBSD convert >to ELF. Peter Wemm, John Poltra and Myself have been working on >this lately, and we have our test systems running all ELF, so >it not that far away... >It wont happen overnight though, as there are ALOT of details >that needs to be sorted out, before we attempt to "morphe" >-current into ELF. It will happen though, but I can't give you >a time frame just yet, neither how its going to be done. >I can however guarantie that we will go for a method, that >causes the least possible pain for our -current users, but >remember -current is bleeding edge, and sometimes the edge is >not exactly userfriendly... > >Please be patient, we are working on this as fast as we can... > >-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- >Søren Schmidt (sos@FreeBSD.org) FreeBSD Core Team > Even more code to hack -- will it ever end >.. Can you put a small, unstripped, statically linked binary someplace (like hello world?) I just want to see if the cross-binutils work... I would like a "development" version (not an installed version), so I can cross-compile... marty From owner-freebsd-current Thu Sep 25 15:15:16 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id PAA17225 for current-outgoing; Thu, 25 Sep 1997 15:15:16 -0700 (PDT) Received: from usr04.primenet.com (tlambert@usr04.primenet.com [206.165.6.204]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id PAA17220; Thu, 25 Sep 1997 15:15:07 -0700 (PDT) Received: (from tlambert@localhost) by usr04.primenet.com (8.8.5/8.8.5) id PAA03466; Thu, 25 Sep 1997 15:15:05 -0700 (MST) From: Terry Lambert Message-Id: <199709252215.PAA03466@usr04.primenet.com> Subject: IMPORTANT ANNOUNCEMENT TO ALL 'CURRENT' USERS... To: karl@Mcs.Net (Karl Denninger) Date: Thu, 25 Sep 1997 22:15:05 +0000 (GMT) Cc: hackers@FreeBSD.ORG, current@FreeBSD.ORG In-Reply-To: <19970925161021.36073@Mars.Mcs.Net> from "Karl Denninger" at Sep 25, 97 04:10:21 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Well, no one with actual power over the tree has made the necessary announcement, so I will: If you are trying to build -current, and you get this error: > loading kernel > isa.o: Undefined symbol `_isa_devtab_cam' referenced from text segment then you need to get the sources in /usr/src/usr.sbin/config, and rebuild "config". Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-current Thu Sep 25 15:16:36 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id PAA17340 for current-outgoing; Thu, 25 Sep 1997 15:16:36 -0700 (PDT) Received: from Kitten.mcs.com (Kitten.mcs.com [192.160.127.90]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id PAA17327; Thu, 25 Sep 1997 15:16:30 -0700 (PDT) Received: from Mars.mcs.net (karl@Mars.mcs.net [192.160.127.85]) by Kitten.mcs.com (8.8.5/8.8.2) with ESMTP id RAA02150; Thu, 25 Sep 1997 17:16:21 -0500 (CDT) Received: (from karl@localhost) by Mars.mcs.net (8.8.7/8.8.2) id RAA17175; Thu, 25 Sep 1997 17:16:20 -0500 (CDT) Message-ID: <19970925171616.26390@Mars.Mcs.Net> Date: Thu, 25 Sep 1997 17:16:16 -0500 From: Karl Denninger To: Terry Lambert Cc: Karl Denninger , hackers@FreeBSD.ORG, current@FreeBSD.ORG Subject: Re: IMPORTANT ANNOUNCEMENT TO ALL 'CURRENT' USERS... References: <19970925161021.36073@Mars.Mcs.Net> <199709252215.PAA03466@usr04.primenet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.64 In-Reply-To: <199709252215.PAA03466@usr04.primenet.com>; from Terry Lambert on Thu, Sep 25, 1997 at 10:15:05PM +0000 Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Thu, Sep 25, 1997 at 10:15:05PM +0000, Terry Lambert wrote: > Well, no one with actual power over the tree has made the necessary > announcement, so I will: > > > > If you are trying to build -current, and you get this error: > > > loading kernel > > isa.o: Undefined symbol `_isa_devtab_cam' referenced from text segment > > then you need to get the sources in /usr/src/usr.sbin/config, and > rebuild "config". > > > Terry Lambert > terry@lambert.org > --- > Any opinions in this posting are my own and not those of my present > or previous employers. Now you tell me :-) -- -- Karl Denninger (karl@MCS.Net)| MCSNet - Serving Chicagoland and Wisconsin http://www.mcs.net/~karl | T1's from $600 monthly to FULL DS-3 Service | NEW! K56Flex modem support is now available Voice: [+1 312 803-MCS1 x219]| 56kbps DIGITAL ISDN DOV on analog lines! Fax: [+1 312 803-4929] | 2 FULL DS-3 Internet links; 400Mbps B/W Internal From owner-freebsd-current Thu Sep 25 15:21:40 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id PAA17718 for current-outgoing; Thu, 25 Sep 1997 15:21:40 -0700 (PDT) Received: from roguetrader.com (brandon@cold.org [206.81.134.103]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id PAA17707 for ; Thu, 25 Sep 1997 15:21:35 -0700 (PDT) Received: from localhost (brandon@localhost) by roguetrader.com (8.8.5/8.8.5) with SMTP id QAA12734 for ; Thu, 25 Sep 1997 16:22:42 -0600 (MDT) Date: Thu, 25 Sep 1997 16:22:42 -0600 (MDT) From: Brandon Gillespie To: freebsd-current@freeBSD.org Subject: Re: where to place new crypt() files? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@freeBSD.org X-Loop: FreeBSD.org Precedence: bulk On Thu, 25 Sep 1997, Alex Nash wrote: > On Thu, 25 Sep 1997, Brandon Gillespie wrote: > > On Thu, 25 Sep 1997, Mark Murray wrote: > > > Brandon Gillespie wrote: > > > > lib/libcrypt/blowfish.c > > > > > > Isn't Blowfish export-restricted? > > > > I dont believe so, but I am still trying to dig up concrete information on > > it and SHS (any help would be appreciated :) > > According to http://www.counterpane.com/blowfish.html: [..] > Of course, the U.S. government will not allow Blowfish implementations > to be exported. (You may have some luck with a crippled 40-bit > version). Ach, damn, and I just finished crypt-blf.c... Suggestions? (damn damn damn) -Brandon From owner-freebsd-current Thu Sep 25 15:25:32 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id PAA17874 for current-outgoing; Thu, 25 Sep 1997 15:25:32 -0700 (PDT) Received: from usr04.primenet.com (tlambert@usr04.primenet.com [206.165.6.204]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id PAA17865 for ; Thu, 25 Sep 1997 15:25:24 -0700 (PDT) Received: (from tlambert@localhost) by usr04.primenet.com (8.8.5/8.8.5) id PAA04200; Thu, 25 Sep 1997 15:25:12 -0700 (MST) From: Terry Lambert Message-Id: <199709252225.PAA04200@usr04.primenet.com> Subject: Re: new timeout routines To: bde@zeta.org.au (Bruce Evans) Date: Thu, 25 Sep 1997 22:25:12 +0000 (GMT) Cc: bde@zeta.org.au, tlambert@primenet.com, current@FreeBSD.ORG, gibbs@plutotech.com, julian@whistle.com, nate@mt.sri.com In-Reply-To: <199709251144.VAA13138@godzilla.zeta.org.au> from "Bruce Evans" at Sep 25, 97 09:44:49 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > >> Now it is (almost) idempotent (N = 1 in the above), provided the > > This is correct. Idempotence (for an element x in a set with a binary > operation '*') is x*x = x. > > >Actually, this is "called reflexively". > > Wrong. Reflexivity (for an element x in a set with a binary relation > R to itself) is xRx. Heh. You omitted the provision stated in "provided the ...". The "called reflexively" referred to a one-to-one relationship between enqueing and dequeueing (or expiration) of timers. If you call untimeout more times than you call tiemout, then it's not "called reflexively". > > Date: 1870 > > : relating to or being a mathematical quantity which when applied to > > itself under a given binary operation (as multiplication) equals > > itself; also : relating to or being an operation under which a > > mathematical quantity is idempotent > > - idempotent noun > > This is correct :-). There must be a binary operation (i.e., a mapping > SxS -> S), not just a self-relation (i.e., a mapping SxS -> {0, 1}) to > define idempotence. Right. Yielding the identity set is not sufficient (ulnless what you are testing for idempotence is the identity set. 8-)). Give them a break, it was 1870. ;-). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-current Thu Sep 25 15:44:58 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id PAA18866 for current-outgoing; Thu, 25 Sep 1997 15:44:58 -0700 (PDT) Received: from usr04.primenet.com (tlambert@usr04.primenet.com [206.165.6.204]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id PAA18857 for ; Thu, 25 Sep 1997 15:44:44 -0700 (PDT) Received: (from tlambert@localhost) by usr04.primenet.com (8.8.5/8.8.5) id PAA05902; Thu, 25 Sep 1997 15:44:23 -0700 (MST) From: Terry Lambert Message-Id: <199709252244.PAA05902@usr04.primenet.com> Subject: Re: Daily SNAPshots at current.freebsd.org shut down for now. To: kato@migmatite.eps.nagoya-u.ac.jp (KATO Takenori) Date: Thu, 25 Sep 1997 22:44:22 +0000 (GMT) Cc: bde@zeta.org.au, current@FreeBSD.ORG In-Reply-To: <199709251645.BAA07216@gneiss.eps.nagoya-u.ac.jp> from "KATO Takenori" at Sep 26, 97 01:45:50 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > clustering is 2 too many for a production system :-) (non-clustering for > > /dev/vn must be forced independently of any mount options and sysctls, > > except possibly for debugging). > > How does mount() in vfs_syscall.c know special device is /dev/vn? It needs to be a per device flag, only asserted by the vn device. > When mount() can know specical device is /dev/vn, then > > if (special device is /dev/vn) > mp->mnt_flag |= MNT_NOCLUSTER; > > works, and doclusterread and doclusterwrite can be eliminated. The easiest place to add this would be as a falg bit in d_flags; put it under D_CHAIN in sys/disklabel.h: #define D_CHAIN 0x10 /* can do back-back transfers */ #define D_UNCLUSTERED 0x20 /* do not cluster{read|write} */ This flag is to be set in the disklabel (look how D_ECC is handled). Personally, I'd prefer to have it an attribute of the "real" device, but that would mean changing d_type into a bitmap, and adding a flag in sys/conf.h and changing the dev/vn/vn.c from: static struct bdevsw vn_bdevsw = { vnopen, vnclose, vnstrategy, vnioctl, /*15*/ vndump, vnsize, D_DISK, "vn", &vn_cdevsw, -1 }; to: static struct bdevsw vn_bdevsw = { vnopen, vnclose, vnstrategy, vnioctl, /*15*/ vndump, vnsize, D_DISK|D_UNCLUSTERED, "vn", &vn_cdevsw, -1 }; The alternative of adding: #define D_CCD 4 /* a concatenated disk*/ Would require too much overhead to check for a d_type of D_CCD in addition to a d_type of D_DISK literally *everywhere*. Either change would mean touching a lot more files than the disklabel hack... but it *is* a hack. On the other hand, Bruce did ask "there's time to go back and do it right later?" (or something to that effect), so he might champion a large change (bit checking of d_type instead of value checking, everywhere it's checked currently). Anyway, that'd be my preference for implementation. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-current Thu Sep 25 15:49:30 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id PAA19092 for current-outgoing; Thu, 25 Sep 1997 15:49:30 -0700 (PDT) Received: from usr04.primenet.com (tlambert@usr04.primenet.com [206.165.6.204]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id PAA19073 for ; Thu, 25 Sep 1997 15:49:16 -0700 (PDT) Received: (from tlambert@localhost) by usr04.primenet.com (8.8.5/8.8.5) id PAA06261; Thu, 25 Sep 1997 15:48:53 -0700 (MST) From: Terry Lambert Message-Id: <199709252248.PAA06261@usr04.primenet.com> Subject: Re: where to place new crypt() files? To: brandon@roguetrader.com (Brandon Gillespie) Date: Thu, 25 Sep 1997 22:48:34 +0000 (GMT) Cc: freebsd-current@FreeBSD.ORG In-Reply-To: from "Brandon Gillespie" at Sep 25, 97 12:17:08 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > Currently, we maintain two seperate copies of the crypt library files, > specifically at: [ ... ] > This is mainly because in the current code, the actual crypt() function > varies. My new code wraps this, however, and calls sub-functions based > off which crypt modules are available (i.e. crypt_des(), crypt_md5(), > etc), so the tree is now: [ ... ] > Any suggestions? Yes. You live in Logan, Utah, so you can't export it, so only the pieces not dealing with the crypt code itself can be exported. For the crypt code itself, this is not a useful change unless you can get the crypt people (in South Africa) to write to your framework. Crypt is such an archaic pain because it's impossible to really collaborate on it without breaking most countries munitions laws. 8-(. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-current Thu Sep 25 15:57:16 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id PAA19640 for current-outgoing; Thu, 25 Sep 1997 15:57:16 -0700 (PDT) Received: from usr04.primenet.com (tlambert@usr04.primenet.com [206.165.6.204]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id PAA19633 for ; Thu, 25 Sep 1997 15:57:11 -0700 (PDT) Received: (from tlambert@localhost) by usr04.primenet.com (8.8.5/8.8.5) id PAA06930; Thu, 25 Sep 1997 15:56:56 -0700 (MST) From: Terry Lambert Message-Id: <199709252256.PAA06930@usr04.primenet.com> Subject: Re: TCP timers (Was: Re: new timeout routines) To: dg@root.com Date: Thu, 25 Sep 1997 22:56:55 +0000 (GMT) Cc: ccsanady@bob.scl.ameslab.gov, current@FreeBSD.ORG In-Reply-To: <199709252053.NAA15471@implode.root.com> from "David Greenman" at Sep 25, 97 01:53:23 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > >Now that we have a scalable timer implementation, perhaps it is time > >to replace TCP's fast and slow timeout queues with regular timers.. > >Is anyone interested in doing this? If not, it seems fairly straight > >forward, and I might have a stab at it when time permits. > > I've been thinking about this for about a year. Justin's changes don't > have a significant impact on the planned way of dealing with delayed-acks. > Basically, construct a del-ack queue, timestamp the PCB for 200ms into > the future, and put it on the end of the del-ack queue. If the queue was > previously empty, schedule a timeout for 200ms in the future. In the > del-ack timeout/timer processing function, start at the head of the del-ack > queue and send acks to all connections that are >= the current time. When an > entry is encountered that isn't old enough yet, calculate a proper timeout > delta, schedule the timeout, and exit. > This scheme gives del-ack accuracy to 200ms + 1tick (as opposed to the > old scheme's variable 0-200ms), and gets rid of the lengthy, non-scaling > linear search of the old scheme. This particular implementation takes > advantage of the fixed-interval nature of the fastimeo timer which allows > us to easily create a time sorted list as well as only needing a single > timeout entry in the system's timer queues. > I haven't thought about the slow timeout yet...that might be a bit more > difficult problem to solve. This will increase the load on the timer code with a lot of 20 tick timers for a 100Hz softclock. Justin's code degrades under these conditions, making it less useful (a large net server will end up with nearly every bucket with multiple entries on any kind of link damage). If you do this, the changes Justin, Julian, I, and the rest discussed about a second head and migration of unsorted to sorted list entries when softclock hits a bucket with unsorted entries is probably a requirement. The design saves Justin from having his entries sorted in most cases, while allowing expiriation to be O(1). I haven't seen a formal layout of the design Archie Cobb said he discussed with Julian, so I can't comment on that, but it would be a good idea to consider all angles before making such a significant change to the networking code (one of BSD's shiny spots). Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-current Thu Sep 25 16:02:25 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id QAA20019 for current-outgoing; Thu, 25 Sep 1997 16:02:25 -0700 (PDT) Received: from implode.root.com (implode.root.com [198.145.90.17]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id QAA20013 for ; Thu, 25 Sep 1997 16:02:20 -0700 (PDT) Received: from implode.root.com (localhost [127.0.0.1]) by implode.root.com (8.8.5/8.8.5) with ESMTP id QAA17051; Thu, 25 Sep 1997 16:03:57 -0700 (PDT) Message-Id: <199709252303.QAA17051@implode.root.com> To: Terry Lambert cc: ccsanady@bob.scl.ameslab.gov, current@FreeBSD.ORG Subject: Re: TCP timers (Was: Re: new timeout routines) In-reply-to: Your message of "Thu, 25 Sep 1997 22:56:55 -0000." <199709252256.PAA06930@usr04.primenet.com> From: David Greenman Reply-To: dg@root.com Date: Thu, 25 Sep 1997 16:03:57 -0700 Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >This will increase the load on the timer code with a lot of 20 tick >timers for a 100Hz softclock. "A lot"? There will be exactly _one_. This is not a problem. Please read again what I wrote and tell me how I was unclear so that I don't make the same mistake in the future. -DG David Greenman Core-team/Principal Architect, The FreeBSD Project From owner-freebsd-current Thu Sep 25 16:17:12 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id QAA20995 for current-outgoing; Thu, 25 Sep 1997 16:17:12 -0700 (PDT) Received: from freebie.lemis.com (freebie.lemis.com [192.109.197.137]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id QAA20979 for ; Thu, 25 Sep 1997 16:17:05 -0700 (PDT) Received: (from grog@localhost) by freebie.lemis.com (8.8.7/8.8.5) id IAA06859; Fri, 26 Sep 1997 08:46:41 +0930 (CST) Message-ID: <19970926084641.09282@lemis.com> Date: Fri, 26 Sep 1997 08:46:41 +0930 From: Greg Lehey To: Mark Murray Cc: Nate Williams , FreeBSD current users Subject: Re: find still broken - is this only happening to me? References: <199709251615.SAA04793@greenpeace.grondar.za> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.81e In-Reply-To: <199709251615.SAA04793@greenpeace.grondar.za>; from Mark Murray on Thu, Sep 25, 1997 at 06:15:30PM +0200 Organisation: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8250 Fax: +61-8-8388-8250 Mobile: +61-41-739-7062 WWW-Home-Page: http://www.lemis.com/~grog Fight-Spam-Now: http://www.cauce.org Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Thu, Sep 25, 1997 at 06:15:30PM +0200, Mark Murray wrote: > Nate Williams wrote: >>> I reported this a couple of weeks ago. Has nobody else experienced it? >>> >>> $ find /sys -follow -name "*.[csh]" | xargs grep ENFILE|less >>> ): no beginning '(' >> >> Works for me (w/out less, since I don't have it installed). No errors. > > This chap (Greg?) most likely has a funny file somewhere. Make the command > line: > $ find /sys -follow -name '*.[csh]' | xargs grep ENFILE|less > > (singe quotes, not double), and it should work. The *.[csh] is being > allowed to glob by the "". Yes, that was my first assumption. Look at the name of the directory: it's the source tree. And GNU find works fine. I did this on numerous directories. OK, if nobody else has seen it, I'll follow it up and see what the problem really is. Watch this space. Greg From owner-freebsd-current Thu Sep 25 16:37:23 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id QAA22168 for current-outgoing; Thu, 25 Sep 1997 16:37:23 -0700 (PDT) Received: from ox.ismi.net (root@ox.ismi.net [206.31.56.6]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id QAA22163 for ; Thu, 25 Sep 1997 16:37:15 -0700 (PDT) Received: from rhiannon.dyn.ml.org (mrr@pm5-16.ismi.net [207.51.208.187]) by ox.ismi.net (8.6.9/8.6.9) with SMTP id TAA22123; Thu, 25 Sep 1997 19:34:42 -0400 Date: Thu, 25 Sep 1997 19:39:17 -0400 (EDT) From: "Michael R. Rudel" To: Terry Lambert cc: Brandon Gillespie , freebsd-current@FreeBSD.ORG Subject: Re: where to place new crypt() files? In-Reply-To: <199709252248.PAA06261@usr04.primenet.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Thu, 25 Sep 1997, Terry Lambert wrote: [ ... ] > > Yes. You live in Logan, Utah, so you can't export it, so only the > pieces not dealing with the crypt code itself can be exported. For > the crypt code itself, this is not a useful change unless you can > get the crypt people (in South Africa) to write to your framework. > > > Crypt is such an archaic pain because it's impossible to really > collaborate on it without breaking most countries munitions laws. > 8-(. > > > Terry Lambert > terry@lambert.org > --- > Any opinions in this posting are my own and not those of my present > or previous employers. > Correct me if I'm wrong, but doesn't the law say something like 'It's illegal to export, but once it's exported, it's legal to use outside the US and Canada?' I thought I saw a trend on here or some other OS-related mailing list a while ago about this sort of thing. -- Michael R. Rudel -=- FreeBSD: There are no limits -=- mrr@rhiannon.dyn.ml.org FreeBSD rhiannon.dyn.ml.org 3.0-CURRENT Rhiannon rings like a star through the night ... and you wouldn't you love to love her? Takes to the sky like a bird in flight ... and who will be her lover? - Rhiannon (Fleetwood Mac) From owner-freebsd-current Thu Sep 25 16:43:12 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id QAA22408 for current-outgoing; Thu, 25 Sep 1997 16:43:12 -0700 (PDT) Received: from thelab.hub.org (root@ppp-136.halifax-01.ican.net [206.231.248.136]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id QAA22401; Thu, 25 Sep 1997 16:43:03 -0700 (PDT) Received: from thelab.hub.org (scrappy@localhost [127.0.0.1]) by thelab.hub.org (8.8.7/8.8.2) with SMTP id UAA15817; Thu, 25 Sep 1997 20:41:59 -0300 (ADT) Date: Thu, 25 Sep 1997 20:41:59 -0300 (ADT) From: The Hermit Hacker To: Terry Lambert cc: Karl Denninger , hackers@FreeBSD.ORG, current@FreeBSD.ORG Subject: Re: IMPORTANT ANNOUNCEMENT TO ALL 'CURRENT' USERS... In-Reply-To: <199709252215.PAA03466@usr04.primenet.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Thu, 25 Sep 1997, Terry Lambert wrote: > Well, no one with actual power over the tree has made the necessary > announcement, so I will: > > > > If you are trying to build -current, and you get this error: > > > loading kernel > > isa.o: Undefined symbol `_isa_devtab_cam' referenced from text segment > > then you need to get the sources in /usr/src/usr.sbin/config, and > rebuild "config". Hrmmm...I always considered this to be "standard operating procedure" when upgrading my kernel: check to make sure config sources haven't changed *Shrug* Marc G. Fournier Systems Administrator @ hub.org primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org From owner-freebsd-current Thu Sep 25 17:02:54 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id RAA23400 for current-outgoing; Thu, 25 Sep 1997 17:02:54 -0700 (PDT) Received: from usr04.primenet.com (tlambert@usr04.primenet.com [206.165.6.204]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id RAA23377 for ; Thu, 25 Sep 1997 17:02:43 -0700 (PDT) Received: (from tlambert@localhost) by usr04.primenet.com (8.8.5/8.8.5) id RAA12137; Thu, 25 Sep 1997 17:02:36 -0700 (MST) From: Terry Lambert Message-Id: <199709260002.RAA12137@usr04.primenet.com> Subject: Re: TCP timers (Was: Re: new timeout routines) To: dg@root.com Date: Fri, 26 Sep 1997 00:02:35 +0000 (GMT) Cc: tlambert@primenet.com, ccsanady@bob.scl.ameslab.gov, current@FreeBSD.ORG In-Reply-To: <199709252303.QAA17051@implode.root.com> from "David Greenman" at Sep 25, 97 04:03:57 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > >This will increase the load on the timer code with a lot of 20 tick > >timers for a 100Hz softclock. > > "A lot"? There will be exactly _one_. This is not a problem. Please read > again what I wrote and tell me how I was unclear so that I don't make the > same mistake in the future. It was unclear that there would not be one per FIN_2_WAIT per socket; how do you plan to handle these timeouts to give one timer entry? Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-current Thu Sep 25 17:07:55 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id RAA23761 for current-outgoing; Thu, 25 Sep 1997 17:07:55 -0700 (PDT) Received: from pluto.plutotech.com (root@mail.plutotech.com [206.168.67.137]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id RAA23751 for ; Thu, 25 Sep 1997 17:07:49 -0700 (PDT) Received: from narnia.plutotech.com (narnia.plutotech.com [206.168.67.130]) by pluto.plutotech.com (8.8.5/8.8.5) with ESMTP id SAA29559; Thu, 25 Sep 1997 18:07:36 -0600 (MDT) Message-Id: <199709260007.SAA29559@pluto.plutotech.com> X-Mailer: exmh version 2.0zeta 7/24/97 To: Terry Lambert cc: dg@root.com, ccsanady@bob.scl.ameslab.gov, current@FreeBSD.ORG Subject: Re: TCP timers (Was: Re: new timeout routines) In-reply-to: Your message of "Thu, 25 Sep 1997 22:56:55 -0000." <199709252256.PAA06930@usr04.primenet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 25 Sep 1997 18:07:23 -0600 From: "Justin T. Gibbs" Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >This will increase the load on the timer code with a lot of 20 tick >timers for a 100Hz softclock. No. There would be exactly one TCP timer for doing delayed acks in the queue at a given time. The TCP code would be performing it's own "one shot" timer management if you will. >I haven't seen a formal layout of the design Archie Cobb said he >discussed with Julian, so I can't comment on that, but it would be >a good idea to consider all angles before making such a significant >change to the networking code (one of BSD's shiny spots). Archie's design is similar to having a set of hierarchical timing wheels which would handle large loads of timers with varying lifespans and chances of expiration better than the single level wheel we have now. I think that this is a better approach than having an ordered/unordered list for each bucket. See the G.Varghese and A. Lauck paper I referenced yesturday: http://dworkin.wustl.edu/~varghese/PAPERS/twheel.ps.Z Which is the second paper the timeout.9 man page references. > Regards, > Terry Lambert > terry@lambert.org >--- >Any opinions in this posting are my own and not those of my present >or previous employers. > -- Justin T. Gibbs =========================================== FreeBSD: Turning PCs into workstations =========================================== From owner-freebsd-current Thu Sep 25 18:20:50 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id SAA27011 for current-outgoing; Thu, 25 Sep 1997 18:20:50 -0700 (PDT) Received: from zippy.dyn.ml.org (garbanzo@spain-9.ppp.hooked.net [206.169.228.9]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id SAA27003 for ; Thu, 25 Sep 1997 18:20:46 -0700 (PDT) Received: from localhost (garbanzo@localhost) by zippy.dyn.ml.org (8.8.7/8.8.7) with SMTP id SAA01224; Thu, 25 Sep 1997 18:21:06 -0700 (PDT) X-Authentication-Warning: zippy.dyn.ml.org: garbanzo owned process doing -bs Date: Thu, 25 Sep 1997 18:21:06 -0700 (PDT) From: Alex X-Sender: garbanzo@zippy.dyn.ml.org To: freebsd-current@FreeBSD.ORG, Terry Lambert Subject: Re: where to place new crypt() files? In-Reply-To: <199709252248.PAA06261@usr04.primenet.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Thu, 25 Sep 1997, Terry Lambert wrote: > Yes. You live in Logan, Utah, so you can't export it, so only the > pieces not dealing with the crypt code itself can be exported. For > the crypt code itself, this is not a useful change unless you can > get the crypt people (in South Africa) to write to your framework. > > > Crypt is such an archaic pain because it's impossible to really > collaborate on it without breaking most countries munitions laws. > 8-(. One could probably export it from San Francisco, after that circuit court judge's two rulings. - alex From owner-freebsd-current Thu Sep 25 18:51:29 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id SAA28402 for current-outgoing; Thu, 25 Sep 1997 18:51:29 -0700 (PDT) Received: from gaia.coppe.ufrj.br (jonny@[146.164.5.200]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id SAA28375; Thu, 25 Sep 1997 18:51:09 -0700 (PDT) Received: (from jonny@localhost) by gaia.coppe.ufrj.br (8.8.7/8.8.7) id WAA03751; Thu, 25 Sep 1997 22:50:55 -0300 (EST) From: Joao Carlos Mendes Luis Message-Id: <199709260150.WAA03751@gaia.coppe.ufrj.br> Subject: Re: pcm device has a conflict with FreeBSD(98)? (Re: cvs commit: src/sys/i386/isa/snd In-Reply-To: <199709241602.SAA21966@labinfo.iet.unipi.it> from Luigi Rizzo at "Sep 24, 97 06:02:02 pm" To: luigi@labinfo.iet.unipi.it (Luigi Rizzo) Date: Thu, 25 Sep 1997 22:50:55 -0300 (EST) Cc: current@FreeBSD.ORG, cvs-all@FreeBSD.ORG, luigi@iet.unipi.it, jmg@FreeBSD.ORG, kato@migmatite.eps.nagoya-u.ac.jp, iwasaki@pc.jaring.my X-Mailer: ELM [version 2.4ME+ PL32 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk #define quoting(Luigi Rizzo) // * the new sound driver is meant to have a single device, named "pcm" // (or whatever) which incorporates the functionalities of all // subdevices; so "sb", "wss", "gus", "trix", etc are going to // disappear anyways; Is it really needed to include support for ALL kinds of sound cards if I need just one ? This is not scalable. I would prefer a common framework for audio devices, and stubs for each card family. Maybe two separate frameworks, if synthesizer support is added someday. Jonny PS: What about audiopcm, pcmaudio, or simply audio for the device name ? -- Joao Carlos Mendes Luis jonny@gta.ufrj.br +55 21 290-4698 jonny@coppe.ufrj.br Universidade Federal do Rio de Janeiro UFRJ/COPPE/CISI PGP fingerprint: 29 C0 50 B9 B6 3E 58 F2 83 5F E3 26 BF 0F EA 67 From owner-freebsd-current Thu Sep 25 18:59:37 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id SAA28830 for current-outgoing; Thu, 25 Sep 1997 18:59:37 -0700 (PDT) Received: from labinfo.iet.unipi.it (labinfo.iet.unipi.it [131.114.9.5]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id SAA28791; Thu, 25 Sep 1997 18:59:18 -0700 (PDT) Received: from localhost (luigi@localhost) by labinfo.iet.unipi.it (8.6.5/8.6.5) id CAA25457; Fri, 26 Sep 1997 02:47:14 +0200 From: Luigi Rizzo Message-Id: <199709260047.CAA25457@labinfo.iet.unipi.it> Subject: Re: pcm device has a conflict with FreeBSD(98)? (Re: cvs commit: src/sys/i386/isa/snd To: jonny@coppe.ufrj.br (Joao Carlos Mendes Luis) Date: Fri, 26 Sep 1997 02:47:13 +0200 (MET DST) Cc: current@FreeBSD.ORG, cvs-all@FreeBSD.ORG, luigi@iet.unipi.it, jmg@FreeBSD.ORG, kato@migmatite.eps.nagoya-u.ac.jp, iwasaki@pc.jaring.my In-Reply-To: <199709260150.WAA03751@gaia.coppe.ufrj.br> from "Joao Carlos Mendes Luis" at Sep 25, 97 10:50:36 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > Is it really needed to include support for ALL kinds of sound cards > if I need just one ? This is not scalable. I would prefer a common > framework for audio devices, and stubs for each card family. Maybe > two separate frameworks, if synthesizer support is added someday. I understand your concern, but as long as there are going to be 2-3 mainstream codecs and tens of different card which emulate these 2-3 differing only in the attach routine, I do think mine is a reasonable approach. Audio cards are not as different as, say, ethernet cards, for which having different drivers is reasonable because they are way different from each other. And btw the "ed" and "de" driver now do the same aggregation work of my sound driver. Similarly, I could have used "sb" and "wss" as names, but it turns out that most modern codecs emulate both (and possibly _need_ access to both) so you end up needing both drivers in any case, hence my decision. I have been thinking on the structure for quite some time, it is not a decision I took out of the blue. Cheers Luigi -----------------------------+-------------------------------------- Luigi Rizzo | Dip. di Ingegneria dell'Informazione email: luigi@iet.unipi.it | Universita' di Pisa tel: +39-50-568533 | via Diotisalvi 2, 56126 PISA (Italy) fax: +39-50-568522 | http://www.iet.unipi.it/~luigi/ _____________________________|______________________________________ From owner-freebsd-current Thu Sep 25 19:16:39 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id TAA29764 for current-outgoing; Thu, 25 Sep 1997 19:16:39 -0700 (PDT) Received: from gaia.coppe.ufrj.br (jonny@[146.164.5.200]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id TAA29759 for ; Thu, 25 Sep 1997 19:16:35 -0700 (PDT) Received: (from jonny@localhost) by gaia.coppe.ufrj.br (8.8.7/8.8.7) id XAA04366; Thu, 25 Sep 1997 23:16:20 -0300 (EST) From: Joao Carlos Mendes Luis Message-Id: <199709260216.XAA04366@gaia.coppe.ufrj.br> Subject: Re: pcm device has a conflict with FreeBSD(98)? (Re: cvs commit: src/sys/i386/isa/snd In-Reply-To: <199709260047.CAA25457@labinfo.iet.unipi.it> from Luigi Rizzo at "Sep 26, 97 02:47:13 am" To: luigi@labinfo.iet.unipi.it (Luigi Rizzo) Date: Thu, 25 Sep 1997 23:16:20 -0300 (EST) Cc: current@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL32 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk #define quoting(Luigi Rizzo) // Date: Fri, 26 Sep 1997 02:47:13 +0200 (MET DST) ^^^^^^^^ Late night hacking ? :) // > Is it really needed to include support for ALL kinds of sound cards // > if I need just one ? This is not scalable. I would prefer a common // > framework for audio devices, and stubs for each card family. Maybe // > two separate frameworks, if synthesizer support is added someday. // // I understand your concern, but as long as there are going to be 2-3 // mainstream codecs and tens of different card which emulate these 2-3 // differing only in the attach routine, I do think mine is a reasonable // approach. My fear is that this limits the addition of a completely new codec sometime. A good implementation should not restrict the options. For example, I have once implemented an audio output from a D/A converter normally used for control systems. This has been done in the old days of DOS modplay, in which a assembler driver was easy to add and soundcards were a rarity around here. It's not something everybody would have, of course. But could make scientific signal processing more readily available with the same interface as audio cards. For most applications what is needed is some kind of constant rate sampling/output. Indeed, I've heard of some universities doing low frequencies spectral analysis with audio cards. // Audio cards are not as different as, say, ethernet cards, for which // having different drivers is reasonable because they are way different // from each other. And btw the "ed" and "de" driver now do the same That's why I talked about a framework (like controller snd0 ?) and devices. And even on ethernet devices there's a pseudo-device ether to collect commom routines. // I have been thinking on the structure for quite some time, it is not a // decision I took out of the blue. I didn't want to mean that. Sorry if I meant. Jonny PS: Am I wrong or your driver is 100Kbytes smaller than the previous one ? :) -- Joao Carlos Mendes Luis jonny@gta.ufrj.br +55 21 290-4698 jonny@coppe.ufrj.br Universidade Federal do Rio de Janeiro UFRJ/COPPE/CISI PGP fingerprint: 29 C0 50 B9 B6 3E 58 F2 83 5F E3 26 BF 0F EA 67 From owner-freebsd-current Thu Sep 25 19:53:58 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id TAA01723 for current-outgoing; Thu, 25 Sep 1997 19:53:58 -0700 (PDT) Received: from usr05.primenet.com (tlambert@usr05.primenet.com [206.165.6.205]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id TAA01710 for ; Thu, 25 Sep 1997 19:53:55 -0700 (PDT) Received: (from tlambert@localhost) by usr05.primenet.com (8.8.5/8.8.5) id TAA23134; Thu, 25 Sep 1997 19:53:29 -0700 (MST) From: Terry Lambert Message-Id: <199709260253.TAA23134@usr05.primenet.com> Subject: Re: TCP timers (Was: Re: new timeout routines) To: gibbs@plutotech.com (Justin T. Gibbs) Date: Fri, 26 Sep 1997 02:53:28 +0000 (GMT) Cc: tlambert@primenet.com, dg@root.com, ccsanady@bob.scl.ameslab.gov, current@FreeBSD.ORG In-Reply-To: <199709260007.SAA29559@pluto.plutotech.com> from "Justin T. Gibbs" at Sep 25, 97 06:07:23 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > >This will increase the load on the timer code with a lot of 20 tick > >timers for a 100Hz softclock. > > No. There would be exactly one TCP timer for doing delayed acks in > the queue at a given time. The TCP code would be performing it's > own "one shot" timer management if you will. Yes, I missed this. David corrected me privately. I don't really like the idea of a multiplicity of timer code like this. I would prefer that TCP not manage it's own timers with a pseudo-softclock resulting from a timeout event in the real softclock. The initial posting to which David responded wanted to use centralized timer code for all timing functions. I liked that idea, with the caveat that the wheel would get loaded fast (Nate brought this up in the using-timers-for-network case back in the original discussion). > >I haven't seen a formal layout of the design Archie Cobb said he > >discussed with Julian, so I can't comment on that, but it would be > >a good idea to consider all angles before making such a significant > >change to the networking code (one of BSD's shiny spots). > > Archie's design is similar to having a set of hierarchical timing wheels > which would handle large loads of timers with varying lifespans and > chances of expiration better than the single level wheel we have now. > I think that this is a better approach than having an ordered/unordered > list for each bucket. I still like the ordered list for the O(n+1) event processing for n events in the process of expiring for a given tick. On the other hand, if it's possible to get HRT with good realtime constraints on maximum event processing duration, then it's sixes as far as I'm concerned. The point of ordering the list is less to deal with the seperation of things that take n ticks and n+256 ticks in the same bucket than it is to deal with RT. How would you handle RT events and priority-lent non-RT events for processes blocking RT required resources, without using a time/priority ordered list, where the RT events were inserted first? > See the G.Varghese and A. Lauck paper I referenced yesturday: > > http://dworkin.wustl.edu/~varghese/PAPERS/twheel.ps.Z Will do, as soon as I get ghostscript compiled up... is there a readable version of the paper anywhere meanwhile? The last paper I had to borrow a PS printer to read. Alternately, can you reference everything at once? ;-). Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-current Thu Sep 25 20:12:48 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id UAA02746 for current-outgoing; Thu, 25 Sep 1997 20:12:48 -0700 (PDT) Received: from pluto.plutotech.com (root@mail.plutotech.com [206.168.67.137]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id UAA02739 for ; Thu, 25 Sep 1997 20:12:44 -0700 (PDT) Received: from narnia.plutotech.com (narnia.plutotech.com [206.168.67.130]) by pluto.plutotech.com (8.8.5/8.8.5) with ESMTP id VAA00273; Thu, 25 Sep 1997 21:12:02 -0600 (MDT) Message-Id: <199709260312.VAA00273@pluto.plutotech.com> X-Mailer: exmh version 2.0zeta 7/24/97 To: Terry Lambert cc: gibbs@plutotech.com (Justin T. Gibbs), dg@root.com, ccsanady@bob.scl.ameslab.gov, current@FreeBSD.ORG Subject: Re: TCP timers (Was: Re: new timeout routines) In-reply-to: Your message of "Fri, 26 Sep 1997 02:53:28 -0000." <199709260253.TAA23134@usr05.primenet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 25 Sep 1997 21:11:49 -0600 From: "Justin T. Gibbs" Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >> Archie's design is similar to having a set of hierarchical timing wheels >> which would handle large loads of timers with varying lifespans and >> chances of expiration better than the single level wheel we have now. >> I think that this is a better approach than having an ordered/unordered >> list for each bucket. > >I still like the ordered list for the O(n+1) event processing for n >events in the process of expiring for a given tick. You would get this with the hierarchical approach. The bottom timing wheel only stores entries that will expire on the tick represented by the next bucket to process. The next timing wheel up needs to have one of it's hash chains "re-inserted" into the lower timing wheel every "lower timing wheel size" ticks. The further out from expiring an entry is, the less often it needs to be touched. In the Linux implementation of this, there are 5 wheels, so an entry will be touched at most 5 times by "softclock" and each insertion takes O(1). >How would you handle RT events and priority-lent non-RT events >for processes blocking RT required resources, without using a >time/priority ordered list, where the RT events were inserted first? This wasn't your original question, but I would probably pay the price of doing that sort during expiration processing using a bucket sort. All events in the bucket you're working on are supposed to expire, so you need to touch them all anyway, so performing an O(n) sort doesn't seem inappropriate. This is especially true if, as would probably be the case in a high resolution system, few entries are expected to expire at the exact same time. >> See the G.Varghese and A. Lauck paper I referenced yesturday: >> >> http://dworkin.wustl.edu/~varghese/PAPERS/twheel.ps.Z > >Will do, as soon as I get ghostscript compiled up... is there a >readable version of the paper anywhere meanwhile? Not that I know of. > Regards, > Terry Lambert > terry@lambert.org >--- >Any opinions in this posting are my own and not those of my present >or previous employers. > -- Justin T. Gibbs =========================================== FreeBSD: Turning PCs into workstations =========================================== From owner-freebsd-current Thu Sep 25 20:41:57 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id UAA03998 for current-outgoing; Thu, 25 Sep 1997 20:41:57 -0700 (PDT) Received: from usr05.primenet.com (tlambert@usr05.primenet.com [206.165.6.205]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id UAA03992 for ; Thu, 25 Sep 1997 20:41:55 -0700 (PDT) Received: (from tlambert@localhost) by usr05.primenet.com (8.8.5/8.8.5) id UAA28703; Thu, 25 Sep 1997 20:41:33 -0700 (MST) From: Terry Lambert Message-Id: <199709260341.UAA28703@usr05.primenet.com> Subject: Re: TCP timers (Was: Re: new timeout routines) To: gibbs@plutotech.com (Justin T. Gibbs) Date: Fri, 26 Sep 1997 03:41:33 +0000 (GMT) Cc: tlambert@primenet.com, gibbs@plutotech.com, dg@root.com, ccsanady@bob.scl.ameslab.gov, current@FreeBSD.ORG In-Reply-To: <199709260312.VAA00273@pluto.plutotech.com> from "Justin T. Gibbs" at Sep 25, 97 09:11:49 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > >How would you handle RT events and priority-lent non-RT events > >for processes blocking RT required resources, without using a > >time/priority ordered list, where the RT events were inserted first? > > This wasn't your original question, but I would probably pay the price of > doing that sort during expiration processing using a bucket sort. All > events in the bucket you're working on are supposed to expire, so you need > to touch them all anyway, so performing an O(n) sort doesn't seem > inappropriate. This is especially true if, as would probably be the case > in a high resolution system, few entries are expected to expire at the > exact same time. If there are few entries, this is happy. If there are more than one or two entries, this becomes less happy. By putting the sort at the time the timer expires, you delay starting the callout for the highest priority RT event. This isn't disasterous, given that there is a hell of a lot of indeterminate slack in the kernel elsewhere, but it would push out the "maximum possible time to process". Ideally, all of the indeterminate slack everywhere will go away, at some point in the (realistically, not near) future. This is one of the places which would have to change at that point anyway. Sorted insertion makes this a non-issue, since you process the insertions after the softclock callouts are processed. Insertion still looks, to the external caller, to be O(1), and priority is established before processing. This may be possible to handle by making another wheel where the actual queueing is done O(1), and then handling one "spoke" of ordered insertions per softclock one softclock ahead. This fits the multiwheel approach, and the sorting is kind of like an event that is scheduled to take place every softclock. 8-). Logically, though, theres no real difference between a seperate wheel vs. a seperate head on a single wheel. The one-ahead fixes the problem of events scheduled for exactly one softclock later (randomly scheduled events always occur 0 <= x < 1 softclocks early... anything that ups this slack is only more of a problem). Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-current Thu Sep 25 21:09:33 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id VAA05296 for current-outgoing; Thu, 25 Sep 1997 21:09:33 -0700 (PDT) Received: from usr05.primenet.com (tlambert@usr05.primenet.com [206.165.6.205]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id VAA05287; Thu, 25 Sep 1997 21:09:23 -0700 (PDT) Received: (from tlambert@localhost) by usr05.primenet.com (8.8.5/8.8.5) id VAA00555; Thu, 25 Sep 1997 21:09:09 -0700 (MST) From: Terry Lambert Message-Id: <199709260409.VAA00555@usr05.primenet.com> Subject: Re: IMPORTANT ANNOUNCEMENT TO ALL 'CURRENT' USERS... To: scrappy@hub.org (The Hermit Hacker) Date: Fri, 26 Sep 1997 04:09:08 +0000 (GMT) Cc: tlambert@primenet.com, karl@Mcs.Net, hackers@FreeBSD.ORG, current@FreeBSD.ORG In-Reply-To: from "The Hermit Hacker" at Sep 25, 97 08:41:59 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > then you need to get the sources in /usr/src/usr.sbin/config, and > > rebuild "config". > > Hrmmm...I always considered this to be "standard operating procedure" > when upgrading my kernel: check to make sure config sources haven't > changed *Shrug* I always considered config to be wasteful, now that it's possible to include or not include modules and have them dynamically register themselves via SYSINIT() simply by deciding that you will/won't link that particular object into the kernel. Once ELF is there, modules can go into different sections, and an ELF object archiver can configure/deconfigure modules without even needing to relink the darned things. *Shrug* 8-) Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-current Thu Sep 25 21:15:39 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id VAA05758 for current-outgoing; Thu, 25 Sep 1997 21:15:39 -0700 (PDT) Received: from gneiss.eps.nagoya-u.ac.jp (gneiss.eps.nagoya-u.ac.jp [133.6.57.99]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id VAA05652 for ; Thu, 25 Sep 1997 21:14:08 -0700 (PDT) Received: from marble.eps.nagoya-u.ac.jp (localhost [127.0.0.1]) by gneiss.eps.nagoya-u.ac.jp (8.8.7/3.5Wpl3) with ESMTP id MAA08226; Fri, 26 Sep 1997 12:40:53 +0900 (JST) Message-Id: <199709260340.MAA08226@gneiss.eps.nagoya-u.ac.jp> To: tlambert@primenet.com Cc: bde@zeta.org.au, current@FreeBSD.ORG Subject: Re: Daily SNAPshots at current.freebsd.org shut down for now. From: KATO Takenori In-Reply-To: Your message of "Thu, 25 Sep 1997 22:44:22 +0000 (GMT)" References: <199709252244.PAA05902@usr04.primenet.com> X-Mailer: Mew version 1.70 on Emacs 19.28.1 / Mule 2.3 X-PGP-Fingerprint: 03 72 85 36 62 46 23 03 52 B1 10 22 44 10 0D 9E Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Fri, 26 Sep 1997 12:40:53 +0900 Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > The easiest place to add this would be as a falg bit in d_flags; > put it under D_CHAIN in sys/disklabel.h: sys/conf.h is suitable place: /* * Types for d_type. */ #define D_TAPE 1 #define D_DISK 2 #define D_TTY 3 #define D_TYPEMASK 0xffff /* we can add four more types. */ #define D_UNCLUSTER 0x10000 /* disable clustering I/O */ (`d_flags' is also used in disklabel structure.) The d_flags member of bdevsw structure is referenced from kern/kern_conf.c and miscfs/specfs/spec_vnops.c in 3.0-current. ---- KATO Takenori Dept. Earth Planet. Sci., Nagoya Univ., Nagoya, 464-01, Japan PGP public key: finger kato@eclogite.eps.nagoya-u.ac.jp ------------------- Powered by FreeBSD(98) ------------------- From owner-freebsd-current Thu Sep 25 23:00:52 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id XAA10854 for current-outgoing; Thu, 25 Sep 1997 23:00:52 -0700 (PDT) Received: from gratis.grondar.za (gratis.grondar.za [196.7.18.133]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id XAA10836 for ; Thu, 25 Sep 1997 23:00:45 -0700 (PDT) Received: from greenpeace.grondar.za (greenpeace.grondar.za [196.7.18.132]) by gratis.grondar.za (8.8.7/8.8.7) with ESMTP id IAA08661; Fri, 26 Sep 1997 08:01:02 +0200 (SAT) Received: from greenpeace.grondar.za (localhost [127.0.0.1]) by greenpeace.grondar.za (8.8.7/8.8.7) with ESMTP id IAA27986; Fri, 26 Sep 1997 08:01:00 +0200 (SAT) Message-Id: <199709260601.IAA27986@greenpeace.grondar.za> To: Brandon Gillespie cc: freebsd-current@FreeBSD.ORG Subject: Re: where to place new crypt() files? Date: Fri, 26 Sep 1997 08:00:59 +0200 From: Mark Murray Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Brandon Gillespie wrote: > > Of course, the U.S. government will not allow Blowfish implementations > > to be exported. (You may have some luck with a crippled 40-bit > > version). > > Ach, damn, and I just finished crypt-blf.c... > > Suggestions? Treat it exactly the same as DES. M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org From owner-freebsd-current Thu Sep 25 23:19:02 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id XAA11900 for current-outgoing; Thu, 25 Sep 1997 23:19:02 -0700 (PDT) Received: from implode.root.com (implode.root.com [198.145.90.17]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id XAA11895 for ; Thu, 25 Sep 1997 23:18:59 -0700 (PDT) Received: from implode.root.com (localhost [127.0.0.1]) by implode.root.com (8.8.5/8.8.5) with ESMTP id XAA21049; Thu, 25 Sep 1997 23:20:55 -0700 (PDT) Message-Id: <199709260620.XAA21049@implode.root.com> To: Terry Lambert cc: ccsanady@bob.scl.ameslab.gov, current@FreeBSD.ORG Subject: Re: TCP timers (Was: Re: new timeout routines) In-reply-to: Your message of "Fri, 26 Sep 1997 00:02:35 -0000." <199709260002.RAA12137@usr04.primenet.com> From: David Greenman Reply-To: dg@root.com Date: Thu, 25 Sep 1997 23:20:55 -0700 Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >> >This will increase the load on the timer code with a lot of 20 tick >> >timers for a 100Hz softclock. >> >> "A lot"? There will be exactly _one_. This is not a problem. Please read >> again what I wrote and tell me how I was unclear so that I don't make the >> same mistake in the future. > >It was unclear that there would not be one per FIN_2_WAIT per socket; >how do you plan to handle these timeouts to give one timer entry? I was only talking about delayed-acks, which is all that the 1/5th second "fast" timer does. The 1/2 second "slow" timer handles all other connection management issues (like retransmits, connection timeouts, etc). The most optimimal way of handling the fast timer events is the way that I described previously, and this will be true no matter how the system timeout code works. The slow timer really is a different animal and it's true that there could be one timer event per connection. The granularity of a slow timer event is in 1/2 second quantums, however, so perhaps the problem isn't as bad as it may seem (the next event for a connection could easily be several seconds or more in the future). Again, I haven't really thought much about how to deal with this, and I certainly agree that it is a much harder problem to solve. -DG David Greenman Core-team/Principal Architect, The FreeBSD Project From owner-freebsd-current Thu Sep 25 23:30:58 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id XAA12635 for current-outgoing; Thu, 25 Sep 1997 23:30:58 -0700 (PDT) Received: from implode.root.com (implode.root.com [198.145.90.17]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id XAA12618 for ; Thu, 25 Sep 1997 23:30:54 -0700 (PDT) Received: from implode.root.com (localhost [127.0.0.1]) by implode.root.com (8.8.5/8.8.5) with ESMTP id XAA21071; Thu, 25 Sep 1997 23:32:52 -0700 (PDT) Message-Id: <199709260632.XAA21071@implode.root.com> To: Terry Lambert cc: ccsanady@bob.scl.ameslab.gov, current@FreeBSD.ORG Subject: Re: TCP timers (Was: Re: new timeout routines) In-reply-to: Your message of "Fri, 26 Sep 1997 02:53:28 -0000." <199709260253.TAA23134@usr05.primenet.com> From: David Greenman Reply-To: dg@root.com Date: Thu, 25 Sep 1997 23:32:52 -0700 Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >> >This will increase the load on the timer code with a lot of 20 tick >> >timers for a 100Hz softclock. >> >> No. There would be exactly one TCP timer for doing delayed acks in >> the queue at a given time. The TCP code would be performing it's >> own "one shot" timer management if you will. > >Yes, I missed this. David corrected me privately. > >I don't really like the idea of a multiplicity of timer code like >this. I would prefer that TCP not manage it's own timers with a >pseudo-softclock resulting from a timeout event in the real softclock. I like whatever scheme is the most efficient. Even an all-singing, all-dancing system timer implementation that keeps everything sorted in a binary tree is going to perform much worse than specialized code that can do simple FIFO sorting by taking advantage of the fixed timeout interval. On a busy machine like wcarchive, tens of thousands of delayed acks can occur each second, so this needs to be optimized for efficiency as much as possible. The extra call overhead that one would incur by having a timer event per connection is plenty enough to make me cringe. >The initial posting to which David responded wanted to use centralized >timer code for all timing functions. I liked that idea, with the I don't like that idea, but maybe it's because my brain refuses to bend around the idea that delayed-ack processing is just another connection state. -DG David Greenman Core-team/Principal Architect, The FreeBSD Project From owner-freebsd-current Thu Sep 25 23:46:35 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id XAA13760 for current-outgoing; Thu, 25 Sep 1997 23:46:35 -0700 (PDT) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id XAA13752 for ; Thu, 25 Sep 1997 23:46:30 -0700 (PDT) Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.5/8.6.9) id QAA23500; Fri, 26 Sep 1997 16:40:38 +1000 Date: Fri, 26 Sep 1997 16:40:38 +1000 From: Bruce Evans Message-Id: <199709260640.QAA23500@godzilla.zeta.org.au> To: bde@zeta.org.au, kato@migmatite.eps.nagoya-u.ac.jp Subject: Re: Daily SNAPshots at current.freebsd.org shut down for now. Cc: current@FreeBSD.ORG Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >> clustering is 2 too many for a production system :-) (non-clustering for >> /dev/vn must be forced independently of any mount options and sysctls, >> except possibly for debugging). > >How does mount() in vfs_syscall.c know special device is /dev/vn? It doesn't yet. It could look at a new flag (vp->v_flag & VNOCLUSTER) where vp is the vnode for the mount point. The flag should be set in vnopen(). This seems to require using bdevvp() to find the vnode. >When mount() can know specical device is /dev/vn, then > > if (special device is /dev/vn) > mp->mnt_flag |= MNT_NOCLUSTER; > >works, and doclusterread and doclusterwrite can be eliminated. Right, except separate MNT_NOCLUSTER{READ,WRITE} flags are required to give the same functionality. Bruce From owner-freebsd-current Fri Sep 26 00:02:00 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id AAA15044 for current-outgoing; Fri, 26 Sep 1997 00:02:00 -0700 (PDT) Received: from freebie.lemis.com (freebie.lemis.com [192.109.197.137]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id AAA15008; Fri, 26 Sep 1997 00:01:50 -0700 (PDT) Received: (from grog@localhost) by freebie.lemis.com (8.8.7/8.8.5) id QAA08062; Fri, 26 Sep 1997 16:31:04 +0930 (CST) Message-ID: <19970926163104.12375@lemis.com> Date: Fri, 26 Sep 1997 16:31:04 +0930 From: Greg Lehey To: Karl Denninger Cc: Terry Lambert , hackers@FreeBSD.ORG, current@FreeBSD.ORG Subject: Re: IMPORTANT ANNOUNCEMENT TO ALL 'CURRENT' USERS... References: <19970925161021.36073@Mars.Mcs.Net> <199709252215.PAA03466@usr04.primenet.com> <19970925171616.26390@Mars.Mcs.Net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.81e In-Reply-To: <19970925171616.26390@Mars.Mcs.Net>; from Karl Denninger on Thu, Sep 25, 1997 at 05:16:16PM -0500 Organisation: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8250 Fax: +61-8-8388-8250 Mobile: +61-41-739-7062 WWW-Home-Page: http://www.lemis.com/~grog Fight-Spam-Now: http://www.cauce.org Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Thu, Sep 25, 1997 at 05:16:16PM -0500, Karl Denninger wrote: > On Thu, Sep 25, 1997 at 10:15:05PM +0000, Terry Lambert wrote: >> Well, no one with actual power over the tree has made the necessary >> announcement, so I will: >> >> >> >> If you are trying to build -current, and you get this error: >> >>> loading kernel >>> isa.o: Undefined symbol `_isa_devtab_cam' referenced from text segment >> >> then you need to get the sources in /usr/src/usr.sbin/config, and >> rebuild "config". > > Now you tell me :-) Sounds like the announcment had its value, then. Greg From owner-freebsd-current Fri Sep 26 00:37:33 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id AAA17296 for current-outgoing; Fri, 26 Sep 1997 00:37:33 -0700 (PDT) Received: from usr04.primenet.com (tlambert@usr04.primenet.com [206.165.6.204]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id AAA17291 for ; Fri, 26 Sep 1997 00:37:30 -0700 (PDT) Received: (from tlambert@localhost) by usr04.primenet.com (8.8.5/8.8.5) id AAA16250; Fri, 26 Sep 1997 00:37:25 -0700 (MST) From: Terry Lambert Message-Id: <199709260737.AAA16250@usr04.primenet.com> Subject: Re: TCP timers (Was: Re: new timeout routines) To: dg@root.com Date: Fri, 26 Sep 1997 07:37:24 +0000 (GMT) Cc: tlambert@primenet.com, ccsanady@bob.scl.ameslab.gov, current@FreeBSD.ORG In-Reply-To: <199709260632.XAA21071@implode.root.com> from "David Greenman" at Sep 25, 97 11:32:52 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > I like whatever scheme is the most efficient. Even an all-singing, > all-dancing system timer implementation that keeps everything sorted in > a binary tree is going to perform much worse than specialized code that > can do simple FIFO sorting by taking advantage of the fixed timeout > interval. On a busy machine like wcarchive, tens of thousands of delayed > acks can occur each second, so this needs to be optimized for efficiency > as much as possible. The extra call overhead that one would incur by having > a timer event per connection is plenty enough to make me cringe. What about inlining the insertion and removal function calls? That should end up being very low overhead... hopefully as low overhead as a seperate implementation. If it's not, then we should be using TCP's code for the system timers instead of the system timer code for TCP. ;-). > >The initial posting to which David responded wanted to use centralized > >timer code for all timing functions. I liked that idea, with the > > I don't like that idea, but maybe it's because my brain refuses to bend > around the idea that delayed-ack processing is just another connection > state. Heh. "Mei meind may very wiel SNNNNNIP!" -- Dr. Scott Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-current Fri Sep 26 00:47:54 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id AAA18099 for current-outgoing; Fri, 26 Sep 1997 00:47:54 -0700 (PDT) Received: from freebie.lemis.com (freebie.lemis.com [192.109.197.137]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id AAA18094 for ; Fri, 26 Sep 1997 00:47:49 -0700 (PDT) Received: (from grog@localhost) by freebie.lemis.com (8.8.7/8.8.5) id RAA08230; Fri, 26 Sep 1997 17:17:30 +0930 (CST) Message-ID: <19970926171729.56024@lemis.com> Date: Fri, 26 Sep 1997 17:17:29 +0930 From: Greg Lehey To: Mark Murray Cc: Nate Williams , FreeBSD current users Subject: Re: find still broken - is this only happening to me? References: <199709251615.SAA04793@greenpeace.grondar.za> <19970926084641.09282@lemis.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.81e In-Reply-To: <19970926084641.09282@lemis.com>; from Greg Lehey on Fri, Sep 26, 1997 at 08:46:41AM +0930 Organisation: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8250 Fax: +61-8-8388-8250 Mobile: +61-41-739-7062 WWW-Home-Page: http://www.lemis.com/~grog Fight-Spam-Now: http://www.cauce.org Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Fri, Sep 26, 1997 at 08:46:41AM +0930, Greg Lehey wrote: > On Thu, Sep 25, 1997 at 06:15:30PM +0200, Mark Murray wrote: >> Nate Williams wrote: >>>> I reported this a couple of weeks ago. Has nobody else experienced it? >>>> >>>> $ find /sys -follow -name "*.[csh]" | xargs grep ENFILE|less >>>> ): no beginning '(' >>> >>> Works for me (w/out less, since I don't have it installed). No errors. >> >> This chap (Greg?) most likely has a funny file somewhere. Make the command >> line: >> $ find /sys -follow -name '*.[csh]' | xargs grep ENFILE|less >> >> (singe quotes, not double), and it should work. The *.[csh] is being >> allowed to glob by the "". > > Yes, that was my first assumption. Look at the name of the directory: > it's the source tree. And GNU find works fine. I did this on > numerous directories. > > OK, if nobody else has seen it, I'll follow it up and see what the > problem really is. Watch this space. Grrr. I went back and recompiled find with -g. And it worked. So I recompiled it with the default CFLAGS. And it worked. I promise, nothing in the source tree has changed since I built it yesterday, only the problem has gone into hiding. Let's forget this one. If it happens again, I'll try to catch it before it goes into hiding again. Greg From owner-freebsd-current Fri Sep 26 01:46:46 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id BAA21796 for current-outgoing; Fri, 26 Sep 1997 01:46:46 -0700 (PDT) Received: from gneiss.eps.nagoya-u.ac.jp (gneiss.eps.nagoya-u.ac.jp [133.6.57.99]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id BAA21713 for ; Fri, 26 Sep 1997 01:44:17 -0700 (PDT) Received: from marble.eps.nagoya-u.ac.jp (localhost [127.0.0.1]) by gneiss.eps.nagoya-u.ac.jp (8.8.7/3.5Wpl3) with ESMTP id RAA08732; Fri, 26 Sep 1997 17:33:00 +0900 (JST) Message-Id: <199709260833.RAA08732@gneiss.eps.nagoya-u.ac.jp> To: bde@zeta.org.au Cc: current@FreeBSD.ORG Subject: Re: Daily SNAPshots at current.freebsd.org shut down for now. From: KATO Takenori In-Reply-To: Your message of "Fri, 26 Sep 1997 16:40:38 +1000" References: <199709260640.QAA23500@godzilla.zeta.org.au> X-Mailer: Mew version 1.70 on Emacs 19.28.1 / Mule 2.3 X-PGP-Fingerprint: 03 72 85 36 62 46 23 03 52 B1 10 22 44 10 0D 9E Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Fri, 26 Sep 1997 17:33:00 +0900 Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > It doesn't yet. It could look at a new flag (vp->v_flag & VNOCLUSTER) > where vp is the vnode for the mount point. The flag should be set in > vnopen(). This seems to require using bdevvp() to find the vnode. Each fs layer (e.g., ufs) can know both (1) special device requests to disable clustering I/O via bdevsw, and (2) the filesystem supports clustering I/O or not. > Right, except separate MNT_NOCLUSTER{READ,WRITE} flags are required to > give the same functionality. There is another reson separted options are required: if only cluster write is unsafe, there is no reason disabling cluster read. This is gzipped patch for 3.0-current: ---------- BEGIN ---------- begin 644 vndiff.gz M'XL("-1P*S0``W9N9&EF9@#E6WM3VT@2_]O[*6;9VI0-`BS);PZJ"+:S5,#F M;!.S=;E2R;8$NLB25P_87,A]]NN>&;W'@B1L=J_.!;8TFIY'3\^O']/:W=TE M_D?_\-8)#XW?`\7TZ8\&7X;G'-P=C"?G;RI#SR)38T.4%I$;O7J[AQ?=;ON' M_?W]4O(B94-AE+O9#]Z3AB*UZH3>$O*393HKPR3:]->I]F9TK0UN9LIP2G_P M:S`9:;]H6!%J68Y1>;+B#_OD^R"Z9?O27@4WN=3LT?&*Z'@GN#,)F0$S+ M-F!2@;$^H+4/X3OJA+=]=G$]A88G@]-^I2)7*H>[9&F'0.(1S]!7EG-+#$=? MV,:JC'P^.9\-*A4E0__@64%"+R2_/+TYAWXK*B5TPO4"Z%P3IV.MHEE8*Y\1 M%^E'IY>#*?GT'IY4/M4E4O\L$79#=E8N'PC.8T9^R<$#_PPF5`@"GNRCA*"JB@Y`OY/!JGPJ'2,QPC'0` M!\LM@MJLEPMJJH4,<:NGJ#U5W2ZKLJQ(LMR)I!7^*A7+)%5[87\(7-_ZMU$U M?8DXT(N]<&KDY)A8F_T32\-'-5J]`DP&R3LF"QQ%]7XC$:@J$:PAD='X;#+H M2^358E,[^N%'J&_8OD&P#SKRS$+E&N1/M*A=]I3`)QF#J#-6KQ):[OX)?`&] M;ZTD4M6!2M<>I7Y'P,@#8ZJY%/K+OJ MO6NM:@LJK%7:)A9_)C$G?C<-#X=)]@CPW35-WPAPUJ:_?^)KIJ??,GY#@\C! M2E&2:-NL0T!?PD!C5=6TH6<8KZ=]3>,,K"Q@I@O*:9\\'I/7$:*-W^*P?C*< ME652T8CFR$7CSYCC\R1DSB7DQ6:_#;/N3=_=^"+`4GO-YI.`%9'GT:K5DUO; MT4II-B6EE1*U>\^PC>K*N+^/N.P90>@YI#H8W9R/6=EG9")EX7I3X-SU5?]T M-DCOJVA;T7%2=IL^ZT(B:_CG>YF"Y#FHYPB&!R1R=;#N1N1>>+! MZP!%S8.KVC_W3U9<1EZ1?AJ*F&AF>@$IRN+5T;=T,7].%_.C+UDTO@?_J&7; MNEF<+7L%E'NGUWS""N74><)N3VZ7;!45$*N9;)5WHW%_,+[2IH-9E36NF9;I MNAO-W=S#K/UE+;7K,U;F`$TXM.72MN$A13?B;@R/\L%/C$P_@)(EV$!!I:CB M@9WR45DEUBZO!;8P6&0:CKV*F"&1R_$U+#^S`"5N)%*S;7AQ^D:;S,$,E,@. M>YXR@7=JJ>;`N*.M:1%YT1R62&;4$MJ+J%+3';TJSH[U_B6=4>,YU1N=_G.Z M8Q53_5'`=^#IRB!_*S$03YAM@ZN+*(-R`MY,QD"U?!<(EZMNJU7G/^6`W^K5 M`OCIA#O/ M`/ZOF?#W@?TOYNIV9'X1OI9*=@DZ=WN-UC,$6X#0(->-4F.F(TO==B35"1P2 MWJ;EV^[R`WC>FG95K7*_\A[P.GJ@(?/(;HV*!-_0VX,"K-72H,!9GW:<#@K( MSPX)<&+NTRLBCYX/0>31G3GCK56X0RP@"F!AY9ZK9]0,:._9'` ME?L`0T>N+)"-1'=@8'>ZIR]QBO[&6%JZ#5;SO;4T0*<1PL0(%H9*`"Q:IQ6# M91&KNEU)K7=CK(H,M#I=I,],KZ94'U]KH8;6'5 MGZ7[1"//::-H'=YA,`0L!=0#ONNIVKJJ-AJ0VZXD&J#C`)+!3 M3`8TU)4Z1E>*.ND6HHO%7.\(+W6VVL=8!EZ7G!BFHHG$GES._:A@I;LM?6?Z'ZEH':#?NJ6Z&_523R+O7%V]KY-4KPM1UHIA!-_:U M_OGT+5\'9,[&`U@QJSNLKJ:O5MJMX1B>M>P1N$'X9C2$KBON2(9UY.?5>V>' M,1O:07HF+83?I7N..N9Q,SKA9BR0+S5A*I35?-]HCB#N7Y[BQ/\*/,A(&T(K MW*#.V6(LJV!3=`4"EZ7,V1(-%?[*`B.JI+246.;B2)/`&ISTQZ.+7]E&%)EQ M\]/1;-*?,R,N2W_\'U)E0#"]/N^31XX*@YO!67S3'[PCC[ATR#0LPM#8+Y/Q M:'P]Y96N1^?C$;\^Q<GL_')0*_8,0YN>G4[>5$,=,((N`$A(R6"B54N- MZ0L',QQ/S@;9F63&%TOY)6(EM;'2QA67=1;(46G4*MH?_].+P\@K67405XDC M-W_Q)

-L,GK?($0"L+7\)O@$:D?QGNV\!.-#IU=4L#FQOH(@A]6Z)"FJW M)+FCI`RFR!FBR.L;RQ!=RGO#QD,,)3DP`"VSC)U"Z@,B[#&7;_OS%"C&<,RU M=ARAO!I,+KGYP;F*@R+S.\,A7N@XB,J60]C0R!HL1C1#B>,&S&C'2)/C,WW# M9Y<80"\WNVKI]+*ZYP^?K!#IE7HV&@+MTMI4CT6GKN!SZ#+] M`A]P-IE)P#[4H8;'PR64(ZDX^5^)(TRXJD*^E$O3"W)))$<-19$:2N;@=ZF# M7D+CJQ>S@D_;7:_13T:;GVX2L*]J[-%*#W0L?ZW-3J\&M>2X*A];JN4%@M7/ M;IQZM&EHS";[3*Y%Y^DJ#+R;/J5]T8&7CERP9%\SCYS""!W+==AW>9BUWE.: M0HTA:J$896V6JHRZ)+>;3!X8RD)!IYYLJULW<,E"7_%X([!^CRK(/:H@^Y9/ M$SW2^1^`:BZH3._!@O5A.I,L#%@4$,[0\0,D.&#TA_CSU$'/'EWM<`VV=Q00 M8U.F[BK9K9$U;HAE%;U#UQ34J47>Y*5V/9Q"^Q*Y!)OJ?#9^6Z-11'19*!3$ M:T2YC+2B+"+0Q')/R86^4Q3Y-9![:DGBD-P"Q=:64VM`"V++,8J6Q39/I?Y[ MG7Z4.@Z>3I0\6,$=7*X,S_Z(R)<8+&QFZ5:HM12WTJ"M8/UHM7`5`U!:NO_1 M6=YYKN.&OOVQV`XWJZ`EF35%6XID(MS`;C,0H&C;^A+0">#)0CF@*Y]M*K+) MH+6&H+5T.+*$?`[DG6>0DW2HROA]XWH!@#R3*+KI#\1KU94E.8G?IH?P[GR* M<3+$B$HU,>H?<\;K8V+L/B9&\"-YS^V%V.Y]C-?[,5XS>C6X2;4\N+D:3V:# M7`/]P3!^D-0Z'?&V!C=O!Y/7]/)B?'9Z@<0_QL37T\&$/OO[]7AV2J\FX_%L M&`V=>4-9#@YHRIQNI\5NZ3J!Y]H1.UG,`'RB>ETDV?]?['O,RGRVA?11^)=R M.8U?-(PEAB^EUV@7X8L1%%/)ZB7G=)VFU*TGV(6WW?SZ,@NGHF2*9K-?*RK3 M)ZE"KF5A%YOP0>S?(U3;P/2'5!G3P(W&I[M'LEC0SP()A26:9[AB..`C$(AA MI)\%$45(FBBY[?TBM;J=FO:,YDFJF=0:OTX9<\0'5%_>$:HR>>A\<(-JDY722QH5QE.*"N')2"@ M4,G1UP8[>H,+1'=TCU>>=0]S,PYN#X@>KBR76]9<%S/W"JGQZHC0\R7/!76P M<:$KH`0C@YU7&?>'8XK9RT#*'"_H$\U/=OJ\E9HJH.%D,*A4&DB;MJUX0Z9G&-M&4!DFJ=-- MT3&KF61-4YV1[CLY8"5XIHHGK.2KLJ93.2BB>H37XQS!LZBR:I0%.&EQI<_, M\0/9D:.]_`*RDUE%^1M64?G&551?;!5?FNTBS"AS4!O=@C,D(LW;%TZ"SS=T,7].%W.>U9(.>DV!K09L<`NVAD]TXA@/S%&3J,;3>80>M2_% M`K'\EF3[@`27J+RM>9B1GA0NK]J5E$3GI=,PL4V,\>=S,/-U1'F:+Y*>B2#S M5'9FMDXF.1.&L2U'Y1J3,TU19N;P&6F9E'#X%0F9A?F4Y6/F>_F"3,PB3Y*. M2#81$P6(_Q>2,%G^)^)% M&:P1L3,:4)J?T5E`G.'*LWTX8>`+(]PG5Y3WHYP345JMA.S"V_S\2K09E=1J!U-9AI@WY$J M@/5Q4)$:WP62Z6!"HWZ,S#>\WT(WT!EI74CR9C*^ODIH;CTWW!2)]K)$J1@7 M$D5H"22RE(.!WD89S=B7"[GB4AM7#8C2)HA^6>LTB(;2$M0BR;AM.P(XKVUTIM&^Z]@?=\`#3BJDSARDRD[*S<]6BU:#@P0^VXN>I9=DQW'3AOJ6 MBO-,119GB;L;75];:2L^]V6U#02M1.%&6I$2C`,QR92_3 MHD8P8\X( MA;F1?;.O0)039@RXEH1!9*4CR:J:.ARF!3&VS-`M3AT'^7=N:*_(PB#^!VNS M,5;D`=./V,$F5/5"?E0,+C.0'PQMHL,OLAY/4P[.`Y(L$13PC!/091E'LU#W M05R7.2'8$:V,>5R2"N$Z?AD22\1V Dept. Earth Planet. Sci., Nagoya Univ., Nagoya, 464-01, Japan PGP public key: finger kato@eclogite.eps.nagoya-u.ac.jp ------------------- Powered by FreeBSD(98) ------------------- From owner-freebsd-current Fri Sep 26 01:59:50 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id BAA22457 for current-outgoing; Fri, 26 Sep 1997 01:59:50 -0700 (PDT) Received: from schizo.dk.tfs.com (mail.trw.dk [195.8.133.123]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id BAA22447 for ; Fri, 26 Sep 1997 01:59:46 -0700 (PDT) Received: from critter.freebsd.dk (critter.dk.tfs.com [140.145.230.252]) by schizo.dk.tfs.com (8.8.7/8.7.3) with ESMTP id KAA07504; Fri, 26 Sep 1997 10:59:14 +0200 (MET DST) Received: from critter.freebsd.dk (localhost.dk.tfs.com [127.0.0.1]) by critter.freebsd.dk (8.8.7/8.8.7) with ESMTP id KAA08147; Fri, 26 Sep 1997 10:58:25 +0200 (CEST) To: Greg Lehey cc: Mark Murray , Nate Williams , FreeBSD current users Subject: Re: find still broken - is this only happening to me? In-reply-to: Your message of "Fri, 26 Sep 1997 17:17:29 +0930." <19970926171729.56024@lemis.com> Date: Fri, 26 Sep 1997 10:58:25 +0200 Message-ID: <8145.875264305@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk In message <19970926171729.56024@lemis.com>, Greg Lehey writes: >>> $ find /sys -follow -name '*.[csh]' | xargs grep ENFILE|less > >Grrr. I went back and recompiled find with -g. And it worked. So I >recompiled it with the default CFLAGS. And it worked. I promise, >nothing in the source tree has changed since I built it yesterday, >only the problem has gone into hiding. > >Let's forget this one. If it happens again, I'll try to catch it >before it goes into hiding again. Is there any chance that you had a directory named so it matched '*.[csh]' ? Ie, would a find /sys -type f -name '*.[csh]' | xargs grep ENFILE|less have made a difference ? -- Poul-Henning Kamp FreeBSD coreteam member phk@FreeBSD.ORG "Real hackers run -current on their laptop." From owner-freebsd-current Fri Sep 26 02:07:38 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id CAA23076 for current-outgoing; Fri, 26 Sep 1997 02:07:38 -0700 (PDT) Received: from freebie.lemis.com (freebie.lemis.com [192.109.197.137]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id CAA23068 for ; Fri, 26 Sep 1997 02:07:34 -0700 (PDT) Received: (from grog@localhost) by freebie.lemis.com (8.8.7/8.8.5) id SAA08591; Fri, 26 Sep 1997 18:34:50 +0930 (CST) Message-ID: <19970926183449.36254@lemis.com> Date: Fri, 26 Sep 1997 18:34:49 +0930 From: Greg Lehey To: Poul-Henning Kamp Cc: Mark Murray , Nate Williams , FreeBSD current users Subject: Re: find still broken - is this only happening to me? References: <19970926171729.56024@lemis.com> <8145.875264305@critter.freebsd.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.81e In-Reply-To: <8145.875264305@critter.freebsd.dk>; from Poul-Henning Kamp on Fri, Sep 26, 1997 at 10:58:25AM +0200 Organisation: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8250 Fax: +61-8-8388-8250 Mobile: +61-41-739-7062 WWW-Home-Page: http://www.lemis.com/~grog Fight-Spam-Now: http://www.cauce.org Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Fri, Sep 26, 1997 at 10:58:25AM +0200, Poul-Henning Kamp wrote: > In message <19970926171729.56024@lemis.com>, Greg Lehey writes: > >>>> $ find /sys -follow -name '*.[csh]' | xargs grep ENFILE|less >> >> Grrr. I went back and recompiled find with -g. And it worked. So I >> recompiled it with the default CFLAGS. And it worked. I promise, >> nothing in the source tree has changed since I built it yesterday, >> only the problem has gone into hiding. >> >> Let's forget this one. If it happens again, I'll try to catch it >> before it goes into hiding again. > > Is there any chance that you had a directory named so it matched '*.[csh]' ? > > Ie, would a > > find /sys -type f -name '*.[csh]' | xargs grep ENFILE|less > > have made a difference ? No, I've seen this in a number of places. And I repeated exactly the same command with the newly compiled version. I'm sure there *is* a bug there somewhere--recall that GNU find doesn't have the same problem--but it's obviously pretty elusive. Greg From owner-freebsd-current Fri Sep 26 07:39:45 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id HAA08021 for current-outgoing; Fri, 26 Sep 1997 07:39:45 -0700 (PDT) Received: from news1.gtn.com (news1.gtn.com [192.109.159.3]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id HAA08010 for ; Fri, 26 Sep 1997 07:39:36 -0700 (PDT) Received: (from uucp@localhost) by news1.gtn.com (8.8.6/8.8.6) with UUCP id QAA17653; Fri, 26 Sep 1997 16:30:14 +0200 (MET DST) Received: (from andreas@localhost) by klemm.gtn.com (8.8.7/8.8.7) id QAA08899; Fri, 26 Sep 1997 16:22:20 +0200 (CEST) Message-ID: <19970926162220.14058@klemm.gtn.com> Date: Fri, 26 Sep 1997 16:22:20 +0200 From: Andreas Klemm To: Neal Westfall Cc: current@FreeBSD.ORG Subject: Re: The 3.0-970920-SNAP CD has been canceled References: <3744.875218930@time.cdrom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.81 In-Reply-To: ; from Neal Westfall on Thu, Sep 25, 1997 at 02:18:33PM -0700 X-Disclaimer: A free society is one where it is safe to be unpopular X-Operating-System: FreeBSD 3.0-CURRENT SMP Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Thu, Sep 25, 1997 at 02:18:33PM -0700, Neal Westfall wrote: > Does anyone know when the last good snapshot was? I want to > install a fairly current snapshot on my machine that is newer > than the last "official" snapshot. I did a make relase at Sept, 11th and installed my system completely new (major repartitioning, use of ccd and such). So if you have the CVS repository and the resources (kernel compiled with vn driver and about 700MB disk space), then you can easily checkout the sources with that date ... and make a private release. Get the cvs repository from a SNAP CD-Rom, update with cvsup (which is indeed fast and reliable) and everything should be fine. -- Andreas Klemm | klemm.gtn.com - powered by Symmetric MultiProcessor FreeBSD http://www.freebsd.org/~fsmp/SMP/SMP.html http://www.freebsd.org/~fsmp/SMP/benches.html From owner-freebsd-current Fri Sep 26 09:44:50 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id JAA15190 for current-outgoing; Fri, 26 Sep 1997 09:44:50 -0700 (PDT) Received: from nessie.ethz.ch (dapor@nessie.ethz.ch [129.132.71.52]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id JAA15185 for ; Fri, 26 Sep 1997 09:44:45 -0700 (PDT) Received: (from dapor@localhost) by nessie.ethz.ch (8.6.10/8.6.12) id SAA06025 for freebsd-current@freebsd.org; Fri, 26 Sep 1997 18:45:27 +0200 From: Carlo Dapor Message-Id: <199709261645.SAA06025@nessie.ethz.ch> Subject: Suggestions on some make rules as far as the -o option is concerned To: freebsd-current@freebsd.org Date: Fri, 26 Sep 1997 18:45:26 +0200 (MET DST) X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hello, everybody My situation is this. I have a Pentium 90 MHz machine, freshly installed with 2.2.2. I unpacked src-2.2.0400xEmpty.gz successfully. I applied the patches up until src-2.2.0447 inclusively. Furthermore, I ran a 'make install' in /usr/src/share/mk. In attempt to make world the success was always broken when some file had to be build by bison. The command line looked like bison -d /some/directory/where/the/dot-y-files-lies/file.y -o foo.c Bison doesn't like the option after the argument given to the -d option. In fact, bison built foo.tab.[ch], ignoring the rest. The build procedure then tried to build foo.o ===>> end of the build process. So I modified all the rules where .y.c is applied. Fortunately there are only 3 occurences. The next run (making the world) outlived the first attempt by a factor of 6 or 7, but ended when a .info file had to be produced. The command line looked very similar to the one mentioned above: makeinfo -d /some/directory/file.texi [ some more options ] -o foo.info Here makeinfo broke hopelessly !! So I modified share/mk/bsd.info.mk. So far, I have fixed some build issues. IMHO both bison and makeinfo do not behave the way they are designed. I am aware that the patches I include in this mail should not be necessary. But then, didn't anybody build the world recently ? Do I have to assume I am the only one ? Everybody else is building current (3.0) all the time ? Who knows, maybe these patches are not the only ones to be applied to successfully 'make world'. And yes, another thing. I am a subscriber of both Release and Snapshots CDs. One thing I miss is the mentioning which source patch number the release corresponds to actually. Just for making this clear: FreeBSD 2.2-RELEASE is equivalent to the sources up and until src-2.2.0209, 2.2.1 up to src-2.2.0216, 2.2.2 up to src-2.2.0286. I'd like to know that, before I have to find it out myself and learning from it when it is rather late. Why the hell do I ask for this thing ? The reason is I usually install the sources from the CD. And to keep up with the rest of You guys, I apply the necessary patches every day. But I need to know where to start from each release. So far I had to operate with trial and error (not fun at all). So, enough talking, here are the patches: --- contrib/gcc/Makefile.in.orig Thu Sep 25 19:54:12 1997 +++ contrib/gcc/Makefile.in Fri Sep 26 10:11:57 1997 @@ -1063 +1063 @@ - cd $(srcdir); $(BISON) $(BISONFLAGS) -d c-parse.y -o c-parse.c + cd $(srcdir); $(BISON) -o c-parse.c $(BISONFLAGS) -d c-parse.y @@ -1125 +1125 @@ - cd $(srcdir); $(BISON) $(BISONFLAGS) objc-parse.y -o objc-parse.c + cd $(srcdir); $(BISON) -o objc-parse.c $(BISONFLAGS) objc-parse.y @@ -1561 +1561 @@ - cd $(srcdir); $(BISON) $(BISONFLAGS) -d bi-parser.y -o bi-parser.c + cd $(srcdir); $(BISON) -o bi-parser.c $(BISONFLAGS) -d bi-parser.y --- gnu/usr.bin/cc/cc1plus/Makefile.orig Thu Sep 25 19:59:10 1997 +++ gnu/usr.bin/cc/cc1plus/Makefile Fri Sep 26 09:55:45 1997 @@ -21 +21 @@ - ${BISON} -d ${GCCDIR}/cp/parse.y -o parse.c + ${BISON} -o parse.c -d ${GCCDIR}/cp/parse.y --- gnu/usr.bin/cc/cc_tools/Makefile.orig Thu Sep 25 19:59:15 1997 +++ gnu/usr.bin/cc/cc_tools/Makefile Fri Sep 26 09:30:23 1997 @@ -30 +30 @@ - ${BISON} ${BISONFLAGS} -d ${.ALLSRC} -o ${.TARGET} + ${BISON} ${BISONFLAGS} -o ${.TARGET} -d ${.ALLSRC} @@ -89 +89 @@ - ${BISON} -d c-parse.y -o c-parse.c + ${BISON} -o c-parse.c -d c-parse.y @@ -101 +101 @@ - ${BISON} -d objc-parse.y -o objc-parse.c + ${BISON} -o objc-parse.c -d objc-parse.y --- gnu/usr.bin/cc/cpp/Makefile.orig Thu Sep 25 19:59:15 1997 +++ gnu/usr.bin/cc/cpp/Makefile Fri Sep 26 09:54:40 1997 @@ -13 +13 @@ - ${BISON} -d ${GCCDIR}/cexp.y -o cexp.c + ${BISON} -o cexp.c -d ${GCCDIR}/cexp.y --- share/mk/bsd.info.mk.orig Thu Sep 25 20:03:17 1997 +++ share/mk/bsd.info.mk Fri Sep 26 17:55:53 1997 @@ -92,2 +92,2 @@ - ${MAKEINFO} ${MAKEINFOFLAGS} -I ${.CURDIR} -I ${SRCDIR} ${.IMPSRC} \ - -o ${.TARGET}.new + ${MAKEINFO} -o ${.TARGET}.new ${MAKEINFOFLAGS} \ + -I ${.CURDIR} -I ${SRCDIR} ${.IMPSRC} @@ -97,2 +97,2 @@ - ${MAKEINFO} ${MAKEINFOFLAGS} -I ${.CURDIR} -I ${SRCDIR} ${.IMPSRC} \ - -o ${.TARGET}.new + ${MAKEINFO} -o ${.TARGET}.new ${MAKEINFOFLAGS} \ + -I ${.CURDIR} -I ${SRCDIR} ${.IMPSRC} -- Carlo Dapor From owner-freebsd-current Fri Sep 26 12:02:30 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id MAA22304 for current-outgoing; Fri, 26 Sep 1997 12:02:30 -0700 (PDT) Received: from ox.ismi.net (root@ox.ismi.net [206.31.56.6]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id MAA22299 for ; Fri, 26 Sep 1997 12:02:25 -0700 (PDT) Received: from rhiannon.dyn.ml.org (mrr@pm5-16.ismi.net [207.51.208.187]) by ox.ismi.net (8.6.9/8.6.9) with SMTP id OAA12568 for ; Fri, 26 Sep 1997 14:55:36 -0400 Date: Fri, 26 Sep 1997 15:00:13 -0400 (EDT) From: "Michael R. Rudel" To: current@freebsd.org Subject: Make world Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I thought someone was going to fix src/Makefile so that if something happened somewhere along the line that caused it to barf and stop, that it would continue, and possibly email root or someone with a message? Just seems to be sort of..handy to me, since stupid stuff in make world seems to fail alot for me. Example: ===> games/sail In file included from /usr/src/games/sail/main.c:44: /usr/src/games/sail/externs.h:305: conflicting types for `calloc' /usr/obj/usr/src/tmp/usr/include/stdlib.h:93: previous declaration of `calloc' cc -nostdinc -O -I/usr/obj/usr/src/tmp/usr/include -c /usr/src/games/sail/main.c Thanks, just wondering. -- Michael R. Rudel -=- FreeBSD: There are no limits -=- mrr@rhiannon.dyn.ml.org FreeBSD rhiannon.dyn.ml.org 3.0-CURRENT Rhiannon rings like a star through the night ... and you wouldn't you love to love her? Takes to the sky like a bird in flight ... and who will be her lover? - Rhiannon (Fleetwood Mac) From owner-freebsd-current Fri Sep 26 12:46:22 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id MAA24155 for current-outgoing; Fri, 26 Sep 1997 12:46:22 -0700 (PDT) Received: from mexico.brainstorm.eu.org (root@mexico.brainstorm.fr [193.56.58.253]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id MAA24139 for ; Fri, 26 Sep 1997 12:46:16 -0700 (PDT) Received: from brasil.brainstorm.eu.org (brasil.brainstorm.fr [193.56.58.33]) by mexico.brainstorm.eu.org (8.8.4/8.8.4) with ESMTP id VAA18750 for ; Fri, 26 Sep 1997 21:46:19 +0200 Received: (from uucp@localhost) by brasil.brainstorm.eu.org (8.8.6/brasil-1.2) with UUCP id VAA18630 for freebsd-current@FreeBSD.ORG; Fri, 26 Sep 1997 21:45:38 +0200 Received: (from roberto@localhost) by keltia.freenix.fr (8.8.7/keltia-2.10/nospam) id VAA04188; Fri, 26 Sep 1997 21:45:24 +0200 (CEST) Message-ID: <19970926214523.57844@keltia.freenix.fr> Date: Fri, 26 Sep 1997 21:45:23 +0200 From: Ollivier Robert To: "FreeBSD Current Users' list" Subject: K6 bug possible workaround Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84 X-Operating-System: FreeBSD 3.0-CURRENT Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk The guy who maintaining the page about the K6 bug has found a workaround. It seems that if A is in a code page and A + 32 MB is a data page, then the bug can occur. More details at Now, we have page coloring I think in FreeBSD, could a similar workaround be tried ? -- Ollivier ROBERT -=- FreeBSD: There are no limits -=- roberto@keltia.freenix.fr FreeBSD keltia.freenix.fr 3.0-CURRENT #35: Sun Sep 21 19:28:07 CEST 1997 From owner-freebsd-current Fri Sep 26 14:58:55 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id OAA01102 for current-outgoing; Fri, 26 Sep 1997 14:58:55 -0700 (PDT) Received: from sendero-ppp.i-connect.net (sendero-ppp.i-Connect.Net [206.190.143.100]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id OAA01095 for ; Fri, 26 Sep 1997 14:58:47 -0700 (PDT) Received: (qmail 26608 invoked by uid 1000); 26 Sep 1997 21:58:58 -0000 Message-ID: X-Mailer: XFMail 1.2-alpha-092397 [p0] on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit MIME-Version: 1.0 Date: Fri, 26 Sep 1997 14:58:58 -0700 (PDT) Organization: Atlas Telecom From: Simon Shapiro To: freebsd-current@freebsd.org Subject: Make Release failures Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi Y'all, Although ``make world'' works flawlessly, ``make release'' still has difficulties. I have a sneaking suspicion that these can be fixed without much troulbe and that they are a result of recent changes: 1. Strange problem with the locale construction. If you ``make world'' immediately prior to building a release, it works. If you do not, it blows up: ===> share/timedef/data for l in da_DK.ISO_8859-1 de_AT.ISO_8859-1 de_DE.ISO_8859-1 en_GB.ISO_8859-1 en_US.ISO_8859-1 fr_FR.ISO_8859-1 hr_HR.ISO_8859-2 is_IS.ISO_8859-1 ja_JP.SJIS it_IT.ISO_8859-1 ko_KR.EUC no_NO.ISO_8859-1 pt_PT.ISO_8859-1 ru_SU.CP866 ru_SU.KOI8-R; do install -c -m 644 -o bin -g bin $l.out /Targets/3.0-970921-SNAP/usr/share/locale/$l/LC_TIME; done install: /Targets/3.0-970921-SNAP/usr/share/locale/ja_JP.SJIS/LC_TIME: No such file or directory *** Error code 71 Stop. *** Error code 1 This is only an example! It can actually blow up in different spots in this area. To me it means that there is some host dependancy that probably should not be there. 2. Something in the PPP code broke. I have seen this before, then it went away (around 27-Aug-97) and now it looks like we contracted it again: cc -O2 -pipe -DCRUNCHED_BINARY -c mount_nfs_stub.c ld -dc -r -o mount_nfs.lo mount_nfs_stub.o /usr/obj//usr/src/sbin/mount_nfs/mount_nfs.o /usr/obj//usr/src/sbin/mount_nfs/getmntopts.o crunchide -k __crunched_mount_nfs_stub mount_nfs.lo cc -static -o boot_crunch boot_crunch.o sh.lo find.lo pwd.lo ft.lo ppp.lo sysinstall.lo newfs.lo gzip.lo cpio.lo bad144.lo fsck.lo ifconfig.lo route.lo slattach.lo mount_nfs.lo -ll -ledit -lutil -lkvm -lmd -lcrypt -lftpio -lalias -ldialog -lncurses -lmytinfo -L/usr/src/release/libdisk/obj -ldisk -lipx ppp.lo: Undefined symbol `_des_set_key' referenced from text segment ppp.lo: Undefined symbol `_des_ecb_encrypt' referenced from text segment ppp.lo: Undefined symbol `_des_set_odd_parity' referenced from text segment *** Error code 1 (continuing) `all' not remade because of errors. mv: rename boot_crunch/boot_crunch to /R/stage/crunch/boot: No such file or directory *** Error code 1 (continuing) This leaves the ``R'' area on the release build sort of sparse :-) 3. I posted a panic scenario for SMP. Steve probably dod not have a chance to whack this problem yet. If someone gives me some pointers on how to chase it down, I will. Gladly. --- Sincerely Yours, Simon Shapiro Atlas Telecom Senior Architect 14355 SW Allen Blvd., Suite 130 Beaverton OR 97005 Shimon@i-Connect.Net Voice: 503.799.2313 From owner-freebsd-current Fri Sep 26 15:31:12 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id PAA02856 for current-outgoing; Fri, 26 Sep 1997 15:31:12 -0700 (PDT) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.54]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id PAA02849 for ; Fri, 26 Sep 1997 15:31:08 -0700 (PDT) Received: (from kargl@localhost) by troutmask.apl.washington.edu (8.8.7/8.8.5) id PAA15993 for freebsd-current@freebsd.org; Fri, 26 Sep 1997 15:33:21 -0700 (PDT) From: "Steven G. Kargl" Message-Id: <199709262233.PAA15993@troutmask.apl.washington.edu> Subject: make buildworld dies again To: freebsd-current@freebsd.org Date: Fri, 26 Sep 1997 15:33:20 -0700 (PDT) X-Mailer: ELM [version 2.4ME+ PL32 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk c -nostdinc -O2 -m486 -pipe -I/freebsd/src/usr.bin/systat/../../sys -I/freebsd/src/usr.bin/systat/../vmstat -I/freebsd/obj/freebsd/src/tmp/usr/include -c /freebsd/src/usr.bin/systat/mode.c cc -nostdinc -O2 -m486 -pipe -I/freebsd/src/usr.bin/systat/../../sys -I/freebsd/src/usr.bin/systat/../vmstat -I/freebsd/obj/freebsd/src/tmp/usr/include -c /freebsd/src/usr.bin/systat/ip.c /freebsd/src/usr.bin/systat/ip.c: In function `initip': /freebsd/src/usr.bin/systat/ip.c:259: `IPCTL_STATS' undeclared (first use this function) /freebsd/src/usr.bin/systat/ip.c:259: (Each undeclared identifier is reported only once /freebsd/src/usr.bin/systat/ip.c:259: for each function it appears in.) /freebsd/src/usr.bin/systat/ip.c: In function `resetip': /freebsd/src/usr.bin/systat/ip.c:303: `IPCTL_STATS' undeclared (first use this function) /freebsd/src/usr.bin/systat/ip.c: In function `fetchip': /freebsd/src/usr.bin/systat/ip.c:329: `IPCTL_STATS' undeclared (first use this function) *** Error code 1 Stop. *** Error code 1 cvsup'd -current this morning. In the past 2 days, several different show stoppers have been committed to the repository. Is there a requirement that a committer actually tests his/her commits?!! -- Steve finger kargl@troutmask.apl.washington.edu http://troutmask.apl.washington.edu/~kargl/sgk.html From owner-freebsd-current Fri Sep 26 17:40:51 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id RAA10149 for current-outgoing; Fri, 26 Sep 1997 17:40:51 -0700 (PDT) Received: from time.cdrom.com (root@time.cdrom.com [204.216.27.226]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id RAA10142 for ; Fri, 26 Sep 1997 17:40:48 -0700 (PDT) Received: from time.cdrom.com (jkh@localhost.cdrom.com [127.0.0.1]) by time.cdrom.com (8.8.7/8.6.9) with ESMTP id RAA14469; Fri, 26 Sep 1997 17:40:16 -0700 (PDT) To: Simon Shapiro cc: freebsd-current@FreeBSD.ORG Subject: Re: Make Release failures In-reply-to: Your message of "Fri, 26 Sep 1997 14:58:58 PDT." Date: Fri, 26 Sep 1997 17:40:16 -0700 Message-ID: <14465.875320816@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > 1. Strange problem with the locale construction. If you ``make world'' > immediately prior to building a release, it works. If you do not, it > blows up: A `make world' prior to making a release has always been a prerequisite. This is not a bug. > 2. Something in the PPP code broke. I have seen this before, then it went > away (around 27-Aug-97) and now it looks like we contracted it again: Naw, it's just a missing -ldes in the boot_crunch file since ppp recently contracted a need to link with the DES code in order to support Microsoft's authentication crapola. Already fixed. > 3. I posted a panic scenario for SMP. Steve probably dod not have a > chance to whack this problem yet. I think Steve's out of the SMP business for awhile - he had to go find other work. Jordan From owner-freebsd-current Fri Sep 26 19:35:39 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id TAA17476 for current-outgoing; Fri, 26 Sep 1997 19:35:39 -0700 (PDT) Received: from peeper.my.domain ([208.128.8.69]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id TAA17466 for ; Fri, 26 Sep 1997 19:35:33 -0700 (PDT) Received: (from tom@localhost) by peeper.my.domain (8.8.7/8.7.3) id VAA00852; Fri, 26 Sep 1997 21:35:05 -0500 (CDT) Message-ID: <19970926213505.33301@my.domain> Date: Fri, 26 Sep 1997 21:35:05 -0500 From: Tom Jackson To: FreeBSD Current Subject: Is this bad performance? Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.81e Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I'm running current up to date. Recently, besides the games and ctype.h breakage I've noticed something that may be something maybe not. Some time ago I built john (the ripper) to play with password cracking. Ever now and then I would start it up working on a local password file. I knew it took up a lot of resources but never really noticed it running before. Lately, if I started it up my console response went to the basement. Echo time for a character from keyboard to screen is something 3-5 seconds. This is with a nice of 20. Walking a find through /usr gives 10:18.29 with john running and 5:37.04 with it not running. This doesn't seem so drastic as the console behavior. BTW I'm running pcvt. Maybe someone with the time would care to replicate this. Is this bad performance or what? Tom From owner-freebsd-current Fri Sep 26 22:16:33 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id WAA26707 for current-outgoing; Fri, 26 Sep 1997 22:16:33 -0700 (PDT) Received: from comp.polyu.edu.hk (csns02.COMP.POLYU.EDU.HK [158.132.25.95]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id WAA26701 for ; Fri, 26 Sep 1997 22:16:29 -0700 (PDT) Received: from cssolar15.COMP.HKP.HK by comp.polyu.edu.hk (SMI-8.6/SMI-SVR4) id NAA25328; Sat, 27 Sep 1997 13:16:36 +0800 Received: (from c5666305@localhost) by cssolar15.COMP.HKP.HK (SMI-8.6/) id NAA04588 for current@freebsd.org; Sat, 27 Sep 1997 13:16:35 +0800 Message-Id: <199709270516.NAA04588@cssolar15.COMP.HKP.HK> Subject: testing. please ignore it To: current@freebsd.org Date: Sat, 27 Sep 1997 13:16:35 +0800 (HKT) From: "c5666305" X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hello This is a testing, please ignore it. Thanks. Clarence From owner-freebsd-current Fri Sep 26 22:26:27 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id WAA27542 for current-outgoing; Fri, 26 Sep 1997 22:26:27 -0700 (PDT) Received: from Kitten.mcs.com (Kitten.mcs.com [192.160.127.90]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id WAA27537 for ; Fri, 26 Sep 1997 22:26:25 -0700 (PDT) Received: from Mars.mcs.net (karl@Mars.mcs.net [192.160.127.85]) by Kitten.mcs.com (8.8.5/8.8.2) with ESMTP id AAA06358 for ; Sat, 27 Sep 1997 00:26:24 -0500 (CDT) Received: (from karl@localhost) by Mars.mcs.net (8.8.7/8.8.2) id AAA08356; Sat, 27 Sep 1997 00:26:23 -0500 (CDT) Message-ID: <19970927002623.46235@Mars.Mcs.Net> Date: Sat, 27 Sep 1997 00:26:23 -0500 From: Karl Denninger To: current@freebsd.org Subject: WARNING! Builds from the last few days have BROKEN NFS Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.64 Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk WARNING! All -current builds from the last few days have BROKEN NFS client code. The symptom is hung jobs during file lookups. Once it happens, any lookup for that filename also hangs (even from a different process). Eventually, if you're not watching the store, you'll run out of either page space or process slots (or both). This is a particularly nasty problem. I have as of yet been unable to isolate the rogue commit which caused this. A kernel extracted from one week ago (Sept 20th) DOES NOT exhibit the problem. There were a boatload of files in the kernel structure changed between those two dates; I don't know which commit(s) are responsible for this, but its a nasty problem and one which all -current users should be aware of. AGAIN - AS OF RIGHT NOW, NFS IS BROKEN TO THE POINT OF BEING BASICALLY USELESS IN -CURRENT. Roll back one week (to Sept 19th/20th) if you need working NFS clients in your kernels! -- -- Karl Denninger (karl@MCS.Net)| MCSNet - Serving Chicagoland and Wisconsin http://www.mcs.net/~karl | T1's from $600 monthly to FULL DS-3 Service | NEW! K56Flex modem support is now available Voice: [+1 312 803-MCS1 x219]| 56kbps DIGITAL ISDN DOV on analog lines! Fax: [+1 312 803-4929] | 2 FULL DS-3 Internet links; 400Mbps B/W Internal From owner-freebsd-current Sat Sep 27 00:00:21 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id AAA04229 for current-outgoing; Sat, 27 Sep 1997 00:00:21 -0700 (PDT) Received: from critter.freebsd.dk (critter.freebsd.dk [195.8.129.26]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id AAA04166 for ; Sat, 27 Sep 1997 00:00:10 -0700 (PDT) Received: from critter.freebsd.dk (localhost.cybercity.dk [127.0.0.1]) by critter.freebsd.dk (8.8.7/8.8.7) with ESMTP id IAA04556; Sat, 27 Sep 1997 08:59:21 +0200 (CEST) To: Karl Denninger cc: current@freebsd.org Subject: Re: WARNING! Builds from the last few days have BROKEN NFS In-reply-to: Your message of "Sat, 27 Sep 1997 00:26:23 CDT." <19970927002623.46235@Mars.Mcs.Net> Date: Sat, 27 Sep 1997 08:59:19 +0200 Message-ID: <4554.875343559@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In message <19970927002623.46235@Mars.Mcs.Net>, Karl Denninger writes: >WARNING! > >All -current builds from the last few days have BROKEN NFS client code. Please try sysctl -w debug.wantfreevnodes=0 -- Poul-Henning Kamp FreeBSD coreteam member phk@FreeBSD.ORG "Real hackers run -current on their laptop." From owner-freebsd-current Sat Sep 27 03:13:14 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id DAA15530 for current-outgoing; Sat, 27 Sep 1997 03:13:14 -0700 (PDT) Received: from news1.gtn.com (news1.gtn.com [192.109.159.3]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id DAA15518 for ; Sat, 27 Sep 1997 03:13:03 -0700 (PDT) Received: (from uucp@localhost) by news1.gtn.com (8.8.6/8.8.6) with UUCP id MAA18365; Sat, 27 Sep 1997 12:00:07 +0200 (MET DST) Received: (from andreas@localhost) by klemm.gtn.com (8.8.7/8.8.7) id LAA28193; Sat, 27 Sep 1997 11:44:08 +0200 (CEST) Message-ID: <19970927114408.01416@klemm.gtn.com> Date: Sat, 27 Sep 1997 11:44:08 +0200 From: Andreas Klemm To: "Michael R. Rudel" Cc: current@FreeBSD.ORG Subject: Re: Make world References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.81 In-Reply-To: ; from Michael R. Rudel on Fri, Sep 26, 1997 at 03:00:13PM -0400 X-Disclaimer: A free society is one where it is safe to be unpopular X-Operating-System: FreeBSD 3.0-CURRENT SMP Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Fri, Sep 26, 1997 at 03:00:13PM -0400, Michael R. Rudel wrote: > I thought someone was going to fix src/Makefile so that if something > happened somewhere along the line that caused it to barf and stop, that it > would continue, and possibly email root or someone with a message? Just > seems to be sort of..handy to me, since stupid stuff in make world seems > to fail alot for me. Example: > > ===> games/sail > In file included from /usr/src/games/sail/main.c:44: > /usr/src/games/sail/externs.h:305: conflicting types for `calloc' > /usr/obj/usr/src/tmp/usr/include/stdlib.h:93: previous declaration of `calloc' > cc -nostdinc -O -I/usr/obj/usr/src/tmp/usr/include -c /usr/src/games/sail/main.c Already fixed if you read the commit logs. -- Andreas Klemm | klemm.gtn.com - powered by Symmetric MultiProcessor FreeBSD http://www.freebsd.org/~fsmp/SMP/SMP.html http://www.freebsd.org/~fsmp/SMP/benches.html From owner-freebsd-current Sat Sep 27 07:51:33 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id HAA25643 for current-outgoing; Sat, 27 Sep 1997 07:51:33 -0700 (PDT) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id HAA25635 for ; Sat, 27 Sep 1997 07:51:06 -0700 (PDT) Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id QAA22402; Sat, 27 Sep 1997 16:50:49 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.8.7/8.8.5) id QAA16991; Sat, 27 Sep 1997 16:22:15 +0200 (MET DST) Message-ID: <19970927162215.PD07211@uriah.heep.sax.de> Date: Sat, 27 Sep 1997 16:22:15 +0200 From: j@uriah.heep.sax.de (J Wunsch) To: current@FreeBSD.ORG Cc: nwestfal@Vorlon.odc.net (Neal Westfall) Subject: Re: The 3.0-970920-SNAP CD has been canceled References: <3744.875218930@time.cdrom.com> X-Mailer: Mutt 0.60_p2-3,5,8-9 Mime-Version: 1.0 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: ; from Neal Westfall on Sep 25, 1997 14:18:33 -0700 Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk As Neal Westfall wrote: > Does anyone know when the last good snapshot was? I want to > install a fairly current snapshot on my machine that is newer > than the last "official" snapshot. I'm happy so far with a system built right before Justin's timeout changes hit the tree, that is from Sep 19. -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-current Sat Sep 27 08:20:55 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id IAA26880 for current-outgoing; Sat, 27 Sep 1997 08:20:55 -0700 (PDT) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id IAA26870 for ; Sat, 27 Sep 1997 08:20:50 -0700 (PDT) Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id RAA22610 for freebsd-current@FreeBSD.ORG; Sat, 27 Sep 1997 17:20:49 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.8.7/8.8.5) id RAA17123; Sat, 27 Sep 1997 17:09:29 +0200 (MET DST) Message-ID: <19970927170929.QR36164@uriah.heep.sax.de> Date: Sat, 27 Sep 1997 17:09:29 +0200 From: j@uriah.heep.sax.de (J Wunsch) To: freebsd-current@FreeBSD.ORG Subject: Re: Make Release failures References: X-Mailer: Mutt 0.60_p2-3,5,8-9 Mime-Version: 1.0 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: ; from Simon Shapiro on Sep 26, 1997 14:58:58 -0700 Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk As Simon Shapiro wrote: > ===> share/timedef/data > for l in da_DK.ISO_8859-1 de_AT.ISO_8859-1 de_DE.ISO_8859-1 > en_GB.ISO_8859-1 en_US.ISO_8859-1 fr_FR.ISO_8859-1 hr_HR.ISO_8859-2 > is_IS.ISO_8859-1 ja_JP.SJIS it_IT.ISO_8859-1 ko_KR.EUC > no_NO.ISO_8859-1 pt_PT.ISO_8859-1 ru_SU.CP866 ru_SU.KOI8-R; do > install -c -m 644 -o bin -g bin $l.out > /Targets/3.0-970921-SNAP/usr/share/locale/$l/LC_TIME; done > install: /Targets/3.0-970921-SNAP/usr/share/locale/ja_JP.SJIS/LC_TIME: No > such file or directory > *** Error code 71 This has supposedly been fixed by Andrey on: revision 1.100 date: 1997/09/25 23:57:53; author: ache; state: Exp; lines: +3 -1 Add missing SJIS and pl_PL entries (src/etc/mtree/BSD.usr.dist, in case you wonder) -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-current Sat Sep 27 08:24:24 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id IAA27068 for current-outgoing; Sat, 27 Sep 1997 08:24:24 -0700 (PDT) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id IAA26973 for ; Sat, 27 Sep 1997 08:22:12 -0700 (PDT) Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id RAA22612 for freebsd-current@FreeBSD.ORG; Sat, 27 Sep 1997 17:20:54 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.8.7/8.8.5) id RAA17136; Sat, 27 Sep 1997 17:12:45 +0200 (MET DST) Message-ID: <19970927171245.WM37928@uriah.heep.sax.de> Date: Sat, 27 Sep 1997 17:12:45 +0200 From: j@uriah.heep.sax.de (J Wunsch) To: freebsd-current@FreeBSD.ORG Subject: Re: Make Release failures References: <14465.875320816@time.cdrom.com> X-Mailer: Mutt 0.60_p2-3,5,8-9 Mime-Version: 1.0 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <14465.875320816@time.cdrom.com>; from Jordan K. Hubbard on Sep 26, 1997 17:40:16 -0700 Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk As Jordan K. Hubbard wrote: > > 1. Strange problem with the locale construction. If you ``make world'' > > immediately prior to building a release, it works. If you do not, it > > blows up: > > A `make world' prior to making a release has always been a prerequisite. > This is not a bug. Huh? Never did it... :-) Can't work for cross-release buildings anyway (i.e., 2.2 under -current, or vice versa). Btw., Simon, i always run `make release' as `make -k release'. Failures in the initial bootstrapping stages are often not fatal, as long as the complete rebuild inside the chroot'ed tree works cleanly. I examine the buildlog afterwards to see whether i can trust the build or not. -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-current Sat Sep 27 09:00:18 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id JAA28917 for current-outgoing; Sat, 27 Sep 1997 09:00:18 -0700 (PDT) Received: from critter.freebsd.dk (critter.freebsd.dk [195.8.129.26]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id JAA28911 for ; Sat, 27 Sep 1997 09:00:13 -0700 (PDT) Received: from critter.freebsd.dk (localhost.cybercity.dk [127.0.0.1]) by critter.freebsd.dk (8.8.7/8.8.7) with ESMTP id RAA05746; Sat, 27 Sep 1997 17:59:27 +0200 (CEST) To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) cc: current@FreeBSD.ORG, nwestfal@Vorlon.odc.net (Neal Westfall) Subject: Re: The 3.0-970920-SNAP CD has been canceled In-reply-to: Your message of "Sat, 27 Sep 1997 16:22:15 +0200." <19970927162215.PD07211@uriah.heep.sax.de> Date: Sat, 27 Sep 1997 17:59:26 +0200 Message-ID: <5744.875375966@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk In message <19970927162215.PD07211@uriah.heep.sax.de>, J Wunsch writes: >As Neal Westfall wrote: > >> Does anyone know when the last good snapshot was? I want to >> install a fairly current snapshot on my machine that is newer >> than the last "official" snapshot. > >I'm happy so far with a system built right before Justin's timeout >changes hit the tree, that is from Sep 19. This one suffers from whatever bogosity it is that makes kernel fold under sysinstall when it gets to makedev and thereabout... -- Poul-Henning Kamp FreeBSD coreteam member phk@FreeBSD.ORG "Real hackers run -current on their laptop." From owner-freebsd-current Sat Sep 27 09:15:58 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id JAA29668 for current-outgoing; Sat, 27 Sep 1997 09:15:58 -0700 (PDT) Received: from critter.freebsd.dk (critter.freebsd.dk [195.8.129.26]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id JAA29660 for ; Sat, 27 Sep 1997 09:15:45 -0700 (PDT) Received: from critter.freebsd.dk (localhost.cybercity.dk [127.0.0.1]) by critter.freebsd.dk (8.8.7/8.8.7) with ESMTP id SAA05888; Sat, 27 Sep 1997 18:14:47 +0200 (CEST) To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) cc: freebsd-current@freebsd.org Subject: Re: Make Release failures In-reply-to: Your message of "Sat, 27 Sep 1997 17:12:45 +0200." <19970927171245.WM37928@uriah.heep.sax.de> Date: Sat, 27 Sep 1997 18:14:47 +0200 Message-ID: <5886.875376887@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In message <19970927171245.WM37928@uriah.heep.sax.de>, J Wunsch writes: >As Jordan K. Hubbard wrote: > >> > 1. Strange problem with the locale construction. If you ``make world'' >> > immediately prior to building a release, it works. If you do not, it >> > blows up: >> >> A `make world' prior to making a release has always been a prerequisite. >> This is not a bug. > >Huh? Never did it... :-) Can't work for cross-release buildings >anyway (i.e., 2.2 under -current, or vice versa). Well, yes and no. You need to be able to populate the chroot tree with enough stuff that it can actually get airborne. Back in 2.1ish days I tried to se how little we could get away with (sh, cc, make, as, ld what's missing next ? ok, sed, awk, strip, ranlib ? ...) Unfortunately our makefiles and tools are quite creative so when this list exceeded 50 files I gave up. If somebody wants to try going through this again, we could improve "make release" quite a lot in both time and quality. Basically the trick is: modify src/release/Makefile to not blankly install everything into the chroot tree. make release while it doesn't work add the missing files in src/release/Makefile make release end Remember that the best way would be to populate only the minimal number of files from the "outside source", and as soon as you have enough tools, build them from the release-to-be sources inside the chroot. -- Poul-Henning Kamp FreeBSD coreteam member phk@FreeBSD.ORG "Real hackers run -current on their laptop." From owner-freebsd-current Sat Sep 27 09:30:46 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id JAA00502 for current-outgoing; Sat, 27 Sep 1997 09:30:46 -0700 (PDT) Received: from mexico.brainstorm.eu.org (root@mexico.brainstorm.fr [193.56.58.253]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id JAA00496 for ; Sat, 27 Sep 1997 09:30:43 -0700 (PDT) Received: from brasil.brainstorm.eu.org (brasil.brainstorm.fr [193.56.58.33]) by mexico.brainstorm.eu.org (8.8.4/8.8.4) with ESMTP id SAA20886 for ; Sat, 27 Sep 1997 18:31:10 +0200 Received: (from uucp@localhost) by brasil.brainstorm.eu.org (8.8.6/brasil-1.2) with UUCP id SAA21480 for current@FreeBSD.ORG; Sat, 27 Sep 1997 18:30:37 +0200 Received: (from roberto@localhost) by keltia.freenix.fr (8.8.7/keltia-2.10/nospam) id SAA07753; Sat, 27 Sep 1997 18:28:33 +0200 (CEST) Message-ID: <19970927182833.29093@keltia.freenix.fr> Date: Sat, 27 Sep 1997 18:28:33 +0200 From: Ollivier Robert To: current@FreeBSD.ORG Subject: Re: The 3.0-970920-SNAP CD has been canceled References: <3744.875218930@time.cdrom.com> <19970927162215.PD07211@uriah.heep.sax.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84 In-Reply-To: <19970927162215.PD07211@uriah.heep.sax.de>; from J Wunsch on Sat, Sep 27, 1997 at 04:22:15PM +0200 X-Operating-System: FreeBSD 3.0-CURRENT Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk According to J Wunsch: > I'm happy so far with a system built right before Justin's timeout > changes hit the tree, that is from Sep 19. Mine is from Sep. 21st (see the .sig) and has been happily running since. 287 [18:27] root@keltia:/etc/mail# uptime 6:28PM up 5 days, 21:18, 4 users, load averages: 0.05, 0.09, 0.11 -- Ollivier ROBERT -=- FreeBSD: There are no limits -=- roberto@keltia.freenix.fr FreeBSD keltia.freenix.fr 3.0-CURRENT #35: Sun Sep 21 19:28:07 CEST 1997 From owner-freebsd-current Sat Sep 27 10:49:22 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id KAA04401 for current-outgoing; Sat, 27 Sep 1997 10:49:22 -0700 (PDT) Received: from Kitten.mcs.com (Kitten.mcs.com [192.160.127.90]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id KAA04394 for ; Sat, 27 Sep 1997 10:49:19 -0700 (PDT) Received: from Mars.mcs.net (karl@Mars.mcs.net [192.160.127.85]) by Kitten.mcs.com (8.8.5/8.8.2) with ESMTP id MAA24779; Sat, 27 Sep 1997 12:49:17 -0500 (CDT) Received: (from karl@localhost) by Mars.mcs.net (8.8.7/8.8.2) id MAA26231; Sat, 27 Sep 1997 12:49:17 -0500 (CDT) Message-ID: <19970927124917.57478@Mars.Mcs.Net> Date: Sat, 27 Sep 1997 12:49:17 -0500 From: Karl Denninger To: Poul-Henning Kamp Cc: Karl Denninger , current@freebsd.org Subject: Re: WARNING! Builds from the last few days have BROKEN NFS References: <19970927002623.46235@Mars.Mcs.Net> <4554.875343559@critter.freebsd.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.64 In-Reply-To: <4554.875343559@critter.freebsd.dk>; from Poul-Henning Kamp on Sat, Sep 27, 1997 at 08:59:19AM +0200 Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Sat, Sep 27, 1997 at 08:59:19AM +0200, Poul-Henning Kamp wrote: > In message <19970927002623.46235@Mars.Mcs.Net>, Karl Denninger writes: > >WARNING! > > > >All -current builds from the last few days have BROKEN NFS client code. > > Please try > sysctl -w debug.wantfreevnodes=0 > -- > Poul-Henning Kamp FreeBSD coreteam member > phk@FreeBSD.ORG "Real hackers run -current on their laptop." What effect does that cause? -- -- Karl Denninger (karl@MCS.Net)| MCSNet - Serving Chicagoland and Wisconsin http://www.mcs.net/~karl | T1's from $600 monthly to FULL DS-3 Service | NEW! K56Flex modem support is now available Voice: [+1 312 803-MCS1 x219]| 56kbps DIGITAL ISDN DOV on analog lines! Fax: [+1 312 803-4929] | 2 FULL DS-3 Internet links; 400Mbps B/W Internal From owner-freebsd-current Sat Sep 27 11:12:09 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id LAA05390 for current-outgoing; Sat, 27 Sep 1997 11:12:09 -0700 (PDT) Received: from critter.freebsd.dk (critter.freebsd.dk [195.8.129.26]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id LAA05385 for ; Sat, 27 Sep 1997 11:12:06 -0700 (PDT) Received: from critter.freebsd.dk (localhost.cybercity.dk [127.0.0.1]) by critter.freebsd.dk (8.8.7/8.8.7) with ESMTP id UAA06981; Sat, 27 Sep 1997 20:11:20 +0200 (CEST) To: Karl Denninger cc: current@freebsd.org Subject: Re: WARNING! Builds from the last few days have BROKEN NFS In-reply-to: Your message of "Sat, 27 Sep 1997 12:49:17 CDT." <19970927124917.57478@Mars.Mcs.Net> Date: Sat, 27 Sep 1997 20:11:20 +0200 Message-ID: <6979.875383880@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In message <19970927124917.57478@Mars.Mcs.Net>, Karl Denninger writes: >On Sat, Sep 27, 1997 at 08:59:19AM +0200, Poul-Henning Kamp wrote: >> In message <19970927002623.46235@Mars.Mcs.Net>, Karl Denninger writes: >> >WARNING! >> > >> >All -current builds from the last few days have BROKEN NFS client code. >> >> Please try >> sysctl -w debug.wantfreevnodes=0 >> -- >> Poul-Henning Kamp FreeBSD coreteam member >> phk@FreeBSD.ORG "Real hackers run -current on their laptop." > >What effect does that cause? A much higher number of vnodes in the system, about half of which will be on the freelist. This was the default until a couple of weeks ago. -- Poul-Henning Kamp FreeBSD coreteam member phk@FreeBSD.ORG "Real hackers run -current on their laptop." From owner-freebsd-current Sat Sep 27 11:23:24 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id LAA05753 for current-outgoing; Sat, 27 Sep 1997 11:23:24 -0700 (PDT) Received: from Kitten.mcs.com (Kitten.mcs.com [192.160.127.90]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id LAA05748 for ; Sat, 27 Sep 1997 11:23:19 -0700 (PDT) Received: from Mars.mcs.net (karl@Mars.mcs.net [192.160.127.85]) by Kitten.mcs.com (8.8.5/8.8.2) with ESMTP id NAA25448; Sat, 27 Sep 1997 13:23:19 -0500 (CDT) Received: (from karl@localhost) by Mars.mcs.net (8.8.7/8.8.2) id NAA26982; Sat, 27 Sep 1997 13:23:18 -0500 (CDT) Message-ID: <19970927132318.04053@Mars.Mcs.Net> Date: Sat, 27 Sep 1997 13:23:18 -0500 From: Karl Denninger To: Poul-Henning Kamp Cc: Karl Denninger , current@freebsd.org Subject: Re: WARNING! Builds from the last few days have BROKEN NFS References: <19970927124917.57478@Mars.Mcs.Net> <6979.875383880@critter.freebsd.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.64 In-Reply-To: <6979.875383880@critter.freebsd.dk>; from Poul-Henning Kamp on Sat, Sep 27, 1997 at 08:11:20PM +0200 Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Sat, Sep 27, 1997 at 08:11:20PM +0200, Poul-Henning Kamp wrote: > In message <19970927124917.57478@Mars.Mcs.Net>, Karl Denninger writes: > >On Sat, Sep 27, 1997 at 08:59:19AM +0200, Poul-Henning Kamp wrote: > >> In message <19970927002623.46235@Mars.Mcs.Net>, Karl Denninger writes: > >> >WARNING! > >> > > >> >All -current builds from the last few days have BROKEN NFS client code. > >> > >> Please try > >> sysctl -w debug.wantfreevnodes=0 > >> -- > >> Poul-Henning Kamp FreeBSD coreteam member > >> phk@FreeBSD.ORG "Real hackers run -current on their laptop." > > > >What effect does that cause? > > A much higher number of vnodes in the system, about half of which will > be on the freelist. This was the default until a couple of weeks ago. Uh, the problem with that Paul is that a build from the sources as they existed on the 19th does *not* exhibit the problem (which is what I'm running now). I believe that the critical change actually occurred mid-week this last week when a set of files in the vm subdirectory were modified. I'd have to go back and check out update sets for each day, one at a time, until I found the critical day, but the last set of updates which appear to have affected this all came in one batch. Do you know precisely when this was changed? -- -- Karl Denninger (karl@MCS.Net)| MCSNet - Serving Chicagoland and Wisconsin http://www.mcs.net/~karl | T1's from $600 monthly to FULL DS-3 Service | NEW! K56Flex modem support is now available Voice: [+1 312 803-MCS1 x219]| 56kbps DIGITAL ISDN DOV on analog lines! Fax: [+1 312 803-4929] | 2 FULL DS-3 Internet links; 400Mbps B/W Internal From owner-freebsd-current Sat Sep 27 12:27:03 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id MAA08271 for current-outgoing; Sat, 27 Sep 1997 12:27:03 -0700 (PDT) Received: from sendero-ppp.i-connect.net (sendero-ppp.i-Connect.Net [206.190.143.100]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id MAA08261 for ; Sat, 27 Sep 1997 12:26:54 -0700 (PDT) Received: (qmail 28122 invoked by uid 1000); 27 Sep 1997 19:27:18 -0000 Message-ID: X-Mailer: XFMail 1.2-alpha-092397 [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: <19970927171245.WM37928@uriah.heep.sax.de> Date: Sat, 27 Sep 1997 12:27:18 -0700 (PDT) Organization: Atlas Telecom From: Simon Shapiro To: (Joerg Wunsch) Subject: Re: Make Release failures Cc: freebsd-current@FreeBSD.ORG Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hi J Wunsch; On 27-Sep-97 you wrote: > As Jordan K. Hubbard wrote: > > > > 1. Strange problem with the locale construction. If you ``make > > > world'' > > > immediately prior to building a release, it works. If you do > > > not, it > > > blows up: > > > > A `make world' prior to making a release has always been a > > prerequisite. > > This is not a bug. > > Huh? Never did it... :-) Can't work for cross-release buildings > anyway (i.e., 2.2 under -current, or vice versa). > > Btw., Simon, i always run `make release' as `make -k release'. > Failures in the initial bootstrapping stages are often not fatal, as > long as the complete rebuild inside the chroot'ed tree works cleanly. > I examine the buildlog afterwards to see whether i can trust the build > or not. The problem I reported was under ``make -k''. Last night's release buit cleanly. Now will it boot? Will it boot? Where is a ``victim'' machine? --- Sincerely Yours, Simon Shapiro Atlas Telecom Senior Architect 14355 SW Allen Blvd., Suite 130 Beaverton OR 97005 Shimon@i-Connect.Net Voice: 503.799.2313 From owner-freebsd-current Sat Sep 27 12:46:39 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id MAA09216 for current-outgoing; Sat, 27 Sep 1997 12:46:39 -0700 (PDT) Received: from ns.mt.sri.com (SRI-56K-FR.mt.net [206.127.65.42]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id MAA09209 for ; Sat, 27 Sep 1997 12:46:34 -0700 (PDT) Received: from rocky.mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.8.7/8.8.7) with ESMTP id NAA29989; Sat, 27 Sep 1997 13:42:25 -0600 (MDT) Received: (from nate@localhost) by rocky.mt.sri.com (8.7.5/8.7.3) id NAA27353; Sat, 27 Sep 1997 13:42:20 -0600 (MDT) Date: Sat, 27 Sep 1997 13:42:20 -0600 (MDT) Message-Id: <199709271942.NAA27353@rocky.mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Karl Denninger Cc: Poul-Henning Kamp , current@freebsd.org Subject: Re: WARNING! Builds from the last few days have BROKEN NFS In-Reply-To: <19970927132318.04053@Mars.Mcs.Net> References: <19970927124917.57478@Mars.Mcs.Net> <6979.875383880@critter.freebsd.dk> <19970927132318.04053@Mars.Mcs.Net> X-Mailer: VM 6.29 under 19.15 XEmacs Lucid Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Karl wrote: >All -current builds from the last few days have BROKEN NFS client code. Poul-Henning responded: > Please try > sysctl -w debug.wantfreevnodes=0 > Uh, the problem with that Paul is that a build from the sources as they ^^^^ Poul-Henning > existed on the 19th does *not* exhibit the problem (which is what I'm > running now). I believe that the critical change actually occurred mid-week > this last week when a set of files in the vm subdirectory were > modified. phk 1997/09/25 09:18:00 PDT Modified files: sys/kern vfs_subr.c Log: Reduce the target number of vnodes on the freelist from desiredvnodes (usually a couple of thousand) to 25. The measured impact on cache-hits doesn't justify spending memory this way: That was in the middle of the week, but wasn't in the VM system. 'Just do it, and quit 'yer arguing' :) :) :) :) Nate ps. Things like this are pretty trivial to find if you have the CVS tree. Go look at the $CVSROOT/CVSROOT/commitlog/sys, and search for '/1997/09/19', and look at the messages after that point. Other significant kernel changes this week including using the zone allocator for M_NAMEI (dyson), timeout changes (gibbs), SMP stuff (various), all of which are easily seen in the commitlogs. From owner-freebsd-current Sat Sep 27 12:51:43 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id MAA09473 for current-outgoing; Sat, 27 Sep 1997 12:51:43 -0700 (PDT) Received: from Kitten.mcs.com (Kitten.mcs.com [192.160.127.90]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id MAA09464 for ; Sat, 27 Sep 1997 12:51:37 -0700 (PDT) Received: from Mars.mcs.net (karl@Mars.mcs.net [192.160.127.85]) by Kitten.mcs.com (8.8.5/8.8.2) with ESMTP id OAA27384; Sat, 27 Sep 1997 14:51:32 -0500 (CDT) Received: (from karl@localhost) by Mars.mcs.net (8.8.7/8.8.2) id OAA29503; Sat, 27 Sep 1997 14:51:32 -0500 (CDT) Message-ID: <19970927145131.64000@Mars.Mcs.Net> Date: Sat, 27 Sep 1997 14:51:32 -0500 From: Karl Denninger To: Nate Williams Cc: Karl Denninger , Poul-Henning Kamp , current@freebsd.org Subject: Re: WARNING! Builds from the last few days have BROKEN NFS References: <19970927124917.57478@Mars.Mcs.Net> <6979.875383880@critter.freebsd.dk> <19970927132318.04053@Mars.Mcs.Net> <199709271942.NAA27353@rocky.mt.sri.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.64 In-Reply-To: <199709271942.NAA27353@rocky.mt.sri.com>; from Nate Williams on Sat, Sep 27, 1997 at 01:42:20PM -0600 Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Sat, Sep 27, 1997 at 01:42:20PM -0600, Nate Williams wrote: > Karl wrote: > >All -current builds from the last few days have BROKEN NFS client code. > > Poul-Henning responded: > > Please try > > sysctl -w debug.wantfreevnodes=0 > > > Uh, the problem with that Paul is that a build from the sources as they > ^^^^ > Poul-Henning > > > existed on the 19th does *not* exhibit the problem (which is what I'm > > running now). I believe that the critical change actually occurred mid-week > > this last week when a set of files in the vm subdirectory were > > modified. > > phk 1997/09/25 09:18:00 PDT > > Modified files: > sys/kern vfs_subr.c > Log: > Reduce the target number of vnodes on the freelist from desiredvnodes > (usually a couple of thousand) to 25. The measured impact on cache-hits > doesn't justify spending memory this way: > > That was in the middle of the week, but wasn't in the VM system. > > 'Just do it, and quit 'yer arguing' :) :) :) :) > > Nate > > ps. Things like this are pretty trivial to find if you have the CVS > tree. Go look at the $CVSROOT/CVSROOT/commitlog/sys, and search for > '/1997/09/19', and look at the messages after that point. Other > significant kernel changes this week including using the zone allocator > for M_NAMEI (dyson), timeout changes (gibbs), SMP stuff (various), all > of which are easily seen in the commitlogs. I understand how to find the commit logs :-) I also understand how to roll the change back with the "-D" option. What I don't understand is why this kind of change would have the effect that it is having. That is, why would reducing the target number of vnodes on the freelist lead to hangs in a disk wait ("D") which are unkillable? The SMP stuff is not relavent to me right now, because I'm not running an SMP system anywhere (yet) :-) I guess what I'm asking is how do we know that this really caused it? Is it not possible that the zone allocator changes are also responsible here? I'm trying to understand both the reason for the code changes and why they broke what was, until then, a reasonably stable kernel (there is still some odd stuff going on in the NFS code, and I'm using V1.41 of nfs_bio.c, as its the last one which is stable and doesn't lead to panics in NFS clients.) -- -- Karl Denninger (karl@MCS.Net)| MCSNet - Serving Chicagoland and Wisconsin http://www.mcs.net/~karl | T1's from $600 monthly to FULL DS-3 Service | NEW! K56Flex modem support is now available Voice: [+1 312 803-MCS1 x219]| 56kbps DIGITAL ISDN DOV on analog lines! Fax: [+1 312 803-4929] | 2 FULL DS-3 Internet links; 400Mbps B/W Internal From owner-freebsd-current Sat Sep 27 12:56:20 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id MAA09834 for current-outgoing; Sat, 27 Sep 1997 12:56:20 -0700 (PDT) Received: from critter.freebsd.dk (critter.freebsd.dk [195.8.129.26]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id MAA09821 for ; Sat, 27 Sep 1997 12:56:15 -0700 (PDT) Received: from critter.freebsd.dk (localhost.cybercity.dk [127.0.0.1]) by critter.freebsd.dk (8.8.7/8.8.7) with ESMTP id VAA13500; Sat, 27 Sep 1997 21:55:23 +0200 (CEST) To: Karl Denninger cc: Nate Williams , current@freebsd.org Subject: Re: WARNING! Builds from the last few days have BROKEN NFS In-reply-to: Your message of "Sat, 27 Sep 1997 14:51:32 CDT." <19970927145131.64000@Mars.Mcs.Net> Date: Sat, 27 Sep 1997 21:55:23 +0200 Message-ID: <13496.875390123@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >> >> 'Just do it, and quit 'yer arguing' :) :) :) :) > >What I don't understand is why this kind of change would have the effect >that it is having. That is, why would reducing the target number of vnodes >on the freelist lead to hangs in a disk wait ("D") which are unkillable? Karl, neither do any of us at this time. We may be pretty good wizards, but we're not gods any of us. We need more data, and that involves you doing as we say in an attempt to figure out what the heck is going on. I'm running a make buildworld across NFS right now, but so far I see no trouble along the lines of what you found. -- Poul-Henning Kamp FreeBSD coreteam member phk@FreeBSD.ORG "Real hackers run -current on their laptop." From owner-freebsd-current Sat Sep 27 13:08:08 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id NAA10692 for current-outgoing; Sat, 27 Sep 1997 13:08:08 -0700 (PDT) Received: from Kitten.mcs.com (Kitten.mcs.com [192.160.127.90]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id NAA10686 for ; Sat, 27 Sep 1997 13:08:04 -0700 (PDT) Received: from Mars.mcs.net (karl@Mars.mcs.net [192.160.127.85]) by Kitten.mcs.com (8.8.5/8.8.2) with ESMTP id PAA27744; Sat, 27 Sep 1997 15:07:55 -0500 (CDT) Received: (from karl@localhost) by Mars.mcs.net (8.8.7/8.8.2) id PAA29967; Sat, 27 Sep 1997 15:07:55 -0500 (CDT) Message-ID: <19970927150755.39452@Mars.Mcs.Net> Date: Sat, 27 Sep 1997 15:07:55 -0500 From: Karl Denninger To: Poul-Henning Kamp Cc: Karl Denninger , Nate Williams , current@freebsd.org Subject: Re: WARNING! Builds from the last few days have BROKEN NFS References: <19970927145131.64000@Mars.Mcs.Net> <13496.875390123@critter.freebsd.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.64 In-Reply-To: <13496.875390123@critter.freebsd.dk>; from Poul-Henning Kamp on Sat, Sep 27, 1997 at 09:55:23PM +0200 Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Sat, Sep 27, 1997 at 09:55:23PM +0200, Poul-Henning Kamp wrote: > >> > >> 'Just do it, and quit 'yer arguing' :) :) :) :) > > > >What I don't understand is why this kind of change would have the effect > >that it is having. That is, why would reducing the target number of vnodes > >on the freelist lead to hangs in a disk wait ("D") which are unkillable? > > Karl, neither do any of us at this time. > > We may be pretty good wizards, but we're not gods any of us. > > We need more data, and that involves you doing as we say in an attempt > to figure out what the heck is going on. > > I'm running a make buildworld across NFS right now, but so far I see no > trouble along the lines of what you found. > > -- > Poul-Henning Kamp FreeBSD coreteam member > phk@FreeBSD.ORG "Real hackers run -current on their laptop." Ok -- tomorrow evening I will check out another copy of the current sources, and give this another shot with the parameters you're referring to. The problem shows up only during fairly heavy I/O load -- my initial tests didn't show it, but putting the code on a reasonably-busy web server does, and its easily reproduced in about 20-30 minutes. Same with the shell systems here. The symptom is that a single disk I/O request will hang in a "D" state. Further attempts to access that same object then also hang, but others, even to the same disk pack, do NOT. That is, a "df" still works, but a "cat " locks up. If "object" is a directory then a "ls" will freeze. If its a file then you have to reference the specific file to see the behavior. Over a fairly short period of time once this starts you're in *big* trouble; you'll end up with thousands of processes hung in a disk wait for a specific file, and eventually run out of either process slots or page space (most people retry failed accesses, which makes the problem worse). Per-user process limits (which I have turned off on these machines) would stop some of the damage, but not all. I was trying to resolve cache inconsistency problems with NFS when I ran headfirst into this. There is a problem with V3 mounts (the default now) where you can "mv" a file on one client, and another client never sees the change. This is particularly distressing when you "mv" the access_log file from a web server (from another amchine), kick the server to re-create the access_log file, and then find that it never shows up on the other syste (or does with zero length, but no data in it -- ever). If you look on the other system, a "ls" doesn't show the errant file. But a "cat" does -- the data is still there. Needless to say this is pretty troublesome, and leads to lots of head-scratching. I thought that perhaps the V3 code was bolluxed, so I rebuilt the kernel to the most current revision and then tried to run with V2mounts ("-2" switch in the /etc/fstab file). That's when I ran into the trouble; removing the "-2" switch had no effect -- dashing my first hypothesis that the V2 code had been broken for some time and I hadn't noticed it. I'll see what else I can find out. -- -- Karl Denninger (karl@MCS.Net)| MCSNet - Serving Chicagoland and Wisconsin http://www.mcs.net/~karl | T1's from $600 monthly to FULL DS-3 Service | NEW! K56Flex modem support is now available Voice: [+1 312 803-MCS1 x219]| 56kbps DIGITAL ISDN DOV on analog lines! Fax: [+1 312 803-4929] | 2 FULL DS-3 Internet links; 400Mbps B/W Internal From owner-freebsd-current Sat Sep 27 13:18:04 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id NAA11193 for current-outgoing; Sat, 27 Sep 1997 13:18:04 -0700 (PDT) Received: from sendero-ppp.i-connect.net (sendero-ppp.i-Connect.Net [206.190.143.100]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id NAA11185 for ; Sat, 27 Sep 1997 13:17:58 -0700 (PDT) Received: (qmail 28596 invoked by uid 1000); 27 Sep 1997 20:18:21 -0000 Message-ID: X-Mailer: XFMail 1.2-alpha-092397 [p0] on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit MIME-Version: 1.0 Date: Sat, 27 Sep 1997 13:18:21 -0700 (PDT) Organization: Atlas Telecom From: Simon Shapiro To: freebsd-current@freebsd.org Subject: Make Releae - Success! Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk To all those who think I am an ever comlaining old grump (well, I am :-); Make release, as of 26-Sep-97 builds without a single hickup. Not only it build, but testing indicates it installs without a barf. Thanx! --- Sincerely Yours, Simon Shapiro Atlas Telecom Senior Architect 14355 SW Allen Blvd., Suite 130 Beaverton OR 97005 Shimon@i-Connect.Net Voice: 503.799.2313 From owner-freebsd-current Sat Sep 27 14:07:24 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id OAA13039 for current-outgoing; Sat, 27 Sep 1997 14:07:24 -0700 (PDT) Received: from Vorlon.odc.net (nwestfal@Vorlon.odc.net [207.137.42.6]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id OAA13034 for ; Sat, 27 Sep 1997 14:07:22 -0700 (PDT) Received: from localhost (nwestfal@localhost) by Vorlon.odc.net (8.8.5/8.8.5) with SMTP id OAA09682; Sat, 27 Sep 1997 14:05:08 -0700 Date: Sat, 27 Sep 1997 14:05:08 -0700 (PDT) From: Neal Westfall To: Ollivier Robert cc: current@FreeBSD.ORG Subject: Re: The 3.0-970920-SNAP CD has been canceled In-Reply-To: <19970927182833.29093@keltia.freenix.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Sat, 27 Sep 1997, Ollivier Robert wrote: > According to J Wunsch: > > I'm happy so far with a system built right before Justin's timeout > > changes hit the tree, that is from Sep 19. > > Mine is from Sep. 21st (see the .sig) and has been happily running since. What I was going to do was install from scratch from one of the snaps on current.freebsd.org, so it would have to be one of the ones where the installation doesn't die. But now that I think about it, maybe it would be better to just sup some more current sources and do a make world. Neal From owner-freebsd-current Sat Sep 27 16:07:00 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id QAA18892 for current-outgoing; Sat, 27 Sep 1997 16:07:00 -0700 (PDT) Received: from usr03.primenet.com (tlambert@usr03.primenet.com [206.165.6.203]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id QAA18879 for ; Sat, 27 Sep 1997 16:06:55 -0700 (PDT) Received: (from tlambert@localhost) by usr03.primenet.com (8.8.5/8.8.5) id QAA14147; Sat, 27 Sep 1997 16:03:03 -0700 (MST) From: Terry Lambert Message-Id: <199709272303.QAA14147@usr03.primenet.com> Subject: Re: WARNING! Builds from the last few days have BROKEN NFS To: karl@mcs.net (Karl Denninger) Date: Sat, 27 Sep 1997 23:03:02 +0000 (GMT) Cc: phk@critter.freebsd.dk, karl@mcs.net, nate@mt.sri.com, current@FreeBSD.ORG In-Reply-To: <19970927150755.39452@Mars.Mcs.Net> from "Karl Denninger" at Sep 27, 97 03:07:55 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > If you look on the other system, a "ls" doesn't show the errant file. > But a "cat" does -- the data is still there. Needless to say this is > pretty troublesome, and leads to lots of head-scratching. This will opccur on two occasions: 1) The file has been deleted, but the vnode was not removed from the cache, so you get a cache hit on open, and the file is still displayable after it has (nominally) been deleted. This points to an error in the name cache code. 2) The open call is OK, but the readdir is broken; the open will succeed, because it does it's own (linear) traversal, but the readdir fails because it does a cookie-based per block traversal. This points to an error in the cookie code. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-current Sat Sep 27 18:14:39 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id SAA24974 for current-outgoing; Sat, 27 Sep 1997 18:14:39 -0700 (PDT) Received: from sendero-ppp.i-connect.net (sendero-ppp.i-Connect.Net [206.190.143.100]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id SAA24969 for ; Sat, 27 Sep 1997 18:14:34 -0700 (PDT) Received: (qmail 6506 invoked by uid 1000); 28 Sep 1997 01:14:58 -0000 Message-ID: X-Mailer: XFMail 1.2-alpha-092397 [p0] on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit MIME-Version: 1.0 Date: Sat, 27 Sep 1997 18:14:58 -0700 (PDT) Organization: Atlas Telecom From: Simon Shapiro To: freebsd-current@freebsd.org Subject: ext2fs - Bad Checkin? Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk OK, Whodoneit now? ../../gnu/ext2fs/ext2_vfsops.c: In function `ext2_mount': ../../gnu/ext2fs/ext2_vfsops.c:220: `bdevsw' undeclared (first use this function) ../../gnu/ext2fs/ext2_vfsops.c:220: (Each undeclared identifier is reported only once ../../gnu/ext2fs/ext2_vfsops.c:220: for each function it appears in.) ../../gnu/ext2fs/ext2_vfsops.c:220: `D_NOCLUSTERR' undeclared (first use this function) ../../gnu/ext2fs/ext2_vfsops.c:222: `D_NOCLUSTERW' undeclared (first use this function) *** Error code 1 This worked fine earlier today. --- Sincerely Yours, Simon Shapiro Atlas Telecom Senior Architect 14355 SW Allen Blvd., Suite 130 Beaverton OR 97005 Shimon@i-Connect.Net Voice: 503.799.2313 From owner-freebsd-current Sat Sep 27 19:34:16 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id TAA29776 for current-outgoing; Sat, 27 Sep 1997 19:34:16 -0700 (PDT) Received: from gneiss.eps.nagoya-u.ac.jp (gneiss.eps.nagoya-u.ac.jp [133.6.57.99]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id TAA29764 for ; Sat, 27 Sep 1997 19:34:04 -0700 (PDT) Received: from marble.eps.nagoya-u.ac.jp (localhost [127.0.0.1]) by gneiss.eps.nagoya-u.ac.jp (8.8.7/3.5Wpl3) with ESMTP id LAA08997; Sun, 28 Sep 1997 11:33:07 +0900 (JST) Message-Id: <199709280233.LAA08997@gneiss.eps.nagoya-u.ac.jp> To: Shimon@i-Connect.Net Cc: freebsd-current@FreeBSD.ORG Subject: Re: ext2fs - Bad Checkin? From: KATO Takenori In-Reply-To: Your message of "Sat, 27 Sep 1997 18:14:58 -0700 (PDT)" References: X-Mailer: Mew version 1.70 on Emacs 19.28.1 / Mule 2.3 X-PGP-Fingerprint: 03 72 85 36 62 46 23 03 52 B1 10 22 44 10 0D 9E Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Sun, 28 Sep 1997 11:33:07 +0900 Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > OK, Whodoneit now? Sorry, I forgot to include . It was fixed in ext2_vfsops.c revision 1.18. Thanks! ---- KATO Takenori Dept. Earth Planet. Sci., Nagoya Univ., Nagoya, 464-01, Japan PGP public key: finger kato@eclogite.eps.nagoya-u.ac.jp ------------------- Powered by FreeBSD(98) ------------------- From owner-freebsd-current Sat Sep 27 19:37:37 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id TAA00178 for current-outgoing; Sat, 27 Sep 1997 19:37:37 -0700 (PDT) Received: from time.cdrom.com (root@time.cdrom.com [204.216.27.226]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id TAA00173 for ; Sat, 27 Sep 1997 19:37:34 -0700 (PDT) Received: from time.cdrom.com (jkh@localhost.cdrom.com [127.0.0.1]) by time.cdrom.com (8.8.7/8.6.9) with ESMTP id TAA27280; Sat, 27 Sep 1997 19:37:18 -0700 (PDT) To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) cc: freebsd-current@FreeBSD.ORG Subject: Re: Make Release failures In-reply-to: Your message of "Sat, 27 Sep 1997 17:12:45 +0200." <19970927171245.WM37928@uriah.heep.sax.de> Date: Sat, 27 Sep 1997 19:37:18 -0700 Message-ID: <27276.875414238@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > Huh? Never did it... :-) Can't work for cross-release buildings > anyway (i.e., 2.2 under -current, or vice versa). Yes, but it makes *sure* that you have a fully populated /usr/obj when the install pass is run. Whether the installed binaries actually work is another thing, but at least you're not going to blow up in the release during the chrootdir population pass. :) Remember Murphy's law. Build the friggin' world if you're going to do a release and that's one less area to worry about it falling over in. ;) Jordan From owner-freebsd-current Sat Sep 27 19:42:26 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id TAA00456 for current-outgoing; Sat, 27 Sep 1997 19:42:26 -0700 (PDT) Received: from time.cdrom.com (root@time.cdrom.com [204.216.27.226]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id TAA00445 for ; Sat, 27 Sep 1997 19:42:22 -0700 (PDT) Received: from time.cdrom.com (jkh@localhost.cdrom.com [127.0.0.1]) by time.cdrom.com (8.8.7/8.6.9) with ESMTP id TAA27305; Sat, 27 Sep 1997 19:38:16 -0700 (PDT) To: Poul-Henning Kamp cc: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch), freebsd-current@FreeBSD.ORG Subject: Re: Make Release failures In-reply-to: Your message of "Sat, 27 Sep 1997 18:14:47 +0200." <5886.875376887@critter.freebsd.dk> Date: Sat, 27 Sep 1997 19:38:15 -0700 Message-ID: <27302.875414295@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > Remember that the best way would be to populate only the minimal number > of files from the "outside source", and as soon as you have enough tools, > build them from the release-to-be sources inside the chroot. Yeah, but this is harder. ;-) Jordan From owner-freebsd-current Sat Sep 27 21:43:16 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id VAA06147 for current-outgoing; Sat, 27 Sep 1997 21:43:16 -0700 (PDT) Received: from atlantis.nconnect.net (root@atlantis.nconnect.net [207.227.50.2]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id VAA06142 for ; Sat, 27 Sep 1997 21:43:12 -0700 (PDT) Received: from nconnect.net (dial170.nconnect.net [207.227.50.170]) by atlantis.nconnect.net (8.8.4/8.7.3) with ESMTP id XAA17738 for ; Sat, 27 Sep 1997 23:45:48 -0500 (CDT) Message-ID: <342DE052.FE793D33@nconnect.net> Date: Sat, 27 Sep 1997 23:42:58 -0500 From: Randy DuCharme Organization: Astrolab Development X-Mailer: Mozilla 4.03b8 [en] (X11; I; FreeBSD 3.0-CURRENT i386) MIME-Version: 1.0 To: current@freebsd.org Subject: Make world failure Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Now what did I do?? I just tried to do a make world after grabbing fresh sources as of 5:30pm It stops shortly after starting with . . . t.lib/lstInit.c /usr/src/usr.bin/make/lst.lib/lstInsert.c /usr/src/usr.bin/make/lst.lib/lstIsAtEnd.c /usr/src/usr.bin/make/lst.lib/lstIsEmpty.c /usr/src/usr.bin/make/lst.lib/lstLast.c /usr/src/usr.bin/make/lst.lib/lstMember.c /usr/src/usr.bin/make/lst.lib/lstNext.c /usr/src/usr.bin/make/lst.lib/lstOpen.c /usr/src/usr.bin/make/lst.lib/lstRemove.c /usr/src/usr.bin/make/lst.lib/lstReplace.c /usr/src/usr.bin/make/lst.lib/lstSucc.c /usr/bin/mkdep: cannot create _mkdep28392: directory nonexistent *** Error code 2 Stop. *** Error code 1 Stop. *** Error code 1 Stop. # I've been digging around for the last 5 hrs or so. I'm Stumped! From owner-freebsd-current Sat Sep 27 23:32:26 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id XAA11045 for current-outgoing; Sat, 27 Sep 1997 23:32:26 -0700 (PDT) Received: from zibbi.mikom.csir.co.za (zibbi.mikom.csir.co.za [146.64.24.58]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id XAA11031 for ; Sat, 27 Sep 1997 23:32:16 -0700 (PDT) Received: (from jhay@localhost) by zibbi.mikom.csir.co.za (8.8.7/8.8.7) id IAA21096 for freebsd-current@FreeBSD.ORG; Sun, 28 Sep 1997 08:32:08 +0200 (SAT) From: John Hay Message-Id: <199709280632.IAA21096@zibbi.mikom.csir.co.za> Subject: ed0 not found on reboots To: freebsd-current@FreeBSD.ORG (FreeBSD-current) Date: Sun, 28 Sep 1997 08:32:08 +0200 (SAT) X-Mailer: ELM [version 2.4ME+ PL31 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hi, I have updated my -current box for the first time in about 6 weeks and found that with the latest kernel my ed0 device is only found atfter a power up or physical reset. After reboot or shutdown -r now it isn't found. Has anyone seen something like this? My machine is a 90MHz Pentium and the ed0 device (when found) probes like this: ===== ed0 at 0x280-0x29f irq 5 maddr 0xd8000 msize 16384 on isa ed0: address 00:00:c0:70:bf:94, type SMC8216/SMC8216C (16 bit) ===== John -- John Hay -- John.Hay@mikom.csir.co.za