From owner-freebsd-hackers Sun Dec 31 00:24:52 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id AAA13122 for hackers-outgoing; Sun, 31 Dec 1995 00:24:52 -0800 (PST) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id AAA13116 for ; Sun, 31 Dec 1995 00:24:40 -0800 (PST) Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id TAA23798; Sun, 31 Dec 1995 19:19:11 +1100 Date: Sun, 31 Dec 1995 19:19:11 +1100 From: Bruce Evans Message-Id: <199512310819.TAA23798@godzilla.zeta.org.au> To: bde@zeta.org.au, dawes@rf900.physics.usyd.edu.au Subject: Re: /dev/io Cc: hackers@freebsd.org Sender: owner-hackers@freebsd.org Precedence: bulk >I think the key point is in how the X server securely feeds back the >list of ports and fb addresses. It would have to be done before entering >multiuser mode -- either built in to the kernel (or handled with >/kernel -c), or by running the X server with a special flag during boot. This reminded me of lkms - you could have the addresses and possibly some kernel X support in X_mod.o - but I think lkms shouldn't be used if the kernel is going to be used at a high security level - they would increase the number of weak points. >If this can be done OK, then I don't think there would be problems with >the same ports being used for both security holes and normal operations >providing the /dev/fb device is single-open (to prevent spying on the >fb contents). Making it single-open prevents the running of multiple >servers, or use of the new DGA extension, but I think that's inevitable >at a high security level. The mapped ports can be determined by accessing them and seeing if a signal is generated (unless the kernel traps these accesses specially). Anyway, port like 3D4/3D5 are likely ;-) to be mapped and they only need one insecure index register in them to cause problems. I think these problems are best handled by not allowing the X server to be restarted (is that what you meant by "prevents running of multiple servers"). Start the X server and let it grab I/O permissions and memory maps the same as now before entering secure mode, and don't allow these operations at all in secure mode. This reduces that problem to the usual one of protecting the server's text and data after it has started. Bruce From owner-freebsd-hackers Sun Dec 31 01:27:21 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id BAA14672 for hackers-outgoing; Sun, 31 Dec 1995 01:27:21 -0800 (PST) Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id BAA14651 for ; Sun, 31 Dec 1995 01:27:15 -0800 (PST) Received: from sax.sax.de by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id KAA07858 for ; Sun, 31 Dec 1995 10:27:07 +0100 Received: by sax.sax.de (8.6.11/8.6.12-s1) with UUCP id KAA12624 for freebsd-hackers@freebsd.org; Sun, 31 Dec 1995 10:27:07 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.7.3/8.6.9) id JAA16189 for freebsd-hackers@freebsd.org; Sun, 31 Dec 1995 09:41:42 +0100 (MET) From: J Wunsch Message-Id: <199512310841.JAA16189@uriah.heep.sax.de> Subject: Re: /dev/io To: freebsd-hackers@freebsd.org (FreeBSD hackers) Date: Sun, 31 Dec 1995 09:41:41 +0100 (MET) Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199512310425.PAA16666@rf900.physics.usyd.edu.au> from "David Dawes" at Dec 31, 95 03:25:46 pm X-Phone: +49-351-2012 669 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-hackers@freebsd.org Precedence: bulk As David Dawes wrote: > > >I wasn't even aware that this existed, but looking at the Xserver source > >it seems like BSDI, Linux, FreeBSD, and NetBSD all have it (but only > >Free/NetBSD use it for Xserver IO permission). I don't think that this would be more secure than our scheme anyway. So although it seems to be more `standard', there's nothing we would gain from another scenario. Given that it doesn't have any technical merit at all, i wonder why NetBSD even adopted it. Security considerations: Our KDENABIO is restricted to a process with effective UID 0. Our /dev/io is a security hole in that it allows group kmem processes to access the registers (and i haven't seen any reason why this might be necessary or useful). I think SysV allows any process to get access to IO registers via the IO perm bitmap. :-( (I don't know about Linux.) > The KDENABIO ioctl originates in SYSV, although in SYSV it is used > to enable ports set in an IO permission bitmap. Most X servers need > ports beyond the 0-0x3ff usually covered by such a bitmap. Also there > is a performance penalty in using the bitmap. In particular, it would require us to use CPU task switching. I believe FreeBSD's context switching behaviour has been fine-tuned to be better without separate task state segments per process. > I don't know what the XInside server does to enable I/O permission. I assume they also use the kbd driver. This interface has been established long before anything in the line of /dev/io or other calls, it even existed in the early pccons driver (though there used to be a central call for all actions required for the X server startup). -- 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-hackers Sun Dec 31 01:53:57 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id BAA16754 for hackers-outgoing; Sun, 31 Dec 1995 01:53:57 -0800 (PST) Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id BAA16742 for ; Sun, 31 Dec 1995 01:53:49 -0800 (PST) Received: from sax.sax.de by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id KAA08184 for ; Sun, 31 Dec 1995 10:53:47 +0100 Received: by sax.sax.de (8.6.11/8.6.12-s1) with UUCP id KAA12736 for freebsd-hackers@freebsd.org; Sun, 31 Dec 1995 10:53:46 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.7.3/8.6.9) id KAA26217 for freebsd-hackers@freebsd.org; Sun, 31 Dec 1995 10:39:32 +0100 (MET) From: J Wunsch Message-Id: <199512310939.KAA26217@uriah.heep.sax.de> Subject: Re: /dev/io To: freebsd-hackers@freebsd.org (FreeBSD hackers) Date: Sun, 31 Dec 1995 10:39:32 +0100 (MET) Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199512310448.UAA00410@rah.star-gate.com> from "Amancio Hasty Jr." at Dec 30, 95 08:48:10 pm X-Phone: +49-351-2012 669 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-hackers@freebsd.org Precedence: bulk As Amancio Hasty Jr. wrote: > > I implemented i/o bitmap permissions way back for 386bsd you may be > able to get the original patches if you search minnies mail archive. > Yes, I know that the patches would not apply to the current kernel > however for anyone interested it would show how it was done. What would it gain you? Why do i wanna have it? -- 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-hackers Sun Dec 31 01:54:01 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id BAA16771 for hackers-outgoing; Sun, 31 Dec 1995 01:54:01 -0800 (PST) Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id BAA16751 for ; Sun, 31 Dec 1995 01:53:56 -0800 (PST) Received: from sax.sax.de by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id KAA08189 for ; Sun, 31 Dec 1995 10:53:48 +0100 Received: by sax.sax.de (8.6.11/8.6.12-s1) with UUCP id KAA12739 for freebsd-hackers@freebsd.org; Sun, 31 Dec 1995 10:53:48 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.7.3/8.6.9) id KAA26011 for freebsd-hackers@freebsd.org; Sun, 31 Dec 1995 10:39:00 +0100 (MET) From: J Wunsch Message-Id: <199512310939.KAA26011@uriah.heep.sax.de> Subject: Re: /dev/io To: freebsd-hackers@freebsd.org (FreeBSD hackers) Date: Sun, 31 Dec 1995 10:38:58 +0100 (MET) Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199512310605.RAA16875@rf900.physics.usyd.edu.au> from "David Dawes" at Dec 31, 95 05:05:13 pm X-Phone: +49-351-2012 669 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-hackers@freebsd.org Precedence: bulk As David Dawes wrote: > > Another thing X needs is to mmap the video memory (which is usually done > by mmapping /dev/mem). That can't be done at securelevel >= 2 can it? This raises the old question that the cleanest way for the X server would be implementing all the hardware dependencies at driver level, instead in a user-land program (most likely to be done as an LKM). Nope, i don't see this will be done in the remaining hours/minutes of this year. :-) -- 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-hackers Sun Dec 31 02:09:21 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id CAA17858 for hackers-outgoing; Sun, 31 Dec 1995 02:09:21 -0800 (PST) Received: from rf900.physics.usyd.edu.au (rf900.physics.usyd.edu.au [129.78.129.109]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id CAA17851 for ; Sun, 31 Dec 1995 02:09:14 -0800 (PST) Received: (from dawes@localhost) by rf900.physics.usyd.edu.au (8.6.11/8.6.9) id VAA17343; Sun, 31 Dec 1995 21:09:07 +1100 From: David Dawes Message-Id: <199512311009.VAA17343@rf900.physics.usyd.edu.au> Subject: Re: /dev/io To: bde@zeta.org.au (Bruce Evans) Date: Sun, 31 Dec 1995 21:09:07 +1100 (EST) Cc: hackers@freebsd.org In-Reply-To: <199512310819.TAA23798@godzilla.zeta.org.au> from "Bruce Evans" at Dec 31, 95 07:19:11 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-hackers@freebsd.org Precedence: bulk >>If this can be done OK, then I don't think there would be problems with >>the same ports being used for both security holes and normal operations >>providing the /dev/fb device is single-open (to prevent spying on the >>fb contents). Making it single-open prevents the running of multiple >>servers, or use of the new DGA extension, but I think that's inevitable >>at a high security level. > >The mapped ports can be determined by accessing them and seeing if a >signal is generated (unless the kernel traps these accesses specially). >Anyway, port like 3D4/3D5 are likely ;-) to be mapped and they only >need one insecure index register in them to cause problems. > >I think these problems are best handled by not allowing the X server to >be restarted (is that what you meant by "prevents running of multiple >servers"). Start the X server and let it grab I/O permissions and I meant running more than one server simultaneously. The ability to do this implies the ability for someone to access the video hardware while a server is running, and that can be considered insecure. Then again I suppose being able to start a server at all while in secure mode is insecure because it implies the ability to snoop on the text screen. >memory maps the same as now before entering secure mode, and don't allow >these operations at all in secure mode. This reduces that problem to >the usual one of protecting the server's text and data after it has >started. This is a rather sever limitation though. There are lots of reasons why you might need to restart a server (the most obvious is if it crashes). However, if you really need a secure environment, this may be acceptable. Some might argue that you shouldn't run an X server at all on a machine that really needs to be secure. David From owner-freebsd-hackers Sun Dec 31 02:20:19 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id CAA18717 for hackers-outgoing; Sun, 31 Dec 1995 02:20:19 -0800 (PST) Received: from rf900.physics.usyd.edu.au (rf900.physics.usyd.edu.au [129.78.129.109]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id CAA18667 for ; Sun, 31 Dec 1995 02:20:08 -0800 (PST) Received: (from dawes@localhost) by rf900.physics.usyd.edu.au (8.6.11/8.6.9) id VAA17378; Sun, 31 Dec 1995 21:19:51 +1100 From: David Dawes Message-Id: <199512311019.VAA17378@rf900.physics.usyd.edu.au> Subject: Re: /dev/io To: joerg_wunsch@uriah.heep.sax.de Date: Sun, 31 Dec 1995 21:19:51 +1100 (EST) Cc: freebsd-hackers@freebsd.org In-Reply-To: <199512310841.JAA16189@uriah.heep.sax.de> from "J Wunsch" at Dec 31, 95 09:41:41 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-hackers@freebsd.org Precedence: bulk >Security considerations: > >Our KDENABIO is restricted to a process with effective UID 0. Our >/dev/io is a security hole in that it allows group kmem processes to >access the registers (and i haven't seen any reason why this might be >necessary or useful). > >I think SysV allows any process to get access to IO registers via the >IO perm bitmap. :-( I don't think that's true. I'm fairly sure that only euid 0 processes can do a KDENABIO on SYSV. David From owner-freebsd-hackers Sun Dec 31 02:58:45 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id CAA20887 for hackers-outgoing; Sun, 31 Dec 1995 02:58:45 -0800 (PST) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id CAA20877 for ; Sun, 31 Dec 1995 02:58:38 -0800 (PST) Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id VAA27229; Sun, 31 Dec 1995 21:58:06 +1100 Date: Sun, 31 Dec 1995 21:58:06 +1100 From: Bruce Evans Message-Id: <199512311058.VAA27229@godzilla.zeta.org.au> To: freebsd-hackers@freebsd.org, j@uriah.heep.sax.de Subject: Re: /dev/io Sender: owner-hackers@freebsd.org Precedence: bulk >> The KDENABIO ioctl originates in SYSV, although in SYSV it is used >> to enable ports set in an IO permission bitmap. Most X servers need >> ports beyond the 0-0x3ff usually covered by such a bitmap. Also there >> is a performance penalty in using the bitmap. >In particular, it would require us to use CPU task switching. I >believe FreeBSD's context switching behaviour has been fine-tuned to >be better without separate task state segments per process. The extra context switching overhead would probably be acceptable if the TSS is only switched when necessary. Ordinary tasks could use the current TSS and X could use a separate TSS with a 64K bits (or whatever is necessary) bitmap. The performance penalty per i/o is less acceptable: cycles for outb %al,%dx for CPL <= IOPL (current case) / CPL > IOPL (bitmap case): 386 486 586 5 / 25 10 / 30 9 / 26 Thus even if the hardware is infinitely fast, in the bitmap case, outb on a 586 is up to 52 times as slow as most integer instructions. In the insecure case it is only up to 18 times slower :-]. Bruce From owner-freebsd-hackers Sun Dec 31 05:03:24 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id FAA02218 for hackers-outgoing; Sun, 31 Dec 1995 05:03:24 -0800 (PST) Received: from sl-046.sl.cybercomm.net (sl-015.sl.cybercomm.net [199.171.196.143]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id FAA02213 for ; Sun, 31 Dec 1995 05:03:16 -0800 (PST) Received: from sl-015.sl.cybercomm.net (localhost [127.0.0.1]) by sl-046.sl.cybercomm.net (8.6.12/8.6.12) with SMTP id IAA01460; Sun, 31 Dec 1995 08:03:00 -0500 Date: Sun, 31 Dec 1995 08:02:52 -0500 (EST) From: Sujal Patel X-Sender: smpatel@sl-015.sl.cybercomm.net To: Joerg Wunsch cc: FreeBSD hackers Subject: Re: /dev/io In-Reply-To: <199512310841.JAA16189@uriah.heep.sax.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org Precedence: bulk On Sun, 31 Dec 1995, J Wunsch wrote: > I don't think that this would be more secure than our scheme anyway. > So although it seems to be more `standard', there's nothing we would > gain from another scenario. Given that it doesn't have any technical > merit at all, i wonder why NetBSD even adopted it. I can't say for sure why NetBSD would have adopted it, but I'm not even sure that they have KDENABIO (anymore?) because I couldn't find it in any of their 1.1A-- As far as I can tell the only way in NetBSD is i386_iopl and friends. This could be because NetBSD supports so many different architectures; IOPL is a pretty architecture dependant function and maybe /dev/io is a bit too generic for them. > Our KDENABIO is restricted to a process with effective UID 0. Our > /dev/io is a security hole in that it allows group kmem processes to > access the registers (and i haven't seen any reason why this might be > necessary or useful). I haven't heard any reason why /dev/io is useful or necessary either :) It seems that just about everything uses KDENABIO to gain IO priviledge. > I think SysV allows any process to get access to IO registers via the > IO perm bitmap. :-( > > (I don't know about Linux.) Linux enforces euid 0 credentials on both ioperm() and iopl(). In Linux, you have a small IO permission bitmap (for ports 0-0x3ff) and then you have to use iopl() to gain access to the rest. Sujal From owner-freebsd-hackers Sun Dec 31 05:38:56 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id FAA03021 for hackers-outgoing; Sun, 31 Dec 1995 05:38:56 -0800 (PST) Received: from strider.ibenet.it (root@Strider.Free.IT [194.179.131.1]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id FAA03015 Sun, 31 Dec 1995 05:38:47 -0800 (PST) Received: (from piero@localhost) by strider.ibenet.it (8.7.3/8.6.12) id OAA00902; Sun, 31 Dec 1995 14:37:33 +0100 (MET) From: Piero Serini Message-Id: <199512311337.OAA00902@strider.ibenet.it> Subject: Re: Problems with majordomo To: scrappy@ki.net (Marc G. Fournier) Date: Sun, 31 Dec 1995 14:37:33 +0100 (MET) Cc: jmb@FreeBSD.org, piero@strider.ibenet.it, Hackers@FreeBSD.org In-Reply-To: from "Marc G. Fournier" at Dec 31, 95 00:18:14 am Reply-To: piero@strider.ibenet.it Operating-System: FreeBSD 1.1.5.1 X-Phone-Number: +39 (2) 58113562 X-NCC-RegID: it.ibenet X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-hackers@FreeBSD.org Precedence: bulk Hello. Quoting from Marc G. Fournier (Sun Dec 31 06:18:14 1995): > Actually, 1.93 compiles and installs without any problems...except > that you need an up to date version of perl. I had to install perl5.001m > to use majordomo 1.93. Yup I can confirm this. I just reinstalled majordomo 1.93 from scratch and works now. I think I made a mistake in setting up permissions, even though I chmoded 777 everything while doing the tests after the crash. Bho. I'll download version 1.92 from kriten in case I encounter further problems. I'll also run a script to beat on my server for a few hours to see what happens. For the record, I run FBSD 1.1.5.1 and per 4.036. Many thanks to all who replied me. Happy New Year! -- # $Id: .signature,v 1.12 1995/08/14 12:10:54 piero Exp $ Piero Serini Via Giambologna, 1 I 20136 Milano - ITALY From owner-freebsd-hackers Sun Dec 31 06:16:29 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id GAA04262 for hackers-outgoing; Sun, 31 Dec 1995 06:16:29 -0800 (PST) Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id GAA04257 for ; Sun, 31 Dec 1995 06:16:24 -0800 (PST) Received: from sax.sax.de by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id PAA11599 for ; Sun, 31 Dec 1995 15:16:22 +0100 Received: by sax.sax.de (8.6.11/8.6.12-s1) with UUCP id PAA14524 for freebsd-hackers@freebsd.org; Sun, 31 Dec 1995 15:16:21 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.7.3/8.6.9) id PAA28368 for freebsd-hackers@freebsd.org; Sun, 31 Dec 1995 15:15:09 +0100 (MET) From: J Wunsch Message-Id: <199512311415.PAA28368@uriah.heep.sax.de> Subject: Re: /dev/io To: freebsd-hackers@freebsd.org (FreeBSD hackers) Date: Sun, 31 Dec 1995 15:15:08 +0100 (MET) Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: from "Sujal Patel" at Dec 31, 95 08:02:52 am X-Phone: +49-351-2012 669 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-hackers@freebsd.org Precedence: bulk As Sujal Patel wrote: > > I haven't heard any reason why /dev/io is useful or necessary either :) > It seems that just about everything uses KDENABIO to gain IO priviledge. Since the X server code evolved from SysV code, and the X server has certainly been the first one that had a real requirement for it. -- 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-hackers Sun Dec 31 06:31:20 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id GAA05249 for hackers-outgoing; Sun, 31 Dec 1995 06:31:20 -0800 (PST) Received: from gilberto.physik.rwth-aachen.de (gilberto.physik.rwth-aachen.de [137.226.31.2]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id GAA05240 for ; Sun, 31 Dec 1995 06:31:17 -0800 (PST) Received: (from kuku@localhost) by gilberto.physik.rwth-aachen.de (8.6.11/8.6.9) id PAA00474 for freebsd-hackers@freefall.cdrom.com; Sun, 31 Dec 1995 15:33:04 +0100 Date: Sun, 31 Dec 1995 15:33:04 +0100 From: "Christoph P. Kukulies" Message-Id: <199512311433.PAA00474@gilberto.physik.rwth-aachen.de> To: freebsd-hackers@freefall.FreeBSD.org Subject: frequent reboots lately (2.1.0R) Sender: owner-hackers@FreeBSD.ORG Precedence: bulk I'm getting a bit concerned about this on my sup server lately. I'm getting frequent reboots during the night hours when sups are running and maybe clients are connecting. Is there a way to log supserv connects? FreeBSD 2.1.0-RELEASE (BLUES) #0: Tue Dec 19 21:50:46 1995 blues> last | head kuku ttyp1 gilberto Sun Dec 31 15:23 still logged in kuku ttyp1 gilberto Sun Dec 31 09:27 - 09:28 (00:00) reboot ~ Sun Dec 31 05:23 reboot ~ Sun Dec 31 03:29 reboot ~ Sun Dec 31 02:23 reboot ~ Sun Dec 31 00:25 kuku ttyp1 gilberto Sat Dec 30 20:29 - 20:39 (00:09) kuku ttyp1 gilberto Sat Dec 30 14:33 - 14:33 (00:00) kuku ttyp1 gilberto Thu Dec 28 09:45 - 09:46 (00:01) kuku ttyp1 gilberto Wed Dec 27 10:57 - 10:57 (00:00) 3:23PM up 10:04, 1 user, load averages: 0.14, 0.03, 0.01 blues> ~v --Chris Christoph P. U. Kukulies kuku@gil.physik.rwth-aachen.de From owner-freebsd-hackers Sun Dec 31 07:26:27 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id HAA09306 for hackers-outgoing; Sun, 31 Dec 1995 07:26:27 -0800 (PST) Received: from snoopy.mv.com (snoopy.mv.com [199.125.64.182]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id HAA09284 for ; Sun, 31 Dec 1995 07:26:22 -0800 (PST) Received: (from pw@localhost) by snoopy.mv.com (8.6.12/8.6.9) id JAA01270; Sun, 31 Dec 1995 09:50:24 -0500 Date: Sun, 31 Dec 1995 09:50:24 -0500 From: "Paul F. Werkowski" Message-Id: <199512311450.JAA01270@snoopy.mv.com> To: Lyndon Nerenberg (VE7TCP) Cc: hackers@FreeBSD.ORG Subject: Re: libraries In-Reply-To: <199512301845.KAA08824@multivac.orthanc.com> References: <199512301845.KAA08824@multivac.orthanc.com> Sender: owner-hackers@FreeBSD.ORG Precedence: bulk >>>>> "lyndon" == VE7TCP writes: >>>>> "John" == John Beukema writes: John> This error is a commonn problem. Comment it out in httcp.c John> or add #ifndef __FreeBSD__ #endif (from memory) around the John> declaration. One is defined as char * and the other as John> const char * as I remember. jbeukema lyndon> The correct fix for sys_errlist declarations is: lyndon> #include #if (!defined(BSD) || (BSD < lyndon> 199306) /* define sys_errlist as appropriate for your lyndon> system */ #endif So, is present on all systems that have a C compiler or just systems with compilers that define the 'unix' macro, or just BSD derived systems? Does one need #if defined __FreeBSD__ || defined __listOfOthersKnownToHaveParam_ .. #include /* tests for various flavors of BSD go here */ #endif Offhand, it looks like the OS dependent feature is hidden in an OS dependent file. It seems to me that the compiler ought to emit the root feature list in some standard way so that codes can have some predictable behaviour. Paul From owner-freebsd-hackers Sun Dec 31 08:06:43 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id IAA11824 for hackers-outgoing; Sun, 31 Dec 1995 08:06:43 -0800 (PST) Received: from brasil.moneng.mei.com (brasil.moneng.mei.com [151.186.109.160]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id IAA11819 for ; Sun, 31 Dec 1995 08:06:39 -0800 (PST) Received: (from jgreco@localhost) by brasil.moneng.mei.com (8.7.Beta.1/8.7.Beta.1) id KAA10081 for hackers@freebsd.org; Sun, 31 Dec 1995 10:06:07 -0600 From: Joe Greco Message-Id: <199512311606.KAA10081@brasil.moneng.mei.com> Subject: Re: syscons driver To: hasty@rah.star-gate.com (Amancio Hasty Jr.) Date: Sat, 30 Dec 1995 08:20:39 -0600 (CST) Cc: freebsd-hackers@freebsd.org In-Reply-To: <199512300519.VAA00740@rah.star-gate.com> from "Amancio Hasty Jr." at Dec 29, 95 09:19:51 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-hackers@freebsd.org Precedence: bulk > >>> Joe Greco said: > > That's not always feasible or possible (different types of disks or > > controllers, for example). I hate having to take apart a machine to drop a > > graphics card into it just so I can install... > > > > (ok ok ok I admit it, all of my boxes have graphics cards right now, but the > > ultimate goal is to run mostly serial consoles, because going around the > > back of the equipment racks and plugging and unplugging monitor and keyboard > > extenders to gain console access to a box is silly). > > > > It's bad enough that sysinstall seems to be linked to syscons ... > > Well, it seems to me that you guys are crafty enough to sort out a way > to do a system intall. Yes, but it's a matter of convenience and flexibility. I can reinstall my Solaris fileservers at work from anywhere in the world simply by having somebody drop in the appropriate CD, reboot the machine, and unplug the keyboard. I can then dial in through the terminal server and get access to the serial console. Inconvenience? Minimal: Unplug kbd. And you can even get around that, in a dire emergency, as long as the system was up and running in UNIX (reset the OBP values to use the serial console). Convenience? I can be reinstalling or fixing my fileservers from Jamaica. I can reinstall my FreeBSD boxes down at sol.net by getting in my car, driving down to the office, climb around in back of the racks to switch VGA and keyboard connections, having to pull a box out of the racks if there doesn't happen to BE a VGA card in it, etc. Boy am I ever S.O.L. if I happen to be down in Jamaica when a box goes south. The unfortunate reality is that at work, there ARE other people who could try to fix the box, but I have the flexibility and technology available to fix it myself. Down at sol.net, there is nobody else who can try tofix dead boxes, and I don't have the flexibility available to me to do it from remote. What I'm doing is sufficiently similar to what an ISP or other larger institution might be doing - you set aside a dozen FreeBSD PC's for various tasks. Yes, I am crafty enough to figure out how I might do a system install. Or other maintenance (which IS possible at this point in time, with a fair amount of puttering, over a serial console - thanks Bill Paul, etc.!) but it needs to all be practical. And ideally this should include the install. ... JG From owner-freebsd-hackers Sun Dec 31 11:00:11 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id LAA16599 for hackers-outgoing; Sun, 31 Dec 1995 11:00:11 -0800 (PST) Received: from rah.star-gate.com (rah.star-gate.com [204.188.121.18]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id LAA16591 for ; Sun, 31 Dec 1995 11:00:06 -0800 (PST) Received: from localhost.v-site.net (localhost.v-site.net [127.0.0.1]) by rah.star-gate.com (8.6.12/8.6.12) with SMTP id KAA01734; Sun, 31 Dec 1995 10:59:47 -0800 Message-Id: <199512311859.KAA01734@rah.star-gate.com> X-Authentication-Warning: rah.star-gate.com: Host localhost.v-site.net didn't use HELO protocol X-Mailer: exmh version 1.6.2 7/18/95 To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) cc: freebsd-hackers@freebsd.org (FreeBSD hackers) Subject: Re: /dev/io In-reply-to: Your message of "Sun, 31 Dec 1995 09:41:41 +0100." <199512310841.JAA16189@uriah.heep.sax.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 31 Dec 1995 10:59:47 -0800 From: "Amancio Hasty Jr." Sender: owner-hackers@freebsd.org Precedence: bulk >>> J Wunsch said: Well the /dev/io hole can be plugged if you like by not including in your typical kernel configuration. We use it to do in/out to devices. Amancio From owner-freebsd-hackers Sun Dec 31 11:15:05 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id LAA16942 for hackers-outgoing; Sun, 31 Dec 1995 11:15:05 -0800 (PST) Received: from rah.star-gate.com (rah.star-gate.com [204.188.121.18]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id LAA16930 for ; Sun, 31 Dec 1995 11:15:00 -0800 (PST) Received: from localhost.v-site.net (localhost.v-site.net [127.0.0.1]) by rah.star-gate.com (8.6.12/8.6.12) with SMTP id LAA01996 for ; Sun, 31 Dec 1995 11:14:41 -0800 Message-Id: <199512311914.LAA01996@rah.star-gate.com> X-Authentication-Warning: rah.star-gate.com: Host localhost.v-site.net didn't use HELO protocol X-Mailer: exmh version 1.6.2 7/18/95 To: hackers@freebsd.org Subject: Re: /dev/io In-reply-to: Your message of "Sun, 31 Dec 1995 21:09:07 +1100." <199512311009.VAA17343@rf900.physics.usyd.edu.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 31 Dec 1995 11:14:40 -0800 From: "Amancio Hasty Jr." Sender: owner-hackers@freebsd.org Precedence: bulk Well, the X server itself has other security problems such as cutting and pasting to a secure document . Amancio From owner-freebsd-hackers Sun Dec 31 11:55:51 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id LAA18194 for hackers-outgoing; Sun, 31 Dec 1995 11:55:51 -0800 (PST) Received: from time.cdrom.com (time.cdrom.com [192.216.222.226]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id LAA18188 for ; Sun, 31 Dec 1995 11:55:46 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by time.cdrom.com (8.6.12/8.6.9) with SMTP id LAA02027; Sun, 31 Dec 1995 11:55:28 -0800 To: David Dawes cc: hackers@freebsd.org Subject: Re: /dev/io In-reply-to: Your message of "Sun, 31 Dec 1995 14:11:20 +1100." <199512310311.OAA16531@rf900.physics.usyd.edu.au> Date: Sun, 31 Dec 1995 11:55:28 -0800 Message-ID: <2025.820439728@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-hackers@freebsd.org Precedence: bulk > For what it's worth, the XFree86 servers get I/O permission by using > the KDENABIO ioctl in the console driver rather than by opening /dev/io. My mistake then. Didn't they use /dev/io at some point? I could have sworn I saw this used there once! Jordan From owner-freebsd-hackers Sun Dec 31 12:07:26 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id MAA18616 for hackers-outgoing; Sun, 31 Dec 1995 12:07:26 -0800 (PST) Received: from rah.star-gate.com (rah.star-gate.com [204.188.121.18]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id MAA18610 for ; Sun, 31 Dec 1995 12:07:24 -0800 (PST) Received: from localhost.v-site.net (localhost.v-site.net [127.0.0.1]) by rah.star-gate.com (8.6.12/8.6.12) with SMTP id MAA02561; Sun, 31 Dec 1995 12:06:53 -0800 Message-Id: <199512312006.MAA02561@rah.star-gate.com> X-Authentication-Warning: rah.star-gate.com: Host localhost.v-site.net didn't use HELO protocol X-Mailer: exmh version 1.6.2 7/18/95 To: "Jordan K. Hubbard" cc: David Dawes , hackers@freebsd.org Subject: Re: /dev/io In-reply-to: Your message of "Sun, 31 Dec 1995 11:55:28 PST." <2025.820439728@time.cdrom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 31 Dec 1995 12:06:52 -0800 From: "Amancio Hasty Jr." Sender: owner-hackers@freebsd.org Precedence: bulk >>> "Jordan K. Hubbard" said: > > For what it's worth, the XFree86 servers get I/O permission by using > > the KDENABIO ioctl in the console driver rather than by opening /dev/io. > > My mistake then. Didn't they use /dev/io at some point? I could have > sworn I saw this used there once! > Nope , not as far as I can remember . Amancio From owner-freebsd-hackers Sun Dec 31 12:15:34 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id MAA18877 for hackers-outgoing; Sun, 31 Dec 1995 12:15:34 -0800 (PST) Received: from public.wintek.com (public.wintek.com [199.233.104.88]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id MAA18872 for ; Sun, 31 Dec 1995 12:15:32 -0800 (PST) Received: from watson.grauel.com (watson.grauel.com [199.233.104.36]) by public.wintek.com (8.6.12/1.13wintek(3.6davy)) with ESMTP id PAA10874; Sun, 31 Dec 1995 15:15:30 -0500 Received: (from rjk@localhost) by watson.grauel.com (8.6.12/8.6.9) id PAA15103; Sun, 31 Dec 1995 15:26:43 -0500 Date: Sun, 31 Dec 1995 15:26:43 -0500 Message-Id: <199512312026.PAA15103@watson.grauel.com> From: Richard J Kuhns To: freebsd-hackers@freebsd.org Subject: An answer, a question, and an offer... Sender: owner-hackers@freebsd.org Precedence: bulk First, a problem and solution with the 2.0.5 ==> 2.1 upgrade: after you've done the upgrade, the GENERIC kernel won't compile due to problems with the matcd driver. This is due to the fact that the 2.0.5 driver #included the file `i386/isa/matcd/matcd.h', which is no longer used by the 2.1 driver but is still there since the upgrade process just writes over existing files; it seems that config causes it to be #included if it exists. Either move it out of the way or remove it, and re-run config. Now, a request. Is there any strong reason not to include terminfo support in libmytinfo.*? I'm working on an enhanced print (among other things) spooler based on MDQS (Multi Device Spooling System) that includes some of the capabilities of the SVR4 lp spooler, and the printer support (which I'd like to run under SVR4 as well) depends on terminfo support (to be able to change things like lines/inch and chars/inch for a given printer). I've found that it works perfectly under FreeBSD 2.0.5 && 2.1-RELEASE, as long as I change the #undef TERMINFO to #define TERMINFO in libmytinfo's config.h file and re-compile/-install and copy the appropriate terminfo files. Not that this is a major problem, but it's extra work to do with every system I install and I don't see any reason it couldn't be the default -- termcap support is still there and works just fine. It's very handy to be able to type something like "pr source.c | lp-emu -o cpi=12", and have it print in elite. If anyone else is interested in testing or criticizing it, drop me a note. It should be ready for some beta testing RSN... Finally, an offer. Being able to smoothly upgrade a system is fairly important to me and a couple of companies I do consulting for. Jordan, I have a machine available (486 DX2/66, 8M RAM, 512M SCSI) that I could install/upgrade as often as necessary, and I'd like to help, both in testing and possibly in coding (will I have to re-learn FORTH?). Let me know... -- Rich Kuhns rjk@grauel.com PO Box 6249 100 Sawmill Road Lafayette, IN 47903 (317)477-6000 x319 From owner-freebsd-hackers Sun Dec 31 12:22:20 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id MAA19102 for hackers-outgoing; Sun, 31 Dec 1995 12:22:20 -0800 (PST) Received: from mail.barrnet.net (mail.barrnet.net [131.119.246.7]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id MAA19097 for ; Sun, 31 Dec 1995 12:22:17 -0800 (PST) Received: from hq.icb.chel.su (icb-rich-gw.icb.chel.su [193.125.10.34]) by mail.barrnet.net (8.7.1/MAIL-RELAY-LEN) with SMTP id AAA04876 for ; Tue, 26 Dec 1995 00:46:11 -0800 (PST) Received: from localhost (babkin@localhost) by hq.icb.chel.su (8.6.5/8.6.5) id NAA25821; Tue, 26 Dec 1995 13:36:59 +0500 From: "Serge A. Babkin" Message-Id: <199512260836.NAA25821@hq.icb.chel.su> Subject: Re: Digiboard patch To: bde@zeta.org.au (Bruce Evans) Date: Tue, 26 Dec 1995 13:36:59 +0500 (GMT+0500) Cc: hackers@freebsd.org In-Reply-To: <199512221447.BAA14659@godzilla.zeta.org.au> from "Bruce Evans" at Dec 23, 95 01:47:02 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-hackers@freebsd.org Precedence: bulk > This was slightly better before. The comment no longer matches the code. > But to be correct, the state should be left at DC_UNCONFIGURED when the > device is first registered, then set to DC_BUSY when a subdevice is > attached (since you're not bothering to keep track of opens). > > Note that setting DC_* in kdc_dgb[0].kdc_state clobbers the template. > In general you have to worry about all the fields in the template being > changed as device 0 is attached, used and detached, so the template > shouldn't be in kdc_xxx[0]. This bug has been copied into about 100 > drivers :-(. This patch must fix these problems. Commit it please (if you think that it is worth). Thank you! ----------------------------------- cut here --------------------------- *** dgb.c 1995/12/22 11:09:12 --- dgb.c 1995/12/26 08:26:21 *************** *** 427,433 **** return 4; /* we need I/O space of 4 ports */ } ! static struct kern_devconf kdc_dgb[NDGB] = { { 0, 0, 0, /* filled in by dev_attach */ "dgb", 0, { MDDT_ISA, 0, "tty" }, isa_generic_externalize, 0, 0, ISA_EXTERNALLEN, --- 427,434 ---- return 4; /* we need I/O space of 4 ports */ } ! static struct kern_devconf kdc_dgb[NDGB]; ! static struct kern_devconf kdc_dgb_init = { 0, 0, 0, /* filled in by dev_attach */ "dgb", 0, { MDDT_ISA, 0, "tty" }, isa_generic_externalize, 0, 0, ISA_EXTERNALLEN, *************** *** 436,442 **** DC_UNCONFIGURED, "DigiBoard multiport card", DC_CLS_SERIAL, ! } }; static void dgbregisterdev(id) --- 437,443 ---- DC_UNCONFIGURED, "DigiBoard multiport card", DC_CLS_SERIAL, ! }; static void dgbregisterdev(id) *************** *** 445,457 **** int unit; unit = id->id_unit; ! if (unit != 0) ! kdc_dgb[unit] = kdc_dgb[0]; kdc_dgb[unit].kdc_unit = unit; kdc_dgb[unit].kdc_isa = id; ! /* now we assume that multiport is always 'open' for simplicity */ ! kdc_dgb[unit].kdc_state = DC_UNKNOWN; dev_attach(&kdc_dgb[unit]); } --- 446,457 ---- int unit; unit = id->id_unit; ! kdc_dgb[unit] = kdc_dgb_init; kdc_dgb[unit].kdc_unit = unit; kdc_dgb[unit].kdc_isa = id; ! /* no ports are open yet */ ! kdc_dgb[unit].kdc_state = DC_IDLE; dev_attach(&kdc_dgb[unit]); } *************** *** 1037,1042 **** --- 1037,1048 ---- port->active_out = TRUE; port->used=1; + + /* If any port is open (i.e. the open() call is completed for it) + * the device is busy + */ + + kdc_dgb[unit].kdc_state = DC_BUSY; out: splx(s); *************** *** 1063,1068 **** --- 1069,1075 ---- struct dgb_softc *sc; struct dgb_p *port; int s; + int i; mynor=minor(dev); unit=MINOR_TO_UNIT(mynor); *************** *** 1086,1091 **** --- 1093,1107 ---- ttyclose(tp); port->closing=0; wakeup(&port->closing); port->used=0; + + /* mark the card idle when all ports are closed */ + + for(i=0; inumports; i++) + if(sc->ports[i].used) + break; + + if(i>= sc->numports) + kdc_dgb[unit].kdc_state = DC_IDLE; splx(s); From owner-freebsd-hackers Sun Dec 31 14:28:05 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id OAA22524 for hackers-outgoing; Sun, 31 Dec 1995 14:28:05 -0800 (PST) Received: from cps201.cps.cmich.edu (cps201.cps.cmich.edu [141.209.20.201]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id OAA22498 for ; Sun, 31 Dec 1995 14:27:59 -0800 (PST) Received: from cps201 (cps201.cps.cmich.edu [141.209.20.201]) by cps201.cps.cmich.edu (8.6.12/8.6.12) with SMTP id RAA11406; Sun, 31 Dec 1995 17:27:45 -0500 Date: Sun, 31 Dec 1995 17:27:45 -0500 (EST) From: Mail Archive X-Sender: archive@cps201 To: "Jordan K. Hubbard" cc: Rashid Karimov , hackers@freebsd.org Subject: Re: ASUS P6/Pro MB and P6-200 In-Reply-To: <5961.820171984@time.cdrom.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org Precedence: bulk > > Our same problem too.. :-( When David received shipment of his "200Mhz > CPU" he found it was the 150Mhz part. Further checking revealed that > the 200Mhz part simply isn't available yet.. :-( > Intel told me friday (dec 29th) that our two demo CPU's won't be available until second week of Janurary. They expect shipping in quanity by the end of feb. Sorry guys but more hype than product at the moment. From owner-freebsd-hackers Sun Dec 31 14:36:30 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id OAA22849 for hackers-outgoing; Sun, 31 Dec 1995 14:36:30 -0800 (PST) Received: from cps201.cps.cmich.edu (cps201.cps.cmich.edu [141.209.20.201]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id OAA22842 Sun, 31 Dec 1995 14:36:22 -0800 (PST) Received: from cps201 (cps201.cps.cmich.edu [141.209.20.201]) by cps201.cps.cmich.edu (8.6.12/8.6.12) with SMTP id RAA11498; Sun, 31 Dec 1995 17:36:15 -0500 Date: Sun, 31 Dec 1995 17:36:14 -0500 (EST) From: Mail Archive X-Sender: archive@cps201 To: "Jonathan M. Bresler" cc: Terry Lambert , joerg_wunsch@uriah.heep.sax.de, daemon@bee.cs.kiev.ua, freebsd-hackers@FreeBSD.ORG Subject: Re: NFS In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@FreeBSD.ORG Precedence: bulk On Thu, 28 Dec 1995, Jonathan M. Bresler wrote: > my new employer is heavy into nis and nfs. i have 2.1.0R > installed there. i can give the nfs code a real pounding now. this can > start in january....late next week even. > > what do you all want hammered on??? > RPC.LOCKD :) thanks :) Matthew S. Bailey From owner-freebsd-hackers Sun Dec 31 15:30:36 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id PAA24535 for hackers-outgoing; Sun, 31 Dec 1995 15:30:36 -0800 (PST) Received: from strider.ibenet.it (root@Strider.Free.IT [194.179.131.1]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id PAA24520 Sun, 31 Dec 1995 15:30:29 -0800 (PST) Received: (from piero@localhost) by strider.ibenet.it (8.7.3/8.6.12) id AAA06908; Mon, 1 Jan 1996 00:29:57 +0100 (MET) From: Piero Serini Message-Id: <199512312329.AAA06908@strider.ibenet.it> Subject: HNY To: Questions@FreeBSD.ORG (FreeBSD Questions List), Hackers@FreeBSD.ORG (FreeBSD Hackers' List) Date: Mon, 1 Jan 1996 00:29:56 +0100 (MET) Reply-To: piero@strider.ibenet.it Operating-System: FreeBSD 1.1.5.1 X-Phone-Number: +39 (2) 58113562 X-NCC-RegID: it.ibenet X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-hackers@FreeBSD.ORG Precedence: bulk Hello. HAPPY NEW YEAR !!!!! Bye, -- # $Id: .signature,v 1.12 1995/08/14 12:10:54 piero Exp $ Piero Serini Via Giambologna, 1 I 20136 Milano - ITALY From owner-freebsd-hackers Sun Dec 31 15:37:30 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id PAA24981 for hackers-outgoing; Sun, 31 Dec 1995 15:37:30 -0800 (PST) Received: from rf900.physics.usyd.edu.au (rf900.physics.usyd.edu.au [129.78.129.109]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id PAA24964 for ; Sun, 31 Dec 1995 15:37:24 -0800 (PST) Received: (from dawes@localhost) by rf900.physics.usyd.edu.au (8.6.11/8.6.9) id KAA19404; Mon, 1 Jan 1996 10:37:10 +1100 From: David Dawes Message-Id: <199512312337.KAA19404@rf900.physics.usyd.edu.au> Subject: Re: /dev/io To: jkh@time.cdrom.com (Jordan K. Hubbard) Date: Mon, 1 Jan 1996 10:37:09 +1100 (EST) Cc: hackers@freebsd.org In-Reply-To: <2025.820439728@time.cdrom.com> from "Jordan K. Hubbard" at Dec 31, 95 11:55:28 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-hackers@freebsd.org Precedence: bulk >> For what it's worth, the XFree86 servers get I/O permission by using >> the KDENABIO ioctl in the console driver rather than by opening /dev/io. > >My mistake then. Didn't they use /dev/io at some point? I could have >sworn I saw this used there once! No. I'd thought about changing to use /dev/io, but it has never been used by the XFree86 servers. David From owner-freebsd-hackers Sun Dec 31 16:08:45 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id QAA27022 for hackers-outgoing; Sun, 31 Dec 1995 16:08:45 -0800 (PST) Received: from hub.org (hub.org [199.166.238.138]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id QAA27013 Sun, 31 Dec 1995 16:08:40 -0800 (PST) Received: (from scrappy@localhost) by hub.org (8.7.3/8.7.3) id TAA21865; Sun, 31 Dec 1995 19:07:42 -0500 (EST) Date: Sun, 31 Dec 1995 19:07:41 -0500 (EST) From: "Marc G. Fournier" X-Sender: scrappy@hub.org To: Mail Archive cc: "Jonathan M. Bresler" , Terry Lambert , joerg_wunsch@uriah.heep.sax.de, daemon@bee.cs.kiev.ua, freebsd-hackers@FreeBSD.org Subject: Re: NFS In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@FreeBSD.org Precedence: bulk On Sun, 31 Dec 1995, Mail Archive wrote: > On Thu, 28 Dec 1995, Jonathan M. Bresler wrote: > > my new employer is heavy into nis and nfs. i have 2.1.0R > > installed there. i can give the nfs code a real pounding now. this can > > start in january....late next week even. > > > > what do you all want hammered on??? > > > RPC.LOCKD :) > I'd say that rpc.quotad would be more of a priority as far as anyone that wants or is using FreeBSD in any ISP environment, more so then rpc.lockd... Marc G. Fournier | POP Mail Telnet Acct DNS Hosting System | WWW Services Database Services | Knowledge, Administrator | | Information and scrappy@ki.net | WWW: http://www.ki.net | Communications, Inc From owner-freebsd-hackers Sun Dec 31 18:51:19 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id SAA03772 for hackers-outgoing; Sun, 31 Dec 1995 18:51:19 -0800 (PST) Received: from Aspen.Woc.Atinc.COM ([198.138.38.205]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id SAA03766 for ; Sun, 31 Dec 1995 18:51:12 -0800 (PST) Received: (from jmb@localhost) by Aspen.Woc.Atinc.COM (8.6.12/8.6.9) id VAA22860; Sun, 31 Dec 1995 21:50:56 -0500 Date: Sun, 31 Dec 1995 21:50:55 -0500 (EST) From: "Jonathan M. Bresler" X-Sender: jmb@Aspen.Woc.Atinc.COM To: Mail Archive cc: Terry Lambert , joerg_wunsch@uriah.heep.sax.de, daemon@bee.cs.kiev.ua, freebsd-hackers@FreeBSD.ORG Subject: Re: NFS In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@FreeBSD.ORG Precedence: bulk On Sun, 31 Dec 1995, Mail Archive wrote: > On Thu, 28 Dec 1995, Jonathan M. Bresler wrote: > > my new employer is heavy into nis and nfs. i have 2.1.0R > > installed there. i can give the nfs code a real pounding now. this can > > start in january....late next week even. > > > > what do you all want hammered on??? > > > RPC.LOCKD :) > > thanks :) cool, i'll fire up amd on tuesday when i get back to work and do a make world with source coming from a nfs mounted drive. so where do i pick up your source for lockd ??? ;^) happy new year's Jonathan M. Bresler FreeBSD Postmaster jmb@FreeBSD.ORG play go. ride bike. hack FreeBSD.--ah the good life i am moving to a new job. PLEASE USE: jmb@FreeBSD.ORG From owner-freebsd-hackers Sun Dec 31 20:10:10 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id UAA06519 for hackers-outgoing; Sun, 31 Dec 1995 20:10:10 -0800 (PST) Received: from voland.phoebe.com (ix-sf11-06.ix.netcom.com [204.30.64.166]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id UAA06510 for ; Sun, 31 Dec 1995 20:10:04 -0800 (PST) Received: (from tulchins@localhost) by voland.phoebe.com (8.6.12/8.6.12) id UAA00261 for hackers@freebsd.org; Sun, 31 Dec 1995 20:11:35 GMT Date: Sun, 31 Dec 1995 20:11:35 GMT From: Steven Tulchinsky Message-Id: <199512312011.UAA00261@voland.phoebe.com> To: hackers@freebsd.org Subject: Doom and Linux emulation Sender: owner-hackers@freebsd.org Precedence: bulk I've been trying for days to get Doom to run but whatever I try to do resuls in Program received signal SIGBUS, Bus error. :-( I looked through mailing list archives and all docs I could find, but there is nothing to fix my problem Here is what I got: % modstat Type Id Off Loadaddr Size Info Rev Module Name EXEC 0 3 f11b6000 0018 f11bb000 1 linux_emulator % ls /usr/local/lib ./ libXaw.so.3@ libc.so.4.5.26@ ../ libXaw.so.3.1.0@ libgr.so.1@ doom/ libXaw.so.6@ libgr.so.1.3@ doom-1.8/ libXaw.so.6.0@ libm.so.4@ ld.so@ libXpm.so.4@ libm.so.4.5.26@ libX11.so.3@ libXpm.so.4.3@ libvga.config libX11.so.3.1.0@ libXt.so.3@ libvga.so.1@ libX11.so.6@ libXt.so.3.1.0@ libvga.so.1.2.0* libX11.so.6.0@ libXt.so.6@ linux_lib/ libXIE.so.6@ libXt.so.6.0@ libXIE.so.6.0@ libc.so.4@ And yes, I compiled kernel with both options LINUX_COMPAT options SYSVSHM What else do I need. Please reply to tulchins@ix.netcom.com Any help is greatly appreciated Steven Tulchinsky From owner-freebsd-hackers Sun Dec 31 20:16:02 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id UAA06693 for hackers-outgoing; Sun, 31 Dec 1995 20:16:02 -0800 (PST) Received: from eztravel.com (eztravel.com [205.179.24.1]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id UAA06663 Sun, 31 Dec 1995 20:15:50 -0800 (PST) Received: (from ez@localhost) by eztravel.com (8.6.11/8.6.9) id MAA00282; Sun, 31 Dec 1995 12:14:37 -0800 From: EZ Travel Message-Id: <199512312014.MAA00282@eztravel.com> Subject: FreeBSD, Zappa & PCI To: hackers@freebsd.org Date: Sun, 31 Dec 1995 12:14:36 -0800 (PST) Cc: questions@freebsd.org, ez@eztravel.com (EZ Travel) X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org Precedence: bulk Regarding the previously posted memory problem: Memory problem was something wierd on the Motherboard that didn't allow me to go beyond 8MB RAM? The count on the screen showed 16MB, setup showed 16MB, yet mem in DOS show only 8MB as well as FreeBSD. Really strange??? So, I bought a Zappa M/B switch everything over (CPU & cards) turned it on - all 16 MB RAM is showing in FreeBSD. One thing different showing up during boot-up is the following: ********** what's showing up now with the zappa board *************** Dec 31 10:59:28 eztravel /kernel: Probing for devices on the pci0 bus: Dec 31 10:59:28 eztravel /kernel: configuration mode 1 allows 32 devices. Dec 31 10:59:29 eztravel /kernel: pci0:0: INTEL CORPORATION, device=0x122d, class=bridge [not supported] Dec 31 10:59:29 eztravel /kernel: pci0:7: INTEL CORPORATION, device=0x122e, class=bridge [not supported] **************** what show'd up with the neptune motherboard *********** Dec 30 21:43:20 eztravel /kernel: Probing for devices on the pci0 bus: Dec 30 21:43:20 eztravel /kernel: configuration mode 2 allows 16 devices. Dec 30 21:43:21 eztravel /kernel: chip0 rev 17 on pci0:0 Dec 30 21:43:21 eztravel /kernel: chip1 rev 3 on pci0:2 Is this a serious problem? What does the class=bridge[not supported] mean? Is this something I can change in setup? I can bring the motherboard back next week (tues/weds) if this is going to create major problems down the road and live with the 8mb ram on the neptune m/b. X runs a lot faster with the Zappa and 16mb... Bob From owner-freebsd-hackers Sun Dec 31 20:43:04 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id UAA07571 for hackers-outgoing; Sun, 31 Dec 1995 20:43:04 -0800 (PST) Received: from fw.ast.com (fw.ast.com [165.164.6.25]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id UAA07566 for ; Sun, 31 Dec 1995 20:43:01 -0800 (PST) Received: from nemesis by fw.ast.com with uucp (Smail3.1.29.1 #2) id m0tWbvd-0000zcC; Sun, 31 Dec 95 22:32 CST Received: by nemesis.lonestar.org (Smail3.1.27.1 #20) id m0tWbmN-000BzGC; Sun, 31 Dec 95 22:23 WET Message-Id: Date: Sun, 31 Dec 95 22:23 WET To: rjk@watson.grauel.com, freebsd-hackers@freebsd.org From: uhclem@nemesis.lonestar.org (Frank Durda IV) Sent: Sun Dec 31 1995, 22:23:23 CST Subject: An answer, a question, and an offer... Cc: uhclem@nemesis.lonestar.org Sender: owner-hackers@freebsd.org Precedence: bulk [0]First, a problem and solution with the 2.0.5 ==> 2.1 upgrade: after you've [0]done the upgrade, the GENERIC kernel won't compile due to problems with the [0]matcd driver. This is due to the fact that the 2.0.5 driver #included the [0]file `i386/isa/matcd/matcd.h', which is no longer used by the 2.1 driver [0]but is still there since the upgrade process just writes over existing [0]files; it seems that config causes it to be #included if it exists. Either [0]move it out of the way or remove it, and re-run config. This is a known problem, and it has been discussed before in -current and in the USENET freebsd groups. The solution is to delete /usr/src/sys/i386/isa/matcd/matcd.h, do a make depend and then a make. It was discovered at a date where I guess there wasn't time to have the install get rid of old files in the source tree before extracting the new tree. Doing something like this is a religious area anyway. There are other files around the entire 2.0.5 (and 2.0.0 and 1.1.5.1) system that will also be hanging around if you have upgraded over each of these instead of doing a fresh extract of the source tree, but as far as I know, the matcd.h is the only one that causes the build to fail for the 2.0.5 -> 2.1.0 jump. The rest of the "dead" files just waste space and make things messy. Frank Durda IV |"Mr. Bill, you claimed that you | would sell eighty-eight million ...letni!rwsys!nemesis!uhclem | billion copies of Windows '95 | in the first four months alone. Aren't you disappointed?" :-) From owner-freebsd-hackers Sun Dec 31 21:27:24 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id VAA08693 for hackers-outgoing; Sun, 31 Dec 1995 21:27:24 -0800 (PST) Received: from cps201.cps.cmich.edu (cps201.cps.cmich.edu [141.209.20.201]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id VAA08688 Sun, 31 Dec 1995 21:27:21 -0800 (PST) Received: from cps201 (cps201.cps.cmich.edu [141.209.20.201]) by cps201.cps.cmich.edu (8.6.12/8.6.12) with SMTP id AAA16375; Mon, 1 Jan 1996 00:27:07 -0500 Date: Mon, 1 Jan 1996 00:27:07 -0500 (EST) From: Mail Archive X-Sender: archive@cps201 To: "Marc G. Fournier" cc: "Jonathan M. Bresler" , Terry Lambert , joerg_wunsch@uriah.heep.sax.de, daemon@bee.cs.kiev.ua, freebsd-hackers@FreeBSD.org Subject: Re: NFS In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@FreeBSD.org Precedence: bulk > > > I'd say that rpc.quotad would be more of a priority as far > as anyone that wants or is using FreeBSD in any ISP environment, > more so then rpc.lockd... Uhmmm not when your working with mail spools on FreeBSD and you have SunOS as a user account server. lockd is vital if nothing more than to get rid of the annoying messages. RPC.RQUOTAD can be taken from a couple other unicies if need be. (Linux/NetBSD) where RPC.LOCKD doesn't even exist anywhere. :) just my 2cents From owner-freebsd-hackers Sun Dec 31 21:30:18 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id VAA08811 for hackers-outgoing; Sun, 31 Dec 1995 21:30:18 -0800 (PST) Received: from cps201.cps.cmich.edu (cps201.cps.cmich.edu [141.209.20.201]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id VAA08806 Sun, 31 Dec 1995 21:30:14 -0800 (PST) Received: from cps201 (cps201.cps.cmich.edu [141.209.20.201]) by cps201.cps.cmich.edu (8.6.12/8.6.12) with SMTP id AAA16434; Mon, 1 Jan 1996 00:30:13 -0500 Date: Mon, 1 Jan 1996 00:30:13 -0500 (EST) From: Mail Archive X-Sender: archive@cps201 To: "Jonathan M. Bresler" cc: Terry Lambert , joerg_wunsch@uriah.heep.sax.de, daemon@bee.cs.kiev.ua, freebsd-hackers@FreeBSD.ORG Subject: Re: NFS In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@FreeBSD.ORG Precedence: bulk On Sun, 31 Dec 1995, Jonathan M. Bresler wrote: > > RPC.LOCKD :) > > > > thanks :) > > cool, i'll fire up amd on tuesday when i get back to work and do > a make world with source coming from a nfs mounted drive. so where do i > pick up your source for lockd ??? ;^) > I think I miss interpreted what you were asking. I thought you wanted to know where pieces were needed to be programmed. Not just used. Sorry about that. I can not program lockd anyway I have looked through the SunOS source on rpc.lockd and rpc.statd. So therefore I am tainted. :) (maybe in more ways than one :) Matt From owner-freebsd-hackers Sun Dec 31 23:09:45 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id XAA10717 for hackers-outgoing; Sun, 31 Dec 1995 23:09:45 -0800 (PST) Received: from relay.hp.com (relay.hp.com [15.255.152.2]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id XAA10712 for ; Sun, 31 Dec 1995 23:09:42 -0800 (PST) Received: from fakir.india.hp.com by relay.hp.com with ESMTP (1.37.109.16/15.5+ECS 3.3) id AA071640174; Sun, 31 Dec 1995 23:09:38 -0800 Received: from localhost by fakir.india.hp.com with SMTP (1.37.109.16/15.5+ECS 3.3) id AA013100019; Mon, 1 Jan 1996 12:37:00 +0530 Message-Id: <199601010707.AA013100019@fakir.india.hp.com> To: hackers@freebsd.org Subject: IOPerms (was Re: /dev/io) Date: Mon, 01 Jan 1996 12:36:59 +0530 From: A JOSEPH KOSHY Sender: owner-hackers@freebsd.org Precedence: bulk Whilst on the discussion on the use of /dev/io ... Things that can be said for the use of I/O permission bitmaps: a. You can control the useage of i/o ports by processes. This is useful in trapping programming errors leading to inadvertant accesses to critical ports etc. It also helps keep your confidence in your system high :). b. Its my guess that using the I/O permission bitmaps would help in implementing VM86 mode, specially when manipulating multiple VM86 tasks all attempting to access the hardware. Koshy From owner-freebsd-hackers Sun Dec 31 23:10:09 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id XAA10765 for hackers-outgoing; Sun, 31 Dec 1995 23:10:09 -0800 (PST) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id XAA10731 for ; Sun, 31 Dec 1995 23:09:58 -0800 (PST) Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id SAA25177; Mon, 1 Jan 1996 18:04:29 +1100 Date: Mon, 1 Jan 1996 18:04:29 +1100 From: Bruce Evans Message-Id: <199601010704.SAA25177@godzilla.zeta.org.au> To: lyndon@orthanc.com, pw@snoopy.mv.com Subject: Re: libraries Cc: hackers@FreeBSD.org Sender: owner-hackers@FreeBSD.org Precedence: bulk >>>>>> "lyndon" == VE7TCP writes: >>>>>> "John" == John Beukema writes: > John> This error is a commonn problem. Comment it out in httcp.c > John> or add #ifndef __FreeBSD__ #endif (from memory) around the > John> declaration. One is defined as char * and the other as > John> const char * as I remember. jbeukema > lyndon> The correct fix for sys_errlist declarations is: > lyndon> #include #if (!defined(BSD) || (BSD < > lyndon> 199306) /* define sys_errlist as appropriate for your > lyndon> system */ #endif >So, is present on all systems that have a C compiler >or just systems with compilers that define the 'unix' macro, or just >BSD derived systems? Of course not. >Does one need >#if defined __FreeBSD__ || defined __listOfOthersKnownToHaveParam_ .. >#include >/* tests for various flavors of BSD go here */ >#endif This is impractical. The list would have to have a few thousand systems in it, and you wouldn't work on thise systems that don't identify themselves. >Offhand, it looks like the OS dependent feature is hidden in an OS >dependent file. It seems to me that the compiler ought to emit the >root feature list in some standard way so that codes can have some >predictable behaviour. This is impractical. The feature list would have to have a few thousand flags in it, and wouldn't work on those systems that don't support it. The correct method to handle this is to generate the feature lists on the fly like gnu autoconf does. However, this is too much trouble for a port. Just use `#if 0', perhaps with a comment, or #ifdef this_is_unportable_and_I_am_too_lazy_to_make_it_portable or the original #ifndef __FreeBSD__ The latter has the advantage that it is usually spelled consistently so you can find it easily. Bruce