From owner-freebsd-current Sun Mar 30 00:32:09 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id AAA15716 for current-outgoing; Sun, 30 Mar 1997 00:32:09 -0800 (PST) Received: from thelab.hub.org (hal-ns1-43.netcom.ca [207.181.94.107]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id AAA15710 for ; Sun, 30 Mar 1997 00:32:06 -0800 (PST) Received: from thelab.hub.org (localhost [127.0.0.1]) by thelab.hub.org (8.8.5/8.8.2) with SMTP id EAA08194 for ; Sun, 30 Mar 1997 04:31:52 -0400 (AST) Date: Sun, 30 Mar 1997 04:31:52 -0400 (AST) From: The Hermit Hacker To: current@freebsd.org Subject: make -j3 on make world? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi... Is there a way of doing a 'make -j3 world'? I've tried it, and it doesn't seem to work, based on what I observe when doing a 'make -j3' when building the kernel... From owner-freebsd-current Sun Mar 30 01:26:17 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id BAA17060 for current-outgoing; Sun, 30 Mar 1997 01:26:17 -0800 (PST) Received: from nlsystems.com (nlsys.demon.co.uk [158.152.125.33]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id BAA17054 for ; Sun, 30 Mar 1997 01:26:10 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by nlsystems.com (8.8.5/8.8.5) with ESMTP id KAA01871 for ; Sun, 30 Mar 1997 10:25:39 +0100 (BST) Date: Sun, 30 Mar 1997 10:25:38 +0100 (BST) From: Doug Rabson To: current@freebsd.org Subject: A new Kernel Module System Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Transfer-Encoding: 8BIT Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I want to re-vamp our kernel module system. The current system is fine as far as it goes but does have some serious limitations. I want to replace the current system with a new design which should be more flexible and should allow many more (hopefully all) device drivers to be supported as loadable modules. To avoid stepping on anyone's toes too early, I have written a paper showing how the new system will work. I would appreciate feedback, flaming or otherwise :-). --------------------------cut here------------------------ A new Kernel Module System A proposal to replace the current LKM system with a new implementation allowing both static and dynamically loaded modules. 1. The current LKM system 1.1. Description The current LKM system only supports dynamically loaded modules. Each module is either one of a small number of specially supported types or is a `catch all' misc module. The modules are a.out object files which are linked against the kernel's symbol table using ld(1). Each module has a single entry point which is called when the module is loaded and unloaded. 1.2. Lifecycle of an LKM The user initiates a module load (either by mounting a filesystem or by explicitly calling modload(8)). The module is loaded in three stages. First memory in the kernel address space is allocated for the module. Second, ld(1) is used to link the module's object file to run at the address which has been allocated for it. The kernel's symbol table is used to resolve external symbol references from the module. Lastly the relocated module is loaded into the kernel. The first thing the kernel does with the new module is to call its entry point to inform it that it has been loaded. If this call returns an error (e.g. because a device probe failed), the module is discarded. For syscalls, filesystems, device drivers and exec format handlers, common code in the lkm subsystem handles this load event. When the module is no longer needed, it can be unloaded using modunload(8). The module's entry point is called to inform it of the event (again this is handled in common code for most modules) and the kernel's memory is reclaimed. 1.3. Limitations Since the link stage is performed outside the kernel, modules can only be loaded after the system is fully initialised (or at least until after filesystems have been mounted). This makes automatic module loading during boot hard or impossible. Kernel initiated module loads (e.g. as a result of detecting a PCI device which is supported by a driver in a module) are virtually impossible. Statically loaded drivers initialise themselves using SYSINIT(9) along with various tables created by config(8) to add their entries to the various device switch tables. Making a statically loaded driver into a loadable module requires extra code to mimic this process. As a result, most drivers cannot be built as modules. 2. A new module system 2.1. Features · Support for both statically and dynamically loaded modules. · Dynamically loaded modules are relocated and linked by the kernel using a built in kernel symbol table. · Static loaded modules are identical to dynamic modules in every way. To include a static module in a kernel, the module's object file is simply included in the kernel's link. · Modules initialise and register themselves with the kernel using SYSINIT(9). · All devices drivers and filesystems and other subsystems are implemented as modules. · Statically loaded modules are informed when the system shuts down. System shutdown would appear to a statically loaded module as an unload event. Various drivers use at_shutdown(9) to tidy up device state before rebooting. This process can happen from the module's unload handler. · A desirable feature would be to support dependencies between modules. Each module would define a symbol table. If a module depends upon another, the dependant module's symbol table is used to resolve undefined symbols. 2.2. Kernel configuration Statically loaded modules are specified by a kernel configuration file, either implicitly by a controller, disk, tape or device keyword or explicitly with a new module keyword. 2.3. Devices Several types of device exist. Currently devices are configured into a kernel using various tables built by config(8) and ld(1). To make it easier to add devices and drivers to a running kernel, I suggest that all drivers use SYSINIT(9) to register themselves with the system. 2.3.1. ISA devices Currently ISA devices are included in a kernel by using config(8) to generate a list of device instances in ioconf.c which reference drivers statically compiled into the kernel. Few drivers support dynamic loading and those that do have hardcoded device instances built into the LKM (see sys/i386/isa/joy.c for an example). ISA drivers will register themselves by name using SYSINIT(9). This would happen either at boot time for static drivers or at module load time for dynamic drivers. Device instances (struct isa_device) will refer to their driver by name rather than by pointer. The name to driver mapping is performed and the device is probed and attached as normal. Statically configured devices are placed in a table by config(8) and modules containing their drivers are added to the kernel Makefile. When an ISA device is configured dynamically, first the module which contains its driver is loaded if not already present and secondly a system call is used to create a new device instance and to call the driver to probe and attach the new device. It is probably worth writing a new utility, isaconf(8), which can add new ISA device instances to the kernel. A desirable feature for a new module system would be to allow drivers to `detach' themselves from device instances, allowing a dynamically loaded driver to be unloaded cleanly. 2.3.2. PCI devices Currently each PCI driver has a pci_device structure which is included in a linker set. When a device is detected by the boot process, all driver probe functions are called in turn until the device is recognised. Again, in the new system, drivers should use SYSINIT(9) to register themselves with the PCI subsystem. Instead of a linker set, the pci_device (shouldn't this be pci_driver?) structures would be held on a linked list built by this registration process. At boot time, the PCI bus is scanned to generate a list of PCI device instances. The probes of all currently loaded drivers are called for these device instances. Any devices which are not assigned drivers are remembered. When a new driver module is loaded, the PCI subsystem re-scans unassigned devices when the module registers itself. This is broadly what happens for PCI drivers contained in LKMs today. If a driver is unloaded, it releases any resources such as interrupts allocated for devices attached to it. These devices become unassigned, as if they were not successfully probed. This allows driver developers to repeatedly load and unload modules without rebooting. 2.4. Dynamic loading Supporting static as well as dynamic modules makes the single module per object file paradigm of the existing LKM system difficult to maintain. A better approach is to separate the idea of a kernel module (a single kernel subsystem) from the idea of a kernel object file. The boot kernel should be thought of as simply a kernel object file which contains the modules that were configured statically. Dependencies between modules are also better treated as dependencies between object files (since they are typically linking dependencies). The new system will use a kernel linker which can load object files into the kernel address space. After loading, sysinits from the new object file are run, allowing any modules contained therein to register themselves. The linker will keep track of which modules are contained in which object so that when a user unloads the object, the modules can be informed of the event. Each object has a symbol table associated with it. When linking a new object into the kernel, the symbol tables of all the objects which it depends on are used to resolve undefined references. All modules implicitly depend on the boot kernel object and therefore can use symbols from the base kernel. Since objects have private symbol tables, a symbol with the same name can be used in more than one object without conflict; this is not a practice to be encouraged since it prevents modules in those objects from being linked statically. Each object has a reference count. Each time a dependant object is loaded, the reference count is increased. The user-initiated load also increases the reference count by one. To unload a module, the user will simply release this reference. The object will only be actually removed from the kernel if its reference count reaches zero. This scheme allows the automatic unloading of dependant modules as well as preventing an object from being removed while it is still in use. -- Doug Rabson Mail: dfr@nlsystems.com Nonlinear Systems Ltd. Phone: +44 181 951 1891 From owner-freebsd-current Sun Mar 30 02:51:47 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id CAA19590 for current-outgoing; Sun, 30 Mar 1997 02:51:47 -0800 (PST) Received: from time.cdrom.com (root@time.cdrom.com [204.216.27.226]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id CAA19585 for ; Sun, 30 Mar 1997 02:51:43 -0800 (PST) Received: from time.cdrom.com (jkh@localhost [127.0.0.1]) by time.cdrom.com (8.8.5/8.6.9) with ESMTP id CAA19169; Sun, 30 Mar 1997 02:51:40 -0800 (PST) To: Doug Rabson cc: current@freebsd.org Subject: Re: A new Kernel Module System In-reply-to: Your message of "Sun, 30 Mar 1997 10:25:38 +0100." Date: Sun, 30 Mar 1997 02:51:40 -0800 Message-ID: <19165.859719100@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk What can I say? I hate it. No, no, I'm just kidding! :-) It looks like a fabulous system, of course. Where do I sign up? :) Some questions, of course: How do you see an LKM (or whatever you're going to call objects in this new system - DRMs? Doug Rabson Modules? :-) accessing configuration data? To be more specific, take the existing system we have right now with UserConfig: Because all the isa_device structures are static, we can get in there and pound on them before the bus probing code is run and we can leave lots of little hints for a driver in the process. To be sure, a lot of the enable/disable behavior will become redundant in a truly dynamic system such as yours, but there are still issues which won't go away quite as easily. One good example is the test machine sitting a few feet to my right - it has an early SMC Ether16 card in it which needs the flags value set to 0x4 on ed0 before it will probe as a 16 bit card. There's no way the driver could know this, the card is simply braindead and I need to tell it. And that's just one example - I'm sure there are many others. There are and will be drivers that have ordering issues and need to be probed before or after other drivers - how will search order that be specified? My feeling is that this could be handled by a more general configuration space (sysctl on steroids, something phk has also been thinking about) where static drivers can register callbacks for named properties, e.g. "my name is sys.dev.fred_driver and I'd like to store my foo_flags property here." Each property would have a stringToData() and dataToString() function pointer and sizeof(void *) bytes of data to use however the conversion functions saw fit so you could come up with more complex representations for things as needed (lists, floats, etc). Then you use sysctl to do something like the following for dynamic drivers: sysctl -w sys.devs.ed0.flags=0x4 dfrmodload /lkm/devs/ed0.lkm ifconfig ed0 ... The code in ed0.lkm knows its unique path is sys.devs.ed0 so it knows where to find the "flags" property and can do the right thing with it. I also don't see any reason why you couldn't just collapse the functionality into "dfrmodload" (:-) and say something like this: dfrmodload sys.devs.ed0.flags=0x4 /lkm/devs/ed0.lkm Though there's also something to be said for the conceptual elegance of: sysctl -Pw sys.devs.ed0.flags=0x4 ifconfig ed0 ... [ dynamically loads ed0 lkm on first ref ] Heh heh. :) That's just off the top of my head and I'm sure other issues will come to me in the day/night, as I'm trying to sleep.. :) Seriously, this pretty much looks like the module system we've always wanted and I'd love to see you do it. Like I said, sign me up! Jordan P.S. Nonlinear Systems, eh? Do tell! :-) From owner-freebsd-current Sun Mar 30 03:36:34 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id DAA20781 for current-outgoing; Sun, 30 Mar 1997 03:36:34 -0800 (PST) Received: from nlsystems.com (nlsys.demon.co.uk [158.152.125.33]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id DAA20776 for ; Sun, 30 Mar 1997 03:36:29 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by nlsystems.com (8.8.5/8.8.5) with SMTP id MAA10461; Sun, 30 Mar 1997 12:35:45 +0100 (BST) Date: Sun, 30 Mar 1997 12:35:45 +0100 (BST) From: Doug Rabson To: "Jordan K. Hubbard" cc: current@freebsd.org Subject: Re: A new Kernel Module System In-Reply-To: <19165.859719100@time.cdrom.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Sun, 30 Mar 1997, Jordan K. Hubbard wrote: > What can I say? I hate it. No, no, I'm just kidding! :-) It looks > like a fabulous system, of course. Where do I sign up? :) > > Some questions, of course: How do you see an LKM (or whatever you're > going to call objects in this new system - DRMs? Doug Rabson Modules? > :-) accessing configuration data? To be more specific, take the > existing system we have right now with UserConfig: Because all the > isa_device structures are static, we can get in there and pound on > them before the bus probing code is run and we can leave lots of > little hints for a driver in the process. To be sure, a lot of the > enable/disable behavior will become redundant in a truly dynamic > system such as yours, but there are still issues which won't go away > quite as easily. One good example is the test machine sitting a few > feet to my right - it has an early SMC Ether16 card in it which needs > the flags value set to 0x4 on ed0 before it will probe as a 16 bit > card. There's no way the driver could know this, the card is simply > braindead and I need to tell it. And that's just one example - I'm > sure there are many others. There are and will be drivers that have > ordering issues and need to be probed before or after other drivers - > how will search order that be specified? The isa_device structures (for statically linked devices) will still be static but they will not be compiled into the driver. The important idea to get across here is the difference between device instances (isa_device) and device drivers (isa_driver). For your SMC card, you would include the 'ed' driver module and add an instance ed0 with the right flags. The changes to the way isa works today would be pretty small. Instead of the isa_device referencing the driver by pointer: { 7, &wdcdriver, IO_WD1, IRQ14, -1, C 0x00000, 0, wdintr, 0, 0x0000, 0, 0, 0, 0, 1, 0, 0 }, the reference would be by name: { 7, "wdc", IO_WD1, IRQ14, -1, C 0x00000, 0, 0, 0x0000, 0, 0, 0, 0, 1, 0, 0 }, When the kernel boots, the wdc module would call a function in isa, say isa_register_driver() to tell it how to handle instances of type "wdc": ... isa_register_driver("wdc", &wdcdriver, wdintr); ... Then isa will match devices to drivers using the names and everything else will work as it does today. UserConfig should be able to edit the device instances just as easily as it does now. For adding devices dynamically, a new system call would create an isa_device structure and fill it with the new device's config data (io, irq, flags etc.) The new device will then match against the installed drivers by name as for static devices. The commands used might be something like: # Add a new device using ed driver isaconf -a ed0 port=0x280 irq=5 iomem=0xd8000 flags=4 # Load the ed driver to activate all ed* instances modload /lkm/devs/isa/ed.so > > My feeling is that this could be handled by a more general > configuration space (sysctl on steroids, something phk has also been > thinking about) where static drivers can register callbacks for named > properties, e.g. "my name is sys.dev.fred_driver and I'd like to > store my foo_flags property here." Each property would have a > stringToData() and dataToString() function pointer and sizeof(void *) > bytes of data to use however the conversion functions saw fit so you > could come up with more complex representations for things as needed > (lists, floats, etc). Then you use sysctl to do something like the > following for dynamic drivers: > > sysctl -w sys.devs.ed0.flags=0x4 > dfrmodload /lkm/devs/ed0.lkm > ifconfig ed0 ... I think that 'sysctl on steroids' would be a very good place to put this information. With a persistent sysctl system, you would place templates for all the isa device instances that you want in the sysctl database and when the system boots (or when sysctl is used to edit the instances). This kind of support is not required, given that we can compile in the device instances using config(8) or add new ones using isaconf(8). > > The code in ed0.lkm knows its unique path is sys.devs.ed0 so it knows > where to find the "flags" property and can do the right thing with it. > I also don't see any reason why you couldn't just collapse the > functionality into "dfrmodload" (:-) and say something like this: > > dfrmodload sys.devs.ed0.flags=0x4 /lkm/devs/ed0.lkm I don't want to go overboard with adding features to modload. Ideally, modload should just dump a new object into the kernel run any init code which it contains. Intelligence about particular classes of module belongs in specific utilities which was the reason for wanting an isaconf(8) utility. > > Though there's also something to be said for the conceptual elegance > of: > > sysctl -Pw sys.devs.ed0.flags=0x4 > ifconfig ed0 ... [ dynamically loads ed0 lkm on first ref ] That would be nice. I think we can do that last though :-). I > > That's just off the top of my head and I'm sure other issues will come > to me in the day/night, as I'm trying to sleep.. :) Seriously, this > pretty much looks like the module system we've always wanted and I'd > love to see you do it. Like I said, sign me up! I am definately going to do this, in some form at least. My ultimate aim is to be able to have a minimal kernel which can automatically load the drivers that it needs as it boots. I would like to get at least a sketch of a design and some consensus before I actually start coding though. > P.S. Nonlinear Systems, eh? Do tell! :-) > My new company! Actually, its just me and my computer at the moment ;-). -- Doug Rabson Mail: dfr@nlsystems.com Nonlinear Systems Ltd. Phone: +44 181 951 1891 From owner-freebsd-current Sun Mar 30 05:17:19 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id FAA24350 for current-outgoing; Sun, 30 Mar 1997 05:17:19 -0800 (PST) Received: from who.cdrom.com (who.cdrom.com [204.216.27.3]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id FAA24345 for ; Sun, 30 Mar 1997 05:17:17 -0800 (PST) Received: from smtp1.xs4all.nl (smtp1.xs4all.nl [194.109.6.51]) by who.cdrom.com (8.8.5/8.6.11) with ESMTP id FAA10875 for ; Sun, 30 Mar 1997 05:17:15 -0800 (PST) Received: from asterix.xs4all.nl (root@asterix.xs4all.nl [194.109.6.11]) by smtp1.xs4all.nl (8.7.6/XS4ALL) with ESMTP id PAA17892 for ; Sun, 30 Mar 1997 15:15:57 +0200 (MET DST) Received: from plm.xs4all.nl (uucp@localhost) by asterix.xs4all.nl (8.7.5/8.7.2) with UUCP id PAA04607 for freebsd-current@freebsd.org; Sun, 30 Mar 1997 15:06:25 +0200 (MET DST) Received: (from plm@localhost) by plm.xs4all.nl (8.8.5/8.7.3) id JAA00995; Fri, 28 Mar 1997 09:14:38 +0100 (MET) To: freebsd-current@freebsd.org Subject: sio overflows From: Peter Mutsaers Date: 28 Mar 1997 09:14:37 +0100 Message-ID: <87zpvol9g2.fsf@plm.xs4all.nl> Lines: 15 X-Mailer: Gnus v5.4.25/Emacs 19.34 Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Since I upgraded from pre-Lite2 to post-Lite2, I occasionally get sio overflows: Mar 28 08:56:46 plm /kernel: sio1: 1 more silo overflow (total 1) Not many of them and I don't have real trouble with it, but still I wonder why it didn't happen before and it does now. This is on a 16550A serial port connected to an ISDN TA (64kb/s). The port itself is set to hardware flow control and 115200 bps. -- /\_/\ ( o.o ) Peter Mutsaers | Abcoude (Utrecht), | Trust is a good quality ) ^ ( plm@xs4all.nl | the Netherlands | for other people to have From owner-freebsd-current Sun Mar 30 06:50:56 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id GAA26985 for current-outgoing; Sun, 30 Mar 1997 06:50:56 -0800 (PST) Received: from vector.jhs.no_domain (slip139-92-4-168.mu.de.ibm.net [139.92.4.168]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id GAA26969; Sun, 30 Mar 1997 06:50:47 -0800 (PST) Received: from vector.jhs.no_domain (localhost [127.0.0.1]) by vector.jhs.no_domain (8.7.5/8.6.9) with ESMTP id JAA07304; Thu, 27 Mar 1997 09:33:51 +0100 (MET) Message-Id: <199703270833.JAA07304@vector.jhs.no_domain> To: dkelly@hiwaay.net cc: Richard Wackerbarth , freebsd-current@freebsd.org Subject: Re: CVS repository pushed off the FreeBSD CD distribution... From: "Julian H. Stacey" Reply-To: "Julian H. Stacey" X-Email: jhs@freebsd.org, Fallback: jhs@gil.physik.rwth-aachen.de X-Organization: Vector Systems Ltd. X-Mailer: EXMH 1.6.7, PGP available X-Address: Holz Strasse 27d, 80469 Munich, Germany X-Tel: Phone +49.89.268616, Fax +49.89.2608126, Data +49.89.26023276 X-Web: http://www.freebsd.org/~jhs/ In-reply-to: Your message of "Tue, 25 Mar 1997 20:45:33 CST." <199703260245.UAA25308@nexgen.hiwaay.net> Date: Thu, 27 Mar 1997 09:33:50 +0100 Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi, Reference: > From: dkelly@hiwaay.net > > ...which brings up another question. I've occasionally wondered how to genera - te one of these myself, wanting to roll my accumulated CTM's into an *Empty* - or *A*. Finally settled on exploding my CTM's into a brand new directory, the - n tar'ing that and deleting the accumulated CTM's. I discussed this sort of thing with Poul-Henning maybe 6 months ago, he pointed out (a) if it's a gzipped ctm archive rather than a tar.gz, it takes up slightly less room (I confirmed this locally) (b) the ctm archive has inbuilt md5's so is more resilient (than a tar archive that might get damaged), I may have his ideas slightly wrong, but whatever, he convinced me :-) ( Actually, being a died in the wool tar reactionary from way back, (who can remember tar flags but not ctm flags) I do roll local tars, but I don't regard them as `good as' ctm A files. ) Julian -- Julian H. Stacey jhs@freebsd.org http://www.freebsd.org/~jhs/ From owner-freebsd-current Sun Mar 30 10:18:08 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id KAA05019 for current-outgoing; Sun, 30 Mar 1997 10:18:08 -0800 (PST) Received: from ravenock.cybercity.dk (ravenock.cybercity.dk [194.16.57.32]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id KAA05010 for ; Sun, 30 Mar 1997 10:18:03 -0800 (PST) Received: (from sos@localhost) by ravenock.cybercity.dk (8.8.5/8.7.3) id UAA00416 for current@freebsd.org; Sun, 30 Mar 1997 20:18:29 +0200 (MET DST) From: Søren Schmidt Message-Id: <199703301818.UAA00416@ravenock.cybercity.dk> Subject: pppd ?? do we have a maintainer ?? To: current@freebsd.org (FreeBSD current) Date: Sun, 30 Mar 1997 20:18:28 +0200 (MET DST) 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-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I have a couble of fixes to pppd (kernel level ppp) that makes it a little more usable (it doesn't work in 2.2.1 and current :( ) There also is a newer version underways, so... Anybody "feels" for the code, or do I have another infant terrible under my wings ?? -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Søren Schmidt (sos@FreeBSD.org) FreeBSD Core Team Even more code to hack -- will it ever end .. From owner-freebsd-current Sun Mar 30 11:57:13 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id LAA09115 for current-outgoing; Sun, 30 Mar 1997 11:57:13 -0800 (PST) Received: from austin.polstra.com (austin.polstra.com [206.213.73.10]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id LAA09110 for ; Sun, 30 Mar 1997 11:57:10 -0800 (PST) Received: from austin.polstra.com (jdp@localhost) by austin.polstra.com (8.8.5/8.8.5) with ESMTP id LAA05078; Sun, 30 Mar 1997 11:57:06 -0800 (PST) Message-Id: <199703301957.LAA05078@austin.polstra.com> To: dfr@nlsystems.com Subject: Re: A new Kernel Module System Newsgroups: polstra.freebsd.current In-Reply-To: References: Organization: Polstra & Co., Seattle, WA Cc: current@freebsd.org Date: Sun, 30 Mar 1997 11:57:05 -0800 From: John Polstra Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk The new module system you described sounds good. I'd just like to mention a small aspect of it that matters to me. Any dynamic linking and/or run-time symbol resolution should be structured in a way that will make it as neutral as possible to the object file format. In other words, please don't introduce any new obstacles to moving away from a.out toward ELF or something else. Surprisingly, the current LKM implementation is pretty good in that regard. That's a result of its using the system loader "ld" to do much of the hard work, thereby keeping many of the object file details out of the kernel. I don't recommend that approach for your new system -- it's really kind of a kludge to run "ld" from modload, IMHO. But it would be good to isolate the file format dependencies at a fairly low level. (I stop just short of asking for a loadable module-loader super-module ... :-) One specific request: Any run-time references to symbols should be expressed *as they would appear in a C program*, to wit: Reference a C function "foo" as "foo", not as the a.out-specific "_foo". Any adding of underscores or other transformations should be isolated in the lowest, object format specific layers. I'd be more than happy to help with this aspect of the new module system, though I suspect you already have a firm grip on the issues. John -- John Polstra jdp@polstra.com John D. Polstra & Co., Inc. Seattle, Washington USA "Self-knowledge is always bad news." -- John Barth From owner-freebsd-current Sun Mar 30 12:55:24 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id MAA11930 for current-outgoing; Sun, 30 Mar 1997 12:55:24 -0800 (PST) Received: from main.gbdata.com (USR1-1.detnet.com [207.113.12.26]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id MAA11925 for ; Sun, 30 Mar 1997 12:55:18 -0800 (PST) Received: (from gclarkii@localhost) by main.gbdata.com (8.8.5/8.8.5) id OAA17217; Sun, 30 Mar 1997 14:55:12 -0600 (CST) From: Gary Clark II Message-Id: <199703302055.OAA17217@main.gbdata.com> Subject: Re: pppd ?? do we have a maintainer ?? To: sos@ravenock.cybercity.dk (Søren Schmidt) Date: Sun, 30 Mar 1997 14:55:11 -0600 (CST) Cc: current@freebsd.org In-Reply-To: <199703301818.UAA00416@ravenock.cybercity.dk> from =?ISO-8859-1?Q?S=F8ren_Schmidt?= at "Mar 30, 97 08:18:28 pm" X-Mailer: ELM [version 2.4ME+ PL22 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Søren Schmidt wrote: > > I have a couble of fixes to pppd (kernel level ppp) that makes > it a little more usable (it doesn't work in 2.2.1 and current :( ) Huh? You mean pppd? The light/2 stuff must have broken it then, because I'm running the snap from right before then and have never had a problem. > Søren Schmidt (sos@FreeBSD.org) FreeBSD Core Team Gary -- Gary Clark II (N5VMF) | I speak only for myself and "maybe" my company gclarkii@GBData.COM | Member of the FreeBSD Doc Team Providing Internet and ISP startups - http://WWW.GBData.com for information FreeBSD FAQ at ftp://ftp.FreeBSD.ORG/pub/FreeBSD/docs/FAQ.latin1 From owner-freebsd-current Sun Mar 30 12:57:47 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id MAA12066 for current-outgoing; Sun, 30 Mar 1997 12:57:47 -0800 (PST) Received: from ravenock.cybercity.dk (ravenock.cybercity.dk [194.16.57.32]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id MAA12057 for ; Sun, 30 Mar 1997 12:57:41 -0800 (PST) Received: (from sos@localhost) by ravenock.cybercity.dk (8.8.5/8.7.3) id WAA00729; Sun, 30 Mar 1997 22:57:18 +0200 (MET DST) From: Søren Schmidt Message-Id: <199703302057.WAA00729@ravenock.cybercity.dk> Subject: Re: pppd ?? do we have a maintainer ?? In-Reply-To: <199703302055.OAA17217@main.gbdata.com> from Gary Clark II at "Mar 30, 97 02:55:11 pm" To: gclarkii@main.gbdata.com (Gary Clark II) Date: Sun, 30 Mar 1997 22:57:18 +0200 (MET DST) Cc: current@freebsd.org 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-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In reply to Gary Clark II who wrote: > Søren Schmidt wrote: > > > > I have a couble of fixes to pppd (kernel level ppp) that makes > > it a little more usable (it doesn't work in 2.2.1 and current :( ) > > Huh? You mean pppd? The light/2 stuff must have broken it then, because > I'm running the snap from right before then and have never had a problem. That cant be :) unless you use it as a client only :) -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Søren Schmidt (sos@FreeBSD.org) FreeBSD Core Team Even more code to hack -- will it ever end .. From owner-freebsd-current Sun Mar 30 13:00:47 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id NAA12250 for current-outgoing; Sun, 30 Mar 1997 13:00:47 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.50]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id NAA12244 for ; Sun, 30 Mar 1997 13:00:43 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id NAA08427; Sun, 30 Mar 1997 13:45:32 -0700 From: Terry Lambert Message-Id: <199703302045.NAA08427@phaeton.artisoft.com> Subject: Re: A new Kernel Module System To: dfr@nlsystems.com (Doug Rabson) Date: Sun, 30 Mar 1997 13:45:31 -0700 (MST) Cc: current@freebsd.org In-Reply-To: from "Doug Rabson" at Mar 30, 97 10:25:38 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Well, as the architect of both the original LKM code and the original SYSINT() code, I can probably be expected to have some comments and corrections... so here they are. Let me know if I need to clarify anything. > A new Kernel Module System > > A proposal to replace the current LKM system with a new > implementation allowing both static and dynamically loaded > modules. > > > > 1. The current LKM system > > 1.1. Description > > The current LKM system only supports dynamically loaded modules. > Each module is either one of a small number of specially supported > types or is a `catch all' misc module. The modules are a.out > object files which are linked against the kernel's symbol table > using ld(1). Each module has a single entry point which is called > when the module is loaded and unloaded. Or queried for status. The single entry point is a multiplex entry point. This design requirement was forced on us by a.out format, which only has a single externally accessable member offset which can be set to a symbol offset at link time: unsigned long a_entry; /* entry point */ The small number of specially supported types of modules is an artifact of the kernel interfaces between subsystems being badly defined in the context of the overall kernel architecture. The kernel architecture must be corrected to be more orthoganal before there can be support for sugh things a "replacement VM system" modules, or, less ambitiously, "external pagers", and so on. One of the problems is that it is not possible to differentiate these subsystems in a loaded kernel. Again, this design requirement was forced on us by our a.out format. > 1.2. Lifecycle of an LKM > > The user initiates a module load (either by mounting a filesystem > or by explicitly calling modload(8)). This is a hack brought on because the loader is not in kernel space. This was a policy decision by the FreeBSD core team. > The module is loaded in three stages. First memory in the kernel > address space is allocated for the module. Second, ld(1) is used > to link the module's object file to run at the address which has > been allocated for it. The kernel's symbol table is used to > resolve external symbol references from the module. Lastly the > relocated module is loaded into the kernel. Six stages: o link module at load address 0 o determine size of linked module in pages o allocate that many contiguous pages in kernel space o link module at load address , whre is the base of the page allocation space o Push the module across the user/kernel boundry (this limitation is brought on by the lack of the kernel to page from a mapped image space, as with executables, because paging of modules would result in faults in kernel, not user, space. Alternately, it could be done by forcing a preload of the image, but the VM system does not support forcing an image into core, nor keeping unmodified pages there once it has been done). o Invoke the LKM control to call the module entry > The first thing the kernel does with the new module is to call its > entry point to inform it that it has been loaded. If this call > returns an error (e.g. because a device probe failed), the module > is discarded. For syscalls, filesystems, device drivers and exec > format handlers, common code in the lkm subsystem handles this > load event. > > When the module is no longer needed, it can be unloaded using > modunload(8). The module's entry point is called to inform it of > the event (again this is handled in common code for most modules) > and the kernel's memory is reclaimed. A module which believes it is in use may return EBUSY and veto the unload. There is currently no mechanism for delayed unload because there is not sufficiently advanced kernel counting semaphore/mutex support. > 1.3. Limitations > > Since the link stage is performed outside the kernel, modules can > only be loaded after the system is fully initialised (or at least > until after filesystems have been mounted). This makes automatic > module loading during boot hard or impossible. Kernel initiated > module loads (e.g. as a result of detecting a PCI device which is > supported by a driver in a module) are virtually impossible. Yes. > Statically loaded drivers initialise themselves using SYSINIT(9) > along with various tables created by config(8) to add their > entries to the various device switch tables. Making a statically > loaded driver into a loadable module requires extra code to mimic > this process. As a result, most drivers cannot be built as > modules. Sort of. I actually introduced SYSINIT() specifically to deal with the issues involved in a fully dynamic kernel configuration. The main problem with SYSINIT() is, once again, one of a.out format. It is possible to modify the modules to use common startup code, and to have that code reference the non-agregated SYSINIT() data directly. The main issue here is the linking against the kernel symbol space, since that link will cause the agregation of the SYSINIT() values with those of the existing kernel (the SYSINIT() implementation is by way of linker set). Because the SYSINIT() code uses linker sets, there must be a variant compilation to prevent the linker set from being agregated. Moving the LKM loader into the kernel, and defining an "exported symbol set" for the kernel which was resolvable by the kernel LKM loader, would be one way of resolving this problem: a kernel linker could choose to not agregate the module linker sets with the existing kernel linker sets. Ideally, the SYSINIT() information would like to not be in linker sets at all. To accomplish this would require some form of support for multiple sections in a single executable, and attribution of these sections so that former-linker-set-data can be identified as such, and the section treated the same no matter how the load takes place. In short, it means moving away from a.out. > 2. A new module system > > 2.1. Features > > * Support for both statically and dynamically loaded modules. > > * Dynamically loaded modules are relocated and linked by the > kernel using a built in kernel symbol table. > > * Static loaded modules are identical to dynamic modules in every > way. To include a static module in a kernel, the module's > object file is simply included in the kernel's link. > > * Modules initialise and register themselves with the kernel using > SYSINIT(9). SYSINIT() is an image-global link-time configuration mechanism. It must be implemented on top of something other than linker sets for this to be an achievable goal. Since this was one of the design considerations for SYSINIT(), this should be relatively trivial to do. Once this is one, the SYSINIT() becomes an actual function call reference, not a linker set reference, and the conditional compilation issues for static vs. dynamic modules simply go away. > * All devices drivers and filesystems and other subsystems are > implemented as modules. This is the subsystem granularity issue again. The kernel is not sufficiently abstracted in its interfaces, at this point, to handle more than the existing subsystems, and perhaps one or two more, as modular components. Part of this problem is that there is no HAL -- "Hardware Abstraction Layer" -- in the kernel. Another part is that after a HAL service set has been defined, it is still necessary to allow a single hardware subsystem to provide one or more HAL insterfaces. It is no accident that the pcaudio driver is not supported on the NetBSD "Multia" port, even though there exists the proper hardware to implement it on that particular Alpha machine. It doesn't exist on other Alpha machines, and NetBSD operates in an LCD -- "least common denominator" -- mode on a per processor architecture basis. > * Statically loaded modules are informed when the system shuts > down. System shutdown would appear to a statically loaded > module as an unload event. Various drivers use at_shutdown(9) > to tidy up device state before rebooting. This process can > happen from the module's unload handler. Yes. One issue, however, is enforcing inverse dependency order on the unload event dispatching. Module dependencies are not always defined in terms of symbol space relationships between modules. Among other issues is a three module stack, or HAL services provided by a module. For example, it's likely that one of the default kernel services will be a kernel "printf" of some kind. But there will not be an explicit dependency on a module calling a kernel "printf" on the module which implements the console for the kernel. For modules which the kernel consumes to provide services to other modules as if they were kernel services, or for which the kernel "wraps" the services of the consumed module, the dependency must be implicit. This becomes even more difficult when there are cyclic dependencies (and thus the dependencies can not be represented simply as a directed acyclic graph). One fix for this would be to define two "zones" of services that a module can provide: service encapsulated by the kernel, and services agregated by the kernel. Clearly, unload order would remove the agregated services before removing the encapsulated services. Just as the current SYSINIT() code is used in a set order in init_main.c, so would shutdon have to occur in a set inverse order in the encapsulated services modules. > * A desirable feature would be to support dependencies between > modules. Each module would define a symbol table. If a module > depends upon another, the dependant module's symbol table is > used to resolve undefined symbols. I believe this is a baseline requirement. It is simply a matter of having per module symbol zones, and establishing a reference count per module based on its symbols in its zone being consumed. When the module consuming goes away, the count is decremented. This implies a module dependency list per module. > 2.2. Kernel configuration > > Statically loaded modules are specified by a kernel configuration > file, either implicitly by a controller, disk, tape or device > keyword or explicitly with a new module keyword. Ideally, you would specify only modules. This implies that you remove the data differences between conditionally compiled code (the only conditional that has been identified as truly being necessary at compile time is "DEBUG"). The main issue here is dependency promiscuious knowledge of the structure on iteration. For example, the proc structure. If the proc structure is permitted to change size for debugging purposes, the only code that should be affected is the code that uses the additional fileds, and code which iterates the structures and therefore must know the structure size. It is only because the iteration of the proc structure is frequently (and incorrectly) by code outside the scope of the compilation directive, that the structures can not simply be made to overlay as if they were opaque pointers (ie: the debug data would be hidden). This is an issue of interface abstraction, both internal to the kernel (where commercial entities who provide binary kernel modules would be well served by not having dependencies on the size of structures exported by a kernel service -- one or more HAL interfaces), and where kernel interfaces are exported as data abstractions instead of functional abstractions ('w', 'ps', 'route', 'ifconfig', etc.). An audit of the use of the sizeof() keyword in all code in the kernel, and all code which uses the kvm header/library would be a Good Idea in general. > 2.3. Devices > > Several types of device exist. Currently devices are configured > into a kernel using various tables built by config(8) and ld(1). > To make it easier to add devices and drivers to a running kernel, > I suggest that all drivers use SYSINIT(9) to register themselves > with the system. This should be coordinated with call-based interfacing for devfs; the devfs abstraction should take precedence, such that the values of device major numbers lose importance in the ability to reference the devices. This may mean a change in syntax, and this should be kept in mind. > 2.3.1. ISA devices > > Currently ISA devices are included in a kernel by using config(8) > to generate a list of device instances in ioconf.c which reference > drivers statically compiled into the kernel. Few drivers support > dynamic loading and those that do have hardcoded device instances > built into the LKM (see sys/i386/isa/joy.c for an example). > > ISA drivers will register themselves by name using SYSINIT(9). > This would happen either at boot time for static drivers or at > module load time for dynamic drivers. Within the bounds of whether SYSINIT() is a data or a functional interface. It needs to be functional for this to work, and it is currently data. > Device instances (struct isa_device) will refer to their driver by > name rather than by pointer. The name to driver mapping is > performed and the device is probed and attached as normal. I'm not clear on why this abstraction is necessary or useful??? > Statically configured devices are placed in a table by config(8) > and modules containing their drivers are added to the kernel > Makefile. I would prefer that modules be build as seperate single object files (potentially agregating multiple object files into one using "ld -r"). A configuration is then simply a list of modules. I'm not sure if I like the idea of keeping a "config" around as anything other than a set of linker directives (in the a,out case), or as a vastly preferrable alternative, as input to an ELF section librarian for an agregate kernel image. This second would still leave us configurable at the binary level, while leaving the future direction open for fallback (firmware based) drivers and not yet requiring that the fallback drivers exist in order to get through boot stage (if the image is in a single file, then the single file is generally accessable without fallback driver support). > When an ISA device is configured dynamically, first the module > which contains its driver is loaded if not already present and > secondly a system call is used to create a new device instance and > to call the driver to probe and attach the new device. It is > probably worth writing a new utility, isaconf(8), which can add > new ISA device instances to the kernel. Careful, this is rocky terrain. ISA devices (non-PnP ones) have a nasty habit of having probe order dependencies. In addition, it might be useful to seperate the probe sequence from the device instance. There is still no useful VM mechanism for dealing with object persistance and/or kernel paging of non-paging critical code and data within the kernel itself. One problem here is that the distinction of "high persistance" and "low persistance" VM objects is made *ONLY* at the kernel/user seperation, with all kernel objects considered to be high persistance. With a load mechanism in place, and unlike the current statically loaded kernel, in common rather than rare use, these "medium persistance" objects could become a serious issue regarding fragmentation of the kernel VM space. Some of the recently discussed techniques for recovering contiguous memory spaces for drivers that need them, late in the kernel lifetime, would probably work, but most of these techniques are very high overhead. What is needed is (1) kernel paging support and (2) policy attribution of modular components so that the paging policy can be modified based on the object persistance. Obviously, probe code is typically used only once (exceptions: PCMCIA, laptop pluggable devices, etc.) and is never needed again. This gets into issues of section coloring and ELF section/segment support before it gets any cleaner. So a bit of caution is highly recommended. > A desirable feature for a new module system would be to allow > drivers to `detach' themselves from device instances, allowing a > dynamically loaded driver to be unloaded cleanly. This goes for shutdown of UART FIFO's, for instance, which will not be correctly reset by most BIOS. > If a driver is unloaded, it releases any resources such as > interrupts allocated for devices attached to it. These devices > become unassigned, as if they were not successfully probed. This > allows driver developers to repeatedly load and unload modules > without rebooting. With only issues of eventual VM space fragmentation, as subsequent versions of drivers change size... this is an issue we will eventually have to address, but it is livable to force the developer to reboot (IMO) at present. > Supporting static as well as dynamic modules makes the single > module per object file paradigm of the existing LKM system > difficult to maintain. A better approach is to separate the idea > of a kernel module (a single kernel subsystem) from the idea of a > kernel object file. The boot kernel should be thought of as > simply a kernel object file which contains the modules that were > configured statically. Dependencies between modules are also > better treated as dependencies between object files (since they > are typically linking dependencies). Is this ELF advocacy, or something else? The object module per LKM is still a valid approach (ld -r). Perhaps you are considering a module that is set up as two distinct (and reusable) components? If so, I would argue that allowing dependencies and breaking it into two modules accomplishes much the same thing. > The new system will use a kernel linker which can load object > files into the kernel address space. After loading, sysinits from > the new object file are run, allowing any modules contained > therein to register themselves. The linker will keep track of > which modules are contained in which object so that when a user > unloads the object, the modules can be informed of the event. Other than name, there is no difference between this and the "_entry" mechanism for identifying entry points, IMO. The big issue is, again, the distinction between data (linker set) based and function call based SYSINIT() mechanisms. 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 Sun Mar 30 13:10:36 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id NAA12834 for current-outgoing; Sun, 30 Mar 1997 13:10:36 -0800 (PST) Received: from thelab.hub.org (hal-ns1-36.netcom.ca [207.181.94.100]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id NAA12826 for ; Sun, 30 Mar 1997 13:10:30 -0800 (PST) Received: from thelab.hub.org (localhost [127.0.0.1]) by thelab.hub.org (8.8.5/8.8.2) with SMTP id RAA10954 for ; Sun, 30 Mar 1997 17:10:15 -0400 (AST) Date: Sun, 30 Mar 1997 17:10:15 -0400 (AST) From: The Hermit Hacker To: current@freebsd.org Subject: Re: make -j3 on make world? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Sun, 30 Mar 1997, The Hermit Hacker wrote: > > Hi... > > Is there a way of doing a 'make -j3 world'? I've tried it, and it > doesn't seem to work, based on what I observe when doing a 'make -j3' when > building the kernel... > > > Hi again... In reply to my own email, I did some playing around last night with the /usr/share/mk/* files, bsd.subdir.mk in particular, and came up with: _SUBDIRUSE: .USE @for entry in ${SUBDIR}; do \ (if test -d ${.CURDIR}/$${entry}.${MACHINE}; then \ ${ECHODIR} "===> ${DIRPRFX}$${entry}.${MACHINE}"; \ edir=$${entry}.${MACHINE}; \ cd ${.CURDIR}/$${edir}; \ else \ ${ECHODIR} "===> ${DIRPRFX}$$entry"; \ edir=$${entry}; \ cd ${.CURDIR}/$${edir}; \ fi; \ ${MAKE} ${MAKEFLAGS} ${.TARGET:realinstall=install} DIRPRFX=${DIRPRFX}$$edir/); \ done The only change is adding ${MAKEFLAGS} to the ${MAKE} line so that the -j3 flag carried down into the subdir's, so that make world works with parellel make... Is there any reason that I'm overlooking why this *shouldn't* be done this way? If not, and there are no arguments against it, I'd like to make the change a permanent feature...? Thanks... From owner-freebsd-current Sun Mar 30 13:21:21 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id NAA13502 for current-outgoing; Sun, 30 Mar 1997 13:21:21 -0800 (PST) Received: from time.cdrom.com (root@time.cdrom.com [204.216.27.226]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id NAA13493 for ; Sun, 30 Mar 1997 13:21:18 -0800 (PST) Received: from time.cdrom.com (jkh@localhost [127.0.0.1]) by time.cdrom.com (8.8.5/8.6.9) with ESMTP id NAA20523; Sun, 30 Mar 1997 13:21:09 -0800 (PST) To: Doug Rabson cc: current@freebsd.org Subject: Re: A new Kernel Module System In-reply-to: Your message of "Sun, 30 Mar 1997 12:35:45 +0100." Date: Sun, 30 Mar 1997 13:21:09 -0800 Message-ID: <20519.859756869@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > For adding devices dynamically, a new system call would create an > isa_device structure and fill it with the new device's config data (io, > irq, flags etc.) The new device will then match against the installed > drivers by name as for static devices. The commands used might be > something like: > > # Add a new device using ed driver > isaconf -a ed0 port=0x280 irq=5 iomem=0xd8000 flags=4 > # Load the ed driver to activate all ed* instances > modload /lkm/devs/isa/ed.so Ah, OK, this is the bit I missed. So you'd use this to load drivers that the kernel had never seen before, e.g. say I get a floppy from ABC Systems along with their new network interface card which none of us have ever even heard of before, and when I say: mcopy a:abc_foonic.so /lkm/devs/isa isaconf -a foo0 port=0x320 irq=11 iomem=0xd0000 modload /lkm/devs/isa/foo0.so It all does the right stuff? What if it's a PCI or EISA card, do I just do the modload and expect it to DTRT? Jordan From owner-freebsd-current Sun Mar 30 14:00:46 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id OAA15721 for current-outgoing; Sun, 30 Mar 1997 14:00:46 -0800 (PST) Received: from mexico.brainstorm.eu.org (mexico.brainstorm.fr [193.56.58.253]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id OAA15714 for ; Sun, 30 Mar 1997 14:00:40 -0800 (PST) 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 AAA23066 for ; Mon, 31 Mar 1997 00:00:30 +0200 Received: (from uucp@localhost) by brasil.brainstorm.eu.org (8.8.4/8.6.12) with UUCP id AAA31073 for current@freebsd.org; Mon, 31 Mar 1997 00:00:20 +0200 Received: (from roberto@localhost) by keltia.freenix.fr (8.8.5/keltia-uucp-2.9) id XAA21527; Sun, 30 Mar 1997 23:52:42 +0200 (CEST) Message-ID: <19970330235242.36106@keltia.freenix.fr> Date: Sun, 30 Mar 1997 23:52:42 +0200 From: Ollivier Robert To: FreeBSD current Subject: Re: pppd ?? do we have a maintainer ?? References: <199703301818.UAA00416@ravenock.cybercity.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Mailer: Mutt 0.67 In-Reply-To: =?iso-8859-1?Q?=3C199703301818=2EUAA00416=40ravenock=2Ecybercity=2Edk=3E?= =?iso-8859-1?Q?=3B_from_S=F8ren_Schmidt_on_Sun=2C_Mar_30=2C_1997_at_08?= =?iso-8859-1?Q?=3A18=3A28PM_+0200?= X-Operating-System: FreeBSD 3.0-CURRENT ctm#3153 Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk According to Søren Schmidt: > I have a couble of fixes to pppd (kernel level ppp) that makes > it a little more usable (it doesn't work in 2.2.1 and current :( ) I'm afraid this answer is sent through a pppd program... I am running a current system from March, 22nd (approx.) so it is after the Lite2 merge and pppd is running with a glitch. What are your problems ? -- Ollivier ROBERT -=- FreeBSD: There are no limits -=- roberto@keltia.freenix.fr FreeBSD keltia.freenix.fr 3.0-CURRENT #41: Sun Mar 23 23:01:22 CET 1997 From owner-freebsd-current Sun Mar 30 14:13:18 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id OAA16421 for current-outgoing; Sun, 30 Mar 1997 14:13:18 -0800 (PST) Received: from nexgen.hiwaay.net (max21-130.HiWAAY.net [208.147.153.130]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id OAA16413; Sun, 30 Mar 1997 14:13:13 -0800 (PST) Received: from nexgen (localhost [127.0.0.1]) by nexgen.hiwaay.net (8.8.5/8.8.4) with ESMTP id QAA19882; Sun, 30 Mar 1997 16:13:10 -0600 (CST) Message-Id: <199703302213.QAA19882@nexgen.hiwaay.net> X-Mailer: exmh version 1.6.9 8/22/96 To: "Julian H. Stacey" cc: Richard Wackerbarth , freebsd-current@freebsd.org From: dkelly@hiwaay.net Subject: Re: CVS repository pushed off the FreeBSD CD distribution... In-reply-to: Message from "Julian H. Stacey" of "Thu, 27 Mar 1997 09:33:50 +0100." <199703270833.JAA07304@vector.jhs.no_domain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 30 Mar 1997 16:13:03 -0600 Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk jhs@freebsd.org said: > Hi, Reference: > From: dkelly@hiwaay.net ...which brings up another > question. I've occasionally wondered how to genera - te one of these > myself, wanting to roll my accumulated CTM's into an *Empty* - or > *A*. Finally settled on exploding my CTM's into a brand new > directory, the - n tar'ing that and deleting the accumulated CTM's. > I discussed this sort of thing with Poul-Henning maybe 6 months ago, > he pointed out (a) if it's a gzipped ctm archive rather than a > tar.gz, it takes up slightly less room (I confirmed this locally) > (b) the ctm archive has inbuilt md5's so is more resilient (than a > tar archive that might get damaged), I may have his ideas slightly > wrong, but whatever, he convinced me :-) Yup. I've noticed my tar.gz's are bigger than the same CTM. So back to the beingings, "How do I make my own CTM's?" Did somebody answer this and I missed it? -- David Kelly N4HHE, dkelly@hiwaay.net ===================================================================== The human mind ordinarily operates at only ten percent of its capacity -- the rest is overhead for the operating system. From owner-freebsd-current Sun Mar 30 15:16:27 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id PAA19812 for current-outgoing; Sun, 30 Mar 1997 15:16:27 -0800 (PST) Received: from time.cdrom.com (root@time.cdrom.com [204.216.27.226]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id PAA19802 for ; Sun, 30 Mar 1997 15:16:24 -0800 (PST) Received: from time.cdrom.com (jkh@localhost [127.0.0.1]) by time.cdrom.com (8.8.5/8.6.9) with ESMTP id PAA23903; Sun, 30 Mar 1997 15:16:19 -0800 (PST) To: The Hermit Hacker cc: current@FreeBSD.org Subject: Re: make -j3 on make world? In-reply-to: Your message of "Sun, 30 Mar 1997 17:10:15 -0400." Date: Sun, 30 Mar 1997 15:16:15 -0800 Message-ID: <23854.859763775@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > The only change is adding ${MAKEFLAGS} to the ${MAKE} line so > that the -j3 flag carried down into the subdir's, so that make world > works with parellel make... That seems an entirely reasonable change - I can't see any reason why you *wouldn't* want MAKEFLAGS passed. Of course, this is also not the only place where ${MAKE} is used without makeflags (heh, and I always thought make passed MAKEFLAGS down *implicitly* to submakes as a special case). Jordan From owner-freebsd-current Sun Mar 30 15:35:05 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id PAA21027 for current-outgoing; Sun, 30 Mar 1997 15:35:05 -0800 (PST) Received: from thelab.hub.org (hal-ns1-19.netcom.ca [207.181.94.83]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id PAA21004 for ; Sun, 30 Mar 1997 15:34:59 -0800 (PST) Received: from thelab.hub.org (localhost [127.0.0.1]) by thelab.hub.org (8.8.5/8.8.2) with SMTP id TAA08612; Sun, 30 Mar 1997 19:34:45 -0400 (AST) Date: Sun, 30 Mar 1997 19:34:45 -0400 (AST) From: The Hermit Hacker To: "Jordan K. Hubbard" cc: current@FreeBSD.org Subject: Re: make -j3 on make world? In-Reply-To: <23854.859763775@time.cdrom.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk On Sun, 30 Mar 1997, Jordan K. Hubbard wrote: > > The only change is adding ${MAKEFLAGS} to the ${MAKE} line so > > that the -j3 flag carried down into the subdir's, so that make world > > works with parellel make... > > That seems an entirely reasonable change - I can't see any reason > why you *wouldn't* want MAKEFLAGS passed. Of course, this is also > not the only place where ${MAKE} is used without makeflags (heh, > and I always thought make passed MAKEFLAGS down *implicitly* to > submakes as a special case). > I'm still playing with it, buts its the only place I've found so far that makes a difference, at least as far as -j3 was concerned.. Having just thought about it, though...you *can* specify -j3 inside of /etc/make.conf as well, but putting in a line of 'MAKEFLAGS= -j3', so I'm going to add (commented out) that to /etc/make.conf and document that as well... From owner-freebsd-current Sun Mar 30 15:37:42 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id PAA21182 for current-outgoing; Sun, 30 Mar 1997 15:37:42 -0800 (PST) Received: from iworks.InterWorks.org (deischen@iworks.interworks.org [128.255.18.10]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id PAA21169; Sun, 30 Mar 1997 15:37:08 -0800 (PST) Received: (from deischen@localhost) by iworks.InterWorks.org (8.7.5/) id RAA19210; Sun, 30 Mar 1997 17:34:39 -0600 (CST) Message-Id: <199703302334.RAA19210@iworks.InterWorks.org> Date: Sun, 30 Mar 1997 17:34:39 -0600 (CST) From: "Daniel M. Eischen" To: freebsd-current@freebsd.org, gclarkii@main.gbdata.com, sos@freebsd.org Subject: Re: pppd ?? do we have a maintainer ?? Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > > I have a couble of fixes to pppd (kernel level ppp) that makes > > > it a little more usable (it doesn't work in 2.2.1 and current :( ) > > > Huh? You mean pppd? The light/2 stuff must have broken it then, because > > I'm running the snap from right before then and have never had a problem. > > That cant be :) unless you use it as a client only :) I'm using it as a client only, and about once every month or two it locks the system up tight forcing a cold reboot. Usually (actually every time I can remember it occurring), I am also doing something as root. When mounting a file system, or even su'ing to root. It's been doing this for probably close to a year now. I can't reliably reproduce it. I've been tracking -current FWIW. Dan Eischen deischen@iworks.InterWorks.org From owner-freebsd-current Sun Mar 30 16:39:22 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id QAA26337 for current-outgoing; Sun, 30 Mar 1997 16:39:22 -0800 (PST) Received: from frmug.org (frmug-gw.frmug.org [193.56.58.252]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id QAA26332 for ; Sun, 30 Mar 1997 16:39:16 -0800 (PST) Received: (from uucp@localhost) by frmug.org (8.8.5/8.8.5/frmug-2.0) with UUCP id CAA00970 for current@FreeBSD.org; Mon, 31 Mar 1997 02:39:02 +0200 (MET DST) Received: from localhost (localhost [127.0.0.1]) by xp11.frmug.org (8.8.5/8.8.5/xp11-uucp-1.1) with ESMTP id LAA00543 for ; Sun, 30 Mar 1997 11:08:26 +0200 (CEST) Message-Id: <199703300908.LAA00543@xp11.frmug.org> To: current@FreeBSD.org Subject: verbosity added with Lite2 merge. Date: Sun, 30 Mar 1997 11:08:26 +0200 From: "Philippe Charnier" Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk When booting, I get: real memory = 33554432 (32768K bytes) avail memory = 30388224 (29676K bytes) bdevsw_add_generic: adding D_DISK flag for device 7 <---- Probing for devices on the ISA bus: sc0 at 0x60-0x6f irq 1 on motherboard sc0: VGA color <16 virtual consoles, flags=0x0> (printed by kern/kern_conf.c, line 199) Shouldn't this be printed when verbose boot is on, not by default? Or it is because of a bug in mcd that is not recognized as a D_DISK at a glance where it should? ------ ------ Philippe Charnier charnier@lirmm.fr (smtp) charnier@xp11.frmug.org (uucp) ``a PC not running FreeBSD is like a venusian with no tentacles'' ------------------------------------------------------------------------ From owner-freebsd-current Sun Mar 30 17:34:52 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id RAA02206 for current-outgoing; Sun, 30 Mar 1997 17:34:52 -0800 (PST) Received: from thelab.hub.org (hal-ns1-05.netcom.ca [207.181.94.69]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id RAA02198 for ; Sun, 30 Mar 1997 17:34:43 -0800 (PST) Received: from thelab.hub.org (localhost [127.0.0.1]) by thelab.hub.org (8.8.5/8.8.2) with SMTP id VAA17829 for ; Sun, 30 Mar 1997 21:33:42 -0400 (AST) Date: Sun, 30 Mar 1997 21:33:42 -0400 (AST) From: The Hermit Hacker To: current@freebsd.org Subject: libstdc++ revisited... Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi... Can someone who knows something about libstdc++ tell me where this template is supposed to be found? /usr/src/gnu/lib/libstdc++/../../../contrib/libg++/libstdc++/sinst.cc:146: no matching template for `getline(istream &, basic_string > &)' found *** Error code 1 I've even tried to rm libstdc++ (and the associate contrib directory) and re-cvsup'ng it, but it keeps failing in the same place. Oh, and I even tried 'make -k install' to install the header files in case there was something missing there...still fails. I've tried just about everything I can think of, so am open to suggestions :( From owner-freebsd-current Sun Mar 30 18:01:56 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id SAA04898 for current-outgoing; Sun, 30 Mar 1997 18:01:56 -0800 (PST) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id SAA04890 for ; Sun, 30 Mar 1997 18:01:52 -0800 (PST) Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.5/8.6.9) id LAA22825; Mon, 31 Mar 1997 11:58:37 +1000 Date: Mon, 31 Mar 1997 11:58:37 +1000 From: Bruce Evans Message-Id: <199703310158.LAA22825@godzilla.zeta.org.au> To: charnier@xp11.frmug.org, current@FreeBSD.org Subject: Re: verbosity added with Lite2 merge. Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk >When booting, I get: > >real memory = 33554432 (32768K bytes) >avail memory = 30388224 (29676K bytes) >bdevsw_add_generic: adding D_DISK flag for device 7 <---- >... >(printed by kern/kern_conf.c, line 199) > >Shouldn't this be printed when verbose boot is on, not by default? Or It's a debugging flag, and shouldn't be printed at all ... >it is because of a bug in mcd that is not recognized as a D_DISK at a >glance where it should? ... after broken non-SCSI cdrom drivers like mcd are fixed :-). These drivers are missing a D_DISK in their bdevsw. It's probably an error for any devices with a bdevsw to be missing a D_XXX classifier. The following drivers in isa seem to be broken: matcd, mcd, scd, wcd, wt (has B_TAPE, should have D_TAPE). The D_DISK flag only makes a difference if securelevel > 0. Things involving security of disks don't work unless the kernel can tell which drivers drive disks. Bruce From owner-freebsd-current Sun Mar 30 18:27:30 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id SAA06539 for current-outgoing; Sun, 30 Mar 1997 18:27:30 -0800 (PST) Received: from root.com (implode.root.com [198.145.90.17]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id SAA06534 for ; Sun, 30 Mar 1997 18:27:26 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by root.com (8.8.5/8.6.5) with SMTP id SAA06086; Sun, 30 Mar 1997 18:27:51 -0800 (PST) Message-Id: <199703310227.SAA06086@root.com> X-Authentication-Warning: implode.root.com: localhost [127.0.0.1] didn't use HELO protocol To: Terry Lambert cc: dfr@nlsystems.com (Doug Rabson), current@freebsd.org Subject: Re: A new Kernel Module System In-reply-to: Your message of "Sun, 30 Mar 1997 13:45:31 MST." <199703302045.NAA08427@phaeton.artisoft.com> From: David Greenman Reply-To: dg@root.com Date: Sun, 30 Mar 1997 18:27:51 -0800 Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >> 1.2. Lifecycle of an LKM >> >> The user initiates a module load (either by mounting a filesystem >> or by explicitly calling modload(8)). > >This is a hack brought on because the loader is not in kernel space. >This was a policy decision by the FreeBSD core team. It was? I've always advocated for the linker to be in the kernel and I don't recall any other core member disagreeing. The reality from my point of view is that this is simply the way we got the code from you. -DG David Greenman Core-team/Principal Architect, The FreeBSD Project From owner-freebsd-current Sun Mar 30 19:35:48 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id TAA10489 for current-outgoing; Sun, 30 Mar 1997 19:35:48 -0800 (PST) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id TAA10483 for ; Sun, 30 Mar 1997 19:35:45 -0800 (PST) Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.5/8.6.9) id NAA25635; Mon, 31 Mar 1997 13:34:10 +1000 Date: Mon, 31 Mar 1997 13:34:10 +1000 From: Bruce Evans Message-Id: <199703310334.NAA25635@godzilla.zeta.org.au> To: current@freebsd.org, scrappy@hub.org Subject: Re: make -j3 on make world? Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > In reply to my own email, I did some playing around last night >with the /usr/share/mk/* files, bsd.subdir.mk in particular, and came >up with: > >_SUBDIRUSE: .USE > @for entry in ${SUBDIR}; do \ > (if test -d ${.CURDIR}/$${entry}.${MACHINE}; then \ > ${ECHODIR} "===> ${DIRPRFX}$${entry}.${MACHINE}"; \ > edir=$${entry}.${MACHINE}; \ > cd ${.CURDIR}/$${edir}; \ > else \ > ${ECHODIR} "===> ${DIRPRFX}$$entry"; \ > edir=$${entry}; \ > cd ${.CURDIR}/$${edir}; \ > fi; \ > ${MAKE} ${MAKEFLAGS} ${.TARGET:realinstall=install} DIRPRFX=${DIRPRFX}$$edir/); \ > done > > > The only change is adding ${MAKEFLAGS} to the ${MAKE} line so >that the -j3 flag carried down into the subdir's, so that make world >works with parellel make... > > Is there any reason that I'm overlooking why this *shouldn't* >be done this way? If not, and there are no arguments against it, I'd >like to make the change a permanent feature...? Yes, you're overlooking the bug in make that causes this behaviour. -j only works when it is specified on the command line. When it is inherited in ${MAKEFLAGS}, it is ignored because ${MAKEFLAGS} is parsed as a second command line, and parsing of the real command line earlier sets the -B flag. Don't change bsd.subdir.mk. Bruce From owner-freebsd-current Sun Mar 30 23:35:52 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id XAA24499 for current-outgoing; Sun, 30 Mar 1997 23:35:52 -0800 (PST) Received: from critter.dk.tfs.com (phk.cybercity.dk [195.8.133.247]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id XAA24489; Sun, 30 Mar 1997 23:35:43 -0800 (PST) Received: from critter (localhost [127.0.0.1]) by critter.dk.tfs.com (8.8.5/8.8.5) with ESMTP id JAA07047; Mon, 31 Mar 1997 09:34:40 +0200 (CEST) To: dkelly@hiwaay.net cc: "Julian H. Stacey" , Richard Wackerbarth , freebsd-current@freebsd.org Subject: Re: CVS repository pushed off the FreeBSD CD distribution... In-reply-to: Your message of "Sun, 30 Mar 1997 16:13:03 MDT." <199703302213.QAA19882@nexgen.hiwaay.net> Date: Mon, 31 Mar 1997 09:34:40 +0200 Message-ID: <7045.859793680@critter> From: Poul-Henning Kamp Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In message <199703302213.QAA19882@nexgen.hiwaay.net>, dkelly@hiwaay.net writes: >jhs@freebsd.org said: >> Hi, Reference: >> From: dkelly@hiwaay.net ...which brings up another >> question. I've occasionally wondered how to genera - te one of these >> myself, wanting to roll my accumulated CTM's into an *Empty* - or >> *A*. Finally settled on exploding my CTM's into a brand new >> directory, the - n tar'ing that and deleting the accumulated CTM's. > >> I discussed this sort of thing with Poul-Henning maybe 6 months ago, >> he pointed out (a) if it's a gzipped ctm archive rather than a >> tar.gz, it takes up slightly less room (I confirmed this locally) >> (b) the ctm archive has inbuilt md5's so is more resilient (than a >> tar archive that might get damaged), I may have his ideas slightly >> wrong, but whatever, he convinced me :-) > >Yup. I've noticed my tar.gz's are bigger than the same CTM. So back to the bei >ngings, "How do I make my own CTM's?" Did somebody answer this and I missed it >? Go look in src/usr.sbin/ctm/mkCTM ... -- Poul-Henning Kamp | phk@FreeBSD.ORG FreeBSD Core-team. http://www.freebsd.org/~phk | phk@login.dknet.dk Private mailbox. whois: [PHK] | phk@tfs.com TRW Financial Systems, Inc. Power and ignorance is a disgusting cocktail. From owner-freebsd-current Mon Mar 31 01:28:31 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id BAA00648 for current-outgoing; Mon, 31 Mar 1997 01:28:31 -0800 (PST) Received: from nlsystems.com (nlsys.demon.co.uk [158.152.125.33]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id BAA00634 for ; Mon, 31 Mar 1997 01:28:27 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by nlsystems.com (8.8.5/8.8.5) with SMTP id KAA27641; Mon, 31 Mar 1997 10:28:22 +0100 (BST) Date: Mon, 31 Mar 1997 10:28:22 +0100 (BST) From: Doug Rabson To: John Polstra cc: current@freebsd.org Subject: Re: A new Kernel Module System In-Reply-To: <199703301957.LAA05078@austin.polstra.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Sun, 30 Mar 1997, John Polstra wrote: > The new module system you described sounds good. I'd just like to > mention a small aspect of it that matters to me. > > Any dynamic linking and/or run-time symbol resolution should be > structured in a way that will make it as neutral as possible to the > object file format. In other words, please don't introduce any new > obstacles to moving away from a.out toward ELF or something else. > > Surprisingly, the current LKM implementation is pretty good in that > regard. That's a result of its using the system loader "ld" to do > much of the hard work, thereby keeping many of the object file > details out of the kernel. I don't recommend that approach for > your new system -- it's really kind of a kludge to run "ld" from > modload, IMHO. But it would be good to isolate the file format > dependencies at a fairly low level. (I stop just short of asking > for a loadable module-loader super-module ... :-) > > One specific request: Any run-time references to symbols should > be expressed *as they would appear in a C program*, to wit: > Reference a C function "foo" as "foo", not as the a.out-specific > "_foo". Any adding of underscores or other transformations should > be isolated in the lowest, object format specific layers. I will make sure that any object file dependancies are carefully segregated in the kernel linker. It should be possible to support both a.out and elf in the same linker. Probably a.out first.. -- Doug Rabson Mail: dfr@nlsystems.com Nonlinear Systems Ltd. Phone: +44 181 951 1891 From owner-freebsd-current Mon Mar 31 02:12:00 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id CAA04090 for current-outgoing; Mon, 31 Mar 1997 02:12:00 -0800 (PST) Received: from nlsystems.com (nlsys.demon.co.uk [158.152.125.33]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id CAA04076 for ; Mon, 31 Mar 1997 02:11:53 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by nlsystems.com (8.8.5/8.8.5) with SMTP id LAA27687; Mon, 31 Mar 1997 11:10:35 +0100 (BST) Date: Mon, 31 Mar 1997 11:10:35 +0100 (BST) From: Doug Rabson To: Terry Lambert cc: current@freebsd.org Subject: Re: A new Kernel Module System In-Reply-To: <199703302045.NAA08427@phaeton.artisoft.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Sun, 30 Mar 1997, Terry Lambert wrote: > > SYSINIT() is an image-global link-time configuration mechanism. It > must be implemented on top of something other than linker sets for > this to be an achievable goal. Since this was one of the design > considerations for SYSINIT(), this should be relatively trivial to > do. Once this is one, the SYSINIT() becomes an actual function > call reference, not a linker set reference, and the conditional > compilation issues for static vs. dynamic modules simply go away. The linker set for a dynamically loaded module would be local to the object file containing the module. Look at the implementation of C++ constructors in userland shared libraries. When the shlib is linked, the linker sets are aggregated. When it is loaded, the linker calls init code in the lib which uses the set. SYSINIT() from a loadable module would be similar. > > > Device instances (struct isa_device) will refer to their driver by > > name rather than by pointer. The name to driver mapping is > > performed and the device is probed and attached as normal. > > I'm not clear on why this abstraction is necessary or useful??? By keeping a separation between device instances (probed or otherwise) and device drivers, the driver does not need to be recompiled when the device configuration (irq or whatever) is changed. The driver should not depend on the individual resource requirements of a particular machine. > > > > Statically configured devices are placed in a table by config(8) > > and modules containing their drivers are added to the kernel > > Makefile. > > I would prefer that modules be build as seperate single object > files (potentially agregating multiple object files into one using > "ld -r"). > > A configuration is then simply a list of modules. > > I'm not sure if I like the idea of keeping a "config" around as > anything other than a set of linker directives (in the a,out case), > or as a vastly preferrable alternative, as input to an ELF section > librarian for an agregate kernel image. There has to be a clear distinction between device instances (isa_device in the current code) and device drivers (isa_driver). There can be many device instances using the same driver, each with its own private configuration data. The driver module itself must not embed any specific device configuration. This should be supplied to it, either by a user supplied configuration for legacy ISA devices or by a list generated at boot time by PnP, PCI, EISA etc. The configuration of a kernel is a list of modules plus a list of ISA device instances (assuming that ISA is the only bus which does not provide a complete list of attached devices). This list of device instances would be carefully ordered (exactly as it is today) to resulve probe difficulties. > > > Supporting static as well as dynamic modules makes the single > > module per object file paradigm of the existing LKM system > > difficult to maintain. A better approach is to separate the idea > > of a kernel module (a single kernel subsystem) from the idea of a > > kernel object file. The boot kernel should be thought of as > > simply a kernel object file which contains the modules that were > > configured statically. Dependencies between modules are also > > better treated as dependencies between object files (since they > > are typically linking dependencies). > > Is this ELF advocacy, or something else? > > The object module per LKM is still a valid approach (ld -r). Perhaps > you are considering a module that is set up as two distinct (and > reusable) components? If so, I would argue that allowing dependencies > and breaking it into two modules accomplishes much the same thing. The boot kernel is an example of a single kernel object which contains many modules. The act of aggregating (with ld -r) several objects into one also generates a single object containing many modules. > > > > The new system will use a kernel linker which can load object > > files into the kernel address space. After loading, sysinits from > > the new object file are run, allowing any modules contained > > therein to register themselves. The linker will keep track of > > which modules are contained in which object so that when a user > > unloads the object, the modules can be informed of the event. > > Other than name, there is no difference between this and the "_entry" > mechanism for identifying entry points, IMO. The big issue is, again, > the distinction between data (linker set) based and function call > based SYSINIT() mechanisms. My problem is that I want to be able to either load the modules individually or aggregate them into larger sets (or statically in the boot kernel). A single object file can only have a single entry point but can contain many SYSINITs. I want a function call based mechanism for initialisation to avoid embedding knowledge in the kernel linker of the many different linker sets in current use in the kernel. -- Doug Rabson Mail: dfr@nlsystems.com Nonlinear Systems Ltd. Phone: +44 181 951 1891 From owner-freebsd-current Mon Mar 31 02:16:15 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id CAA04366 for current-outgoing; Mon, 31 Mar 1997 02:16:15 -0800 (PST) Received: from nlsystems.com (nlsys.demon.co.uk [158.152.125.33]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id CAA04358 for ; Mon, 31 Mar 1997 02:16:08 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by nlsystems.com (8.8.5/8.8.5) with SMTP id LAA27699; Mon, 31 Mar 1997 11:15:33 +0100 (BST) Date: Mon, 31 Mar 1997 11:15:33 +0100 (BST) From: Doug Rabson To: "Jordan K. Hubbard" cc: current@freebsd.org Subject: Re: A new Kernel Module System In-Reply-To: <20519.859756869@time.cdrom.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Sun, 30 Mar 1997, Jordan K. Hubbard wrote: > > For adding devices dynamically, a new system call would create an > > isa_device structure and fill it with the new device's config data (io, > > irq, flags etc.) The new device will then match against the installed > > drivers by name as for static devices. The commands used might be > > something like: > > > > # Add a new device using ed driver > > isaconf -a ed0 port=0x280 irq=5 iomem=0xd8000 flags=4 > > # Load the ed driver to activate all ed* instances > > modload /lkm/devs/isa/ed.so > > Ah, OK, this is the bit I missed. So you'd use this to load drivers > that the kernel had never seen before, e.g. say I get a floppy from > ABC Systems along with their new network interface card which none of > us have ever even heard of before, and when I say: > > mcopy a:abc_foonic.so /lkm/devs/isa > isaconf -a foo0 port=0x320 irq=11 iomem=0xd0000 > modload /lkm/devs/isa/foo0.so Almost. You would load /lkm/devs/isa/foo.so. The driver object does not need an instance number since the same driver could support many different instances: isaconf -a foo0 port=320 irq=10 iomem=0xd0000 isaconf -a foo1 port=330 irq=11 iomem=0xd8000 isaconf -a foo2 port=340 irq=12 iomem=0xe0000 modload /lkm/devs/isa/foo.so > > It all does the right stuff? > > What if it's a PCI or EISA card, do I just do the modload and expect > it to DTRT? For a PCI or EISA (or PnP or PCCARD) device, the bus scan will determine the presence of the device. The driver module's probe would be called with the PCI device ids (or EISA id etc.) and if it recognises one which it supports, the probe will succeed. -- Doug Rabson Mail: dfr@nlsystems.com Nonlinear Systems Ltd. Phone: +44 181 951 1891 From owner-freebsd-current Mon Mar 31 08:31:02 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id IAA25372 for current-outgoing; Mon, 31 Mar 1997 08:31:02 -0800 (PST) Received: from austin.polstra.com (austin.polstra.com [206.213.73.10]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id IAA25362 for ; Mon, 31 Mar 1997 08:30:59 -0800 (PST) Received: from austin.polstra.com (jdp@localhost) by austin.polstra.com (8.8.5/8.8.5) with ESMTP id IAA09912; Mon, 31 Mar 1997 08:30:40 -0800 (PST) Message-Id: <199703311630.IAA09912@austin.polstra.com> To: smp@csn.net Subject: Re: sendmail and 2.2.1R not happy Newsgroups: polstra.freebsd.hackers In-Reply-To: <199703302103.OAA01705@Ilsa.StevesCafe.com> References: <199703302103.OAA01705@Ilsa.StevesCafe.com> Organization: Polstra & Co., Seattle, WA Cc: current@freebsd.org Date: Mon, 31 Mar 1997 08:30:40 -0800 From: John Polstra Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In article <199703302103.OAA01705@Ilsa.StevesCafe.com>, Steve Passe wrote: > Mar 29 19:19:39 Sam sendmail[540]: /etc/pwd.db: Permission denied > Mar 29 19:19:39 Sam sendmail[540]: LAA04887: SYSERR(UID1): Cannot exec > /usr/libexec/mail.local: Permission denied > > # lt `which sendmail` > -r-sr-xr-x 5 root bin 274432 Mar 25 07:50 /usr/sbin/sendmail* > > # lt /etc/pwd.db > -rw-r--r-- 1 root wheel 40960 Mar 30 03:31 /etc/pwd.db > > # lt /usr/libexec/mail.local > -r-sr-xr-x 1 root bin 12288 Mar 25 07:42 /usr/libexec/mail.local* > > Anyone have any ideas??? I don't know what's going on with your sendmail, but I bet ktrace could tell you. :-) John -- John Polstra jdp@polstra.com John D. Polstra & Co., Inc. Seattle, Washington USA "Self-knowledge is always bad news." -- John Barth From owner-freebsd-current Mon Mar 31 09:28:54 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id JAA28439 for current-outgoing; Mon, 31 Mar 1997 09:28:54 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.50]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id JAA28421 for ; Mon, 31 Mar 1997 09:28:42 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id KAA09639; Mon, 31 Mar 1997 10:12:14 -0700 From: Terry Lambert Message-Id: <199703311712.KAA09639@phaeton.artisoft.com> Subject: Re: A new Kernel Module System To: dg@root.com Date: Mon, 31 Mar 1997 10:12:14 -0700 (MST) Cc: terry@lambert.org, dfr@nlsystems.com, current@freebsd.org In-Reply-To: <199703310227.SAA06086@root.com> from "David Greenman" at Mar 30, 97 06:27:51 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > >> 1.2. Lifecycle of an LKM > >> > >> The user initiates a module load (either by mounting a filesystem > >> or by explicitly calling modload(8)). > > > >This is a hack brought on because the loader is not in kernel space. > >This was a policy decision by the FreeBSD core team. > > It was? I've always advocated for the linker to be in the kernel and I > don't recall any other core member disagreeing. The reality from my point > of view is that this is simply the way we got the code from you. Garrett disagreed; this is not to say that he didn't have good reasons, but I believe the benefits outweigh the additional size and other issues which he raises. 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 Mar 31 09:48:03 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id JAA29359 for current-outgoing; Mon, 31 Mar 1997 09:48:03 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.50]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id JAA29342 for ; Mon, 31 Mar 1997 09:48:01 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id KAA09669; Mon, 31 Mar 1997 10:32:21 -0700 From: Terry Lambert Message-Id: <199703311732.KAA09669@phaeton.artisoft.com> Subject: Re: A new Kernel Module System To: dfr@nlsystems.com (Doug Rabson) Date: Mon, 31 Mar 1997 10:32:21 -0700 (MST) Cc: terry@lambert.org, current@freebsd.org In-Reply-To: from "Doug Rabson" at Mar 31, 97 11:10:35 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > SYSINIT() is an image-global link-time configuration mechanism. It > > must be implemented on top of something other than linker sets for > > this to be an achievable goal. Since this was one of the design > > considerations for SYSINIT(), this should be relatively trivial to > > do. Once this is one, the SYSINIT() becomes an actual function > > call reference, not a linker set reference, and the conditional > > compilation issues for static vs. dynamic modules simply go away. > > The linker set for a dynamically loaded module would be local to the > object file containing the module. Look at the implementation of C++ > constructors in userland shared libraries. When the shlib is linked, the > linker sets are aggregated. When it is loaded, the linker calls init code > in the lib which uses the set. SYSINIT() from a loadable module would be > similar. I don't think this is the same thing, really. Consider that in order to use a dynamically linked shared library, the symbol list must be imported into the executable that is bound to the binary. You can't do this for a module which is dynamically loaded; there is no symbol set within the kernel with knowledge of the modules constructor symbol names, as there is when the symbols are linked into the CTOR/DTOR list with a C++ shared library. Shared libs LKM's has knowledge of symbols has knowledge of one offset has static data loads static data, which must be relocated has multiple entry points has one entry point because of vtable ld.so mapped into process paging (and therefore mapping) not supported > > > Device instances (struct isa_device) will refer to their driver by > > > name rather than by pointer. The name to driver mapping is > > > performed and the device is probed and attached as normal. > > > > I'm not clear on why this abstraction is necessary or useful??? > > By keeping a separation between device instances (probed or otherwise) and > device drivers, the driver does not need to be recompiled when the device > configuration (irq or whatever) is changed. The driver should not depend > on the individual resource requirements of a particular machine. Ah, I understand. It's to allow external manipulation of device data. Say I have an interface named "ed0" and I need variable numbers of parameters to make it work? For instance PCMCIA vs. non-PCMCIA vs. PnP ISA vs. real PnP PCI. The idea is sound, but perhaps it needs to be nearly as parametric as PnP itself? > > > Statically configured devices are placed in a table by config(8) > > > and modules containing their drivers are added to the kernel > > > Makefile. > > > > I would prefer that modules be build as seperate single object > > files (potentially agregating multiple object files into one using > > "ld -r"). > > > > A configuration is then simply a list of modules. > > > > I'm not sure if I like the idea of keeping a "config" around as > > anything other than a set of linker directives (in the a,out case), > > or as a vastly preferrable alternative, as input to an ELF section > > librarian for an agregate kernel image. > > There has to be a clear distinction between device instances (isa_device > in the current code) and device drivers (isa_driver). There can be many > device instances using the same driver, each with its own private > configuration data. The driver module itself must not embed any > specific device configuration. This should be supplied to it, either by a > user supplied configuration for legacy ISA devices or by a list generated > at boot time by PnP, PCI, EISA etc. But shouldn't device instantiation within a driver be handled by the probe code coming true? Is this just for static configuration of devices without invoking a probe? > The configuration of a kernel is a list of modules plus a list of ISA > device instances (assuming that ISA is the only bus which does not provide > a complete list of attached devices). This list of device instances would > be carefully ordered (exactly as it is today) to resulve probe > difficulties. OK. But I think we can do this anyway. For instance, a LANCE-based ethernet is probed by kicking it and seeing if it yells (INTs). But you *can* also detect the thing by its ROM. > > The object module per LKM is still a valid approach (ld -r). Perhaps > > you are considering a module that is set up as two distinct (and > > reusable) components? If so, I would argue that allowing dependencies > > and breaking it into two modules accomplishes much the same thing. > > The boot kernel is an example of a single kernel object which contains > many modules. The act of aggregating (with ld -r) several objects into > one also generates a single object containing many modules. OK, then I remove my question... it's a semantic issue, not a technical one. > My problem is that I want to be able to either load the modules > individually or aggregate them into larger sets (or statically in the boot > kernel). A single object file can only have a single entry point but can > contain many SYSINITs. It seems that a linker set of SYSINIT()'s would meet this need, as long as you had a "generic" _entry mechanism capable of multiplexing not only load/unload/stat but also which of the elements you are applying the operation to. This is reasonable if you are willing to continue linking a seperate entry stub for each "module group", OR if you are willing to double the interior symbol space (to distinguish between internal entry points used by the driver and those exported by the driver for use by other modules). I think something like this is necessary to reduce the amount of kernel symbol namespace pollution that results from loading a bazillion modules, anyway... in other words, it has benefit above and beyond that of formallizing the module interfaces. > I want a function call based mechanism for initialisation to avoid > embedding knowledge in the kernel linker of the many different linker sets > in current use in the kernel. Yes, this is an obvious requirement which I totally agree with. I'm just not sure you can cleanly implement a CTOR/DTOR calling method to be able to support it... at least not without going away from a.out, perhaps sooner than you want to (bigger delta's == bigger risks). 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 Mar 31 09:49:20 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id JAA29425 for current-outgoing; Mon, 31 Mar 1997 09:49:20 -0800 (PST) Received: from rover.village.org (rover.village.org [204.144.255.49]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id JAA29417 for ; Mon, 31 Mar 1997 09:49:17 -0800 (PST) Received: from rover.village.org [127.0.0.1] by rover.village.org with esmtp (Exim 1.60 #1) id 0wBlCc-0006sH-00; Mon, 31 Mar 1997 10:49:06 -0700 To: Doug Rabson Subject: Re: A new Kernel Module System Cc: "Jordan K. Hubbard" , current@freebsd.org In-reply-to: Your message of "Mon, 31 Mar 1997 11:15:33 +0100." References: Date: Mon, 31 Mar 1997 10:49:05 -0700 From: Warner Losh Message-Id: Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In message Doug Rabson writes: : Almost. You would load /lkm/devs/isa/foo.so. The driver object does not : need an instance number since the same driver could support many different : instances: : : isaconf -a foo0 port=320 irq=10 iomem=0xd0000 : isaconf -a foo1 port=330 irq=11 iomem=0xd8000 : isaconf -a foo2 port=340 irq=12 iomem=0xe0000 : modload /lkm/devs/isa/foo.so That would be way cool. I'd especially like to be able to do this with the GENERIC kernel. Right now there is no way to do this, short of booting -c. When you install a new kernel on a machine at a remote office and thinkn that you are set because the old kernel was generic too and do a reboot, only to find out that it really wasn't generic GENERIC.... That is I'd like to be able to boot a generic thing, and have it preserve my deltas to the "settings" of the device drivers across upgrades. It is often nice to have one GENERIC kernel that gets pushed out to n sites who's only differences are the IRQs and I/O addresses of some of the ethernet cards, etc. Warner From owner-freebsd-current Mon Mar 31 10:35:36 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id KAA02099 for current-outgoing; Mon, 31 Mar 1997 10:35:36 -0800 (PST) Received: from bacardi.torrentnet.com (plexuscom.com [207.87.46.99]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id KAA02093 for ; Mon, 31 Mar 1997 10:35:34 -0800 (PST) Received: from localhost.torrentnet.com (localhost.torrentnet.com [127.0.0.1]) by bacardi.torrentnet.com (8.7.6/8.7.3) with SMTP id NAA04015; Mon, 31 Mar 1997 13:34:15 -0500 (EST) Message-Id: <199703311834.NAA04015@bacardi.torrentnet.com> X-Authentication-Warning: bacardi.plexuscom.com: Host localhost.torrentnet.com [127.0.0.1] didn't use HELO protocol To: terry@lambert.org cc: freebsd-current@freebsd.org Subject: Re: A new Kernel Module System In-Reply-To: <199703311712.KAA09639@phaeton.artisoft.com> Organization: Torrent Networking Technologies Corp Date: Mon, 31 Mar 1997 13:34:15 -0500 From: James da Silva Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In article <199703311712.KAA09639@phaeton.artisoft.com> Terry writes: >> >This is a hack brought on because the loader is not in kernel space. >> >This was a policy decision by the FreeBSD core team. >> >> It was? I've always advocated for the linker to be in the kernel and >> I don't recall any other core member disagreeing. The reality from my >> point of view is that this is simply the way we got the code from you. > >Garrett disagreed; this is not to say that he didn't have good reasons, >but I believe the benefits outweigh the additional size and other >issues which he raises. People should bear in mind in this discussion that the code to do the relocations on a loaded a.out file is well under 8K. FYI. Seems well worth it to me. Jaime ........................................................................... : James da Silva : Stand on my shoulders, : : Torrent Networking Technologies Corp. : not on my toes. : From owner-freebsd-current Mon Mar 31 11:05:31 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id LAA03724 for current-outgoing; Mon, 31 Mar 1997 11:05:31 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.50]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id LAA03716 for ; Mon, 31 Mar 1997 11:05:26 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id LAA09880; Mon, 31 Mar 1997 11:49:03 -0700 From: Terry Lambert Message-Id: <199703311849.LAA09880@phaeton.artisoft.com> Subject: Re: A new Kernel Module System To: imp@village.org (Warner Losh) Date: Mon, 31 Mar 1997 11:49:03 -0700 (MST) Cc: dfr@nlsystems.com, jkh@time.cdrom.com, current@freebsd.org In-Reply-To: from "Warner Losh" at Mar 31, 97 10:49:05 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > : Almost. You would load /lkm/devs/isa/foo.so. The driver object does not > : need an instance number since the same driver could support many different > : instances: > : > : isaconf -a foo0 port=320 irq=10 iomem=0xd0000 > : isaconf -a foo1 port=330 irq=11 iomem=0xd8000 > : isaconf -a foo2 port=340 irq=12 iomem=0xe0000 > : modload /lkm/devs/isa/foo.so > > That would be way cool. I'd especially like to be able to do this > with the GENERIC kernel. Right now there is no way to do this, short > of booting -c. When you install a new kernel on a machine at a remote > office and thinkn that you are set because the old kernel was generic > too and do a reboot, only to find out that it really wasn't generic > GENERIC.... It seems to me that either the isaconf and the modload order is inverted, or that the kernel should be demand loading the driver for the isaconf case if the driver were not already present (the loading done by the *kernel*, not the *isaconf*)... in which case there should not be a modload at all. > That is I'd like to be able to boot a generic thing, and have it > preserve my deltas to the "settings" of the device drivers across > upgrades. It is often nice to have one GENERIC kernel that gets > pushed out to n sites who's only differences are the IRQs and I/O > addresses of some of the ethernet cards, etc. Me too; when are we going to data-drive all of the system settings like we were first talking about in October of 1993? That way I can upgrade my /etc/rc* without the machine not working... Heh. 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 Mar 31 11:22:59 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id LAA04483 for current-outgoing; Mon, 31 Mar 1997 11:22:59 -0800 (PST) Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.0.193]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id LAA04470 for ; Mon, 31 Mar 1997 11:22:56 -0800 (PST) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.8.5/8.8.5) id OAA16298; Mon, 31 Mar 1997 14:22:54 -0500 (EST) Date: Mon, 31 Mar 1997 14:22:54 -0500 (EST) From: Garrett Wollman Message-Id: <199703311922.OAA16298@khavrinen.lcs.mit.edu> To: terry@lambert.org, freebsd-current@freebsd.org Subject: Re: A new Kernel Module System In-Reply-To: <199703311834.NAA04015@bacardi.torrentnet.com> References: <199703311712.KAA09639@phaeton.artisoft.com> <199703311834.NAA04015@bacardi.torrentnet.com> Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > In article <199703311712.KAA09639@phaeton.artisoft.com> Terry writes: >>> >This is a hack brought on because the loader is not in kernel space. >>> >This was a policy decision by the FreeBSD core team. >>> >>> It was? I've always advocated for the linker to be in the kernel and >>> I don't recall any other core member disagreeing. The reality from my >>> point of view is that this is simply the way we got the code from you. >> >> Garrett disagreed; this is not to say that he didn't have good reasons, >> but I believe the benefits outweigh the additional size and other >> issues which he raises. Please don't put words into my mouth. -GAWollman -- Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same wollman@lcs.mit.edu | O Siem / The fires of freedom Opinions not those of| Dance in the burning flame MIT, LCS, CRS, or NSA| - Susan Aglukark and Chad Irschick From owner-freebsd-current Mon Mar 31 11:32:59 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id LAA05036 for current-outgoing; Mon, 31 Mar 1997 11:32:59 -0800 (PST) Received: from helbig.informatik.ba-stuttgart.de (helbig.informatik.ba-stuttgart.de [141.31.166.22]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id LAA04877 for ; Mon, 31 Mar 1997 11:31:23 -0800 (PST) Received: (from helbig@localhost) by helbig.informatik.ba-stuttgart.de (8.8.5/8.8.5) id VAA21182; Mon, 31 Mar 1997 21:28:46 +0200 (MET DST) From: Wolfgang Helbig Message-Id: <199703311928.VAA21182@helbig.informatik.ba-stuttgart.de> Subject: pppd ?? do we have a maintainer ?? To: sos@ravenock.cybercity.dk Date: Mon, 31 Mar 1997 21:28:37 +0200 (MET DST) Cc: current@freebsd.org X-Mailer: ELM [version 2.4ME+ PL30 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi, Well I probably *did* run into a pppd bug trying to set up a dial up connection via ISDN. Maybe your fixes would help in my case? Thank you in advance Wolfgang. ----- Forwarded message from helbig ----- >From helbig Sat Mar 29 01:56:00 1997 Subject: dial up ppp To: isdn@muc.ditec.de Date: Sat, 29 Mar 1997 01:56:00 +0100 (MET) X-Mailer: ELM [version 2.4ME+ PL30 (25)] Hi, I am trying to set up a pppd-"server", so a friend of mine with a M$-Box can download fbsd-2.2.1. Both of us can set up a ppp-connection to Ascend Router of our ISP. I am happily using bisdnppp and he is using his M$-software. For several reasons, we would like to connect directly to each other. but we cannot because the IPCP does not finish successfully. My side does not interpret the IPCP-frames correctly, it seems. Here is my start_ppp_in - script: #!/bin/sh exec /usr/local/bin/isdnpppd -d persist -detach \ 192.168.1.1:192.168.1.2 silent And here is the the pppd-log. I've tried to interpret those "unknown Protocolls" and they look like good IPCP-Requests. Mar 28 23:59:43 helbig pppd[17945]: Exit. Mar 29 00:04:09 helbig pppd[17957]: pppd 2.2.0 started by helbig, uid 0 Mar 29 00:04:09 helbig pppd[17957]: Using interface ppp0 Mar 29 00:04:09 helbig pppd[17957]: Connect: ppp0 <--> /dev/tty Mar 29 00:04:09 helbig pppd[17957]: rcvd [LCP ConfReq id=0x1 < 0d 03 06>] Mar 29 00:04:09 helbig pppd[17957]: sent [LCP ConfReq id=0x1 ] Mar 29 00:04:09 helbig pppd[17957]: sent [LCP ConfRej id=0x1 < 0d 03 06>] Mar 29 00:04:09 helbig pppd[17957]: rcvd [LCP ConfAck id=0x1 ] Mar 29 00:04:09 helbig pppd[17957]: rcvd [LCP ConfReq id=0x2 ] Mar 29 00:04:09 helbig pppd[17957]: sent [LCP ConfAck id=0x2 ] Mar 29 00:04:09 helbig pppd[17957]: sent [IPCP ConfReq id=0x1 ] Mar 29 00:04:09 helbig pppd[17957]: sent [CCP ConfReq id=0x1 ] Mar 29 00:04:09 helbig pppd[17957]: rcvd 80 21 01 01 00 28 02 06 00 2d 0f 01 03 06 00 00 00 00 81 06 00 00 00 00 82 06 00 00 00 00 83 06 00 00 00 00 84 06 00 00 00 00 >>>> see below, why I think this is a valid IPCP-Frame Mar 29 00:04:09 helbig pppd[17957]: Unknown protocol (0x101) received Mar 29 00:04:09 helbig pppd[17957]: sent [LCP ProtRej id=0x2 01 01 00 28 02 06 00 2d 0f 01 03 06 00 00 00 00 81 06 00 00 00 00 82 06 00 00 00 00 83 06 00 00 00 00 84 06 00 00 00 00] Mar 29 00:04:09 helbig pppd[17957]: rcvd 80 21 02 01 00 10 03 06 c0 a8 01 01 02 06 00 2d 0f 01 Mar 29 00:04:09 helbig pppd[17957]: Unknown protocol (0x201) received Mar 29 00:04:09 helbig pppd[17957]: sent [LCP ProtRej id=0x3 02 01 00 10 03 06 c0 a8 01 01 02 06 00 2d 0f 01] Mar 29 00:04:09 helbig pppd[17957]: rcvd [LCP ProtRej id=0x3 80 fd 01 01 00 07 15 03 2c] Mar 29 00:04:12 helbig pppd[17957]: sent [IPCP ConfReq id=0x1 ] Mar 29 00:04:12 helbig pppd[17957]: rcvd 80 21 01 02 00 28 02 06 00 2d 0f 01 03 06 00 00 00 00 81 06 00 00 00 00 82 06 00 00 00 00 83 06 00 00 00 00 84 06 00 00 00 00 Mar 29 00:04:12 helbig pppd[17957]: Unknown protocol (0x102) received Mar 29 00:04:12 helbig pppd[17957]: sent [LCP ProtRej id=0x4 01 02 00 28 02 06 00 2d 0f 01 03 06 00 00 00 00 81 06 00 00 00 00 82 06 00 00 00 00 83 06 00 00 00 00 84 06 00 00 00 00] Mar 29 00:04:12 helbig pppd[17957]: rcvd 80 21 02 01 00 10 03 06 c0 a8 01 01 02 06 00 2d 0f 01 Mar 29 00:04:12 helbig pppd[17957]: Unknown protocol (0x201) received Mar 29 00:04:12 helbig pppd[17957]: sent [LCP ProtRej id=0x5 02 01 00 10 03 06 c0 a8 01 01 02 06 00 2d 0f 01] Mar 29 00:04:15 helbig pppd[17957]: sent [IPCP ConfReq id=0x1 ] Mar 29 00:04:15 helbig pppd[17957]: rcvd 80 21 01 03 00 10 02 06 00 2d 0f 01 03 06 00 00 00 00 Mar 29 00:04:15 helbig pppd[17957]: Unknown protocol (0x103) received Mar 29 00:04:15 helbig pppd[17957]: sent [LCP ProtRej id=0x6 01 03 00 10 02 06 00 2d 0f 01 03 06 00 00 00 00] Mar 29 00:04:15 helbig pppd[17957]: rcvd 80 21 02 01 00 10 03 06 c0 a8 01 01 02 06 00 2d 0f 01 Mar 29 00:04:15 helbig pppd[17957]: Unknown protocol (0x201) received Mar 29 00:04:15 helbig pppd[17957]: sent [LCP ProtRej id=0x7 02 01 00 10 03 06 c0 a8 01 01 02 06 00 2d 0f 01] Mar 29 00:04:18 helbig pppd[17957]: sent [IPCP ConfReq id=0x1 ] Mar 29 00:04:18 helbig pppd[17957]: rcvd 80 21 01 04 00 10 02 06 00 2d 0f 01 03 06 00 00 00 00 Mar 29 00:04:18 helbig pppd[17957]: Unknown protocol (0x104) received Mar 29 00:04:18 helbig pppd[17957]: sent [LCP ProtRej id=0x8 01 04 00 10 02 06 00 2d 0f 01 03 06 00 00 00 00] Mar 29 00:04:18 helbig pppd[17957]: rcvd 80 21 02 01 00 10 03 06 c0 a8 01 01 02 06 00 2d 0f 01 Mar 29 00:04:18 helbig pppd[17957]: Unknown protocol (0x201) received Mar 29 00:04:18 helbig pppd[17957]: sent [LCP ProtRej id=0x9 02 01 00 10 03 06 c0 a8 01 01 02 06 00 2d 0f 01] Mar 29 00:04:21 helbig pppd[17957]: sent [IPCP ConfReq id=0x1 ] Mar 29 00:04:21 helbig pppd[17957]: rcvd 80 21 01 05 00 10 02 06 00 2d 0f 01 03 06 00 00 00 00 Mar 29 00:04:21 helbig pppd[17957]: Unknown protocol (0x105) received Mar 29 00:04:21 helbig pppd[17957]: sent [LCP ProtRej id=0xa 01 05 00 10 02 06 00 2d 0f 01 03 06 00 00 00 00] Mar 29 00:04:21 helbig pppd[17957]: rcvd 80 21 02 01 00 10 03 06 c0 a8 01 01 02 06 00 2d 0f 01 Mar 29 00:04:21 helbig pppd[17957]: Unknown protocol (0x201) received Mar 29 00:04:21 helbig pppd[17957]: sent [LCP ProtRej id=0xb 02 01 00 10 03 06 c0 a8 01 01 02 06 00 2d 0f 01] Mar 29 00:04:24 helbig pppd[17957]: sent [IPCP ConfReq id=0x1 ] Mar 29 00:04:24 helbig pppd[17957]: rcvd 80 21 01 06 00 10 02 06 00 2d 0f 01 03 06 00 00 00 00 Mar 29 00:04:24 helbig pppd[17957]: Unknown protocol (0x106) received Mar 29 00:04:24 helbig pppd[17957]: sent [LCP ProtRej id=0xc 01 06 00 10 02 06 00 2d 0f 01 03 06 00 00 00 00] Mar 29 00:04:24 helbig pppd[17957]: rcvd 80 21 02 01 00 10 03 06 c0 a8 01 01 02 06 00 2d 0f 01 Mar 29 00:04:24 helbig pppd[17957]: Unknown protocol (0x201) received Mar 29 00:04:24 helbig pppd[17957]: sent [LCP ProtRej id=0xd 02 01 00 10 03 06 c0 a8 01 01 02 06 00 2d 0f 01] Mar 29 00:04:27 helbig pppd[17957]: sent [IPCP ConfReq id=0x1 ] Mar 29 00:04:27 helbig pppd[17957]: rcvd 80 21 01 07 00 10 02 06 00 2d 0f 01 03 06 00 00 00 00 Mar 29 00:04:27 helbig pppd[17957]: Unknown protocol (0x107) received Mar 29 00:04:27 helbig pppd[17957]: sent [LCP ProtRej id=0xe 01 07 00 10 02 06 00 2d 0f 01 03 06 00 00 00 00] Mar 29 00:04:27 helbig pppd[17957]: rcvd 80 21 02 01 00 10 03 06 c0 a8 01 01 02 06 00 2d 0f 01 Mar 29 00:04:27 helbig pppd[17957]: Unknown protocol (0x201) received Mar 29 00:04:27 helbig pppd[17957]: sent [LCP ProtRej id=0xf 02 01 00 10 03 06 c0 a8 01 01 02 06 00 2d 0f 01] Mar 29 00:04:30 helbig pppd[17957]: sent [IPCP ConfReq id=0x1 ] Mar 29 00:04:30 helbig pppd[17957]: rcvd 80 21 01 08 00 10 02 06 00 2d 0f 01 03 06 00 00 00 00 Mar 29 00:04:30 helbig pppd[17957]: Unknown protocol (0x108) received Mar 29 00:04:30 helbig pppd[17957]: sent [LCP ProtRej id=0x10 01 08 00 10 02 06 00 2d 0f 01 03 06 00 00 00 00] Mar 29 00:04:30 helbig pppd[17957]: rcvd 80 21 02 01 00 10 03 06 c0 a8 01 01 02 06 00 2d 0f 01 Mar 29 00:04:30 helbig pppd[17957]: Unknown protocol (0x201) received Mar 29 00:04:30 helbig pppd[17957]: sent [LCP ProtRej id=0x11 02 01 00 10 03 06 c0 a8 01 01 02 06 00 2d 0f 01] Mar 29 00:04:33 helbig pppd[17957]: sent [IPCP ConfReq id=0x1 ] Mar 29 00:04:33 helbig pppd[17957]: rcvd 80 21 01 09 00 10 02 06 00 2d 0f 01 03 06 00 00 00 00 Mar 29 00:04:33 helbig pppd[17957]: Unknown protocol (0x109) received Mar 29 00:04:33 helbig pppd[17957]: sent [LCP ProtRej id=0x12 01 09 00 10 02 06 00 2d 0f 01 03 06 00 00 00 00] Mar 29 00:04:33 helbig pppd[17957]: rcvd 80 21 02 01 00 10 03 06 c0 a8 01 01 02 06 00 2d 0f 01 Mar 29 00:04:33 helbig pppd[17957]: Unknown protocol (0x201) received Mar 29 00:04:33 helbig pppd[17957]: sent [LCP ProtRej id=0x13 02 01 00 10 03 06 c0 a8 01 01 02 06 00 2d 0f 01] Mar 29 00:04:36 helbig pppd[17957]: sent [IPCP ConfReq id=0x1 ] Mar 29 00:04:36 helbig pppd[17957]: rcvd 80 21 01 0a 00 10 02 06 00 2d 0f 01 03 06 00 00 00 00 Mar 29 00:04:36 helbig pppd[17957]: Unknown protocol (0x10a) received Mar 29 00:04:36 helbig pppd[17957]: sent [LCP ProtRej id=0x14 01 0a 00 10 02 06 00 2d 0f 01 03 06 00 00 00 00] Mar 29 00:04:36 helbig pppd[17957]: rcvd 80 21 02 01 00 10 03 06 c0 a8 01 01 02 06 00 2d 0f 01 Mar 29 00:04:36 helbig pppd[17957]: Unknown protocol (0x201) received Mar 29 00:04:36 helbig pppd[17957]: sent [LCP ProtRej id=0x15 02 01 00 10 03 06 c0 a8 01 01 02 06 00 2d 0f 01] Mar 29 00:04:39 helbig pppd[17957]: IPCP: timeout sending Config-Requests Mar 29 00:04:43 helbig pppd[17957]: rcvd [LCP TermReq id=0x4] Mar 29 00:04:43 helbig pppd[17957]: LCP terminated at peer's request Mar 29 00:04:43 helbig pppd[17957]: sent [LCP TermAck id=0x4] Mar 29 00:04:43 helbig pppd[17957]: Terminating on signal 15. Mar 29 00:04:43 helbig pppd[17957]: read_rec1: Interrupted system call Mar 29 00:04:43 helbig pppd[17957]: lost connection: Interrupted system call Mar 29 00:04:43 helbig pppd[17957]: Couldn't restore device fd flags: Bad file descriptor Some parts of the rejected frames I do not understand, here is what I've found out so far: ------------------------------------------------Start of frame----------------- 8021 Protocoll IPCP ------------------------------------------------Start of packet---------------- 01 Code Configure request 01 Identifier 0028 Length 40 Bytes ------------------------------------------------Start of option---------------- 02 Type IP-Compression-Protocol 06 Length 6 Bytes 002d Compr. Proto. Van Jacobson 0f Max-Slot-ID 15 01 Comp-Slot-ID The slot identifier may be compressed. ------------------------------------------------Start of next option----------- 03 Type IP-Address (local IP-Address of sender) 06 Length 6 Bytes 00000000 IP-Address 0.0.0.0 (expecting dynamic address from us) -------------------------------------------------------------------------------- 81 these options I do not know :-( 06 00000000 -------------------------------------------------------------------------------- 82 06 00000000 -------------------------------------------------------------------------------- 83 06 00000000 -------------------------------------------------------------------------------- 84 06 00000000 TIA Wolfgang ----- End of forwarded message from helbig ----- From owner-freebsd-current Mon Mar 31 12:06:24 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id MAA06684 for current-outgoing; Mon, 31 Mar 1997 12:06:24 -0800 (PST) Received: from critter.dk.tfs.com (phk.cybercity.dk [195.8.133.247]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id MAA06553; Mon, 31 Mar 1997 12:03:57 -0800 (PST) Received: from critter (localhost [127.0.0.1]) by critter.dk.tfs.com (8.8.5/8.8.5) with ESMTP id WAA27688; Mon, 31 Mar 1997 22:02:54 +0200 (CEST) To: Garrett Wollman cc: terry@lambert.org, freebsd-current@FreeBSD.ORG Subject: Re: A new Kernel Module System In-reply-to: Your message of "Mon, 31 Mar 1997 14:22:54 CDT." <199703311922.OAA16298@khavrinen.lcs.mit.edu> Date: Mon, 31 Mar 1997 22:02:53 +0200 Message-ID: <27686.859838573@critter> From: Poul-Henning Kamp Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Question: If we stick the linker in the kernel, doesn't it mean that we could use it for shlibs too ? Basically the dl* functions could be made syscalls couldn't they ? That would be way faster than mmap'ing ld.so all the time... -- Poul-Henning Kamp | phk@FreeBSD.ORG FreeBSD Core-team. http://www.freebsd.org/~phk | phk@login.dknet.dk Private mailbox. whois: [PHK] | phk@tfs.com TRW Financial Systems, Inc. Power and ignorance is a disgusting cocktail. From owner-freebsd-current Mon Mar 31 13:05:48 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id NAA10274 for current-outgoing; Mon, 31 Mar 1997 13:05:48 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.50]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id NAA10258 for ; Mon, 31 Mar 1997 13:05:42 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id NAA10071; Mon, 31 Mar 1997 13:49:22 -0700 From: Terry Lambert Message-Id: <199703312049.NAA10071@phaeton.artisoft.com> Subject: Re: A new Kernel Module System To: wollman@khavrinen.lcs.mit.edu (Garrett Wollman) Date: Mon, 31 Mar 1997 13:49:22 -0700 (MST) Cc: terry@lambert.org, freebsd-current@freebsd.org In-Reply-To: <199703311922.OAA16298@khavrinen.lcs.mit.edu> from "Garrett Wollman" at Mar 31, 97 02:22:54 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk [ ... putting the linker for LKM's into the kernel ... ] > >> Garrett disagreed; this is not to say that he didn't have good reasons, > >> but I believe the benefits outweigh the additional size and other > >> issues which he raises. > > Please don't put words into my mouth. Unfortunately the -current list archives do not seem to go back to 1994; I could reluctantly dig it out of my personal archives if I absolutely had to. It was something to the effect of: Terry: Why not? Garrett: Over my dead body... ...and left me feeling that there was no uncertainty about where you were standing on the issue. If you've changed your mind, fine, but the statement was *so* definite and unconditional at the time that it *really* stuck with 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 Mar 31 13:15:45 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id NAA10980 for current-outgoing; Mon, 31 Mar 1997 13:15:45 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.50]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id NAA10973 for ; Mon, 31 Mar 1997 13:15:37 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id NAA10110; Mon, 31 Mar 1997 13:59:25 -0700 From: Terry Lambert Message-Id: <199703312059.NAA10110@phaeton.artisoft.com> Subject: Re: A new Kernel Module System To: phk@critter.dk.tfs.com (Poul-Henning Kamp) Date: Mon, 31 Mar 1997 13:59:25 -0700 (MST) Cc: wollman@khavrinen.lcs.mit.edu, terry@lambert.org, freebsd-current@FreeBSD.ORG In-Reply-To: <27686.859838573@critter> from "Poul-Henning Kamp" at Mar 31, 97 10:02:53 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > Question: If we stick the linker in the kernel, doesn't it mean that > we could use it for shlibs too ? Probably. I've felt for a long time now that the intent of the memory hole at the start of the executable in the ELF SVR4 EABI was to allow the mapping of the ld.so into the process address space without there being code in crt0.o to actually do the work. > Basically the dl* functions could be made syscalls couldn't they ? Or section (3) wrappers for mmap. I don't know how you would deal with the issue of dlsym(), but you'd want to do it in such a way that it didn't matter if the vtable reference was ELF, COFF, a.out, or whatever. That may imply a system call for kernel decoding the format specific symbol information. The big hairy question mark there is how to handle library static data and per thread replication, etc.. I'd like to see it instanced per link instead of crammed into the image as static data. That would resolve a number of my LGPL misgivings about dynamic linking. I don't know how you would make the compiler generate the slower PIC references to the data in that case, and NOT do it in all cases. > That would be way faster than mmap'ing ld.so all the time... Unless the kernel did the mapping and the ld.so was (effectively) a piece of the execution class loader, as a result. The difference, I suppose, is where the r/o mappings for the linker code originated, and whether they were in the process address space, or whether you had to cross a real protection domain to get them. I'd almost prefer they stay in the process address space (trading startup speed in favor of runtime speed). 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 Mar 31 15:51:29 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id PAA19638 for current-outgoing; Mon, 31 Mar 1997 15:51:29 -0800 (PST) Received: from daniel.sobral ([200.239.56.223]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id PAA19431 for ; Mon, 31 Mar 1997 15:49:18 -0800 (PST) Received: (from dcs@localhost) by daniel.sobral (8.7.6/8.7.3) id UAA15037 for current@freefall.freebsd.org; Mon, 31 Mar 1997 20:50:22 -0300 (EST) From: "Daniel C. Sobral" Message-Id: <199703312350.UAA15037@daniel.sobral> Subject: xinstall problem To: current@freefall.freebsd.org Date: Mon, 31 Mar 1997 20:50:22 -0300 (EST) Disclaimer: Klaatu Barada Nikto! 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-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk I have been trying to make world about a week now, always to fail at xinstall (MAP_FAILED undeclared at lines 517 and 584, functions compare and copy). Is anyone else experiencing this problem? -- Daniel C. Sobral (8-DCS) dcs@gns.com.br dcs@linf.unb.br Heisenberg may have been here. From owner-freebsd-current Mon Mar 31 19:27:07 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id TAA03931 for current-outgoing; Mon, 31 Mar 1997 19:27:07 -0800 (PST) Received: from austin.polstra.com (austin.polstra.com [206.213.73.10]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id TAA03926 for ; Mon, 31 Mar 1997 19:27:03 -0800 (PST) Received: from austin.polstra.com (jdp@localhost) by austin.polstra.com (8.8.5/8.8.5) with ESMTP id TAA24955; Mon, 31 Mar 1997 19:26:45 -0800 (PST) Message-Id: <199704010326.TAA24955@austin.polstra.com> To: phk@critter.dk.tfs.com Subject: Re: A new Kernel Module System Newsgroups: polstra.freebsd.current In-Reply-To: <27686.859838573@critter> References: <27686.859838573@critter> Organization: Polstra & Co., Seattle, WA Cc: current@freebsd.org Date: Mon, 31 Mar 1997 19:26:44 -0800 From: John Polstra Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk PHK wrote: > Question: If we stick the linker in the kernel, doesn't it mean that > we could use it for shlibs too ? > > Basically the dl* functions could be made syscalls couldn't they ? > > That would be way faster than mmap'ing ld.so all the time... Part of it could be put into the kernel, I suppose. But some of the things it does, such as dealing with ld.so.hints and LD_LIBRARY_PATH, and searching for shared libraries, seem to me like they don't belong in the kernel. When I worked on speeding up ld.so some time ago, I set up a "not quite profiling" system for measuring how much time was spent doing various things inside the dynamic linker. Mmapping it seemed to take a negligible portion of the time. Most of the time was spent in the actual linking, i.e., doing relocations and binding symbol definitions and references. (I was able to get speedups of up to a factor of three just by improving the symbol lookup code.) These tasks are strictly computational, and putting them in the kernel is unlikely to make any difference. If you want to avoid the overhead of mmapping ld.so all the time, SVR4 had a good idea. There, the dynamic linker is a part of libc. By mapping the dynamic linker, you also get libc for free. Since libc is used by every program, it's a win. The downside is that the coupling between ld.so versions and libc versions becomes much tighter. On a different but related subject ... Maybe nobody's confused about this, but just in case: The kernel modules (new LKMs) do not have to be PIC. They can just as well be plain object files, and they probably should be. PIC is only needed when the same object is going to be mapped simultaneously into several different processes at potentially different addresses. PIC doesn't eliminate the need for relocation; it just isolates all the position-dependent information in the data segment. Since each kernel module will be mapped at most once into the kernel, there's no need to make it PIC. It should probably not be PIC, because of the substantial performance penalty that PIC adds. John -- John Polstra jdp@polstra.com John D. Polstra & Co., Inc. Seattle, Washington USA "Self-knowledge is always bad news." -- John Barth From owner-freebsd-current Mon Mar 31 19:28:45 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id TAA04007 for current-outgoing; Mon, 31 Mar 1997 19:28:45 -0800 (PST) Received: from veda.is (ubiq.veda.is [193.4.230.60]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id TAA04000 for ; Mon, 31 Mar 1997 19:28:41 -0800 (PST) Received: (from adam@localhost) by veda.is (8.8.4/8.7.3) id DAA27966; Tue, 1 Apr 1997 03:49:35 GMT Date: Tue, 1 Apr 1997 03:49:35 GMT From: Adam David Message-Id: <199704010349.DAA27966@veda.is> To: sos@ravenock.cybercity.DK (Søren Schmidt) Cc: freebsd-current@freebsd.org Subject: Re: pppd ?? do we have a maintainer ?? Newsgroups: list.freebsd.current References: <199703302055.OAA17217@main.gbdata.com> <199703302057.WAA00729@ravenock.cybercity.dk> X-Newsreader: NN version 6.5.0 #2 (NOV) Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >> Huh? You mean pppd? The light/2 stuff must have broken it then, because >> I'm running the snap from right before then and have never had a problem. >That cant be :) unless you use it as a client only :) I'm running 21.jan.1997-current and pppd works fine as a server. I've not found a way of tricking it into accepting an "instant" login from a Windows box yet though, in cooperation with getty. -- Adam David From owner-freebsd-current Mon Mar 31 19:29:51 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id TAA04069 for current-outgoing; Mon, 31 Mar 1997 19:29:51 -0800 (PST) Received: from austin.polstra.com (austin.polstra.com [206.213.73.10]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id TAA04064 for ; Mon, 31 Mar 1997 19:29:46 -0800 (PST) Received: from austin.polstra.com (jdp@localhost) by austin.polstra.com (8.8.5/8.8.5) with ESMTP id TAA25551; Mon, 31 Mar 1997 19:28:52 -0800 (PST) Message-Id: <199704010328.TAA25551@austin.polstra.com> To: terry@lambert.org Subject: Re: A new Kernel Module System Newsgroups: polstra.freebsd.current In-Reply-To: <199703312059.NAA10110@phaeton.artisoft.com> References: <199703312059.NAA10110@phaeton.artisoft.com> Organization: Polstra & Co., Seattle, WA Cc: current@freebsd.org Date: Mon, 31 Mar 1997 19:28:52 -0800 From: John Polstra Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In article <199703312059.NAA10110@phaeton.artisoft.com>, Terry Lambert wrote: > I've felt for a long time now that the intent of the memory hole > at the start of the executable in the ELF SVR4 EABI was to allow > the mapping of the ld.so into the process address space without > there being code in crt0.o to actually do the work. That is exactly the case in SVR4. The kernel maps the combined libc+ld.so into the hole before execution begins. -- John Polstra jdp@polstra.com John D. Polstra & Co., Inc. Seattle, Washington USA "Self-knowledge is always bad news." -- John Barth From owner-freebsd-current Mon Mar 31 19:38:43 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id TAA04848 for current-outgoing; Mon, 31 Mar 1997 19:38:43 -0800 (PST) Received: from veda.is (ubiq.veda.is [193.4.230.60]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id TAA04842 for ; Mon, 31 Mar 1997 19:38:39 -0800 (PST) Received: (from adam@localhost) by veda.is (8.8.4/8.7.3) id EAA28007; Tue, 1 Apr 1997 04:00:31 GMT Date: Tue, 1 Apr 1997 04:00:31 GMT From: Adam David Message-Id: <199704010400.EAA28007@veda.is> To: jdp@polstra.COM (John Polstra) Cc: freebsd-current@freebsd.org Subject: Re: sendmail and 2.2.1R not happy Newsgroups: list.freebsd.current References: <199703302103.OAA01705@Ilsa.StevesCafe.com> <199703311630.IAA09912@austin.polstra.com> X-Newsreader: NN version 6.5.0 #2 (NOV) Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >In article <199703302103.OAA01705@Ilsa.StevesCafe.com>, >Steve Passe wrote: >> Mar 29 19:19:39 Sam sendmail[540]: /etc/pwd.db: Permission denied >> Mar 29 19:19:39 Sam sendmail[540]: LAA04887: SYSERR(UID1): Cannot exec >> /usr/libexec/mail.local: Permission denied I've seen stuff like this quite often after updating binaries in a running system. Come to think of it, I've also seen this kind of stuff spontaneously after fairly long uptimes, and with no obvious triggering condition. Once in a while no exec's are possible (permission denied, segmentation violation, bus error, whatever). Then after awhile it tends to clear up by itself. This is with NFS mounted /usr. BTW, have the recently introduced NFS exec panics been taken care of yet and fixed? -- Adam David From owner-freebsd-current Mon Mar 31 20:52:02 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id UAA09642 for current-outgoing; Mon, 31 Mar 1997 20:52:02 -0800 (PST) Received: from 586quick166.saturn-tech.com ([207.229.19.32]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id UAA09625 for ; Mon, 31 Mar 1997 20:51:57 -0800 (PST) Received: from localhost (drussell@localhost) by 586quick166.saturn-tech.com (8.8.4/8.8.4) with SMTP id VAA13405; Mon, 31 Mar 1997 21:51:36 -0700 (MST) X-Authentication-Warning: 586quick166.saturn-tech.com: drussell owned process doing -bs Date: Mon, 31 Mar 1997 21:51:35 -0700 (MST) From: Doug Russell To: Adam David cc: freebsd-current@FreeBSD.ORG Subject: Re: pppd ?? do we have a maintainer ?? In-Reply-To: <199704010349.DAA27966@veda.is> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Tue, 1 Apr 1997, Adam David wrote: > I've not found a way of tricking it into accepting an "instant" login from > a Windows box yet though, in cooperation with getty. That's actually really easy. First of all, add some entries in gettytab: ppp.57600|57600-baud:\ :np:sp#57600:pp=/usr/local/libexec/ppplogin: ppp.115200|115200-baud:\ :np:sp#115200:pp=/usr/local/libexec/ppplogin: then create a script in /usr/local/libexec called ppplogin. It can be really simple.... #! /bin/sh - stty crtscts exec /usr/sbin/pppd auth login +pap Or, it can be more complex, depending on your needs. The only thing it is really lacking right now, IMHO, is a way to *cleanly* allow certain users to have their own static IP number, while everyone else gets a specific IP per ttyd they are on. Right now, I'm smooshing it by forcing all auto-logins (windows, whatever) though getty and the script to use the IP number based on the tty, and the couple priveledged users have to log in and exec pppd, which is owned by group pppds, to which those priveledged users belong, and only those users can exec... Then you just make a .ppprc file in their home directory, r/w able only by root with a :theiraddress line in it, and all they have to do is log in and type pppd. It works, but it's kludgy. Static IP users can't auto-login from Windows, and others can't log in via a script and hit pppd, but so far neither has been a problem. :) Later...... From owner-freebsd-current Mon Mar 31 23:32:51 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id XAA16343 for current-outgoing; Mon, 31 Mar 1997 23:32:51 -0800 (PST) Received: from peeper.jackson.org ([208.128.8.135]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id XAA16337 for ; Mon, 31 Mar 1997 23:32:47 -0800 (PST) Received: (from tom@localhost) by peeper.jackson.org (8.8.5/8.7.3) id BAA00255; Tue, 1 Apr 1997 01:18:48 -0600 (CST) Message-ID: <19970401011847.31693@peeper.jackson.org> Date: Tue, 1 Apr 1997 01:18:47 -0600 From: Tom Jackson To: current@freebsd.org Subject: Current is crashing X Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.67e Reply-To: toj@gorilla.net Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Running current on a p5/100. Kernel built from ctm#2824 seemed to have no problems. Got ctm#2827 today and since there had been some kernel source changes, rebuilt the kernel after a successful make on the system. When I went to start X the box crashes and does an auto reboot. CTM having its latency, I looked for anything similar, didn't see any, and wonder if this is some fluke. Any others see this? -- Tom Jackson I'm ProChoice->FreeBSD toj@gorilla.net http://www.freebsd.org tjackson@tulsix.utulsa.edu "Out in the Ozone Again" From owner-freebsd-current Tue Apr 1 00:31:59 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id AAA18913 for current-outgoing; Tue, 1 Apr 1997 00:31:59 -0800 (PST) Received: from nlsystems.com (nlsys.demon.co.uk [158.152.125.33]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id AAA18905 for ; Tue, 1 Apr 1997 00:31:52 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by nlsystems.com (8.8.5/8.8.5) with SMTP id JAA00327; Tue, 1 Apr 1997 09:31:02 +0100 (BST) Date: Tue, 1 Apr 1997 09:31:02 +0100 (BST) From: Doug Rabson To: John Polstra cc: phk@critter.dk.tfs.com, current@FreeBSD.ORG Subject: Re: A new Kernel Module System In-Reply-To: <199704010326.TAA24955@austin.polstra.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Mon, 31 Mar 1997, John Polstra wrote: > On a different but related subject ... Maybe nobody's confused about > this, but just in case: The kernel modules (new LKMs) do not have > to be PIC. They can just as well be plain object files, and they > probably should be. PIC is only needed when the same object is > going to be mapped simultaneously into several different processes > at potentially different addresses. PIC doesn't eliminate the need > for relocation; it just isolates all the position-dependent > information in the data segment. Since each kernel module will be > mapped at most once into the kernel, there's no need to make it PIC. > It should probably not be PIC, because of the substantial > performance penalty that PIC adds. Exactly what I was thinking. PIC has no benefits for the kernel. The only thing I would need from the a.out shlib format is the relocations and runtime symbol table. -- Doug Rabson Mail: dfr@nlsystems.com Nonlinear Systems Ltd. Phone: +44 181 951 1891 From owner-freebsd-current Tue Apr 1 01:28:35 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id BAA20820 for current-outgoing; Tue, 1 Apr 1997 01:28:35 -0800 (PST) Received: from fgate.flevel.co.uk (root@fgate.flevel.co.uk [194.6.101.2]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id BAA20799; Tue, 1 Apr 1997 01:28:30 -0800 (PST) Received: from localhost (dev@localhost) by fgate.flevel.co.uk (8.8.3/8.6.9) with SMTP id KAA25766; Tue, 1 Apr 1997 10:28:28 +0100 (BST) Date: Tue, 1 Apr 1997 10:28:28 +0100 (BST) From: Developer To: freebsd-current@freebsd.org, freebsd-hackers@freebsd.org Subject: PPP Desperate for help! Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk We are really stuck trying to get the PPP user program (ppp) to connect to our Perle 833 dial in server. We can connect using Windows NT fine but on BSD ppp logs in and then data will travel in both directions (As I can see the modem lights flash at both ends for both send/recieve) but no data seems to actually get through as pings do not work. The packets from the server to the user, but seem to be lost on the way back. Ive had this problem for a week now and no solution?? Thanks in advance. Trefor S. From owner-freebsd-current Tue Apr 1 02:16:46 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id CAA22639 for current-outgoing; Tue, 1 Apr 1997 02:16:46 -0800 (PST) Received: from mailbox.uq.edu.au (zzshocki.slip.cc.uq.edu.au [130.102.221.173]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id CAA22633 for ; Tue, 1 Apr 1997 02:16:39 -0800 (PST) Received: from bloop.craftncomp.com (localhost.craftncomp.com [127.0.0.1]) by mailbox.uq.edu.au (8.8.5/8.6.12) with ESMTP id UAA28966; Tue, 1 Apr 1997 20:09:58 +1000 (EST) Message-Id: <199704011009.UAA28966@mailbox.uq.edu.au> X-Mailer: exmh version 2.0gamma 1/27/96 To: toj@gorilla.net cc: current@freebsd.org, toor@dyson.net Subject: Re: Current is crashing X In-reply-to: Your message of "Tue, 01 Apr 1997 01:18:47 CST." <19970401011847.31693@peeper.jackson.org> From: shocking@mailbox.uq.edu.au Reply-To: shocking@mailbox.uq.edu.au Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 01 Apr 1997 20:09:56 +1000 Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > Running current on a p5/100. Kernel built from ctm#2824 seemed to have no > problems. Got ctm#2827 today and since there had been some kernel source > changes, rebuilt the kernel after a successful make on the system. When > I went to start X the box crashes and does an auto reboot. > > CTM having its latency, I looked for anything similar, didn't see any, and > wonder if this is some fluke. Any others see this? Yup. I'm getting a panic with "lockmgr: locking against myself", which is tracked down to /sys/sys/lock.c. It occurs when the X server gets a client, i.e. it happens when firing up startx or having xdm start X, but not when running the X server by itself (/usr/X11R6/bin/XF86_whatever). I can get a traceback, but the offending machine is at work at the moment. This happened between src-cur 2826 & src-cur 2827 (i.e. it did not exist at 2826). Stephen From owner-freebsd-current Tue Apr 1 02:16:59 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id CAA22658 for current-outgoing; Tue, 1 Apr 1997 02:16:59 -0800 (PST) Received: from korin.warman.org.pl (korin.warman.org.pl [148.81.160.10]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id CAA22646 for ; Tue, 1 Apr 1997 02:16:49 -0800 (PST) Received: from localhost (abial@localhost) by korin.warman.org.pl (8.8.3/8.7.3) with SMTP id MAA27014; Tue, 1 Apr 1997 12:15:58 +0200 (MET DST) Date: Tue, 1 Apr 1997 12:15:57 +0200 (MET DST) From: Andrzej Bialecki To: "Daniel C. Sobral" cc: current@freefall.freebsd.org Subject: Re: xinstall problem In-Reply-To: <199703312350.UAA15037@daniel.sobral> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Mon, 31 Mar 1997, Daniel C. Sobral wrote: > I have been trying to make world about a week now, always to fail at > xinstall (MAP_FAILED undeclared at lines 517 and 584, functions > compare and copy). Is anyone else experiencing this problem? Try to install /usr/include files *first*, before you make the world. At least this helped in my case... BTW: how old the sources are? > > Heisenberg may have been here. > True... :-) Andy, +-------------------------------------------------------------------------+ Andrzej Bialecki _) _) _)_) _)_)_) _) _) --------------------------------------- _)_) _) _) _) _)_) _)_) Research and Academic Network in Poland _) _)_) _)_)_)_) _) _) _) Bartycka 18, 00-716 Warsaw, Poland _) _) _) _) _)_)_) _) _) +-------------------------------------------------------------------------+ From owner-freebsd-current Tue Apr 1 02:47:42 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id CAA23872 for current-outgoing; Tue, 1 Apr 1997 02:47:42 -0800 (PST) Received: from korin.warman.org.pl (korin.warman.org.pl [148.81.160.10]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id CAA23853; Tue, 1 Apr 1997 02:47:25 -0800 (PST) Received: from localhost (abial@localhost) by korin.warman.org.pl (8.8.3/8.7.3) with SMTP id MAA27130; Tue, 1 Apr 1997 12:23:56 +0200 (MET DST) Date: Tue, 1 Apr 1997 12:23:55 +0200 (MET DST) From: Andrzej Bialecki To: Developer cc: freebsd-current@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: PPP Desperate for help! In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Tue, 1 Apr 1997, Developer wrote: > > We are really stuck trying to get the PPP user program (ppp) to connect to > our Perle 833 dial in server. We can connect using Windows NT fine but on > BSD ppp logs in and then data will travel in both directions (As I can see > the modem lights flash at both ends for both send/recieve) but no data > seems to actually get through as pings do not work. The packets from the > server to the user, but seem to be lost on the way back. Let me take a guess: maybe it's a known problem with tcp_extensions set to YES in /etc/sysconfig? Some broken TCP stacks don't like it, so the solution would be to turn it off. Andy +-------------------------------------------------------------------------+ Andrzej Bialecki _) _) _)_) _)_)_) _) _) --------------------------------------- _)_) _) _) _) _)_) _)_) Research and Academic Network in Poland _) _)_) _)_)_)_) _) _) _) Bartycka 18, 00-716 Warsaw, Poland _) _) _) _) _)_)_) _) _) +-------------------------------------------------------------------------+ From owner-freebsd-current Tue Apr 1 02:58:54 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id CAA24170 for current-outgoing; Tue, 1 Apr 1997 02:58:54 -0800 (PST) Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id CAA24165 for ; Tue, 1 Apr 1997 02:58:51 -0800 (PST) Received: (from msmith@localhost) by genesis.atrad.adelaide.edu.au (8.8.5/8.7.3) id UAA19942; Tue, 1 Apr 1997 20:28:27 +0930 (CST) From: Michael Smith Message-Id: <199704011058.UAA19942@genesis.atrad.adelaide.edu.au> Subject: Re: A new Kernel Module System In-Reply-To: <20519.859756869@time.cdrom.com> from "Jordan K. Hubbard" at "Mar 30, 97 01:21:09 pm" To: jkh@time.cdrom.com (Jordan K. Hubbard) Date: Tue, 1 Apr 1997 20:28:27 +0930 (CST) Cc: dfr@nlsystems.com, current@freebsd.org X-Mailer: ELM [version 2.4ME+ PL28 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk (Apologies for lobbing in at the wrong end of a discussion. I promise to backtrack when I have dealt with my easter-holiday mail backlog 8) Jordan K. Hubbard stands accused of saying: > > Ah, OK, this is the bit I missed. So you'd use this to load drivers > that the kernel had never seen before, e.g. say I get a floppy from > ABC Systems along with their new network interface card which none of > us have ever even heard of before, and when I say: > > mcopy a:abc_foonic.so /lkm/devs/isa > isaconf -a foo0 port=0x320 irq=11 iomem=0xd0000 > modload /lkm/devs/isa/foo0.so > > It all does the right stuff? That sounds pretty right. It's likely that isaconf should backend onto the "registry" thing, ie. the probe parameters for the ISA device(s) would be persistent across reboots etc. > What if it's a PCI or EISA card, do I just do the modload and expect > it to DTRT? That would make sense; if the module supported PCI/EISA hardware it should know how to look for the hardware it grokked, but that's not so easy because the driver may well support hardware it doesn't actually know it supports. > Jordan -- ]] Mike Smith, Software Engineer msmith@gsoft.com.au [[ ]] Genesis Software genesis@gsoft.com.au [[ ]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[ ]] realtime instrument control. (ph) +61-8-8267-3493 [[ ]] Unix hardware collector. "Where are your PEZ?" The Tick [[ From owner-freebsd-current Tue Apr 1 04:42:59 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id EAA29252 for current-outgoing; Tue, 1 Apr 1997 04:42:59 -0800 (PST) Received: from fgate.flevel.co.uk (root@fgate.flevel.co.uk [194.6.101.2]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id EAA29232; Tue, 1 Apr 1997 04:42:52 -0800 (PST) Received: from localhost (dev@localhost) by fgate.flevel.co.uk (8.8.3/8.6.9) with SMTP id NAA27341; Tue, 1 Apr 1997 13:42:45 +0100 (BST) Date: Tue, 1 Apr 1997 13:42:45 +0100 (BST) From: Developer cc: freebsd-current@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: PPP Desperate for help! In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Tue, 1 Apr 1997, Andrzej Bialecki wrote: > On Tue, 1 Apr 1997, Developer wrote: > > > > > We are really stuck trying to get the PPP user program (ppp) to connect to > > our Perle 833 dial in server. We can connect using Windows NT fine but on > > BSD ppp logs in and then data will travel in both directions (As I can see > > the modem lights flash at both ends for both send/recieve) but no data > > seems to actually get through as pings do not work. The packets from the > > server to the user, but seem to be lost on the way back. > > Let me take a guess: maybe it's a known problem with tcp_extensions set to > YES in /etc/sysconfig? Some broken TCP stacks don't like it, so the > solution would be to turn it off. > > Andy We've tried this - no difference. Any more ideas please? From owner-freebsd-current Tue Apr 1 05:07:59 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id FAA00153 for current-outgoing; Tue, 1 Apr 1997 05:07:59 -0800 (PST) Received: from milkyway.org (lta-r-1.usit.net [205.241.194.17]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id FAA00133; Tue, 1 Apr 1997 05:07:53 -0800 (PST) Received: (from toby@localhost) by milkyway.org (8.8.3/8.8.3) id IAA00318; Tue, 4 Mar 1997 08:09:19 -0500 (EST) Date: Tue, 4 Mar 1997 08:09:19 -0500 (EST) From: "Toby J. Swanson" Message-Id: <199703041309.IAA00318@milkyway.org> To: dev@fgate.flevel.co.uk, freebsd-current@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: PPP Desperate for help! Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Greetings, I am no expert, but I have sucessfully set up several PPP connections and am willing to help. Item first - Please describe the sequence of events fully. Such as, I enter the command "ppp destination", the machine responds "Log level is 09, Using i From owner-freebsd-current Tue Apr 1 05:23:25 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id FAA00880 for current-outgoing; Tue, 1 Apr 1997 05:23:25 -0800 (PST) Received: from nlsystems.com (nlsys.demon.co.uk [158.152.125.33]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id FAA00873 for ; Tue, 1 Apr 1997 05:23:18 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by nlsystems.com (8.8.5/8.8.5) with SMTP id OAA03230; Tue, 1 Apr 1997 14:21:46 +0100 (BST) Date: Tue, 1 Apr 1997 14:21:46 +0100 (BST) From: Doug Rabson To: Terry Lambert cc: current@freebsd.org Subject: Re: A new Kernel Module System In-Reply-To: <199703311732.KAA09669@phaeton.artisoft.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Mon, 31 Mar 1997, Terry Lambert wrote: > > The linker set for a dynamically loaded module would be local to the > > object file containing the module. Look at the implementation of C++ > > constructors in userland shared libraries. When the shlib is linked, the > > linker sets are aggregated. When it is loaded, the linker calls init code > > in the lib which uses the set. SYSINIT() from a loadable module would be > > similar. > > I don't think this is the same thing, really. > > Consider that in order to use a dynamically linked shared library, > the symbol list must be imported into the executable that is bound > to the binary. You can't do this for a module which is dynamically > loaded; there is no symbol set within the kernel with knowledge of > the modules constructor symbol names, as there is when the symbols > are linked into the CTOR/DTOR list with a C++ shared library. That isn't quite what I am getting at here. What I mean is that the *implementation* of global ctors/dtors in a.out shlibs is by the use of linker sets. The linker set is aggregated together when the shlib is linker; on load time, the loader calls a single entry point for the shlib which deals with the constructors. In C++ at least, it is perfectly possible to have a shlib which has no exported symbols at all other than the ctor entry point. It can still perform useful work through the ctors. > > > > Device instances (struct isa_device) will refer to their driver by > > > > name rather than by pointer. The name to driver mapping is > > > > performed and the device is probed and attached as normal. > > > > > > I'm not clear on why this abstraction is necessary or useful??? > > > > By keeping a separation between device instances (probed or otherwise) and > > device drivers, the driver does not need to be recompiled when the device > > configuration (irq or whatever) is changed. The driver should not depend > > on the individual resource requirements of a particular machine. > > Ah, I understand. It's to allow external manipulation of device data. > > Say I have an interface named "ed0" and I need variable numbers of > parameters to make it work? For instance PCMCIA vs. non-PCMCIA vs. > PnP ISA vs. real PnP PCI. Exactly. For legacy ISA devices which can't be reliably detected, probe hints are supplied by config(8). For PnP ISA devices, probe hints are generated by the pnp scan. > > The idea is sound, but perhaps it needs to be nearly as parametric > as PnP itself? That reminds me, I must read the PnP spec.. > But shouldn't device instantiation within a driver be handled by the > probe code coming true? Is this just for static configuration of > devices without invoking a probe? Yes. The device lists from config(8) are only needed to provide a list of hints on what to probe for. -- Doug Rabson Mail: dfr@nlsystems.com Nonlinear Systems Ltd. Phone: +44 181 951 1891 From owner-freebsd-current Tue Apr 1 05:26:09 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id FAA01002 for current-outgoing; Tue, 1 Apr 1997 05:26:09 -0800 (PST) Received: from milkyway.org (lta-r-1.usit.net [205.241.194.17]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id FAA00980; Tue, 1 Apr 1997 05:26:03 -0800 (PST) Received: (from toby@localhost) by milkyway.org (8.8.3/8.8.3) id IAA00337; Tue, 4 Mar 1997 08:27:35 -0500 (EST) Date: Tue, 4 Mar 1997 08:27:35 -0500 (EST) From: "Toby J. Swanson" Message-Id: <199703041327.IAA00337@milkyway.org> To: dev@fgate.flevel.co.uk, freebsd-current@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: PPP Desperate for help! Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Greetings, I am no expert, but I have set up several PPP connections and am willing to help. Item first - Please describe fully the sequence of events as you execute the ppp command. Such as, I enter "ppp destination". The machine responds with "Log level is 09, Using interface: tun0, ...". Is the dial successful? Is the login successful. Item second - Can you show me the contents of your ppp.conf and ppp.linkup files, or at least the portions dealing with this connection? Any passwords or other sensitive data should be replaced by asterisks. Item last - Have you been able to connect in interactive mode using ppp's term command? Most problems I've encountered have been typos or bad settings in configuration files. If you got a partial message from me before this one, please ignore it. Hope I can be of help. Toby From owner-freebsd-current Tue Apr 1 05:27:23 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id FAA01061 for current-outgoing; Tue, 1 Apr 1997 05:27:23 -0800 (PST) Received: from nlsystems.com (nlsys.demon.co.uk [158.152.125.33]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id FAA01056 for ; Tue, 1 Apr 1997 05:27:19 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by nlsystems.com (8.8.5/8.8.5) with SMTP id OAA03237; Tue, 1 Apr 1997 14:25:58 +0100 (BST) Date: Tue, 1 Apr 1997 14:25:58 +0100 (BST) From: Doug Rabson To: Terry Lambert cc: Warner Losh , jkh@time.cdrom.com, current@freebsd.org Subject: Re: A new Kernel Module System In-Reply-To: <199703311849.LAA09880@phaeton.artisoft.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Mon, 31 Mar 1997, Terry Lambert wrote: > > : Almost. You would load /lkm/devs/isa/foo.so. The driver object does not > > : need an instance number since the same driver could support many different > > : instances: > > : > > : isaconf -a foo0 port=320 irq=10 iomem=0xd0000 > > : isaconf -a foo1 port=330 irq=11 iomem=0xd8000 > > : isaconf -a foo2 port=340 irq=12 iomem=0xe0000 > > : modload /lkm/devs/isa/foo.so > > > > That would be way cool. I'd especially like to be able to do this > > with the GENERIC kernel. Right now there is no way to do this, short > > of booting -c. When you install a new kernel on a machine at a remote > > office and thinkn that you are set because the old kernel was generic > > too and do a reboot, only to find out that it really wasn't generic > > GENERIC.... > > It seems to me that either the isaconf and the modload order is > inverted, or that the kernel should be demand loading the driver > for the isaconf case if the driver were not already present (the > loading done by the *kernel*, not the *isaconf*)... in which case > there should not be a modload at all. Actually, the modload could happen at any time. You could load the driver and attach instances to it after, or you could add device instances first and then load the driver, which would automatically go through the list of unbound instances and attach them to the new driver. It would be possible for isaconf(8) or the kernel to automatically load the driver but this isn't necessary for the purposes of the example. -- Doug Rabson Mail: dfr@nlsystems.com Nonlinear Systems Ltd. Phone: +44 181 951 1891 From owner-freebsd-current Tue Apr 1 06:35:41 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id GAA04269 for current-outgoing; Tue, 1 Apr 1997 06:35:41 -0800 (PST) Received: from etinc.com (et-gw-fr1.etinc.com [204.141.244.98]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id GAA04251; Tue, 1 Apr 1997 06:35:32 -0800 (PST) Received: from dbws.etinc.com (dbws.etinc.com [204.141.95.130]) by etinc.com (8.8.3/8.6.9) with SMTP id JAA15234; Tue, 1 Apr 1997 09:39:40 -0500 (EST) Message-Id: <3.0.32.19970401095010.006a2504@etinc.com> X-Sender: dennis@etinc.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Tue, 01 Apr 1997 09:50:12 -0500 To: Developer From: dennis Subject: Re: PPP Desperate for help! Cc: freebsd-current@FreeBSD.ORG, freebsd-hackers@FreeBSD.ORG Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk At 01:42 PM 4/1/97 +0100, Developer wrote: > > >On Tue, 1 Apr 1997, Andrzej Bialecki wrote: > >> On Tue, 1 Apr 1997, Developer wrote: >> >> > >> > We are really stuck trying to get the PPP user program (ppp) to connect to >> > our Perle 833 dial in server. We can connect using Windows NT fine but on >> > BSD ppp logs in and then data will travel in both directions (As I can see >> > the modem lights flash at both ends for both send/recieve) but no data >> > seems to actually get through as pings do not work. The packets from the >> > server to the user, but seem to be lost on the way back. >> >> Let me take a guess: maybe it's a known problem with tcp_extensions set to >> YES in /etc/sysconfig? Some broken TCP stacks don't like it, so the >> solution would be to turn it off. >> >> Andy > >We've tried this - no difference. Any more ideas please? Why not post a trace of the ppp negotiations? Perhaps there is a parameter conflict....are you getting to state IPCP_OPENED? If not, you cant pass traffic. Dennis From owner-freebsd-current Tue Apr 1 06:59:07 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id GAA05162 for current-outgoing; Tue, 1 Apr 1997 06:59:07 -0800 (PST) Received: from dyslexic.phoenix.net (root@dyslexic.phoenix.net [199.3.233.7]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id GAA05157 for ; Tue, 1 Apr 1997 06:59:04 -0800 (PST) Received: (from gemohler@localhost) by dyslexic.phoenix.net (8.8.5/8.7.3) id IAA09632; Tue, 1 Apr 1997 08:58:09 -0600 (CST) Date: Tue, 1 Apr 1997 08:58:08 -0600 (CST) From: Geoff Mohler X-Sender: gemohler@dyslexic.phoenix.net To: current@FreeBSD.ORG Subject: Bounce Buffers Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk I was getting this on a stock 2.2.1 installation: Panic: Bounce Buffers Out Of Range =-=-=-=-=- I got this when I took the GENERIC *or any* Kernel definition file, and added the line: options "MAXMEM=262144" Then it would report the above error on bootup, just after reporting kernel bus options. Now, the problem only went away after removing a megabyte of ram. When I changed it to: options "MAXMEM=261120" ..it works fine. =-=-=-=-=- ROMANI ITE DOMUM Geoff Mohler Operations Engineer Charter Communications/Phoenix Data Net From owner-freebsd-current Tue Apr 1 08:27:31 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id IAA10239 for current-outgoing; Tue, 1 Apr 1997 08:27:31 -0800 (PST) Received: from austin.polstra.com (austin.polstra.com [206.213.73.10]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id IAA10229 for ; Tue, 1 Apr 1997 08:27:26 -0800 (PST) Received: from austin.polstra.com (jdp@localhost) by austin.polstra.com (8.8.5/8.8.5) with ESMTP id IAA01496; Tue, 1 Apr 1997 08:27:02 -0800 (PST) Message-Id: <199704011627.IAA01496@austin.polstra.com> To: Doug Rabson cc: phk@critter.dk.tfs.com, current@FreeBSD.ORG Subject: Re: A new Kernel Module System In-reply-to: Your message of "Tue, 01 Apr 1997 09:31:02 +0100." References: Date: Tue, 01 Apr 1997 08:27:02 -0800 From: John Polstra Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > Exactly what I was thinking. PIC has no benefits for the kernel. > The only thing I would need from the a.out shlib format is the > relocations and runtime symbol table. I don't think you can get a runtime symbol table, unless you're building a shared object, i.e., using PIC. You'll have to use the "normal" symbol table. That shouldn't be a problem as far as I can see. -- John Polstra jdp@polstra.com John D. Polstra & Co., Inc. Seattle, Washington USA "Self-knowledge is always bad news." -- John Barth From owner-freebsd-current Tue Apr 1 08:35:54 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id IAA10674 for current-outgoing; Tue, 1 Apr 1997 08:35:54 -0800 (PST) Received: from nlsystems.com (nlsys.demon.co.uk [158.152.125.33]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id IAA10662 for ; Tue, 1 Apr 1997 08:35:40 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by nlsystems.com (8.8.5/8.8.5) with SMTP id RAA04139; Tue, 1 Apr 1997 17:34:20 +0100 (BST) Date: Tue, 1 Apr 1997 17:34:18 +0100 (BST) From: Doug Rabson To: John Polstra cc: phk@critter.dk.tfs.com, current@FreeBSD.ORG Subject: Re: A new Kernel Module System In-Reply-To: <199704011627.IAA01496@austin.polstra.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Tue, 1 Apr 1997, John Polstra wrote: > > Exactly what I was thinking. PIC has no benefits for the kernel. > > The only thing I would need from the a.out shlib format is the > > relocations and runtime symbol table. > > I don't think you can get a runtime symbol table, unless you're building > a shared object, i.e., using PIC. You'll have to use the "normal" > symbol table. That shouldn't be a problem as far as I can see. I am pretty sure that if I link a bunch of objects together using -Bshareable, then ld(1) will generate a symbol table for me. The objects don't have to contain PIC code for this. You can do this with non-PIC objects for userland shared libraries but the text relocations make this wasteful of memory. -- Doug Rabson Mail: dfr@nlsystems.com Nonlinear Systems Ltd. Phone: +44 181 951 1891 From owner-freebsd-current Tue Apr 1 08:53:28 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id IAA11511 for current-outgoing; Tue, 1 Apr 1997 08:53:28 -0800 (PST) Received: from austin.polstra.com (austin.polstra.com [206.213.73.10]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id IAA11497 for ; Tue, 1 Apr 1997 08:53:24 -0800 (PST) Received: from austin.polstra.com (jdp@localhost) by austin.polstra.com (8.8.5/8.8.5) with ESMTP id IAA02429; Tue, 1 Apr 1997 08:53:09 -0800 (PST) Message-Id: <199704011653.IAA02429@austin.polstra.com> To: Doug Rabson cc: current@FreeBSD.ORG Subject: Re: A new Kernel Module System In-reply-to: Your message of "Tue, 01 Apr 1997 17:34:18 +0100." References: Date: Tue, 01 Apr 1997 08:53:09 -0800 From: John Polstra Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > I am pretty sure that if I link a bunch of objects together using > -Bshareable, then ld(1) will generate a symbol table for me. Yes, you're right. I stand corrected. You get zillions of warnings about RRS text relocations, but the output file does seem to be legitimate. I still have doubts that this buys you anything, though. Is there any advantage over just using the static symbol table and relocations? Remember, you'll have to link against kernel symbols too, and it won't have a run-time symbol table. -- John Polstra jdp@polstra.com John D. Polstra & Co., Inc. Seattle, Washington USA "Self-knowledge is always bad news." -- John Barth From owner-freebsd-current Tue Apr 1 09:08:54 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id JAA12583 for current-outgoing; Tue, 1 Apr 1997 09:08:54 -0800 (PST) Received: from rocky.mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id JAA12578 for ; Tue, 1 Apr 1997 09:08:50 -0800 (PST) Received: (from nate@localhost) by rocky.mt.sri.com (8.7.5/8.7.3) id KAA02706; Tue, 1 Apr 1997 10:08:46 -0700 (MST) Date: Tue, 1 Apr 1997 10:08:46 -0700 (MST) Message-Id: <199704011708.KAA02706@rocky.mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: current@freebsd.org Subject: NCR extraneous data error messages now gone X-Mailer: VM 6.22 under 19.14 XEmacs Lucid Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk It looks like it was fixed with the following change: revision 1.47 date: 1997/03/24 01:46:15; author: gibbs; state: Exp; lines: +3 -1 free_xs must be called at splbio(). This is usually the case since the main caller is scsi_done which the controller interrupt handlers call. In the case of a non-buffer based transaction, the xs structure is freed by the process that initiated the transfer in scsi_scsi_cmd. In this case, an explicit splbio/splx pair around the call to free_xs is required. Without the splbio protection, the xs free list could be corrupted, and the type driver's start routine might run without spl protection. Submitted by: Tor Egge Obtained from: PR kern/2891 (This was also brought into 2.2 as well) From owner-freebsd-current Tue Apr 1 09:50:15 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id JAA15554 for current-outgoing; Tue, 1 Apr 1997 09:50:15 -0800 (PST) Received: from who.cdrom.com (who.cdrom.com [204.216.27.3]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id JAA15542 for ; Tue, 1 Apr 1997 09:50:12 -0800 (PST) Received: from nlsystems.com (nlsys.demon.co.uk [158.152.125.33]) by who.cdrom.com (8.8.5/8.6.11) with ESMTP id JAA14878 for ; Tue, 1 Apr 1997 09:49:11 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by nlsystems.com (8.8.5/8.8.5) with SMTP id SAA04222; Tue, 1 Apr 1997 18:43:20 +0100 (BST) Date: Tue, 1 Apr 1997 18:43:20 +0100 (BST) From: Doug Rabson To: John Polstra cc: current@FreeBSD.ORG Subject: Re: A new Kernel Module System In-Reply-To: <199704011653.IAA02429@austin.polstra.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Tue, 1 Apr 1997, John Polstra wrote: > > I am pretty sure that if I link a bunch of objects together using > > -Bshareable, then ld(1) will generate a symbol table for me. > > Yes, you're right. I stand corrected. You get zillions of warnings > about RRS text relocations, but the output file does seem to be > legitimate. > > I still have doubts that this buys you anything, though. Is there any > advantage over just using the static symbol table and relocations? > Remember, you'll have to link against kernel symbols too, and it won't > have a run-time symbol table. I plan to link the kernel as if it was a dynamic executable. This involves hacking ld(1) so that it still generates _DYNAMIC information even if no shared libraries are seen in the link. -- Doug Rabson Mail: dfr@nlsystems.com Nonlinear Systems Ltd. Phone: +44 181 951 1891 From owner-freebsd-current Tue Apr 1 09:50:37 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id JAA15640 for current-outgoing; Tue, 1 Apr 1997 09:50:37 -0800 (PST) Received: from who.cdrom.com (who.cdrom.com [204.216.27.3]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id JAA15628 for ; Tue, 1 Apr 1997 09:50:34 -0800 (PST) Received: from peeper.jackson.org ([208.128.8.138]) by who.cdrom.com (8.8.5/8.6.11) with ESMTP id JAA14886 for ; Tue, 1 Apr 1997 09:50:31 -0800 (PST) Received: (from tom@localhost) by peeper.jackson.org (8.8.5/8.7.3) id LAA01516; Tue, 1 Apr 1997 11:49:09 -0600 (CST) Message-ID: <19970401114909.30003@peeper.jackson.org> Date: Tue, 1 Apr 1997 11:49:09 -0600 From: Tom Jackson To: freebsd-current@freebsd.org Subject: Re: PPP Desperate for help! References: <3.0.32.19970401095010.006a2504@etinc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.67e In-Reply-To: <3.0.32.19970401095010.006a2504@etinc.com>; from dennis on Tue, Apr 01, 1997 at 09:50:12AM -0500 Reply-To: toj@gorilla.net Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Tue, Apr 01, 1997 at 09:50:12AM -0500, dennis wrote: > At 01:42 PM 4/1/97 +0100, Developer wrote: > >> > We are really stuck trying to get the PPP user program (ppp) to > connect to > >> > our Perle 833 dial in server. We can connect using Windows NT fine but on > >> > BSD ppp logs in and then data will travel in both directions (As I can > see > >> > the modem lights flash at both ends for both send/recieve) but no data > >> > seems to actually get through as pings do not work. The packets from the > >> > server to the user, but seem to be lost on the way back. > > Why not post a trace of the ppp negotiations? Perhaps there is a parameter > conflict....are you getting to state IPCP_OPENED? If not, you cant pass > traffic. Is this dynamic set addressing? If it is and you have anything other than the 127.0.0.1 address for localhost in /etc/hosts, user ppp will not negotiate the dynamic address (at least this is what happens on my box). Use netstat -i to determine your links once the ppp link is up and report results. -- Tom Jackson I'm ProChoice->FreeBSD toj@gorilla.net http://www.freebsd.org tjackson@tulsix.utulsa.edu "Out in the Ozone Again" From owner-freebsd-current Tue Apr 1 09:53:14 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id JAA16027 for current-outgoing; Tue, 1 Apr 1997 09:53:14 -0800 (PST) Received: from dyson.iquest.net (dyson.iquest.net [198.70.144.127]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id JAA16022 for ; Tue, 1 Apr 1997 09:53:11 -0800 (PST) Received: (from root@localhost) by dyson.iquest.net (8.8.4/8.6.9) id MAA02576; Tue, 1 Apr 1997 12:52:51 -0500 (EST) From: "John S. Dyson" Message-Id: <199704011752.MAA02576@dyson.iquest.net> Subject: Re: Bounce Buffers In-Reply-To: from Geoff Mohler at "Apr 1, 97 08:58:08 am" To: gemohler@c-com.net (Geoff Mohler) Date: Tue, 1 Apr 1997 12:52:51 -0500 (EST) 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-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > I was getting this on a stock 2.2.1 installation: > > Panic: Bounce Buffers Out Of Range > =-=-=-=-=- > > I got this when I took the GENERIC *or any* Kernel definition file, and > added the line: > options "MAXMEM=262144" > > Then it would report the above error on bootup, just after reporting > kernel bus options. > > Now, the problem only went away after removing a megabyte of ram. When I > changed it to: > options "MAXMEM=261120" > > ..it works fine. > You can also remove the bounce-buffers define. Those aren't usually needed with new technology hardware. The problem is that the kernel takes so much space, that there isn't room <16MB for bounce buffers. Unless we get lots of users with > 128M using ISA SCSI adaptors, I don't think that it is worth fixing the memory allocation code, until we create physical memory type attributes. John From owner-freebsd-current Tue Apr 1 10:40:51 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id KAA19397 for current-outgoing; Tue, 1 Apr 1997 10:40:51 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.50]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id KAA19386 for ; Tue, 1 Apr 1997 10:40:44 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id LAA11700; Tue, 1 Apr 1997 11:24:19 -0700 From: Terry Lambert Message-Id: <199704011824.LAA11700@phaeton.artisoft.com> Subject: Re: A new Kernel Module System To: jdp@polstra.com (John Polstra) Date: Tue, 1 Apr 1997 11:24:19 -0700 (MST) Cc: terry@lambert.org, current@freebsd.org In-Reply-To: <199704010328.TAA25551@austin.polstra.com> from "John Polstra" at Mar 31, 97 07:28:52 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > I've felt for a long time now that the intent of the memory hole > > at the start of the executable in the ELF SVR4 EABI was to allow > > the mapping of the ld.so into the process address space without > > there being code in crt0.o to actually do the work. > > That is exactly the case in SVR4. The kernel maps the combined libc+ld.so > into the hole before execution begins. I knew that. I'm a former USL employee who hacked on SVR4 kernel code for FS, VM, and process context sharing. It just may not have been the intent of the spec. writers, even though I think it was, since they carefully avoid saying anything about the hole in their rationale. Probably because they don't want to have people come back on them later when their "large enough" reserved area is no longer "large enough". 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 Apr 1 10:52:54 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id KAA20001 for current-outgoing; Tue, 1 Apr 1997 10:52:54 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.50]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id KAA19987 for ; Tue, 1 Apr 1997 10:52:46 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id LAA11731; Tue, 1 Apr 1997 11:35:50 -0700 From: Terry Lambert Message-Id: <199704011835.LAA11731@phaeton.artisoft.com> Subject: Re: A new Kernel Module System To: jdp@polstra.com (John Polstra) Date: Tue, 1 Apr 1997 11:35:50 -0700 (MST) Cc: phk@critter.dk.tfs.com, current@freebsd.org In-Reply-To: <199704010326.TAA24955@austin.polstra.com> from "John Polstra" at Mar 31, 97 07:26:44 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > Question: If we stick the linker in the kernel, doesn't it mean that > > we could use it for shlibs too ? > > > > Basically the dl* functions could be made syscalls couldn't they ? > > > > That would be way faster than mmap'ing ld.so all the time... > > Part of it could be put into the kernel, I suppose. But some of > the things it does, such as dealing with ld.so.hints and LD_LIBRARY_PATH, > and searching for shared libraries, seem to me like they don't > belong in the kernel. The ld.so.hints stuff is trivial, assuming that there is a corrected implementation of kernel level file I/O for it to use to do the dirty deed. The LD_LIBRARY_PATH (like variant symlinks, which are always coming up) is more of a problem in the implementation of process environment space than it is a real issue. The child process created will inherit the parent's value, and at the exec, the envp will be "visibile" to the kernel. The child process can't set it's own path to use in running itself, after all, because of where in crt0 this all happens (before _main is called). 8-). > When I worked on speeding up ld.so some time ago, I set up a "not > quite profiling" system for measuring how much time was spent doing > various things inside the dynamic linker. Mmapping it seemed to take > a negligible portion of the time. Most of the time was spent in the > actual linking, i.e., doing relocations and binding symbol > definitions and references. (I was able to get speedups of up to a > factor of three just by improving the symbol lookup code.) These > tasks are strictly computational, and putting them in the kernel is > unlikely to make any difference. Except for image size, when the code is removed from the crt0 startup code. There are also a number of possible compatability issues which "drop out" when this is done. For instance, in another thread of this discussion, the SVR4 EABI mapping of ld.so and libc, which should be done by our execution class loader for ABI compatability anyway. > If you want to avoid the overhead of mmapping ld.so all the time, > SVR4 had a good idea. There, the dynamic linker is a part of libc. > By mapping the dynamic linker, you also get libc for free. Since > libc is used by every program, it's a win. The downside is that the > coupling between ld.so versions and libc versions becomes much > tighter. Yes; this is not a necessary/sufficient condition on mapping the ld.so; we could still map both of them, and get libc; as you said, the mapping is the least of the issues. One big issue, IMO, is that the symbol munging can be made to "go away", so long as you sort the vtable contents, and call by vtable offset. This assumes a vtable implementation very much like that used by Microsoft, actually -- a win in general, if we wish to be able to consume commercially produced "component-ware". > On a different but related subject ... Maybe nobody's confused about > this, but just in case: The kernel modules (new LKMs) do not have > to be PIC. They can just as well be plain object files, and they > probably should be. PIC is only needed when the same object is > going to be mapped simultaneously into several different processes > at potentially different addresses. PIC doesn't eliminate the need > for relocation; it just isolates all the position-dependent > information in the data segment. Since each kernel module will be > mapped at most once into the kernel, there's no need to make it PIC. > It should probably not be PIC, because of the substantial > performance penalty that PIC adds. Yes. My reference to PIC was relative. If the modules were required to be truly PIC in the current scheme of things, one link would suffice at base address 0, and then the image of the module could be loaded at the allocated space without a relink; clearly, this isn't a real possibility for module stacking, since the relocation offsets of the data need to be patched, and subsequent links would get the data relocated to the wrong address. 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 Apr 1 10:54:22 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id KAA20159 for current-outgoing; Tue, 1 Apr 1997 10:54:22 -0800 (PST) Received: from gateway2.platinum.com (firewall-user@gateway2.platinum.com [206.214.170.8]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id KAA20146 for ; Tue, 1 Apr 1997 10:54:16 -0800 (PST) Received: by gateway2.platinum.com; id MAA16344; Tue, 1 Apr 1997 12:49:55 -0600 Received: from mailhub.platinum.com(172.17.26.25) by gateway2.platinum.com via smap (3.2) id xma016329; Tue, 1 Apr 97 12:49:33 -0600 Received: from bigbert.vt.platinum.com by mailhub.platinum.com (8.8.5/) id MAA13337; Tue, 1 Apr 1997 12:49:32 -0600 (CST) Received: from slimebert.vt.platinum.com by bigbert.vt.platinum.com (8.7.3/NX3.0S) id MAA13120; Tue, 1 Apr 1997 12:51:58 -0600 (CST) Received: by slimebert.vt.platinum.com with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.994.63) id <01BC3E9A.BCDE6B30@slimebert.vt.platinum.com>; Tue, 1 Apr 1997 12:46:37 -0600 Message-ID: From: "Brent J. Nordquist" To: "'freebsd-current@freebsd.org'" Subject: 2.2.1-RELEASE make world fails in libg++/libio Date: Tue, 1 Apr 1997 12:46:36 -0600 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.994.63 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk [Please copy this address in any replies... thanks!] I started with a 2.1.5-era system. I grabbed the entire source tree from //ftp.freebsd.org/pub/FreeBSD/2.2.1-RELEASE/src and installed it using install.sh (starting with /usr/src and /usr/obj completely empty). make world is dying here: c++ -O -I/usr/src/gnu/lib/libstdc++/../../../contrib/libg++/include -I/usr/include/g++ -I. -I/usr/src/gnu/lib/libstdc++/../../../contrib/libg++/include -I/usr/src/gnu/lib/libstdc++/../../../contrib/libg++/libio -I/usr/src/gnu/lib/libstdc++/../../../contrib/libg++/libstdc++ -fno-implicit-templates -c /usr/src/gnu/lib/libstdc++/../../../contrib/libg++/libio/isscan.cc -o isscan.o /usr/src/gnu/lib/libstdc++/../../../contrib/libg++/libio/isscan.cc: In method `class istream & istream::scan(const char * ...)': /usr/src/gnu/lib/libstdc++/../../../contrib/libg++/libio/isscan.cc:34: bad argument 2 for function `int streambuf::vscan(const char *, char *, class ios * = 0)' (type was void *) It looks like from lines 42-44, _IO_va_list is getting set to (char *), whereas isscan.cc line 34 is passing (void *). Since this is the "final" 2.2.1-RELEASE I'm assuming it has compiled fine for others. Is there some kind of bootstrapping I have to do? Thanks! From owner-freebsd-current Tue Apr 1 10:58:28 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id KAA20431 for current-outgoing; Tue, 1 Apr 1997 10:58:28 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.50]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id KAA20426 for ; Tue, 1 Apr 1997 10:58:25 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id LAA11746; Tue, 1 Apr 1997 11:41:56 -0700 From: Terry Lambert Message-Id: <199704011841.LAA11746@phaeton.artisoft.com> Subject: Re: A new Kernel Module System To: jdp@polstra.com (John Polstra) Date: Tue, 1 Apr 1997 11:41:56 -0700 (MST) Cc: dfr@nlsystems.com, phk@critter.dk.tfs.com, current@FreeBSD.ORG In-Reply-To: <199704011627.IAA01496@austin.polstra.com> from "John Polstra" at Apr 1, 97 08:27:02 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > Exactly what I was thinking. PIC has no benefits for the kernel. > > The only thing I would need from the a.out shlib format is the > > relocations and runtime symbol table. > > I don't think you can get a runtime symbol table, unless you're building > a shared object, i.e., using PIC. You'll have to use the "normal" > symbol table. That shouldn't be a problem as far as I can see. The real need is for a vtable-based list of entry points which can be resolved against a list of symbols, and which has a known offset and sorted contents so that it's robust against interface changes. Then when it's mapped, the call is always relative to the mapping address, and no symbol resolution is needed. This presumes that the interface is pure virtual ...ie: the data is local to the library, and the program data is not directly referenced by the library (used to be a problem with termcap). The library vtables need specific entry points for "process attach", "process detach", "thread attach", and "thread detach" that are globally invariant, to allow for construction in the processes data address space instead of the libraries, and to allow for per process or per thread static data replication (probably copy on write, otherwise). 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 Apr 1 11:00:31 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id LAA20665 for current-outgoing; Tue, 1 Apr 1997 11:00:31 -0800 (PST) Received: from austin.polstra.com (austin.polstra.com [206.213.73.10]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id LAA20659 for ; Tue, 1 Apr 1997 11:00:28 -0800 (PST) Received: from austin.polstra.com (jdp@localhost) by austin.polstra.com (8.8.5/8.8.5) with ESMTP id KAA01029; Tue, 1 Apr 1997 10:59:08 -0800 (PST) Message-Id: <199704011859.KAA01029@austin.polstra.com> To: Terry Lambert cc: current@freebsd.org Subject: Re: A new Kernel Module System In-reply-to: Your message of "Tue, 01 Apr 1997 11:35:50 MST." <199704011835.LAA11731@phaeton.artisoft.com> References: <199704011835.LAA11731@phaeton.artisoft.com> Date: Tue, 01 Apr 1997 10:59:07 -0800 From: John Polstra Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > For instance, in another thread of this discussion, the SVR4 EABI > mapping of ld.so and libc, which should be done by our execution > class loader for ABI compatability anyway. It is done that way in FreeBSD for ELF files -- just not for a.out. > One big issue, IMO, is that the symbol munging can be made to "go > away", so long as you sort the vtable contents, and call by vtable > offset. This assumes a vtable implementation very much like that > used by Microsoft, actually You mean the one that they got a patent on? ;-) -- John Polstra jdp@polstra.com John D. Polstra & Co., Inc. Seattle, Washington USA "Self-knowledge is always bad news." -- John Barth From owner-freebsd-current Tue Apr 1 11:10:51 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id LAA21356 for current-outgoing; Tue, 1 Apr 1997 11:10:51 -0800 (PST) Received: from dyslexic.phoenix.net (dyslexic.phoenix.net [199.3.233.7]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id LAA21341 for ; Tue, 1 Apr 1997 11:10:38 -0800 (PST) Received: (from gemohler@localhost) by dyslexic.phoenix.net (8.8.5/8.7.3) id NAA11158; Tue, 1 Apr 1997 13:09:00 -0600 (CST) Date: Tue, 1 Apr 1997 13:09:00 -0600 (CST) From: Geoff Mohler X-Sender: gemohler@dyslexic.phoenix.net To: "John S. Dyson" cc: current@freebsd.org Subject: Re: Bounce Buffers In-Reply-To: <199704011752.MAA02576@dyson.iquest.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Tue, 1 Apr 1997, John S. Dyson wrote: > > I was getting this on a stock 2.2.1 installation: > > > > Panic: Bounce Buffers Out Of Range > > =-=-=-=-=- > > > > I got this when I took the GENERIC *or any* Kernel definition file, and > > added the line: > > options "MAXMEM=262144" > > > > Then it would report the above error on bootup, just after reporting > > kernel bus options. > > > > Now, the problem only went away after removing a megabyte of ram. When I > > changed it to: > > options "MAXMEM=261120" > > > > ..it works fine. > > > You can also remove the bounce-buffers define. Those aren't usually needed > with new technology hardware. Yes, even with and without the: options BOUNCE_BUFFERS ...it still did the same thing. Note: Worked with Rod Grimes on this issue. > The problem is that the kernel takes so much space, that there isn't room > <16MB for bounce buffers. Unless we get lots of users with > 128M using > ISA SCSI adaptors, I don't think that it is worth fixing the memory > allocation code, until we create physical memory type attributes. Interesting note..but this still happens with and without the bounce_buffers option. =-=-=-=-=- ROMANI ITE DOMUM Geoff Mohler Operations Engineer Charter Communications/Phoenix Data Net From owner-freebsd-current Tue Apr 1 11:48:42 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id LAA24508 for current-outgoing; Tue, 1 Apr 1997 11:48:42 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.50]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id LAA24503 for ; Tue, 1 Apr 1997 11:48:40 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id MAA11846; Tue, 1 Apr 1997 12:32:14 -0700 From: Terry Lambert Message-Id: <199704011932.MAA11846@phaeton.artisoft.com> Subject: Re: A new Kernel Module System To: jdp@polstra.com (John Polstra) Date: Tue, 1 Apr 1997 12:32:14 -0700 (MST) Cc: terry@lambert.org, current@freebsd.org In-Reply-To: <199704011859.KAA01029@austin.polstra.com> from "John Polstra" at Apr 1, 97 10:59:07 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > One big issue, IMO, is that the symbol munging can be made to "go > > away", so long as you sort the vtable contents, and call by vtable > > offset. This assumes a vtable implementation very much like that > > used by Microsoft, actually > > You mean the one that they got a patent on? ;-) They don't have a patent on this...if anyone does, it's Intel, since they use the same thing for INT handling. 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 Tue Apr 1 11:52:22 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id LAA24869 for current-outgoing; Tue, 1 Apr 1997 11:52:22 -0800 (PST) Received: from enst.enst.fr (uaNx6xk4g5ziWN+RpsmVNgoi0GbIA9Jt@enst.enst.fr [137.194.2.16]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id LAA24861 for ; Tue, 1 Apr 1997 11:52:17 -0800 (PST) Received: from email.enst.fr (email.enst.fr [137.194.168.17]) by enst.enst.fr (8.8.4/8.8.4) with ESMTP id VAA13935 for ; Tue, 1 Apr 1997 21:52:12 +0200 (MET DST) Received: from nikopol.enst.fr (nikopol.enst.fr [137.194.168.105]) by email.enst.fr (8.8.4/8.8.4) with ESMTP id VAA01822; Tue, 1 Apr 1997 21:52:05 +0200 (MET DST) Received: (from fenyo@localhost) by nikopol.enst.fr (8.8.4/8.8.4) id VAA24028; Tue, 1 Apr 1997 21:52:04 +0200 (MET DST) To: freebsd-current@freebsd.org Subject: Bugs in libc_r X-WWW: http://home.eowyn.fr.eu.org/~fenyo/documents/axel.html X-PGP-Key: finger alex@eowyn.fr.eu.org X-NIC-Handle: AF713 X-Whois: whois -h whois.internic.net fenyo X-Pager: 06-04-30-75-94 (for emergency only) Organization: Ecole Nationale Superieure des Telecommunications de Paris From: fenyo@email.enst.fr (Alex Fenyo (eowyn)) Date: 01 Apr 1997 21:52:03 +0200 Message-ID: Lines: 23 X-Mailer: Red Gnus v0.50/XEmacs 19.14 Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hello, The same bug is repeated 4 times in libc_r. The problem is that the operator '&' has a lower precedence than '==' in C, and the author of the code forgot it at 4 places in the source : in /usr/src/lib/libc_r/uthread/uthread_read.c : ------------------------------------------------------------ if (_thread_fd_table[fd]->flags & O_NONBLOCK == 0 && (errno == EWOULDBLOCK || errno == EAGAIN)) { ------------------------------------------------------------ should be replaced by : ------------------------------------------------------------ if ((_thread_fd_table[fd]->flags & O_NONBLOCK) == 0 && (errno == EWOULDBLOCK || errno == EAGAIN)) { ------------------------------------------------------------ The same replacement should be done in : uthread_readv.c, uthread_write.c, uthread_writev.c Could someone apply the modifications ? Alexandre Fenyo From owner-freebsd-current Tue Apr 1 12:54:52 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id MAA29517 for current-outgoing; Tue, 1 Apr 1997 12:54:52 -0800 (PST) Received: from awfulhak.demon.co.uk (awfulhak.demon.co.uk [158.152.17.1]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id MAA29493; Tue, 1 Apr 1997 12:54:44 -0800 (PST) Received: from awfulhak.demon.co.uk (localhost.lan.awfulhak.org [127.0.0.1]) by awfulhak.demon.co.uk (8.8.5/8.8.5) with ESMTP id UAA00720; Tue, 1 Apr 1997 20:49:07 +0100 (BST) Message-Id: <199704011949.UAA00720@awfulhak.demon.co.uk> X-Mailer: exmh version 1.6.9 8/22/96 To: dennis cc: Developer , freebsd-current@FreeBSD.ORG, freebsd-hackers@FreeBSD.ORG Subject: Re: PPP Desperate for help! In-reply-to: Your message of "Tue, 01 Apr 1997 09:50:12 CDT." <3.0.32.19970401095010.006a2504@etinc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 01 Apr 1997 20:49:07 +0100 From: Brian Somers Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > At 01:42 PM 4/1/97 +0100, Developer wrote: > > > > > >On Tue, 1 Apr 1997, Andrzej Bialecki wrote: > > > >> On Tue, 1 Apr 1997, Developer wrote: > >> > >> > > >> > We are really stuck trying to get the PPP user program (ppp) to > connect to > >> > our Perle 833 dial in server. We can connect using Windows NT fine but on > >> > BSD ppp logs in and then data will travel in both directions (As I can > see > >> > the modem lights flash at both ends for both send/recieve) but no data > >> > seems to actually get through as pings do not work. The packets from the > >> > server to the user, but seem to be lost on the way back. > >> > >> Let me take a guess: maybe it's a known problem with tcp_extensions set to > >> YES in /etc/sysconfig? Some broken TCP stacks don't like it, so the > >> solution would be to turn it off. > >> > >> Andy > > > >We've tried this - no difference. Any more ideas please? > > Why not post a trace of the ppp negotiations? Perhaps there is a parameter > conflict....are you getting to state IPCP_OPENED? If not, you cant pass > traffic. > > Dennis I suspect you're way ahead of the problem. Has the original poster tried "set openmode active" ? Without this, a client ppp will wait for the server to initiate LCP. I think it may be frugal to make this the default for both client *and* server. A lot of server implementations wait for the client to start. Any comments ? -- Brian , Don't _EVER_ lose your sense of humour.... From owner-freebsd-current Tue Apr 1 13:39:06 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id NAA03056 for current-outgoing; Tue, 1 Apr 1997 13:39:06 -0800 (PST) Received: from rosie.scsn.net (scsn.net [206.25.246.12]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id NAA03049 for ; Tue, 1 Apr 1997 13:39:02 -0800 (PST) Received: from cola112.scsn.net ([206.25.247.112]) by rosie.scsn.net (Post.Office MTA v3.0 release (Release 114) ID# 0-32322U5000L100S10000) with ESMTP id AAA176; Tue, 1 Apr 1997 16:33:14 -0500 Received: (from root@localhost) by cola112.scsn.net (8.8.5/8.6.12) id QAA00446; Tue, 1 Apr 1997 16:37:22 -0500 (EST) From: "Donald J. Maddox" Message-Id: <199704012137.QAA00446@cola112.scsn.net> Subject: Re: Current is crashing X In-Reply-To: <19970401011847.31693@peeper.jackson.org> from Tom Jackson at "Apr 1, 97 01:18:47 am" To: toj@gorilla.net Date: Tue, 1 Apr 1997 16:37:22 -0500 (EST) Cc: freebsd-current@freebsd.org Reply-To: dmaddox@scsn.net 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-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Tom Jackson > Running current on a p5/100. Kernel built from ctm#2824 seemed to have no > problems. Got ctm#2827 today and since there had been some kernel source > changes, rebuilt the kernel after a successful make on the system. When > I went to start X the box crashes and does an auto reboot. > > CTM having its latency, I looked for anything similar, didn't see any, and > wonder if this is some fluke. Any others see this? It's no fluke... I did my build last night from sources cvsupped last night, and I'm seeing exactly the same thing. As soon as the server starts a client, the machine locks up tight as a drum. If anybody has already fixed this, I would sure appreciate it if you could mail me a patch... -- Donald J. Maddox (dmaddox@scsn.net) From owner-freebsd-current Tue Apr 1 14:22:18 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id OAA07106 for current-outgoing; Tue, 1 Apr 1997 14:22:18 -0800 (PST) Received: from dyslexic.phoenix.net (root@dyslexic.phoenix.net [199.3.233.7]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id OAA07092 for ; Tue, 1 Apr 1997 14:22:08 -0800 (PST) Received: (from gemohler@localhost) by dyslexic.phoenix.net (8.8.5/8.7.3) id QAA12206; Tue, 1 Apr 1997 16:18:47 -0600 (CST) Date: Tue, 1 Apr 1997 16:18:47 -0600 (CST) From: Geoff Mohler X-Sender: gemohler@dyslexic.phoenix.net To: freebsd-current@freebsd.org Subject: Downtime Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk FTP2.FREEBSD.ORG will be down from midnight to approx 3am for an OS upgrade, and a CCD installation. Just an informational notice to anyone using ftp2 for CVS support. =-=-=-=-=- ROMANI ITE DOMUM Geoff Mohler Operations Engineer Charter Communications/Phoenix Data Net From owner-freebsd-current Tue Apr 1 15:29:42 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id PAA12832 for current-outgoing; Tue, 1 Apr 1997 15:29:42 -0800 (PST) Received: from bacardi.torrentnet.com (plexuscom.com [207.87.46.99]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id PAA12827 for ; Tue, 1 Apr 1997 15:29:36 -0800 (PST) Received: (from jds@localhost) by bacardi.torrentnet.com (8.7.6/8.7.3) id SAA25348; Tue, 1 Apr 1997 18:28:38 -0500 (EST) Date: Tue, 1 Apr 1997 18:28:38 -0500 (EST) From: James da Silva Message-Id: <199704012328.SAA25348@bacardi.torrentnet.com> To: dfr@nlsystems.com Subject: Re: A new Kernel Module System In-Reply-To: Organization: Torrent Networking Technologies Corp. Cc: freebsd-current@freebsd.org Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Doug writes: >On Tue, 1 Apr 1997, John Polstra wrote: > >> > I am pretty sure that if I link a bunch of objects together using >> > -Bshareable, then ld(1) will generate a symbol table for me. >> >> Yes, you're right. I stand corrected. You get zillions of warnings >> about RRS text relocations, but the output file does seem to be >> legitimate. >> >> I still have doubts that this buys you anything, though. Is there any >> advantage over just using the static symbol table and relocations? >> Remember, you'll have to link against kernel symbols too, and it won't >> have a run-time symbol table. > >I plan to link the kernel as if it was a dynamic executable. This >involves hacking ld(1) so that it still generates _DYNAMIC information >even if no shared libraries are seen in the link. Doug, are you sure you can't do what you want with plain .o files, without hacking ld and mucking with -Bshareable? I agree with John. The kernel symbol table is already loaded, or can arrange to be loaded anyway. After that, you suck in the module .o files whole, traversing their relocs and just applying them. The symbol tables are pulled into a linked list of symbol tables for searching on subsequent linking. This is very simple. I can dig up the code I have that does this (load .o and reloc it against previously loaded symbols) if you want, it's less than 8k of code. What do you need that the simple method is lacking? Jaime ........................................................................... : James da Silva : Stand on my shoulders, : : Torrent Networking Technologies Corp. : not on my toes. : From owner-freebsd-current Tue Apr 1 15:58:08 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id PAA15212 for current-outgoing; Tue, 1 Apr 1997 15:58:08 -0800 (PST) Received: from proxy1.ba.best.com (root@proxy1.ba.best.com [206.184.139.12]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id PAA15194 for ; Tue, 1 Apr 1997 15:58:05 -0800 (PST) Received: from bsampley.vip.best.com (bsampley.vip.best.com [206.184.160.196]) by proxy1.ba.best.com (8.8.5/8.8.3) with SMTP id PAA27176; Tue, 1 Apr 1997 15:56:03 -0800 (PST) Date: Tue, 1 Apr 1997 15:55:08 -0800 (PST) From: Burton Sampley To: dmaddox@scsn.net cc: toj@gorilla.net, freebsd-current@freebsd.org Subject: Re: Current is crashing X In-Reply-To: <199704012137.QAA00446@cola112.scsn.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I cvsup'ed on sat morning. Make world completed and I rebuilt my kernel. I haven't had any problems with X. Maybe it's your display server, are you both using the same server? I'm running AcceleratedX from XI Graphics. On Tue, 1 Apr 1997, Donald J. Maddox wrote: > Tom Jackson > > Running current on a p5/100. Kernel built from ctm#2824 seemed to have no > > problems. Got ctm#2827 today and since there had been some kernel source > > changes, rebuilt the kernel after a successful make on the system. When > > I went to start X the box crashes and does an auto reboot. > > > > CTM having its latency, I looked for anything similar, didn't see any, and > > wonder if this is some fluke. Any others see this? > > It's no fluke... I did my build last night from sources > cvsupped last night, and I'm seeing exactly the same thing. As > soon as the server starts a client, the machine locks up tight > as a drum. > > If anybody has already fixed this, I would sure appreciate > it if you could mail me a patch... > > -- > > > Donald J. Maddox > (dmaddox@scsn.net) > > --- Brought to you by a 100% Micro$oft free system. You too can disinfect your system at http://www.freebsd.org E-Mail: burton@bsampley.vip.best.com Alternate E-Mail: bsampley@haywire.csuhayward.edu Home Page: http://www.best.com/~bsampley (permanently under construction) From owner-freebsd-current Tue Apr 1 16:12:04 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id QAA16429 for current-outgoing; Tue, 1 Apr 1997 16:12:04 -0800 (PST) Received: from etinc.com (et-gw-fr1.etinc.com [204.141.244.98]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id QAA16335; Tue, 1 Apr 1997 16:10:38 -0800 (PST) Received: from dialup-usr11.etinc.com (dialup-usr11.etinc.com [204.141.95.132]) by etinc.com (8.8.3/8.6.9) with SMTP id TAA18745; Tue, 1 Apr 1997 19:14:36 -0500 (EST) Message-Id: <3.0.32.19970401190724.00b1d924@etinc.com> X-Sender: dennis@etinc.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Tue, 01 Apr 1997 19:07:32 -0500 To: Brian Somers From: dennis Subject: Re: PPP Desperate for help! Cc: Developer , freebsd-current@freebsd.org, freebsd-hackers@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk At 08:49 PM 4/1/97 +0100, Brian Somers wrote: >> At 01:42 PM 4/1/97 +0100, Developer wrote: >> > >> > >> >On Tue, 1 Apr 1997, Andrzej Bialecki wrote: >> > >> >> On Tue, 1 Apr 1997, Developer wrote: >> >> >> >> > >> >> > We are really stuck trying to get the PPP user program (ppp) to >> connect to >> >> > our Perle 833 dial in server. We can connect using Windows NT fine but on >> >> > BSD ppp logs in and then data will travel in both directions (As I can >> see >> >> > the modem lights flash at both ends for both send/recieve) but no data >> >> > seems to actually get through as pings do not work. The packets from the >> >> > server to the user, but seem to be lost on the way back. >> >> >> >> Let me take a guess: maybe it's a known problem with tcp_extensions set to >> >> YES in /etc/sysconfig? Some broken TCP stacks don't like it, so the >> >> solution would be to turn it off. >> >> >> >> Andy >> > >> >We've tried this - no difference. Any more ideas please? >> >> Why not post a trace of the ppp negotiations? Perhaps there is a parameter >> conflict....are you getting to state IPCP_OPENED? If not, you cant pass >> traffic. >> >> Dennis > >I suspect you're way ahead of the problem. Has the original poster >tried "set openmode active" ? Without this, a client ppp will wait >for the server to initiate LCP. > >I think it may be frugal to make this the default for both client >*and* server. A lot of server implementations wait for the client >to start. Any comments ? It shouldnt make a difference, if implemented properly. There is no master-slave relationship in ppp...the ends are peers. Upon starting the interface it should send "n" configs, and then stop if no reply is received. When a config is received it starts again. The state machine allows for this nicely. One problem is when the electrical interface (UP) is not implemented (ie, receipt of DSR) properly. You should not be able to get into both ends being dormant if its done properly. Dennis From owner-freebsd-current Tue Apr 1 16:27:45 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id QAA18257 for current-outgoing; Tue, 1 Apr 1997 16:27:45 -0800 (PST) Received: from rosie.scsn.net (scsn.net [206.25.246.12]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id QAA18252 for ; Tue, 1 Apr 1997 16:27:33 -0800 (PST) Received: from rhiannon.scsn.net ([206.25.247.49]) by rosie.scsn.net (Post.Office MTA v3.0 release (Release 114) ID# 0-32322U5000L100S10000) with SMTP id AAA145; Tue, 1 Apr 1997 19:21:53 -0500 Message-ID: <3341A791.7540@scsn.net> Date: Tue, 01 Apr 1997 19:25:53 -0500 From: dmaddox@scsn.net (Donald J. Maddox) Reply-To: dmaddox@scsn.net X-Mailer: Mozilla 3.01Gold (Win95; I) MIME-Version: 1.0 To: Burton Sampley CC: freebsd-current@FreeBSD.org Subject: Re: Current is crashing X References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk Burton Sampley wrote: > > I cvsup'ed on sat morning. Make world completed and I rebuilt my kernel. > I haven't had any problems with X. Maybe it's your display server, are > you both using the same server? I'm running AcceleratedX from XI > Graphics. So did I... On Saturday, it worked. After CVSup and `make world` last night it doesn't. From owner-freebsd-current Tue Apr 1 18:29:02 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id SAA27598 for current-outgoing; Tue, 1 Apr 1997 18:29:02 -0800 (PST) Received: from gns.com.br ([200.239.56.235]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id SAA27585 for ; Tue, 1 Apr 1997 18:28:58 -0800 (PST) Received: (from dcs@localhost) by gns.com.br (8.8.5/8.7.3) id XAA00426 for current@freefall.freebsd.org; Tue, 1 Apr 1997 23:26:54 -0300 (EST) From: "Daniel C. Sobral" Message-Id: <199704020226.XAA00426@gns.com.br> Subject: Re: current-digest V3 #50 In-Reply-To: <199704011853.KAA20017@freefall.freebsd.org> from "owner-current-digest@freefall.freebsd.org" at "Apr 1, 97 10:53:00 am" To: current@freefall.freebsd.org Date: Tue, 1 Apr 1997 23:26:54 -0300 (EST) Disclaimer: Klaatu Barada Nikto! 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-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > From: Andrzej Bialecki > Date: Tue, 1 Apr 1997 12:15:57 +0200 (MET DST) > Subject: Re: xinstall problem > > > I have been trying to make world about a week now, always to fail at > > xinstall (MAP_FAILED undeclared at lines 517 and 584, functions > > compare and copy). Is anyone else experiencing this problem? > > Try to install /usr/include files *first*, before you make the world. At > least this helped in my case... BTW: how old the sources are? I tried a number of times from about march 25 up to march 31, the day I sent my message. I always cvsupped a new source before trying the make world. As for the work-around, it's actually very easy. The problem I was calling attention to is that _make world_ couldn't do it. I was under the impression that make world _is_ supposed to deal with this kind of problem... -- Daniel C. Sobral (8-DCS) dcs@gns.com.br dcs@linf.unb.br If Patrick Henry thought that taxation without representation was bad, he should see how bad it is with representation. From owner-freebsd-current Tue Apr 1 19:47:30 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id TAA02600 for current-outgoing; Tue, 1 Apr 1997 19:47:30 -0800 (PST) Received: from palrel1.hp.com (palrel1.hp.com [15.253.72.10]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id TAA02595 for ; Tue, 1 Apr 1997 19:47:28 -0800 (PST) Received: from fakir.india.hp.com (fakir.india.hp.com [15.10.40.3]) by palrel1.hp.com with ESMTP (8.7.5/8.7.3) id TAA24233 for ; Tue, 1 Apr 1997 19:47:22 -0800 (PST) Received: from localhost by fakir.india.hp.com with SMTP (1.37.109.20/15.5+ECS 3.3) id AA124144681; Wed, 2 Apr 1997 09:18:01 +0500 Message-Id: <199704020418.AA124144681@fakir.india.hp.com> To: freebsd-current@freebsd.org Subject: Re: Kernel Module System Date: Wed, 02 Apr 1997 09:18:01 +0500 From: "A JOSEPH KOSHY" Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk A suggestion for Doug: how about adding a version number in the LKM which can be compared against that expected by the kernel. The idea is to warn and/or disallow loading of older LKMs into the kernel. The version number would be changed whenever say, a binary incompatibility is introduced. Do we have an ``approved set'' of kernel routines (a Driver Development API) that are callable by drivers? Koshy My Personal Opinions Only From owner-freebsd-current Tue Apr 1 20:20:50 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id UAA04053 for current-outgoing; Tue, 1 Apr 1997 20:20:50 -0800 (PST) Received: from sovcom.kiae.su (sovcom.kiae.su [193.125.152.1]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id UAA04048; Tue, 1 Apr 1997 20:20:44 -0800 (PST) Received: by sovcom.kiae.su id AA15927 (5.65.kiae-1 ); Wed, 2 Apr 1997 07:11:04 +0300 Received: by sovcom.KIAE.su (UUMAIL/2.0); Wed, 2 Apr 97 07:11:03 +0300 Received: (from ache@localhost) by nagual.ru (8.8.5/8.8.5) id IAA00290; Wed, 2 Apr 1997 08:10:32 +0400 (MSD) Date: Wed, 2 Apr 1997 08:10:30 +0400 (MSD) From: =?KOI8-R?B?4c7E0sXKIP7F0s7P1w==?= To: dyson@freebsd.org, Bruce Evans , FreeBSD-current Subject: ufs lock panic in -current Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I just got following panic: lockmgr: locking against myself stack looks like: lockmgr ufs_lock vn_lock vputrele vrele vnode_pager_dealloc vm_pager_deallocate vm_pager_terminate vm_object_deallocate vputrele vrele execve Please, fix. -- Andrey A. Chernov http://www.nagual.ru/~ache/ From owner-freebsd-current Tue Apr 1 20:23:15 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id UAA04215 for current-outgoing; Tue, 1 Apr 1997 20:23:15 -0800 (PST) Received: from pluto.plutotech.com (root@pluto.plutotech.com [206.168.67.1]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id UAA04205 for ; Tue, 1 Apr 1997 20:23:12 -0800 (PST) Received: from narnia.plutotech.com (narnia.plutotech.com [206.168.67.130]) by pluto.plutotech.com (8.8.5/8.8.3) with ESMTP id VAA18373; Tue, 1 Apr 1997 21:20:34 -0700 (MST) Message-Id: <199704020420.VAA18373@pluto.plutotech.com> X-Mailer: exmh version 2.0beta 12/23/96 To: "A JOSEPH KOSHY" cc: freebsd-current@freebsd.org Subject: Re: Kernel Module System In-reply-to: Your message of "Wed, 02 Apr 1997 09:18:01 +0500." <199704020418.AA124144681@fakir.india.hp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 01 Apr 1997 21:18:47 -0700 From: "Justin T. Gibbs" Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > >A suggestion for Doug: how about adding a version number in the LKM which >can be compared against that expected by the kernel. The idea is to warn >and/or disallow loading of older LKMs into the kernel. > >The version number would be changed whenever say, a binary incompatibility >is introduced. You don't want a single version number really. You want one for each subsystem that an LKM may depend upon. For example, the SCSI system might itself be an LKM and a controller driver would need to ensure that it is compatible both with the version of the "LKM loading subsytem" and that of the SCSI subsystem. The SCSI subsystem would in turn check its dependencies (timeout mechanism, software interrupt registration, whatever). >Do we have an ``approved set'' of kernel routines (a Driver Development API) >that are callable by drivers? Don't we all wish... >Koshy > My Personal Opinions Only -- Justin T. Gibbs =========================================== FreeBSD: Turning PCs into workstations =========================================== From owner-freebsd-current Tue Apr 1 20:57:22 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id UAA05578 for current-outgoing; Tue, 1 Apr 1997 20:57:22 -0800 (PST) Received: from palrel1.hp.com (palrel1.hp.com [15.253.72.10]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id UAA05573 for ; Tue, 1 Apr 1997 20:57:20 -0800 (PST) Received: from fakir.india.hp.com (fakir.india.hp.com [15.10.40.3]) by palrel1.hp.com with ESMTP (8.7.5/8.7.3) id UAA06216; Tue, 1 Apr 1997 20:57:05 -0800 (PST) Received: from localhost by fakir.india.hp.com with SMTP (1.37.109.20/15.5+ECS 3.3) id AA134058855; Wed, 2 Apr 1997 10:27:35 +0500 Message-Id: <199704020527.AA134058855@fakir.india.hp.com> To: "Justin T. Gibbs" Cc: freebsd-current@freebsd.org Subject: Re: Kernel Module System In-Reply-To: Your message of "Tue, 01 Apr 1997 21:18:47 MST." <199704020420.VAA18373@pluto.plutotech.com> Date: Wed, 02 Apr 1997 10:27:35 +0500 From: "A JOSEPH KOSHY" Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >>>> ""Justin T. Gibbs"" writes Hi, > You don't want a single version number really. You want one for each > subsystem that an LKM may depend upon. For example, the SCSI system might Yes, but there is a tradeoff between complexity and utility. If we basically want to prevent a 2.2 LKM being loaded into a 3.1 kernel, (or vice-versa) a simple version number would suffice. This would trap say, attempts by a user to load in a third-party LKM into his/her FreeBSD kernel. In the absence of such a mechanism; the user would know that the LKM is mismatched only when something catastrophic happens. This is really a release engineering issue, not a development one, and I think it may make it easier for third party vendors to offer binary only LKM addons for FreeBSD. Such a LKM versioning system is probably not relevant for people following -current; the traditional method of rebuilding LKMs every now and then would probably still suffice for them. I was initially looking a `kernel signature' derived from the sizes of key data structures, version numbers of sources etc. However, further thought showed that such a solution would really be overkill for the intended purpose and a single version number would probably suffice. Koshy My Personal Opinions Only. From owner-freebsd-current Wed Apr 2 00:57:26 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id AAA16357 for current-outgoing; Wed, 2 Apr 1997 00:57:26 -0800 (PST) Received: from relay.nuxi.com (nuxi.ucdavis.edu [128.120.175.23]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id AAA16352 for ; Wed, 2 Apr 1997 00:57:24 -0800 (PST) Received: from dragon.nuxi.com (dav1-12.calweb.com [207.211.82.12]) by relay.nuxi.com (8.8.5/8.6.12) with ESMTP id BAA17371 for ; Wed, 2 Apr 1997 01:01:39 GMT Received: (from obrien@localhost) by dragon.nuxi.com (8.8.5/8.7.3) id IAA00867; Wed, 2 Apr 1997 08:57:16 GMT Message-ID: <19970402005715.49303@dragon.nuxi.com> Date: Wed, 2 Apr 1997 00:57:15 -0800 From: "David O'Brien" To: freebsd-current@freebsd.org Subject: max files problem Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.68 Reply-To: obrien@NUXI.com X-Warning: Mutt Bites! X-Operating-System: FreeBSD 2.2.1-RELEASE Organization: The NUXI *BSD group X-PGP-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Keyid: 34F9F9D5 Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi all, I keep getting messages like on my RELENG_2_2 box: Apr 1 09:27:57 dragon syslogd: /var/run/utmp: Too many open files in system Apr 1 09:27:59 dragon syslogd: /var/run/utmp: Too many open files in system Apr 1 09:27:59 dragon /kernel: file: table is full And this is with "options OPEN_MAX=192" in my kernel config file. ``bash$ ulimit -a'' shows this to be the case. Does Netscape (either v2.02 or v3.01) have a file descriptor leak? I think this happens to me most often when running Netscape... but then I run Netscape most of the time.. so maybe not. I've only been seeing a lot of these since 2.2-BETA (I moved there from 2.2-961008-SNAP). Any idea how high I should bump up OPEN_MAX? This is on my personal home machine running X, many xterms and rxvt's, PPP and sendmail. (oh, of course Mutt too :-)) -- -- David (obrien@NUXI.com -or- obrien@FreeBSD.org) From owner-freebsd-current Wed Apr 2 01:18:05 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id BAA17398 for current-outgoing; Wed, 2 Apr 1997 01:18:05 -0800 (PST) Received: from fgate.flevel.co.uk (root@fgate.flevel.co.uk [194.6.101.2]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id BAA17378; Wed, 2 Apr 1997 01:17:58 -0800 (PST) Received: from localhost (dev@localhost) by fgate.flevel.co.uk (8.8.3/8.6.9) with SMTP id KAA09917; Wed, 2 Apr 1997 10:17:54 +0100 (BST) Date: Wed, 2 Apr 1997 10:17:54 +0100 (BST) From: Developer To: freebsd-current@freebsd.org, freebsd-hackers@freebsd.org Subject: PPP Problems -- The next chapter *grin* Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk After not being able to get the user ppp software to work I decided to give up and try pppd instead. After configuring correctly pppd works fine (Just use kermit to dial and then run it)?? I wonder what is different between ppp and pppd that would cause the problem? Regards, Trefor S. From owner-freebsd-current Wed Apr 2 01:37:46 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id BAA18464 for current-outgoing; Wed, 2 Apr 1997 01:37:46 -0800 (PST) Received: from mailbox.uq.edu.au (zzshocki.slip.cc.uq.edu.au [130.102.221.173]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id BAA18451 for ; Wed, 2 Apr 1997 01:37:39 -0800 (PST) Received: from bloop.craftncomp.com (localhost.craftncomp.com [127.0.0.1]) by mailbox.uq.edu.au (8.8.5/8.6.12) with ESMTP id TAA26057; Wed, 2 Apr 1997 19:30:07 +1000 (EST) Message-Id: <199704020930.TAA26057@mailbox.uq.edu.au> X-Mailer: exmh version 2.0gamma 1/27/96 To: =?KOI8-R?B?4c7E0sXKIP7F0s7P1w==?= cc: current@freebsd.org Subject: Re: ufs lock panic in -current In-reply-to: Your message of "Wed, 02 Apr 1997 08:10:30 +0400." From: shocking@mailbox.uq.edu.au Reply-To: shocking@mailbox.uq.edu.au Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 02 Apr 1997 19:30:04 +1000 Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I've filed a pr for this one - complete with traceback & the ctm src-cur update where it died. Stephen From owner-freebsd-current Wed Apr 2 01:54:32 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id BAA19504 for current-outgoing; Wed, 2 Apr 1997 01:54:32 -0800 (PST) Received: from saba.kuentos.guam.net (root@saba.kuentos.guam.net [198.81.233.14]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id BAA19495 for ; Wed, 2 Apr 1997 01:54:28 -0800 (PST) Received: by saba.kuentos.guam.net (Smail3.1.29.1 #9) id m0wCMkK-002EuNC; Wed, 2 Apr 97 19:54 GST Date: Wed, 2 Apr 1997 19:54:23 +1000 (GST) From: T-I-GG-Rrr!! To: freebsd-current@freebsd.org Subject: unsubscribe Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk unsubscribe meltedice@kuentos.guam.net =*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*= =* Bill Shaw *= =* Kuentos Communications Inc. Guam USA *= =* Guams First Internet Provider *= =* meltedice@kuentos.guam.net *= =* http://www.guam.net/home/bhshaw2 *= =* IFORMS Chat Run On BSDI *= =* telnet buri.kuentos.guam.net 3000 *= =* *= =*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*= From owner-freebsd-current Wed Apr 2 04:04:38 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id EAA25302 for current-outgoing; Wed, 2 Apr 1997 04:04:38 -0800 (PST) Received: from nlsystems.com (nlsys.demon.co.uk [158.152.125.33]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id EAA25297 for ; Wed, 2 Apr 1997 04:04:33 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by nlsystems.com (8.8.5/8.8.5) with SMTP id NAA11388; Wed, 2 Apr 1997 13:03:52 +0100 (BST) Date: Wed, 2 Apr 1997 13:03:51 +0100 (BST) From: Doug Rabson To: James da Silva cc: freebsd-current@freebsd.org Subject: Re: A new Kernel Module System In-Reply-To: <199704012328.SAA25348@bacardi.torrentnet.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Tue, 1 Apr 1997, James da Silva wrote: > >I plan to link the kernel as if it was a dynamic executable. This > >involves hacking ld(1) so that it still generates _DYNAMIC information > >even if no shared libraries are seen in the link. > > Doug, are you sure you can't do what you want with plain .o files, without > hacking ld and mucking with -Bshareable? > > I agree with John. The kernel symbol table is already loaded, or can > arrange to be loaded anyway. After that, you suck in the module .o files > whole, traversing their relocs and just applying them. The symbol tables > are pulled into a linked list of symbol tables for searching on subsequent > linking. > > This is very simple. I can dig up the code I have that does this (load .o > and reloc it against previously loaded symbols) if you want, it's less than > 8k of code. It actually seemed easier to use the symbol tables from -Bshareable. No hacking is required to ld other than a simple change to make sure it generates a symbol table and _DYNAMIC for /kernel. The rrs information has only the exported symbols from the object and includes extra useful information such as a symbol hashtable for lookups and a list of dependancies. > > What do you need that the simple method is lacking? Not much. The symbol hashtable and dependancy list should be useful though. -- Doug Rabson Mail: dfr@nlsystems.com Nonlinear Systems Ltd. Phone: +44 181 951 1891 From owner-freebsd-current Wed Apr 2 04:13:51 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id EAA25687 for current-outgoing; Wed, 2 Apr 1997 04:13:51 -0800 (PST) Received: from shadows.aeon.net (bsdcur@shadows.aeon.net [194.100.41.1]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id EAA25679 for ; Wed, 2 Apr 1997 04:13:46 -0800 (PST) Received: (from bsdcur@localhost) by shadows.aeon.net (8.8.5/8.8.3) id PAA03406; Wed, 2 Apr 1997 15:13:54 +0300 (EET DST) From: mika ruohotie Message-Id: <199704021213.PAA03406@shadows.aeon.net> Subject: Re: Current is crashing X In-Reply-To: <3341A791.7540@scsn.net> from "Donald J. Maddox" at "Apr 1, 97 07:25:53 pm" To: dmaddox@scsn.net Date: Wed, 2 Apr 1997 15:13:54 +0300 (EET DST) Cc: burton@bsampley.vip.best.com, 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-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > Burton Sampley wrote: > > I cvsup'ed on sat morning. Make world completed and I rebuilt my kernel. > > I haven't had any problems with X. Maybe it's your display server, are > So did I... On Saturday, it worked. After CVSup and `make world` > last > night it doesn't. this is actual problem, came around sometime after sunday, i am not sure exactly when, last kernel i have that works is from march 29th 15:00 EET (GMT+2) none of the kernels i've made after that, several of them, work with XFree. there's no crashdumps available. mickey From owner-freebsd-current Wed Apr 2 04:18:42 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id EAA25850 for current-outgoing; Wed, 2 Apr 1997 04:18:42 -0800 (PST) Received: from Pkrw.tcn.net (Pkrw.tcn.net [199.166.4.58]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id EAA25843 for ; Wed, 2 Apr 1997 04:18:39 -0800 (PST) Received: from localhost (krw@localhost) by Pkrw.tcn.net (8.8.5/8.8.5) with SMTP id WAA03895 for ; Tue, 1 Apr 1997 22:06:39 -0500 (EST) X-Authentication-Warning: Pkrw.tcn.net: krw owned process doing -bs Date: Tue, 1 Apr 1997 22:05:24 -0500 (EST) From: "Kenneth R. Westerback" To: freebsd-current@freebsd.org Subject: 2.2.1-STABLE src-2.2.0224 make world fails Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk After applying src-2.2.0224 I tried a make world and it failed: ===> share/man/man8 ===> share/me ===> share/misc "Makefile", line 6: Unassociated shell command "iso3166 man.template mdoc.template na.phone operator scsi_modes zipcodes" Fatal errors encountered -- cannot continue *** Error code 1 Stop. etc. I have to say 2.2.1 seems as, jhk, has said, cursed. It seems that not only is the CD-ROM resisting release, but src-xxxx updates seem to break make world quite regularly. ---- Ken From owner-freebsd-current Wed Apr 2 04:19:00 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id EAA25886 for current-outgoing; Wed, 2 Apr 1997 04:19:00 -0800 (PST) Received: from Pkrw.tcn.net (Pkrw.tcn.net [199.166.4.58]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id EAA25877 for ; Wed, 2 Apr 1997 04:18:57 -0800 (PST) Received: from localhost (krw@localhost) by Pkrw.tcn.net (8.8.5/8.8.5) with SMTP id VAA00548; Tue, 25 Mar 1997 21:26:45 -0500 (EST) Date: Tue, 25 Mar 1997 21:26:22 -0500 (EST) From: "Kenneth R. Westerback" To: dkelly@hiwaay.net cc: cracauer@wavehh.hanse.de, jkh@time.cdrom.COM, freebsd-current@freebsd.org Subject: Re: CVS repository pushed off the FreeBSD CD distribution... In-Reply-To: <199703250156.TAA20506@nexgen.hiwaay.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Darned if I didn't suggest this last week and was told that this very thing had been implemented the day after I downloaded the CTM base delta! Check out the src-2.2-CTM-README file in the CTM directory. The new one. It explains how to start with CTM from the src distribution. I only hope they keep this up! ---- Ken On Mon, 24 Mar 1997 dkelly@hiwaay.net wrote: > > > I always felt that a base CTM delta would be very valuable for a CD, > > too. After all, CTM is for use poor people who can't ftp a 70 MB > > file. > > Agreed. But wouldn't it be even simpler if the -RELEASE was sync'ed to a > CTM delta (might be already, would be nice if there was a release marker in > the CTM filename), and then all we'd need are .ctm_status files in the > appropriate places. Even cheaper than a 70M base delta. > > -- > David Kelly N4HHE, dkelly@hiwaay.net > ===================================================================== > The human mind ordinarily operates at only ten percent of its > capacity -- the rest is overhead for the operating system. > > > > From owner-freebsd-current Wed Apr 2 07:11:52 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id HAA03892 for current-outgoing; Wed, 2 Apr 1997 07:11:52 -0800 (PST) Received: from fyeung5 (netific.vip.best.com [205.149.182.145]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id HAA03885; Wed, 2 Apr 1997 07:11:48 -0800 (PST) Received: from fyeung8.netific.com (fyeung8 [204.238.125.8]) by fyeung5 (8.6.11/8.6.9) with SMTP id HAA03765; Wed, 2 Apr 1997 07:11:16 -0800 Received: by fyeung8.netific.com (5.x/SMI-SVR4) id AA16536; Wed, 2 Apr 1997 07:19:10 -0800 Date: Wed, 2 Apr 1997 07:19:10 -0800 From: fyeung@fyeung8.netific.com (Francis Yeung) Message-Id: <9704021519.AA16536@fyeung8.netific.com> To: dennis@etinc.com, brian@awfulhak.org Subject: Re: PPP Desperate for help! Cc: dev@fgate.flevel.co.uk, freebsd-current@freebsd.org, freebsd-hackers@freebsd.org X-Sun-Charset: US-ASCII Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Greetings, Will you have the magic number problem if you connect 2 FreeBSD machines directly via PPP ? (both machines are in LCP active) Francis > From brian@awfulhak.org Tue Apr 1 14:32 PST 1997 > To: dennis > Cc: Developer , freebsd-current@freebsd.org, > freebsd-hackers@freebsd.org > Subject: Re: PPP Desperate for help! > Mime-Version: 1.0 > Date: Tue, 01 Apr 1997 20:49:07 +0100 > From: Brian Somers > X-Loop: FreeBSD.org > X-Fetchmail-Warning: no recipient addresses matched declared local names > > > At 01:42 PM 4/1/97 +0100, Developer wrote: > > > > > > > > >On Tue, 1 Apr 1997, Andrzej Bialecki wrote: > > > > > >> On Tue, 1 Apr 1997, Developer wrote: > > >> > > >> > > > >> > We are really stuck trying to get the PPP user program (ppp) to > > connect to > > >> > our Perle 833 dial in server. We can connect using Windows NT fine but on > > >> > BSD ppp logs in and then data will travel in both directions (As I can > > see > > >> > the modem lights flash at both ends for both send/recieve) but no data > > >> > seems to actually get through as pings do not work. The packets from the > > >> > server to the user, but seem to be lost on the way back. > > >> > > >> Let me take a guess: maybe it's a known problem with tcp_extensions set to > > >> YES in /etc/sysconfig? Some broken TCP stacks don't like it, so the > > >> solution would be to turn it off. > > >> > > >> Andy > > > > > >We've tried this - no difference. Any more ideas please? > > > > Why not post a trace of the ppp negotiations? Perhaps there is a parameter > > conflict....are you getting to state IPCP_OPENED? If not, you cant pass > > traffic. > > > > Dennis > > I suspect you're way ahead of the problem. Has the original poster > tried "set openmode active" ? Without this, a client ppp will wait > for the server to initiate LCP. > > I think it may be frugal to make this the default for both client > *and* server. A lot of server implementations wait for the client > to start. Any comments ? > -- > Brian , > > Don't _EVER_ lose your sense of humour.... > > From owner-freebsd-current Wed Apr 2 08:01:54 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id IAA06611 for current-outgoing; Wed, 2 Apr 1997 08:01:54 -0800 (PST) Received: from out2.ibm.net (out2.ibm.net [165.87.201.252]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id IAA06606; Wed, 2 Apr 1997 08:01:49 -0800 (PST) Received: (from uucp@localhost) by out2.ibm.net (8.6.9/8.6.9) id QAA710624; Wed, 2 Apr 1997 16:01:39 GMT Message-Id: <199704021601.QAA710624@out2.ibm.net> Received: from slip166-72-229-226.va.us.ibm.net(166.72.229.226) by out2.ibm.net via smap (V1.3mjr) id smanecDFW; Wed Apr 2 15:58:48 1997 Reply-To: From: "Steve Sims" To: "Hackers" , Subject: -current 'make world' chokes Date: Wed, 2 Apr 1997 10:58:25 -0500 X-MSMail-Priority: Normal X-Priority: 3 X-Mailer: Microsoft Internet Mail 4.70.1161 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk How come -current has, for the last couple of days (at least, that I've *noticed*) chokes while making the world. I do 'cd /usr/src ; make update world' to pull current and build it and get: [blah, blah, blah] cd /usr/src/lib/csu/i386 && make beforeinstall install -C -o bin -g bin -m 444 /usr/src/lib/csu/i386/dlfcn.h /usr/include install -c -o bin -g bin -m 444 crt0.o c++rt0.o gcrt0.o scrt0.o sgcrt0.o /usr/lib install: crt0.o: No such file or directory *** Error code 71 Stop. *** Error code 1 Stop. *** Error code 1 Stop. # _ cd'ing to /usr/src/lib and doing 'make' and/or 'make install' builds crt0.o just fine, but it looks like it's getting skipped in the world context. It's kind of a pain to iteratively make this branch of the tree and then make world with NOCLOBBER, NOCLEAN, etc... Am I totally missing the big picture here? ...sjs... From owner-freebsd-current Wed Apr 2 08:35:41 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id IAA08075 for current-outgoing; Wed, 2 Apr 1997 08:35:41 -0800 (PST) Received: from etinc.com (et-gw-fr1.etinc.com [204.141.244.98]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id IAA08041; Wed, 2 Apr 1997 08:35:26 -0800 (PST) Received: from ntws (ntws.etinc.com [204.141.95.142]) by etinc.com (8.8.3/8.6.9) with SMTP id LAA24142; Wed, 2 Apr 1997 11:39:42 -0500 (EST) Message-Id: <3.0.32.19970402113410.00b716e0@etinc.com> X-Sender: dennis@etinc.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Wed, 02 Apr 1997 11:34:17 -0500 To: fyeung@fyeung8.netific.com (Francis Yeung), brian@awfulhak.org From: dennis Subject: Re: PPP Desperate for help! Cc: dev@fgate.flevel.co.uk, freebsd-current@FreeBSD.org, freebsd-hackers@FreeBSD.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk At 07:19 AM 4/2/97 -0800, Francis Yeung wrote: > > >Greetings, > > Will you have the magic number problem if you >connect 2 FreeBSD machines directly via PPP ? (both >machines are in LCP active) > > Francis What "magic number" problem are you referring to? db > >> From brian@awfulhak.org Tue Apr 1 14:32 PST 1997 >> To: dennis >> Cc: Developer , freebsd-current@freebsd.org, >> freebsd-hackers@freebsd.org >> Subject: Re: PPP Desperate for help! >> Mime-Version: 1.0 >> Date: Tue, 01 Apr 1997 20:49:07 +0100 >> From: Brian Somers >> X-Loop: FreeBSD.org >> X-Fetchmail-Warning: no recipient addresses matched declared local names >> >> > At 01:42 PM 4/1/97 +0100, Developer wrote: >> > > >> > > >> > >On Tue, 1 Apr 1997, Andrzej Bialecki wrote: >> > > >> > >> On Tue, 1 Apr 1997, Developer wrote: >> > >> >> > >> > >> > >> > We are really stuck trying to get the PPP user program (ppp) to >> > connect to >> > >> > our Perle 833 dial in server. We can connect using Windows NT fine but on >> > >> > BSD ppp logs in and then data will travel in both directions (As I can >> > see >> > >> > the modem lights flash at both ends for both send/recieve) but no data >> > >> > seems to actually get through as pings do not work. The packets from the >> > >> > server to the user, but seem to be lost on the way back. >> > >> >> > >> Let me take a guess: maybe it's a known problem with tcp_extensions set to >> > >> YES in /etc/sysconfig? Some broken TCP stacks don't like it, so the >> > >> solution would be to turn it off. >> > >> >> > >> Andy >> > > >> > >We've tried this - no difference. Any more ideas please? >> > >> > Why not post a trace of the ppp negotiations? Perhaps there is a parameter >> > conflict....are you getting to state IPCP_OPENED? If not, you cant pass >> > traffic. >> > >> > Dennis >> >> I suspect you're way ahead of the problem. Has the original poster >> tried "set openmode active" ? Without this, a client ppp will wait >> for the server to initiate LCP. >> >> I think it may be frugal to make this the default for both client >> *and* server. A lot of server implementations wait for the client >> to start. Any comments ? >> -- >> Brian , >> >> Don't _EVER_ lose your sense of humour.... >> >> > > From owner-freebsd-current Wed Apr 2 08:39:37 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id IAA08270 for current-outgoing; Wed, 2 Apr 1997 08:39:37 -0800 (PST) Received: from austin.polstra.com (austin.polstra.com [206.213.73.10]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id IAA08263 for ; Wed, 2 Apr 1997 08:39:31 -0800 (PST) Received: (from jdp@localhost) by austin.polstra.com (8.8.5/8.8.5) id IAA08484; Wed, 2 Apr 1997 08:39:24 -0800 (PST) To: freebsd-current@freebsd.org Path: not-for-mail From: jdp@polstra.com (John Polstra) Newsgroups: polstra.freebsd.current Subject: Re: 2.2.1-STABLE src-2.2.0224 make world fails Date: 2 Apr 1997 08:39:24 -0800 Organization: Polstra & Co., Seattle, WA Lines: 16 Distribution: local Message-ID: <5hu23s$891@austin.polstra.com> References: Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In article , Kenneth R. Westerback wrote: > After applying src-2.2.0224 I tried a make world and it failed: > > ===> share/man/man8 > ===> share/me > ===> share/misc > "Makefile", line 6: Unassociated shell command "iso3166 man.template > mdoc.template na.phone operator scsi_modes zipcodes" > Fatal errors encountered -- cannot continue The fix has been committed now. -- John Polstra jdp@polstra.com John D. Polstra & Co., Inc. Seattle, Washington USA "Self-knowledge is always bad news." -- John Barth From owner-freebsd-current Wed Apr 2 08:52:09 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id IAA09132 for current-outgoing; Wed, 2 Apr 1997 08:52:09 -0800 (PST) Received: from austin.polstra.com (austin.polstra.com [206.213.73.10]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id IAA09122 for ; Wed, 2 Apr 1997 08:52:04 -0800 (PST) Received: from austin.polstra.com (jdp@localhost) by austin.polstra.com (8.8.5/8.8.5) with ESMTP id IAA08561; Wed, 2 Apr 1997 08:50:46 -0800 (PST) Message-Id: <199704021650.IAA08561@austin.polstra.com> To: SimsS@IBM.Net Subject: Re: -current 'make world' chokes Newsgroups: polstra.freebsd.current In-Reply-To: <199704021601.QAA710624@out2.ibm.net> References: <199704021601.QAA710624@out2.ibm.net> Organization: Polstra & Co., Seattle, WA Cc: current@freebsd.org Date: Wed, 02 Apr 1997 08:50:46 -0800 From: John Polstra Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In article <199704021601.QAA710624@out2.ibm.net>, Steve Sims wrote: > > cd /usr/src/lib/csu/i386 && make beforeinstall > install -C -o bin -g bin -m 444 /usr/src/lib/csu/i386/dlfcn.h /usr/include > install -c -o bin -g bin -m 444 crt0.o c++rt0.o gcrt0.o scrt0.o sgcrt0.o > /usr/lib > install: crt0.o: No such file or directory > *** Error code 71 > [...] > Am I totally missing the big picture here? No, it really was broken. I just committed a fix. Thanks for reporting the problem. John -- John Polstra jdp@polstra.com John D. Polstra & Co., Inc. Seattle, Washington USA "Self-knowledge is always bad news." -- John Barth From owner-freebsd-current Wed Apr 2 10:00:07 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id KAA13121 for current-outgoing; Wed, 2 Apr 1997 10:00:07 -0800 (PST) Received: from fyeung5 (netific.vip.best.com [205.149.182.145]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id KAA13057; Wed, 2 Apr 1997 10:00:00 -0800 (PST) Received: from fyeung8.netific.com (fyeung8 [204.238.125.8]) by fyeung5 (8.6.11/8.6.9) with SMTP id JAA26102; Wed, 2 Apr 1997 09:59:28 -0800 Received: by fyeung8.netific.com (5.x/SMI-SVR4) id AA17015; Wed, 2 Apr 1997 10:07:17 -0800 Date: Wed, 2 Apr 1997 10:07:17 -0800 From: fyeung@fyeung8.netific.com (Francis Yeung) Message-Id: <9704021807.AA17015@fyeung8.netific.com> To: fyeung@fyeung8.netific.com, brian@awfulhak.org, dennis@etinc.com Subject: Re: PPP Desperate for help! Cc: dev@fgate.flevel.co.uk, freebsd-current@freebsd.org, freebsd-hackers@freebsd.org X-Sun-Charset: US-ASCII Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Dennis, The LCP magic number which is to be exchanged between both sides during LCP negotiation. Francis > From dennis@etinc.com Wed Apr 2 09:42 PST 1997 > X-Sender: dennis@etinc.com > Date: Wed, 02 Apr 1997 11:34:17 -0500 > To: fyeung@fyeung8.netific.com (Francis Yeung), brian@awfulhak.org > From: dennis > Subject: Re: PPP Desperate for help! > Cc: dev@fgate.flevel.co.uk, freebsd-current@freebsd.org, > freebsd-hackers@freebsd.org > Mime-Version: 1.0 > X-Loop: FreeBSD.org > X-Fetchmail-Warning: no recipient addresses matched declared local names > > At 07:19 AM 4/2/97 -0800, Francis Yeung wrote: > > > > > >Greetings, > > > > Will you have the magic number problem if you > >connect 2 FreeBSD machines directly via PPP ? (both > >machines are in LCP active) > > > > Francis > > What "magic number" problem are you referring to? > > db > > > >> From brian@awfulhak.org Tue Apr 1 14:32 PST 1997 > >> To: dennis > >> Cc: Developer , freebsd-current@freebsd.org, > >> freebsd-hackers@freebsd.org > >> Subject: Re: PPP Desperate for help! > >> Mime-Version: 1.0 > >> Date: Tue, 01 Apr 1997 20:49:07 +0100 > >> From: Brian Somers > >> X-Loop: FreeBSD.org > >> X-Fetchmail-Warning: no recipient addresses matched declared local names > >> > >> > At 01:42 PM 4/1/97 +0100, Developer wrote: > >> > > > >> > > > >> > >On Tue, 1 Apr 1997, Andrzej Bialecki wrote: > >> > > > >> > >> On Tue, 1 Apr 1997, Developer wrote: > >> > >> > >> > >> > > >> > >> > We are really stuck trying to get the PPP user program (ppp) to > >> > connect to > >> > >> > our Perle 833 dial in server. We can connect using Windows NT > fine but on > >> > >> > BSD ppp logs in and then data will travel in both directions (As > I can > >> > see > >> > >> > the modem lights flash at both ends for both send/recieve) but no > data > >> > >> > seems to actually get through as pings do not work. The packets > from the > >> > >> > server to the user, but seem to be lost on the way back. > >> > >> > >> > >> Let me take a guess: maybe it's a known problem with tcp_extensions > set to > >> > >> YES in /etc/sysconfig? Some broken TCP stacks don't like it, so the > >> > >> solution would be to turn it off. > >> > >> > >> > >> Andy > >> > > > >> > >We've tried this - no difference. Any more ideas please? > >> > > >> > Why not post a trace of the ppp negotiations? Perhaps there is a > parameter > >> > conflict....are you getting to state IPCP_OPENED? If not, you cant pass > >> > traffic. > >> > > >> > Dennis > >> > >> I suspect you're way ahead of the problem. Has the original poster > >> tried "set openmode active" ? Without this, a client ppp will wait > >> for the server to initiate LCP. > >> > >> I think it may be frugal to make this the default for both client > >> *and* server. A lot of server implementations wait for the client > >> to start. Any comments ? > >> -- > >> Brian , > >> > >> Don't _EVER_ lose your sense of humour.... > >> > >> > > > > From owner-freebsd-current Wed Apr 2 10:29:08 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id KAA14618 for current-outgoing; Wed, 2 Apr 1997 10:29:08 -0800 (PST) Received: from Campino.Informatik.RWTH-Aachen.DE (campino.Informatik.RWTH-Aachen.DE [137.226.116.240]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id KAA14592; Wed, 2 Apr 1997 10:29:04 -0800 (PST) Received: from gilberto.physik.rwth-aachen.de (gilberto.physik.rwth-aachen.de [137.226.31.2]) by Campino.Informatik.RWTH-Aachen.DE (RBI-Z-5/8.6.12) with ESMTP id UAA08403; Wed, 2 Apr 1997 20:29:12 +0200 (MET DST) Received: (from kuku@localhost) by gilberto.physik.rwth-aachen.de (8.8.5/8.6.9) id UAA00819; Wed, 2 Apr 1997 20:42:24 +0200 (MET DST) From: Christoph Kukulies Message-Id: <199704021842.UAA00819@gilberto.physik.rwth-aachen.de> Subject: Re: -current 'make world' chokes In-Reply-To: <199704021601.QAA710624@out2.ibm.net> from Steve Sims at "Apr 2, 97 10:58:25 am" To: SimsS@IBM.Net Date: Wed, 2 Apr 1997 20:42:24 +0200 (MET DST) Cc: Hackers@FreeBSD.ORG, freebsd-current@FreeBSD.ORG Reply-To: Christoph Kukulies X-Mailer: ELM [version 2.4ME+ PL28 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > How come -current has, for the last couple of days (at least, that I've > *noticed*) chokes while making the world. > > I do 'cd /usr/src ; make update world' to pull current and build it and get: > > [blah, blah, blah] > > cd /usr/src/lib/csu/i386 && make beforeinstall > install -C -o bin -g bin -m 444 /usr/src/lib/csu/i386/dlfcn.h /usr/include > install -c -o bin -g bin -m 444 crt0.o c++rt0.o gcrt0.o scrt0.o sgcrt0.o > /usr/lib > install: crt0.o: No such file or directory > *** Error code 71 Got this too, today. Just that you're not feeling alone :-) > > Stop. > *** Error code 1 > > Stop. > *** Error code 1 > > Stop. > > # _ > > > cd'ing to /usr/src/lib and doing 'make' and/or 'make install' builds crt0.o > just fine, but it looks like it's getting skipped in the world context. > > It's kind of a pain to iteratively make this branch of the tree and then make > world with NOCLOBBER, NOCLEAN, etc... > > Am I totally missing the big picture here? > > ...sjs... > -- Christoph P. U. Kukulies kuku@gil.physik.rwth-aachen.de From owner-freebsd-current Wed Apr 2 10:37:34 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id KAA15336 for current-outgoing; Wed, 2 Apr 1997 10:37:34 -0800 (PST) Received: from mercury.uniserve.com (mercury.uniserve.com [204.191.197.248]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id KAA15331 for ; Wed, 2 Apr 1997 10:37:32 -0800 (PST) Received: from haven.uniserve.com (haven.uniserve.com [198.53.215.121]) by mercury.uniserve.com (8.8.2/8.8.2) with SMTP id KAA19255; Wed, 2 Apr 1997 10:33:18 -0800 (PST) Date: Wed, 2 Apr 1997 10:43:08 -0800 (PST) From: Tom Samplonius To: "Kenneth R. Westerback" cc: freebsd-current@freebsd.org Subject: Re: 2.2.1-STABLE src-2.2.0224 make world fails In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Tue, 1 Apr 1997, Kenneth R. Westerback wrote: > After applying src-2.2.0224 I tried a make world and it failed: > > ===> share/man/man8 > ===> share/me > ===> share/misc > "Makefile", line 6: Unassociated shell command "iso3166 man.template > mdoc.template na.phone operator scsi_modes zipcodes" > Fatal errors encountered -- cannot continue > > *** Error code 1 > > Stop. > > etc. This is an easy one. The Makefile is missing the "\" continuation character at the end of one of the lines. Tom From owner-freebsd-current Wed Apr 2 10:44:44 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id KAA15609 for current-outgoing; Wed, 2 Apr 1997 10:44:44 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.50]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id KAA15603; Wed, 2 Apr 1997 10:44:38 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id LAA14010; Wed, 2 Apr 1997 11:28:05 -0700 From: Terry Lambert Message-Id: <199704021828.LAA14010@phaeton.artisoft.com> Subject: Re: ufs lock panic in -current To: ache@nagual.ru (=?KOI8-R?B?4c7E0sXKIP7F0s7P1w==?=) Date: Wed, 2 Apr 1997 11:28:05 -0700 (MST) Cc: dyson@FreeBSD.ORG, bde@zeta.org.au, current@FreeBSD.ORG In-Reply-To: from "=?KOI8-R?B?4c7E0sXKIP7F0s7P1w==?=" at Apr 2, 97 08:10:30 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > I just got following panic: > > lockmgr: locking against myself > > stack looks like: > > lockmgr > ufs_lock > vn_lock > vputrele > vrele > vnode_pager_dealloc > vm_pager_deallocate > vm_pager_terminate > vm_object_deallocate > vputrele > vrele > execve > > Please, fix. The fix is conceptually non-trivial, and requires that the transitive closure be calculated at the same layer for all FS's. This implies a veto, rather than a call-down, interface for VOP_LOCK. Physically, the fix is about 200 lines of code, including all FS code changes. 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 Apr 2 10:51:37 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id KAA15949 for current-outgoing; Wed, 2 Apr 1997 10:51:37 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.50]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id KAA15942 for ; Wed, 2 Apr 1997 10:51:27 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id LAA14025; Wed, 2 Apr 1997 11:30:54 -0700 From: Terry Lambert Message-Id: <199704021830.LAA14025@phaeton.artisoft.com> Subject: Re: Kernel Module System To: koshy@india.hp.com (A JOSEPH KOSHY) Date: Wed, 2 Apr 1997 11:30:54 -0700 (MST) Cc: gibbs@plutotech.com, freebsd-current@freebsd.org In-Reply-To: <199704020527.AA134058855@fakir.india.hp.com> from "A JOSEPH KOSHY" at Apr 2, 97 10:27:35 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > You don't want a single version number really. You want one for each > > subsystem that an LKM may depend upon. For example, the SCSI system might > > Yes, but there is a tradeoff between complexity and utility. When things get more complex, there is an unfortunate increase in their utility as well? 8-) 8-) 8-p. > This is really a release engineering issue, not a development one, and I > think it may make it easier for third party vendors to offer binary only > LKM addons for FreeBSD. Yes. That should be one of the main considerations: how do you open up commercial markets to increase overall support of FreeBSD by vendors who want to support it, but can't because it's too closed. 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 Wed Apr 2 11:16:14 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id LAA17313 for current-outgoing; Wed, 2 Apr 1997 11:16:14 -0800 (PST) Received: from Kitten.mcs.com (Kitten.mcs.com [192.160.127.90]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id LAA17238; Wed, 2 Apr 1997 11:15:35 -0800 (PST) Received: from Jupiter.Mcs.Net (karl@Jupiter.mcs.net [192.160.127.88]) by Kitten.mcs.com (8.8.5/8.8.2) with ESMTP id NAA17424; Wed, 2 Apr 1997 13:15:10 -0600 (CST) Received: (from karl@localhost) by Jupiter.Mcs.Net (8.8.5/8.8.2) id NAA27941; Wed, 2 Apr 1997 13:15:10 -0600 (CST) Message-ID: <19970402131508.59503@Jupiter.Mcs.Net> Date: Wed, 2 Apr 1997 13:15:08 -0600 From: Karl Denninger To: Terry Lambert Cc: ??????????????? , dyson@FreeBSD.ORG, bde@zeta.org.au, current@FreeBSD.ORG Subject: Re: ufs lock panic in -current References: <199704021828.LAA14010@phaeton.artisoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.64 In-Reply-To: <199704021828.LAA14010@phaeton.artisoft.com>; from Terry Lambert on Wed, Apr 02, 1997 at 11:28:05AM -0700 Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Wed, Apr 02, 1997 at 11:28:05AM -0700, Terry Lambert wrote: > > I just got following panic: > > > > lockmgr: locking against myself > > > > stack looks like: > > > > lockmgr > > ufs_lock > > vn_lock > > vputrele > > vrele > > vnode_pager_dealloc > > vm_pager_deallocate > > vm_pager_terminate > > vm_object_deallocate > > vputrele > > vrele > > execve > > > > Please, fix. > > The fix is conceptually non-trivial, and requires that the transitive > closure be calculated at the same layer for all FS's. This implies a > veto, rather than a call-down, interface for VOP_LOCK. > > Physically, the fix is about 200 lines of code, including all FS > code changes. > > > Regards, > Terry Lambert > terry@lambert.org Am I correct in understanding that this isn't fixed yet, and that also the NFS exec() problems with paging are also still open? I'm sorry about not being more up-to-date on this; I've been INSANELY busy the last few weeks, and haven't had time to dig into the NFS layer. Is it still as it was? (BTW, its easy to test -- a loopback mount from the same machine will fail just as hard as one over a real wire). -- -- Karl Denninger (karl@MCS.Net)| MCSNet - The Finest Internet Connectivity http://www.mcs.net/~karl | T1's from $600 monthly to FULL DS-3 Service | 99 Analog numbers, 77 ISDN, http://www.mcs.net/ Voice: [+1 312 803-MCS1 x219]| NOW Serving 56kbps DIGITAL on our analog lines! Fax: [+1 312 803-4929] | 2 FULL DS-3 Internet links; 400Mbps B/W Internal From owner-freebsd-current Wed Apr 2 11:32:38 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id LAA18289 for current-outgoing; Wed, 2 Apr 1997 11:32:38 -0800 (PST) Received: from critter.dk.tfs.com (phk.cybercity.dk [195.8.133.247]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id LAA18260; Wed, 2 Apr 1997 11:31:59 -0800 (PST) Received: from critter (localhost [127.0.0.1]) by critter.dk.tfs.com (8.8.5/8.8.5) with ESMTP id VAA00249; Wed, 2 Apr 1997 21:30:52 +0200 (CEST) To: Terry Lambert cc: ache@nagual.ru (=?KOI8-R?B?4c7E0sXKIP7F0s7P1w==?=), dyson@freebsd.org, bde@zeta.org.au, current@freebsd.org Subject: Re: ufs lock panic in -current In-reply-to: Your message of "Wed, 02 Apr 1997 11:28:05 PDT." <199704021828.LAA14010@phaeton.artisoft.com> Date: Wed, 02 Apr 1997 21:30:51 +0200 Message-ID: <247.860009451@critter> From: Poul-Henning Kamp Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In message <199704021828.LAA14010@phaeton.artisoft.com>, Terry Lambert writes: (Terry sent his standard reply #1:) > >The fix is conceptually non-trivial, and requires that the transitive >closure be calculated at the same layer for all FS's. This implies a >veto, rather than a call-down, interface for VOP_LOCK. > >Physically, the fix is about 200 lines of code, including all FS >code changes. (And I send my standard reply #1:) Well, send us the patch Terry! -- Poul-Henning Kamp | phk@FreeBSD.ORG FreeBSD Core-team. http://www.freebsd.org/~phk | phk@login.dknet.dk Private mailbox. whois: [PHK] | phk@tfs.com TRW Financial Systems, Inc. Power and ignorance is a disgusting cocktail. From owner-freebsd-current Wed Apr 2 11:51:23 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id LAA19593 for current-outgoing; Wed, 2 Apr 1997 11:51:23 -0800 (PST) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id LAA19584 for ; Wed, 2 Apr 1997 11:51:19 -0800 (PST) Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id VAA10655 for freebsd-current@freebsd.org; Wed, 2 Apr 1997 21:51:17 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.8.5/8.8.5) id VAA24762; Wed, 2 Apr 1997 21:27:58 +0200 (MET DST) Message-ID: <19970402212758.AV05420@uriah.heep.sax.de> Date: Wed, 2 Apr 1997 21:27:58 +0200 From: j@uriah.heep.sax.de (J Wunsch) To: freebsd-current@freebsd.org Subject: Re: PPP Problems -- The next chapter *grin* 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 Developer on Apr 2, 1997 10:17:54 +0100 Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk (Posting to two lists is always wrong.) As Developer wrote: > After not being able to get the user ppp software to work I decided to > give up and try pppd instead. After configuring correctly pppd works fine > (Just use kermit to dial and then run it)?? > > I wonder what is different between ppp and pppd that would cause the > problem? They are completely different implementations. Just telling ``it doesn't work'' is not going to get you much help. The least you should do is trying to circle the problem by examining the logs. Both, ppp and pppd can write much better logs than i've seen from many commercial PPP implementations, e.g. employed in ISDN routers. It's just that you need to turn logging on if you've got a problem. -- 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 Wed Apr 2 12:23:14 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id MAA21415 for current-outgoing; Wed, 2 Apr 1997 12:23:14 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.50]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id MAA21374; Wed, 2 Apr 1997 12:22:43 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id NAA14273; Wed, 2 Apr 1997 13:05:42 -0700 From: Terry Lambert Message-Id: <199704022005.NAA14273@phaeton.artisoft.com> Subject: Re: ufs lock panic in -current To: phk@critter.dk.tfs.com (Poul-Henning Kamp) Date: Wed, 2 Apr 1997 13:05:42 -0700 (MST) Cc: terry@lambert.org, ache@nagual.ru, dyson@freebsd.org, bde@zeta.org.au, current@freebsd.org In-Reply-To: <247.860009451@critter> from "Poul-Henning Kamp" at Apr 2, 97 09:30:51 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > (Terry sent his standard reply #1:) > > > >The fix is conceptually non-trivial, and requires that the transitive > >closure be calculated at the same layer for all FS's. This implies a > >veto, rather than a call-down, interface for VOP_LOCK. > > > >Physically, the fix is about 200 lines of code, including all FS > >code changes. > > (And I send my standard reply #1:) > > Well, send us the patch Terry! Have you guys integrated the patches I sent to Julian for the namei/nameifree fixes and the redundant code reduction "EXCLUDE" NDINIT() op flag yet? I even broke them out as seperate from all my other patches, even though it meant buying another disk and building a seperate source tree to do it: I've spend a not inconsiderable amount of money trying to appease you by hopping on the correct foot during the chanting and incense burning. If not, which will you integrate first, the lock veto fixes, or the layering fixes? I only ask so that when I hit the same function in the same file for both of them, I get the dependency order right. Or am I just supposed to send patches that work regardless of the dependency order? I'll remind you that dependencies aren't acyclic, unless we move to one function per object module, which would be ridiculous. I did send some order independent patches to you once (by stuffing in all the patches at once), but you said that they touched too much stuff at one time, so they couldn't be reviewed... Please make up your mind, and let me know when you're done. 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 Apr 2 12:36:45 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id MAA22248 for current-outgoing; Wed, 2 Apr 1997 12:36:45 -0800 (PST) Received: from peedub.gj.org (ns1046.munich.netsurf.de [195.180.235.46]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id MAA22221; Wed, 2 Apr 1997 12:36:31 -0800 (PST) Received: from peedub.gj.org (localhost [127.0.0.1]) by peedub.gj.org (8.8.5/8.6.9) with ESMTP id WAA01626; Wed, 2 Apr 1997 22:36:09 GMT Message-Id: <199704022236.WAA01626@peedub.gj.org> X-Mailer: exmh version 2.0gamma 1/27/96 To: "Peter M. Chen" Cc: freebsd-current@freebsd.org, freebsd-questions@freebsd.org Subject: Re: writing to kernel global variables with gdb Reply-To: Gary Jennejohn In-reply-to: Your message of "Tue, 01 Apr 1997 15:55:44 EST." <199704012055.PAA27208@life.eecs.umich.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 02 Apr 1997 22:36:08 +0000 From: Gary Jennejohn Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk "Peter M. Chen" writes: >Hi Gary, > Joerg referred me to you as the maintainer for kgdb. I am using >"gdb -w -k kernel.debug /dev/mem" to try to change a global variable on a >running kernel (which Joerg thought should work), but I get >"kvm_write:write failed". This is true even when I run as root. > > Any ideas? > it turns out that there's already a "w" option ("use windows") defined in main.c. There's no code which makes use of it. If you start gdb with -wcore, then you can write OK. The "w" window option isn't documented with the --help flag. But then again, the "w" make core writable option isn't either, although wcore does show up in the list. Perhaps it would be better to use "-wk" for "writable kernel" (that's sort of mnemonic) in place of "-w". Any opinions ? Guess this should really be documented somewhere. This affects both -current and 2.2.1R :( I'm forwarding this to both the current and questions mail lists, since it's (IMO) of general interest. --- Gary Jennejohn Home - Gary.Jennejohn@munich.netsurf.de Work - gjennejohn@frt.dec.com From owner-freebsd-current Wed Apr 2 12:37:30 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id MAA22311 for current-outgoing; Wed, 2 Apr 1997 12:37:30 -0800 (PST) Received: from critter.dk.tfs.com (phk.cybercity.dk [195.8.133.247]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id MAA22297; Wed, 2 Apr 1997 12:37:09 -0800 (PST) Received: from critter (localhost [127.0.0.1]) by critter.dk.tfs.com (8.8.5/8.8.5) with ESMTP id WAA00425; Wed, 2 Apr 1997 22:35:36 +0200 (CEST) To: Terry Lambert cc: ache@nagual.ru, dyson@freebsd.org, bde@zeta.org.au, current@freebsd.org Subject: Re: ufs lock panic in -current In-reply-to: Your message of "Wed, 02 Apr 1997 13:05:42 PDT." <199704022005.NAA14273@phaeton.artisoft.com> Date: Wed, 02 Apr 1997 22:35:35 +0200 Message-ID: <423.860013335@critter> From: Poul-Henning Kamp Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >> Well, send us the patch Terry! > >Have you guys integrated the patches I sent to Julian for the >namei/nameifree fixes and the redundant code reduction "EXCLUDE" >NDINIT() op flag yet? I seem to recall that you had made a lot of entirely unrelated changes too. I'm not going to rehash the history of this subject, but merely repeat my offer to you, that if you upload your sources to somwhere where I can get at it, I will funnel through changes into FreeBSD. -- Poul-Henning Kamp | phk@FreeBSD.ORG FreeBSD Core-team. http://www.freebsd.org/~phk | phk@login.dknet.dk Private mailbox. whois: [PHK] | phk@tfs.com TRW Financial Systems, Inc. Power and ignorance is a disgusting cocktail. From owner-freebsd-current Wed Apr 2 12:40:27 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id MAA22607 for current-outgoing; Wed, 2 Apr 1997 12:40:27 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.50]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id MAA22581; Wed, 2 Apr 1997 12:40:03 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id NAA14329; Wed, 2 Apr 1997 13:16:38 -0700 From: Terry Lambert Message-Id: <199704022016.NAA14329@phaeton.artisoft.com> Subject: Re: ufs lock panic in -current To: karl@Mcs.Net (Karl Denninger) Date: Wed, 2 Apr 1997 13:16:38 -0700 (MST) Cc: terry@lambert.org, ache@nagual.ru, dyson@FreeBSD.ORG, bde@zeta.org.au, current@FreeBSD.ORG In-Reply-To: <19970402131508.59503@Jupiter.Mcs.Net> from "Karl Denninger" at Apr 2, 97 01:15:08 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > Am I correct in understanding that this isn't fixed yet, and that also the > NFS exec() problems with paging are also still open? Yes. I believe, however, that Doug Rabson was replacing the stubbed routines in the NFS case to respect the lock used by vclean. This is a sort of kludge soloution, but should fix the NFS vnode problems. The paging problems were mentioned by John Dyson as something he was actively looking at; they are, it seems, related to the VM object alising issues that the Lite2 unionfs also suffers under (from my minimal reading of John's posting and the affected code in both FS's). > I'm sorry about not being more up-to-date on this; I've been INSANELY busy > the last few weeks, and haven't had time to dig into the NFS layer. Is it > still as it was? > > (BTW, its easy to test -- a loopback mount from the same machine will fail > just as hard as one over a real wire). I believe the work discussed above may be sufficient to mask both these problems (and solve them, in one of the cases). 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 Apr 2 13:14:11 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id NAA24456 for current-outgoing; Wed, 2 Apr 1997 13:14:11 -0800 (PST) Received: from awfulhak.demon.co.uk (awfulhak.demon.co.uk [158.152.17.1]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id NAA24388; Wed, 2 Apr 1997 13:13:53 -0800 (PST) Received: from awfulhak.demon.co.uk (localhost.lan.awfulhak.org [127.0.0.1]) by awfulhak.demon.co.uk (8.8.5/8.8.5) with ESMTP id WAA14851; Wed, 2 Apr 1997 22:07:01 +0100 (BST) Message-Id: <199704022107.WAA14851@awfulhak.demon.co.uk> X-Mailer: exmh version 1.6.9 8/22/96 To: Developer cc: freebsd-current@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: PPP Problems -- The next chapter *grin* In-reply-to: Your message of "Wed, 02 Apr 1997 10:17:54 BST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 02 Apr 1997 22:07:01 +0100 From: Brian Somers Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > After not being able to get the user ppp software to work I decided to > give up and try pppd instead. After configuring correctly pppd works fine > (Just use kermit to dial and then run it)?? > > I wonder what is different between ppp and pppd that would cause the > problem? > > Regards, > > Trefor S. The answer would be shorter if you asked what isn't different. Were you using the pmdemand example and reading the handbook tutorial ? Was it >= 2.2 ? -- Brian , Don't _EVER_ lose your sense of humour.... From owner-freebsd-current Wed Apr 2 13:15:55 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id NAA24637 for current-outgoing; Wed, 2 Apr 1997 13:15:55 -0800 (PST) Received: from awfulhak.demon.co.uk (awfulhak.demon.co.uk [158.152.17.1]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id NAA24580; Wed, 2 Apr 1997 13:15:43 -0800 (PST) Received: from awfulhak.demon.co.uk (localhost.lan.awfulhak.org [127.0.0.1]) by awfulhak.demon.co.uk (8.8.5/8.8.5) with ESMTP id VAA14484; Wed, 2 Apr 1997 21:51:59 +0100 (BST) Message-Id: <199704022051.VAA14484@awfulhak.demon.co.uk> X-Mailer: exmh version 1.6.9 8/22/96 To: dennis cc: Brian Somers , Developer , freebsd-current@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: PPP Desperate for help! In-reply-to: Your message of "Tue, 01 Apr 1997 19:07:32 CDT." <3.0.32.19970401190724.00b1d924@etinc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 02 Apr 1997 21:51:58 +0100 From: Brian Somers Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > >I think it may be frugal to make this the default for both client > >*and* server. A lot of server implementations wait for the client > >to start. Any comments ? > > It shouldnt make a difference, if implemented properly. There is > no master-slave relationship in ppp...the ends are peers. Upon > starting the interface it should send "n" configs, and then stop > if no reply is received. When a config is received it starts again. The > state machine allows for this nicely. One problem is when the electrical > interface (UP) is not implemented (ie, receipt of DSR) properly. You should > not be able to get into both ends being dormant if its done properly. > > Dennis But the problem is (and I experienced this myself with my ISP) that ppp in "call-up" mode won't start LCP. My ISP will not start either, so I make the call and we both sit there looking at eachother, grinning in a way that only ppp connections can. With "set openmode active", LCP is initiated irrespective. -- Brian , Don't _EVER_ lose your sense of humour.... From owner-freebsd-current Wed Apr 2 13:16:30 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id NAA24791 for current-outgoing; Wed, 2 Apr 1997 13:16:30 -0800 (PST) Received: from awfulhak.demon.co.uk (awfulhak.demon.co.uk [158.152.17.1]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id NAA24767; Wed, 2 Apr 1997 13:16:22 -0800 (PST) Received: from awfulhak.demon.co.uk (localhost.lan.awfulhak.org [127.0.0.1]) by awfulhak.demon.co.uk (8.8.5/8.8.5) with ESMTP id VAA14184; Wed, 2 Apr 1997 21:48:17 +0100 (BST) Message-Id: <199704022048.VAA14184@awfulhak.demon.co.uk> X-Mailer: exmh version 1.6.9 8/22/96 To: fyeung@fyeung8.netific.com (Francis Yeung) cc: dennis@etinc.com, brian@awfulhak.org, dev@fgate.flevel.co.uk, freebsd-current@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: PPP Desperate for help! In-reply-to: Your message of "Wed, 02 Apr 1997 07:19:10 -0800." <9704021519.AA16536@fyeung8.netific.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 02 Apr 1997 21:48:16 +0100 From: Brian Somers Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > > Greetings, > > Will you have the magic number problem if you > connect 2 FreeBSD machines directly via PPP ? (both > machines are in LCP active) > > Francis Nope - check out GenerateMagic in lcp.c. It's not exactly random, but you'd be pretty lucky to have problems. -- Brian , Don't _EVER_ lose your sense of humour.... From owner-freebsd-current Wed Apr 2 13:18:46 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id NAA25044 for current-outgoing; Wed, 2 Apr 1997 13:18:46 -0800 (PST) Received: from awfulhak.demon.co.uk (awfulhak.demon.co.uk [158.152.17.1]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id NAA25020; Wed, 2 Apr 1997 13:18:36 -0800 (PST) Received: from awfulhak.demon.co.uk (localhost.lan.awfulhak.org [127.0.0.1]) by awfulhak.demon.co.uk (8.8.5/8.8.5) with ESMTP id VAA14200; Wed, 2 Apr 1997 21:49:22 +0100 (BST) Message-Id: <199704022049.VAA14200@awfulhak.demon.co.uk> X-Mailer: exmh version 1.6.9 8/22/96 To: dennis cc: fyeung@fyeung8.netific.com (Francis Yeung), brian@awfulhak.org, dev@fgate.flevel.co.uk, freebsd-current@FreeBSD.org, freebsd-hackers@FreeBSD.org Subject: Re: PPP Desperate for help! In-reply-to: Your message of "Wed, 02 Apr 1997 11:34:17 CDT." <3.0.32.19970402113410.00b716e0@etinc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 02 Apr 1997 21:49:22 +0100 From: Brian Somers Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > At 07:19 AM 4/2/97 -0800, Francis Yeung wrote: > > > > > >Greetings, > > > > Will you have the magic number problem if you > >connect 2 FreeBSD machines directly via PPP ? (both > >machines are in LCP active) > > > > Francis > > What "magic number" problem are you referring to? > > db >From rfc1663: [.....] Every link in a single machine MUST have different Magic Numbers, and each end of every link between two peers SHOULD have Magic Numbers which are unique to those peers. This protects against patch-panel errors in addition to looped-back links. [.....] -- Brian , Don't _EVER_ lose your sense of humour.... From owner-freebsd-current Wed Apr 2 13:18:31 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id NAA25007 for current-outgoing; Wed, 2 Apr 1997 13:18:31 -0800 (PST) Received: from mailbox.uq.edu.au (zzshocki.slip.cc.uq.edu.au [130.102.221.173]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id NAA24990 for ; Wed, 2 Apr 1997 13:18:26 -0800 (PST) Received: from bloop.craftncomp.com (localhost.craftncomp.com [127.0.0.1]) by mailbox.uq.edu.au (8.8.5/8.6.12) with ESMTP id HAA00750; Thu, 3 Apr 1997 07:10:04 +1000 (EST) Message-Id: <199704022110.HAA00750@mailbox.uq.edu.au> X-Mailer: exmh version 2.0gamma 1/27/96 To: Poul-Henning Kamp , terry@lambert.org cc: current@freebsd.org Subject: Re: ufs lock panic in -current In-reply-to: Your message of "Wed, 02 Apr 1997 22:35:35 +0200." <423.860013335@critter> From: shocking@mailbox.uq.edu.au Reply-To: shocking@mailbox.uq.edu.au Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 03 Apr 1997 07:10:03 +1000 Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk [The great FS patch saga deleted] Dammit, just get the blasted thing in current, where we'll beat the bugs out of them. If you do this, I guarantee that Terry's email bill will drop by 50% 8^) 8^). Besides, I want to see what all this transitive closure stuff looks like. Stephen From owner-freebsd-current Wed Apr 2 13:42:24 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id NAA27127 for current-outgoing; Wed, 2 Apr 1997 13:42:24 -0800 (PST) Received: from Kitten.mcs.com (Kitten.mcs.com [192.160.127.90]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id NAA27112; Wed, 2 Apr 1997 13:42:07 -0800 (PST) Received: from Jupiter.Mcs.Net (karl@Jupiter.mcs.net [192.160.127.88]) by Kitten.mcs.com (8.8.5/8.8.2) with ESMTP id PAA23246; Wed, 2 Apr 1997 15:41:50 -0600 (CST) Received: (from karl@localhost) by Jupiter.Mcs.Net (8.8.5/8.8.2) id PAA03204; Wed, 2 Apr 1997 15:41:48 -0600 (CST) Message-ID: <19970402154148.33915@Jupiter.Mcs.Net> Date: Wed, 2 Apr 1997 15:41:48 -0600 From: Karl Denninger To: Terry Lambert Cc: Karl Denninger , ache@nagual.ru, dyson@freebsd.org, bde@zeta.org.au, current@freebsd.org Subject: Re: ufs lock panic in -current References: <19970402131508.59503@Jupiter.Mcs.Net> <199704022016.NAA14329@phaeton.artisoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.64 In-Reply-To: <199704022016.NAA14329@phaeton.artisoft.com>; from Terry Lambert on Wed, Apr 02, 1997 at 01:16:38PM -0700 Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Wed, Apr 02, 1997 at 01:16:38PM -0700, Terry Lambert wrote: > > Am I correct in understanding that this isn't fixed yet, and that also the > > NFS exec() problems with paging are also still open? > > Yes. > > I believe, however, that Doug Rabson was replacing the stubbed routines > in the NFS case to respect the lock used by vclean. This is a sort > of kludge soloution, but should fix the NFS vnode problems. > > The paging problems were mentioned by John Dyson as something he > was actively looking at; they are, it seems, related to the VM object > alising issues that the Lite2 unionfs also suffers under (from my > minimal reading of John's posting and the affected code in both > FS's). > > > > I'm sorry about not being more up-to-date on this; I've been INSANELY busy > > the last few weeks, and haven't had time to dig into the NFS layer. Is it > > still as it was? > > > > (BTW, its easy to test -- a loopback mount from the same machine will fail > > just as hard as one over a real wire). > > I believe the work discussed above may be sufficient to mask both these > problems (and solve them, in one of the cases). Ok, can someone make sure to drop a note in -current when they think this is fixed? I'll take another poke at it at that point. -- -- Karl Denninger (karl@MCS.Net)| MCSNet - The Finest Internet Connectivity http://www.mcs.net/~karl | T1's from $600 monthly to FULL DS-3 Service | 99 Analog numbers, 77 ISDN, http://www.mcs.net/ Voice: [+1 312 803-MCS1 x219]| NOW Serving 56kbps DIGITAL on our analog lines! Fax: [+1 312 803-4929] | 2 FULL DS-3 Internet links; 400Mbps B/W Internal From owner-freebsd-current Wed Apr 2 13:52:22 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id NAA27657 for current-outgoing; Wed, 2 Apr 1997 13:52:22 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.50]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id NAA27644; Wed, 2 Apr 1997 13:52:16 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id OAA14527; Wed, 2 Apr 1997 14:35:30 -0700 From: Terry Lambert Message-Id: <199704022135.OAA14527@phaeton.artisoft.com> Subject: Re: ufs lock panic in -current To: phk@critter.dk.tfs.com (Poul-Henning Kamp) Date: Wed, 2 Apr 1997 14:35:29 -0700 (MST) Cc: terry@lambert.org, ache@nagual.ru, dyson@freebsd.org, bde@zeta.org.au, current@freebsd.org In-Reply-To: <423.860013335@critter> from "Poul-Henning Kamp" at Apr 2, 97 10:35:35 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > >Have you guys integrated the patches I sent to Julian for the > >namei/nameifree fixes and the redundant code reduction "EXCLUDE" > >NDINIT() op flag yet? > > I seem to recall that you had made a lot of entirely unrelated > changes too. I believe that depended on whose big picture you were looking at. I still don't have any idea of "maximal acceptable granularity" because I still have no idea of what your big picture is (so I can see how it differs from mine). The changes were *certainly* related to moving toward where I wanted to be (SMP, kernel multithreading, median granularity subsystem locking to fine grain context locking, etc.). > I'm not going to rehash the history of this subject, but merely > repeat my offer to you, that if you upload your sources to somwhere > where I can get at it, I will funnel through changes into FreeBSD. Pretty clearly, I'm going to have to redo them all, now that the target has moved. I did this once already for the changes I already sent to Julian. If you want a granularity above that, you will need to specify it for me; if you don't want that, then integrate what I sent to Julian, and when it shows up in my SUP tree, I'll do the next bite-sized round of changes and then wait for them to show up, too. Eventually we will get to where we would have been with all the "unrelated" changes, and I'll have less baggage to drag from revision to revision, and can concentrate on other things I want to do, like working NFS locking and other things which you might see as desirable and not unrelated (*no*, I will *not* abandon my baggage to pursue goals like this -- my "baggage" is a baseline services requirement for me to build toward some of these goals, and you will not dictate to me my priorities). 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 Apr 2 14:22:38 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id OAA29198 for current-outgoing; Wed, 2 Apr 1997 14:22:38 -0800 (PST) Received: from lamb.sas.com (root@lamb.sas.com [192.35.83.8]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id OAA29192 for ; Wed, 2 Apr 1997 14:22:34 -0800 (PST) Received: from mozart by lamb.sas.com (5.65c/SAS/Gateway/01-23-95) id AA13481; Wed, 2 Apr 1997 17:08:15 -0500 Received: from iluvatar.unx.sas.com by mozart (5.65c/SAS/Domains/5-6-90) id AA24028; Wed, 2 Apr 1997 17:08:10 -0500 Received: by iluvatar.unx.sas.com (5.65c/SAS/Generic 9.01/3-26-93) id AA02609; Wed, 2 Apr 1997 17:08:10 -0500 From: "John W. DeBoskey" Message-Id: <199704022208.AA02609@iluvatar.unx.sas.com> Subject: UserMode ppp problem with set device To: freebsd-current@freebsd.org Date: Wed, 2 Apr 1997 17:08:10 -0500 (EST) Cc: jwd@unx.sas.com (John W. DeBoskey) X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hello, I'm having a problem with usermode ppp. It replicates at both 2.2 Release and 3.0-CURRENT. I have a modem pool which I access via a telnet session, so I use the set device option. My config & log output follow. If anyone has any hints, I'd appreciate them. I thought the problem was a short network read, but I'm not so sure any more. Unfortunately, I don't have a modem directly attached, so I can't test ppp in that mode. It seems to fail in LCP negotiations. The only oddity is the message 'magic is same!!.' My conf file & log follow. Thanks, John default: set device dialout.net:23 set dial "TIMEOUT 2 OK-ATE1Q0-OK \\dATDT\\T TIMEOUT 25 CONNECT" sasppp: set phone 9wxxxyyyy,,,zzzz set login "Login script here -- works fine" set debug phase chat connect carrier lcp lqm tcpip hdlc async link enable pap accept pap disable chap deny chap set ifaddr 192.42.243.16/32 192.42.243.1/32 set openmode active 04-02 11:49:53 [469] Connected! 04-02 11:49:53 [469] LCP: state change Initial --> Closed 04-02 11:49:53 [469] LCP: SendConfigReq 04-02 11:49:53 [469] ACFCOMP 04-02 11:49:53 [469] PROTOCOMP 04-02 11:49:53 [469] ACCMAP [6] 00000000 04-02 11:49:53 [469] MRU [4] 1500 04-02 11:49:53 [469] MAGICNUM [6] d5416e5d 04-02 11:49:53 [469] QUALPROTO (3000) 04-02 11:49:53 [469] AUTHPROTO [4] 49187 04-02 11:49:53 [469] HdlcOutput 04-02 11:49:53 [469] ff 03 c0 21 01 01 00 24 08 02 07 02 02 06 00 00 04-02 11:49:53 [469] 00 00 01 04 05 dc 05 06 d5 41 6e 5d 04 08 c0 25 04-02 11:49:53 [469] 00 00 0b b8 03 04 c0 23 f6 83 04-02 11:49:53 [469] WriteModem 04-02 11:49:53 [469] 7e 7d df 7d 23 c0 21 7d 21 7d 21 7d 20 24 7d 28 04-02 11:49:53 [469] 7d 22 7d 27 7d 22 7d 22 7d 26 7d 20 7d 20 7d 20 04-02 11:49:53 [469] 7d 20 7d 21 7d 24 7d 25 dc 7d 25 7d 26 d5 41 6e 04-02 11:49:53 [469] 5d 7d 24 7d 28 c0 25 7d 20 7d 20 7d 2b b8 7d 23 04-02 11:49:53 [469] 7d 24 c0 23 f6 83 7e 04-02 11:49:53 [469] LCP: state change Closed --> Req-Sent 04-02 11:49:53 [469] ReadFromModem 04-02 11:49:53 [469] 20 0d 00 0a 20 20 20 20 20 20 20 20 20 04-02 11:49:53 [469] ReadFromModem 04-02 11:49:53 [469] 20 20 20 20 20 20 20 20 20 20 20 55 6e 61 75 74 04-02 11:49:53 [469] 68 6f 72 69 7a 65 64 20 61 63 63 65 73 73 20 70 04-02 11:49:53 [469] 72 6f 68 69 62 69 74 65 64 20 2d 20 64 69 61 6c 04-02 11:49:53 [469] 75 70 30 0d 00 0a 0d 00 0a 0d 00 0a 0d 00 0a 64 04-02 11:49:53 [469] 69 61 6c 75 70 30 3e 20 73 65 74 20 70 6f 72 74 04-02 11:49:53 [469] 20 69 6e 74 65 72 6e 65 74 20 70 70 70 20 65 6e 04-02 11:49:53 [469] 61 62 6c 65 04-02 11:49:53 [469] ReadFromModem 04-02 11:49:53 [469] 0d 00 0a 58 79 70 6c 65 78 20 2d 37 30 32 2d 20 04-02 11:49:53 [469] 4b 65 79 77 6f 72 64 20 22 50 50 50 22 20 04-02 11:49:53 [469] ReadFromModem 04-02 11:49:53 [469] 6e 6f 74 20 6b 6e 6f 77 6e 20 6f 72 20 61 6d 62 04-02 11:49:53 [469] 69 67 75 6f 75 73 0d 00 0a 20 20 20 20 20 20 20 04-02 11:49:53 [469] 20 20 20 20 20 20 4c 6f 6f 6b 69 6e 67 20 66 6f 04-02 11:49:53 [469] 72 3a 20 20 43 4f 4e 4e 45 43 54 49 4f 4e 53 20 04-02 11:49:53 [469] 43 53 4c 49 50 20 46 49 4c 54 45 52 20 53 45 43 04-02 11:49:53 [469] 55 52 49 54 59 20 53 4c 49 50 20 54 43 50 20 04-02 11:49:53 [469] ReadFromModem 04-02 11:49:53 [469] 0d 00 0a 0d 00 0a 64 69 61 6c 75 70 30 3e 20 7e 04-02 11:49:53 [469] 7d df 7d 23 c0 21 7d 21 7d 21 7d 20 24 7d 28 7d 04-02 11:49:53 [469] 22 7d 27 7d 22 7d 22 7d 26 7d 20 7d 20 7d 20 7d 04-02 11:49:53 [469] 20 7d 21 7d 24 7d 25 dc 7d 25 7d 26 d5 41 6e 5d 04-02 11:49:53 [469] 7d 24 7d 28 c0 25 7d 20 7d 20 7d 2b b8 7d 23 7d 04-02 11:49:53 [469] 24 c0 23 f6 83 7e 04-02 11:49:53 [469] HdlcInput: 04-02 11:49:53 [469] ff 03 c0 21 01 01 00 24 08 02 07 02 02 06 00 00 04-02 11:49:53 [469] 00 00 01 04 05 dc 05 06 d5 41 6e 5d 04 08 c0 25 04-02 11:49:53 [469] 00 00 0b b8 03 04 c0 23 f6 83 04-02 11:49:53 [469] LCP: Received Configure Request (1) state = Req-Sent (6) 04-02 11:49:53 [469] ACFCOMP 04-02 11:49:53 [469] PROTOCOMP 04-02 11:49:53 [469] ACCMAP 00000000 04-02 11:49:53 [469] MRU 1500 04-02 11:49:53 [469] MAGICNUM d5416e5d magic is same!! d5416e5d, d5416e5d, 0 04-02 11:49:53 [469] QUALPROTO proto: c025, interval: 30000ms 04-02 11:49:53 [469] AUTHPROTO proto = c023 04-02 11:49:53 [469] LCP: SendConfigAck(Req-Sent) 04-02 11:49:53 [469] ACFCOMP 04-02 11:49:53 [469] PROTOCOMP 04-02 11:49:53 [469] ACCMAP 00000000 04-02 11:49:53 [469] MRU 1500 04-02 11:49:53 [469] MAGICNUM d5416e5d 04-02 11:49:53 [469] QUALPROTO proto: c025, interval: 30000ms 04-02 11:49:53 [469] AUTHPROTO proto = c023 04-02 11:49:53 [469] HdlcOutput 04-02 11:49:53 [469] ff 03 c0 21 02 01 00 24 08 02 07 02 02 06 00 00 04-02 11:49:53 [469] 00 00 01 04 05 dc 05 06 d5 41 6e 5d 04 08 c0 25 04-02 11:49:53 [469] 00 00 0b b8 03 04 c0 23 36 7f 04-02 11:49:53 [469] WriteModem 04-02 11:49:53 [469] 7e 7d df 7d 23 c0 21 7d 22 7d 21 7d 20 24 7d 28 04-02 11:49:53 [469] 7d 22 7d 27 7d 22 7d 22 7d 26 7d 20 7d 20 7d 20 04-02 11:49:53 [469] 7d 20 7d 21 7d 24 7d 25 dc 7d 25 7d 26 d5 41 6e 04-02 11:49:53 [469] 5d 7d 24 7d 28 c0 25 7d 20 7d 20 7d 2b b8 7d 23 04-02 11:49:53 [469] 7d 24 c0 23 36 7f 7e 04-02 11:49:53 [469] LCP: state change Req-Sent --> Ack-Sent 04-02 11:49:54 [469] ReadFromModem 04-02 11:49:54 [469] 7e 7d df 7d 23 c0 21 7d 22 7d 21 7d 20 24 7d 28 04-02 11:49:54 [469] 7d 22 7d 27 7d 04-02 11:49:54 [469] ReadFromModem 04-02 11:49:54 [469] 22 7d 22 7d 26 7d 20 7d 20 7d 20 7d 20 7d 21 7d 04-02 11:49:54 [469] 24 7d 25 dc 7d 25 7d 26 d5 41 6e 5d 7d 24 7d 28 04-02 11:49:54 [469] c0 25 7d 20 7d 20 7d 2b 07 07 07 07 07 07 07 07 04-02 11:49:54 [469] 07 07 07 07 07 07 07 07 07 07 08 20 08 7e 07 07 04-02 11:49:54 [469] HdlcInput: 04-02 11:49:54 [469] ff 03 c0 21 02 01 00 24 08 02 07 02 02 06 00 00 04-02 11:49:54 [469] 00 00 01 04 05 dc 05 06 d5 41 6e 5d 04 08 c0 25 04-02 11:49:54 [469] 00 00 0b 07 07 07 07 07 07 07 07 07 07 07 07 07 04-02 11:49:54 [469] 07 07 07 07 07 08 20 08 04-02 11:49:56 [469] LCP: SendConfigReq 04-02 11:49:56 [469] ACFCOMP 04-02 11:49:56 [469] PROTOCOMP 04-02 11:49:56 [469] ACCMAP [6] 00000000 04-02 11:49:56 [469] MRU [4] 1500 04-02 11:49:56 [469] MAGICNUM [6] d5416e5d 04-02 11:49:56 [469] QUALPROTO (3000) 04-02 11:49:56 [469] AUTHPROTO [4] 49187 04-02 11:49:56 [469] HdlcOutput 04-02 11:49:56 [469] ff 03 c0 21 01 02 00 24 08 02 07 02 02 06 00 00 04-02 11:49:56 [469] 00 00 01 04 05 dc 05 06 d5 41 6e 5d 04 08 c0 25 04-02 11:49:56 [469] 00 00 0b b8 03 04 c0 23 bd 94 04-02 11:49:56 [469] WriteModem 04-02 11:49:56 [469] 7e 7d df 7d 23 c0 21 7d 21 7d 22 7d 20 24 7d 28 04-02 11:49:56 [469] 7d 22 7d 27 7d 22 7d 22 7d 26 7d 20 7d 20 7d 20 04-02 11:49:56 [469] 7d 20 7d 21 7d 24 7d 25 dc 7d 25 7d 26 d5 41 6e 04-02 11:49:56 [469] 5d 7d 24 7d 28 c0 25 7d 20 7d 20 7d 2b b8 7d 23 04-02 11:49:56 [469] 7d 24 c0 23 bd 94 7e 04-02 11:49:56 [469] ReadFromModem 04-02 11:49:56 [469] 07 07 07 07 07 07 07 07 07 07 07 07 07 07 07 07 04-02 11:49:56 [469] 07 07 07 07 07 07 07 07 07 07 07 07 07 07 07 07 04-02 11:49:56 [469] 07 07 07 07 07 07 07 07 07 07 07 07 07 07 07 07 04-02 11:49:56 [469] 07 07 07 07 07 07 07 07 07 07 07 07 07 07 07 07 04-02 11:49:56 [469] 07 07 07 07 07 07 07 07 07 07 07 07 07 07 07 07 04-02 11:49:56 [469] 07 07 07 07 07 07 07 07 07 07 07 07 07 07 07 07 04-02 11:49:56 [469] 07 07 07 07 07 07 07 07 07 07 07 07 07 07 07 07 04-02 11:49:56 [469] 07 07 07 07 07 07 07 07 07 07 07 07 07 07 07 07 04-02 11:49:56 [469] 07 07 07 07 07 07 07 07 07 07 07 04-02 11:49:56 [469] ReadFromModem 04-02 11:49:56 [469] 07 07 07 04-02 11:49:59 [469] LCP: SendConfigReq 04-02 11:49:59 [469] ACFCOMP 04-02 11:49:59 [469] PROTOCOMP 04-02 11:49:59 [469] ACCMAP [6] 00000000 04-02 11:49:59 [469] MRU [4] 1500 04-02 11:49:59 [469] MAGICNUM [6] d5416e5d 04-02 11:49:59 [469] QUALPROTO (3000) 04-02 11:49:59 [469] AUTHPROTO [4] 49187 04-02 11:49:59 [469] HdlcOutput 04-02 11:49:59 [469] ff 03 c0 21 01 03 00 24 08 02 07 02 02 06 00 00 04-02 11:49:59 [469] 00 00 01 04 05 dc 05 06 d5 41 6e 5d 04 08 c0 25 04-02 11:49:59 [469] 00 00 0b b8 03 04 c0 23 84 99 04-02 11:49:59 [469] WriteModem 04-02 11:49:59 [469] 7e 7d df 7d 23 c0 21 7d 21 7d 23 7d 20 24 7d 28 04-02 11:49:59 [469] 7d 22 7d 27 7d 22 7d 22 7d 26 7d 20 7d 20 7d 20 04-02 11:49:59 [469] 7d 20 7d 21 7d 24 7d 25 dc 7d 25 7d 26 d5 41 6e 04-02 11:49:59 [469] 5d 7d 24 7d 28 c0 25 7d 20 7d 20 7d 2b b8 7d 23 04-02 11:49:59 [469] 7d 24 c0 23 84 99 7e 04-02 11:49:59 [469] ReadFromModem 04-02 11:49:59 [469] 07 07 07 07 07 07 07 07 07 07 07 07 07 07 07 07 04-02 11:49:59 [469] 07 07 07 07 07 07 07 07 07 07 07 07 07 07 07 07 04-02 11:49:59 [469] 07 07 07 07 07 07 07 07 07 07 07 07 07 07 07 07 04-02 11:49:59 [469] 07 07 07 07 07 07 07 07 07 07 07 07 07 07 07 07 04-02 11:49:59 [469] 07 07 07 07 07 07 07 07 07 07 07 07 07 07 07 07 04-02 11:49:59 [469] 07 07 07 07 07 07 07 07 07 07 07 07 07 07 07 07 04-02 11:49:59 [469] 07 07 07 07 07 07 07 07 07 07 07 07 07 07 07 07 04-02 11:49:59 [469] 07 07 07 07 07 07 07 07 07 07 07 07 07 07 07 07 04-02 11:49:59 [469] 07 07 07 07 07 07 04-02 11:49:59 [469] ReadFromModem 04-02 11:49:59 [469] 07 07 07 07 07 07 07 07 04-02 11:50:02 [469] LCP: SendConfigReq 04-02 11:50:02 [469] ACFCOMP 04-02 11:50:02 [469] PROTOCOMP 04-02 11:50:02 [469] ACCMAP [6] 00000000 04-02 11:50:02 [469] MRU [4] 1500 04-02 11:50:02 [469] MAGICNUM [6] d5416e5d 04-02 11:50:02 [469] QUALPROTO (3000) 04-02 11:50:02 [469] AUTHPROTO [4] 49187 04-02 11:50:02 [469] HdlcOutput 04-02 11:50:02 [469] ff 03 c0 21 01 04 00 24 08 02 07 02 02 06 00 00 04-02 11:50:02 [469] 00 00 01 04 05 dc 05 06 d5 41 6e 5d 04 08 c0 25 04-02 11:50:02 [469] 00 00 0b b8 03 04 c0 23 2b ba 04-02 11:50:02 [469] WriteModem 04-02 11:50:02 [469] 7e 7d df 7d 23 c0 21 7d 21 7d 24 7d 20 24 7d 28 04-02 11:50:02 [469] 7d 22 7d 27 7d 22 7d 22 7d 26 7d 20 7d 20 7d 20 04-02 11:50:02 [469] 7d 20 7d 21 7d 24 7d 25 dc 7d 25 7d 26 d5 41 6e 04-02 11:50:02 [469] 5d 7d 24 7d 28 c0 25 7d 20 7d 20 7d 2b b8 7d 23 04-02 11:50:02 [469] 7d 24 c0 23 2b ba 7e 04-02 11:50:02 [469] ReadFromModem 04-02 11:50:02 [469] 07 07 07 07 07 07 07 07 07 07 07 07 07 07 07 07 04-02 11:50:02 [469] 07 07 07 07 07 07 07 07 07 07 07 07 07 07 07 07 04-02 11:50:02 [469] 07 07 07 07 07 07 07 07 07 07 07 07 07 07 07 07 04-02 11:50:02 [469] 07 07 07 07 07 07 07 07 07 07 07 07 07 07 07 07 04-02 11:50:02 [469] 07 07 07 07 07 07 07 07 07 07 07 07 07 07 07 07 04-02 11:50:02 [469] 07 07 07 07 07 07 07 07 07 07 07 07 07 07 07 07 04-02 11:50:02 [469] 07 07 07 07 07 07 07 07 07 07 07 07 07 07 07 07 04-02 11:50:02 [469] 07 07 07 07 07 07 07 07 07 07 07 07 07 07 07 07 04-02 11:50:02 [469] 07 07 07 07 07 07 07 07 07 07 07 07 07 07 04-02 11:50:05 [469] LCP: SendConfigReq 04-02 11:50:05 [469] ACFCOMP 04-02 11:50:05 [469] PROTOCOMP 04-02 11:50:05 [469] ACCMAP [6] 00000000 04-02 11:50:05 [469] MRU [4] 1500 04-02 11:50:05 [469] MAGICNUM [6] d5416e5d 04-02 11:50:05 [469] QUALPROTO (3000) 04-02 11:50:05 [469] AUTHPROTO [4] 49187 04-02 11:50:05 [469] HdlcOutput 04-02 11:50:05 [469] ff 03 c0 21 01 05 00 24 08 02 07 02 02 06 00 00 04-02 11:50:05 [469] 00 00 01 04 05 dc 05 06 d5 41 6e 5d 04 08 c0 25 04-02 11:50:05 [469] 00 00 0b b8 03 04 c0 23 12 b7 04-02 11:50:05 [469] WriteModem 04-02 11:50:05 [469] 7e 7d df 7d 23 c0 21 7d 21 7d 25 7d 20 24 7d 28 04-02 11:50:05 [469] 7d 22 7d 27 7d 22 7d 22 7d 26 7d 20 7d 20 7d 20 04-02 11:50:05 [469] 7d 20 7d 21 7d 24 7d 25 dc 7d 25 7d 26 d5 41 6e 04-02 11:50:05 [469] 5d 7d 24 7d 28 c0 25 7d 20 7d 20 7d 2b b8 7d 23 04-02 11:50:05 [469] 7d 24 c0 23 7d 32 b7 7e 04-02 11:50:05 [469] ReadFromModem 04-02 11:50:05 [469] 07 07 07 07 07 07 07 07 07 07 07 07 07 07 07 07 04-02 11:50:05 [469] 07 07 07 07 07 07 07 07 07 07 07 07 07 07 07 07 04-02 11:50:05 [469] 07 07 07 07 07 07 07 07 07 07 07 07 04-02 11:50:05 [469] ReadFromModem 04-02 11:50:05 [469] 07 07 07 07 07 07 07 07 07 07 07 07 07 07 07 07 04-02 11:50:05 [469] 07 07 07 07 07 07 07 07 07 07 07 07 07 07 07 07 04-02 11:50:05 [469] 07 07 07 07 07 07 07 07 07 07 07 07 07 07 07 07 04-02 11:50:05 [469] 07 07 07 07 07 07 07 07 07 07 07 07 07 07 07 07 04-02 11:50:05 [469] 07 07 07 07 07 07 07 07 07 07 07 07 07 07 07 07 04-02 11:50:05 [469] 07 07 07 07 07 07 07 07 07 07 07 07 07 07 07 07 04-02 11:50:05 [469] 07 07 07 07 04-02 11:50:08 [469] LCP: state change Ack-Sent --> Stopped 04-02 11:50:08 [469] LCP: LayerFinish 04-02 11:50:08 [469] Phase: Dead 04-02 11:51:36 [469] PPP Terminated. From owner-freebsd-current Wed Apr 2 14:22:54 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id OAA29236 for current-outgoing; Wed, 2 Apr 1997 14:22:54 -0800 (PST) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id OAA29229 for ; Wed, 2 Apr 1997 14:22:50 -0800 (PST) Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id AAA12749; Thu, 3 Apr 1997 00:22:48 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.8.5/8.8.5) id AAA25397; Thu, 3 Apr 1997 00:10:29 +0200 (MET DST) Message-ID: <19970403001029.KU32814@uriah.heep.sax.de> Date: Thu, 3 Apr 1997 00:10:29 +0200 From: j@uriah.heep.sax.de (J Wunsch) To: freebsd-current@freebsd.org Cc: Gary.Jennejohn@munich.netsurf.de (Gary Jennejohn) Subject: Re: writing to kernel global variables with gdb References: <199704012055.PAA27208@life.eecs.umich.edu> <199704022236.WAA01626@peedub.gj.org> 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: <199704022236.WAA01626@peedub.gj.org>; from Gary Jennejohn on Apr 2, 1997 22:36:08 +0000 Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk As Gary Jennejohn wrote: > Perhaps it would be better to use "-wk" for "writable kernel" (that's > sort of mnemonic) in place of "-w". Any opinions ? Whatever you decide, document it in the kerneldebug.sgml file of the handbook. -- 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 Wed Apr 2 14:46:28 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id OAA00778 for current-outgoing; Wed, 2 Apr 1997 14:46:28 -0800 (PST) Received: from time.cdrom.com (root@time.cdrom.com [204.216.27.226]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id OAA00756; Wed, 2 Apr 1997 14:46:20 -0800 (PST) Received: from time.cdrom.com (jkh@localhost [127.0.0.1]) by time.cdrom.com (8.8.5/8.6.9) with ESMTP id OAA18010; Wed, 2 Apr 1997 14:44:51 -0800 (PST) To: Terry Lambert cc: phk@critter.dk.tfs.com (Poul-Henning Kamp), ache@nagual.ru, dyson@FreeBSD.ORG, bde@zeta.org.au, current@FreeBSD.ORG Subject: Re: ufs lock panic in -current In-reply-to: Your message of "Wed, 02 Apr 1997 14:35:29 MST." <199704022135.OAA14527@phaeton.artisoft.com> Date: Wed, 02 Apr 1997 14:44:51 -0800 Message-ID: <18006.860021091@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > I'm not going to rehash the history of this subject, but merely > > repeat my offer to you, that if you upload your sources to somwhere > > where I can get at it, I will funnel through changes into FreeBSD. > > Pretty clearly, I'm going to have to redo them all, now that the > target has moved. I did this once already for the changes I already > sent to Julian. No, no, just upload them *now* please! Phk is already more than familiar with the degree of target movement involved, and putting them up for public display is precisely where you've waffled out on this issue *every single time* it's come up. If you don't want to release your bits, fine, but then kindly *stop* talking about how reluctant we are to integrate them everytime someone so much as gives you an opening! You can't have it both ways, OK? Please, just take phk up on his offer and ** upload your changes *** so that we can maybe even get *past* this "2 year's worth of delay" you keep talking about. Don't make it 3 years through your own initiative now, eh? :-) Jordan From owner-freebsd-current Wed Apr 2 14:54:11 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id OAA01238 for current-outgoing; Wed, 2 Apr 1997 14:54:11 -0800 (PST) Received: from proxy3.ba.best.com (root@proxy3.ba.best.com [206.184.139.14]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id OAA01233; Wed, 2 Apr 1997 14:54:07 -0800 (PST) Received: from bsampley.vip.best.com (bsampley.vip.best.com [206.184.160.196]) by proxy3.ba.best.com (8.8.5/8.8.3) with SMTP id OAA27612; Wed, 2 Apr 1997 14:35:11 -0800 (PST) Date: Wed, 2 Apr 1997 14:33:38 -0800 (PST) From: Burton Sampley To: questions@FreeBSD.ORG cc: current@FreeBSD.ORG Subject: more problems w/ fetchmail Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Greetings, I'm still having some trouble w/ fetchamil. I have posted a message earlier to both -current and -questions. Thanks to everyone who has helped me. Here's what's happening (or not): Fetchmail only seems to work correctly if I run routed. If I do not use routed then fetchmail gives the following error: bash$ fetchmail -av Querying mail.best.com (protocol POP3) at Wed Apr 2 14:05:11 1997 fetchmail: POP3< +OK BEST Internet PopPlus (version 1.0) host:shellx fetchmail: POP3> USER bsampley fetchmail: POP3< +OK Password required for bsampley. fetchmail: POP3> PASS * fetchmail: POP3< +OK bsampley has 55 message(s) (163318 octets). fetchmail: POP3> STAT fetchmail: POP3< +OK 55 163318 fetchmail: 55 messages at bsampley@mail.best.com. fetchmail: POP3> RETR 1 fetchmail: POP3< +OK 2002 octets reading message 1 (2002 bytes)fetchmail: SMTP connect failed fetchmail: POP3> QUIT fetchmail: POP3< Hi, fetchmail: SMTP transaction error while fetching from mail.best.com When it gets to the line reading message 1 it will sit there for about 15 seconds and then give the message SMTP transaction error and then move on to the next host listed in my .fetchmailrc file. If I start routed while this problem is occuring the it suddenly works correctly and D/L's everything. If I kill routed and then start fetchmail again then it works. I'm using ppp -auto -alias demand to start ppp from my rc.local file. I used to start fetchmail with fetchmail -ad 3600 from my .profile (I know this is probably no the best place to start this, but it works for me and this is my home system). One person that responded to my previous posting stated that most likely I did not have a route to the 'outside world' but the above shows that fetchmail was able to login to the remote server and determine the number of un-read messages. Also, I am able to surf the net using both my FBSD box w/ Netscape and Lynx prior to starting routed (I removed it from the /etc/sysconfig file and now start and kill it manually to get fetchmail to work) and my Win95 box through an eithernet connection into the FBSD box. I setup both ppp and the connection to the Win95 box following the instructions from the 'Pendantic ppp primer' in the tutorials section at www.freebsd.org. Any ideas? Oh, BTW, I running 3.0-current (last CVSUPed Sat. morning with a successfull make world and recompiled kernel). If anyone needs more info, please email me and I'll send it. Thanks in advance. Burton Sampley --- Brought to you by a 100% Micro$oft free system. You too can disinfect your system at http://www.freebsd.org E-Mail: burton@bsampley.vip.best.com Alternate E-Mail: bsampley@haywire.csuhayward.edu Home Page: http://www.best.com/~bsampley (permanently under construction) From owner-freebsd-current Wed Apr 2 15:20:28 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id PAA03799 for current-outgoing; Wed, 2 Apr 1997 15:20:28 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.50]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id PAA03773; Wed, 2 Apr 1997 15:20:10 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id QAA14842; Wed, 2 Apr 1997 16:02:31 -0700 From: Terry Lambert Message-Id: <199704022302.QAA14842@phaeton.artisoft.com> Subject: Re: ufs lock panic in -current To: jkh@time.cdrom.com (Jordan K. Hubbard) Date: Wed, 2 Apr 1997 16:02:31 -0700 (MST) Cc: terry@lambert.org, phk@critter.dk.tfs.com, ache@nagual.ru, dyson@FreeBSD.ORG, bde@zeta.org.au, current@FreeBSD.ORG In-Reply-To: <18006.860021091@time.cdrom.com> from "Jordan K. Hubbard" at Apr 2, 97 02:44:51 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > Pretty clearly, I'm going to have to redo them all, now that the > > target has moved. I did this once already for the changes I already > > sent to Julian. > > No, no, just upload them *now* please! Phk is already more than > familiar with the degree of target movement involved, and putting them > up for public display is precisely where you've waffled out on this > issue *every single time* it's come up. If you don't want to release > your bits, fine, but then kindly *stop* talking about how reluctant we > are to integrate them everytime someone so much as gives you an > opening! You can't have it both ways, OK? Please, just take phk up > on his offer and ** upload your changes *** so that we can maybe even > get *past* this "2 year's worth of delay" you keep talking about. > Don't make it 3 years through your own initiative now, eh? :-) And precisely what is wrong with the set of scaled down patches that meet your "not unrelated" criteria which I have submitted, but which you have not yet integrated, either? If it isn't obvious to you by now, I don't trust you to see the intent behind my implementation choices, since you did not see the (obvious to me) relationship between the changes I initially submitted. Since you were unwilling to discuss *why* I made the changes the way I did, and instead simply rejected them without discussion, you should be able to understand why I want to spoon-feed them to you in chunks. I'd rather not have you exercise "editorial license" to remove what you see as "unrelated and useless changes" and what I see as necessary support infrastructure for what I want to do next. That is, I'd rather you didn't prevent me from doing what I want to do next because you aren't willing to spend the time to find out where I'm headed. I am here to work on a platform which provides me the ability to do further research. I am not here to be your code supermarket. I'd rather have no editiorial criticism than destructive editorial criticism, thank you. Giving you the changes incrementally seems to be the only reliable way to achieve this. 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 Apr 2 15:39:54 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id PAA06200 for current-outgoing; Wed, 2 Apr 1997 15:39:54 -0800 (PST) Received: from sovcom.kiae.su (sovcom.kiae.su [193.125.152.1]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id PAA06179; Wed, 2 Apr 1997 15:39:47 -0800 (PST) Received: by sovcom.kiae.su id AA23878 (5.65.kiae-1 ); Thu, 3 Apr 1997 02:28:45 +0300 Received: by sovcom.KIAE.su (UUMAIL/2.0); Thu, 3 Apr 97 02:28:45 +0300 Received: (from ache@localhost) by nagual.ru (8.8.5/8.8.5) id DAA00382; Thu, 3 Apr 1997 03:26:06 +0400 (MSD) Date: Thu, 3 Apr 1997 03:26:02 +0400 (MSD) From: =?KOI8-R?B?4c7E0sXKIP7F0s7P1w==?= To: "Jordan K. Hubbard" Cc: Terry Lambert , Poul-Henning Kamp , dyson@FreeBSD.ORG, bde@zeta.org.au, current@FreeBSD.ORG Subject: Re: ufs lock panic in -current In-Reply-To: <18006.860021091@time.cdrom.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Wed, 2 Apr 1997, Jordan K. Hubbard wrote: > No, no, just upload them *now* please! Phk is already more than > familiar with the degree of target movement involved, and putting them > up for public display is precisely where you've waffled out on this > issue *every single time* it's come up. If you don't want to release > your bits, fine, but then kindly *stop* talking about how reluctant we > are to integrate them everytime someone so much as gives you an > opening! You can't have it both ways, OK? Please, just take phk up > on his offer and ** upload your changes *** so that we can maybe even > get *past* this "2 year's worth of delay" you keep talking about. > Don't make it 3 years through your own initiative now, eh? :-) I doubt that this 200lines patch is really needed. Only 4 days ago I not have this panic, but now I got it with 100% probability when say 'startx'. Somethings is broken very _recently_. -- Andrey A. Chernov http://www.nagual.ru/~ache/ From owner-freebsd-current Wed Apr 2 16:07:48 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id QAA08121 for current-outgoing; Wed, 2 Apr 1997 16:07:48 -0800 (PST) Received: from vector.jhs.no_domain (slip139-92-4-67.mu.de.ibm.net [139.92.4.67]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id QAA08115; Wed, 2 Apr 1997 16:07:33 -0800 (PST) Received: from vector.jhs.no_domain (localhost [127.0.0.1]) by vector.jhs.no_domain (8.7.5/8.6.9) with ESMTP id BAA13237; Thu, 3 Apr 1997 01:57:17 +0200 (MET DST) Message-Id: <199704022357.BAA13237@vector.jhs.no_domain> To: current@freebsd.org cc: shocking@mailbox.uq.edu.au Subject: Let's stop breaking current for a couple of weeks. From: "Julian H. Stacey" Reply-To: "Julian H. Stacey" X-Email: jhs@freebsd.org, Fallback: jhs@gil.physik.rwth-aachen.de X-Organization: Vector Systems Ltd. X-Mailer: EXMH 1.6.7, PGP available X-Address: Holz Strasse 27d, 80469 Munich, Germany X-Tel: Phone +49.89.268616, Fax +49.89.2608126, Data +49.89.26023276 X-Web: http://www.freebsd.org/~jhs/ In-reply-to: Your message of "Thu, 03 Apr 1997 07:10:03 +1000." <199704022110.HAA00750@mailbox.uq.edu.au> Date: Thu, 03 Apr 1997 01:57:15 +0200 Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Subject was: Re: ufs lock panic in -current Hi, Reference: > From: shocking@mailbox.uq.edu.au > > [The great FS patch saga deleted] > > Dammit, just get the blasted thing in current, where we'll beat the bugs out > of them. If you do this, I guarantee that Terry's email bill will drop by 50% - > 8^) 8^). Besides, I want to see what all this transitive closure stuff looks > like. > > Stephen _NO_ Thanks ! Have you heard the Chinese curse: "May you live in interesting times" ? We don't need _more_ interesting new bugs in current this week or next. Like numerous others I dumped current & dropped back to a Release because I couldn't stand the recently constantly volatile broken current. Lite2 needs to go in, but as we've seen people asking other folks to sync other diffs to current, & getting the response ~"No. current is too volatile just now, wait till it calms down"~ ..... It's time to try for intervening periods of relative calm on current, between assualts by broken/untested/incomplete code; for if current becomes continuous broken hell, it'll deter other contributions. There've been a few "I survived a make world" claims lately .. but not many in a long time. Current needs to be less unstable for a while, so refugees can return to it from their Release temporary havens. If some people just want to view or publish odd bits of code in progress, web space does that, (EG I keep my add-ons & diffs in http://www.freebsd.org/~jhs/src/src.html & maintain that copy with rdist, & applicability to src/ with a shell, & bits don't get offered for a commit until they're matured & proven benign :-) Please, Let's NOT _deliberately commit more broken or untested code, unless the stuff is #ifdefed out, (or kernel optioned), or not linked in by default, so it doesn't wreck the current operating base & deter other people working in other unrelated current areas ! Thanks ! Julian -- Julian H. Stacey jhs@freebsd.org http://www.freebsd.org/~jhs/ From owner-freebsd-current Wed Apr 2 16:09:17 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id QAA08188 for current-outgoing; Wed, 2 Apr 1997 16:09:17 -0800 (PST) Received: from time.cdrom.com (root@time.cdrom.com [204.216.27.226]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id QAA08183; Wed, 2 Apr 1997 16:09:11 -0800 (PST) Received: from time.cdrom.com (jkh@localhost [127.0.0.1]) by time.cdrom.com (8.8.5/8.6.9) with ESMTP id QAA18417; Wed, 2 Apr 1997 16:08:15 -0800 (PST) To: Terry Lambert cc: phk@critter.dk.tfs.com, ache@nagual.ru, dyson@FreeBSD.ORG, bde@zeta.org.au, current@FreeBSD.ORG Subject: Re: ufs lock panic in -current In-reply-to: Your message of "Wed, 02 Apr 1997 16:02:31 MST." <199704022302.QAA14842@phaeton.artisoft.com> Date: Wed, 02 Apr 1997 16:08:14 -0800 Message-ID: <18413.860026094@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > I am here to work on a platform which provides me the ability to > do further research. I am not here to be your code supermarket. And if you're not here to work on that project in a way which is at all compatible with the way everyone else works on that project, and we've talked about this issue time and time again until I was blue over it, then maybe you'd better go hunting for another platform since your work is *never* going to make it in and we're just wasting our time discussing the very existance of that work. One would think that 2 years would be long enough to get the point. I guess with some people it just takes longer (or harder walls). Jordan From owner-freebsd-current Wed Apr 2 16:35:23 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id QAA10381 for current-outgoing; Wed, 2 Apr 1997 16:35:23 -0800 (PST) Received: from scds.ziplink.net (scds.ziplink.net [206.15.128.34]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id QAA10362 for ; Wed, 2 Apr 1997 16:35:07 -0800 (PST) Received: (from jseger@localhost) by scds.ziplink.net (8.8.5/8.8.4) id TAA06671 for current@freebsd.org; Wed, 2 Apr 1997 19:46:14 GMT Date: Wed, 2 Apr 1997 19:46:14 GMT From: "Justin M. Seger" Message-Id: <199704021946.TAA06671@scds.ziplink.net> To: current@freebsd.org Subject: Where are the src-cur and ports-cur CTM distributions stored? Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Subject says it all, thanks in advance. -Justin Seger- From owner-freebsd-current Wed Apr 2 16:39:40 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id QAA10770 for current-outgoing; Wed, 2 Apr 1997 16:39:40 -0800 (PST) Received: from noc.msc.edu (noc.msc.edu [137.66.12.254]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id QAA10765 for ; Wed, 2 Apr 1997 16:39:38 -0800 (PST) Received: from uc.msc.edu by noc.msc.edu (5.65/MSC/v3.0.1(920324)) id AA02576; Wed, 2 Apr 97 18:39:29 -0600 Received: from pobox.com (fergus-11.dialup.prtel.com [206.10.99.141]) by uc.msc.edu (8.7.5/8.6.6) with ESMTP id SAA28698; Wed, 2 Apr 1997 18:39:30 -0600 (CST) Received: (from alk@localhost) by pobox.com (8.8.5/8.7.3) id SAA00807; Wed, 2 Apr 1997 18:39:02 -0600 (CST) Date: Wed, 2 Apr 1997 18:39:02 -0600 (CST) Reply-To: alk@pobox.com Message-Id: <199704030039.SAA00807@pobox.com> From: Tony Kimball Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: current@freebsd.org Cc: dfr@nlsystems.com, archie@whistle.com Subject: Re: Anyone familiar with iijppp NFS failures? References: <199703282158.VAA00548@compound.east.sun.com> X-Face: O9M"E%K;(f-Go/XDxL+pCxI5*gr[=FN@Y`cl1.Tn Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Thanks to all responders. iijppp seems to set the MTU to 600 every time I negotiated with a certain specific uAnnex. Adding an ifconfig tun0 mtu 1500 to ppp.linkup does the trick. From owner-freebsd-current Wed Apr 2 16:45:58 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id QAA11164 for current-outgoing; Wed, 2 Apr 1997 16:45:58 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.50]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id QAA11155; Wed, 2 Apr 1997 16:45:51 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id RAA15056; Wed, 2 Apr 1997 17:28:35 -0700 From: Terry Lambert Message-Id: <199704030028.RAA15056@phaeton.artisoft.com> Subject: Re: ufs lock panic in -current To: jkh@time.cdrom.com (Jordan K. Hubbard) Date: Wed, 2 Apr 1997 17:28:35 -0700 (MST) Cc: terry@lambert.org, phk@critter.dk.tfs.com, ache@nagual.ru, dyson@FreeBSD.ORG, bde@zeta.org.au, current@FreeBSD.ORG In-Reply-To: <18413.860026094@time.cdrom.com> from "Jordan K. Hubbard" at Apr 2, 97 04:08:14 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > I am here to work on a platform which provides me the ability to > > do further research. I am not here to be your code supermarket. > > And if you're not here to work on that project in a way which is at > all compatible with the way everyone else works on that project, and > we've talked about this issue time and time again until I was blue > over it, then maybe you'd better go hunting for another platform since > your work is *never* going to make it in and we're just wasting our > time discussing the very existance of that work. Who else do you treat as a supermarket, where their whole sources must be laid out for you to pick and choose what you want, without regard to how your choices impact their own ability to use the resulting code base for their own research? Other than CSRG, NetBSD, OpenBSD, and occasionally Linux, I mean... > One would think that 2 years would be long enough to get the point. I > guess with some people it just takes longer (or harder walls). One would think that 2 years would be long enough to earn citizenship rights. You don't make these requirements of your other contributors. 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 Apr 2 16:50:59 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id QAA11602 for current-outgoing; Wed, 2 Apr 1997 16:50:59 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.50]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id QAA11575; Wed, 2 Apr 1997 16:50:44 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id RAA15079; Wed, 2 Apr 1997 17:34:21 -0700 From: Terry Lambert Message-Id: <199704030034.RAA15079@phaeton.artisoft.com> Subject: Re: Let's stop breaking current for a couple of weeks. To: jhs@FreeBSD.ORG Date: Wed, 2 Apr 1997 17:34:21 -0700 (MST) Cc: current@FreeBSD.ORG, shocking@mailbox.uq.edu.au In-Reply-To: <199704022357.BAA13237@vector.jhs.no_domain> from "Julian H. Stacey" at Apr 3, 97 01:57:15 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > Like numerous others I dumped current & dropped back to a Release because > I couldn't stand the recently constantly volatile broken current. > Lite2 needs to go in, but as we've seen people asking > other folks to sync other diffs to current, & getting the response > ~"No. current is too volatile just now, wait till it calms down"~ ..... I'm in exactly the same boat, only current is never calm enough for anything but a piece at a time because the review requirements are so strict (funny, the LKM and SYSINIT code went in fast enough...). I have also compromised on the "broken as hell" and "we can't see the relationship" issues... perhaps we will see something come of this still, despite Jordan's rantings about getting everything at once so he can pick and choose. 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 Apr 2 16:53:49 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id QAA11824 for current-outgoing; Wed, 2 Apr 1997 16:53:49 -0800 (PST) Received: from mercury.uniserve.com (mercury.uniserve.com [204.191.197.248]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id QAA11813; Wed, 2 Apr 1997 16:53:46 -0800 (PST) Received: from haven.uniserve.com (haven.uniserve.com [198.53.215.121]) by mercury.uniserve.com (8.8.2/8.8.2) with SMTP id QAA13088; Wed, 2 Apr 1997 16:49:33 -0800 (PST) Date: Wed, 2 Apr 1997 16:59:24 -0800 (PST) From: Tom Samplonius To: "Julian H. Stacey" cc: current@FreeBSD.ORG, shocking@mailbox.uq.edu.au Subject: Re: Let's stop breaking current for a couple of weeks. In-Reply-To: <199704022357.BAA13237@vector.jhs.no_domain> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Thu, 3 Apr 1997, Julian H. Stacey wrote: ... > There've been a few "I survived a make world" claims lately .. but not many > in a long time. Current needs to be less unstable for a while, so refugees > can return to it from their Release temporary havens. You don't need to revent to a release, you can use RELENG_2_2 instead, which is maintained well, and is not broken most of the time. Tom From owner-freebsd-current Wed Apr 2 17:00:18 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id RAA12247 for current-outgoing; Wed, 2 Apr 1997 17:00:18 -0800 (PST) Received: from proxy2.ba.best.com (root@proxy2.ba.best.com [206.184.139.13]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id RAA12238; Wed, 2 Apr 1997 17:00:15 -0800 (PST) Received: from bsampley.vip.best.com (bsampley.vip.best.com [206.184.160.196]) by proxy2.ba.best.com (8.8.5/8.8.3) with SMTP id QAA12661; Wed, 2 Apr 1997 16:46:35 -0800 (PST) Date: Wed, 2 Apr 1997 16:45:02 -0800 (PST) From: Burton Sampley To: Adam Hawks cc: questions@FreeBSd.ORG, current@FreeBSd.ORG Subject: RE: more problems w/ fetchmail In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@FreeBSd.ORG X-Loop: FreeBSD.org Precedence: bulk On Wed, 2 Apr 1997, Adam Hawks wrote: > I have 3.0-current running and have similar problems. If its doing the > same thing as mine you can look at your routeing table and you will > probably notice that the default route points to your gateway then there > is a route from you gateway to your 127.0.0.1 when it works and not > there when if fails. It seems that in fetchmail wants to loopback but is > sending it to the gateway address instead of the 127.0.0.1 loopback. I > don't know much about the way the mail system works so it may be in the > kernel or fetchmail? > > Don't know if this helps but its what I have observed on my system. > > Adam W. Hawks > awhawks@perigee.net > > Thanks for the reply. As strange as this may seem, I just happen to have a xterm open with netstat -r before I started routed. I see exactly what you mean. I'm going to cc this message to both groups and see if anybody has a solution. Here's the info: bash# netstat -r Routing tables Internet: Destination Gateway Flags Refs Use Netif Expire default ns3.best.com UGSc 4 0 tun0 localhost localhost UH 0 0 lo0 192.168.1 link#1 UC 0 0 ns3.best.com bsampley UH 5 10 tun0 bash# routed bash# kill 1733 [routed] bash# netstat -r Routing tables Internet: Destination Gateway Flags Refs Use Netif Expire default ns3.best.com UGSc 4 0 tun0 localhost localhost UH 0 225 lo0 192.168.1 link#1 UC 0 0 ns3.best.com bsampley UH 5 124 tun0 bsampley localhost UH 0 199 lo0 bash# Anybody know what I need to change so the routing table looks liks the second version without having to run and kill routed? --- Brought to you by a 100% Micro$oft free system. You too can disinfect your system at http://www.freebsd.org E-Mail: burton@bsampley.vip.best.com Alternate E-Mail: bsampley@haywire.csuhayward.edu Home Page: http://www.best.com/~bsampley (permanently under construction) From owner-freebsd-current Wed Apr 2 17:20:33 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id RAA14356 for current-outgoing; Wed, 2 Apr 1997 17:20:33 -0800 (PST) Received: from time.cdrom.com (root@time.cdrom.com [204.216.27.226]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id RAA14349; Wed, 2 Apr 1997 17:20:08 -0800 (PST) Received: from time.cdrom.com (jkh@localhost [127.0.0.1]) by time.cdrom.com (8.8.5/8.6.9) with ESMTP id RAA18690; Wed, 2 Apr 1997 17:18:53 -0800 (PST) To: Terry Lambert cc: phk@critter.dk.tfs.com, ache@nagual.ru, dyson@FreeBSD.ORG, bde@zeta.org.au, current@FreeBSD.ORG Subject: Re: ufs lock panic in -current In-reply-to: Your message of "Wed, 02 Apr 1997 17:28:35 MST." <199704030028.RAA15056@phaeton.artisoft.com> Date: Wed, 02 Apr 1997 17:18:52 -0800 Message-ID: <18686.860030332@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > Who else do you treat as a supermarket, where their whole sources > must be laid out for you to pick and choose what you want, without > regard to how your choices impact their own ability to use the > resulting code base for their own research? > > Other than CSRG, NetBSD, OpenBSD, and occasionally Linux, I mean... If you're going to continue with the slippery conversational gambits then I'm here to tell you that we're not going to get anywhere at all with this. Oh sure, we can continue to fence and parry and try to impress everyone on -current with our debating skills, but it's not going to get us any closer to determining the Real Truth(tm) about why Terry's code is not getting in the tree. You know darn well that I'm not asking you to be a Coding K-Mart just as you know darn well why you don't have commit privileges (or "citizenship", to use your term) after 2 years, this wide-eyed "gosh I just don't know what their problem is" act starting to get just a mite stale. The power to change all of this has always rested squarely in your hands, and I've taken out time and energy on more than one occasion to send you multi-page letters describing exactly how things work and what we expect from someone who wants to work on FreeBSD's kernel and general infrastructure in the areas you're wishing to get involved in. These letters did no good whatsoever. I've pointed to numerous counter-examples to your claims about how The System Itself Must Be Flawed If It Can't Accomodate A Lambert, demonstrating time and again that numerous *other* developers, coming along well after your arrival, had walked easily over the very same bar you were claiming was above head-height and unreasonably placed. You continue to contend that we're the unreasonable ones here as even more committers join the project each day. Face it, Terry, you're a stubborn cuss and you want the project to revolve around you, you have no interest in being a sattelite in someone else's orbit or you would have *adapted* to team player status in the very same ways that the other 70+ people currently on the CVS committers list have. You would have been working to establish bonds of trust rather than dictating from the pulpit, or maybe you would have been just slightly more strategic in taking over an obscure utility and getting commit privs on that basis (and you need only look to the existing roster for many working examples of that), expanding your role from there as you and the other committer/core members became more familiar with one another's work methods rather than demanding the keys to the safe on your first day at the job. You could have done any number of things, in fact, but you didn't because success at *joining* wasn't really what you had in mind - you just wanted to get close enough so that the occasional thrown rock would have a better chance of scoring, maybe, damned if I understand your actual motivation here. :-) NetBSD has its Chris Demetriou, I guess we have our Terry Lambert * Why not just admit that you like the role of being FreeBSD's Phillis Shaffley (if I spelled her name correctly) and revel openly in it? You don't want to become part of the project, that would spoil all your fun. :-) Jordan * And no other comparison between Chris & Terry except their respective "gadfly" roles intended or implied - you may put your gun away now Chris, thank you. From owner-freebsd-current Wed Apr 2 17:26:08 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id RAA14715 for current-outgoing; Wed, 2 Apr 1997 17:26:08 -0800 (PST) Received: from rocky.mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id RAA14702 for ; Wed, 2 Apr 1997 17:26:04 -0800 (PST) Received: (from nate@localhost) by rocky.mt.sri.com (8.7.5/8.7.3) id SAA18652; Wed, 2 Apr 1997 18:22:16 -0700 (MST) Date: Wed, 2 Apr 1997 18:22:16 -0700 (MST) Message-Id: <199704030122.SAA18652@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: jkh@time.cdrom.com (Jordan K. Hubbard), phk@critter.dk.tfs.com, current@freebsd.org Subject: Terry's changes (was Re: ufs lock panic in -current) In-Reply-To: <199704022302.QAA14842@phaeton.artisoft.com> References: <18006.860021091@time.cdrom.com> <199704022302.QAA14842@phaeton.artisoft.com> X-Mailer: VM 6.22 under 19.15 XEmacs Lucid Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > > Pretty clearly, I'm going to have to redo them all, now that the > > > target has moved. I did this once already for the changes I already > > > sent to Julian. > > > > No, no, just upload them *now* please! .. > > Please, just take phk up > > on his offer and ** upload your changes *** so that we can maybe even > > get *past* this "2 year's worth of delay" you keep talking about. > > Don't make it 3 years through your own initiative now, eh? :-) ... > I'd rather not have you exercise "editorial license" to remove what > you see as "unrelated and useless changes" and what I see as necessary > support infrastructure for what I want to do next. So, the bottom line is that you aren't willing to submit changes to anyone unless they follow what you do with them. How is that any different from the GPL, which you claim is a bad thing. If your changes are indeed 'worthwhile', they'll stand on their own merit, even if they are indented and run through an obfuscator first. If they aren't, then they are worthless. > That is, I'd rather you didn't prevent me from doing what I want to > do next because you aren't willing to spend the time to find out > where I'm headed. As you are so fond of saying, even if we take *portions* of them into our tree, you are still better off since it means less work for you to integrate them. So, either you're willing to *submit* changes to the FreeBSD tree, or you're only willing to *control* the FreeBSD source tree (which you don't have control over and it bothers you to no end.) You're either a submitter or the kernel architect, and David's not going to give that up (nor does anyone want him to give it up.) > I am here to work on a platform which provides me the ability to > do further research. I am not here to be your code supermarket. Then quit bitching about FreeBSD not accepting your patches. You've been asked to provide them in an 'easy to vend' manner, and you've refused stating it's too much work. Then, PHK and others have stated, upload your whole store, and you're unwilling to do that either. There is no in-between ground, since neither piece-meal nor lock-stock-and-barrel *submissions* are acceptable to you. So, refrain from saying anything and you can unsubscribe yourself to the FreeBSD lists and go start TerryBSD where you have complete freedom to be your own kernel architect. However, if you change your mind, there are people willing to *integrate* your patches in the tree in some fashion if you allow them editorial privilege. That's the price you pay for being a submitter. Nate From owner-freebsd-current Wed Apr 2 17:42:30 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id RAA15462 for current-outgoing; Wed, 2 Apr 1997 17:42:30 -0800 (PST) Received: from rocky.mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id RAA15455 for ; Wed, 2 Apr 1997 17:42:22 -0800 (PST) Received: (from nate@localhost) by rocky.mt.sri.com (8.7.5/8.7.3) id SAA18970; Wed, 2 Apr 1997 18:38:32 -0700 (MST) Date: Wed, 2 Apr 1997 18:38:32 -0700 (MST) Message-Id: <199704030138.SAA18970@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: jkh@time.cdrom.com (Jordan K. Hubbard), phk@critter.dk.tfs.com, current@freebsd.org Subject: Re: ufs lock panic in -current In-Reply-To: <199704030028.RAA15056@phaeton.artisoft.com> References: <18413.860026094@time.cdrom.com> <199704030028.RAA15056@phaeton.artisoft.com> X-Mailer: VM 6.22 under 19.15 XEmacs Lucid Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > Who else do you treat as a supermarket, where their whole sources > must be laid out for you to pick and choose what you want, without > regard to how your choices impact their own ability to use the > resulting code base for their own research? Every other BSD OS that has come. Every other free software project that has maintainers. Every project that has some people that 'own' it because of their salaries, responsibilities, time and effort. > > One would think that 2 years would be long enough to get the point. I > > guess with some people it just takes longer (or harder walls). > > One would think that 2 years would be long enough to earn citizenship > rights. You don't make these requirements of your other contributors. Sure we do. You've yet to show that you can 'play by the rules', and your recent temper-tantrum only shows that you haven't changed your tactics nor your willingness to work with the team. Nate From owner-freebsd-current Wed Apr 2 17:47:25 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id RAA15667 for current-outgoing; Wed, 2 Apr 1997 17:47:25 -0800 (PST) Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id RAA15643; Wed, 2 Apr 1997 17:47:17 -0800 (PST) Received: (from msmith@localhost) by genesis.atrad.adelaide.edu.au (8.8.5/8.7.3) id LAA05672; Thu, 3 Apr 1997 11:16:53 +0930 (CST) From: Michael Smith Message-Id: <199704030146.LAA05672@genesis.atrad.adelaide.edu.au> Subject: Re: writing to kernel global variables with gdb In-Reply-To: <199704022236.WAA01626@peedub.gj.org> from Gary Jennejohn at "Apr 2, 97 10:36:08 pm" To: Gary.Jennejohn@munich.netsurf.de Date: Thu, 3 Apr 1997 11:16:53 +0930 (CST) Cc: pmchen@eecs.umich.edu, freebsd-current@freebsd.org, freebsd-questions@freebsd.org X-Mailer: ELM [version 2.4ME+ PL28 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Gary Jennejohn stands accused of saying: > "Peter M. Chen" writes: > >Hi Gary, > > Joerg referred me to you as the maintainer for kgdb. I am using > >"gdb -w -k kernel.debug /dev/mem" to try to change a global variable on a > >running kernel (which Joerg thought should work), but I get > >"kvm_write:write failed". This is true even when I run as root. > > > > Any ideas? > > > > it turns out that there's already a "w" option ("use windows") > defined in main.c. There's no code which makes use of it. This code is part of gdbtk, which is also why gdb understands -nw (like emacs). > Gary Jennejohn -- ]] Mike Smith, Software Engineer msmith@gsoft.com.au [[ ]] Genesis Software genesis@gsoft.com.au [[ ]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[ ]] realtime instrument control. (ph) +61-8-8267-3493 [[ ]] Unix hardware collector. "Where are your PEZ?" The Tick [[ From owner-freebsd-current Wed Apr 2 17:50:23 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id RAA16003 for current-outgoing; Wed, 2 Apr 1997 17:50:23 -0800 (PST) Received: from parkplace.cet.co.jp (parkplace.cet.co.jp [202.32.64.1]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id RAA15987; Wed, 2 Apr 1997 17:50:18 -0800 (PST) Received: from localhost (michaelh@localhost) by parkplace.cet.co.jp (8.8.5/CET-v2.1) with SMTP id BAA01469; Thu, 3 Apr 1997 01:50:11 GMT Date: Thu, 3 Apr 1997 10:50:11 +0900 (JST) From: Michael Hancock To: "Julian H. Stacey" cc: current@freebsd.org, shocking@mailbox.uq.edu.au Subject: Re: Let's stop breaking current for a couple of weeks. In-Reply-To: <199704022357.BAA13237@vector.jhs.no_domain> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk update -dP -rRELENG_2_2 Get out of the way for little while. We don't need the developers pushed into making mistakes or stupid decisions. Regards, Mike Hancock On Thu, 3 Apr 1997, Julian H. Stacey wrote: > Subject was: Re: ufs lock panic in -current > > Hi, Reference: > > From: shocking@mailbox.uq.edu.au > > > > [The great FS patch saga deleted] > > > > Dammit, just get the blasted thing in current, where we'll beat the bugs out > > of them. If you do this, I guarantee that Terry's email bill will drop by 50% > - > > 8^) 8^). Besides, I want to see what all this transitive closure stuff looks > > like. > > > > Stephen > > _NO_ Thanks ! > Have you heard the Chinese curse: "May you live in interesting times" ? > We don't need _more_ interesting new bugs in current this week or next. > > Like numerous others I dumped current & dropped back to a Release because > I couldn't stand the recently constantly volatile broken current. > Lite2 needs to go in, but as we've seen people asking > other folks to sync other diffs to current, & getting the response > ~"No. current is too volatile just now, wait till it calms down"~ ..... > > It's time to try for intervening periods of relative calm on current, > between assualts by broken/untested/incomplete code; for if current > becomes continuous broken hell, it'll deter other contributions. > > There've been a few "I survived a make world" claims lately .. but not many > in a long time. Current needs to be less unstable for a while, so refugees > can return to it from their Release temporary havens. > > If some people just want to view or publish odd bits of code in progress, > web space does that, (EG I keep my add-ons & diffs in > http://www.freebsd.org/~jhs/src/src.html > & maintain that copy with rdist, & applicability to src/ with a shell, > & bits don't get offered for a commit until they're matured & proven benign :-) > > Please, Let's NOT _deliberately commit more broken or untested code, > unless the stuff is #ifdefed out, (or kernel optioned), or not linked in > by default, so it doesn't wreck the current operating base & deter other > people working in other unrelated current areas ! > > Thanks ! > > Julian > -- > Julian H. Stacey jhs@freebsd.org http://www.freebsd.org/~jhs/ > From owner-freebsd-current Wed Apr 2 18:41:18 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id SAA20770 for current-outgoing; Wed, 2 Apr 1997 18:41:18 -0800 (PST) Received: from lamb.sas.com (daemon@lamb.sas.com [192.35.83.8]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id SAA20761 for ; Wed, 2 Apr 1997 18:41:14 -0800 (PST) Received: from mozart by lamb.sas.com (5.65c/SAS/Gateway/01-23-95) id AA25992; Wed, 2 Apr 1997 21:40:57 -0500 Received: from iluvatar.unx.sas.com by mozart (5.65c/SAS/Domains/5-6-90) id AA19236; Wed, 2 Apr 1997 21:40:48 -0500 Received: by iluvatar.unx.sas.com (5.65c/SAS/Generic 9.01/3-26-93) id AA03513; Wed, 2 Apr 1997 21:40:47 -0500 From: "John W. DeBoskey" Message-Id: <199704030240.AA03513@iluvatar.unx.sas.com> Subject: UserMode ppp problem (updated log) To: freebsd-current@freebsd.org Date: Wed, 2 Apr 1997 21:40:47 -0500 (EST) Cc: jas@flyingfox.com X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hello, Hi again. My apologies for my previous posting which contained a bad log file. Below is the /var/log/ppp.log file which fails. Many thanks to Jim Shankland for pointing out the error of my ways. My conf file & log follow. I note that both reads from the modem start with the sequence '7e ff ff 7d', which do not match any of the sequences that ppp is looking for: ie: 7EFF03C021 7EFF7D23C021 7E7F7D234021 7E7DDF7D23C021 7E7D5F7D234021 Also, I've added some additional logging to printout the readable format of the data from the modem, which makes it easier to debug. Who should I send the diffs to? Thanks again, John default: set device dialout.net:23 set dial "TIMEOUT 2 OK-ATE1Q0-OK \\dATDT\\T TIMEOUT 25 CONNECT" set escape 0xff sasppp: set phone 9wxxxyyyy,,,zzzz set login "Login script here -- works fine" set debug phase chat connect carrier lcp lqm tcpip hdlc async link enable pap accept pap disable chap deny chap set ifaddr 192.42.243.16/32 192.42.243.1/32 set openmode active 04-02 16:14:46 [902] Connected! 04-02 16:14:46 [902] LCP: state change Initial --> Closed 04-02 16:14:46 [902] LCP: SendConfigReq 04-02 16:14:46 [902] ACFCOMP 04-02 16:14:46 [902] PROTOCOMP 04-02 16:14:46 [902] ACCMAP [6] 00000000 04-02 16:14:46 [902] MRU [4] 1500 04-02 16:14:46 [902] MAGICNUM [6] 50758b1e 04-02 16:14:46 [902] QUALPROTO (3000) 04-02 16:14:46 [902] AUTHPROTO [4] 49187 04-02 16:14:46 [902] HdlcOutput 04-02 16:14:46 [902] ff 03 c0 21 01 01 00 24 08 02 07 02 02 06 00 00 04-02 16:14:46 [902] 00 00 01 04 05 dc 05 06 50 75 8b 1e 04 08 c0 25 04-02 16:14:46 [902] 00 00 0b b8 03 04 c0 23 ee 46 04-02 16:14:46 [902] WriteModem 04-02 16:14:46 [902] 7e 7d df 7d 23 c0 21 7d 21 7d 21 7d 20 24 7d 28 ~}_}#@!}!}!} $}( 04-02 16:14:46 [902] 7d 22 7d 27 7d 22 7d 22 7d 26 7d 20 7d 20 7d 20 }"}'}"}"}&} } } 04-02 16:14:46 [902] 7d 20 7d 21 7d 24 7d 25 dc 7d 25 7d 26 50 75 8b } }!}$}%\}%}&Pu. 04-02 16:14:46 [902] 7d 3e 7d 24 7d 28 c0 25 7d 20 7d 20 7d 2b b8 7d }>}$}(@%} } }+8} 04-02 16:14:46 [902] 23 7d 24 c0 23 ee 46 7e #}$@#nF~ 04-02 16:14:46 [902] LCP: state change Closed --> Req-Sent 04-02 16:14:46 [902] ReadFromModem 04-02 16:14:46 [902] 20 73 65 74 20 70 6f 72 74 20 70 70 70 20 65 6e set port ppp en 04-02 16:14:46 [902] 61 62 6c 65 able 04-02 16:14:46 [902] ReadFromModem 04-02 16:14:46 [902] 7e ff ff 7d 23 c0 21 7d 21 7d 21 7d 20 7d 34 7d ~}#@!}!}!} }4} 04-02 16:14:46 [902] 22 7d 26 7d 20 7d 2a 7d 20 7d 20 7d 25 7d 26 7d "}&} }*} } }%}&} 04-02 16:14:46 [902] 21 7d 24 a2 6f 7d 27 7d 22 7d 28 7d 22 7d 2f 9a !}$"o}'}"}(}"}/. 04-02 16:14:46 [902] 7e ~ 04-02 16:14:46 [902] HdlcInput: 04-02 16:14:46 [902] ff ff 03 c0 21 01 01 00 14 02 06 00 0a 00 00 05 04-02 16:14:46 [902] 06 01 04 a2 6f 07 02 08 02 0f 9a 04-02 16:14:49 [902] LCP: SendConfigReq 04-02 16:14:49 [902] ACFCOMP 04-02 16:14:49 [902] PROTOCOMP 04-02 16:14:49 [902] ACCMAP [6] 00000000 04-02 16:14:49 [902] MRU [4] 1500 04-02 16:14:49 [902] MAGICNUM [6] 50758b1e 04-02 16:14:49 [902] QUALPROTO (3000) 04-02 16:14:49 [902] AUTHPROTO [4] 49187 04-02 16:14:49 [902] HdlcOutput 04-02 16:14:49 [902] ff 03 c0 21 01 02 00 24 08 02 07 02 02 06 00 00 04-02 16:14:49 [902] 00 00 01 04 05 dc 05 06 50 75 8b 1e 04 08 c0 25 04-02 16:14:49 [902] 00 00 0b b8 03 04 c0 23 a5 51 04-02 16:14:49 [902] WriteModem 04-02 16:14:49 [902] 7e 7d df 7d 23 c0 21 7d 21 7d 22 7d 20 24 7d 28 ~}_}#@!}!}"} $}( 04-02 16:14:49 [902] 7d 22 7d 27 7d 22 7d 22 7d 26 7d 20 7d 20 7d 20 }"}'}"}"}&} } } 04-02 16:14:49 [902] 7d 20 7d 21 7d 24 7d 25 dc 7d 25 7d 26 50 75 8b } }!}$}%\}%}&Pu. 04-02 16:14:49 [902] 7d 3e 7d 24 7d 28 c0 25 7d 20 7d 20 7d 2b b8 7d }>}$}(@%} } }+8} 04-02 16:14:49 [902] 23 7d 24 c0 23 a5 51 7e #}$@#%Q~ 04-02 16:14:49 [902] ReadFromModem 04-02 16:14:49 [902] 7e ff ff 7d 23 c0 21 7d 21 7d 22 7d 20 7d 34 7d ~}#@!}!}"} }4} 04-02 16:14:49 [902] 22 7d 26 7d 20 7d 2a 7d 20 7d 20 7d 25 7d 26 7d "}&} }*} } }%}&} 04-02 16:14:49 [902] 21 7d 24 a2 6f 7d 27 7d 22 7d 28 7d 22 c5 27 7e !}$"o}'}"}(}"E'~ 04-02 16:14:49 [902] HdlcInput: 04-02 16:14:49 [902] ff ff 03 c0 21 01 02 00 14 02 06 00 0a 00 00 05 04-02 16:14:49 [902] 06 01 04 a2 6f 07 02 08 02 c5 27 04-02 16:14:52 [902] LCP: SendConfigReq 04-02 16:14:52 [902] ACFCOMP 04-02 16:14:52 [902] PROTOCOMP 04-02 16:14:52 [902] ACCMAP [6] 00000000 04-02 16:14:52 [902] MRU [4] 1500 04-02 16:14:52 [902] MAGICNUM [6] 50758b1e 04-02 16:14:52 [902] QUALPROTO (3000) 04-02 16:14:52 [902] AUTHPROTO [4] 49187 04-02 16:14:52 [902] HdlcOutput 04-02 16:14:52 [902] ff 03 c0 21 01 03 00 24 08 02 07 02 02 06 00 00 04-02 16:14:52 [902] 00 00 01 04 05 dc 05 06 50 75 8b 1e 04 08 c0 25 04-02 16:14:52 [902] 00 00 0b b8 03 04 c0 23 9c 5c 04-02 16:14:52 [902] WriteModem 04-02 16:14:52 [902] 7e 7d df 7d 23 c0 21 7d 21 7d 23 7d 20 24 7d 28 ~}_}#@!}!}#} $}( 04-02 16:14:52 [902] 7d 22 7d 27 7d 22 7d 22 7d 26 7d 20 7d 20 7d 20 }"}'}"}"}&} } } 04-02 16:14:52 [902] 7d 20 7d 21 7d 24 7d 25 dc 7d 25 7d 26 50 75 8b } }!}$}%\}%}&Pu. 04-02 16:14:52 [902] 7d 3e 7d 24 7d 28 c0 25 7d 20 7d 20 7d 2b b8 7d }>}$}(@%} } }+8} 04-02 16:14:52 [902] 23 7d 24 c0 23 9c 5c 7e #}$@#.\~ 04-02 16:14:53 [902] ReadFromModem 04-02 16:14:53 [902] 7e ff ff 7d 23 c0 21 7d 21 7d 23 7d 20 7d 34 7d ~}#@!}!}#} }4} 04-02 16:14:53 [902] 22 7d 26 7d 20 7d 2a 7d 20 7d 20 7d 25 7d 26 7d "}&} }*} } }%}&} 04-02 16:14:53 [902] 21 7d 24 a2 6f 7d 27 7d 22 7d 28 7d 22 8c b4 7e !}$"o}'}"}(}".4~ 04-02 16:14:53 [902] HdlcInput: 04-02 16:14:53 [902] ff ff 03 c0 21 01 03 00 14 02 06 00 0a 00 00 05 04-02 16:14:53 [902] 06 01 04 a2 6f 07 02 08 02 8c b4 04-02 16:14:55 [902] LCP: SendConfigReq 04-02 16:14:55 [902] ACFCOMP 04-02 16:14:55 [902] PROTOCOMP 04-02 16:14:55 [902] ACCMAP [6] 00000000 04-02 16:14:55 [902] MRU [4] 1500 04-02 16:14:55 [902] MAGICNUM [6] 50758b1e 04-02 16:14:55 [902] QUALPROTO (3000) 04-02 16:14:55 [902] AUTHPROTO [4] 49187 04-02 16:14:55 [902] HdlcOutput 04-02 16:14:55 [902] ff 03 c0 21 01 04 00 24 08 02 07 02 02 06 00 00 04-02 16:14:55 [902] 00 00 01 04 05 dc 05 06 50 75 8b 1e 04 08 c0 25 04-02 16:14:55 [902] 00 00 0b b8 03 04 c0 23 33 7f 04-02 16:14:55 [902] WriteModem 04-02 16:14:55 [902] 7e 7d df 7d 23 c0 21 7d 21 7d 24 7d 20 24 7d 28 ~}_}#@!}!}$} $}( 04-02 16:14:55 [902] 7d 22 7d 27 7d 22 7d 22 7d 26 7d 20 7d 20 7d 20 }"}'}"}"}&} } } 04-02 16:14:55 [902] 7d 20 7d 21 7d 24 7d 25 dc 7d 25 7d 26 50 75 8b } }!}$}%\}%}&Pu. 04-02 16:14:55 [902] 7d 3e 7d 24 7d 28 c0 25 7d 20 7d 20 7d 2b b8 7d }>}$}(@%} } }+8} 04-02 16:14:55 [902] 23 7d 24 c0 23 33 7f 7e #}$@#3.~ 04-02 16:14:57 [902] ReadFromModem 04-02 16:14:57 [902] 7e ff ff 7d 23 c0 21 7d 21 7d 24 7d 20 7d 34 7d ~}#@!}!}$} }4} 04-02 16:14:57 [902] 22 7d 26 7d 20 7d 2a 7d 20 7d 20 7d 25 7d 26 7d "}&} }*} } }%}&} 04-02 16:14:57 [902] 21 7d 24 a2 6f 7d 27 7d 22 7d 28 7d 22 40 54 7e !}$"o}'}"}(}"@T~ 04-02 16:14:57 [902] HdlcInput: 04-02 16:14:57 [902] ff ff 03 c0 21 01 04 00 14 02 06 00 0a 00 00 05 04-02 16:14:57 [902] 06 01 04 a2 6f 07 02 08 02 40 54 04-02 16:14:58 [902] LCP: SendConfigReq 04-02 16:14:58 [902] ACFCOMP 04-02 16:14:58 [902] PROTOCOMP 04-02 16:14:58 [902] ACCMAP [6] 00000000 04-02 16:14:58 [902] MRU [4] 1500 04-02 16:14:58 [902] MAGICNUM [6] 50758b1e 04-02 16:14:58 [902] QUALPROTO (3000) 04-02 16:14:58 [902] AUTHPROTO [4] 49187 04-02 16:14:58 [902] HdlcOutput 04-02 16:14:58 [902] ff 03 c0 21 01 05 00 24 08 02 07 02 02 06 00 00 04-02 16:14:58 [902] 00 00 01 04 05 dc 05 06 50 75 8b 1e 04 08 c0 25 04-02 16:14:58 [902] 00 00 0b b8 03 04 c0 23 0a 72 04-02 16:14:58 [902] WriteModem 04-02 16:14:58 [902] 7e 7d df 7d 23 c0 21 7d 21 7d 25 7d 20 24 7d 28 ~}_}#@!}!}%} $}( 04-02 16:14:58 [902] 7d 22 7d 27 7d 22 7d 22 7d 26 7d 20 7d 20 7d 20 }"}'}"}"}&} } } 04-02 16:14:58 [902] 7d 20 7d 21 7d 24 7d 25 dc 7d 25 7d 26 50 75 8b } }!}$}%\}%}&Pu. 04-02 16:14:58 [902] 7d 3e 7d 24 7d 28 c0 25 7d 20 7d 20 7d 2b b8 7d }>}$}(@%} } }+8} 04-02 16:14:58 [902] 23 7d 24 c0 23 7d 2a 72 7e #}$@#}*r~ 04-02 16:15:01 [902] LCP: state change Req-Sent --> Stopped 04-02 16:15:01 [902] LCP: LayerFinish 04-02 16:15:01 [902] Phase: Dead 04-02 16:20:30 [902] PPP Terminated. From owner-freebsd-current Wed Apr 2 18:59:01 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id SAA21245 for current-outgoing; Wed, 2 Apr 1997 18:59:01 -0800 (PST) Received: from fsp.fsp.com ([157.134.205.1]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id SAA21240 for ; Wed, 2 Apr 1997 18:58:58 -0800 (PST) Received: from boole.fsp.com by fsp.fsp.com (5.65/1.35) id AA06459; Wed, 2 Apr 97 21:59:20 -0500 Message-Id: <3343CC2D.EE@fsp.fsp.com> Date: Thu, 03 Apr 1997 10:26:37 -0500 From: Thomas Kellar Organization: Freelance Systems Programming X-Mailer: Mozilla 3.0 (Win95; I) Mime-Version: 1.0 To: freebsd-current@FreeBSD.ORG Subject: (no subject) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk subscribe freebsd-current subscribe cvs-all From owner-freebsd-current Wed Apr 2 19:12:58 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id TAA22026 for current-outgoing; Wed, 2 Apr 1997 19:12:58 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.50]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id TAA22018; Wed, 2 Apr 1997 19:12:48 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id TAA15269; Wed, 2 Apr 1997 19:54:55 -0700 From: Terry Lambert Message-Id: <199704030254.TAA15269@phaeton.artisoft.com> Subject: Re: ufs lock panic in -current To: jkh@time.cdrom.com (Jordan K. Hubbard) Date: Wed, 2 Apr 1997 19:54:55 -0700 (MST) Cc: terry@lambert.org, phk@critter.dk.tfs.com, ache@nagual.ru, dyson@FreeBSD.ORG, bde@zeta.org.au, current@FreeBSD.ORG In-Reply-To: <18686.860030332@time.cdrom.com> from "Jordan K. Hubbard" at Apr 2, 97 05:18:52 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > If you're going to continue with the slippery conversational gambits > then I'm here to tell you that we're not going to get anywhere at all > with this. Oh sure, we can continue to fence and parry and try to > impress everyone on -current with our debating skills, but it's not > going to get us any closer to determining the Real Truth(tm) about why > Terry's code is not getting in the tree. Julian has my namei/nameifree and "EXCLUDE" NDINIT() op redundant code reduction changes. Feel free to commit them. I just sent you (posted) some Logical Name support code. Feel free to commit that. > You know darn well that I'm not asking you to be a Coding K-Mart just > as you know darn well why you don't have commit privileges (or > "citizenship", to use your term) after 2 years, this wide-eyed "gosh I > just don't know what their problem is" act starting to get just a mite > stale. I did not use the euphamism "citizenship" to refer to "commit priviledges", I used it to refer to you not applying the same citeria to me as you do to other developers. You keep suggesting that I should upload my complete patches for my working code set (which are based on a snapshot from June of 1994). These patches were already deemed "unsuitable". I respectfully suggest you take the patches that I have updated to meet your standards of suitability, and forget about those which you deem "unsuitable". I have already shown a willingness to meet your criteria, and there is no need for you to publically appear willing to accept patches which you have already rejected (since my patches applied against the tree date specified applied cleanly and would result in the same source tree you are suggesting that I upload). > The power to change all of this has always rested squarely in > your hands, and I've taken out time and energy on more than one > occasion to send you multi-page letters describing exactly how things > work and what we expect from someone who wants to work on FreeBSD's > kernel and general infrastructure in the areas you're wishing to get > involved in. These letters did no good whatsoever. Because you have failed to provide a set of criteria which I can apply to a design to determine if the results of the design would meet the criteria. Richard and others have found themselves in the same boat. > I've pointed to > numerous counter-examples to your claims about how The System Itself > Must Be Flawed If It Can't Accomodate A Lambert, demonstrating time > and again that numerous *other* developers, coming along well after > your arrival, had walked easily over the very same bar you were > claiming was above head-height and unreasonably placed. I have never made the flaw claims in the way you state. I have made organizational flaw claims where I believed they were valid. I have made no "bar" claims except where you were not uniformly applying, or simply not disclosing (making it impossible to judge uniformity of application) your standards. > You continue to contend that we're the unreasonable ones here as > even more committers join the project each day. While I was a USL employee, I specifically *declined* commit priviledges. Then you took the *ALPHA* SYSINIT() code and integrated, complaining bitterly about my use of goto's in "production code", and marking me a coding pariah ever since. > Face it, Terry, you're a stubborn cuss and you want the project to > revolve around you, you have no interest in being a sattelite in > someone else's orbit or you would have *adapted* to team player status > in the very same ways that the other 70+ people currently on the CVS > committers list have. This is total and utter bullshit. I could care less if the project revolved around me, you, or Uranus. All I care is that the project be the best project it can be, and meet its stated "research platform" goals because I would find a research platform that actually met those goals useful. I would like to do SMP, FS, and kernel multithreading research. The project as it stands is unsuitable for that task because you do not meet your own stated goals. Everything is a "work in progress" and you never reach a useful destination. The patches I have submitted so far (and the code which I have submitted and which you *HAVE* integrated) are nothing to me. They are changes necessary to make FreeBSD as useful research vehicle, nothing more. The utility of the changes are independent of whether I ustilize this vehicle, or others do so: their value is independent of "Accommodate A Lambert". Yes, I would prefer that I not have to drag my changes along from one of your revisions to the next. But I have suitable cuts of the FreeBSD code which will allow me to pursue the avenues of research which I want to pursue at the moment. I am content to submit changes in piecemeal fashion so that when I discover the next avenue I wish to pursue, FreeBSD will be ready for it. > You would have been working to establish bonds of trust rather > than dictating from the pulpit, Bogus and argumentative. > or maybe you would have been just slightly more strategic in > taking over an obscure utility and getting commit privs on > that basis s/strategic/dishonest/ s/basis/false pretense/ I, sir, have a bit more honor than that. > You > could have done any number of things, in fact, but you didn't because > success at *joining* wasn't really what you had in mind - you just > wanted to get close enough so that the occasional thrown rock would > have a better chance of scoring, maybe, damned if I understand your > actual motivation here. :-) This is because you engage in amateur psychology, under the pretense that we are "fencing" with "slippery conversational gambits", rather than *reading* what I have *stated* are my motivations. There was no need for you to cause this discussion to deteriorate into a public head-bashing instead of taking it to private email, unless your intent was to take the opportunity presented to skewer me on you rapier wit yet again, instead of forthwrightly stating and disposing the issues. Frankly, if you spent as much time in reasoned discussion as you do honing your sword on the bones of your victims, we would no longer have any differences to speak to: we would agree where we agreed, and we would agree to disagree where we did not, and that would be the end of it. > Why not just admit that you like the role of being FreeBSD's Phillis > Shaffley (if I spelled her name correctly) and revel openly in it? > You don't want to become part of the project, that would spoil all > your fun. :-) I am uninterested in being the subject of your head-bashing. If you have an issue with me personally, take it to private email. But drop the "publically wronged hero" act. Review the patches sent Julian. If you don't like them, tell me why so I can correct them and you can commite them, and I will send more patches. If you do like them, commit them, and I will send more patches. This is the very simple formula for getting code out of "A Lambert". Judge the code, not the coder. That's all I've ever wanted from the project as a whole, and it seems to me that it's not an unreasonable expectation. 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 Apr 2 19:28:19 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id TAA22544 for current-outgoing; Wed, 2 Apr 1997 19:28:19 -0800 (PST) Received: from bunyip.cc.uq.edu.au (daemon@bunyip.cc.uq.edu.au [130.102.2.1]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id TAA22534 for ; Wed, 2 Apr 1997 19:28:09 -0800 (PST) Received: (from daemon@localhost) by bunyip.cc.uq.edu.au (8.8.5/8.8.5) id NAA16622 for current@freebsd.org; Thu, 3 Apr 1997 13:27:15 +1000 Received: from maya.devetir.qld.gov.au by ogre.dtir.qld.gov.au (8.7.5/DEVETIR-E0.3a) with ESMTP id LAA08612 for ; Thu, 3 Apr 1997 11:43:56 +1000 (EST) Received: from netfl15a.devetir.qld.gov.au (netfl15a.devetir.qld.gov.au [167.123.24.12]) by maya.devetir.qld.gov.au (8.8.5/8.8.5) with SMTP id LAA05795 for ; Thu, 3 Apr 1997 11:40:09 +1000 (EST) Received: from localhost by netfl15a.devetir.qld.gov.au (8.6.8.1/DEVETIR-0.1) id BAA04433 for ; Thu, 3 Apr 1997 01:42:56 GMT Message-Id: <199704030142.BAA04433@netfl15a.devetir.qld.gov.au> X-Mailer: exmh version 2.0beta 12/23/96 To: current@freebsd.org Subject: POLL & the Single FreeBSD'r X-Face: 3}heU+2?b->-GSF-G4T4>jEB9~FR(V9lo&o>kAy=Pj&;oVOc<|pr%I/VSG"ZD32J>5gGC0N 7gj]^GI@M:LlqNd]|(2OxOxy@$6@/!,";-!OlucF^=jq8s57$%qXd/ieC8DhWmIy@J1AcnvSGV\|*! >Bvu7+0h4zCY^]{AxXKsDTlgA2m]fX$W@'8ev-Qi+-;%L'CcZ'NBL!@n?}q!M&Em3*eW7,093nOeV8 M)(u+6D;%B7j\XA/9j4!Gj~&jYzflG[#)E9sI&Xe9~y~Gn%fA7>F:YKr"Wx4cZU*6{^2ocZ!YyR Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 03 Apr 1997 11:42:54 +1000 From: Stephen Hocking Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I note that NetBSD has had the poll system call for some time. Are there any plans to integrate one of the few nice SYSV'isms into FreeBSD (it would make porting some code a snap). Stephen -- The views expressed above are not those of WorkCover Queensland, Australia. "We've heard that a million monkeys at a million keyboards could produce the Complete Works of Shakespeare; now, thanks to the Internet, we know this is not true." Robert Wilensky, University of California From owner-freebsd-current Wed Apr 2 19:36:38 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id TAA22923 for current-outgoing; Wed, 2 Apr 1997 19:36:38 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.50]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id TAA22918 for ; Wed, 2 Apr 1997 19:36:35 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id UAA15340; Wed, 2 Apr 1997 20:18:54 -0700 From: Terry Lambert Message-Id: <199704030318.UAA15340@phaeton.artisoft.com> Subject: Re: Terry's changes (was Re: ufs lock panic in -current) To: nate@mt.sri.com (Nate Williams) Date: Wed, 2 Apr 1997 20:18:54 -0700 (MST) Cc: terry@lambert.org, jkh@time.cdrom.com, phk@critter.dk.tfs.com, current@freebsd.org In-Reply-To: <199704030122.SAA18652@rocky.mt.sri.com> from "Nate Williams" at Apr 2, 97 06:22:16 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > I'd rather not have you exercise "editorial license" to remove what > > you see as "unrelated and useless changes" and what I see as necessary > > support infrastructure for what I want to do next. > > So, the bottom line is that you aren't willing to submit changes to > anyone unless they follow what you do with them. How is that any > different from the GPL, which you claim is a bad thing. I am willing to submit changes in small enough increments that you will be able to understand them as a coherent whole. This is not an unwillingness to submit changes, it's an unwillingness to defend my view of a coherent whole vs. your view of a coherent whole. > If your changes are indeed 'worthwhile', they'll stand on their own > merit, even if they are indented and run through an obfuscator first. > > If they aren't, then they are worthless. So you, too, review the changes I sent to Julian. Make comments on them, not comments on me. > > That is, I'd rather you didn't prevent me from doing what I want to > > do next because you aren't willing to spend the time to find out > > where I'm headed. > > As you are so fond of saying, even if we take *portions* of them into > our tree, you are still better off since it means less work for you to > integrate them. It depends on what you consider "trivial and unrelated" vs. what I consider "trivial and unrelated". As I stated to Jordan, my suggested changes are not an end, but a means to an end. I only submit them at all to increase FreeBSD's utility in helping me pursue my end. Most code submissions fit this description. > So, either you're willing to *submit* changes to the FreeBSD tree, or > you're only willing to *control* the FreeBSD source tree (which you > don't have control over and it bothers you to no end.) No. I am willing to submit changes in small enough increments that you will be able to understand them as a coherent whole. This means I'm not going to give you everything at once, because I have already done so once, and you failed to understand them as a coherent whole. When that happens, I risk losing rungs on an incremental ladder. Rungs which I need to do my own research. I have now demonstrated a willingness to submit the rungs one at a time so that you can judge them on their individual merit. > Then quit bitching about FreeBSD not accepting your patches. You've > been asked to provide them in an 'easy to vend' manner, and you've > refused stating it's too much work. This is bullshit. Ask Julian for copies of 'easy to vend' patches. > Then, PHK and others have stated, upload your whole store, and > you're unwilling to do that either. Yes, I am unwilling to upload the whole store, unless you are willing to discuss the intent of changes I have made before you draw conclusions about the utility of the changes with no input from me but the changes themselves. I would like to be permitted to defend my design decisions... but I do not demand that that defense result in you agreeing with me, only that you make no comments on coherency until you have asked questions and heard out my answers. > There is no in-between ground, since neither piece-meal nor > lock-stock-and-barrel *submissions* are acceptable to you. Again, check with Julian. He has a piece-meal submission, and has had since before the Lite2 integration began. Jeffrey Hsu had a system running with "lock-stock-and-barrel" much earlier than that, so it's not as if the "lock-stock-and-barrel" patches were unusable as provided in final form. > However, if you change your mind, there > are people willing to *integrate* your patches in the tree in some > fashion if you allow them editorial privilege. That's the price you pay > for being a submitter. Feel free to take editorial license with the patches I have submitted through Julian. They are small enough in scope that your doing so will not damage my ability to use the resulting code base for my own future research (the purpose of their submission is to provide facilities and interfaces sufficient for what this research requires; if this is naievely deemed selfish, so be it). I am willing to submit additional piece-meal patches on the same terms for as long as you want to review them, and as long as it continues to suit me to do so. 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 Apr 2 19:39:01 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id TAA23006 for current-outgoing; Wed, 2 Apr 1997 19:39:01 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.50]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id TAA23001 for ; Wed, 2 Apr 1997 19:38:56 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id UAA15361; Wed, 2 Apr 1997 20:20:08 -0700 From: Terry Lambert Message-Id: <199704030320.UAA15361@phaeton.artisoft.com> Subject: Re: ufs lock panic in -current To: nate@mt.sri.com (Nate Williams) Date: Wed, 2 Apr 1997 20:20:08 -0700 (MST) Cc: terry@lambert.org, jkh@time.cdrom.com, phk@critter.dk.tfs.com, current@freebsd.org In-Reply-To: <199704030138.SAA18970@rocky.mt.sri.com> from "Nate Williams" at Apr 2, 97 06:38:32 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > Sure we do. You've yet to show that you can 'play by the rules', and > your recent temper-tantrum only shows that you haven't changed your > tactics nor your willingness to work with the team. I respectfully suggest you reexamine this thread for the origins of the "tantrum". 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 Apr 2 19:52:59 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id TAA23625 for current-outgoing; Wed, 2 Apr 1997 19:52:59 -0800 (PST) Received: from palrel1.hp.com (palrel1.hp.com [15.253.72.10]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id TAA23609 for ; Wed, 2 Apr 1997 19:52:46 -0800 (PST) Received: from fakir.india.hp.com (fakir.india.hp.com [15.10.40.3]) by palrel1.hp.com with ESMTP (8.7.5/8.7.3) id TAA24381; Wed, 2 Apr 1997 19:52:40 -0800 (PST) Received: from localhost by fakir.india.hp.com with SMTP (1.37.109.20/15.5+ECS 3.3) id AA299151399; Thu, 3 Apr 1997 09:23:19 +0500 Message-Id: <199704030423.AA299151399@fakir.india.hp.com> To: Peter Dufault Cc: freebsd-current@freebsd.org Subject: Re: Internal clock In-Reply-To: Your message of "Tue, 01 Apr 1997 13:42:03 EST." Date: Thu, 03 Apr 1997 09:23:19 +0500 From: "A JOSEPH KOSHY" Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >>>> "Peter Dufault" writes > > Jukka Ukonnen's patches were passed around by Jordan on -hackers, > > and I think sent to gnats around Christmas, so they should be Shortly after the patches had been sent out I had folded them into the then -current tree (Dec/Jan); the original patches were against 2.1.5 I think. They were working fine under the limited testing I had done then. The Lite2 merge has touched many of the same files that the patches affected, so I plan to redo this effort sometime in the (near?) future. I'm still catching up with Lite2. Koshy My Personal Opinions Only. From owner-freebsd-current Wed Apr 2 19:53:42 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id TAA23663 for current-outgoing; Wed, 2 Apr 1997 19:53:42 -0800 (PST) Received: from rocky.mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id TAA23658 for ; Wed, 2 Apr 1997 19:53:39 -0800 (PST) Received: (from nate@localhost) by rocky.mt.sri.com (8.7.5/8.7.3) id UAA19501; Wed, 2 Apr 1997 20:49:54 -0700 (MST) Date: Wed, 2 Apr 1997 20:49:54 -0700 (MST) Message-Id: <199704030349.UAA19501@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), jkh@time.cdrom.com, phk@critter.dk.tfs.com, current@freebsd.org Subject: Re: Terry's changes (was Re: ufs lock panic in -current) In-Reply-To: <199704030318.UAA15340@phaeton.artisoft.com> References: <199704030122.SAA18652@rocky.mt.sri.com> <199704030318.UAA15340@phaeton.artisoft.com> X-Mailer: VM 6.22 under 19.15 XEmacs Lucid Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > > I'd rather not have you exercise "editorial license" to remove what > > > you see as "unrelated and useless changes" and what I see as necessary > > > support infrastructure for what I want to do next. > > > > So, the bottom line is that you aren't willing to submit changes to > > anyone unless they follow what you do with them. How is that any > > different from the GPL, which you claim is a bad thing. > > I am willing to submit changes in small enough increments that you > will be able to understand them as a coherent whole. This is not > an unwillingness to submit changes, it's an unwillingness to defend > my view of a coherent whole vs. your view of a coherent whole. Where are these patches? I've never seen them, and neither has anyone else who is willing to commit them. Julian hasn't done anything with them, and you never submitted them for public use. > So you, too, review the changes I sent to Julian. Make comments on > them, not comments on me. I can't, Julian is on his way back to Australia. > No. I am willing to submit changes in small enough increments that > you will be able to understand them as a coherent whole. Where are the PR's? > This means I'm not going to give you everything at once, because > I have already done so once, and you failed to understand them > as a coherent whole. Who is this 'ethereal' 'you'? You certainly didn't make them available publically. > When that happens, I risk losing rungs on > an incremental ladder. Rungs which I need to do my own research. How can making your code available be determinental to you? Revealing information a little bit at a time or in one huge chunk is still revealing the same information. > I have now demonstrated a willingness to submit the rungs one at > a time so that you can judge them on their individual merit. Where are the PR's. > > Then quit bitching about FreeBSD not accepting your patches. You've > > been asked to provide them in an 'easy to vend' manner, and you've > > refused stating it's too much work. > > This is bullshit. Ask Julian for copies of 'easy to vend' patches. Julian != FreeBSD. Julian is one person. Submit them via a public medium, so that you can't state that *everyone* is ignoring you and your patches. If they're valid, they'll stand on their own merit and then your claim that you are being ignored by the FreeBSD project, when in fact you've never submitted your patches to the group. The only public patch you've sent out in recent *years* is now in the tree. Nate From owner-freebsd-current Wed Apr 2 20:16:22 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id UAA24514 for current-outgoing; Wed, 2 Apr 1997 20:16:22 -0800 (PST) Received: from kithrup.com (kithrup.com [205.179.156.40]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id UAA24507 for ; Wed, 2 Apr 1997 20:16:19 -0800 (PST) Received: (from sef@localhost) by kithrup.com (8.6.8/8.6.6) id UAA14316; Wed, 2 Apr 1997 20:14:55 -0800 Date: Wed, 2 Apr 1997 20:14:55 -0800 From: Sean Eric Fagan Message-Id: <199704030414.UAA14316@kithrup.com> To: terry@lambert.org Subject: Re: ufs lock panic in -current Newsgroups: kithrup.freebsd.current In-Reply-To: <199704030254.TAA15269.kithrup.freebsd.current@phaeton.artisoft.com> References: <18686.860030332@time.cdrom.com> from "Jordan K. Hubbard" at Apr 2, 97 05:18:52 pm Organization: Kithrup Enterprises, Ltd. Cc: current@freebsd.org Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In article <199704030254.TAA15269.kithrup.freebsd.current@phaeton.artisoft.com> you write: >Julian has my namei/nameifree and "EXCLUDE" NDINIT() op redundant >code reduction changes. > >Feel free to commit them. Well, I haven't seen them, so I can't comment. But I would be willing to look at your code sometime. Several others have volunteered, it looks like, as well. >I just sent you (posted) some Logical Name support code. Feel free >to commit that. I remember that, I think. It was fairly close to how I would have done it. However, I don't know that it's *worth* doing it, as it's a very experimental thing. But maybe -current is a good place for that, now. >You keep suggesting that I should upload my complete patches >for my working code set (which are based on a snapshot from June >of 1994). These patches were already deemed "unsuitable". Actually, what we would all prefer is a set of patches related to a SINGLE problem. *Or* you do what Julian and others have done, when making sweeping changes: track -current, put the code up for anon. ftp or cvs, and encourage people to grab it. Yes, that means a lot of work on your part to continue to track -current. That's why the people who do such sweeping changes are few and far between -- david and john spring to mind ;). Or the SMP work. I believe the problem for *you* is that you haven't been standing still, and now your working set is radically different from "our" stuff. So, naturally, you're pissed that you have to go back and seperate individual projects and re-apply them to a set of files that are now completely different or completely uninteresting to you. I don't blame you for being frustrated. I don't blame Jordan for being frustrated. I don't know what the solution is; I know I'd like to have you working on more mainstream code, and get some of the stuff you've done integrated. But I think the first step is making the code publicly available, not just to a single individual. Sean. From owner-freebsd-current Wed Apr 2 20:50:35 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id UAA25589 for current-outgoing; Wed, 2 Apr 1997 20:50:35 -0800 (PST) Received: from zeus.xtalwind.net (slipper8b.xtalwind.net [205.160.242.66]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id UAA25579 for ; Wed, 2 Apr 1997 20:50:30 -0800 (PST) Received: from localhost (zeus.xtalwind.net [127.0.0.1]) by zeus.xtalwind.net (8.8.5/8.8.5) with SMTP id XAA02995; Wed, 2 Apr 1997 23:50:23 -0500 (EST) Date: Wed, 2 Apr 1997 23:50:22 -0500 (EST) From: jack X-Sender: jack@zeus.xtalwind.net Reply-To: jack To: freebsd-current@freebsd.org Subject: make release under 2.2.1-RELEASE Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk This morning we began converting our 5 BSDi boxes to FreeBSD. We shuffled some things around and freedup a p5-133 w/ ~5gig of drive space. Since we have many users with >8 char names i just did a bin and source install, edited utmp.h and param.h, and made world and the kernel. All went well. :) My plan was to roll a release on that box and install to the others from it. Make release has not gone well. ===> lkm/wcd install -c -o bin -g bin -m 555 wcd_mod.o /var/release/lkm cd /var/release/usr && rm -rf src && cvs -d co -P -r RELENG_2_2 src cvs: invalid option -- P Usage: cvs [cvs-options] command [command-options] [files...] Checking the Makefile it seems CVSROOT needs to be defined. My first guess was /usr/src/CVS. So much for that idea. :( cd /var/release/usr && rm -rf src && cvs -d /usr/src/CVS co -r RELENG_2_2 src cvs co: Sorry, you don't have sufficient access to /usr/src/CVS cvs [co aborted]: /usr/src/CVS/CVSROOT: No such file or directory Help.. What part of TFM do I need to R? -------------------------------------------------------------------------- Jack O'Neill Crystal Wind Communications, Inc. jacko@xtalwind.net Citrus County FL's Premier ISP Finger jacko@diamond.xtalwind.net or The CyberSurf C@fe http://www.xtalwind.net/~jacko/pubpgp.html for my PGP key. (352) 564-0101 (modem) #include (352) 563-5822 (voice) PGP Key fingerprint = F6 C4 E6 D4 2F 15 A7 67 FD 09 E9 3C 5F CC EB CD -------------------------------------------------------------------------- From owner-freebsd-current Wed Apr 2 21:02:44 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id VAA26029 for current-outgoing; Wed, 2 Apr 1997 21:02:44 -0800 (PST) Received: from dyson.iquest.net (dyson.iquest.net [198.70.144.127]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id VAA26021 for ; Wed, 2 Apr 1997 21:02:40 -0800 (PST) Received: (from root@localhost) by dyson.iquest.net (8.8.4/8.6.9) id AAA01333; Thu, 3 Apr 1997 00:01:29 -0500 (EST) From: "John S. Dyson" Message-Id: <199704030501.AAA01333@dyson.iquest.net> Subject: Re: ufs lock panic in -current In-Reply-To: <199704030414.UAA14316@kithrup.com> from Sean Eric Fagan at "Apr 2, 97 08:14:55 pm" To: sef@Kithrup.COM (Sean Eric Fagan) Date: Thu, 3 Apr 1997 00:01:28 -0500 (EST) Cc: terry@lambert.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-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > Yes, that means a lot of work on your part to continue to track -current. > That's why the people who do such sweeping changes are few and far between > -- david and john spring to mind ;). Or the SMP work. > You know about the terrible mess that I sometimes make also... :-(. John From owner-freebsd-current Wed Apr 2 21:08:23 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id VAA26323 for current-outgoing; Wed, 2 Apr 1997 21:08:23 -0800 (PST) Received: from hydrogen.nike.efn.org (metriclient-9.uoregon.edu [128.223.172.9]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id VAA26313 for ; Wed, 2 Apr 1997 21:08:18 -0800 (PST) Received: (from jmg@localhost) by hydrogen.nike.efn.org (8.8.4/8.8.4) id VAA01135; Wed, 2 Apr 1997 21:08:02 -0800 (PST) Message-ID: <19970402210802.64256@hydrogen.nike.efn.org> Date: Wed, 2 Apr 1997 21:08:02 -0800 From: John-Mark Gurney To: jack Cc: freebsd-current@FreeBSD.ORG Subject: Re: make release under 2.2.1-RELEASE References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.67 In-Reply-To: ; from jack on Wed, Apr 02, 1997 at 11:50:22PM -0500 Reply-To: John-Mark Gurney Organization: Cu Networking X-Operating-System: FreeBSD 2.2-960801-SNAP 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-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk jack scribbled this message on Apr 2: > This morning we began converting our 5 BSDi boxes to FreeBSD. We > shuffled some things around and freedup a p5-133 w/ ~5gig of drive space. > Since we have many users with >8 char names i just did a bin and source > install, edited utmp.h and param.h, and made world and the kernel. All > went well. :) My plan was to roll a release on that box and install to > the others from it. Make release has not gone well. > > ===> lkm/wcd > install -c -o bin -g bin -m 555 wcd_mod.o /var/release/lkm > cd /var/release/usr && rm -rf src && cvs -d co -P -r RELENG_2_2 src > cvs: invalid option -- P Usage: cvs [cvs-options] command > [command-options] [files...] > > Checking the Makefile it seems CVSROOT needs to be defined. My first > guess was /usr/src/CVS. So much for that idea. :( > > cd /var/release/usr && rm -rf src && cvs -d /usr/src/CVS co -r RELENG_2_2 > src > cvs co: Sorry, you don't have sufficient access to /usr/src/CVS > cvs [co aborted]: /usr/src/CVS/CVSROOT: No such file or directory > > Help.. > > What part of TFM do I need to R? you need to grabe a copy of the CVS tree... and point the CVSROOT env var to it... the release requires the CVS tree to check out parts of the code... if you have any questions... I'll try to help, but I've never rolled a release before... hope you get it working... ttyl.. -- John-Mark Cu Networking Modem/FAX: +1 541 683 6954 Live in Peace, destroy Micro$oft, support free software, run FreeBSD From owner-freebsd-current Wed Apr 2 21:32:30 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id VAA27364 for current-outgoing; Wed, 2 Apr 1997 21:32:30 -0800 (PST) Received: from time.cdrom.com (root@time.cdrom.com [204.216.27.226]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id VAA27359; Wed, 2 Apr 1997 21:32:24 -0800 (PST) Received: from time.cdrom.com (jkh@localhost [127.0.0.1]) by time.cdrom.com (8.8.5/8.6.9) with ESMTP id VAA19308; Wed, 2 Apr 1997 21:30:26 -0800 (PST) To: Terry Lambert cc: phk@critter.dk.tfs.com, ache@nagual.ru, dyson@FreeBSD.ORG, bde@zeta.org.au, current@FreeBSD.ORG Subject: Re: ufs lock panic in -current In-reply-to: Your message of "Wed, 02 Apr 1997 19:54:55 MST." <199704030254.TAA15269@phaeton.artisoft.com> Date: Wed, 02 Apr 1997 21:30:26 -0800 Message-ID: <19304.860045426@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > Julian has my namei/nameifree and "EXCLUDE" NDINIT() op redundant > code reduction changes. > > Feel free to commit them. How can I? You've sent them only to Julian, and as far as I can see so far, he ain't talking. This entire thread *started* from my asking you to put these same changes up for FTP someplace (since you mentioned them specifically as an example of a contribution and phk followed up that he wanted in) and now you're suddenly playing The Reasonable Man over them, after engaging in another multi-mail thread about how you *weren't* going to do this. In case you were confused, I never asked you to post the complete sources for TerryOS, simply some of these changes you keep talking about. > I just sent you (posted) some Logical Name support code. Feel free > to commit that. You posted a skeleton which may be something I can flesh out into a working Logical Name facility with a bit more work invested - what benefit would there be to my commiting what you sent me just now? I'll assume you were just short of examples in this case and tossed a non-example into the pot by mistake. > You keep suggesting that I should upload my complete patches > for my working code set (which are based on a snapshot from June > of 1994). These patches were already deemed "unsuitable". I suggest you upload *some patches*, any patches, which start the ball rolling. You seem to think I have a crystal ball of some sort and know what "complete patches for your working code set" would amount to or even look like. Well I don't and I furthermore don't even *care* what your grand design looks like or if you give us only 10% or 90% of it, all I'm concerned with is you continuing to hang around making noise about how we're impeding your progress yet remaining in denial about your own issues which actually keep this from happening. It's frustrating and it's not getting us anywhere. > I respectfully suggest you take the patches that I have updated > to meet your standards of suitability, and forget about those which > you deem "unsuitable". I respectfully suggest that you be a little more careful in your choice of pronouns. I personally have rejected nothing of yours, by my standards of suitability or anyone else's. I'm the one asking you to put diffs up, along with other members of the project team, and I could personally care less how many "gotos" you use - I've never taken any particular issue with your programming style and if somebody flamed you way back when over it well then that's hardly my fault. We've all been flamed, both fairly and unfairly, and there's no such thing as a "Unified FreeBSD Opinion About Terry Lambert" if it's such a thing you're attacking. Again, you may have sent some patches to where one guy could look at them but you didn't send them to where all of -committers could. Please do that, it's nothing more less than we ask of others. > I have already shown a willingness to meet your criteria, and there > is no need for you to publically appear willing to accept patches > which you have already rejected (since my patches applied against See above. > Because you have failed to provide a set of criteria which I can apply > to a design to determine if the results of the design would meet the > criteria. Richard and others have found themselves in the same boat. Sigh. Both you and Richard want the Core Team equivalent of a McDonald's Franchise Operations Manual, complete with intructions on how long to fry the patties, what color the uniforms should be and what the minimum standards for perkiness are for the people who stand up front and talk to customers. Sorry, we just don't have that and we don't have time to write it. Furthermore, we don't work to any fixed set of criteria short of "Does everyone seem to like it? Does it smell OK? Does the author look like the kind of guy who'll support it? Can we work with him on an ongoing basis or does he have Personality Odor?" That's it. There's no design doc for the minimum and maximum amounts of delta-V allowed per release and it all comes down to *what* the changes are and *what* they buy you, hopefully expressed or implemented in code to the extent that it's possible for people who can't peer directly into Terry Lambert's brain to figure it out and reach some conclusions about it. > > You would have been working to establish bonds of trust rather > > than dictating from the pulpit, > > Bogus and argumentative. Factual and unfortunate. Address this issue and you may find those "bonds of trust" I mentioned starting to form a little more solidly, but right now, I and many of the other developers trust you about as much as we'd trust Bill Clinton at a Miss America pagent. I draw a barbed analogy in jest but I mean this in complete earnestness. The combined effect of your postings over these last 2-3 years have left me completely and utterly unable to see you as any kind of team player. > that we are "fencing" with "slippery conversational gambits", rather > than *reading* what I have *stated* are my motivations. There was > no need for you to cause this discussion to deteriorate into a public > head-bashing instead of taking it to private email, unless your Perhaps more head-bashing got introduced as I went along than was my intention at the start, and for that excess I apologise. However, I don't particularly think that a private exchange would have done much good either, to be frank. I've used stronger language with you in private and I've tried long, involved discussion and I've tried being short and to the point, brutally so at times, and I've tried just about everything else and through it all you Just Don't Get It. You think I'm just castigating you for the fun of it, perhaps, or have some deep-seated reason for treating you "differently" from the other developers, and there is absolutely nothing flawed about your own approach. Terry does not need to change, the FreeBSD core team does. Yeah, right. That's all I can say. The less polite words would not be appropriate in this forum. > the issues. Frankly, if you spent as much time in reasoned > discussion as you do honing your sword on the bones of your victims, > we would no longer have any differences to speak to: we would agree > where we agreed, and we would agree to disagree where we did not, > and that would be the end of it. It takes two to tango, pal, and I *have* tried the "reasoned discussion" approach with you too. If you're not wearing me down with huge trestises on vote-driven commit systems, whole new levels of abstration and a host of other Must Have proposals which would only overly complicate my life and totally sideline me from all my other work but would indeed somehow solve The Problem You're Having, it's generally me telling you your best chances of getting your changes into the tree and you answering how that's all Frightfully Impossible for some reason or another right now and that the mountain is just going to have to come to Mohammed this once. Until you change your MO, this is an unending topic which no amount of reasoned discussion is going to resolve. > Review the patches sent Julian. If you don't like them, tell me > why so I can correct them and you can commite them, and I will send > more patches. If you do like them, commit them, and I will send > more patches. This is the very simple formula for getting code > out of "A Lambert". I cannot judge what I do not have. I repeat, very tiredly, for what is perhaps the 3rd time: Put them up for FTP please. Thank you. I would be more than happy to judge the code over the coder if I could see the code. Jordan From owner-freebsd-current Wed Apr 2 22:17:25 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id WAA29641 for current-outgoing; Wed, 2 Apr 1997 22:17:25 -0800 (PST) Received: from critter.dk.tfs.com (phk.cybercity.dk [195.8.133.247]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id WAA29628; Wed, 2 Apr 1997 22:17:09 -0800 (PST) Received: from critter (localhost [127.0.0.1]) by critter.dk.tfs.com (8.8.5/8.8.5) with ESMTP id IAA01168; Thu, 3 Apr 1997 08:16:03 +0200 (CEST) To: Nate Williams cc: Terry Lambert , jkh@time.cdrom.com (Jordan K. Hubbard), current@freebsd.org Subject: Re: Terry's changes (was Re: ufs lock panic in -current) In-reply-to: Your message of "Wed, 02 Apr 1997 18:22:16 PDT." <199704030122.SAA18652@rocky.mt.sri.com> Date: Thu, 03 Apr 1997 08:16:03 +0200 Message-ID: <1166.860048163@critter> From: Poul-Henning Kamp Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >Then quit bitching about FreeBSD not accepting your patches. You've >been asked to provide them in an 'easy to vend' manner, and you've >refused stating it's too much work. Then, PHK and others have stated, >upload your whole store, and you're unwilling to do that either. Well, I'm not sure he wasn't willing to, but I belive that last time we went over that Terry ran into a terrible string of bad luck. First his disk crashed, then his powersupply died and finally the city-council banned all export of non-zero valued bits or something so he has to invent and code a encryption routine that would only outbut zero bits... I remember when I received Terrys much talked about version of the SMP prototype. The only difference was that it could still not even get close to working and he had addded a couple of comments. Is it just because I'm danish that I'm thinking of H.C.Andersens tale "The emperors new clothes" ? Terry's code doesn't exist. -- Poul-Henning Kamp | phk@FreeBSD.ORG FreeBSD Core-team. http://www.freebsd.org/~phk | phk@login.dknet.dk Private mailbox. whois: [PHK] | phk@tfs.com TRW Financial Systems, Inc. Power and ignorance is a disgusting cocktail. From owner-freebsd-current Wed Apr 2 23:12:40 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id XAA02408 for current-outgoing; Wed, 2 Apr 1997 23:12:40 -0800 (PST) Received: from ravenock.cybercity.dk (ravenock.cybercity.dk [194.16.57.32]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id XAA02397; Wed, 2 Apr 1997 23:12:31 -0800 (PST) Received: (from sos@localhost) by ravenock.cybercity.dk (8.8.5/8.7.3) id JAA08723; Thu, 3 Apr 1997 09:11:07 +0200 (MET DST) From: Søren Schmidt Message-Id: <199704030711.JAA08723@ravenock.cybercity.dk> Subject: Re: ufs lock panic in -current In-Reply-To: <199704022302.QAA14842@phaeton.artisoft.com> from Terry Lambert at "Apr 2, 97 04:02:31 pm" To: terry@lambert.org (Terry Lambert) Date: Thu, 3 Apr 1997 09:10:58 +0200 (MET DST) Cc: jkh@time.cdrom.com, terry@lambert.org, phk@critter.dk.tfs.com, ache@nagual.ru, dyson@FreeBSD.org, bde@zeta.org.au, current@FreeBSD.org 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-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk In reply to Terry Lambert who wrote: > > No, no, just upload them *now* please! Phk is already more than > > familiar with the degree of target movement involved, and putting them > > up for public display is precisely where you've waffled out on this > > issue *every single time* it's come up. If you don't want to release > > your bits, fine, but then kindly *stop* talking about how reluctant we > > are to integrate them everytime someone so much as gives you an > > opening! You can't have it both ways, OK? Please, just take phk up > > on his offer and ** upload your changes *** so that we can maybe even > > get *past* this "2 year's worth of delay" you keep talking about. > > Don't make it 3 years through your own initiative now, eh? :-) [Alot of Terry bla bla deleted] > I'd rather have no editiorial criticism than destructive editorial > criticism, thank you. Giving you the changes incrementally seems > to be the only reliable way to achieve this. So again Terry exactly WHEN do we get the first chunk then ?? -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Søren Schmidt (sos@FreeBSD.org) FreeBSD Core Team Even more code to hack -- will it ever end .. From owner-freebsd-current Wed Apr 2 23:21:09 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id XAA03031 for current-outgoing; Wed, 2 Apr 1997 23:21:09 -0800 (PST) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id XAA03022 for ; Wed, 2 Apr 1997 23:21:05 -0800 (PST) Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id JAA18193 for freebsd-current@freebsd.org; Thu, 3 Apr 1997 09:21:03 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.8.5/8.8.5) id JAA28022; Thu, 3 Apr 1997 09:10:21 +0200 (MET DST) Message-ID: <19970403091021.GQ10330@uriah.heep.sax.de> Date: Thu, 3 Apr 1997 09:10:21 +0200 From: j@uriah.heep.sax.de (J Wunsch) To: freebsd-current@freebsd.org Subject: Re: UserMode ppp problem with set device References: <199704022208.AA02609@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: <199704022208.AA02609@iluvatar.unx.sas.com>; from John W. DeBoskey on Apr 2, 1997 17:08:10 -0500 Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk As John W. DeBoskey wrote: > It seems to fail in LCP negotiations. The only oddity is the message > 'magic is same!!.' Answered privately. -- 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 Wed Apr 2 23:28:21 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id XAA03381 for current-outgoing; Wed, 2 Apr 1997 23:28:21 -0800 (PST) Received: from helbig.informatik.ba-stuttgart.de (helbig.informatik.ba-stuttgart.de [141.31.166.22]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id XAA03375 for ; Wed, 2 Apr 1997 23:28:16 -0800 (PST) Received: (from helbig@localhost) by helbig.informatik.ba-stuttgart.de (8.8.5/8.8.5) id JAA29025 for current@freebsd.org; Thu, 3 Apr 1997 09:28:14 +0200 (MET DST) From: Wolfgang Helbig Message-Id: <199704030728.JAA29025@helbig.informatik.ba-stuttgart.de> Subject: ctm deprivation To: current@freebsd.org Date: Thu, 3 Apr 1997 09:28:12 +0200 (MET DST) X-Mailer: ELM [version 2.4ME+ PL30 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi, I didn't get cvs-cur ctm deltas since #3182. Do I just have to wait or do I have to fix something? Thanks in advance Wolfgang From owner-freebsd-current Wed Apr 2 23:53:27 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id XAA04980 for current-outgoing; Wed, 2 Apr 1997 23:53:27 -0800 (PST) Received: from ravenock.cybercity.dk (ravenock.cybercity.dk [194.16.57.32]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id XAA04974 for ; Wed, 2 Apr 1997 23:53:24 -0800 (PST) Received: (from sos@localhost) by ravenock.cybercity.dk (8.8.5/8.7.3) id JAA09048 for current@freebsd.org; Thu, 3 Apr 1997 09:53:42 +0200 (MET DST) From: Søren Schmidt Message-Id: <199704030753.JAA09048@ravenock.cybercity.dk> Subject: CTM generation stopped ?? To: current@freebsd.org (FreeBSD current) Date: Thu, 3 Apr 1997 09:53:06 +0200 (MET DST) 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-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk It seems the generation of ctm cvs-cur deltas has stopped ?? any ideas ?? -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Søren Schmidt (sos@FreeBSD.org) FreeBSD Core Team Even more code to hack -- will it ever end .. From owner-freebsd-current Wed Apr 2 23:58:44 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id XAA05231 for current-outgoing; Wed, 2 Apr 1997 23:58:44 -0800 (PST) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id XAA05226 for ; Wed, 2 Apr 1997 23:58:40 -0800 (PST) Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id JAA18521 for current@freebsd.org; Thu, 3 Apr 1997 09:58:33 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.8.5/8.8.5) id JAA28170; Thu, 3 Apr 1997 09:50:26 +0200 (MET DST) Message-ID: <19970403095026.AM16414@uriah.heep.sax.de> Date: Thu, 3 Apr 1997 09:50:26 +0200 From: j@uriah.heep.sax.de (J Wunsch) To: current@freebsd.org Subject: Re: POLL & the Single FreeBSD'r References: <199704030142.BAA04433@netfl15a.devetir.qld.gov.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) In-Reply-To: <199704030142.BAA04433@netfl15a.devetir.qld.gov.au>; from Stephen Hocking on Apr 3, 1997 11:42:54 +1000 Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk As Stephen Hocking wrote: > I note that NetBSD has had the poll system call for some time. Are > there any plans to integrate one of the few nice SYSV'isms into > FreeBSD (it would make porting some code a snap). At least, it hasn't been diminished to be a bad idea. -- 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 Thu Apr 3 00:35:15 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id AAA06476 for current-outgoing; Thu, 3 Apr 1997 00:35:15 -0800 (PST) Received: from fgate.flevel.co.uk (root@fgate.flevel.co.uk [194.6.101.2]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id AAA06457; Thu, 3 Apr 1997 00:35:10 -0800 (PST) Received: from localhost (dev@localhost) by fgate.flevel.co.uk (8.8.3/8.6.9) with SMTP id JAA29929; Thu, 3 Apr 1997 09:35:06 +0100 (BST) Date: Thu, 3 Apr 1997 09:35:06 +0100 (BST) From: Developer To: Brian Somers cc: freebsd-current@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: PPP Problems -- The next chapter *grin* In-Reply-To: <199704022107.WAA14851@awfulhak.demon.co.uk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Wed, 2 Apr 1997, Brian Somers wrote: > The answer would be shorter if you asked what isn't different. Were you > using the pmdemand example and reading the handbook tutorial ? Was it > >= 2.2 ? No, we are not using pmdemand. No I wasn't reading the tutorial in the handbook either *grin* We are using a 3.0-current snap. Regards, Trefor S. > Brian , > > Don't _EVER_ lose your sense of humour.... > > > From owner-freebsd-current Thu Apr 3 01:01:12 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id BAA07672 for current-outgoing; Thu, 3 Apr 1997 01:01:12 -0800 (PST) Received: from ravenock.cybercity.dk (ravenock.cybercity.dk [194.16.57.32]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id BAA07662 for ; Thu, 3 Apr 1997 01:01:06 -0800 (PST) Received: (from sos@localhost) by ravenock.cybercity.dk (8.8.5/8.7.3) id LAA09216; Thu, 3 Apr 1997 11:01:12 +0200 (MET DST) From: Søren Schmidt Message-Id: <199704030901.LAA09216@ravenock.cybercity.dk> Subject: Re: ctm deprivation In-Reply-To: <199704030728.JAA29025@helbig.informatik.ba-stuttgart.de> from Wolfgang Helbig at "Apr 3, 97 09:28:12 am" To: helbig@MX.BA-Stuttgart.De (Wolfgang Helbig) Date: Thu, 3 Apr 1997 11:01:02 +0200 (MET DST) Cc: current@freebsd.org 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-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In reply to Wolfgang Helbig who wrote: > Hi, > > I didn't get cvs-cur ctm deltas since #3182. Do I just have to wait > or do I have to fix something? There is nothing wrong with you (in this respect :) ), there hasn't been any CTM since then. The question reamins though as to WHY?? Richard?? HELP! -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Søren Schmidt (sos@FreeBSD.org) FreeBSD Core Team Even more code to hack -- will it ever end .. From owner-freebsd-current Thu Apr 3 01:02:05 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id BAA07759 for current-outgoing; Thu, 3 Apr 1997 01:02:05 -0800 (PST) Received: from palrel1.hp.com (palrel1.hp.com [15.253.72.10]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id BAA07753 for ; Thu, 3 Apr 1997 01:02:00 -0800 (PST) Received: from fakir.india.hp.com (fakir.india.hp.com [15.10.40.3]) by palrel1.hp.com with ESMTP (8.7.5/8.7.3) id BAA19366 for ; Thu, 3 Apr 1997 01:01:55 -0800 (PST) Received: from localhost by fakir.india.hp.com with SMTP (1.37.109.20/15.5+ECS 3.3) id AA060449937; Thu, 3 Apr 1997 14:32:17 +0500 Message-Id: <199704030932.AA060449937@fakir.india.hp.com> To: "Peter M. Chen" Cc: freebsd-current@freebsd.org Subject: Re: question on buffer cache and VMIO In-Reply-To: Your message of "Tue, 01 Apr 1997 22:15:03 EST." Date: Thu, 03 Apr 1997 14:32:16 +0500 From: "A JOSEPH KOSHY" Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >>>> ""Peter M. Chen"" writes > The only hardware is a battery. The VM write protection is software. > Those without batteries need to write to disk (or non-volatile memory); > those with batteries (e.g. machine rooms, laptops) can keep data in memory > if it survives crashes. If I understood the paper correctly, Vista first copies out the protected address range to RIO protected memory prior to allowing the application to proceed with its changes. Would some form of copy-on-write scheme help to eliminate this initial copy? Whether there would be a performance benefit from this would depend on the relative costs of copying vs creating a set of mappings, I guess. Koshy My Personal Opinions Only From owner-freebsd-current Thu Apr 3 01:10:14 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id BAA08194 for current-outgoing; Thu, 3 Apr 1997 01:10:14 -0800 (PST) Received: from hydrogen.nike.efn.org (resnet.uoregon.edu [128.223.170.28]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id BAA08189 for ; Thu, 3 Apr 1997 01:10:08 -0800 (PST) Received: (from jmg@localhost) by hydrogen.nike.efn.org (8.8.4/8.8.4) id BAA01865; Thu, 3 Apr 1997 01:09:57 -0800 (PST) Message-ID: <19970403010957.13573@hydrogen.nike.efn.org> Date: Thu, 3 Apr 1997 01:09:57 -0800 From: John-Mark Gurney To: FreeBSD Current Subject: termcap and color Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.67 Reply-To: John-Mark Gurney Organization: Cu Networking X-Operating-System: FreeBSD 2.2-960801-SNAP 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-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk well... I was looking through and seeing how xterm-color defined it's color entries... and I noticed that is uses, Co, Sf, and Sb... then I did a man 5 termcap to look up what this did (to make sure they were what I was looking for), but they aren't listed... hmm.. interesting... so then I said.. well I know that ansi.sys supports color but they weren't listed... also.. dtterm has a Co set to 8.. but there isn't a Sf or a Sb listed to set the color... so: o) I add Co, Sf, and Sb to termcap(5) o) either dtterm removes Co#8, or we add Sf, Sb to it's entry, (I have access to dtterm at school if someone want to send me something to test) o) add Co, Sf, and Sb to ansi.sys to support color also. anybody have any problems with the above? and were/who decided on using Co/Sf/Sb for the color stuff?? (just so I can look to it/them to make sure it is legit) thanks for the comments... ttyl... -- John-Mark Cu Networking Modem/FAX: +1 541 683 6954 Live in Peace, destroy Micro$oft, support free software, run FreeBSD From owner-freebsd-current Thu Apr 3 01:28:10 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id BAA08982 for current-outgoing; Thu, 3 Apr 1997 01:28:10 -0800 (PST) Received: from hda.hda.com (hda-bicnet.bicnet.net [207.198.1.121]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id BAA08976 for ; Thu, 3 Apr 1997 01:28:06 -0800 (PST) Received: (from dufault@localhost) by hda.hda.com (8.8.5/8.8.5) id AAA03090; Thu, 3 Apr 1997 00:49:35 -0500 (EST) From: Peter Dufault Message-Id: <199704030549.AAA03090@hda.hda.com> Subject: Re: Internal clock In-Reply-To: <199704030423.AA299151399@fakir.india.hp.com> from A JOSEPH KOSHY at "Apr 3, 97 09:23:19 am" To: koshy@india.hp.com (A JOSEPH KOSHY) Date: Thu, 3 Apr 1997 00:49:34 -0500 (EST) Cc: current@freebsd.org X-Mailer: ELM [version 2.4ME+ PL25 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > Shortly after the patches had been sent out I had folded them into the then > -current tree (Dec/Jan); the original patches were against 2.1.5 I think. > They were working fine under the limited testing I had done then. > > The Lite2 merge has touched many of the same files that the patches affected, > so I plan to redo this effort sometime in the (near?) future. I'm still > catching up with Lite2. Just a heads up that I'm working on this now. I'm not planning on committing until this sort of program works as expected and is reviewed. If I stop working on it I'll let the list know. #define _POSIX_SOURCE #define _POSIX_C_SOURCE 199309 #include #include #include #include #include int main(int ac, char *av[]) { int scheduler; #if _POSIX_VERSION < 199309 fprintf(stderr, "POSIX.4 is not supported\n"); exit(-1); #else #if !defined(_POSIX_PRIORITY_SCHEDULING) fprintf(stderr, "POSIX priority scheduling is not supported.\n"); exit(-1); #endif /* Is priority scheduling configured? */ errno = 0; if (sysconf(_SC_PRIORITY_SCHEDULING) == -1) { if (errno != 0) { /* This isn't valid - may be a standard violation */ perror("sysconf(_SC_PRIORITY_SCHEDULING)"); exit(errno); } else { fprintf(stderr, "Priority scheduling not supported.\n"); exit(-1); } } scheduler = sched_getscheduler(0); printf("sched_getscheduler says scheduler is %d.\n", scheduler); return 0; #endif /* _POSIX_VERSION < 199309 */ } -- Peter Dufault (dufault@hda.com) Realtime Machine Control and Simulation HD Associates, Inc. Voice: 508 433 6936 From owner-freebsd-current Thu Apr 3 01:40:14 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id BAA09566 for current-outgoing; Thu, 3 Apr 1997 01:40:14 -0800 (PST) Received: from critter.dk.tfs.com ([140.145.230.252]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id BAA09553; Thu, 3 Apr 1997 01:40:08 -0800 (PST) Received: from critter (localhost [127.0.0.1]) by critter.dk.tfs.com (8.8.5/8.8.5) with ESMTP id LAA00344; Thu, 3 Apr 1997 11:39:06 +0200 (CEST) Date: Thu, 03 Apr 1997 11:39:05 +0200 Message-ID: <338.860060345.1@critter> From: Poul-Henning Kamp Subject: New CTM meister... MIME-Version: 1.0 Content-Type: multipart/digest; boundary="----- =_aaaaaaaaaa" Content-Description: Blind Carbon Copy Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk To: undisclosed-recipients:; ------- =_aaaaaaaaaa Content-Type: message/rfc822 Content-Description: Original Message To: ctm-announce@freebsd.org Subject: New CTM meister... Reply-to: phk@freebsd.org Date: Thu, 03 Apr 1997 11:39:05 +0200 Message-ID: <338.860060345@critter> From: Poul-Henning Kamp Just this bit to make it official: Richard Wackerbarth Has taken over the job of CTM meister for FreeBSD, he is now the man behind the "ctm@FreeBSD.org" alias, which as always is the place to send email on the subject of CTM. Thanks for taking this over Richard! Poul-Henning -- Poul-Henning Kamp | phk@FreeBSD.ORG FreeBSD Core-team. http://www.freebsd.org/~phk | phk@login.dknet.dk Private mailbox. whois: [PHK] | phk@tfs.com TRW Financial Systems, Inc. Future will arrive by its own means, progress not so. ------- =_aaaaaaaaaa-- From owner-freebsd-current Thu Apr 3 01:40:59 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id BAA09630 for current-outgoing; Thu, 3 Apr 1997 01:40:59 -0800 (PST) Received: from hda.hda.com (hda-bicnet.bicnet.net [207.198.1.121]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id BAA09609 for ; Thu, 3 Apr 1997 01:40:49 -0800 (PST) Received: (from dufault@localhost) by hda.hda.com (8.8.5/8.8.5) id BAA03118 for current@freebsd.org; Thu, 3 Apr 1997 01:05:01 -0500 (EST) From: Peter Dufault Message-Id: <199704030605.BAA03118@hda.hda.com> Subject: I've survived make world. In-Reply-To: <199704022357.BAA13237@vector.jhs.no_domain> from "Julian H. Stacey" at "Apr 3, 97 01:57:15 am" To: current@freebsd.org Date: Thu, 3 Apr 1997 01:05:01 -0500 (EST) X-Mailer: ELM [version 2.4ME+ PL25 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > There've been a few "I survived a make world" claims lately .. but not many > in a long time. Current needs to be less unstable for a while, so refugees > can return to it from their Release temporary havens. I've survived make world from Monday. On a Compaq Presario of all things with no SCSI. I've built world twice with that build. It has been solid as a single user workstation. -- Peter Dufault (dufault@hda.com) Realtime Machine Control and Simulation HD Associates, Inc. Voice: 508 433 6936 From owner-freebsd-current Thu Apr 3 02:36:17 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id CAA13107 for current-outgoing; Thu, 3 Apr 1997 02:36:17 -0800 (PST) Received: from silvia.HIP.Berkeley.EDU (ala-ca8-59.ix.netcom.com [207.93.141.187]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id CAA13099 for ; Thu, 3 Apr 1997 02:36:10 -0800 (PST) Received: (from asami@localhost) by silvia.HIP.Berkeley.EDU (8.8.5/8.6.9) id CAA17928; Thu, 3 Apr 1997 02:36:02 -0800 (PST) Date: Thu, 3 Apr 1997 02:36:02 -0800 (PST) Message-Id: <199704031036.CAA17928@silvia.HIP.Berkeley.EDU> To: dufault@hda.com CC: current@freebsd.org In-reply-to: <199704030605.BAA03118@hda.hda.com> (message from Peter Dufault on Thu, 3 Apr 1997 01:05:01 -0500 (EST)) Subject: Re: I've survived make world. From: asami@vader.cs.berkeley.edu (Satoshi Asami) Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk * I've survived make world from Monday. On a Compaq Presario of all things * with no SCSI. I've built world twice with that build. It has been * solid as a single user workstation. I've survived a make world from 3/24, 3/26 and 3/31. (In fact, this is the machine that "packages-current" is built from now.) This is a P6-200 with an IDE system disk and 3940W with a Seagate ST15150W. However, the NFS client appears to be hopelessly broken (I don't know about the NFS server, this machine isn't one). I initially had the ports/distfiles pointing to a directory on an NFS server (running FreeBSD-2.1.5). At some point during the package builds, a process locks up trying to read/write a distfile, and the whole NFS system went down on this machine (I could still login as "root", as long as I didn't try to touch NFS-mounted directories). I changed ports/distfiles to a local directory and it appears to be fairly stable since then. Satoshi From owner-freebsd-current Thu Apr 3 03:37:09 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id DAA16704 for current-outgoing; Thu, 3 Apr 1997 03:37:09 -0800 (PST) Received: from ravenock.cybercity.dk (ravenock.cybercity.dk [194.16.57.32]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id DAA16699 for ; Thu, 3 Apr 1997 03:37:06 -0800 (PST) Received: (from sos@localhost) by ravenock.cybercity.dk (8.8.5/8.7.3) id NAA09615; Thu, 3 Apr 1997 13:37:16 +0200 (MET DST) From: Søren Schmidt Message-Id: <199704031137.NAA09615@ravenock.cybercity.dk> Subject: Re: I've survived make world. In-Reply-To: <199704031036.CAA17928@silvia.HIP.Berkeley.EDU> from Satoshi Asami at "Apr 3, 97 02:36:02 am" To: asami@vader.cs.berkeley.edu (Satoshi Asami) Date: Thu, 3 Apr 1997 13:37:16 +0200 (MET DST) Cc: dufault@hda.com, current@FreeBSD.org 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-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk In reply to Satoshi Asami who wrote: > * I've survived make world from Monday. On a Compaq Presario of all things > * with no SCSI. I've built world twice with that build. It has been > * solid as a single user workstation. > > I've survived a make world from 3/24, 3/26 and 3/31. (In fact, this > is the machine that "packages-current" is built from now.) This is a > P6-200 with an IDE system disk and 3940W with a Seagate ST15150W. I have done the same here on my P6-233/pure SCSI, apparently no probs... > However, the NFS client appears to be hopelessly broken (I don't know > about the NFS server, this machine isn't one). I initially had the > ports/distfiles pointing to a directory on an NFS server (running > FreeBSD-2.1.5). At some point during the package builds, a process > locks up trying to read/write a distfile, and the whole NFS system > went down on this machine (I could still login as "root", as long as I > didn't try to touch NFS-mounted directories). I changed > ports/distfiles to a local directory and it appears to be fairly > stable since then. Have you fiddled with the resvport option ?? that helped my clients connecting to the above mentioned box.... -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Søren Schmidt (sos@FreeBSD.org) FreeBSD Core Team Even more code to hack -- will it ever end .. From owner-freebsd-current Thu Apr 3 03:54:49 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id DAA17581 for current-outgoing; Thu, 3 Apr 1997 03:54:49 -0800 (PST) Received: from hda.hda.com (hda-bicnet.bicnet.net [207.198.1.121]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id DAA17576 for ; Thu, 3 Apr 1997 03:54:45 -0800 (PST) Received: (from dufault@localhost) by hda.hda.com (8.8.5/8.8.5) id DAA03412; Thu, 3 Apr 1997 03:18:42 -0500 (EST) From: Peter Dufault Message-Id: <199704030818.DAA03412@hda.hda.com> Subject: Re: I've survived make world. In-Reply-To: <199704031036.CAA17928@silvia.HIP.Berkeley.EDU> from Satoshi Asami at "Apr 3, 97 02:36:02 am" To: asami@vader.cs.berkeley.edu (Satoshi Asami) Date: Thu, 3 Apr 1997 03:18:41 -0500 (EST) Cc: current@freebsd.org X-Mailer: ELM [version 2.4ME+ PL25 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > However, the NFS client appears to be hopelessly broken (I don't know > about the NFS server, this machine isn't one). I initially had the > ports/distfiles pointing to a directory on an NFS server (running > FreeBSD-2.1.5). At some point during the package builds, a process > locks up trying to read/write a distfile, and the whole NFS system > went down on this machine (I could still login as "root", as long as I > didn't try to touch NFS-mounted directories). I changed > ports/distfiles to a local directory and it appears to be fairly > stable since then. FWIW: I've been doing my real work (but not the make world) over NFS with the server running 2.1.7.1. I've done a few ports builds with ports/distfiles mounted NFS (bash and one of the tk flavors). The Compaq is mass market: 24 MB memory, P5-166, IDE drive, 3C509 ethernet, etc. -- Peter Dufault (dufault@hda.com) Realtime Machine Control and Simulation HD Associates, Inc. Voice: 508 433 6936 From owner-freebsd-current Thu Apr 3 04:09:56 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id EAA18132 for current-outgoing; Thu, 3 Apr 1997 04:09:56 -0800 (PST) Received: from silvia.HIP.Berkeley.EDU (ala-ca8-59.ix.netcom.com [207.93.141.187]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id EAA18125; Thu, 3 Apr 1997 04:09:50 -0800 (PST) Received: (from asami@localhost) by silvia.HIP.Berkeley.EDU (8.8.5/8.6.9) id EAA18485; Thu, 3 Apr 1997 04:09:48 -0800 (PST) Date: Thu, 3 Apr 1997 04:09:48 -0800 (PST) Message-Id: <199704031209.EAA18485@silvia.HIP.Berkeley.EDU> To: freebsd-gnats-submit@freebsd.org CC: current@freebsd.org Subject: PR ports/3175 From: asami@vader.cs.berkeley.edu (Satoshi Asami) Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk It's not only emacs, it's all the ports that hail from the emacs family. A typical failure looks like this: === cc -Demacs -DHAVE_CONFIG_H -I. -I../src -I/ccd/ports/japanese/mule-canna/work/mule-2.3/lib-src -I/ccd/ports/japanese/mule-canna/work/mule-2.3/lib-src/../src -O /ccd/ports/japanese/mule-canna/work/mule-2.3/lib-src/fakemail.c -lutil -o fakemail /ccd/ports/japanese/mule-canna/work/mule-2.3/lib-src/fakemail.c: In function `make_file_preface': /ccd/ports/japanese/mule-canna/work/mule-2.3/lib-src/fakemail.c:308: warning: assignment makes pointer from integer without a cast /usr/tmp/cc0038671.o: Undefined symbol `_cuserid' referenced from text segment gmake[1]: *** [fakemail] Error 1 gmake[1]: Leaving directory `/ccd/ports/japanese/mule-canna/work/mule-2.3/lib-src' gmake: *** [lib-src] Error 2 === After digging around the sources a bit, I came up with the following patch to src/s/freebsd.h (this is for mule-canna/patches/patch-ac, the same patch applies to editors/emacs): === Index: patches/patch-ac =================================================================== RCS file: /usr/cvs/ports/japanese/mule-canna/patches/patch-ac,v retrieving revision 1.3 diff -u -r1.3 patch-ac --- patch-ac 1996/11/30 10:01:20 1.3 +++ patch-ac 1997/04/03 11:59:34 @@ -13,3 +13,12 @@ /* Reread the time zone on startup. */ #define LOCALTIME_CACHE +@@ -81,6 +81,8 @@ + #define BSD 199103 + #elif __FreeBSD__ == 2 + #define BSD 199306 ++#elif __FreeBSD__ == 3 ++#define BSD 199506 + #endif + + #define WAITTYPE int === I personally think this piece of code is one of the worst hacks I've seen (and obviously a ticking time-bomb, as we just experienced). If this is ok, I'll commit the patch to all emacs/mule ports and submit it back to FSF (although I prefer this fixed in some better way...hmm, Bruce? :). Satoshi From owner-freebsd-current Thu Apr 3 04:17:55 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id EAA18456 for current-outgoing; Thu, 3 Apr 1997 04:17:55 -0800 (PST) Received: from silvia.HIP.Berkeley.EDU (ala-ca8-59.ix.netcom.com [207.93.141.187]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id EAA18445; Thu, 3 Apr 1997 04:17:50 -0800 (PST) Received: (from asami@localhost) by silvia.HIP.Berkeley.EDU (8.8.5/8.6.9) id EAA18517; Thu, 3 Apr 1997 04:17:48 -0800 (PST) Date: Thu, 3 Apr 1997 04:17:48 -0800 (PST) Message-Id: <199704031217.EAA18517@silvia.HIP.Berkeley.EDU> To: freebsd-gnats-submit@freebsd.org CC: current@freebsd.org Subject: Re: ports/3175 From: asami@vader.cs.berkeley.edu (Satoshi Asami) Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk It's not only emacs, it's all the ports that hail from the emacs family. A typical failure looks like this: === cc -Demacs -DHAVE_CONFIG_H -I. -I../src -I/ccd/ports/japanese/mule-canna/work/mule-2.3/lib-src -I/ccd/ports/japanese/mule-canna/work/mule-2.3/lib-src/../src -O /ccd/ports/japanese/mule-canna/work/mule-2.3/lib-src/fakemail.c -lutil -o fakemail /ccd/ports/japanese/mule-canna/work/mule-2.3/lib-src/fakemail.c: In function `make_file_preface': /ccd/ports/japanese/mule-canna/work/mule-2.3/lib-src/fakemail.c:308: warning: assignment makes pointer from integer without a cast /usr/tmp/cc0038671.o: Undefined symbol `_cuserid' referenced from text segment gmake[1]: *** [fakemail] Error 1 gmake[1]: Leaving directory `/ccd/ports/japanese/mule-canna/work/mule-2.3/lib-src' gmake: *** [lib-src] Error 2 === After digging around the sources a bit, I came up with the following patch to src/s/freebsd.h (this is for mule-canna/patches/patch-ac, the patch does not apply to editors/emacs because patch-ac is not there but you get the idea): === Index: patches/patch-ac =================================================================== RCS file: /usr/cvs/ports/japanese/mule-canna/patches/patch-ac,v retrieving revision 1.3 diff -u -r1.3 patch-ac --- patch-ac 1996/11/30 10:01:20 1.3 +++ patch-ac 1997/04/03 11:59:34 @@ -13,3 +13,12 @@ /* Reread the time zone on startup. */ #define LOCALTIME_CACHE +@@ -81,6 +81,8 @@ + #define BSD 199103 + #elif __FreeBSD__ == 2 + #define BSD 199306 ++#elif __FreeBSD__ == 3 ++#define BSD 199506 + #endif + + #define WAITTYPE int === I personally think this piece of code is one of the worst hacks I've seen (and obviously a ticking time-bomb, as we just experienced). If this is ok, I'll commit the patch to all emacs/mule ports and submit it back to FSF (although I prefer this fixed in some better way...hmm, Bruce? :). Satoshi From owner-freebsd-current Thu Apr 3 04:40:45 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id EAA20414 for current-outgoing; Thu, 3 Apr 1997 04:40:45 -0800 (PST) Received: from silvia.HIP.Berkeley.EDU (ala-ca8-59.ix.netcom.com [207.93.141.187]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id EAA20409 for ; Thu, 3 Apr 1997 04:40:42 -0800 (PST) Received: (from asami@localhost) by silvia.HIP.Berkeley.EDU (8.8.5/8.6.9) id EAA18589; Thu, 3 Apr 1997 04:40:40 -0800 (PST) Date: Thu, 3 Apr 1997 04:40:40 -0800 (PST) Message-Id: <199704031240.EAA18589@silvia.HIP.Berkeley.EDU> To: current@freebsd.org In-reply-to: <199704031209.EAA18485@silvia.HIP.Berkeley.EDU> (asami@vader.cs.berkeley.edu) Subject: Re: PR ports/3175 From: asami@vader.cs.berkeley.edu (Satoshi Asami) Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk * Subject: PR ports/3175 Note: if you are reading -current, do NOT followup to this mail. There is another one (that has a subject "Re: ports/3175"), which is the correct one. The first attempt got misfiled by gnats (because I wrote "PR" instad of "Re:"). Satoshi From owner-freebsd-current Thu Apr 3 05:49:18 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id FAA23139 for current-outgoing; Thu, 3 Apr 1997 05:49:18 -0800 (PST) Received: from cougar.isg.siue.edu (cougar.isg.siue.edu [146.163.5.29]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id FAA23134 for ; Thu, 3 Apr 1997 05:49:15 -0800 (PST) Received: (from mforjan@localhost) by cougar.isg.siue.edu (8.8.5/8.8.5) id HAA21547 for freebsd-current@freebsd.org; Thu, 3 Apr 1997 07:53:37 -0600 (CST) From: MIGUEL FORJAN Message-Id: <199704031353.HAA21547@cougar.isg.siue.edu> Subject: unsubscribe To: freebsd-current@freebsd.org Date: Thu, 3 Apr 1997 07:53:37 -0600 (CST) X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk unsubscribe freebsd-current Miguel Forjan From owner-freebsd-current Thu Apr 3 06:04:26 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id GAA23915 for current-outgoing; Thu, 3 Apr 1997 06:04:26 -0800 (PST) Received: from life.eecs.umich.edu (pmchen@life.eecs.umich.edu [141.213.8.32]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id GAA23910 for ; Thu, 3 Apr 1997 06:04:21 -0800 (PST) Received: (from pmchen@localhost) by life.eecs.umich.edu (8.8.5/8.8.0) id JAA20132; Thu, 3 Apr 1997 09:03:05 -0500 (EST) Date: Thu, 3 Apr 1997 09:03:05 -0500 (EST) From: "Peter M. Chen" Message-Id: <199704031403.JAA20132@life.eecs.umich.edu> To: koshy@india.hp.com, pmchen@eecs.umich.edu Subject: Re: question on buffer cache and VMIO Cc: freebsd-current@freebsd.org Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >From koshy@india.hp.com Thu Apr 3 04:01:03 1997 > >If I understood the paper correctly, Vista first copies out the protected >address range to RIO protected memory prior to allowing the application >to proceed with its changes. > >Would some form of copy-on-write scheme help to eliminate this initial >copy? Whether there would be a performance benefit from this would depend >on the relative costs of copying vs creating a set of mappings, I guess. Vista is a library that implements transactional memory on top of Rio (like RVM out of Carnegie Mellon, only 2000 times faster and 10 times smaller because of reliable memory). The initial copy is needed for transactions to implement atomicity. Copy-on-write wouldn't help because the transaction only copies the range of addresses it intends on modifying. We've actually implemented a copy-on-write scheme to ease the programming of transactions (implicit transactions), but this is really slow because of the extra mprotects and VM traps. Vista has only 5 usec overhead per transaction, so even 1 system call hurts a lot. Pete From owner-freebsd-current Thu Apr 3 06:07:08 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id GAA24069 for current-outgoing; Thu, 3 Apr 1997 06:07:08 -0800 (PST) Received: from korin.warman.org.pl (korin.warman.org.pl [148.81.160.10]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id GAA24049 for ; Thu, 3 Apr 1997 06:06:57 -0800 (PST) Received: from localhost (abial@localhost) by korin.warman.org.pl (8.8.3/8.7.3) with SMTP id QAA11701 for ; Thu, 3 Apr 1997 16:06:42 +0200 (MET DST) Date: Thu, 3 Apr 1997 16:06:41 +0200 (MET DST) From: Andrzej Bialecki To: freebsd-current@freebsd.org Subject: IPv6 && -current Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hello! What is the status of IPv6 implementation under -current? I'd be probably interested in setting up a machine and a tunnel to 6bone, so I would gladly use FreeBSD for this, if it's possible... Sincerely yours, --- Andrzej Bialecki FreeBSD: Turning PCs Into Workstations http://www.freebsd.org Research and Academic Network in Poland From owner-freebsd-current Thu Apr 3 07:01:04 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id HAA26594 for current-outgoing; Thu, 3 Apr 1997 07:01:04 -0800 (PST) Received: from smtp.utexas.edu (smtp.utexas.edu [128.83.126.2]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id HAA26588 for ; Thu, 3 Apr 1997 07:01:01 -0800 (PST) Received: (qmail-queue invoked from smtpd); 3 Apr 1997 15:01:00 -0000 Received: from mail.utexas.edu (128.83.126.1) by smtp.utexas.edu with SMTP; 3 Apr 1997 15:01:00 -0000 Received: from [208.2.87.4] (cod.dataplex.net [208.2.87.4]) by mail.utexas.edu with ESMTP id JAA27511; Thu, 3 Apr 1997 09:00:57 -0600 (CST) X-Sender: rkw@shrimp.dataplex.net Message-Id: In-Reply-To: <199704030753.JAA09048@ravenock.cybercity.dk> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Thu, 3 Apr 1997 08:58:33 -0600 To: =?iso-8859-1?Q?S=AFren?= Schmidt From: Richard Wackerbarth Subject: Re: CTM generation stopped ?? Cc: current@freebsd.org (FreeBSD current) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by freefall.freebsd.org id HAA26590 Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk At 1:53 AM -0600 4/3/97, S¯ren Schmidt wrote: >It seems the generation of ctm cvs-cur deltas has stopped ?? >any ideas ?? I think that there is something in the FreeBSD code that recognizes that I have not logged in within the past 24 hours and crashes the system :-) Sorry for the disruption. The flow should resume today. Richard From owner-freebsd-current Thu Apr 3 07:32:04 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id HAA27831 for current-outgoing; Thu, 3 Apr 1997 07:32:04 -0800 (PST) Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id HAA27787 for ; Thu, 3 Apr 1997 07:31:55 -0800 (PST) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.8.5/8.8.5) id KAA04612; Thu, 3 Apr 1997 10:29:08 -0500 (EST) Date: Thu, 3 Apr 1997 10:29:08 -0500 (EST) From: Garrett Wollman Message-Id: <199704031529.KAA04612@khavrinen.lcs.mit.edu> To: Andrzej Bialecki Cc: freebsd-current@freebsd.org Subject: IPv6 && -current In-Reply-To: References: Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk < said: > What is the status of IPv6 implementation under -current? I'd be probably > interested in setting up a machine and a tunnel to 6bone, so I would > gladly use FreeBSD for this, if it's possible... I am aware of two implementations out there, and the unfortunate truth is that both of them suck, in different ways. (Although at least one of them, I am told, is getting significantly better stylistically.) Until this situation changes a bit more (or we find someone interested in doing an IPv6 implementation that obeys style(9) and isn't altogether bletcherous), there should not be IPv6 code in the -current kernel. However, having said that, I certainly see no bar to making whatever changes in the rest of the kernel are necessary to support the drop-in of one of these stacks (probably the NRL one). -GAWollman -- From owner-freebsd-current Thu Apr 3 07:41:36 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id HAA28407 for current-outgoing; Thu, 3 Apr 1997 07:41:36 -0800 (PST) Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id HAA28397 for ; Thu, 3 Apr 1997 07:41:28 -0800 (PST) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.8.5/8.8.5) id KAA04665; Thu, 3 Apr 1997 10:41:19 -0500 (EST) Date: Thu, 3 Apr 1997 10:41:19 -0500 (EST) From: Garrett Wollman Message-Id: <199704031541.KAA04665@khavrinen.lcs.mit.edu> To: Peter Dufault Cc: current@freebsd.org Subject: I've survived make world. In-Reply-To: <199704030605.BAA03118@hda.hda.com> References: <199704022357.BAA13237@vector.jhs.no_domain> <199704030605.BAA03118@hda.hda.com> Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk < said: > I've survived make world from Monday. On a Compaq Presario of all things > with no SCSI. I've built world twice with that build. It has been > solid as a single user workstation. I built a kernel on Monday and suffered from the ``crashing X'' phenomenon. Only for me, it was worse than others have reported because it didn't actually crash the system, only the server. Since I use xdm, that got me into an infinite loop which I could not easily break out of since the server was constantly being restarted and switching VTs. I haven't tried to build another kernel since then, as I've seen no evidence that anyone has actually figured out the real problem. -GAWollman -- Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same wollman@lcs.mit.edu | O Siem / The fires of freedom Opinions not those of| Dance in the burning flame MIT, LCS, CRS, or NSA| - Susan Aglukark and Chad Irschick From owner-freebsd-current Thu Apr 3 07:52:58 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id HAA28909 for current-outgoing; Thu, 3 Apr 1997 07:52:58 -0800 (PST) Received: from hda.hda.com (hda-bicnet.bicnet.net [207.198.1.121]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id HAA28903 for ; Thu, 3 Apr 1997 07:52:52 -0800 (PST) Received: (from dufault@localhost) by hda.hda.com (8.8.5/8.8.5) id KAA03814 for current@freebsd.org; Thu, 3 Apr 1997 10:50:35 -0500 (EST) From: Peter Dufault Message-Id: <199704031550.KAA03814@hda.hda.com> Subject: Re: I've survived make world. In-Reply-To: <199704031541.KAA04665@khavrinen.lcs.mit.edu> from Garrett Wollman at "Apr 3, 97 10:41:19 am" To: current@freebsd.org Date: Thu, 3 Apr 1997 10:50:34 -0500 (EST) X-Mailer: ELM [version 2.4ME+ PL25 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > I built a kernel on Monday and suffered from the ``crashing X'' > phenomenon... I have no X-server as I have no monitor on that system. I'll start it up later and see what happens. -- Peter Dufault (dufault@hda.com) Realtime Machine Control and Simulation HD Associates, Inc. Voice: 508 433 6936 From owner-freebsd-current Thu Apr 3 09:13:33 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id JAA03264 for current-outgoing; Thu, 3 Apr 1997 09:13:33 -0800 (PST) Received: from nlsystems.com (nlsys.demon.co.uk [158.152.125.33]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id JAA03252 for ; Thu, 3 Apr 1997 09:13:28 -0800 (PST) Received: from herring.nlsystems.com (herring.nlsystems.com [10.0.0.2]) by nlsystems.com (8.8.5/8.8.5) with SMTP id SAA04730; Thu, 3 Apr 1997 18:12:22 +0100 (BST) Date: Thu, 3 Apr 1997 18:12:22 +0100 (BST) From: Doug Rabson To: Satoshi Asami cc: dufault@hda.com, current@freebsd.org Subject: Re: I've survived make world. In-Reply-To: <199704031036.CAA17928@silvia.HIP.Berkeley.EDU> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Thu, 3 Apr 1997, Satoshi Asami wrote: > * I've survived make world from Monday. On a Compaq Presario of all things > * with no SCSI. I've built world twice with that build. It has been > * solid as a single user workstation. > > I've survived a make world from 3/24, 3/26 and 3/31. (In fact, this > is the machine that "packages-current" is built from now.) This is a > P6-200 with an IDE system disk and 3940W with a Seagate ST15150W. > > However, the NFS client appears to be hopelessly broken (I don't know > about the NFS server, this machine isn't one). I initially had the > ports/distfiles pointing to a directory on an NFS server (running > FreeBSD-2.1.5). At some point during the package builds, a process > locks up trying to read/write a distfile, and the whole NFS system > went down on this machine (I could still login as "root", as long as I > didn't try to touch NFS-mounted directories). I changed > ports/distfiles to a local directory and it appears to be fairly > stable since then. I can reproduce this reliably on my test system now. Just run make world (nfs mounted source, local obj), cvs update (nfs mounted source and dest) and rm -rf largetree (nfs mounted) all at the same time. I should have a fix for this tomorrow. -- Doug Rabson Mail: dfr@nlsystems.com Nonlinear Systems Ltd. Phone: +44 181 951 1891 From owner-freebsd-current Thu Apr 3 09:26:05 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id JAA04007 for current-outgoing; Thu, 3 Apr 1997 09:26:05 -0800 (PST) Received: from xoca-160.ssc.af.mil (root@XOCA-160.SSG.GUNTER.AF.MIL [143.158.36.160]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id JAA03980 for ; Thu, 3 Apr 1997 09:25:53 -0800 (PST) Received: from xoca-160.ssg.gunter.af.mil (cgagnon@xoca-160.ssg.gunter.af.mil [143.158.36.160]) by xoca-160.ssc.af.mil with SMTP (8.7.5/8.7.3) id LAA04849 for ; Thu, 3 Apr 1997 11:29:32 -0600 (CST) Message-ID: <3343E8FB.2CAE@xoca-160.ssc.af.mil> Date: Thu, 03 Apr 1997 11:29:31 -0600 From: Chuck Gagnon Organization: SSG/XOCA X-Mailer: Mozilla 3.0Gold (X11; I; HP-UX B.10.20 9000/715) MIME-Version: 1.0 To: FreeBSD-Current Subject: Hello Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I'm Sorry about this but for some reason I am no longer getting any mail from this list. I got a reply from both my unsubscribe and subscribe (in that order), but nothing else. If anyone gets this could you please let me know (I feel so alone). -- SrA Charles G. Gagnon Jr. | Email:cgagnon@xoca-160.ssg.gunter.af.mil From owner-freebsd-current Thu Apr 3 10:31:30 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id KAA07364 for current-outgoing; Thu, 3 Apr 1997 10:31:30 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.50]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id KAA07357 for ; Thu, 3 Apr 1997 10:31:26 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id LAA16506; Thu, 3 Apr 1997 11:13:35 -0700 From: Terry Lambert Message-Id: <199704031813.LAA16506@phaeton.artisoft.com> Subject: Re: Terry's changes (was Re: ufs lock panic in -current) To: phk@critter.dk.tfs.com (Poul-Henning Kamp) Date: Thu, 3 Apr 1997 11:13:35 -0700 (MST) Cc: nate@mt.sri.com, terry@lambert.org, jkh@time.cdrom.com, current@freebsd.org In-Reply-To: <1166.860048163@critter> from "Poul-Henning Kamp" at Apr 3, 97 08:16:03 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > >Then quit bitching about FreeBSD not accepting your patches. You've > >been asked to provide them in an 'easy to vend' manner, and you've > >refused stating it's too much work. Then, PHK and others have stated, > >upload your whole store, and you're unwilling to do that either. > > Well, I'm not sure he wasn't willing to, but I belive that last time > we went over that Terry ran into a terrible string of bad luck. First > his disk crashed, then his powersupply died and finally the city-council > banned all export of non-zero valued bits or something so he has to > invent and code a encryption routine that would only outbut zero bits... Actually, I suffered a compression fracture of my L1 vertebra, and did not get out of the back-brace until 8 weeks ago. It may astound you that someone recovering from a broken back would not be at full capacity the day after the injury. Maybe you Danes are just made of sterner stuff than us Americans... > I remember when I received Terrys much talked about version of the SMP > prototype. The only difference was that it could still not even get > close to working and he had addded a couple of comments. This was Jack Vogel's code, and all I did was update the code to the new initialization method, obtain the missing header file not in Jacks posted patch set, and organize the boot build so that the code would build. This was not *my* SMP prototype, and it required that you start with the October 10th, 1994 code that Jack started with to get correct locore.s code without the stack frame and other changes introduced since then. If you had started with the code of the date specified, the patches would apply cleanly, and SMP motherboards meeting the Intel MP Specification version 1.1 and with the optional MP Configuration table in BIOS (like the ASUS board I bought and the ASUS board that Walnut Creek CDROM loaned to Jack) would come up with two processors running. Much like if you had started with the 16 June 1995 tree date specified in my "grand unified patch set", the patch set would have applied cleanly, either as two deltas (the first set was admittedly incomplete -- I said as much at the time) or as a whole (when you didn't want to apply two sets of patches, I supplied them as one set). > Is it just because I'm danish that I'm thinking of H.C.Andersens > tale "The emperors new clothes" ? > > Terry's code doesn't exist. Jeffrey Hsu had the full "one set" which I supplied you, and was able to deal with it to get a running system. I still don't know what your problem was with them. Both Julian Elischer and John Dyson (sorry I forgot about John) have had copies of the demanded "scaled down" set since before the Lite2 merge. I have been patiently waiting for the merge to be completed so that they will be able to tell the difference between general bugs and those I may have introduced. I will continue to wait. 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 Apr 3 11:29:16 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id LAA10795 for current-outgoing; Thu, 3 Apr 1997 11:29:16 -0800 (PST) Received: from chess.inetspace.com ([206.50.163.14]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id LAA10786 for ; Thu, 3 Apr 1997 11:29:08 -0800 (PST) Received: (from kgor@localhost) by chess.inetspace.com (8.8.5/8.7.3) id NAA00229; Thu, 3 Apr 1997 13:27:31 -0600 (CST) Date: Thu, 3 Apr 1997 13:27:31 -0600 (CST) Message-Id: <199704031927.NAA00229@chess.inetspace.com> From: "Kent S. Gordon" To: freebsd-current@freebsd.org Subject: Hang on boot in recent -current kernels Mime-Version: 1.0 (generated by tm-edit 7.105) Content-Type: text/plain; charset=US-ASCII Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I have not been able to boot -current kernels using sources after about March 23. The boot hangs after getting the message scbus0 at bt0 bus 0. What suggests do people have for me to try in debugging this problem. I have attached below the output of the boot from the latest working kernel that I have plus my kernel config file. Apr 2 11:03:23 chess /kernel.good: Copyright (c) 1992-1997 FreeBSD Inc. Apr 2 11:03:23 chess /kernel.good: Copyright (c) 1982, 1986, 1989, 1991, 1993 Apr 2 11:03:23 chess /kernel.good: The Regents of the University of California. All rights reserved. Apr 2 11:03:23 chess /kernel.good: FreeBSD 3.0-CURRENT #0: Thu Mar 20 06:10:23 CST 1997 Apr 2 11:03:23 chess /kernel.good: root@chess.inetspace.com:/usr/src/sys/compile/CHESS Apr 2 11:03:23 chess /kernel.good: CPU: i486DX (486-class CPU) Apr 2 11:03:23 chess /kernel.good: real memory = 16777216 (16384K bytes) Apr 2 11:03:23 chess /kernel.good: avail memory = 14794752 (14448K bytes) Apr 2 11:03:24 chess /kernel.good: Probing for devices on the ISA bus: Apr 2 11:03:24 chess /kernel.good: sc0 at 0x60-0x6f irq 1 on motherboard Apr 2 11:03:24 chess /kernel.good: sc0: VGA color <16 virtual consoles, flags=0x0> Apr 2 11:03:24 chess /kernel.good: ed0 at 0x300-0x31f irq 5 on isa Apr 2 11:03:24 chess /kernel.good: ed0: address 00:00:e8:cb:ac:1a, type NE2000 (16 bit) Apr 2 11:03:24 chess /kernel.good: sio0 at 0x3f8-0x3ff irq 4 on isa Apr 2 11:03:24 chess /kernel.good: sio0: type 16550A Apr 2 11:03:24 chess /kernel.good: sio1 at 0x2f8-0x2ff irq 3 on isa Apr 2 11:03:24 chess /kernel.good: sio1: type 16550A Apr 2 11:03:24 chess /kernel.good: lpt0 at 0x378-0x37f irq 7 on isa Apr 2 11:03:24 chess /kernel.good: lpt0: Interrupt-driven port Apr 2 11:03:24 chess /kernel.good: lp0: TCP/IP capable interface Apr 2 11:03:25 chess /kernel.good: fdc0 at 0x3f0-0x3f7 irq 6 drq 2 on isa Apr 2 11:03:25 chess /kernel.good: fdc0: NEC 765 Apr 2 11:03:25 chess /kernel.good: fd0: 1.44MB 3.5in Apr 2 11:03:25 chess /kernel.good: fd1: 1.2MB 5.25in Apr 2 11:03:25 chess /kernel.good: bt0: Bt445S/ 0-ISA(24bit) bus Apr 2 11:03:25 chess /kernel.good: bt0: Your card cannot DMA above 16MB boundary. Bounce buffering enabled. Apr 2 11:03:25 chess /kernel.good: bt0: reading board settings, dma=5, int=11 Apr 2 11:03:25 chess /kernel.good: bt0: version 3.36, fast sync, parity, 32 mbxs, 32 ccbs Apr 2 11:03:25 chess /kernel.good: bt0: targ 0 sync rate=10.00MB/s(100ns), offset=15 Apr 2 11:03:25 chess /kernel.good: bt0: targ 1 sync rate=10.00MB/s(100ns), offset=15 Apr 2 11:03:25 chess /kernel.good: bt0: Using Strict Round robin scheme Apr 2 11:03:25 chess /kernel.good: bt0 at 0x330 irq 11 drq 5 on isa Apr 2 11:03:26 chess /kernel.good: bt0: waiting for scsi devices to settle Apr 2 11:03:26 chess /kernel.good: scbus0 at bt0 bus 0 Apr 2 11:03:26 chess /kernel.good: sd0 at scbus0 target 0 lun 0 Apr 2 11:03:26 chess /kernel.good: sd0: type 0 fixed SCSI 2 Apr 2 11:03:26 chess /kernel.good: sd0: Direct-Access 1908MB (3907911 512 byte sectors) Apr 2 11:03:26 chess /kernel.good: sd1 at scbus0 target 1 lun 0 Apr 2 11:03:26 chess /kernel.good: sd1: type 0 fixed SCSI 2 Apr 2 11:03:26 chess /kernel.good: sd1: Direct-Access 1006MB (2061108 512 byte sectors) Apr 2 11:03:26 chess /kernel.good: npx0 on motherboard Apr 2 11:03:26 chess /kernel.good: npx0: INT 16 interface Apr 2 11:03:26 chess /kernel.good: changing root device to sd0a # # GGZOO -- Cyrix 586/100 with BT controller # # For more information read the handbook part System Administration -> # Configuring the FreeBSD Kernel -> The Configuration File. # The handbook is available in /usr/share/doc/handbook or online as # latest version from the FreeBSD World Wide Web server # # # An exhaustive list of options and more detailed explanations of the # device lines is present in the ./LINT configuration file. If you are # in doubt as to the purpose or necessity of a line, check first in LINT. # # $Id: GENERIC,v 1.78 1996/11/16 01:09:17 gibbs Exp $ machine "i386" #cpu "I386_CPU" cpu "I486_CPU" cpu "I586_CPU" cpu "I686_CPU" ident GGZOO maxusers 10 #options MATH_EMULATE #Support for x87 emulation options INET #InterNETworking options FFS #Berkeley Fast Filesystem options NFS #Network Filesystem options MSDOSFS #MSDOS Filesystem options "CD9660" #ISO 9660 Filesystem options PROCFS #Process filesystem options "COMPAT_43" #Compatible with BSD 4.3 [KEEP THIS!] #options SCSI_DELAY=15 #Be pessimistic about Joe SCSI device options SCSI_DELAY=5 #Be pessimistic about Joe SCSI device options BOUNCE_BUFFERS #include support for DMA bounce buffers options UCONSOLE #Allow users to grab the console options FAILSAFE #Be conservative options USERCONFIG #boot -c editor options VISUAL_USERCONFIG #visual boot -c editor options SYSVSHM options SYSVSEM options SYSVMSG options "AUTO_EOI_1" #faster interrupts config kernel root on wd0 controller isa0 #I have a VLB, but no aha28xx cards, that think they are on a eisa bus. #controller eisa0 #controller pci0 controller fdc0 at isa? port "IO_FD1" bio irq 6 drq 2 vector fdintr disk fd0 at fdc0 drive 0 disk fd1 at fdc0 drive 1 #tape ft0 at fdc0 drive 2 #controller wdc0 at isa? port "IO_WD1" bio irq 14 vector wdintr #disk wd0 at wdc0 drive 0 #disk wd1 at wdc0 drive 1 #controller wdc1 at isa? port "IO_WD2" bio irq 15 vector wdintr #disk wd2 at wdc1 drive 0 #disk wd3 at wdc1 drive 1 #options ATAPI #Enable ATAPI support for IDE bus #options ATAPI_STATIC #Don't do it as an LKM #device wcd0 #IDE CD-ROM # A single entry for any of these controllers (ncr, ahb, ahc) is sufficient # for any number of installed devices. #controller ncr0 #controller ahb0 #controller ahc0 controller bt0 at isa? port "IO_BT0" bio irq ? vector bt_isa_intr #controller uha0 at isa? port "IO_UHA0" bio irq ? drq 5 vector uhaintr #controller aha0 at isa? port "IO_AHA0" bio irq ? drq 5 vector ahaintr #controller aic0 at isa? port 0x340 bio irq 11 vector aicintr #controller nca0 at isa? port 0x1f88 bio irq 10 vector ncaintr #controller nca1 at isa? port 0x350 bio irq 5 vector ncaintr #controller sea0 at isa? bio irq 5 iomem 0xc8000 iosiz 0x2000 vector seaintr controller scbus0 device sd0 device od0 #See LINT for possible `od' options. device st0 device cd0 #Only need one of these, the code dynamically grows #device wt0 at isa? port 0x300 bio irq 5 drq 1 vector wtintr #device mcd0 at isa? port 0x300 bio irq 10 vector mcdintr #controller matcd0 at isa? port 0x230 bio #device scd0 at isa? port 0x230 bio # syscons is the default console driver, resembling an SCO console device sc0 at isa? port "IO_KBD" tty irq 1 vector scintr # Enable this and PCVT_FREEBSD for pcvt vt220 compatible console driver #device vt0 at isa? port "IO_KBD" tty irq 1 vector pcrint #options PCVT_FREEBSD=210 # pcvt running on FreeBSD >= 2.0.5 #options XSERVER # include code for XFree86 #options FAT_CURSOR # start with block cursor # If you have a ThinkPAD, uncomment this along with the rest of the PCVT lines #options PCVT_SCANSET=2 # IBM keyboards are non-std # Mandatory, don't remove device npx0 at isa? port "IO_NPX" irq 13 vector npxintr # # Laptop support (see LINT for more options) # #device apm0 at isa? disable # Advanced Power Management #options APM_BROKEN_STATCLOCK # Workaround some buggy APM BIOS # PCCARD (PCMCIA) support #controller crd0 #device pcic0 at crd? #device pcic1 at crd? device sio0 at isa? port "IO_COM1" tty irq 4 vector siointr device sio1 at isa? port "IO_COM2" tty irq 3 vector siointr #device sio2 at isa? disable port "IO_COM3" tty irq 5 vector siointr #device sio3 at isa? disable port "IO_COM4" tty irq 9 vector siointr device lpt0 at isa? port? tty irq 7 vector lptintr #device lpt1 at isa? port? tty #device mse0 at isa? port 0x23c tty irq 5 vector mseintr #device psm0 at isa? disable port "IO_KBD" conflicts tty irq 12 vector psmintr # Order is important here due to intrusive probes, do *not* alphabetize # this list of network interfaces until the probes have been fixed. # Right now it appears that the ie0 must be probed before ep0. See # revision 1.20 of this file. #device de0 #device fxp0 #device vx0 #device ed0 at isa? port 0x280 net irq 5 iomem 0xd8000 vector edintr #device ed1 at isa? port 0x300 net irq 5 iomem 0xd8000 vector edintr device ed0 at isa? port 0x300 net irq 5 iomem 0xd8000 vector edintr #device ie0 at isa? port 0x360 net irq 7 iomem 0xd0000 vector ieintr #device ep0 at isa? port 0x300 net irq 10 vector epintr #device fe0 at isa? port 0x300 net irq ? vector feintr #device ix0 at isa? port 0x300 net irq 10 iomem 0xd0000 iosiz 32768 vector ixintr #device le0 at isa? port 0x300 net irq 5 iomem 0xd0000 vector le_intr #device lnc0 at isa? port 0x280 net irq 10 drq 0 vector lncintr #device ze0 at isa? port 0x300 net irq 5 iomem 0xd8000 vector zeintr #device zp0 at isa? port 0x300 net irq 10 iomem 0xd8000 vector zpintr pseudo-device loop pseudo-device ether pseudo-device log #pseudo-device sl 1 # ijppp uses tun instead of ppp device #pseudo-device ppp 1 pseudo-device tun 1 pseudo-device pty 32 pseudo-device bpfilter 4 #Berkeley packet filter pseudo-device gzip # Exec gzipped a.out's # KTRACE enables the system-call tracing facility ktrace(2). # This adds 4 KB bloat to your kernel, and slightly increases # the costs of each syscall. options KTRACE #kernel tracing Kent S. Gordon Senior Software Engineer INetSpace Co. voice: (972)851-3494 fax:(972)702-0384 e-mail:kgor@inetspace.com From owner-freebsd-current Thu Apr 3 12:59:08 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id MAA15771 for current-outgoing; Thu, 3 Apr 1997 12:59:08 -0800 (PST) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id MAA15750 for ; Thu, 3 Apr 1997 12:59:00 -0800 (PST) Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id WAA27454 for freebsd-current@freebsd.org; Thu, 3 Apr 1997 22:58:58 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.8.5/8.8.5) id WAA00169; Thu, 3 Apr 1997 22:50:28 +0200 (MET DST) Message-ID: <19970403225028.UD37275@uriah.heep.sax.de> Date: Thu, 3 Apr 1997 22:50:28 +0200 From: j@uriah.heep.sax.de (J Wunsch) To: freebsd-current@freebsd.org (FreeBSD Current) Subject: Re: termcap and color References: <19970403010957.13573@hydrogen.nike.efn.org> 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: <19970403010957.13573@hydrogen.nike.efn.org>; from John-Mark Gurney on Apr 3, 1997 01:09:57 -0800 Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk As John-Mark Gurney wrote: > so: > o) I add Co, Sf, and Sb to termcap(5) Note that you should also mention that it's a matter of the application whether it even remotely thinks of using these entries or not. That's the thing with termcap (as opposed to terminfo): you can extend it beyond things that have been originally intended. Note also that XFree86's termcap entry defines two similar capabilities: AB is a synonym for Sb, and AF is a synonym for Sf. It depends on the application which one it's expecting. They also define pa#64. -- 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 Thu Apr 3 13:43:50 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id NAA18533 for current-outgoing; Thu, 3 Apr 1997 13:43:50 -0800 (PST) Received: from vector.jhs.no_domain (slip139-92-4-169.mu.de.ibm.net [139.92.4.169]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id NAA18512; Thu, 3 Apr 1997 13:43:24 -0800 (PST) Received: from vector.jhs.no_domain (localhost [127.0.0.1]) by vector.jhs.no_domain (8.7.5/8.6.9) with ESMTP id PAA02136; Thu, 3 Apr 1997 15:38:29 +0200 (MET DST) Message-Id: <199704031338.PAA02136@vector.jhs.no_domain> To: "Justin M. Seger" cc: current@freebsd.org Subject: Re: Where are the src-cur and ports-cur CTM distributions stored? From: "Julian H. Stacey" Reply-To: "Julian H. Stacey" X-Email: jhs@freebsd.org, Fallback: jhs@gil.physik.rwth-aachen.de X-Organization: Vector Systems Ltd. X-Mailer: EXMH 1.6.7, PGP available X-Address: Holz Strasse 27d, 80469 Munich, Germany X-Tel: Phone +49.89.268616, Fax +49.89.2608126, Data +49.89.26023276 X-Web: http://www.freebsd.org/~jhs/ In-reply-to: Your message of "Wed, 02 Apr 1997 19:46:14 GMT." <199704021946.TAA06671@scds.ziplink.net> Date: Thu, 03 Apr 1997 15:38:27 +0200 Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi, Reference: > Subject: Re: Where are the src-cur and ports-cur CTM distributions stored? ftp:eel.dataplex.net/pub/FreeBSD/CTM/src-cur AFAIK Julian -- Julian H. Stacey jhs@freebsd.org http://www.freebsd.org/~jhs/ From owner-freebsd-current Thu Apr 3 14:04:43 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id OAA19361 for current-outgoing; Thu, 3 Apr 1997 14:04:43 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.50]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id OAA19356 for ; Thu, 3 Apr 1997 14:04:38 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id OAA17328 for current@freebsd.org; Thu, 3 Apr 1997 14:47:55 -0700 From: Terry Lambert Message-Id: <199704032147.OAA17328@phaeton.artisoft.com> Subject: FS PATCHES To: current@freebsd.org Date: Thu, 3 Apr 1997 14:47:55 -0700 (MST) X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Nate, Jordan, Poul, et al: 1) My root handling modifications to the tree as it was on 25 Jul 1995 are: ftp://freefall.cdrom.com/~terry/root_mods.tar.gz. They have been there since 27 Jul 1995. 2) My original FS layering patches to the tree as it was on 10 Oct 1995 (including "unrelated" changes) are: ftp://freefall.cdrom.com/~terry/fs_layer_patch.gz They have been there since 28 Oct 1995. 3) My UNICODE support changes to the tree as it was on 25 Aug 1995 are: ftp://freefall.cdrom.com/~terry/UNI.diff.gz They have been there since 25 Aug 1995. 4) My SYSINIT patches to the tree as it was on 19 Aug 1995 are: ftp://freefall.cdrom.com/~terry/SYSINIT.tar.gz They have been there since 19 Aug 1995 (as you well know, since they were integrated). 5) My kernel support for NFS locking patches to the tree as it was on 20 Aug 1995 are: ftp://freefall.cdrom.com/~terry/RLOCK.tar.gz They have been there since 20 Aug 1995 (as Jordan well knows, since I provided them to support him in his internals class, where he promised to work on NFS locking). 6) My simplified patches for the namei/nameifree layering fixes and support of the NDINIT() nameiop flag "EXCLUDE" for redundant code reduction in the "lookup on file for CREATE when file exists" are: ftp://freefall.cdrom.com/~terry/namei.diff They have just been uploaded, but they were provided to Julian Elisher, John Dyson, and others who were willing to review them for integration instead of "talking about what a terrible person Terry is". The problem is definitely not one of me not providing code, it's one of people ignoring it when I do. 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 Apr 3 14:13:14 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id OAA19787 for current-outgoing; Thu, 3 Apr 1997 14:13:14 -0800 (PST) Received: from who.cdrom.com (who.cdrom.com [204.216.27.3]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id OAA19781; Thu, 3 Apr 1997 14:13:10 -0800 (PST) Received: from mail.vlsi.fi (mail.vlsi.fi [195.74.10.147]) by who.cdrom.com (8.8.5/8.6.11) with ESMTP id OAA18712 ; Thu, 3 Apr 1997 14:12:33 -0800 (PST) Received: (from smap@localhost) by mail.vlsi.fi (8.7.6/8.7.3) id BAA27583; Fri, 4 Apr 1997 01:04:33 +0300 (EET DST) Received: from vlsi1.vlsi.fi(193.64.2.2) by mail.vlsi.fi via smap (V1.3) id sma027579; Fri Apr 4 01:04:18 1997 Received: from layout.vlsi.fi by vlsi1.vlsi.fi with ESMTP (1.37.109.16/16.2) id AA244335056; Fri, 4 Apr 1997 01:04:17 +0300 Received: by layout.vlsi.fi (1.37.109.15/16.2) id AA156415056; Fri, 4 Apr 1997 01:04:16 +0300 Date: Fri, 4 Apr 1997 01:04:16 +0300 Message-Id: <199704032204.AA156415056@layout.vlsi.fi> From: Ville Eerola To: Burton Sampley Cc: Adam Hawks , questions@freebsd.org, current@freebsd.org Subject: RE: more problems w/ fetchmail In-Reply-To: References: X-Mailer: VM Version 5.93 (beta) under GNU Emacs 19.29.6 Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Burton Sampley writes: > Thanks for the reply. As strange as this may seem, I just happen to have > a xterm open with netstat -r before I started routed. I see exactly what > you mean. I'm going to cc this message to both groups and see if anybody > has a solution. > > Here's the info: > > bash# netstat -r > Routing tables > > Internet: > Destination Gateway Flags Refs Use Netif > Expire > default ns3.best.com UGSc 4 0 tun0 > localhost localhost UH 0 0 lo0 > 192.168.1 link#1 UC 0 0 > ns3.best.com bsampley UH 5 10 tun0 > bash# routed > bash# kill 1733 [routed] > bash# netstat -r > Routing tables > > Internet: > Destination Gateway Flags Refs Use Netif > Expire > default ns3.best.com UGSc 4 0 tun0 > localhost localhost UH 0 225 lo0 > 192.168.1 link#1 UC 0 0 > ns3.best.com bsampley UH 5 124 tun0 > bsampley localhost UH 0 199 lo0 > bash# > > Anybody know what I need to change so the routing table looks liks the > second version without having to run and kill routed? Yeah, Do you see the difference: > bsampley localhost UH 0 199 lo0 was added by routed. You can get this efect by including the following into your /etc/sysconfig file: > static_routes="loopback" > route_loopback="${hostname} localhost" This will create the static route to your host using the loopback interface. From the shell you can say: # route add bsampley localhost Regards, Ville -- Ville.Eerola@vlsi.fi VLSI Solution Oy Tel:+358 3 3165579 Hermiankatu 6-8 C Fax:+358 3 3165220 FIN-33720 Tampere, Finland From owner-freebsd-current Thu Apr 3 14:19:41 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id OAA20306 for current-outgoing; Thu, 3 Apr 1997 14:19:41 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.50]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id OAA20292; Thu, 3 Apr 1997 14:19:31 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id OAA17416; Thu, 3 Apr 1997 14:59:10 -0700 From: Terry Lambert Message-Id: <199704032159.OAA17416@phaeton.artisoft.com> Subject: Re: ufs lock panic in -current To: sos@ravenock.cybercity.dk (Søren Schmidt) Date: Thu, 3 Apr 1997 14:59:09 -0700 (MST) Cc: terry@lambert.org, jkh@time.cdrom.com, phk@critter.dk.tfs.com, ache@nagual.ru, dyson@FreeBSD.org, bde@zeta.org.au, current@FreeBSD.org In-Reply-To: <199704030711.JAA08723@ravenock.cybercity.dk> from "Søren Schmidt" at Apr 3, 97 09:10:58 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > [Alot of Terry bla bla deleted] > > > I'd rather have no editiorial criticism than destructive editorial > > criticism, thank you. Giving you the changes incrementally seems > > to be the only reliable way to achieve this. > > So again Terry exactly WHEN do we get the first chunk then ?? You get it one year and nine months ago, that I can document. See my most resent posting reminding Jordan, et al. of the URL's, and providing the code I already provided to Julian and John. 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 Apr 3 15:00:05 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id PAA22516 for current-outgoing; Thu, 3 Apr 1997 15:00:05 -0800 (PST) Received: from time.cdrom.com (root@time.cdrom.com [204.216.27.226]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id PAA22485 for ; Thu, 3 Apr 1997 15:00:01 -0800 (PST) Received: from time.cdrom.com (jkh@localhost [127.0.0.1]) by time.cdrom.com (8.8.5/8.6.9) with ESMTP id OAA16644; Thu, 3 Apr 1997 14:59:05 -0800 (PST) To: Terry Lambert cc: current@freebsd.org Subject: Re: FS PATCHES In-reply-to: Your message of "Thu, 03 Apr 1997 14:47:55 MST." <199704032147.OAA17328@phaeton.artisoft.com> Date: Thu, 03 Apr 1997 14:59:04 -0800 Message-ID: <16640.860108344@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > The problem is definitely not one of me not providing code, it's > one of people ignoring it when I do. Not at all. This is the first truly definitive roadmap of your work I've ever seen, and I personally am going to copy each and every item into a checklist and start talking to the various kernel hacks about evaluating all of them, not checking something off until I'm sure that you've either seen your changes incorporated or have been given sufficient and fair feedback as to why they cannot be. Jordan From owner-freebsd-current Thu Apr 3 15:24:43 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id PAA25034 for current-outgoing; Thu, 3 Apr 1997 15:24:43 -0800 (PST) Received: from pdx1.world.net (pdx1.world.net [192.243.32.18]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id PAA25022 for ; Thu, 3 Apr 1997 15:24:38 -0800 (PST) From: proff@suburbia.net Received: from suburbia.net (suburbia.net [203.4.184.1]) by pdx1.world.net (8.7.5/8.7.3) with SMTP id PAA16384 for ; Thu, 3 Apr 1997 15:26:49 -0800 (PST) Received: (qmail 12621 invoked by uid 110); 3 Apr 1997 11:48:27 -0000 Message-ID: <19970403114827.12620.qmail@suburbia.net> Subject: Re: ufs lock panic in -current In-Reply-To: <199704030138.SAA18970@rocky.mt.sri.com> from Nate Williams at "Apr 2, 97 06:38:32 pm" To: nate@mt.sri.com (Nate Williams) Date: Thu, 3 Apr 1997 21:48:27 +1000 (EST) Cc: terry@lambert.org, jkh@time.cdrom.com, phk@critter.dk.tfs.com, current@freebsd.org X-Mailer: ELM [version 2.4ME+ PL28 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > One would think that 2 years would be long enough to earn citizenship > > rights. You don't make these requirements of your other contributors. > > Sure we do. You've yet to show that you can 'play by the rules', and > your recent temper-tantrum only shows that you haven't changed your > tactics nor your willingness to work with the team. > > > Nate I don't see this alienating a potentially valuable contributor very helpful. The 'war' to be won is encouraging talent, not proving that Terry has sinned. Julian. From owner-freebsd-current Thu Apr 3 15:29:37 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id PAA25548 for current-outgoing; Thu, 3 Apr 1997 15:29:37 -0800 (PST) Received: from dyslexic.phoenix.net (root@dyslexic.phoenix.net [199.3.233.7]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id PAA25511 for ; Thu, 3 Apr 1997 15:29:25 -0800 (PST) Received: (from gemohler@localhost) by dyslexic.phoenix.net (8.8.5/8.7.3) id RAA28001; Thu, 3 Apr 1997 17:28:06 -0600 (CST) Date: Thu, 3 Apr 1997 17:28:06 -0600 (CST) From: Geoff Mohler X-Sender: gemohler@dyslexic.phoenix.net To: current@freebsd.org Subject: Re: FS PATCHES In-Reply-To: <16640.860108344@time.cdrom.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Jordan: Gotta bug I found.. When upgrading to 2.2x *and possible 2.1.7 I forget* the upgrade path forgets about my fpa0 device in the sysconfig file. It retains the ifconfig statement(s) for fpa0, but drops fpa0 as a valid interface assignment. =-=-=-=-=- ROMANI ITE DOMUM Geoff Mohler Operations Engineer Charter Communications/Phoenix Data Net From owner-freebsd-current Thu Apr 3 15:33:02 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id PAA25924 for current-outgoing; Thu, 3 Apr 1997 15:33:02 -0800 (PST) Received: from austin.polstra.com (austin.polstra.com [206.213.73.10]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id PAA25912 for ; Thu, 3 Apr 1997 15:32:58 -0800 (PST) Received: from austin.polstra.com (jdp@localhost) by austin.polstra.com (8.8.5/8.8.5) with ESMTP id PAA18722; Thu, 3 Apr 1997 15:32:03 -0800 (PST) Message-Id: <199704032332.PAA18722@austin.polstra.com> To: terry@lambert.org Subject: Re: ufs lock panic in -current Newsgroups: polstra.freebsd.current In-Reply-To: <199704032159.OAA17416@phaeton.artisoft.com> References: <199704032159.OAA17416@phaeton.artisoft.com> Organization: Polstra & Co., Seattle, WA Cc: current@freebsd.org Date: Thu, 03 Apr 1997 15:32:03 -0800 From: John Polstra Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In article <199704032159.OAA17416@phaeton.artisoft.com>, Terry Lambert wrote: > See > my most resent posting [...] Aha! So you admit it, then. Just as I've suspected all along. All your long-winded postings are really just a single one, resent over and over again. :-) -- John Polstra jdp@polstra.com John D. Polstra & Co., Inc. Seattle, Washington USA "Self-knowledge is always bad news." -- John Barth From owner-freebsd-current Thu Apr 3 15:45:27 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id PAA26924 for current-outgoing; Thu, 3 Apr 1997 15:45:27 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.50]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id PAA26915 for ; Thu, 3 Apr 1997 15:45:23 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id QAA17735 for current@freebsd.org; Thu, 3 Apr 1997 16:28:39 -0700 From: Terry Lambert Message-Id: <199704032328.QAA17735@phaeton.artisoft.com> Subject: DISCUSS: system open file table To: current@freebsd.org Date: Thu, 3 Apr 1997 16:28:39 -0700 (MST) X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I'm looking for discussion, pro and con. ---------------------------------------------------------------------------- I went looking into the system open file table today. I was mildly surprised at what I found. I would like to suggest functionally seperating process descriptor management from system open file table management. The purpose of this seperation would be to provide for the possibility of entries in the system open file table which do not exist in a per process open file table anywhere. The point of this exercise is to enable the creation of a descriptor based kernel level file I/O interface. This interface would be used both by the system calls which deal with per process descriptor manipulation, and it would also be usable within the kernel itself. This would be useful for: 1) File I/O in a kernel threading environment 2) File I/O from within some types of file system stacking layers; most notably "quota" and "ACL", but it would also be useful for SEF's suggested method of providing persistance for a devfs. 3) File I/O on non-normal files (sockets for CIFS/SMB and AllpeTalk file system support, pipes for FS->user event notification such as directory modifications being signalled to file browsers, etc.). 4) Any other kernel file I/O operations which rely on stored credentials established at file open(*). (*) The descriptor f_type and f_ops field are not relevent arguments in favor of this, since they are cruft which should be diked out. The facilities would be similar in nature to those provided by the AIX kernel. ---------------------------------------------------------------------------- From owner-freebsd-current Thu Apr 3 16:00:12 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id QAA27866 for current-outgoing; Thu, 3 Apr 1997 16:00:12 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.50]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id QAA27858 for ; Thu, 3 Apr 1997 16:00:06 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id QAA17773 for current@freebsd.org; Thu, 3 Apr 1997 16:43:22 -0700 From: Terry Lambert Message-Id: <199704032343.QAA17773@phaeton.artisoft.com> Subject: DISCUSS: vnode references as open instances To: current@freebsd.org Date: Thu, 3 Apr 1997 16:43:21 -0700 (MST) X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I am looking for discussion, pro and con. ----------------------------------------------------------------------------- I believe that vnode references should be treated as counting semaphores. Currently, reference holders are net required to count references in all cases. The purpose of this change would be to significantly clean up the vnode reference interactions to provide a meaningful seperation between vnode maintenance and vnode reclamation, with the eventual intention of removing the need for vclean() and the duplication of code in each per FS VOP_LOCK implementation. This change would affect the directory name lookup cache code (for which a vnode reference in a cache would be very much the same as an open instance for a vnode reference by a system open file table reference), as well as several other subsystems. Though vnodes are currently globally accounted, I beleive that there should be a per FS interface, initially to the global accounting interface, for freeing vnodes in an FS specific manner. The eventual intent of this change is to allow per-FS management of vnodes as part of the FS's [*,i]node pool, and to therefore relieve the need for global vnode pool management, and thus global recovery of vnodes for reuse. This would be similar in scope to the SVR4 vnode management scheme, as described in "The Magic Garden Explained" and the _Bach_ book. One large benefit of this technique would be to allow the recovery of unreferenced vnodes from per FS "second chance" caches, like the FFS "ihash" facility, and therfore the recovery of perfectly valid memory pages that refere to a referenced per FS object. Currently, there is no recovery mechanism whereby the valid pages can be re-referenced for use once the vnode had been disassociated from the per-FS object, but not from the valid pages. When a reference which references these pages occurs, the data, though in core, cannot be reclaimed, and must be reread from disk. ----------------------------------------------------------------------------- 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 Apr 3 16:02:16 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id QAA28062 for current-outgoing; Thu, 3 Apr 1997 16:02:16 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.50]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id QAA28050 for ; Thu, 3 Apr 1997 16:02:04 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id QAA17785; Thu, 3 Apr 1997 16:44:47 -0700 From: Terry Lambert Message-Id: <199704032344.QAA17785@phaeton.artisoft.com> Subject: Re: ufs lock panic in -current To: jdp@polstra.com (John Polstra) Date: Thu, 3 Apr 1997 16:44:46 -0700 (MST) Cc: terry@lambert.org, current@freebsd.org In-Reply-To: <199704032332.PAA18722@austin.polstra.com> from "John Polstra" at Apr 3, 97 03:32:03 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > See > > my most resent posting [...] > > Aha! So you admit it, then. Just as I've suspected all along. All your > long-winded postings are really just a single one, resent over and > over again. > > :-) "The squeaky wheel gets the grease". From owner-freebsd-current Thu Apr 3 16:20:50 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id QAA29043 for current-outgoing; Thu, 3 Apr 1997 16:20:50 -0800 (PST) Received: from time.cdrom.com (root@time.cdrom.com [204.216.27.226]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id QAA29038 for ; Thu, 3 Apr 1997 16:20:46 -0800 (PST) Received: from time.cdrom.com (jkh@localhost [127.0.0.1]) by time.cdrom.com (8.8.5/8.6.9) with ESMTP id QAA17044; Thu, 3 Apr 1997 16:20:47 -0800 (PST) To: Geoff Mohler cc: current@freebsd.org Subject: Re: FS PATCHES In-reply-to: Your message of "Thu, 03 Apr 1997 17:28:06 CST." Date: Thu, 03 Apr 1997 16:20:47 -0800 Message-ID: <17041.860113247@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > When upgrading to 2.2x *and possible 2.1.7 I forget* the upgrade path > forgets about my fpa0 device in the sysconfig file. Hmmm. And fpa0 was probed in the 2nd pass? I can't imagine why it would be occluded. If you could explain to me in private email a little more detail on what exactly you did? Jordan From owner-freebsd-current Thu Apr 3 16:27:11 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id QAA29883 for current-outgoing; Thu, 3 Apr 1997 16:27:11 -0800 (PST) Received: from Kitten.mcs.com (Kitten.mcs.com [192.160.127.90]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id QAA29877 for ; Thu, 3 Apr 1997 16:27:02 -0800 (PST) Received: from Jupiter.Mcs.Net (karl@Jupiter.mcs.net [192.160.127.88]) by Kitten.mcs.com (8.8.5/8.8.2) with ESMTP id SAA18837 for ; Thu, 3 Apr 1997 18:26:55 -0600 (CST) Received: (from karl@localhost) by Jupiter.Mcs.Net (8.8.5/8.8.2) id SAA26643; Thu, 3 Apr 1997 18:26:55 -0600 (CST) Message-ID: <19970403182654.29991@Jupiter.Mcs.Net> Date: Thu, 3 Apr 1997 18:26:54 -0600 From: Karl Denninger To: current@freebsd.org Subject: Oops Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.64 Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk While trying to update... /usr/local/sbin/cvsup /var/sup/cvs-supfile.cvsup Checksum mismatch for src/gnu/usr.bin/cpio/main.c,v -- will transfer entire file Checksum mismatch for src/gnu/usr.bin/cpio/rtapelib.c,v -- will transfer entire file *** *** runtime error: *** Exception "RCSError.E" not in RAISES list *** Abort trap (core dumped) -- -- Karl Denninger (karl@MCS.Net)| MCSNet - The Finest Internet Connectivity http://www.mcs.net/~karl | T1's from $600 monthly to FULL DS-3 Service | 99 Analog numbers, 77 ISDN, http://www.mcs.net/ Voice: [+1 312 803-MCS1 x219]| NOW Serving 56kbps DIGITAL on our analog lines! Fax: [+1 312 803-4929] | 2 FULL DS-3 Internet links; 400Mbps B/W Internal From owner-freebsd-current Thu Apr 3 16:36:40 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id QAA00592 for current-outgoing; Thu, 3 Apr 1997 16:36:40 -0800 (PST) Received: from root.com (implode.root.com [198.145.90.17]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id QAA00586 for ; Thu, 3 Apr 1997 16:36:37 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by root.com (8.8.5/8.6.5) with SMTP id QAA05861; Thu, 3 Apr 1997 16:36:50 -0800 (PST) Message-Id: <199704040036.QAA05861@root.com> X-Authentication-Warning: implode.root.com: localhost [127.0.0.1] didn't use HELO protocol To: Terry Lambert cc: current@FreeBSD.ORG Subject: Re: DISCUSS: system open file table In-reply-to: Your message of "Thu, 03 Apr 1997 16:28:39 MST." <199704032328.QAA17735@phaeton.artisoft.com> From: David Greenman Reply-To: dg@root.com Date: Thu, 03 Apr 1997 16:36:50 -0800 Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >4) Any other kernel file I/O operations which rely > on stored credentials established at file open(*). > > (*) The descriptor f_type and f_ops field are not > relevent arguments in favor of this, since they > are cruft which should be diked out. It's already trivially easy to do file I/O in the kernel without a file descriptor. As you know, a "file descriptor" in FreeBSD is only a mechanism to translate a per-process file handle to a kernel vnode. For this reason, the very notion of a "file descriptor" is only relevant in the context of a process. It sounds like #4 is the main thing you're after, but I fail to see how this is relevant unless you have a process context in which to do the I/O, and in that case you already have easy access to the process' credentials. -DG David Greenman Core-team/Principal Architect, The FreeBSD Project From owner-freebsd-current Thu Apr 3 17:04:29 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id RAA02132 for current-outgoing; Thu, 3 Apr 1997 17:04:29 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.50]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id RAA02119 for ; Thu, 3 Apr 1997 17:04:25 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id RAA17931; Thu, 3 Apr 1997 17:47:04 -0700 From: Terry Lambert Message-Id: <199704040047.RAA17931@phaeton.artisoft.com> Subject: Re: DISCUSS: system open file table To: dg@root.com Date: Thu, 3 Apr 1997 17:47:04 -0700 (MST) Cc: terry@lambert.org, current@FreeBSD.ORG In-Reply-To: <199704040036.QAA05861@root.com> from "David Greenman" at Apr 3, 97 04:36:50 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > >4) Any other kernel file I/O operations which rely > > on stored credentials established at file open(*). > > > > (*) The descriptor f_type and f_ops field are not > > relevent arguments in favor of this, since they > > are cruft which should be diked out. > > It's already trivially easy to do file I/O in the kernel without a file > descriptor. As you know, a "file descriptor" in FreeBSD is only a mechanism > to translate a per-process file handle to a kernel vnode. For this reason, > the very notion of a "file descriptor" is only relevant in the context of > a process. It sounds like #4 is the main thing you're after, but I fail to > see how this is relevant unless you have a process context in which to do > the I/O, and in that case you already have easy access to the process' > credentials. But... currently, a vnode reference is not the same thing as an open reference. Also, for things like a CIFS/SMBFS/AppleTalk/NetWare client, I want to be able to use credentials which are not BSD process credentials, but user credentials. If a vnode reference becomes an open reference, this resolves a lot of things, but it still doesn't resolve traversal of the system open file table, which is needed by sysctl (in general), identd (for credential vouchsafing), and for accounting reasons (when I want to unmount an FS with open files, etc.). I want to make the distinction between a cached reference and a real reference, as well, both for the file I/O in a kernel thread, and to get around some of the recent problems that come from VOP_LOCK handling two types of locks. Finally, there is the issue of taking faults in kernel mode without a process context to sleep on. I'd like to see the sleeping moved to the address of the field in the system open file table,so that the sleep handle doesn't have to know what kind of caller is making the call. 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 Apr 3 17:12:49 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id RAA02608 for current-outgoing; Thu, 3 Apr 1997 17:12:49 -0800 (PST) Received: from time.cdrom.com (root@time.cdrom.com [204.216.27.226]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id RAA02603 for ; Thu, 3 Apr 1997 17:12:45 -0800 (PST) Received: from time.cdrom.com (jkh@localhost [127.0.0.1]) by time.cdrom.com (8.8.5/8.6.9) with ESMTP id RAA17345; Thu, 3 Apr 1997 17:12:01 -0800 (PST) To: Terry Lambert cc: current@FreeBSD.ORG Subject: Re: DISCUSS: system open file table In-reply-to: Your message of "Thu, 03 Apr 1997 16:28:39 MST." <199704032328.QAA17735@phaeton.artisoft.com> Date: Thu, 03 Apr 1997 17:12:00 -0800 Message-ID: <17339.860116320@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > I would like to suggest functionally seperating process descriptor > management from system open file table management. Sounds good to me. Being able to do reasonably trivial file I/O from inside the kernel seems to make it enough of a win to go for it just on that basis alone. Gotten any nibbles from people actually willing and/or able to help you with the implmentation? Jordan From owner-freebsd-current Thu Apr 3 17:15:27 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id RAA02865 for current-outgoing; Thu, 3 Apr 1997 17:15:27 -0800 (PST) Received: from rocky.mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id RAA02855 for ; Thu, 3 Apr 1997 17:15:22 -0800 (PST) Received: (from nate@localhost) by rocky.mt.sri.com (8.7.5/8.7.3) id SAA25530; Thu, 3 Apr 1997 18:11:29 -0700 (MST) Date: Thu, 3 Apr 1997 18:11:29 -0700 (MST) Message-Id: <199704040111.SAA25530@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: current@freebsd.org Subject: Re: FS PATCHES In-Reply-To: <199704032147.OAA17328@phaeton.artisoft.com> References: <199704032147.OAA17328@phaeton.artisoft.com> X-Mailer: VM 6.22 under 19.15 XEmacs Lucid Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > Nate, Jordan, Poul, et al: ... > ftp://freefall.cdrom.com/~terry/namei.diff Thanks for the pointers! This if the *first* I've known about the code patches. Nate From owner-freebsd-current Thu Apr 3 17:24:14 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id RAA03459 for current-outgoing; Thu, 3 Apr 1997 17:24:14 -0800 (PST) Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id RAA03452 for ; Thu, 3 Apr 1997 17:24:10 -0800 (PST) Received: (from msmith@localhost) by genesis.atrad.adelaide.edu.au (8.8.5/8.7.3) id KAA16028; Fri, 4 Apr 1997 10:52:48 +0930 (CST) From: Michael Smith Message-Id: <199704040122.KAA16028@genesis.atrad.adelaide.edu.au> Subject: Re: DISCUSS: system open file table In-Reply-To: <199704032328.QAA17735@phaeton.artisoft.com> from Terry Lambert at "Apr 3, 97 04:28:39 pm" To: terry@lambert.org (Terry Lambert) Date: Fri, 4 Apr 1997 10:52:48 +0930 (CST) Cc: current@freebsd.org X-Mailer: ELM [version 2.4ME+ PL28 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Terry Lambert stands accused of saying: > > I would like to suggest functionally seperating process descriptor > management from system open file table management. > > The purpose of this seperation would be to provide for the > possibility of entries in the system open file table which do > not exist in a per process open file table anywhere. One could suggest that, as an alternative, one treated the kernel as a process (or possibly create another kernel process which exists solely to own files on the kernel's behalf). I make no judgement as to whether this is a "better" approach. -- ]] Mike Smith, Software Engineer msmith@gsoft.com.au [[ ]] Genesis Software genesis@gsoft.com.au [[ ]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[ ]] realtime instrument control. (ph) +61-8-8267-3493 [[ ]] Unix hardware collector. "Where are your PEZ?" The Tick [[ From owner-freebsd-current Thu Apr 3 17:26:51 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id RAA03784 for current-outgoing; Thu, 3 Apr 1997 17:26:51 -0800 (PST) Received: from root.com (implode.root.com [198.145.90.17]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id RAA03770 for ; Thu, 3 Apr 1997 17:26:47 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by root.com (8.8.5/8.6.5) with SMTP id RAA06069; Thu, 3 Apr 1997 17:27:00 -0800 (PST) Message-Id: <199704040127.RAA06069@root.com> X-Authentication-Warning: implode.root.com: localhost [127.0.0.1] didn't use HELO protocol To: Terry Lambert cc: current@FreeBSD.ORG Subject: Re: DISCUSS: system open file table In-reply-to: Your message of "Thu, 03 Apr 1997 17:47:04 MST." <199704040047.RAA17931@phaeton.artisoft.com> From: David Greenman Reply-To: dg@root.com Date: Thu, 03 Apr 1997 17:27:00 -0800 Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >> >4) Any other kernel file I/O operations which rely >> > on stored credentials established at file open(*). >> > >> > (*) The descriptor f_type and f_ops field are not >> > relevent arguments in favor of this, since they >> > are cruft which should be diked out. >> >> It's already trivially easy to do file I/O in the kernel without a file >> descriptor. As you know, a "file descriptor" in FreeBSD is only a mechanism >> to translate a per-process file handle to a kernel vnode. For this reason, >> the very notion of a "file descriptor" is only relevant in the context of >> a process. It sounds like #4 is the main thing you're after, but I fail to >> see how this is relevant unless you have a process context in which to do >> the I/O, and in that case you already have easy access to the process' >> credentials. > >But... currently, a vnode reference is not the same thing as an open >reference. Actually, for all practical purposes, it is. Ideally, everything in the kernel would do a "VOP_OPEN" (actually, vn_open) for internal file I/O (such as coredumps)...and I think we actually do now. There was a time in the past where this wasn't the case, however. >Also, for things like a CIFS/SMBFS/AppleTalk/NetWare client, I want >to be able to use credentials which are not BSD process credentials, >but user credentials. I don't think this makes any sense. Process credentials are an instance of user credentials in the kernel. >I want to make the distinction between a cached reference and a real >reference, as well, both for the file I/O in a kernel thread, and >to get around some of the recent problems that come from VOP_LOCK >handling two types of locks. Hmmm. I agree with one thing: the current kludge of having vnodes with a "0" reference count + vnode generation count in the cache seems very wrong to me. It's done this way because of the handsprings one must do for NFS (and presumably any other "stateless" filesystem, which can't hold an "open" instance)... >Finally, there is the issue of taking faults in kernel mode without >a process context to sleep on. I'd like to see the sleeping moved to >the address of the field in the system open file table,so that the >sleep handle doesn't have to know what kind of caller is making the >call. Hmmm. Yes, I can see how this would be useful, but on the other hand, you have to have some saved state (whether that is a kernel thread or a process context), and any notion of kernel threads in FreeBSD (which I think is highly unlikely to ever occur) is going to have to deal with sleeping anyway...so I don't see a problem here. (Note: don't confuse this statement with kernel support for user threads, which IS very likely to occur in FreeBSD's near future). -DG David Greenman Core-team/Principal Architect, The FreeBSD Project From owner-freebsd-current Thu Apr 3 17:43:32 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id RAA04978 for current-outgoing; Thu, 3 Apr 1997 17:43:32 -0800 (PST) Received: from austin.polstra.com (austin.polstra.com [206.213.73.10]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id RAA04972 for ; Thu, 3 Apr 1997 17:43:29 -0800 (PST) Received: from austin.polstra.com (jdp@localhost) by austin.polstra.com (8.8.5/8.8.5) with ESMTP id RAA19367; Thu, 3 Apr 1997 17:43:26 -0800 (PST) Message-Id: <199704040143.RAA19367@austin.polstra.com> To: karl@Mcs.Net Subject: Re: Oops Newsgroups: polstra.freebsd.current In-Reply-To: <19970403182654.29991@Jupiter.Mcs.Net> References: <19970403182654.29991@Jupiter.Mcs.Net> Organization: Polstra & Co., Seattle, WA Cc: current@freebsd.org Date: Thu, 03 Apr 1997 17:43:25 -0800 From: John Polstra Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In article <19970403182654.29991@Jupiter.Mcs.Net>, Karl Denninger wrote: > > While trying to update... > /usr/local/sbin/cvsup /var/sup/cvs-supfile.cvsup > Checksum mismatch for src/gnu/usr.bin/cpio/main.c,v -- will transfer entire file > Checksum mismatch for src/gnu/usr.bin/cpio/rtapelib.c,v -- will transfer entire file > > > *** > *** runtime error: > *** Exception "RCSError.E" not in RAISES list > *** What version of CVSup are you running? Run "cvsup -v" to find out. I didn't see the problem here. In the future, please report CVSup problems to "cvsup-bugs@polstra.com". John -- John Polstra jdp@polstra.com John D. Polstra & Co., Inc. Seattle, Washington USA "Self-knowledge is always bad news." -- John Barth From owner-freebsd-current Thu Apr 3 17:50:02 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id RAA05428 for current-outgoing; Thu, 3 Apr 1997 17:50:02 -0800 (PST) Received: from Kitten.mcs.com (Kitten.mcs.com [192.160.127.90]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id RAA05401 for ; Thu, 3 Apr 1997 17:49:55 -0800 (PST) Received: from Jupiter.Mcs.Net (karl@Jupiter.mcs.net [192.160.127.88]) by Kitten.mcs.com (8.8.5/8.8.2) with ESMTP id TAA24257; Thu, 3 Apr 1997 19:49:53 -0600 (CST) Received: (from karl@localhost) by Jupiter.Mcs.Net (8.8.5/8.8.2) id TAA28846; Thu, 3 Apr 1997 19:49:52 -0600 (CST) Message-ID: <19970403194951.58431@Jupiter.Mcs.Net> Date: Thu, 3 Apr 1997 19:49:51 -0600 From: Karl Denninger To: John Polstra Cc: karl@Mcs.Net, current@freebsd.org Subject: Re: Oops References: <19970403182654.29991@Jupiter.Mcs.Net> <199704040143.RAA19367@austin.polstra.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.64 In-Reply-To: <199704040143.RAA19367@austin.polstra.com>; from John Polstra on Thu, Apr 03, 1997 at 05:43:25PM -0800 Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Thu, Apr 03, 1997 at 05:43:25PM -0800, John Polstra wrote: > In article <19970403182654.29991@Jupiter.Mcs.Net>, > Karl Denninger wrote: > > > > While trying to update... > > /usr/local/sbin/cvsup /var/sup/cvs-supfile.cvsup > > Checksum mismatch for src/gnu/usr.bin/cpio/main.c,v -- will transfer entire file > > Checksum mismatch for src/gnu/usr.bin/cpio/rtapelib.c,v -- will transfer entire file > > > > > > *** > > *** runtime error: > > *** Exception "RCSError.E" not in RAISES list > > *** > > What version of CVSup are you running? Run "cvsup -v" to find out. I > didn't see the problem here. > > In the future, please report CVSup problems to "cvsup-bugs@polstra.com". > > John > -- > John Polstra jdp@polstra.com > John D. Polstra & Co., Inc. Seattle, Washington USA > "Self-knowledge is always bad news." -- John Barth I reloaded the entire tree and the problme went away. -- -- Karl Denninger (karl@MCS.Net)| MCSNet - The Finest Internet Connectivity http://www.mcs.net/~karl | T1's from $600 monthly to FULL DS-3 Service | 99 Analog numbers, 77 ISDN, http://www.mcs.net/ Voice: [+1 312 803-MCS1 x219]| NOW Serving 56kbps DIGITAL on our analog lines! Fax: [+1 312 803-4929] | 2 FULL DS-3 Internet links; 400Mbps B/W Internal From owner-freebsd-current Thu Apr 3 18:25:51 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id SAA07861 for current-outgoing; Thu, 3 Apr 1997 18:25:51 -0800 (PST) Received: from thelab.hub.org (hal-ns1-32.netcom.ca [207.181.94.96]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id SAA07856 for ; Thu, 3 Apr 1997 18:25:43 -0800 (PST) Received: from thelab.hub.org (localhost [127.0.0.1]) by thelab.hub.org (8.8.5/8.8.2) with SMTP id WAA24061; Thu, 3 Apr 1997 22:24:02 -0400 (AST) Date: Thu, 3 Apr 1997 22:24:02 -0400 (AST) From: "Marc G. Fournier" To: John Polstra cc: cvsup-bugs@polstra.com, current@freebsd.org Subject: Re: Oops In-Reply-To: <199704040143.RAA19367@austin.polstra.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Thu, 3 Apr 1997, John Polstra wrote: > In article <19970403182654.29991@Jupiter.Mcs.Net>, > Karl Denninger wrote: > > > > While trying to update... > > /usr/local/sbin/cvsup /var/sup/cvs-supfile.cvsup > > Checksum mismatch for src/gnu/usr.bin/cpio/main.c,v -- will transfer entire file > > Checksum mismatch for src/gnu/usr.bin/cpio/rtapelib.c,v -- will transfer entire file > > > > > > *** > > *** runtime error: > > *** Exception "RCSError.E" not in RAISES list > > *** > > What version of CVSup are you running? Run "cvsup -v" to find out. I > didn't see the problem here. > I hit this problem as well, for a couple of files in /usr/src/sys (lock.c was one, I believe)...I just rm'd the files and re-cvsup'd them and all was fine. > cvsup -v CVSup client Software version: REL_14_1_1 Protocol version: 14.0 Marc G. Fournier Systems Administrator @ hub.org primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org From owner-freebsd-current Thu Apr 3 18:38:20 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id SAA08640 for current-outgoing; Thu, 3 Apr 1997 18:38:20 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.50]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id SAA08628 for ; Thu, 3 Apr 1997 18:38:17 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id TAA18256 for current@freebsd.org; Thu, 3 Apr 1997 19:21:29 -0700 From: Terry Lambert Message-Id: <199704040221.TAA18256@phaeton.artisoft.com> Subject: Re: DISCUSS: system open file table To: current@freebsd.org Date: Thu, 3 Apr 1997 19:21:23 -0700 (MST) In-Reply-To: <199704040127.RAA06069@root.com> from "David Greenman" at Apr 3, 97 05:27:00 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > >But... currently, a vnode reference is not the same thing as an open > >reference. > > Actually, for all practical purposes, it is. Ideally, everything in the > kernel would do a "VOP_OPEN" (actually, vn_open) for internal file I/O (such > as coredumps)...and I think we actually do now. There was a time in the > past where this wasn't the case, however. Is this new since the Lite2 merge? My Lite2 tree is not on this machine, so I can't check very easily. If it is, I need to back off until I've had a chance to look at the Lite2 stuff... Actually, the vnode being returned is being returned by VOP_LOOKUP, by way of the namei() call. The VOP_OPEN is one of those few "veto" based interfaces that actually works. The open calls the ufs_open() in ufs_vnops.c, and is basically there to veto the ability to zap the "append only" files. One problem I have with this is that the VOP_LOOKUP calls the generic kernel allocation code, and the deallocation code is called by the same layer that called the VOP_OPEN. I would really rather that if you call a VOP to allocate a vnode, you call a VOP to free one. We can discuss whether or not the VFS should be consuming a kernel vnode pool management interface in another thread; if the interface is reflexive, it doesn't matter because that consumption is opaque. If the vnode reference instance *was* the open instance, I'd be OK with leaving the interface at the VOP_ layer... though it still makes it difficult to perform an open in the kernel for a file in the FS proper, because VOP_'s are per FS, which is why we have namei(). The vn_open() soloution for this problem is not very nice, because it assumes that it will be called in a process context... I can't just pass it a manifest SUSER credential. The system open file table entry is really just a credential holder in the kernel case, and it makes it easier to deal with the idea of revoking a vnode: because the reference is to the system open file table entry instead of the vnode, you can revoke the vnode that the entry points to without notifying the people who refernced it until the go to access the now invalid vnode. If they have a vnode pointer instead, they have to be able to "check it" to see if its valid, or be notified. There's no real clean failure on refernce. So effectively, it's not only a credential holder, its a handle that can be invalidated out from under it. This is the same thing that happens to a user space process in the case of a forcible unmount of an FS where it has a file open. > >Also, for things like a CIFS/SMBFS/AppleTalk/NetWare client, I want > >to be able to use credentials which are not BSD process credentials, > >but user credentials. > > I don't think this makes any sense. Process credentials are an instance > of user credentials in the kernel. It lets me look up my user credentials indirectly, as root. This lets me have a "password cache", either "unlocked by user credentials" or stored in a session manager. This lets me have seperate "alien" credentials than some other process, but I can use the same connection to the server for multiple user sessions. I know this workds for CIFS Kerberos tickets; I admit, I think that an SMBFS (Samba, etc.) client would need a server connection per user; on the other hand, it could virtualize these (say having a maximum pool of 10 active connections) and using the credential lookup, make another connection on the requesting users behalf, after discarding the LRU list tail of the 10. For NetWare, which handles multiple session over a single connection for OS/2 and NT clients, it should work on one connection (though sessions might want to be pooled). It may also be that the session ticket was supplied by NDS or some other directory server (LDAP? X.500?) and not be a Kerberos ticket at all; so we can't just "handle it all the same". > >I want to make the distinction between a cached reference and a real > >reference, as well, both for the file I/O in a kernel thread, and > >to get around some of the recent problems that come from VOP_LOCK > >handling two types of locks. > > Hmmm. I agree with one thing: the current kludge of having vnodes with a > "0" reference count + vnode generation count in the cache seems very wrong to > me. It's done this way because of the handsprings one must do for NFS (and > presumably any other "stateless" filesystem, which can't hold an "open" > instance)... Yes, and it's complicated by a relatively high turnover, though this would probably tail off a lot if the vnode were FS associative instead of in a global pool. The SVR4 soloution for the name cache (which has similar problems) is to flush the cache by vnode (or by VFS, when an FS is unmounted). The NFS problem is less of an issue if the VFS handles cookie generation a bit more intelligently, and doesn't use the vp to do it. This is also a "vp is FS associative" argument... the NFS file handle lookup is done using the VFS OP FHTOVP to invoke a per FS "*_fhtovp" function, so the NFS wiring is all already there. > >Finally, there is the issue of taking faults in kernel mode without > >a process context to sleep on. I'd like to see the sleeping moved to > >the address of the field in the system open file table,so that the > >sleep handle doesn't have to know what kind of caller is making the > >call. > > Hmmm. Yes, I can see how this would be useful, but on the other hand, you > have to have some saved state (whether that is a kernel thread or a process > context), and any notion of kernel threads in FreeBSD (which I think is highly > unlikely to ever occur) is going to have to deal with sleeping anyway...so > I don't see a problem here. (Note: don't confuse this statement with kernel > support for user threads, which IS very likely to occur in FreeBSD's near > future). For kernel threading, the idea would be to allocate a context for the call; this would include a kernel stack, etc.. It's roughly exactly what you would need to support an async call gate for system calls (asyscall instead of syscall, and then operate of the same sysent[] table, with another flag for "CALL_CAN_BLOCK") to support call conversion for a full user space POSIX threading implementation. I actually think there was a kernel threading implementation posted to the SMP list a while back -- I know that one was done for FreeBSD, in any case, so I can probably dig it out from somewhere, even if it wasn't the SMP list. But I agree that supporting a future kernel threading implementation isn't the primary reason for doing this. 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 Apr 3 19:35:57 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id TAA11930 for current-outgoing; Thu, 3 Apr 1997 19:35:57 -0800 (PST) Received: from root.com (implode.root.com [198.145.90.17]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id TAA11925 for ; Thu, 3 Apr 1997 19:35:53 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by root.com (8.8.5/8.6.5) with SMTP id TAA08517; Thu, 3 Apr 1997 19:36:05 -0800 (PST) Message-Id: <199704040336.TAA08517@root.com> X-Authentication-Warning: implode.root.com: localhost [127.0.0.1] didn't use HELO protocol To: Terry Lambert cc: current@freebsd.org Subject: Re: DISCUSS: system open file table In-reply-to: Your message of "Thu, 03 Apr 1997 19:21:23 MST." <199704040221.TAA18256@phaeton.artisoft.com> From: David Greenman Reply-To: dg@root.com Date: Thu, 03 Apr 1997 19:36:05 -0800 Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >> >But... currently, a vnode reference is not the same thing as an open >> >reference. >> >> Actually, for all practical purposes, it is. Ideally, everything in the >> kernel would do a "VOP_OPEN" (actually, vn_open) for internal file I/O (such >> as coredumps)...and I think we actually do now. There was a time in the >> past where this wasn't the case, however. > >Is this new since the Lite2 merge? My Lite2 tree is not on this machine, >so I can't check very easily. If it is, I need to back off until I've >had a chance to look at the Lite2 stuff... No, it happened as a result of the merged cache. It was important to have this in order to accurately track (VM) object reference counts. >The vn_open() soloution for this problem is not very nice, because it >assumes that it will be called in a process context... I can't just >pass it a manifest SUSER credential. You should be able to pass a "NOCRED" credential and escentially get that, but I'm not sure what will happen in NFS which must pass a uid. >The system open file table entry is really just a credential holder >in the kernel case, and it makes it easier to deal with the idea >of revoking a vnode: because the reference is to the system open >file table entry instead of the vnode, you can revoke the vnode >that the entry points to without notifying the people who refernced >it until the go to access the now invalid vnode. If they have a >vnode pointer instead, they have to be able to "check it" to see if >its valid, or be notified. There's no real clean failure on refernce. > >So effectively, it's not only a credential holder, its a handle that >can be invalidated out from under it. This is only true if there are no "open" instances. The vnode won't get ripped away unless it is on the free list, and it's only on the free list if noone has it "open". >This is the same thing that happens to a user space process in the >case of a forcible unmount of an FS where it has a file open. Actually, no. What happens in the forcible unmount case is that the vnode gets re-assigned to deadfs and all further reads/write return EIO. The vnode continues to remain "open" and not on the free list until all references to it have been released (usually through "close"). -DG David Greenman Core-team/Principal Architect, The FreeBSD Project From owner-freebsd-current Thu Apr 3 21:39:48 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id VAA17670 for current-outgoing; Thu, 3 Apr 1997 21:39:48 -0800 (PST) Received: from rocky.mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id VAA17661 for ; Thu, 3 Apr 1997 21:39:28 -0800 (PST) Received: (from nate@localhost) by rocky.mt.sri.com (8.7.5/8.7.3) id WAA26546; Thu, 3 Apr 1997 22:39:14 -0700 (MST) Date: Thu, 3 Apr 1997 22:39:14 -0700 (MST) Message-Id: <199704040539.WAA26546@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: John Polstra , current@freebsd.org Subject: Re: Oops In-Reply-To: <19970403194951.58431@Jupiter.Mcs.Net> References: <19970403182654.29991@Jupiter.Mcs.Net> <199704040143.RAA19367@austin.polstra.com> <19970403194951.58431@Jupiter.Mcs.Net> X-Mailer: VM 6.22 under 19.15 XEmacs Lucid Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > > While trying to update... > > > /usr/local/sbin/cvsup /var/sup/cvs-supfile.cvsup > > > Checksum mismatch for src/gnu/usr.bin/cpio/main.c,v -- will transfer entire file > > > Checksum mismatch for src/gnu/usr.bin/cpio/rtapelib.c,v -- will transfer entire file > > > > > > > > > *** > > > *** runtime error: > > > *** Exception "RCSError.E" not in RAISES list > > > *** > > > > What version of CVSup are you running? Run "cvsup -v" to find out. I > > didn't see the problem here. > > I reloaded the entire tree and the problme went away. I had this problem, but it turned out I was running V13.5. I had installed V14.1, but there was an old binary that was getting picked up first. It crashed for 3-4 days straight w/out me noticing it until I finally noted that later parts of my tree weren't getting updated. Nate From owner-freebsd-current Fri Apr 4 00:29:07 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id AAA26181 for current-outgoing; Fri, 4 Apr 1997 00:29:07 -0800 (PST) Received: from hydrogen.nike.efn.org (resnet.uoregon.edu [128.223.170.28]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id AAA26157 for ; Fri, 4 Apr 1997 00:29:01 -0800 (PST) Received: (from jmg@localhost) by hydrogen.nike.efn.org (8.8.4/8.8.4) id AAA07139; Fri, 4 Apr 1997 00:29:00 -0800 (PST) Message-ID: <19970404002900.52101@hydrogen.nike.efn.org> Date: Fri, 4 Apr 1997 00:29:00 -0800 From: John-Mark Gurney To: FreeBSD Current Subject: Re: termcap and color References: <19970403010957.13573@hydrogen.nike.efn.org> <19970403225028.UD37275@uriah.heep.sax.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.67 In-Reply-To: <19970403225028.UD37275@uriah.heep.sax.de>; from J Wunsch on Thu, Apr 03, 1997 at 10:50:28PM +0200 Reply-To: John-Mark Gurney Organization: Cu Networking X-Operating-System: FreeBSD 2.2-960801-SNAP 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-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk J Wunsch scribbled this message on Apr 3: > As John-Mark Gurney wrote: > > > so: > > o) I add Co, Sf, and Sb to termcap(5) > > Note that you should also mention that it's a matter of the > application whether it even remotely thinks of using these entries or > not. That's the thing with termcap (as opposed to terminfo): you can > extend it beyond things that have been originally intended. ok.. sounds good... I think instead of listing 'em all... I'll just add a segment and point them to the document Bruce mentioned... > Note also that XFree86's termcap entry defines two similar > capabilities: AB is a synonym for Sb, and AF is a synonym for Sf. It > depends on the application which one it's expecting. They also define > pa#64. actually, it's screen that uses AF and AB (in addition to Sf, Sb)... but all entries that use color happen to define pa#64 also... thanks for the pointers... -- John-Mark Cu Networking Modem/FAX: +1 541 683 6954 Live in Peace, destroy Micro$oft, support free software, run FreeBSD From owner-freebsd-current Fri Apr 4 00:47:24 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id AAA26761 for current-outgoing; Fri, 4 Apr 1997 00:47:24 -0800 (PST) Received: from hydrogen.nike.efn.org (resnet.uoregon.edu [128.223.170.28]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id AAA26756 for ; Fri, 4 Apr 1997 00:47:16 -0800 (PST) Received: (from jmg@localhost) by hydrogen.nike.efn.org (8.8.4/8.8.4) id AAA07477; Fri, 4 Apr 1997 00:47:14 -0800 (PST) Message-ID: <19970404004714.27849@hydrogen.nike.efn.org> Date: Fri, 4 Apr 1997 00:47:14 -0800 From: John-Mark Gurney To: FreeBSD Current Subject: modify termcap to support both A[FB] and S[fb]... Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.67 Reply-To: John-Mark Gurney Organization: Cu Networking X-Operating-System: FreeBSD 2.2-960801-SNAP 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-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk does anybody object to me modifing termcap to support both ways of declaring color codes? it seems that screen wants to use A[FB] only... and that cons/xterm want to use S[fb]... if no one objects I'll make the mods so that they understand each other... this will probably also fix a problem with mutt not knowing that colors exist when running under screen, and consXX... thanks for the input... ttyl.. -- John-Mark Cu Networking Modem/FAX: +1 541 683 6954 Live in Peace, destroy Micro$oft, support free software, run FreeBSD From owner-freebsd-current Fri Apr 4 01:16:54 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id BAA28103 for current-outgoing; Fri, 4 Apr 1997 01:16:54 -0800 (PST) Received: from alterego.stack.nl (alterego.stack.nl [131.155.141.160]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id BAA28096 for ; Fri, 4 Apr 1997 01:16:50 -0800 (PST) Received: (from xaa@localhost) by alterego.stack.nl (8.8.5/8.8.5) id LAA00620; Fri, 4 Apr 1997 11:16:47 +0200 (MET DST) Message-ID: <19970404111646.13559@alterego.stack.nl> Date: Fri, 4 Apr 1997 11:16:46 +0200 From: Mark Huizer To: freebsd-current@freebsd.org Subject: cvsup.nl.freebsd.org instable for a day :-( Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.67 Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Brr... good idea that was, had to recompile a kernel, and I trusted current enough, needed new lkm's so a make word... and then there were no more ncr0, no ed0 :-( So it'll go back to 2.2.1 today, and will be up, down, up, down, for today :-( Sorry for the inconvenience, but cvsup.nl.freebsd.org should be considered inusable Friday April 4th Mark Huizer ------------------------------------------------------------------------- - Mark Huizer - xaa@stack.nl - rcbamh@urc.tue.nl - ------------------------------------------------------------------------- - A child of five could understand this! Fetch me a child of five. - ------------------------------------------------------------------------- From owner-freebsd-current Fri Apr 4 03:34:14 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id DAA02709 for current-outgoing; Fri, 4 Apr 1997 03:34:14 -0800 (PST) Received: from hydrogen.nike.efn.org (resnet.uoregon.edu [128.223.170.28]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id DAA02661 for ; Fri, 4 Apr 1997 03:34:04 -0800 (PST) Received: (from jmg@localhost) by hydrogen.nike.efn.org (8.8.4/8.8.4) id DAA09141; Fri, 4 Apr 1997 03:33:30 -0800 (PST) Message-ID: <19970404033330.29888@hydrogen.nike.efn.org> Date: Fri, 4 Apr 1997 03:33:30 -0800 From: John-Mark Gurney To: FreeBSD Current Subject: tset as reset at login... Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.67 Reply-To: John-Mark Gurney Organization: Cu Networking X-Operating-System: FreeBSD 2.2-960801-SNAP 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-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk well... I've been doing some more investigating into this termcap business... man are there a TON of inconsistancies... o) first of all terminfo_extensions.doc don't list every thing that termcap(5) does o) termcap(5) says that `is' is sent the first time you login, this is actually incorrect... `is' is only sent when tset is called as reset. o) when tset is called as reset it doesn't even do what the man page (termcap(5)) says will do when resetting the terminal I'm reluctant to touch tset as it may adversely effect how tset normally operates... but does anybody have problems with me fixing tset to match the man page? or should I fix the man page to match the program? yikes... I just looked at our skel files and there is no example of tset included in these files... is there a good reason why not? thanks for your comments on the subject... -- John-Mark Cu Networking Modem/FAX: +1 541 683 6954 Live in Peace, destroy Micro$oft, support free software, run FreeBSD From owner-freebsd-current Fri Apr 4 04:12:43 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id EAA04022 for current-outgoing; Fri, 4 Apr 1997 04:12:43 -0800 (PST) Received: from korin.warman.org.pl (korin.warman.org.pl [148.81.160.10]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id EAA03998 for ; Fri, 4 Apr 1997 04:12:01 -0800 (PST) Received: from localhost (abial@localhost) by korin.warman.org.pl (8.8.3/8.7.3) with SMTP id OAA14437; Fri, 4 Apr 1997 14:11:07 +0200 (MET DST) Date: Fri, 4 Apr 1997 14:10:58 +0200 (MET DST) From: Andrzej Bialecki To: Garrett Wollman cc: freebsd-current@freebsd.org Subject: Re: IPv6 && -current In-Reply-To: <199704031529.KAA04612@khavrinen.lcs.mit.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Thu, 3 Apr 1997, Garrett Wollman wrote: > < said: > > > What is the status of IPv6 implementation under -current? I'd be probably > > interested in setting up a machine and a tunnel to 6bone, so I would > > gladly use FreeBSD for this, if it's possible... > > I am aware of two implementations out there, and the unfortunate truth > is that both of them suck, in different ways. (Although at least one > of them, I am told, is getting significantly better stylistically.) > Until this situation changes a bit more (or we find someone interested > in doing an IPv6 implementation that obeys style(9) and isn't > altogether bletcherous), there should not be IPv6 code in the -current > kernel. Hmmm... some time ago there was a port of NRL code to FreeBSD 2.1.x, I think. Does it mean someone from FreeBSD developers {is doing,has done} anything with this? Sincerely yours, --- Andrzej Bialecki FreeBSD: Turning PCs Into Workstations http://www.freebsd.org Research and Academic Network in Poland From owner-freebsd-current Fri Apr 4 09:45:59 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id JAA22038 for current-outgoing; Fri, 4 Apr 1997 09:45:59 -0800 (PST) Received: from austin.polstra.com (austin.polstra.com [206.213.73.10]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id JAA22032 for ; Fri, 4 Apr 1997 09:45:55 -0800 (PST) Received: from austin.polstra.com (jdp@localhost) by austin.polstra.com (8.8.5/8.8.5) with ESMTP id JAA24277; Fri, 4 Apr 1997 09:45:53 -0800 (PST) Message-Id: <199704041745.JAA24277@austin.polstra.com> To: current@freebsd.org Subject: Re: Oops Newsgroups: polstra.freebsd.current In-Reply-To: <199704040539.WAA26546@rocky.mt.sri.com> References: <19970403182654.29991@Jupiter.Mcs.Net> <199704040143.RAA19367@austin.polstra.com> <19970403194951.58431@Jupiter.Mcs.Net> <199704040539.WAA26546@rocky.mt.sri.com> Organization: Polstra & Co., Seattle, WA Cc: nate@mt.sri.com Date: Fri, 04 Apr 1997 09:45:53 -0800 From: John Polstra Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In article <199704040539.WAA26546@rocky.mt.sri.com>, Nate Williams wrote: > > > > *** > > > > *** runtime error: > > > > *** Exception "RCSError.E" not in RAISES list > > > > *** > > > > > > What version of CVSup are you running? Run "cvsup -v" to find out. I > > > didn't see the problem here. > > > > I reloaded the entire tree and the problme went away. > > I had this problem, but it turned out I was running V13.5. In private e-mail to me, Karl reported that he was running 13.5 as well. The potential for this kind of problem is much reduced in 14.1.1, the current released version. There is an unreleased version, 14.1.4, which I believe solves the whole problem. In that version, I did some extensive restructuring of the code that does file updates. Now there is a unified framework that handles all the different kinds of updates (RCS, append, touch, rsync, etc.). It greatly simplified and reduced the code. As a side-effect, it makes it much easier to be sure that unexpected situations like the one above are handled properly. These kinds of errors only happen when something forbidden has been done to the repository. What you are watching is an evolution of my notions about what CVSup should reasonably be expected to deal with in a CVS repository, either on the server or the client. It's progressed something like this: Only things done via legitimate "cvs" commands => Manual hacking around in the repository by well-meaning troublemakers => Complete trashing of repository files by well-meaning troublemakers => Anything except kernel errors => Anything except hardware errors => Anything except RAM errors => Any damn thing whatsoever. :-( If anybody wants to use 14.1.4, it's in the "BETA" subdirectory of the usual distribution points: ftp://freefall.freebsd.org/pub/CVSup/ (California) ftp://ftp.cs.tu-berlin.de/pub/FreeBSD/CVSup/ (Germany) ftp://ftp.polstra.com/pub/FreeBSD/CVSup/ (slow; avoid if possible) Freefall, the US mirrors, and some of the other mirrors have all been running it for weeks without problems. It's only a "beta" because I wanted to add a few more features before making another official release. There's no port or package for it, but the sources and static executables are available as usual. By the way, I'd like to publicly thank the folks at Pluto Technologies for supporting much of the work that went into 14.1.4, as well as other enhancements that are underway. Check out their web page some time: . They're doing some pretty cool things! John -- John Polstra jdp@polstra.com John D. Polstra & Co., Inc. Seattle, Washington USA "Self-knowledge is always bad news." -- John Barth From owner-freebsd-current Fri Apr 4 10:15:42 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id KAA23688 for current-outgoing; Fri, 4 Apr 1997 10:15:42 -0800 (PST) Received: from sovcom.kiae.su (sovcom.kiae.su [193.125.152.1]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id KAA23683 for ; Fri, 4 Apr 1997 10:15:39 -0800 (PST) Received: by sovcom.kiae.su id AA19753 (5.65.kiae-1 ); Fri, 4 Apr 1997 21:02:50 +0300 Received: by sovcom.KIAE.su (UUMAIL/2.0); Fri, 4 Apr 97 21:02:50 +0300 Received: (from ache@localhost) by nagual.ru (8.8.5/8.8.5) id VAA00831; Fri, 4 Apr 1997 21:53:46 +0400 (MSD) Date: Fri, 4 Apr 1997 21:53:43 +0400 (MSD) From: =?KOI8-R?B?4c7E0sXKIP7F0s7P1w==?= To: John-Mark Gurney Cc: FreeBSD Current Subject: Re: modify termcap to support both A[FB] and S[fb]... In-Reply-To: <19970404004714.27849@hydrogen.nike.efn.org> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Fri, 4 Apr 1997, John-Mark Gurney wrote: > does anybody object to me modifing termcap to support both ways of > declaring color codes? > > it seems that screen wants to use A[FB] only... and that cons/xterm > want to use S[fb]... I object, we don't need 1000+1 abbreviations for the same capatibility, fix screen instead. -- Andrey A. Chernov http://www.nagual.ru/~ache/ From owner-freebsd-current Fri Apr 4 10:22:42 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id KAA24186 for current-outgoing; Fri, 4 Apr 1997 10:22:42 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.50]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id KAA24177 for ; Fri, 4 Apr 1997 10:22:38 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id LAA19566; Fri, 4 Apr 1997 11:04:57 -0700 From: Terry Lambert Message-Id: <199704041804.LAA19566@phaeton.artisoft.com> Subject: Re: modify termcap to support both A[FB] and S[fb]... To: gurney_j@resnet.uoregon.edu Date: Fri, 4 Apr 1997 11:04:57 -0700 (MST) Cc: freebsd-current@freebsd.org In-Reply-To: <19970404004714.27849@hydrogen.nike.efn.org> from "John-Mark Gurney" at Apr 4, 97 00:47:14 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > does anybody object to me modifing termcap to support both ways of > declaring color codes? > > it seems that screen wants to use A[FB] only... and that cons/xterm > want to use S[fb]... > > if no one objects I'll make the mods so that they understand each > other... this will probably also fix a problem with mutt not knowing > that colors exist when running under screen, and consXX... These entries are for the ISO color sequences, which take a manifest color constant, of which only 0-7 are defined, right? The problem with PC hardware is that there are 16 foreground colors and either 8 background colors and the ability to blink, or 16 background colors and no ability to blink. One traditional (SCO) way of handling this was to use the "bold" attribute to select the additional 8 foreground colors (which are HLS scaled up from the other 8 colors that are shared with the background) and the "blink" attribute to select the 8 background colors "blink bit". Whether the "blink" attribute causes "bold" background colors or causes the foreground characters to blink, depends on the settings in CGA register (either the real thing, or the emulated thing) #2, bit 5. SCO defined thair own sequence (and termcap entry) for dealing with this, too. Finally, SCO wimped out, and provided a "select background", "select foreground" and a "select background and foreground" sequence, which did not match the ISO definitions, and was technically in collision with a number of ANSI definitions. But these SCO sequences (except the "blink" vs. "bold" control) are not necessary to get at all the color combinations, foreground and background. Ah, the vagries of PC hardware... 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 Fri Apr 4 11:45:52 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id LAA29429 for current-outgoing; Fri, 4 Apr 1997 11:45:52 -0800 (PST) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id LAA29418; Fri, 4 Apr 1997 11:45:33 -0800 (PST) Received: from current1.whistle.com (current1.whistle.com [207.76.205.22]) by alpo.whistle.com (8.8.5/8.8.4) with SMTP id LAA04263; Fri, 4 Apr 1997 11:36:10 -0800 (PST) Message-ID: <33455773.3F54BC7E@whistle.com> Date: Fri, 04 Apr 1997 11:33:07 -0800 From: Julian Elischer Organization: Whistle Communications X-Mailer: Mozilla 3.0Gold (X11; I; FreeBSD 2.2-CURRENT i386) MIME-Version: 1.0 To: "Jordan K. Hubbard" CC: Terry Lambert , phk@critter.dk.tfs.com, ache@nagual.ru, dyson@FreeBSD.ORG, bde@zeta.org.au, current@FreeBSD.ORG Subject: Re: ufs lock panic in -current References: <19304.860045426@time.cdrom.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Jordan K. Hubbard wrote: > > > Julian has my namei/nameifree and "EXCLUDE" NDINIT() op redundant > > code reduction changes. > > > > Feel free to commit them. > > How can I? You've sent them only to Julian, and as far as I can see > so far, he ain't talking. This entire thread *started* from my asking > you to put these same changes up for FTP someplace (since you > mentioned them specifically as an example of a contribution and phk > followed up that he wanted in) and now you're suddenly playing The > Reasonable Man over them, after engaging in another multi-mail thread > about how you *weren't* going to do this. Yes I have them basically they make sense I'd like to discuss them with john and/or david, but the LITE2 stuff hit so I've been sitting on them it's probably time to bring them out again there are some definite improvements there, but also a few things that are more "judgement calls" and need to be thought about.. I haven't forgotten them I'm just busy here at whistle so I don't want to waste my time on doing them and then finding that lite 2 makes it all useless. From owner-freebsd-current Fri Apr 4 12:16:53 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id MAA01251 for current-outgoing; Fri, 4 Apr 1997 12:16:53 -0800 (PST) Received: from terra.stack.nl (terra.stack.nl [131.155.140.128]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id MAA01242 for ; Fri, 4 Apr 1997 12:16:50 -0800 (PST) Received: from xaa.stack.nl (uucp@localhost) by terra.stack.nl (8.8.5) with UUCP id WAA03451 for current@freebsd.org; Fri, 4 Apr 1997 22:16:41 +0200 (MET DST) Received: (from freebsd@localhost) by xaa.stack.nl (8.8.5/8.8.2) id WAA06953; Fri, 4 Apr 1997 22:12:41 +0200 (MET DST) Message-ID: <19970404221240.05075@xaa.stack.nl> Date: Fri, 4 Apr 1997 22:12:40 +0200 From: "FreeBSD matters of Mark Huizer (xaa)" To: current@freebsd.org Subject: How to declare a PCI card nowadays?? Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.68 From: xaa@stack.nl (Mark Huizer) Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hmm... how should I declare PCI cards in config-files nowadays??? I used to just have a ncr0 and a ed0 in the config file, which were detected as ncr0 and ed1 both on pci0, but when I did a rebuilt yesterday all it did was give me trouble and no pci-cards :-( Not even the pci-board was detected Mark From owner-freebsd-current Fri Apr 4 13:19:47 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id NAA04100 for current-outgoing; Fri, 4 Apr 1997 13:19:47 -0800 (PST) Received: from militzer.me.tuns.ca (militzer.me.tuns.ca [134.190.50.153]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id NAA04089 for ; Fri, 4 Apr 1997 13:19:40 -0800 (PST) Received: from localhost (bemfica@localhost) by militzer.me.tuns.ca (8.8.5/8.8.4) with SMTP id RAA00594 for ; Fri, 4 Apr 1997 17:19:15 -0400 (AST) Date: Fri, 4 Apr 1997 17:19:14 -0400 (AST) From: Antonio Bemfica To: freebsd-current@freebsd.org Subject: ufs filesystem not available at mount time ... Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hello A week or so back someone posted a message refering to a problem with mount at boot time. The same problem is happening to my -current box after a 'make world' (I didn't have a chance of building a new kernel...): mount: ufs filesystem is not available One proposed solution was to boot with the fixit floppy and copy the mount* files onto a new location on the hard drive, reboot it in single user mode and use the new mount* binaries to get things back in order. How exactly do you accomplish that? When I boot with the floppy I have no access to the hard drive - I have a minimal filesystem up and the floppy is mounted at /mnt2. Should I mount /dev/rsd0a (my "/" ) onto / or onto /mnt, or some such thing? I tried some combinations, but never got access to the fixed drive (mount complains it needs a "block device" or something like that). Any help would be appreciated. Antonio -- ------------------------------------------------------------------------ "I myself have always disliked being called a 'genius'. It is fascinating to notice how quick people have been to intuit this aversion and avoid using the term" -- John Lanchester, in "The Debt to Pleasure" From owner-freebsd-current Fri Apr 4 13:20:37 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id NAA04285 for current-outgoing; Fri, 4 Apr 1997 13:20:37 -0800 (PST) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id NAA04265 for ; Fri, 4 Apr 1997 13:20:30 -0800 (PST) Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id XAA02427 for freebsd-current@FreeBSD.org; Fri, 4 Apr 1997 23:20:23 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.8.5/8.8.5) id WAA05032; Fri, 4 Apr 1997 22:10:51 +0200 (MET DST) Message-ID: <19970404221051.PZ02960@uriah.heep.sax.de> Date: Fri, 4 Apr 1997 22:10:51 +0200 From: j@uriah.heep.sax.de (J Wunsch) To: freebsd-current@FreeBSD.org (FreeBSD Current) Subject: Re: modify termcap to support both A[FB] and S[fb]... References: <19970404004714.27849@hydrogen.nike.efn.org> 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 ??????????????? on Apr 4, 1997 21:53:43 +0400 Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk As Andrey wrote: > > it seems that screen wants to use A[FB] only... and that cons/xterm > > want to use S[fb]... > > I object, we don't need 1000+1 abbreviations for the same capatibility, > fix screen instead. I object against your objection. :-) ncurses (libdialog?) seems to have made a simlar arbitrary decision about using Sf/Sb. None if them is ``more correct'' than the other one, and i remember a discussion in the XFree86 team that AB/AF are supposedly from SysV land. -- 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 Fri Apr 4 13:20:45 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id NAA04311 for current-outgoing; Fri, 4 Apr 1997 13:20:45 -0800 (PST) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id NAA04284 for ; Fri, 4 Apr 1997 13:20:36 -0800 (PST) Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id XAA02434 for freebsd-current@freebsd.org; Fri, 4 Apr 1997 23:20:34 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.8.5/8.8.5) id WAA05041; Fri, 4 Apr 1997 22:12:39 +0200 (MET DST) Message-ID: <19970404221239.CA51772@uriah.heep.sax.de> Date: Fri, 4 Apr 1997 22:12:39 +0200 From: j@uriah.heep.sax.de (J Wunsch) To: freebsd-current@freebsd.org Subject: Re: modify termcap to support both A[FB] and S[fb]... References: <19970404004714.27849@hydrogen.nike.efn.org> <199704041804.LAA19566@phaeton.artisoft.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: <199704041804.LAA19566@phaeton.artisoft.com>; from Terry Lambert on Apr 4, 1997 11:04:57 -0700 Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk As Terry Lambert wrote: > The problem with PC hardware is that there are 16 foreground colors > and either 8 background colors and the ability to blink, or 16 > background colors and no ability to blink. That's only one possible mode of operation. Another one (as used by pcvt) is to have 8 foreground colors only, with the ability of using 512 character cells in the chargen. pcvt needs this mode to be closer to the rich charset abilities of VTxxx ttys, as opposed to the poor 256 chars of a typical PeeCee. -- 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 Fri Apr 4 14:31:01 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id OAA07760 for current-outgoing; Fri, 4 Apr 1997 14:31:01 -0800 (PST) Received: from mercury.uniserve.com (mercury.uniserve.com [204.191.197.248]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id OAA07754 for ; Fri, 4 Apr 1997 14:30:59 -0800 (PST) Received: from haven.uniserve.com (haven.uniserve.com [198.53.215.121]) by mercury.uniserve.com (8.8.2/8.8.2) with SMTP id OAA04531; Fri, 4 Apr 1997 14:26:27 -0800 (PST) Date: Fri, 4 Apr 1997 14:36:29 -0800 (PST) From: Tom Samplonius To: "FreeBSD matters of Mark Huizer (xaa)" , Mark Huizer cc: current@freebsd.org Subject: Re: How to declare a PCI card nowadays?? In-Reply-To: <19970404221240.05075@xaa.stack.nl> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Fri, 4 Apr 1997, FreeBSD matters of Mark Huizer (xaa) wrote: > Hmm... how should I declare PCI cards in config-files nowadays??? > I used to just have a ncr0 and a ed0 in the config file, which were > detected as ncr0 and ed1 both on pci0, but when I did a rebuilt yesterday > all it did was give me trouble and no pci-cards :-( Not even the pci-board > was detected > > Mark > You should look at LINT. It has examples of correct device configurations for these devices. Tom From owner-freebsd-current Fri Apr 4 14:37:38 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id OAA08052 for current-outgoing; Fri, 4 Apr 1997 14:37:38 -0800 (PST) Received: from icicle.winternet.com (adm@icicle.winternet.com [198.174.169.5]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id OAA08047 for ; Fri, 4 Apr 1997 14:37:35 -0800 (PST) Received: (from adm@localhost) by icicle.winternet.com (8.7.5/8.7.5) id QAA02557 for ; Fri, 4 Apr 1997 16:37:27 -0600 (CST) Posted-Date: Fri, 4 Apr 1997 16:37:27 -0600 (CST) Received: from fools.ecp.net(204.246.64.101) by icicle.winternet.com via smap (V2.0beta) id xma002465; Fri, 4 Apr 97 16:36:56 -0600 Received: from localhost (moke@localhost) by fools.ecp.net (8.8.5/8.8.4) with SMTP id QAA05827 for ; Fri, 4 Apr 1997 16:32:21 -0600 (CST) Date: Fri, 4 Apr 1997 16:32:11 -0600 (CST) From: Jimbo Bahooli To: freebsd-current@freebsd.org Subject: ipfilter Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I upgraded my src/contrib/ipfilter to the new ipfilter in hopes that it actually would compile. Currently i'm getting the error make: don't know how to make build. . Any help from anyone? The symlinks are wrong in BSD/i386 it appears, but there is no build in the Makefile it should point to anyways, so i am lost. From owner-freebsd-current Fri Apr 4 15:43:52 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id PAA11426 for current-outgoing; Fri, 4 Apr 1997 15:43:52 -0800 (PST) Received: from diroxbsd.dx ([195.180.235.113]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id PAA11419 for ; Fri, 4 Apr 1997 15:43:48 -0800 (PST) Received: (from dirk@localhost) by diroxbsd.dx (8.8.5/8.7.3) id BAA00334; Sat, 5 Apr 1997 01:32:42 +0200 (MET DST) Date: Sat, 5 Apr 1997 01:32:42 +0200 (MET DST) From: To: current@freebsd.org Subject: Re: Current is crashing X Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I have set the execute bits of/usr/X11R6/lib/X11/xinit/xinitrc . After that X works fine. The standard mode of this file is 444. The file will be execute by xinit in the procedure startClient. If you have a local .xinitrc you have to set the execute bit of the user too. The permissions for xserverrc-files should be set analogous. I'm running XFree86. Dirk From owner-freebsd-current Fri Apr 4 15:49:35 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id PAA11696 for current-outgoing; Fri, 4 Apr 1997 15:49:35 -0800 (PST) Received: from helbig.informatik.ba-stuttgart.de (helbig.informatik.ba-stuttgart.de [141.31.166.22]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id PAA11687 for ; Fri, 4 Apr 1997 15:49:29 -0800 (PST) Received: (from helbig@localhost) by helbig.informatik.ba-stuttgart.de (8.8.5/8.8.5) id BAA27949; Sat, 5 Apr 1997 01:49:17 +0200 (MET DST) From: Wolfgang Helbig Message-Id: <199704042349.BAA27949@helbig.informatik.ba-stuttgart.de> Subject: Re: ufs filesystem not available at mount time ... In-Reply-To: from Antonio Bemfica at "Apr 4, 97 05:19:14 pm" To: bemfica@militzer.me.tuns.ca (Antonio Bemfica) Date: Sat, 5 Apr 1997 01:49:16 +0200 (MET DST) Cc: current@freebsd.org X-Mailer: ELM [version 2.4ME+ PL30 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > A week or so back someone posted a message refering to a problem with > mount at boot time. The same problem is happening to my -current box after > a 'make world' (I didn't have a chance of building a new kernel...): > > mount: ufs filesystem is not available [...] > is mounted at /mnt2. Should I mount /dev/rsd0a (my "/" ) onto / or onto > /mnt, or some such thing? I tried some combinations, but never got access > to the fixed drive (mount complains it needs a "block device" or something > like that). Well, so give it a block device, i. e. /dev/sd0a (w/o the "r" for raw device) You have to specify the raw-device to all programs that want a disk device. (like newfs, disklabel ...) With one exception: mount. Wolfgang From owner-freebsd-current Fri Apr 4 15:49:37 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id PAA11707 for current-outgoing; Fri, 4 Apr 1997 15:49:37 -0800 (PST) Received: from whistle.com (s205m131.whistle.com [207.76.205.131]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id PAA11693 for ; Fri, 4 Apr 1997 15:49:33 -0800 (PST) Received: (from smap@localhost) by whistle.com (8.7.5/8.6.12) id PAA08248; Fri, 4 Apr 1997 15:49:02 -0800 (PST) Received: from crab.whistle.com(207.76.205.112) by whistle.com via smap (V1.3) id sma008246; Fri Apr 4 15:48:59 1997 Received: (from ambrisko@localhost) by crab.whistle.com (8.8.5/8.6.12) id PAA13436; Fri, 4 Apr 1997 15:50:42 -0800 (PST) From: Doug Ambrisko Message-Id: <199704042350.PAA13436@crab.whistle.com> Subject: Re: Oops In-Reply-To: <199704040539.WAA26546@rocky.mt.sri.com> from Nate Williams at "Apr 3, 97 10:39:14 pm" To: nate@mt.sri.com (Nate Williams) Date: Fri, 4 Apr 1997 15:50:42 -0800 (PST) Cc: karl@mcs.net, jdp@polstra.com, current@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL25 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Nate Williams writes: | | I had this problem, but it turned out I was running V13.5. I had | installed V14.1, but there was an old binary that was getting picked up | first. It crashed for 3-4 days straight w/out me noticing it until I | finally noted that later parts of my tree weren't getting updated. Yep I ran into the same problem since I had /usr/local/sbin before /usr/local/bin in my path and cvsup was moved into /usr/local/bin. Doug A. From owner-freebsd-current Fri Apr 4 18:47:48 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id SAA16760 for current-outgoing; Fri, 4 Apr 1997 18:47:48 -0800 (PST) Received: from sequent.kiae.su (sequent.kiae.su [193.125.152.6]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id SAA16754 for ; Fri, 4 Apr 1997 18:47:43 -0800 (PST) Received: by sequent.kiae.su id AA09892 (5.65.kiae-2 ); Sat, 5 Apr 1997 05:38:34 +0300 Received: by sequent.KIAE.su (UUMAIL/2.0); Sat, 5 Apr 97 05:38:34 +0300 Received: (from ache@localhost) by nagual.ru (8.8.5/8.8.5) id GAA01842; Sat, 5 Apr 1997 06:34:27 +0400 (MSD) Date: Sat, 5 Apr 1997 06:34:24 +0400 (MSD) From: =?KOI8-R?B?4c7E0sXKIP7F0s7P1w==?= To: Joerg Wunsch Cc: FreeBSD Current Subject: Re: modify termcap to support both A[FB] and S[fb]... In-Reply-To: <19970404221051.PZ02960@uriah.heep.sax.de> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Fri, 4 Apr 1997, J Wunsch wrote: > I object against your objection. :-) ncurses (libdialog?) seems to > have made a simlar arbitrary decision about using Sf/Sb. None if them > is ``more correct'' than the other one, and i remember a discussion in > the XFree86 team that AB/AF are supposedly from SysV land. We don't need to add A* entries, as I already say, the reason is misunderstanding between S* and A* treating. Sb not equal to AB and Sf not equal to AF. Sb (setb) stays as "set background color" AB (setab) stays as "set ANSI background color" similar things for Sf/AF The difference is that S* entries could put any color (like user-defined) while A* entries restricts to ANSI colors only. The rule is: if terminal can't redifine colors and its colors are ANSI ones, we should use A* entries, else S* entries (not both of them in any case). This subject reveal a bug in cons25 termcap entry, A* should be there, I'll fix it ASAP. -- Andrey A. Chernov http://www.nagual.ru/~ache/ From owner-freebsd-current Fri Apr 4 19:46:57 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id TAA18683 for current-outgoing; Fri, 4 Apr 1997 19:46:57 -0800 (PST) Received: from sovcom.kiae.su (sovcom.kiae.su [193.125.152.1]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id TAA18678 for ; Fri, 4 Apr 1997 19:46:54 -0800 (PST) Received: by sovcom.kiae.su id AA29933 (5.65.kiae-1 ); Sat, 5 Apr 1997 06:14:59 +0300 Received: by sovcom.KIAE.su (UUMAIL/2.0); Sat, 5 Apr 97 06:14:58 +0300 Received: (from ache@localhost) by nagual.ru (8.8.5/8.8.5) id HAA01938; Sat, 5 Apr 1997 07:10:09 +0400 (MSD) Date: Sat, 5 Apr 1997 07:10:04 +0400 (MSD) From: =?KOI8-R?B?4c7E0sXKIP7F0s7P1w==?= To: Joerg Wunsch Cc: FreeBSD Current Subject: Re: modify termcap to support both A[FB] and S[fb]... In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=KOI8-R Content-Transfer-Encoding: 8BIT Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Sat, 5 Apr 1997, áÎÄÒÅÊ þÅÒÎÏ× wrote: > The rule is: if terminal can't redifine colors and its colors are ANSI > ones, we should use A* entries, else S* entries (not both of them in > any case). If terminal can redifine colors (or have own colors != ANSI) AND have pre-defined ANSI colors too (which can't be redifined), we can use both, of course, but I don't know any example. -- Andrey A. Chernov http://www.nagual.ru/~ache/ From owner-freebsd-current Fri Apr 4 21:46:02 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id VAA22531 for current-outgoing; Fri, 4 Apr 1997 21:46:02 -0800 (PST) Received: from pdx1.world.net (pdx1.world.net [192.243.32.18]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id VAA22525 for ; Fri, 4 Apr 1997 21:45:59 -0800 (PST) From: proff@suburbia.net Received: from suburbia.net (suburbia.net [203.4.184.1]) by pdx1.world.net (8.7.5/8.7.3) with SMTP id VAA08483 for ; Fri, 4 Apr 1997 21:48:16 -0800 (PST) Received: (qmail 12817 invoked by uid 110); 5 Apr 1997 04:49:54 -0000 Message-ID: <19970405044954.12816.qmail@suburbia.net> Subject: Re: ipfilter In-Reply-To: from Jimbo Bahooli at "Apr 4, 97 04:32:11 pm" To: moke@fools.ecp.net (Jimbo Bahooli) Date: Sat, 5 Apr 1997 14:49:53 +1000 (EST) Cc: freebsd-current@freebsd.org X-Mailer: ELM [version 2.4ME+ PL28 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > I upgraded my src/contrib/ipfilter to the new ipfilter in hopes that it > actually would compile. Currently i'm getting the error make: don't know > how to make build. . Any help from anyone? The symlinks are wrong in > BSD/i386 it appears, but there is no build in the Makefile it should point > to anyways, so i am lost. BSD/Makefile hasn't ever been commited. Cheers, Julian. From owner-freebsd-current Fri Apr 4 22:32:13 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id WAA23504 for current-outgoing; Fri, 4 Apr 1997 22:32:13 -0800 (PST) Received: from icicle.winternet.com (adm@icicle.winternet.com [198.174.169.5]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id WAA23499 for ; Fri, 4 Apr 1997 22:32:10 -0800 (PST) Received: (from adm@localhost) by icicle.winternet.com (8.7.5/8.7.5) id AAA14848; Sat, 5 Apr 1997 00:32:04 -0600 (CST) Posted-Date: Sat, 5 Apr 1997 00:32:04 -0600 (CST) Received: from fools.ecp.net(204.246.64.101) by icicle.winternet.com via smap (V2.0beta) id xma014810; Sat, 5 Apr 97 00:31:50 -0600 Received: from localhost (moke@localhost) by fools.ecp.net (8.8.5/8.8.4) with SMTP id AAA00294; Sat, 5 Apr 1997 00:27:03 -0600 (CST) Date: Sat, 5 Apr 1997 00:27:02 -0600 (CST) From: Jimbo Bahooli To: proff@suburbia.net cc: freebsd-current@freebsd.org Subject: Re: ipfilter In-Reply-To: <19970405044954.12816.qmail@suburbia.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > I upgraded my src/contrib/ipfilter to the new ipfilter in hopes that it > > actually would compile. Currently i'm getting the error make: don't know > > how to make build. . Any help from anyone? The symlinks are wrong in > > BSD/i386 it appears, but there is no build in the Makefile it should point > > to anyways, so i am lost. > > BSD/Makefile hasn't ever been commited. > Yep, I figured that out shortly after posting this message. So I went and found the real tarball. Compiled great and worked decently, although I had to add a sleep(2); in ipmon.c because it was using 100% cpu when it could. From owner-freebsd-current Fri Apr 4 23:56:44 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id XAA26289 for current-outgoing; Fri, 4 Apr 1997 23:56:44 -0800 (PST) Received: from hydrogen.nike.efn.org (resnet.uoregon.edu [128.223.170.28]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id XAA26282 for ; Fri, 4 Apr 1997 23:56:39 -0800 (PST) Received: (from jmg@localhost) by hydrogen.nike.efn.org (8.8.4/8.8.4) id XAA14627; Fri, 4 Apr 1997 23:56:37 -0800 (PST) Message-ID: <19970404235636.44208@hydrogen.nike.efn.org> Date: Fri, 4 Apr 1997 23:56:36 -0800 From: John-Mark Gurney To: FreeBSD Current Subject: Re: modify termcap to support both A[FB] and S[fb]... References: <19970404221051.PZ02960@uriah.heep.sax.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.67 In-Reply-To: ; from ??????????????? on Sat, Apr 05, 1997 at 06:34:24AM +0400 Reply-To: John-Mark Gurney Organization: Cu Networking X-Operating-System: FreeBSD 2.2-960801-SNAP 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-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk ??????????????? scribbled this message on Apr 5: > On Fri, 4 Apr 1997, J Wunsch wrote: > > > I object against your objection. :-) ncurses (libdialog?) seems to > > have made a simlar arbitrary decision about using Sf/Sb. None if them > > is ``more correct'' than the other one, and i remember a discussion in > > the XFree86 team that AB/AF are supposedly from SysV land. > > We don't need to add A* entries, as I already say, the reason is > misunderstanding between S* and A* treating. > > Sb not equal to AB and Sf not equal to AF. > > Sb (setb) stays as "set background color" > AB (setab) stays as "set ANSI background color" > > similar things for Sf/AF could you point me to the document which says this?? I like to make sure this is the case... all terminfo_examples.doc says is: set_a_foreground "setaf" str "AF" or set_foreground "setf" str "Sf" thanks... > The difference is that S* entries could put any color (like user-defined) > while A* entries restricts to ANSI colors only. hmm... but what about the terminals were you define the colors to be ansi colors (like I've almost done with my tek)... also.. do you propose to make ALL applications understand the difference between the two?? > The rule is: if terminal can't redifine colors and its colors are ANSI > ones, we should use A* entries, else S* entries (not both of them in > any case). > > This subject reveal a bug in cons25 termcap entry, A* should be there, > I'll fix it ASAP. you CAN change the console's colors... maybe not through anything that FreeBSD provides... but you can do this... also.. are you going to update ansi's entry too?? ttyl.. -- John-Mark Cu Networking Modem/FAX: +1 541 683 6954 Live in Peace, destroy Micro$oft, support free software, run FreeBSD From owner-freebsd-current Sat Apr 5 01:58:26 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id BAA29715 for current-outgoing; Sat, 5 Apr 1997 01:58:26 -0800 (PST) Received: from sovcom.kiae.su (sovcom.kiae.su [193.125.152.1]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id BAA29710 for ; Sat, 5 Apr 1997 01:58:23 -0800 (PST) Received: by sovcom.kiae.su id AA29558 (5.65.kiae-1 ); Sat, 5 Apr 1997 12:52:40 +0300 Received: by sovcom.KIAE.su (UUMAIL/2.0); Sat, 5 Apr 97 12:52:39 +0300 Received: (from ache@localhost) by nagual.ru (8.8.5/8.8.5) id NAA00297; Sat, 5 Apr 1997 13:48:36 +0400 (MSD) Date: Sat, 5 Apr 1997 13:48:32 +0400 (MSD) From: =?KOI8-R?B?4c7E0sXKIP7F0s7P1w==?= To: John-Mark Gurney Cc: FreeBSD Current Subject: Re: modify termcap to support both A[FB] and S[fb]... In-Reply-To: <19970404235636.44208@hydrogen.nike.efn.org> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Fri, 4 Apr 1997, John-Mark Gurney wrote: > > Sb (setb) stays as "set background color" > > AB (setab) stays as "set ANSI background color" > > > > similar things for Sf/AF > > could you point me to the document which says this?? I like to make sure > this is the case... all terminfo_examples.doc says is: > set_a_foreground "setaf" str "AF" > or > set_foreground "setf" str "Sf" man terminfo in SVr4 and ncurses include/Caps (not FreeBSD version) > > The difference is that S* entries could put any color (like user-defined) > > while A* entries restricts to ANSI colors only. > > hmm... but what about the terminals were you define the colors to be ansi > colors (like I've almost done with my tek)... also.. do you propose to > make ALL applications understand the difference between the two?? I mean termcap way of redefining colors only (this capability usually taking 3 parameters like RGB or HSL) > you CAN change the console's colors... maybe not through anything that > FreeBSD provides... but you can do this... So, it will be your responsibility... > also.. are you going to update ansi's entry too?? All incorrect Sf/Sb just changed to AF/AB, I don't add new ones. -- Andrey A. Chernov http://www.nagual.ru/~ache/ From owner-freebsd-current Sat Apr 5 02:08:33 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id CAA00585 for current-outgoing; Sat, 5 Apr 1997 02:08:33 -0800 (PST) Received: from hda.hda.com (hda-bicnet.bicnet.net [207.198.1.121]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id CAA00580 for ; Sat, 5 Apr 1997 02:08:26 -0800 (PST) Received: (from dufault@localhost) by hda.hda.com (8.8.5/8.8.5) id FAA08421 for current@freebsd.org; Sat, 5 Apr 1997 05:06:04 -0500 (EST) From: Peter Dufault Message-Id: <199704051006.FAA08421@hda.hda.com> Subject: Breaking the lkm DISPATCH macro To: current@freebsd.org Date: Sat, 5 Apr 1997 05:06:03 -0500 (EST) X-Mailer: ELM [version 2.4ME+ PL25 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Heads up: I'm about to break LKM's DISPATCH macro by passing in the name argument. LKM's are broken in -current for MOD_DEV, and in fixing them I want to eliminate the static _module structure by prepending the name. This can't be done compatably (without cruft like feature test macros) since DISPATCH uses _module directly and the new MOD_DECL functions will prepend the name. The interface change will require changing DISPATCH to MOD_DISPATCH (gratuitous for consistency with the other macros) and passing the name in. I'm keeping a DISPATCH macro there to generate an error that leads back to the header to see what changed. I've fixed the code in the tree but user LKMs in -current will break. They're already broken in -current versus non -current since the name argument has changed from a string to an identifier so I think that is a minor issue. Bruce reviewed the changes. -- Peter Dufault (dufault@hda.com) Realtime Machine Control and Simulation HD Associates, Inc. Voice: 508 433 6936 From owner-freebsd-current Sat Apr 5 02:24:11 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id CAA01142 for current-outgoing; Sat, 5 Apr 1997 02:24:11 -0800 (PST) Received: from hydrogen.nike.efn.org (resnet.uoregon.edu [128.223.170.28]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id CAA01099 for ; Sat, 5 Apr 1997 02:23:58 -0800 (PST) Received: (from jmg@localhost) by hydrogen.nike.efn.org (8.8.4/8.8.4) id CAA15568; Sat, 5 Apr 1997 02:23:54 -0800 (PST) Message-ID: <19970405022353.21034@hydrogen.nike.efn.org> Date: Sat, 5 Apr 1997 02:23:53 -0800 From: John-Mark Gurney To: FreeBSD Current Subject: Re: modify termcap to support both A[FB] and S[fb]... References: <19970404235636.44208@hydrogen.nike.efn.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.67 In-Reply-To: ; from ??????????????? on Sat, Apr 05, 1997 at 01:48:32PM +0400 Reply-To: John-Mark Gurney Organization: Cu Networking X-Operating-System: FreeBSD 2.2-960801-SNAP 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-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk ??????????????? scribbled this message on Apr 5: > On Fri, 4 Apr 1997, John-Mark Gurney wrote: > > > > Sb (setb) stays as "set background color" > > > AB (setab) stays as "set ANSI background color" > > > > > > similar things for Sf/AF > > > > could you point me to the document which says this?? I like to make sure > > this is the case... all terminfo_examples.doc says is: > > set_a_foreground "setaf" str "AF" > > or > > set_foreground "setf" str "Sf" > > man terminfo in SVr4 and ncurses include/Caps (not FreeBSD version) looks like I'm going to be updating our terminfo_examples.doc... thanks for the pointers... > > > The difference is that S* entries could put any color (like user-defined) > > > while A* entries restricts to ANSI colors only. > > > > hmm... but what about the terminals were you define the colors to be ansi > > colors (like I've almost done with my tek)... also.. do you propose to > > make ALL applications understand the difference between the two?? > > I mean termcap way of redefining colors only (this capability usually > taking 3 parameters like RGB or HSL) ahh... ok... thanks... this makes the above clearer... > > you CAN change the console's colors... maybe not through anything that > > FreeBSD provides... but you can do this... > > So, it will be your responsibility... heh... I was thinking of writing to the PAL entries to change 'em... but your most recent statement above makes what I said (about being able to change syscons's colors) void and pointless... > > also.. are you going to update ansi's entry too?? > > All incorrect Sf/Sb just changed to AF/AB, I don't add new ones. ok... I'll update the ansi entry when I'm through making all my mods... hopefully by then I'll have a better tek4107 entry.. :) thanks again for the pointers (and info)... ttyl.. -- John-Mark Cu Networking Modem/FAX: +1 541 683 6954 Live in Peace, destroy Micro$oft, support free software, run FreeBSD From owner-freebsd-current Sat Apr 5 03:04:44 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id DAA02070 for current-outgoing; Sat, 5 Apr 1997 03:04:44 -0800 (PST) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id DAA02065 for ; Sat, 5 Apr 1997 03:04:40 -0800 (PST) Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.5/8.6.9) id UAA03952; Sat, 5 Apr 1997 20:57:18 +1000 Date: Sat, 5 Apr 1997 20:57:18 +1000 From: Bruce Evans Message-Id: <199704051057.UAA03952@godzilla.zeta.org.au> To: current@freebsd.org, dufault@hda.com Subject: Re: Breaking the lkm DISPATCH macro Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >I've fixed the code in the tree but user LKMs in -current will break. >They're already broken in -current versus non -current since the name >argument has changed from a string to an identifier so I think that >is a minor issue. Only very-uncurrent user LKMs are broken in -current, since the name arg changed from a string to an identifier in -current almost 18 months ago. 2.2 is the same as -current here. Bruce From owner-freebsd-current Sat Apr 5 04:14:16 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id EAA03993 for current-outgoing; Sat, 5 Apr 1997 04:14:16 -0800 (PST) Received: from nlsystems.com (nlsys.demon.co.uk [158.152.125.33]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id EAA03986 for ; Sat, 5 Apr 1997 04:14:09 -0800 (PST) Received: from herring.nlsystems.com (herring.nlsystems.com [10.0.0.2]) by nlsystems.com (8.8.5/8.8.5) with SMTP id NAA21842; Sat, 5 Apr 1997 13:14:18 +0100 (BST) Date: Sat, 5 Apr 1997 13:14:18 +0100 (BST) From: Doug Rabson To: Peter Dufault cc: current@freebsd.org Subject: Re: Breaking the lkm DISPATCH macro In-Reply-To: <199704051006.FAA08421@hda.hda.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Sat, 5 Apr 1997, Peter Dufault wrote: > Heads up: > > I'm about to break LKM's DISPATCH macro by passing in the name > argument. LKM's are broken in -current for MOD_DEV, and in fixing > them I want to eliminate the static _module structure by prepending > the name. > > This can't be done compatably (without cruft like feature test macros) > since DISPATCH uses _module directly and the new MOD_DECL functions > will prepend the name. > > The interface change will require changing DISPATCH to > MOD_DISPATCH (gratuitous for consistency with the other macros) > and passing the name in. I'm keeping a DISPATCH macro there to > generate an error that leads back to the header to see what changed. > > I've fixed the code in the tree but user LKMs in -current will break. > They're already broken in -current versus non -current since the name > argument has changed from a string to an identifier so I think that > is a minor issue. Does this mean that my OSS module will stop working? Sigh.. -- Doug Rabson Mail: dfr@nlsystems.com Nonlinear Systems Ltd. Phone: +44 181 951 1891 From owner-freebsd-current Sat Apr 5 04:18:34 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id EAA04085 for current-outgoing; Sat, 5 Apr 1997 04:18:34 -0800 (PST) Received: from mailhost (user-37kb49m.dialup.mindspring.com [207.69.145.54]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id EAA04080 for ; Sat, 5 Apr 1997 04:18:28 -0800 (PST) Received: from rlb by mailhost with smtp (Smail3.1.29.1 #1) id m0wDUQV-000G03C; Sat, 5 Apr 97 07:18 EST Message-ID: <33464317.2E0F@mindspring.com> Date: Sat, 05 Apr 1997 07:18:31 -0500 From: Ron Bolin X-Mailer: Mozilla 3.01Gold (X11; I; SunOS 5.5.1 i86pc) MIME-Version: 1.0 To: FreeBSD Current Mailing List Subject: CVSUP RELENG_2_2 Question Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I am trying to get the contrib/ipfilter tree via cvsup. I am using tag=RELENG_2_2, but it never pulls it down. Is there a new tag for 2.2? I found ipfilter in the CVS Repository WWW page http://www/freebsd.org/cgi/cvsweg.cgi. Thank's Ron -- **************************************************************************** Ron Bolin rlb@mindspring.com, http://www.mindspring.com/~rlb/ http://rlb.users.mindspring.com gs01rlb@panther.gsu.edu matrlbx@indigo4.cs.gsu.edu Home: 770-992-8877 Work: 770-246-5404 From owner-freebsd-current Sat Apr 5 04:24:28 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id EAA04897 for current-outgoing; Sat, 5 Apr 1997 04:24:28 -0800 (PST) Received: from hydrogen.nike.efn.org (resnet.uoregon.edu [128.223.170.28]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id EAA04887 for ; Sat, 5 Apr 1997 04:24:23 -0800 (PST) Received: (from jmg@localhost) by hydrogen.nike.efn.org (8.8.4/8.8.4) id EAA19513; Sat, 5 Apr 1997 04:24:22 -0800 (PST) Message-ID: <19970405042421.06894@hydrogen.nike.efn.org> Date: Sat, 5 Apr 1997 04:24:21 -0800 From: John-Mark Gurney To: FreeBSD Current Subject: using opendir, but passing a fd instead of path... Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.67 Reply-To: John-Mark Gurney Organization: Cu Networking X-Operating-System: FreeBSD 2.2-960801-SNAP 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-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I was looking at the man page for opendir, and currently there isn't a way to open a dir from a file descriptor... would this be a useful addition to the opendir set of routines? or would this be a "wart" on something that really shouldn't be touched? the reason I ask is because of a program that I'm writing, and I don't feel like having to pass the path to a subfunction, but I am passing an open fd of the dir... thanks for the input... ttyl.. -- John-Mark Cu Networking Modem/FAX: +1 541 683 6954 Live in Peace, destroy Micro$oft, support free software, run FreeBSD From owner-freebsd-current Sat Apr 5 04:31:01 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id EAA05434 for current-outgoing; Sat, 5 Apr 1997 04:31:01 -0800 (PST) Received: from hda.hda.com (hda-bicnet.bicnet.net [207.198.1.121]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id EAA05426 for ; Sat, 5 Apr 1997 04:30:57 -0800 (PST) Received: (from dufault@localhost) by hda.hda.com (8.8.5/8.8.5) id HAA08730; Sat, 5 Apr 1997 07:28:25 -0500 (EST) From: Peter Dufault Message-Id: <199704051228.HAA08730@hda.hda.com> Subject: Re: Breaking the lkm DISPATCH macro In-Reply-To: from Doug Rabson at "Apr 5, 97 01:14:18 pm" To: dfr@nlsystems.com (Doug Rabson) Date: Sat, 5 Apr 1997 07:28:24 -0500 (EST) Cc: dufault@hda.com, current@freebsd.org X-Mailer: ELM [version 2.4ME+ PL25 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > Does this mean that my OSS module will stop working? Sigh.. Binary modules will continue to work. There will be a compile time error. -- Peter Dufault (dufault@hda.com) Realtime Machine Control and Simulation HD Associates, Inc. Voice: 508 433 6936 From owner-freebsd-current Sat Apr 5 04:42:31 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id EAA05687 for current-outgoing; Sat, 5 Apr 1997 04:42:31 -0800 (PST) Received: from time.cdrom.com (root@time.cdrom.com [204.216.27.226]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id EAA05681 for ; Sat, 5 Apr 1997 04:42:27 -0800 (PST) Received: from time.cdrom.com (jkh@localhost [127.0.0.1]) by time.cdrom.com (8.8.5/8.6.9) with ESMTP id EAA04369; Sat, 5 Apr 1997 04:42:19 -0800 (PST) To: Doug Rabson cc: Peter Dufault , current@freebsd.org Subject: Re: Breaking the lkm DISPATCH macro In-reply-to: Your message of "Sat, 05 Apr 1997 13:14:18 +0100." Date: Sat, 05 Apr 1997 04:42:16 -0800 Message-ID: <4365.860244136@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > Does this mean that my OSS module will stop working? Sigh.. That brings up a very good point, which is that we need to start thinking about contacting vendors when we do stuff which will cause their stuff to break. I realize that everyone can't keep track of every single commercial product available for FreeBSD (not that it's exactly *hard* right now though :) and its dependencies, so all I'm asking is that if a user (like Doug here) raises an advance concern or we start getting bug reports from our early BETA customers WRT some commercial product, that should raise a *really big red flag* with us. The commercial sector contains some of our best current and potential allies, and the last thing we need to do is alienate them by breaking interfaces without at least trying to contact their developers in advance or working out *some* sort of arrangement. Don't make their customers be the first ones to tell them that FreeBSD busted their software, eh? ;-) In this case it's not such a big deal since OSS is not currently guaranteed to run under 3.0, nor is 3.0 mentioned as supported in any way, so one could argue that user of it were on thin ice anyway. What *would* be a big deal, however, would be if it took Hannu until the actual release day of 3.0 to find out about the incompatibility! :-) Jordan From owner-freebsd-current Sat Apr 5 04:54:02 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id EAA06089 for current-outgoing; Sat, 5 Apr 1997 04:54:02 -0800 (PST) Received: from shrimp.dataplex.net (shrimp.dataplex.net [208.2.87.3]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id EAA06084 for ; Sat, 5 Apr 1997 04:53:58 -0800 (PST) Received: from [208.2.87.4] (cod.dataplex.net [208.2.87.4]) by shrimp.dataplex.net (8.8.5/8.8.5) with ESMTP id GAA11146; Sat, 5 Apr 1997 06:53:53 -0600 (CST) X-Sender: rkw@shrimp.dataplex.net Message-Id: In-Reply-To: <33464317.2E0F@mindspring.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sat, 5 Apr 1997 06:49:08 -0600 To: Ron Bolin From: Richard Wackerbarth Subject: Re: CVSUP RELENG_2_2 Question Cc: FreeBSD Current Mailing List Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk At 6:18 AM -0600 4/5/97, Ron Bolin wrote: >I am trying to get the contrib/ipfilter tree via cvsup. > >I am using tag=RELENG_2_2, but it never pulls it down. > >Is there a new tag for 2.2? I found ipfilter in the CVS >Repository WWW page http://www/freebsd.org/cgi/cvsweg.cgi. No. You have the correct tag for the 2.2 tree. However, it is likely that the current ipfilter stuff has not been placed in that tree yet. There is quite a bit of discussion of problems with it in "-current" and I suspect that they will, properly, refrain from adding it to 2.2 until the implementation settles down. From owner-freebsd-current Sat Apr 5 05:50:50 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id FAA09574 for current-outgoing; Sat, 5 Apr 1997 05:50:50 -0800 (PST) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id FAA09569 for ; Sat, 5 Apr 1997 05:50:47 -0800 (PST) Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.5/8.6.9) id XAA08067 for current@freebsd.org; Sat, 5 Apr 1997 23:48:48 +1000 Date: Sat, 5 Apr 1997 23:48:48 +1000 From: Bruce Evans Message-Id: <199704051348.XAA08067@godzilla.zeta.org.au> To: current@freebsd.org Subject: Re: cvs commit: src/sys/i386/isa sio.c Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > Modified: sys/i386/isa sio.c > Log: > Use device flags instead of options for serial console configuration > (see LINT). There is a new low-level console type that is more suitable > for use with gdb-remote. You must use `flags 0x10' for sio0 to recover the current default behaviour, or `flags 0x30' for sio0 instead of `options COMCONSOLE'. The flags work on any (one) sio unit. Bruce From owner-freebsd-current Sat Apr 5 06:54:49 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id GAA11116 for current-outgoing; Sat, 5 Apr 1997 06:54:49 -0800 (PST) Received: from nlsystems.com (nlsys.demon.co.uk [158.152.125.33]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id GAA11109 for ; Sat, 5 Apr 1997 06:54:45 -0800 (PST) Received: from herring.nlsystems.com (herring.nlsystems.com [10.0.0.2]) by nlsystems.com (8.8.5/8.8.5) with SMTP id PAA22383; Sat, 5 Apr 1997 15:54:20 +0100 (BST) Date: Sat, 5 Apr 1997 15:54:20 +0100 (BST) From: Doug Rabson To: "Jordan K. Hubbard" cc: Peter Dufault , current@freebsd.org Subject: Re: Breaking the lkm DISPATCH macro In-Reply-To: <4365.860244136@time.cdrom.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Sat, 5 Apr 1997, Jordan K. Hubbard wrote: > > Does this mean that my OSS module will stop working? Sigh.. > > That brings up a very good point, which is that we need to start > thinking about contacting vendors when we do stuff which will cause > their stuff to break. I realize that everyone can't keep track of > every single commercial product available for FreeBSD (not that it's > exactly *hard* right now though :) and its dependencies, so all I'm > asking is that if a user (like Doug here) raises an advance concern or > we start getting bug reports from our early BETA customers WRT some > commercial product, that should raise a *really big red flag* with us. > > The commercial sector contains some of our best current and potential > allies, and the last thing we need to do is alienate them by breaking > interfaces without at least trying to contact their developers in > advance or working out *some* sort of arrangement. Don't make their > customers be the first ones to tell them that FreeBSD busted their > software, eh? ;-) > I totally agree. Developers ought to be *very* careful when changing kernel data structures. I don't want to get too religious about back compatibility (we aren't Windoze after all) but if a couple of minutes thought can preserve binary compatibility, then it is a couple of minutes well spent. > In this case it's not such a big deal since OSS is not currently > guaranteed to run under 3.0, nor is 3.0 mentioned as supported in any > way, so one could argue that user of it were on thin ice anyway. What > *would* be a big deal, however, would be if it took Hannu until the > actual release day of 3.0 to find out about the incompatibility! :-) It works pretty well on 3.0 though :-) -- Doug Rabson Mail: dfr@nlsystems.com Nonlinear Systems Ltd. Phone: +44 181 951 1891 From owner-freebsd-current Sat Apr 5 07:01:20 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id HAA11337 for current-outgoing; Sat, 5 Apr 1997 07:01:20 -0800 (PST) Received: from nlsystems.com (nlsys.demon.co.uk [158.152.125.33]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id HAA11329 for ; Sat, 5 Apr 1997 07:01:15 -0800 (PST) Received: from herring.nlsystems.com (herring.nlsystems.com [10.0.0.2]) by nlsystems.com (8.8.5/8.8.5) with SMTP id QAA22396 for ; Sat, 5 Apr 1997 16:00:46 +0100 (BST) Date: Sat, 5 Apr 1997 16:00:46 +0100 (BST) From: Doug Rabson To: current@freebsd.org Subject: Is the vx driver supposed to work at 100Mbps? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk My new machine had one of these in it and performance for 100Mbps ethernet was abysmal. I only got 50k/sec for ftp transfers. Luckily I happened to have an Intel card lying around (6Meg/sec) but it would be nice to get the 3com card working since there are huge numbers of them being sold all over the place. -- Doug Rabson Mail: dfr@nlsystems.com Nonlinear Systems Ltd. Phone: +44 181 951 1891 From owner-freebsd-current Sat Apr 5 07:31:55 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id HAA12787 for current-outgoing; Sat, 5 Apr 1997 07:31:55 -0800 (PST) Received: from Campino.Informatik.RWTH-Aachen.DE (campino.Informatik.RWTH-Aachen.DE [137.226.116.240]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id HAA12782 for ; Sat, 5 Apr 1997 07:31:51 -0800 (PST) Received: from gilberto.physik.rwth-aachen.de (gilberto.physik.rwth-aachen.de [137.226.31.2]) by Campino.Informatik.RWTH-Aachen.DE (RBI-Z-5/8.6.12) with ESMTP id RAA02071; Sat, 5 Apr 1997 17:32:05 +0200 (MET DST) Received: (from kuku@localhost) by gilberto.physik.rwth-aachen.de (8.8.5/8.6.9) id RAA15025; Sat, 5 Apr 1997 17:46:12 +0200 (MET DST) From: Christoph Kukulies Message-Id: <199704051546.RAA15025@gilberto.physik.rwth-aachen.de> Subject: Re: ufs filesystem not available at mount time ... In-Reply-To: from Antonio Bemfica at "Apr 4, 97 05:19:14 pm" To: bemfica@militzer.me.tuns.ca (Antonio Bemfica) Date: Sat, 5 Apr 1997 17:46:12 +0200 (MET DST) Cc: freebsd-current@freebsd.org Reply-To: Christoph Kukulies X-Mailer: ELM [version 2.4ME+ PL28 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > Hello > > A week or so back someone posted a message refering to a problem with > mount at boot time. The same problem is happening to my -current box after > a 'make world' (I didn't have a chance of building a new kernel...): > > mount: ufs filesystem is not available > > One proposed solution was to boot with the fixit floppy and copy the > mount* files onto a new location on the hard drive, reboot it in single > user mode and use the new mount* binaries to get things back in order. > > How exactly do you accomplish that? When I boot with the floppy I have no > access to the hard drive - I have a minimal filesystem up and the floppy > is mounted at /mnt2. Should I mount /dev/rsd0a (my "/" ) onto / or onto > /mnt, or some such thing? I tried some combinations, but never got access > to the fixed drive (mount complains it needs a "block device" or something And why then don't you use the block device? You tried to use the character (raw device) instead of the the block device. Use mount /dev/sd0a /mnt and you will be fine. > like that). > > Any help would be appreciated. > > Antonio > -- ------------------------------------------------------------------------ > "I myself have always disliked being called a 'genius'. It is fascinating > to notice how quick people have been to intuit this aversion and avoid > using the term" -- John Lanchester, in "The Debt to Pleasure" > > -- Christoph P. U. Kukulies kuku@gil.physik.rwth-aachen.de From owner-freebsd-current Sat Apr 5 07:34:57 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id HAA12958 for current-outgoing; Sat, 5 Apr 1997 07:34:57 -0800 (PST) Received: from research.gate.nec.co.jp (research.gate.nec.co.jp [202.32.8.49]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id HAA12952 for ; Sat, 5 Apr 1997 07:34:54 -0800 (PST) Received: from sbl-gw.sbl.cl.nec.co.jp by research.gate.nec.co.jp (8.8.5+2.7Wbeta5/950912) with ESMTP id AAA13735; Sun, 6 Apr 1997 00:34:45 +0900 (JST) Received: from sirius.sbl.cl.nec.co.jp by sbl-gw.sbl.cl.nec.co.jp (8.8.5+2.7Wbeta5/3.3W6) with ESMTP id AAA22587; Sun, 6 Apr 1997 00:34:41 +0900 (JST) Received: by sirius.sbl.cl.nec.co.jp (8.7.5+2.6Wbeta6/3.3W6) with UUCP id AAA07259; Sun, 6 Apr 1997 00:34:36 +0900 (JST) Date: Sun, 6 Apr 1997 00:34:36 +0900 (JST) From: Naoki Hamada Message-Id: <199704051534.AAA07259@sirius.sbl.cl.nec.co.jp> References: To: dfr@nlsystems.com CC: current@freebsd.org In-reply-to: Doug Rabson's message of "Sat, 5 Apr 1997 16:00:46 +0100 (BST)" Subject: Re: Is the vx driver supposed to work at 100Mbps? Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Doug Rabson writes: >My new machine had one of these in it and performance for 100Mbps ethernet >was abysmal. I only got 50k/sec for ftp transfers. Luckily I happened to >have an Intel card lying around (6Meg/sec) but it would be nice to get the >3com card working since there are huge numbers of them being sold all over >the place. Some 3C905 actually shows astonishingly poor performance with the vx driver. Since 3com still does not provide me its technical reference manual, its support is only experimental. They say `Only internal notes which are not distributable to unfamiliar people are present.' Their mails are sincere enough to believe it, so what I can do is only to wait :-< - nao From owner-freebsd-current Sat Apr 5 10:48:49 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id KAA21804 for current-outgoing; Sat, 5 Apr 1997 10:48:49 -0800 (PST) Received: from isbalham.ist.co.uk (isbalham.ist.co.uk [192.31.26.1]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id KAA21798 for ; Sat, 5 Apr 1997 10:48:44 -0800 (PST) Received: from gid.co.uk (uucp@localhost) by isbalham.ist.co.uk (8.8.4/8.8.4) with UUCP id TAA11219 for freebsd.org!current; Sat, 5 Apr 1997 19:45:11 +0100 (BST) Received: from [194.32.164.2] by seagoon.gid.co.uk; Sat, 5 Apr 1997 19:40:10 +0100 X-Sender: rb@194.32.164.1 Message-Id: In-Reply-To: <199704030605.BAA03118@hda.hda.com> References: <199704022357.BAA13237@vector.jhs.no_domain> from "Julian H. Stacey" at "Apr 3, 97 01:57:15 am" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sat, 5 Apr 1997 19:37:51 +0100 To: current@freebsd.org From: Bob Bishop Subject: Re: I've survived make world. Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Just worlded from CTM src-cur 2829, on a kernel dating from 26 Mar. Building a new kernel now... -- Bob Bishop (0118) 977 4017 international code +44 118 rb@gid.co.uk fax (0118) 989 4254 between 0800 and 1800 UK From owner-freebsd-current Sat Apr 5 11:20:52 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id LAA22876 for current-outgoing; Sat, 5 Apr 1997 11:20:52 -0800 (PST) Received: from mantar.slip.netcom.com (mantar.slip.netcom.com [192.187.167.134]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id LAA22871 for ; Sat, 5 Apr 1997 11:20:48 -0800 (PST) Received: from localhost (manfred@localhost) by mantar.slip.netcom.com (8.8.5/8.8.5) with SMTP id LAA00536 for ; Sat, 5 Apr 1997 11:20:45 -0800 (PST) Date: Sat, 5 Apr 1997 11:20:45 -0800 (PST) From: Manfred Antar To: current@freebsd.org Subject: /var/run/utmp Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I keep getting this error in .xsession-errors for a new user make sure that you can write /var/run/utmp! if type w i get: 11:19AM up 15 mins, 1 user, load averages: 0.31, 0.32, 0.19 USER TTY FROM LOGIN@ IDLE WHAT even though there is a user logged in any ideas Thanks ============================== || mantar@netcom.com || || Ph. (415) 647-4843 || ============================== From owner-freebsd-current Sat Apr 5 12:29:42 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id MAA26072 for current-outgoing; Sat, 5 Apr 1997 12:29:42 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.50]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id MAA26067 for ; Sat, 5 Apr 1997 12:29:40 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id NAA23502; Sat, 5 Apr 1997 13:11:41 -0700 From: Terry Lambert Message-Id: <199704052011.NAA23502@phaeton.artisoft.com> Subject: Re: using opendir, but passing a fd instead of path... To: gurney_j@resnet.uoregon.edu Date: Sat, 5 Apr 1997 13:11:41 -0700 (MST) Cc: freebsd-current@freebsd.org In-Reply-To: <19970405042421.06894@hydrogen.nike.efn.org> from "John-Mark Gurney" at Apr 5, 97 04:24:21 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > I was looking at the man page for opendir, and currently there isn't > a way to open a dir from a file descriptor... would this be a useful > addition to the opendir set of routines? or would this be a "wart" on > something that really shouldn't be touched? > > the reason I ask is because of a program that I'm writing, and I don't > feel like having to pass the path to a subfunction, but I am passing > an open fd of the dir... How did you get the open fd of the dir? Probably you should be passing around a DIR *, not an fd. I admit that there is a discrepancy in the interface between the reflexive stdio "fdopen". If you are passing around the fd for fchdir, you should be able to reference the fd out of the dir struct. This would be an interface violation, too, but a minor one: there is a defined macro "dirfd(DIR *)" which returns the fd out of the DIR * in dirent.h, even though it isn't part of the POSIX definition. The reason, if you are interested, is that POSIX does not require a directory to be a normal file accessable through "open". Probably a cleaner overall fix would be to get a "dichdir(DIR *)" defined, but that's not going to happen any time soon, if at all. 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 Sat Apr 5 12:39:51 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id MAA26496 for current-outgoing; Sat, 5 Apr 1997 12:39:51 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.50]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id MAA26491 for ; Sat, 5 Apr 1997 12:39:48 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id NAA23542; Sat, 5 Apr 1997 13:21:13 -0700 From: Terry Lambert Message-Id: <199704052021.NAA23542@phaeton.artisoft.com> Subject: Re: Breaking the lkm DISPATCH macro To: dfr@nlsystems.com (Doug Rabson) Date: Sat, 5 Apr 1997 13:21:13 -0700 (MST) Cc: jkh@time.cdrom.com, dufault@hda.com, current@freebsd.org In-Reply-To: from "Doug Rabson" at Apr 5, 97 03:54:20 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > > Does this mean that my OSS module will stop working? Sigh.. > > > > That brings up a very good point, which is that we need to start > > thinking about contacting vendors when we do stuff which will cause > > their stuff to break. I realize that everyone can't keep track of > > every single commercial product available for FreeBSD (not that it's > > exactly *hard* right now though :) and its dependencies, so all I'm > > asking is that if a user (like Doug here) raises an advance concern or > > we start getting bug reports from our early BETA customers WRT some > > commercial product, that should raise a *really big red flag* with us. [ ... ] > I totally agree. Developers ought to be *very* careful when changing > kernel data structures. I don't want to get too religious about back > compatibility (we aren't Windoze after all) but if a couple of minutes > thought can preserve binary compatibility, then it is a couple of minutes > well spent. This bolsters the case for seperability of kernel interfaces, so as to minimize the breakage that results when you *need* to change an interface. Right now there is a great deal of spaghetti in there, and it's only going to get worse so long as we continue to provide libkvm as an acceptable method of "interfacing". Any time we do that, we "define" a defacto interface that depends on the kernel data structures implementation, and frankly, we can't afford to make any kind of commitment that we will never change important kernel data structures. Binary compatability should be maintained where possible, but should be abandoned when maintaining compatability would criple good engineering changes. That said, I *do* think we've been a bit cavalier about changing the proc struct around without providing a standard interface to needed data through sysctl() or /proc. One of the major villans here is "ps" and family's historical ability to operate on system dumps, and the use of knowledge of the structure size as an iteration mechanism for determining active processes in the system. 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 Sat Apr 5 15:08:41 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id PAA05643 for current-outgoing; Sat, 5 Apr 1997 15:08:41 -0800 (PST) Received: from hydrogen.nike.efn.org (resnet.uoregon.edu [128.223.170.28]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id PAA05634 for ; Sat, 5 Apr 1997 15:08:37 -0800 (PST) Received: (from jmg@localhost) by hydrogen.nike.efn.org (8.8.4/8.8.4) id PAA21300; Sat, 5 Apr 1997 15:08:35 -0800 (PST) Message-ID: <19970405150835.41585@hydrogen.nike.efn.org> Date: Sat, 5 Apr 1997 15:08:35 -0800 From: John-Mark Gurney To: freebsd-current@freebsd.org Subject: Re: using opendir, but passing a fd instead of path... References: <19970405042421.06894@hydrogen.nike.efn.org> <199704052011.NAA23502@phaeton.artisoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.67 In-Reply-To: <199704052011.NAA23502@phaeton.artisoft.com>; from Terry Lambert on Sat, Apr 05, 1997 at 01:11:41PM -0700 Reply-To: John-Mark Gurney Organization: Cu Networking X-Operating-System: FreeBSD 2.2-960801-SNAP 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-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Terry Lambert scribbled this message on Apr 5: > > I was looking at the man page for opendir, and currently there isn't > > a way to open a dir from a file descriptor... would this be a useful > > addition to the opendir set of routines? or would this be a "wart" on > > something that really shouldn't be touched? > > > > the reason I ask is because of a program that I'm writing, and I don't > > feel like having to pass the path to a subfunction, but I am passing > > an open fd of the dir... > > How did you get the open fd of the dir? fd=open("directory", O_RDONLY, 0); then I pass fd to my function... > Probably you should be passing around a DIR *, not an fd. well.. I'm trying to make a generic interface that will handle the differt types of files properly... i.e. after I open the "possible" file, the I fstat the file.. and then, depending on the st_mode of the struct stat... I call different functions... > I admit that there is a discrepancy in the interface between > the reflexive stdio "fdopen". > > If you are passing around the fd for fchdir, you should be able to > reference the fd out of the dir struct. This would be an interface > violation, too, but a minor one: there is a defined macro "dirfd(DIR *)" > which returns the fd out of the DIR * in dirent.h, even though it > isn't part of the POSIX definition. yeh... I noticed that one... but as above it doesn't help me.. :( > The reason, if you are interested, is that POSIX does not require a > directory to be a normal file accessable through "open". ahhh... that's a good reason that opendir doesn't have a fopendir or similar call... > Probably a cleaner overall fix would be to get a "dichdir(DIR *)" > defined, but that's not going to happen any time soon, if at all. as I describe above... this won't help me any... thanks for the extra info... opendir makes a bit more sense now... ttyl.. -- John-Mark Cu Networking Modem/FAX: +1 541 683 6954 Live in Peace, destroy Micro$oft, support free software, run FreeBSD