From owner-freebsd-hackers Sun Dec 15 00:36:50 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id AAA04202 for hackers-outgoing; Sun, 15 Dec 1996 00:36:50 -0800 (PST) Received: from root.com (implode.root.com [198.145.90.17]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id AAA04195 for ; Sun, 15 Dec 1996 00:36:47 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by root.com (8.7.6/8.6.5) with SMTP id AAA04463; Sun, 15 Dec 1996 00:36:05 -0800 (PST) Message-Id: <199612150836.AAA04463@root.com> X-Authentication-Warning: implode.root.com: Host localhost [127.0.0.1] didn't use HELO protocol To: Tony Overfield cc: Eivind Eklund , hackers@freebsd.org Subject: Re: MAXMEM was: Re: 2.1.6 on Compaq Prosignia 500 (2.1.5 worked) In-reply-to: Your message of "Sun, 15 Dec 1996 01:57:11 EST." <3.0.1.32.19961215015705.0067a82c@bugs.us.dell.com> From: David Greenman Reply-To: dg@root.com Date: Sun, 15 Dec 1996 00:36:05 -0800 Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >A few various queries using AltaVista turned up this link: >http://www.uruk.org/grub/mem64mb.html which documents the calls. >Perhaps not coincidentally, the link at: >http://www.uruk.org/grub/ describes a fancy boot loader. There are plans to switch to this eventually, BTW. -DG David Greenman Core-team/Principal Architect, The FreeBSD Project From owner-freebsd-hackers Sun Dec 15 01:17:44 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id BAA07130 for hackers-outgoing; Sun, 15 Dec 1996 01:17:44 -0800 (PST) Received: from labinfo.iet.unipi.it (labinfo.iet.unipi.it [131.114.9.5]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id BAA07125 for ; Sun, 15 Dec 1996 01:17:41 -0800 (PST) Received: from localhost (luigi@localhost) by labinfo.iet.unipi.it (8.6.5/8.6.5) id JAA07695; Sun, 15 Dec 1996 09:42:23 +0100 From: Luigi Rizzo Message-Id: <199612150842.JAA07695@labinfo.iet.unipi.it> Subject: A question on diskless boot To: phk@critter.tfs.com (Poul-Henning Kamp) Date: Sun, 15 Dec 1996 09:42:23 +0100 (MET) Cc: hackers@freebsd.org X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi, sorry to bother you but I posted a similar question to the mailing lists and got no answer. One of our labs has a number of machines with a network card (21140 based, if_de driver) which is unsupported by netboot. I am looking for some alternative ways to setup these machines as diskless, i.e mounting root at the very least from a remote server. It seems that other bootloader (e.g. floppy or dosboot) at the moment do not support such a behaviour. The problem, I think, is that the kernel expect the nfsdiskless structure being filled up with server parameters (collected with bootp/tftp) instead of collecting them itself using bootp, the way netboot does. Obviously you cannot get them before the network card is up and running (well you could hardwire them in the loader but that's not a reasonable option). I am willing to work on it, and would just like a bit of advice. Would it be a wise thing to try to merge into the kernel part of the code which is currently in netboot (main.c I believe) which fills up the nfsdiskless structure, so that diskless boot only requires to pass an interface name to the kernel ? That way we could probably boot diskless even with biosboot/dosboot, and this does not look like much work. Thanks Luigi -----------------------------+-------------------------------------- Luigi Rizzo | Dip. di Ingegneria dell'Informazione email: luigi@iet.unipi.it | Universita' di Pisa tel: +39-50-568533 | via Diotisalvi 2, 56126 PISA (Italy) fax: +39-50-568522 | http://www.iet.unipi.it/~luigi/ _____________________________|______________________________________ From owner-freebsd-hackers Sun Dec 15 01:39:46 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id BAA09057 for hackers-outgoing; Sun, 15 Dec 1996 01:39:46 -0800 (PST) Received: from tfs.com (tfs.com [140.145.250.1]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id BAA09049 for ; Sun, 15 Dec 1996 01:39:45 -0800 (PST) Received: from critter.tfs.com by tfs.com (smail3.1.28.1) with SMTP id m0vZD2N-0003vlC; Sun, 15 Dec 96 01:39 PST Received: from critter.tfs.com (localhost.phk.dk [127.0.0.1]) by critter.tfs.com (8.8.2/8.8.2) with ESMTP id KAA09209; Sun, 15 Dec 1996 10:42:30 +0100 (MET) To: Luigi Rizzo cc: hackers@freebsd.org Subject: Re: A question on diskless boot In-reply-to: Your message of "Sun, 15 Dec 1996 09:42:23 +0100." <199612150842.JAA07695@labinfo.iet.unipi.it> Date: Sun, 15 Dec 1996 10:42:29 +0100 Message-ID: <9207.850642949@critter.tfs.com> From: Poul-Henning Kamp Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In message <199612150842.JAA07695@labinfo.iet.unipi.it>, Luigi Rizzo writes: >Hi, > >sorry to bother you but I posted a similar question to the mailing >lists and got no answer. > >One of our labs has a number of machines with a network card (21140 >based, if_de driver) which is unsupported by netboot. I am looking for >some alternative ways to setup these machines as diskless, i.e mounting >root at the very least from a remote server. There is some preliminary support for PCI devices, but probably only for NE2000 kind of stuff in the netboot code. I've never heard from anybody if it even works. >I am willing to work on it, and would just like a bit of advice. Let me tell you what I would do: Make a kernel with a builtin MFS filesystem, just like the one on boot.flp. Boot this kernel from wherever you want (floppy ?) Add generic code to the ethernet support in the kernel so that one can say ifconfig -bootp de0 > /etc/bootp.reply or possibly: bootp de0 > /etc/bootp.de0 where /etc/bootp.de0 would contain something like: ip=192.168.2.44 sm=255.255.255.0 ... so you could use it in the rest of the setup too. Adding the bootp code shouldn't be too hard I think I've just never gotten around to do it. Alternatively, you can hardcode the IP# on each floppy, but that seems like more work for me actually... Finally, you may want to try to see if you can get any kind of boot-proms for the de0 cards, and use whatever method they use to get live. -- 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-hackers Sun Dec 15 01:52:26 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id BAA11784 for hackers-outgoing; Sun, 15 Dec 1996 01:52:26 -0800 (PST) Received: from irz401.inf.tu-dresden.de (irz401.inf.tu-dresden.de [141.76.1.12]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id BAA11766 for ; Sun, 15 Dec 1996 01:52:21 -0800 (PST) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by irz401.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id KAA29337; Sun, 15 Dec 1996 10:51:44 +0100 Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id KAA19404; Sun, 15 Dec 1996 10:51:44 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.8.2/8.6.9) id KAA10237; Sun, 15 Dec 1996 10:49:13 +0100 (MET) From: J Wunsch Message-Id: <199612150949.KAA10237@uriah.heep.sax.de> Subject: Re: MAXMEM was: Re: 2.1.6 on Compaq Prosignia 500 (2.1.5 worked) To: freebsd-hackers@freebsd.org (FreeBSD hackers) Date: Sun, 15 Dec 1996 10:49:13 +0100 (MET) Cc: tony@dell.com (Tony Overfield) Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <3.0.1.32.19961214202436.0067ea7c@bugs.us.dell.com> from Tony Overfield at "Dec 14, 96 08:24:46 pm" 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 X-Mailer: ELM [version 2.4ME+ PL17 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk As Tony Overfield wrote: > There are standardized BIOS calls to obtain the correct amount of > memory, even when it exceeds 65 MB. I think the boot loader should > make these BIOS calls and pass the correct information to the kernel. What BIOS calls? My old notebook is probably the oldest machine that somebody would be willing and able to run FreeBSD on (386/16, 5 MB RAM, approx. 1990/91), so i could test its BIOS for the existance of that call. -- 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 15 03:16:08 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id DAA19622 for hackers-outgoing; Sun, 15 Dec 1996 03:16:08 -0800 (PST) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id DAA19617 for ; Sun, 15 Dec 1996 03:16:04 -0800 (PST) Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.3/8.6.9) id WAA01612; Sun, 15 Dec 1996 22:13:53 +1100 Date: Sun, 15 Dec 1996 22:13:53 +1100 From: Bruce Evans Message-Id: <199612151113.WAA01612@godzilla.zeta.org.au> To: freebsd-hackers@FreeBSD.org, j@uriah.heep.sax.de Subject: Re: MAXMEM was: Re: 2.1.6 on Compaq Prosignia 500 (2.1.5 worked) Cc: tony@dell.com Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk >What BIOS calls? My old notebook is probably the oldest machine that >somebody would be willing and able to run FreeBSD on (386/16, 5 MB >RAM, approx. 1990/91), so i could test its BIOS for the existance of >that call. You don't have >= 64MB extended memory, so the existence of the calls doesn't matter. What matters is that they fail correctly if they are not supported. The Interrupt List version 46 (June 1995) gives the at least the following calls: --- INT 15h/AH=88h The standard call, used in our boot blocks. Limited to 64MB. Said to be unreliable because some BIOSes don't set the carry flag if they don't support it. INT 15h/AX=DA88h. Works on AMI PCI BIOS. Returns size in K in CL:BX. INT 15h/AX=E801h. Works on some Compaqs and Dells. Details not all known. Limited to 64M. INT 15h/AX=E802h. Works on some Compaqs. Details not known. INT 15h/AX=E802h. Works on some Dells. More details given than for Compaq, but not enough to actually use it. It can apparently report any number of discontiguous regions. --- There is probably a standard way now, but it may not work on the old Compaqs and Dells. Some have a stupid 15 or 16MB limit, so they hit the limit a couple of years before other systems. Bruce From owner-freebsd-hackers Sun Dec 15 03:18:10 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id DAA19738 for hackers-outgoing; Sun, 15 Dec 1996 03:18:10 -0800 (PST) Received: from jau.thunderbolt.fi (jukkonen.dial.tele.fi [194.89.253.78]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id DAA19685; Sun, 15 Dec 1996 03:17:59 -0800 (PST) Received: (from jau@localhost) by jau.thunderbolt.fi (8.7.5/8.6.12+CSC-2.1) id NAA24559; Sun, 15 Dec 1996 13:17:49 +0200 (EET) Message-Id: <199612151117.NAA24559@jau.thunderbolt.fi> Subject: funny unstable behaviour in the stdio library... To: hackers@freebsd.org, questions@freebsd.org Date: Sun, 15 Dec 1996 13:17:48 +0200 (EET) Reply-To: jau@iki.fi From: jau@iki.fi (Jukka Ukkonen) Latin-Date: Duminice XV Decembrie a.d. MCMXCVI Organization: Private person Phone: +358-9-6215280 (home) Reply-To: jau@iki.fi (Jukka Ukkonen) Content-Conversion: prohibited X-Mailer: ELM [version 2.4 PL25+pgp] MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi everybody! Has anyone noticed the following unexpected behaviour in the stdio library? When one reads the input using fgetc() and echoes the read character immediately using fputc() there is no problem. If one instead reads the input input using fgetc(stdin) and tries to output something using fprintf(stdout, ...) (or printf) there appears some weird extra garbage on the out (usually an 'a' in my case) just as if the printf machinery left some trash in the input for the fgetc (stdin) to find. If I fseek() the stdin even without trying any real movement within the stream as in fseek (stdin, 0, SEEK_CUR); before calling fgetc(stdin) the next time everything seems to be almost alright. But even then it only works correctly for one character at the time input, because fseek (stdin, ...) flushes the input stream after the one character that was just read and processed. You could try the following short piece of code to reproduce the problem. ------------------------------ clip clip ------------------------------ /* * stdio-echo-test */ #include #undef fputc int main (ac, av) int ac; char **av; { register char ch; for (ch = fgetc (stdin); ! feof (stdin); ch = fgetc (stdin)) { fprintf (stdout, "ch = %x %c\n", ch, ch); #ifdef SEEK_STDIN fseek (stdin, 0, SEEK_CUR); #endif } return (0); } ------------------------------ clip clip ------------------------------ When everything works as expected one would expect it produce something like this... input: XYZ output: ch = 58 X output: ch = 59 Y output: ch = 5a Z What I get without the additional call to fseek() is... input: XYZ output: ch = 58 X output: ch = 59 Y output: ch = 5a Z output: ch = a I have no idea whether this oddity is present already in the original BSD version of stdio library or has someone tried to fix or enhance something and broken the original on the way. I assume though that this is probably a problem in the original code because also Linux and DEC's OSF/1 both seem to behave exactly the same way. Anyhow one does not (And should not have to!!) expect the stdin change when calling one of the printf functions on the stdout stream, if the input stream does not change also when using the fputc() family of functions. The same weird behaviour seems to be present at least on FreeBSD versions from 2.1.0-RELEASE to 2.2-960501-SNAP. Does anyone have good ideas about why is this as it is, and what could be done about it if anything? Cheers, // jau ------ / Jukka A. Ukkonen, Telemedia / Finnish Telecom Ltd. /__ M.Sc. (sw-eng & cs) (Phone) +358-2040-4025 / Internet: Jukka.Ukkonen@tele.fi (Fax) +358-2040-2712 / Internet: jau@iki.fi (Mobile) +358-400-606671 v Internet: ukkonen@nic.funet.fi (Home&Fax) +358-9-6215280 From owner-freebsd-hackers Sun Dec 15 04:43:19 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id EAA23840 for hackers-outgoing; Sun, 15 Dec 1996 04:43:19 -0800 (PST) Received: from murkwood.gaffaneys.com (dialup14.gaffaneys.com [134.129.252.33]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id EAA23831; Sun, 15 Dec 1996 04:43:15 -0800 (PST) Received: (from zach@localhost) by murkwood.gaffaneys.com (8.8.2/8.7.3) id GAA04600; Sun, 15 Dec 1996 06:44:07 -0600 (CST) To: jau@iki.fi Cc: hackers@freebsd.org, questions@freebsd.org Subject: Re: funny unstable behaviour in the stdio library... References: <199612151117.NAA24559@jau.thunderbolt.fi> Mime-Version: 1.0 (generated by tm-edit 7.89) Content-Type: text/plain; charset=US-ASCII From: Zach Heilig Date: 15 Dec 1996 06:44:06 -0600 In-Reply-To: jau@iki.fi's message of Sun, 15 Dec 1996 13:17:48 +0200 (EET) Message-ID: <87n2vg3rl5.fsf@murkwood.gaffaneys.com> Lines: 59 X-Mailer: Gnus v5.3/Emacs 19.34 Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk jau@iki.fi (Jukka Ukkonen) writes: ... > register char ch; ^^^^ you should really read into 'int's so when the various input functions return EOF, that value is distinguishable from all valid (unsigned) character values. If you _always_ use feof() correctly, this might not be an issue... > for (ch = fgetc (stdin); ! feof (stdin); ch = fgetc (stdin)) { ... > fseek (stdin, 0, SEEK_CUR); ^^^^^ fseek() on stdin is almost always a mistake. ... > When everything works as expected one would expect it produce > something like this... > input: XYZ > output: ch = 58 X > output: ch = 59 Y > output: ch = 5a Z Why this? You presumably have to type some character to send the line to the program for processing... Where is that character in the above output? > What I get without the additional call to fseek() is... fseek() on stdin when stdin is attached to a tty has no meaning. I only got the single line: ch = 58 X with the fseek() compiled in. (FreeBSD 2.2-ALPHA) > input: XYZ meaning you most likely typed: XYZ > output: ch = 58 X > output: ch = 59 Y > output: ch = 5a Z > output: ch = a Ahah! you did type a linefeed to send the line to your program. Of course your program will also read the linefeed and print it out. You did notice the extra blank line after the 'ch = a' line, right? :-) > Anyhow one does not (And should not have to!!) expect the stdin > change when calling one of the printf functions on the stdout > stream, if the input stream does not change also when using > the fputc() family of functions. The same weird behaviour seems > to be present at least on FreeBSD versions from 2.1.0-RELEASE > to 2.2-960501-SNAP. Does anyone have good ideas about why is > this as it is, and what could be done about it if anything? This is a pilot error, not a compiler (or library) bug. From owner-freebsd-hackers Sun Dec 15 05:04:13 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id FAA24622 for hackers-outgoing; Sun, 15 Dec 1996 05:04:13 -0800 (PST) Received: from haywire.DIALix.COM (news@haywire.DIALix.COM [192.203.228.65]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id FAA24594 for ; Sun, 15 Dec 1996 05:04:02 -0800 (PST) Received: (from news@localhost) by haywire.DIALix.COM (8.8.3/8.8.2) id VAA04382 for freebsd-hackers@freebsd.org; Sun, 15 Dec 1996 21:03:49 +0800 (WST) X-Authentication-Warning: haywire.DIALix.COM: news set sender to usenet-request@haywire.dialix.com using -f Received: from GATEWAY by haywire.DIALix.COM with netnews for freebsd-hackers@freebsd.org (problems to: usenet@haywire.dialix.com) To: freebsd-hackers@freebsd.org Date: 15 Dec 1996 13:03:47 GMT From: peter@spinner.DIALix.COM (Peter Wemm) Message-ID: <590svj$3dp$1@haywire.DIALix.COM> Organization: DIALix Services, Perth, Australia. References: <199612092304.PAA11079@lestat.nas.nasa.gov> Subject: Re: poll(2) Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In article <199612092304.PAA11079@lestat.nas.nasa.gov>, thorpej@nas.nasa.gov (Jason Thorpe) writes: > > If someone decides to add poll, note: the tiemout is only good to 1ms > > theoretical (argument resolution) or 10ms actual (system clock update > > frequency), so it isn't suitable for doing a lot of things that select() > > *is* suitable for doing... > > I'd like to see a upoll(2), as well... an extension, that gives the > funtionality of poll, but takes a more reasonable timeout (like, > probably a struct timespec). I did some code to do this about 6 months ago, it's still in my checked out -current kernel and still works. I had seen OpenBSD's code (a lot) so it's not purely independent, but it is quite different in certain areas. While I was there, I got carried away and implemented the feature described in the "BUGS" section right at the end of the select(2) man page. -Peter From owner-freebsd-hackers Sun Dec 15 05:21:18 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id FAA25242 for hackers-outgoing; Sun, 15 Dec 1996 05:21:18 -0800 (PST) Received: from isbalham.ist.co.uk (isbalham.ist.co.uk [192.31.26.1]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id FAA25152; Sun, 15 Dec 1996 05:19:51 -0800 (PST) Received: from gid.co.uk (uucp@localhost) by isbalham.ist.co.uk (8.8.4/8.8.4) with UUCP id NAA02088; Sun, 15 Dec 1996 13:03:59 GMT Date: Sun, 15 Dec 1996 12:53:42 GMT Received: from [194.32.164.2] by seagoon.gid.co.uk; Sun, 15 Dec 1996 12:53:42 GMT X-Sender: rb@194.32.164.1 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: Terry Lambert , proff@iq.org (Julian Assange) From: rb@gid.co.uk (Bob Bishop) Subject: Re: vulnerability in new pw suite Cc: security@freebsd.org, hackers@freebsd.org Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk At 2:23 pm 14/12/96, Terry Lambert wrote: >I've noticed a similar restriction on the search space is caused by >enforcing password length and use of particular values (digits, >control characters, and capitalization) > >Once we add in "non-pronouncible" and "not in dictionary" and so on, >I think that eventually, in the interests of "security", users will >be forced to choose from a list of 10 or so "sufficiently safe" >passwords. > >Of course, once that happens, we'll just publish the list... any >restriction on "allowed values" is an implicit restriction of the >search space a cracker is required to search, and makes cracking >just that much easier. Apologies if my irony detector is malfunctioning, but I can't let this one go :-) There are something over 10^14 usable 8 character passwords. Of these, maybe 10^5 are in dictionaries, and maybe another 100 'guessables' per user could be found easily by trawling the user's home directory and points south. Throw in a few more (SO's name, phone number and the like) and maybe you can get up to c. 2 x 10^5 passwords per user that are unsafe. That still leaves comfortably over 10^14 comparatively safe 8 character passwords. So there isn't actually a problem, it's just that those pesky users will insist on picking passwords from the unsafe set. They use lame excuses like "I cant remember %bSx48&J". Insisting on one non-alphanumeric character reduces the total search space right enough, to between 10^13 and 10^14, but it almost certainly forces the password out of the much smaller unsafe set. You can introduce a few such restrictions before the total search space falls below 10^12 which is probably good enough. At least, it's *much* better than 10^5. -- 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-hackers Sun Dec 15 05:54:14 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id FAA26306 for hackers-outgoing; Sun, 15 Dec 1996 05:54:14 -0800 (PST) Received: from whizzo.transsys.com (whizzo.TransSys.COM [144.202.42.10]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id FAA26301 for ; Sun, 15 Dec 1996 05:54:10 -0800 (PST) Received: from localhost.transsys.com (localhost.transsys.com [127.0.0.1]) by whizzo.transsys.com (8.8.3/8.7.3) with SMTP id IAA11420; Sun, 15 Dec 1996 08:54:05 -0500 (EST) Message-Id: <199612151354.IAA11420@whizzo.transsys.com> X-Mailer: exmh version 2.0alpha 12/3/96 To: Amancio Hasty cc: hackers@freebsd.org From: "Louis A. Mamakos" Subject: Re: PCI 2.1 Byte Enables? References: <199612150720.XAA00409@rah.star-gate.com> In-reply-to: Your message of "Sat, 14 Dec 1996 23:20:08 PST." <199612150720.XAA00409@rah.star-gate.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 15 Dec 1996 08:54:05 -0500 Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk The 4 bit PCI byte enables probably maps to the C/BE#[3:0] "Command or Byte Enable bus", which is used to define the type of transaction and which which PCI data paths are used. C/BE3# - Data path 3, AD[31:24], and the fourth location in the currently addressed doubleword. C/BE2# - Data path 2, AD[23:16], and the third location in the currently addressed doubleword. C/BE3# - Data path 1, AD[15:8], and the second location in the currently addressed doubleword. C/BE3# - Data path 0, AD[7:0], and the first location in the currently addressed doubleword. During the data phase, the signals are interpreted as such: C/BE3# C/BE2# C/BE1# C/BE0# ------ ------ ------ ------ 0 0 0 0 The initiator intend to transfer all four byte within the currently addresed doubleword using all four data paths 0 0 0 1 The initiator intends to transfer the upper three bytes within the currently addressed doubleword using the upper three data paths 0 0 1 0 The initiator intends to transfer the upper two bytes and the first byte wintin the currently addressed doubleword using the upper two data paths and the first data path. 0 0 1 1 The initiator intends to transfer the upper two bytes within the currently addressed doubleword using the upper two data paths 0 1 0 0 The initiator intends to transfer the upper byte and the lower two bytes within the currently addressed doubleword using the upper datapath and the lower two data paths. etc. If your interested in a pretty good treatment of the PCI bus, I'd recommend "PCI System Architecture", by Tom Shanley and Don Anderson of MindShare, Inc. Published by Addison Wesley, ISBN 0-201-40993-3. It covers in pretty good detail all the aspects of the PCI bus, including the autoconfiguration registers and other software issues. louie From owner-freebsd-hackers Sun Dec 15 07:41:51 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id HAA07884 for hackers-outgoing; Sun, 15 Dec 1996 07:41:51 -0800 (PST) Received: from ami.tom.computerworks.net (root@AMI.RES.CMU.EDU [128.2.95.1]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id HAA07869 for ; Sun, 15 Dec 1996 07:41:49 -0800 (PST) Received: from bonkers.taronga.com by ami.tom.computerworks.net with smtp (Smail3.1.29.1 #1) id m0vZIh8-0021ViC; Sun, 15 Dec 96 10:41 EST Received: (from peter@localhost) by bonkers.taronga.com (8.6.11/8.6.9) id JAA21675; Sun, 15 Dec 1996 09:39:15 -0600 Date: Sun, 15 Dec 1996 09:39:15 -0600 From: peter@taronga.com (Peter da Silva) Message-Id: <199612151539.JAA21675@bonkers.taronga.com> To: hackers@freebsd.org Subject: Re: Fwd: CVSup with SSH Newsgroups: taronga.freebsd.hackers In-Reply-To: <199612122224.OAA01655@austin.polstra.com> References: <199612121657.IAA17705@austin.polstra.com>,<199612121657.IAA17705@austin.polstra.com> Organization: none Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In article <199612122224.OAA01655@austin.polstra.com> you write: >Following up once more on using the TCP forwarding of ssh to CVSup >through a firewall: How are y'all tunneling ssh though the firewall? From owner-freebsd-hackers Sun Dec 15 08:10:08 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id IAA11725 for hackers-outgoing; Sun, 15 Dec 1996 08:10:08 -0800 (PST) Received: from bugs.us.dell.com (bugs.us.dell.com [143.166.169.147]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id IAA11703 for ; Sun, 15 Dec 1996 08:10:03 -0800 (PST) Received: from ant.us.dell.com (ant.us.dell.com [198.64.66.34]) by bugs.us.dell.com (8.6.12/8.6.12) with SMTP id KAA13530; Sun, 15 Dec 1996 10:09:23 -0600 Message-Id: <3.0.1.32.19961215100920.00678040@bugs.us.dell.com> X-Sender: tony@bugs.us.dell.com X-Mailer: Windows Eudora Light Version 3.0.1 beta 4 (32) Date: Sun, 15 Dec 1996 10:09:23 -0500 To: Bruce Evans , freebsd-hackers@FreeBSD.org, j@uriah.heep.sax.de From: Tony Overfield Subject: Re: MAXMEM was: Re: 2.1.6 on Compaq Prosignia 500 (2.1.5 worked) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk Sorry about this long answer! My genuine respect for you guys compels me to offer the best information I can. At 10:13 PM 12/15/96 +1100, Bruce Evans wrote: >>What BIOS calls? My old notebook is probably the oldest machine that >>somebody would be willing and able to run FreeBSD on (386/16, 5 MB >>RAM, approx. 1990/91), so i could test its BIOS for the existance of >>that call. > >You don't have >= 64MB extended memory, so the existence of the calls >doesn't matter. What matters is that they fail correctly if they are >not supported. Right. >The Interrupt List version 46 (June 1995) gives the at least the >following calls: > >--- >INT 15h/AH=88h The standard call, used in our boot blocks. Limited to > 64MB. Said to be unreliable because some BIOSes don't set the > carry flag if they don't support it. They didn't get this quite right. This call isn't optional and it cannot fail on 286+ systems. They may be confused by the fact that the carry flag is not even returned by this call, since, for compatibility, it must exit with IRET. If you feel compelled to check carry after this call, make sure it's cleared before you call it. Bonus: Since there could be 86xxh KB of extended memory, don't use AH=86h as a fail code for this function either. (I know, it's not likely.) >INT 15h/AX=DA88h. Works on AMI PCI BIOS. Returns size in K in CL:BX. This is a private, non-standard call. > >INT 15h/AX=E801h. Works on some Compaqs and Dells. Details not all > known. Limited to 64M. Not quite right. The values returned by this call are not limited to 64 MB. The details at http://www.uruk.org/grub/mem64mb.html are essentially correct for this function. Here's some of the missing info: The difference between the "configured" and "extended" values is that the "configured" represents the CMOS Setup values and "extended" represents the amount detected by POST. The word "extended", as used here, is usually called "installed" or "detected" by others. In the old days, when we had separate diskette-based Setup programs, these could actually differ until the user corrected the mismatch. The AX=E801h function works in real mode and 16-bit protected mode. There is also a 32-bit protected mode variant that is called with EAX=E881h, but don't expect that one to be supported. In more complete docs, the < 16 MB return values (in KB) are defined to be equal to the RTC-memory values. In effect, this limits the RTC-memory values to 15 MB extended. Windows NT codified this interpretation since NT will not use the E801h function unless the INT 15 AH=88h function returns no more than 15 MB. This limitation was later ignored to support rogue DOS-extenders and the like, but that, in turn, rendered the function useless for Windows NT and it drove Microsoft (and Intel) to create the considerably more powerful AX=0E820h function. See http://www.microsoft.com/kb/articles/q117/3/73.htm or search Microsoft for "e820" if this link was one of those short-term search temp things. > >INT 15h/AX=E802h. Works on some Compaqs. Details not known. > >INT 15h/AX=E802h. Works on some Dells. More details given than for > Compaq, but not enough to actually use it. It can apparently > report any number of discontiguous regions. They got this partly wrong too. The call is INT 15h/AX=0E820h. This call works on Compaq, Dell and a large number of other systems. The documentation at http://www.uruk.org/grub/mem64mb.html appears to be complete, although the official spec has been slightly revised for ACPI. The best version that I'm aware of is chapter 14 of the ACPI specification (ver. 0.9) which is located at: http://www.teleport.com/~acpi/ This function can indeed return arbitrarily detailed system memory maps. This function is called repeatedly until it "dries up." > >There is probably a standard way now, but it may not work on the old >Compaqs and Dells. Some have a stupid 15 or 16MB limit, so they hit >the limit a couple of years before other systems. > >Bruce That limit may indeed seem stupid now, but Dell and Compaq have been shipping systems that support greater than 64 MB of memory for more than six years. For most people, thank goodness, that "stupid limit" disappeared many years ago. The INT 15 AH=88h function hasn't, strictly speaking, worked correctly since about 1990. It seems petty to brag that "My BIOS discards less memory than yours does!" -- To help bolster my point, I'm conveniently ignoring the fact that a fair number of systems have more than 16 MB and not more than 64 MB of memory. ;-) I also think it's bad to use the RTC-memory values, since they are nominally BIOS-private values. In fact, in some systems, the oft-groped extended memory values are just the lower two bytes of an extended width value. Thus a 96 MB system may appear to be a 32 MB system, if the two RTC-memory bytes are used directly. However, in these cases the AH=88h value is wrong too, so some other solution is required anyway. In any case, for the last few years, all Dell systems have returned up to 0FC00h for INT 15h AH=88h, and they have supported at least one of INT 15h AX=E801h or AX=E820h. So, why does anything still use the AH=88h function (or the RTC-memory values) when it has been known for so many years that it is unable to support large memory systems? Of course, the answer is that the current solution works pretty well in most cases, so there's always been more deserving things to work on. Please believe me, I'm not trying to change that. I'm merely trying to offer whatever bits of wisdom I might have accumulated over the years on this topic. - p.s. -- Warning! Boring historical chronicle follows! -- There was a point in time (about 1990/1991) when Dell and Compaq were making EISA systems that supported over 100 MB of system memory. At that time, there were 286 protected-mode programs and operating systems that would horribly malfunction (descriptor overflows, etc.) when they queried system memory using AH=88h and got values greater than 15 MB. This is why some BIOS's in those days limited AH=88h to 15 MB. Besides, the AH=88h function was "defined" as part of a lowly 286 16 MB AT BIOS. Newer 386 and 486 EISA systems provided a way (via EISA BIOS calls, real- and protected-mode) to obtain the actual memory configuration in great detail. EISA was the wave of the future and all large memory systems would, of course, be EISA and therefore have the fancy EISA memory query functions. That was the theory anyway. There were some Dell and Compaq systems produced at this time that only supported AH=88h up to 15 MB and had only the weird EISA calls to obtain the extra extended memory. After a while, when large memory non-EISA systems were developed, the E801h function was created to report the extra memory above 16 MB. Oblivious to these things, other BIOS's were appearing that were returning values greater than 15 MB for AH=88h. This worked for systems with small memory (< 64 MB) and with most software. The simplicity of this short-sighted approach caused the DOS-extender writers (and others) to ignore the fancy new EISA BIOS calls and the new extended BIOS calls used by Dell, Compaq and others. The old 286 programs were quickly being upgraded or were being replaced by their superior competitors. By now, DOS, Windows, Windows NT, and OS/2 were using the new BIOS calls. But many new programs (some based on the 'rogue' DOS-extenders) were still relying on the AH=88h call to return all installed memory. It was at this point that the Dell BIOS was changed to return as much as 63 MB of extended memory from INT 15 AH=88h. Well that's a long story, but I think I got it mostly right. - Tony - not speaking in any official capacity. From owner-freebsd-hackers Sun Dec 15 08:43:01 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id IAA14404 for hackers-outgoing; Sun, 15 Dec 1996 08:43:01 -0800 (PST) Received: from mexico.brainstorm.eu.org (root@mexico.brainstorm.fr [193.56.58.253]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id IAA14398 for ; Sun, 15 Dec 1996 08:42:52 -0800 (PST) Received: from brasil.brainstorm.eu.org (brasil.brainstorm.fr [193.56.58.33]) by mexico.brainstorm.eu.org (8.7.5/8.7.3) with ESMTP id RAA29447 for ; Sun, 15 Dec 1996 17:42:45 +0100 Received: (from uucp@localhost) by brasil.brainstorm.eu.org (8.6.12/8.6.12) with UUCP id RAA08526 for hackers@freebsd.org; Sun, 15 Dec 1996 17:42:34 +0100 Received: (from roberto@localhost) by keltia.freenix.fr (8.8.4/keltia-uucp-2.9) id RAA05716; Sun, 15 Dec 1996 17:06:15 +0100 (CET) Message-ID: Date: Sun, 15 Dec 1996 17:06:14 +0100 From: roberto@keltia.freenix.fr (Ollivier Robert) To: hackers@freebsd.org Subject: Re: Fwd: CVSup with SSH References: <199612121657.IAA17705@austin.polstra.com>,<199612121657.IAA17705@austin.polstra.com> <199612151539.JAA21675@bonkers.taronga.com> X-Mailer: Mutt 0.54 Mime-Version: 1.0 X-Operating-System: FreeBSD 3.0-CURRENT ctm#2768 In-Reply-To: <199612151539.JAA21675@bonkers.taronga.com>; from Peter da Silva on Dec 15, 1996 09:39:15 -0600 Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk According to Peter da Silva: > > How are y'all tunneling ssh though the firewall? In my case, the port 22 is authorized from my machine to anywhere in the world. So I ssh to freefall with port redirection for CVSup. It works like a charm. I had a CVS tree at ctm_level 2700 and in less than one hour I was had CVSup-ed the current tree. ssh compression + CVSup is great. -- Ollivier ROBERT -=- The daemon is FREE! -=- roberto@keltia.freenix.fr FreeBSD keltia.freenix.fr 3.0-CURRENT #31: Tue Dec 3 23:52:58 CET 1996 From owner-freebsd-hackers Sun Dec 15 12:04:26 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id MAA24676 for hackers-outgoing; Sun, 15 Dec 1996 12:04:26 -0800 (PST) Received: from rah.star-gate.com ([204.188.121.18]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id MAA24670 for ; Sun, 15 Dec 1996 12:04:23 -0800 (PST) Received: from rah.star-gate.com (localhost.star-gate.com [127.0.0.1]) by rah.star-gate.com (8.7.6/8.7.3) with ESMTP id MAA01471; Sun, 15 Dec 1996 12:03:59 -0800 (PST) Message-Id: <199612152003.MAA01471@rah.star-gate.com> X-Mailer: exmh version 1.6.9 8/22/96 To: FreeBSD@net-tel.co.uk cc: hackers@freebsd.org Subject: Re: PCI 2.1 Byte Enables? In-reply-to: Your message of "Sun, 15 Dec 1996 13:45:09 GMT." <"1c28-961215134504-FCA1*/S=FreeBSD/O=NET-TEL Computer Systems Ltd/PRMD=NET-TEL/ADMD=Gold 400/C=GB/"@MHS> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 15 Dec 1996 12:03:59 -0800 From: Amancio Hasty Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >From The Desk Of FreeBSD@net-tel.co.uk : > > I am writing a device driver for a PCI video capture board, > > Brooktree Bt848,as part of a dma risc instruction it requires : > > byte count and 4 bits for PCI byte enables. > > > > Can anyone guess what the PCI byte enables are for? > > PCI transfers operate on 32-bit words, and are always addressed on 4-byte > boundaries. With each word transferred, there are 4 byte-enable signals > to indicate which of the 4 bytes are in use. > > So, to do a DMA transfer of an abritrary byte-aligned block of memory, > you would do one cycle with byte enables adjusted to pick up the first > 1,2, or 3 bytes to bring you to a word boundary, then a number of > cycles with all 4 byte enables active, then a last cycle with byte > enables set to write the write number of bytes. > > On the bus, the byte enables are 4 bits, one for each byte of the > 32-bit word, and are "1" for disable, "0" for enable. You are not > required to set them contiguously - you could transfer alternate > bytes by setting the enables appropriately if you felt like it. > > However, you would expect two sets of byte enable settings for an > arbitrary DMA transfer (starting/ending), so your chip must be doing > somthing more sophisticated - maybe you give it the starting > byte enables and it computes the ending ones from the byte count? Hi, I am going out today and get a PCI book not just for the PCI Byte enables issue but to find out more about the PCI bus. At any rate, this is what the risc instruction looks like: WRITE opcode 0001 --- Write Packed mode Pixels to memory from the FIFO beginning at the specified target address. dword0: 11:0 Byte Count 15:12 Byte Enables 23:16 Reset/Set RISC_STATUS 24 IRQ 25 Reserved 26 EOL - End of line 27 SOL - Start of Line 31:28 Opcode dword1: 31:0 Target Address (buffer to dump video to) -- WRITEC opcode 0101 --- Write Packed mode pixels to memory from the FIFO continuing from the current target address. (packed mode is rgb32, rgb24, or rgb16) dword0: 11:0 Byte Count 15:12 Byte Enables 23:16 Reset/Set RISC_STATUS 24 IRQ 25 Reserved 26 EOL - End of Line 27 SOL - Start of Line bit not used in this instruction 31:28 Opcode -- A "dma risc program" can have one or more "WRITE" or WRITEC instructions. In the case of a "WRITEC" instruction, the DMA transfer must be first initiated by a "WRITE" instruction with the "SOL" bit set According to the databook a "WRITE" can have both EOL and SOL set which implies that the Bt848 is capable of starting and ending a DMA transfer. Since, I am transferring rgb32 -- 4bytes per pixel and my buffer is dword aligned my guess is that PCI Byte Enables should be 0. Tnks also to all who responded... Regards, Amancio From owner-freebsd-hackers Sun Dec 15 13:05:32 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id NAA00269 for hackers-outgoing; Sun, 15 Dec 1996 13:05:32 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id NAA00262 for ; Sun, 15 Dec 1996 13:05:30 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id NAA23851; Sun, 15 Dec 1996 13:41:13 -0700 From: Terry Lambert Message-Id: <199612152041.NAA23851@phaeton.artisoft.com> Subject: Re: MAXMEM was: Re: 2.1.6 on Compaq Prosignia 500 (2.1.5 worked) To: tony@dell.com (Tony Overfield) Date: Sun, 15 Dec 1996 13:41:13 -0700 (MST) Cc: eivind@dimaga.com, hackers@freebsd.org In-Reply-To: <3.0.1.32.19961214202436.0067ea7c@bugs.us.dell.com> from "Tony Overfield" at Dec 14, 96 08:24:46 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-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > There are standardized BIOS calls to obtain the correct amount of > memory, even when it exceeds 65 MB. I think the boot loader should > make these BIOS calls and pass the correct information to the kernel. Go ahead and add it. Make sure the boot code doesn't grow over the 8k limit imposed on it by the fact that there isn't any more space between the start of the BSD area on the disk and the disklabel on everyone's hardrives for several years now... 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-hackers Sun Dec 15 13:10:14 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id NAA00451 for hackers-outgoing; Sun, 15 Dec 1996 13:10:14 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id NAA00446; Sun, 15 Dec 1996 13:10:11 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id NAA23837; Sun, 15 Dec 1996 13:39:04 -0700 From: Terry Lambert Message-Id: <199612152039.NAA23837@phaeton.artisoft.com> Subject: Re: vulnerability in new pw suite To: rb@gid.co.uk (Bob Bishop) Date: Sun, 15 Dec 1996 13:39:04 -0700 (MST) Cc: terry@lambert.org, proff@iq.org, security@freebsd.org, hackers@freebsd.org In-Reply-To: from "Bob Bishop" at Dec 15, 96 12:53:42 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-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > There are something over 10^14 usable 8 character passwords. Of these, > maybe 10^5 are in dictionaries, and maybe another 100 'guessables' per user > could be found easily by trawling the user's home directory and points > south. Throw in a few more (SO's name, phone number and the like) and maybe > you can get up to c. 2 x 10^5 passwords per user that are unsafe. That > still leaves comfortably over 10^14 comparatively safe 8 character > passwords. > > So there isn't actually a problem, it's just that those pesky users will > insist on picking passwords from the unsafe set. They use lame excuses like > "I cant remember %bSx48&J". Heh. Please define "unsafe" in the context of a functional (inaccessible for pre-salt-based attacks) shadow password system. 8-) 8-). I'm tired of having passwd not let me use whatever password I want, considering that with a shadow file, the user will have to brute-force it through /bin/login or equivalent. It seems the harder it becomes to see my post-encryption password, the more anal the passwd command becomes about making post-encryption passwords "safe" from attacks which are impossible to institute unless root has been compromised. Just my opinion about anal passwd programs... 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-hackers Sun Dec 15 13:11:25 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id NAA00525 for hackers-outgoing; Sun, 15 Dec 1996 13:11:25 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id NAA00516 for ; Sun, 15 Dec 1996 13:11:21 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id NAA23869; Sun, 15 Dec 1996 13:47:16 -0700 From: Terry Lambert Message-Id: <199612152047.NAA23869@phaeton.artisoft.com> Subject: Re: MAXMEM was: Re: 2.1.6 on Compaq Prosignia 500 (2.1.5 To: eivind@dimaga.com (Eivind Eklund) Date: Sun, 15 Dec 1996 13:47:16 -0700 (MST) Cc: tony@dell.com, hackers@freebsd.org In-Reply-To: <3.0.32.19961215044615.00925dd0@dimaga.com> from "Eivind Eklund" at Dec 15, 96 04:46:16 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-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > The problem is that these BIOS calls are (to my knowledge; I'm no BIOS/PC > hardware guru) only are guaranteed available on EISA computers, and only > work from protected mode. To do this "properly" requires both a check to > see if the computer has an EISA bus (which is in no way guaranteed - EISA > seems to be dying), a switch to protected mode, and a fetch of the value. > Few operating systems seems to do this "correctly". As examples, both > Novell and SCO need this to be specified as an option. You forgot to mention that the EISA standard does not specify a mechanism for determining the per slot memory which the particular machine has, except from a real mode only BIOS call. The real soloution is to make VM86() work, and make the BIOS calls from protected mode by creating a VM, loading code, running the VM to make real mode BIOS calls, fetching out the results, and destroying the VM (unless you have a disk driver or something using it). Note that in order to do this, you have to read the CMOS values (up to 16M) to know a minimal amount of memory you have to work with. However the point remains valid: the place to fix this is in the kernel support for virtual machines, not in the boot blocks themselves. Consider: the PC is an inept design. Almost all other systems have standardized ROM interfaces for protected mode. Even PS/2 machines (ABIOS). 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-hackers Sun Dec 15 13:13:02 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id NAA00627 for hackers-outgoing; Sun, 15 Dec 1996 13:13:02 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id NAA00622 for ; Sun, 15 Dec 1996 13:12:59 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id NAA23883; Sun, 15 Dec 1996 13:48:55 -0700 From: Terry Lambert Message-Id: <199612152048.NAA23883@phaeton.artisoft.com> Subject: Re: MAXMEM was: Re: 2.1.6 on Compaq Prosignia 500 (2.1.5 To: tony@dell.com (Tony Overfield) Date: Sun, 15 Dec 1996 13:48:54 -0700 (MST) Cc: eivind@dimaga.com, hackers@FreeBSD.ORG In-Reply-To: <3.0.1.32.19961215015705.0067a82c@bugs.us.dell.com> from "Tony Overfield" at Dec 15, 96 01:57:11 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-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > A few various queries using AltaVista turned up this link: > http://www.uruk.org/grub/mem64mb.html which documents the calls. > Perhaps not coincidentally, the link at: > http://www.uruk.org/grub/ describes a fancy boot loader. Not incidently, this is Erich's home page and his boot loader, and he is seriously involved in the SMP effort already. 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-hackers Sun Dec 15 13:17:36 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id NAA00896 for hackers-outgoing; Sun, 15 Dec 1996 13:17:36 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id NAA00891 for ; Sun, 15 Dec 1996 13:17:33 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id NAA23897; Sun, 15 Dec 1996 13:53:59 -0700 From: Terry Lambert Message-Id: <199612152053.NAA23897@phaeton.artisoft.com> Subject: Re: poll(2) To: peter@spinner.DIALix.COM (Peter Wemm) Date: Sun, 15 Dec 1996 13:53:59 -0700 (MST) Cc: freebsd-hackers@freebsd.org In-Reply-To: <590svj$3dp$1@haywire.DIALix.COM> from "Peter Wemm" at Dec 15, 96 01:03:47 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-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > I did some code to do this about 6 months ago, it's still in my checked > out -current kernel and still works. I had seen OpenBSD's code (a lot) > so it's not purely independent, but it is quite different in certain > areas. While I was there, I got carried away and implemented the feature > described in the "BUGS" section right at the end of the select(2) man page. This would be the modification of the remaining time for a non-null, non-zero timeval struct? You should note that this will not work for much of the software in the known universe... I think even Linux backed this one out after it caused problems with ...oh... Netscape. 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-hackers Sun Dec 15 13:43:04 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id NAA02205 for hackers-outgoing; Sun, 15 Dec 1996 13:43:04 -0800 (PST) Received: from dfw.dfw.net (aleph1@[198.175.15.10]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id NAA02187; Sun, 15 Dec 1996 13:43:00 -0800 (PST) Received: from localhost by dfw.dfw.net (4.1/SMI-4.1) id AA19213; Sun, 15 Dec 96 15:40:44 CST Date: Sun, 15 Dec 1996 15:40:43 -0600 (CST) From: Aleph One To: Terry Lambert Cc: Bob Bishop , proff@iq.org, security@FreeBSD.ORG, hackers@FreeBSD.ORG Subject: Re: vulnerability in new pw suite In-Reply-To: <199612152039.NAA23837@phaeton.artisoft.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Sun, 15 Dec 1996, Terry Lambert wrote: > I'm tired of having passwd not let me use whatever password I want, > considering that with a shadow file, the user will have to brute-force > it through /bin/login or equivalent. It seems the harder it becomes to > see my post-encryption password, the more anal the passwd command > becomes about making post-encryption passwords "safe" from attacks > which are impossible to institute unless root has been compromised. Just because the passwd is shadowed does not mean it wont be cracked. The are programs that will brute force passwords using POP, TELNET, RSH, etc. > > Regards, > Terry Lambert > terry@lambert.org > --- > Any opinions in this posting are my own and not those of my present > or previous employers. > Aleph One / aleph1@dfw.net http://underground.org/ KeyID 1024/948FD6B5 Fingerprint EE C9 E8 AA CB AF 09 61 8C 39 EA 47 A8 6A B8 01 From owner-freebsd-hackers Sun Dec 15 13:54:35 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id NAA03666 for hackers-outgoing; Sun, 15 Dec 1996 13:54:35 -0800 (PST) Received: from apolo.biblos.unal.edu.co ([168.176.37.75]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id NAA03658 for ; Sun, 15 Dec 1996 13:54:28 -0800 (PST) Received: from unalmodem.usc.unal.edu.co ([168.176.3.39]) by apolo.biblos.unal.edu.co (8.8.2/8.8.2) with SMTP id QAA04760; Sun, 15 Dec 1996 16:55:07 -0500 (EST) Message-ID: <32B49D07.3A62@fps.biblos.unal.edu.co> Date: Sun, 15 Dec 1996 16:51:19 -0800 From: "Pedro Giffuni S." Organization: Universidad Nacional de Colombia X-Mailer: Mozilla 3.0 (Win16; I) MIME-Version: 1.0 To: Terry Lambert CC: freebsd-hackers@freefall.freebsd.org Subject: Other filesystems under FreeBSD References: <199610312127.OAA26259@phaeton.artisoft.com> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hello: I have this crazy dream that I could, one day, mount SCO, Linux, and Solaris FS's under FreeBSD *and* run all this apps transparently by emulating. I now have more documentation about SCO filesystems, and HPFS: these two are also supported (partially) by Linux. What I really donīt have is documentation about FFS. Since fbsd seems to be ill suited for other filesystems, should "we" try to implement a standard Linux filesystem and derive the others from it, or should *we* try to use more documentation than Linux sources, and try to implement them from our VFS? Pedro. Some years ago, Terry Lambert wrote: > > > There is nothing "magical" about these implementations, except our VFS > interface is still pretty poorly suited to adding new FS's without a > lot of work to get around layering problems, a lot of code which has > to be duplicated per FS which belongs in upper layers, and a full > kernel recompile because the vfs_init still gets its side from the > UFS vnops and vfsops structures intead of from a sizeof() in vnode_if.c. > > 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-hackers Sun Dec 15 14:04:39 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id OAA04841 for hackers-outgoing; Sun, 15 Dec 1996 14:04:39 -0800 (PST) Received: from gw.muc.ditec.de (gw.muc.ditec.de [194.120.126.3]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id OAA04825 for ; Sun, 15 Dec 1996 14:04:34 -0800 (PST) Received: (from nobody@localhost) by gw.muc.ditec.de (8.7.5/8.6.9) id XAA22158 for ; Sun, 15 Dec 1996 23:04:52 +0100 (MET) X-Authentication-Warning: gw.muc.ditec.de: nobody set sender to using -f Received: from tartufo.muc.ditec.de(134.98.18.2) by gw.muc.ditec.de via smap (V2.0alpha) id sma022156; Sun Dec 15 23:04:31 1996 Received: by tartufo.muc.ditec.de (/\=-/\ Smail3.1.16.1 #16.39) id ; Wed, 4 Dec 96 16:05 MEZ Message-Id: Date: Sun, 15 Dec 96 23:06 MEZ From: me@tartufo.muc.ditec.de (Michael Elbel) To: cracauer@wavehh.hanse.de Cc: hackers@freebsd.org Subject: Re: A simple way to crash your system. Newsgroups: lists.freebsd.hackers References: <199611260208.TAA02586@rocky.mt.sri.com> <9611271251.AA07737@wavehh.hanse.de> Reply-To: me@gw.muc.ditec.de X-Newsreader: NN version 6.5.0 #1 (NOV) Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In lists.freebsd.hackers you write: >>I'd welcome some compromise solutions, otherwise I think it's simply >>too dangerous to advertise, explicitly or implicitly, as a feature. >> Jordan >What about read-only mode? Maybe I missed something, but I didn't hear >from problems reading it. So listen up then ;) I've tried to install my notebook from DOS partition before I got this &#*@) 3com 589C PCMCIA card working and just reading the tarballs didn't work (corrupted data came out of msdosfs). Michael -- Michael Elbel, DITEC, Muenchen, Germany - me@muc.ditec.de Fermentation fault (coors dumped) From owner-freebsd-hackers Sun Dec 15 14:34:59 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id OAA08236 for hackers-outgoing; Sun, 15 Dec 1996 14:34:59 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id OAA08225 for ; Sun, 15 Dec 1996 14:34:56 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id PAA24071; Sun, 15 Dec 1996 15:11:35 -0700 From: Terry Lambert Message-Id: <199612152211.PAA24071@phaeton.artisoft.com> Subject: Re: Other filesystems under FreeBSD To: pgiffuni@fps.biblos.unal.edu.co (Pedro Giffuni S.) Date: Sun, 15 Dec 1996 15:11:35 -0700 (MST) Cc: terry@lambert.org, freebsd-hackers@freefall.freebsd.org In-Reply-To: <32B49D07.3A62@fps.biblos.unal.edu.co> from "Pedro Giffuni S." at Dec 15, 96 04:51:19 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-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > I have this crazy dream that I could, one day, mount SCO, Linux, and > Solaris FS's under FreeBSD *and* run all this apps transparently by > emulating. > I now have more documentation about SCO filesystems, and HPFS: these two > are also supported (partially) by Linux. What I really don=B4t have is > documentation about FFS. > Since fbsd seems to be ill suited for other filesystems, should "we" try > to implement a standard Linux filesystem and derive the others from it, > or should *we* try to use more documentation than Linux sources, and try > to implement them from our VFS? > > > Pedro. > > Some years ago, Terry Lambert wrote: > > There is nothing "magical" about these implementations, except our VFS > > interface is still pretty poorly suited to adding new FS's without a > > lot of work to get around layering problems, a lot of code which has > > to be duplicated per FS which belongs in upper layers, and a full > > kernel recompile because the vfs_init still gets its side from the > > UFS vnops and vfsops structures intead of from a sizeof() in vnode_if.c. This is out of context. The article you are quoting was discussing this either in the context adding new VNOPS, or in the context of adding multiple name spaces for VFAT/NTFS/HPFS support. You also seem a bit confused about what I said, vs. what I meant. This is probably my fault, so I'll clarify a bit. FreeBSD is well suited to other file systems. What I was discussing was a number of small changes to the mechanism to seperate the implementation from the instantiation. Basically, I wanted to be able to simplify the code I needed to write to write a new FS, even more than it is already simplified over that for Linux. This is not the same thing as the code being impossible without the changes, only "more difficult than it would be in Terry's ideal world". The BSD VFS interface is much, much better abstracted than the Linux VFS interface. Part of this is because the Linux interface has been rigidly defined in order to meet the LGPL criteria for kernel modules that are not GPL/LGPL themselves calling kernel functions, but yet not technically being part of the kernel. Part of it is the way the VFS bottom end interface to the buffer cache and disk I/O has been grown organically in Linux. And part of it is that the Linux VFS expects only a single consumer, so the top end interface is not well seperated from the system call interface (this is also the reason it does not yet have a kernel NFS server). Usage of region prevalidation, besides leaving nasty security holes in the SMP and kernel multithreading cases, is very system-call consumer specific. The FFS is probably irrlevant for what you want to do... it's overly complex for simple sample code. Actually, you probably want to implement the SCO FS's seperately. For this, the monolithic FS's would be a better example of cache and VFS top end interfacing than the UFS derived FS's, which share code in non-obvious ways. Clearly, this would be easier for you if the FreeBSD VFS interface was more rigidly abstracted than it is at the top end, and the FS physical media interfaces were better documented than they are (both of these are problems which are being addressed). But even though I don't think they are done (I have high standards), they beat the Linux abstractions (which are non-existant) cold. If you find you have specific questions on implementation that aren't answered in the Heidemann thesis in the FICUS project directory on ftp.cs.ucla.edu, or in the book "The Design and Implementation of the 4.4BSD Operating System", then send me mail. If I don't already have the answer archived, I will find one for you (the SCO FS's are rather important; HPFS has been dropped from BT 4.x and so is about as important as OS/2: not very). 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-hackers Sun Dec 15 14:37:43 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id OAA08587 for hackers-outgoing; Sun, 15 Dec 1996 14:37:43 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id OAA08568 for ; Sun, 15 Dec 1996 14:37:39 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id PAA24090; Sun, 15 Dec 1996 15:14:23 -0700 From: Terry Lambert Message-Id: <199612152214.PAA24090@phaeton.artisoft.com> Subject: Re: Other filesystems under FreeBSD To: pgiffuni@fps.biblos.unal.edu.co (Pedro Giffuni S.) Date: Sun, 15 Dec 1996 15:14:23 -0700 (MST) Cc: terry@lambert.org, freebsd-hackers@freefall.freebsd.org In-Reply-To: <32B49D07.3A62@fps.biblos.unal.edu.co> from "Pedro Giffuni S." at Dec 15, 96 04:51:19 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-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Ugh. I was not aware that this was going to the list; if I had been, I probably would have either modified the address list, or been a bit less frank in my observations about the Linux VFS and the differences between the ideal interface in BSD and the current reality. If anyone was offended, I appologize in advance for not tailoring my response to your (illogical) sensibilites. 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-hackers Sun Dec 15 14:46:09 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id OAA09396 for hackers-outgoing; Sun, 15 Dec 1996 14:46:09 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id OAA09387; Sun, 15 Dec 1996 14:46:06 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id PAA24138; Sun, 15 Dec 1996 15:21:44 -0700 From: Terry Lambert Message-Id: <199612152221.PAA24138@phaeton.artisoft.com> Subject: Re: vulnerability in new pw suite To: aleph1@dfw.net (Aleph One) Date: Sun, 15 Dec 1996 15:21:44 -0700 (MST) Cc: terry@lambert.org, rb@gid.co.uk, proff@iq.org, security@FreeBSD.ORG, hackers@FreeBSD.ORG In-Reply-To: from "Aleph One" at Dec 15, 96 03:40:43 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-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > Just because the passwd is shadowed does not mean it wont be cracked. The > are programs that will brute force passwords using POP, TELNET, RSH, etc. And as a result will hit source/attempt based security triggers on any real machine, and automatically shut down future attempts until such time as the administrator can deal wit the alerts to the systems satisfaction. Try five failed login attempts to telnet on a Sun machine. It delays (and reports) each failed attempt, and drops the connection (after as huge delay) after the fifth. 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-hackers Sun Dec 15 14:52:45 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id OAA10739 for hackers-outgoing; Sun, 15 Dec 1996 14:52:45 -0800 (PST) Received: from irz201.inf.tu-dresden.de (irz201.inf.tu-dresden.de [141.76.1.10]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id OAA10616 for ; Sun, 15 Dec 1996 14:52:29 -0800 (PST) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by irz201.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id XAA16286; Sun, 15 Dec 1996 23:51:43 +0100 Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id XAA02623; Sun, 15 Dec 1996 23:51:42 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.8.4/8.6.9) id XAA01285; Sun, 15 Dec 1996 23:42:18 +0100 (MET) From: J Wunsch Message-Id: <199612152242.XAA01285@uriah.heep.sax.de> Subject: Re: Fwd: CVSup with SSH To: freebsd-hackers@freebsd.org (FreeBSD hackers) Date: Sun, 15 Dec 1996 23:42:18 +0100 (MET) Cc: peter@taronga.com (Peter da Silva) Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199612151539.JAA21675@bonkers.taronga.com> from Peter da Silva at "Dec 15, 96 09:39:15 am" 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 X-Mailer: ELM [version 2.4ME+ PL17 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk As Peter da Silva wrote: > >Following up once more on using the TCP forwarding of ssh to CVSup > >through a firewall: > > How are y'all tunneling ssh though the firewall? port 22 permit :-) I don't see much points in _not_ tunneling it through a firewall. Well, i don't see much points in firewalls at all, so better redirect followups to -chat. ;-) -- 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 15 15:06:25 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id PAA12285 for hackers-outgoing; Sun, 15 Dec 1996 15:06:25 -0800 (PST) Received: from garrison.inetcan.net (dreamer@garrison.inetcan.net [206.186.215.2]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id PAA12252; Sun, 15 Dec 1996 15:06:13 -0800 (PST) Received: (from dreamer@localhost) by garrison.inetcan.net (8.8.4/8.8.4) id RAA10623; Sun, 15 Dec 1996 17:10:04 -0700 Date: Sun, 15 Dec 1996 17:10:04 -0700 (MST) From: Digital Dreamer To: Terry Lambert cc: Bob Bishop , terry@lambert.org, proff@iq.org, security@FreeBSD.ORG, hackers@FreeBSD.ORG Subject: Re: vulnerability in new pw suite In-Reply-To: <199612152039.NAA23837@phaeton.artisoft.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Sun, 15 Dec 1996, Terry Lambert wrote: > Heh. > > Please define "unsafe" in the context of a functional (inaccessible for > pre-salt-based attacks) shadow password system. > > 8-) 8-). > > I'm tired of having passwd not let me use whatever password I want, > considering that with a shadow file, the user will have to brute-force > it through /bin/login or equivalent. It seems the harder it becomes to > see my post-encryption password, the more anal the passwd command > becomes about making post-encryption passwords "safe" from attacks > which are impossible to institute unless root has been compromised. > > Just my opinion about anal passwd programs... The idea, from what I understand, is to act as if you don't have shadow passwords, and therefore not rely on them. Security through obscurity and all that. For example, let's say someone breaks root on your machine. Ok, you're in a lot of trouble. But let's attempt to minimize the damage by not giving them 6e12 accounts to log on as in the future when/if they're discovered by handing over the passwords for them on a silver plate. It takes a lot longer to get all your users to change passwords than it takes to fix a backdoored /bin/login. dreamer From owner-freebsd-hackers Sun Dec 15 15:08:06 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id PAA12504 for hackers-outgoing; Sun, 15 Dec 1996 15:08:06 -0800 (PST) Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id PAA12495 for ; Sun, 15 Dec 1996 15:08:03 -0800 (PST) Received: (from msmith@localhost) by genesis.atrad.adelaide.edu.au (8.8.2/8.7.3) id JAA18445; Mon, 16 Dec 1996 09:36:23 +1030 (CST) From: Michael Smith Message-Id: <199612152306.JAA18445@genesis.atrad.adelaide.edu.au> Subject: VM86 (was Re: MAXMEM...) In-Reply-To: <199612152047.NAA23869@phaeton.artisoft.com> from Terry Lambert at "Dec 15, 96 01:47:16 pm" To: terry@lambert.org (Terry Lambert) Date: Mon, 16 Dec 1996 09:36:22 +1030 (CST) Cc: eivind@dimaga.com, tony@dell.com, hackers@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-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Terry Lambert stands accused of saying: > > The real soloution is to make VM86() work, and make the BIOS calls Yeah, well vm86() would have been working about 6 months ago if Sean and I had ever received a response to our pleas for help. As it is, it seems to exist more profitably as some Great White Hope than as a working kernel service. > Terry Lambert (If anyone does want to help; change the size of the sigcontext struct, recompile your kernel, and then come back with an enumerated list of other things that need to be changed to stop it from crashing. We could _really_ use some help here.) -- ]] 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-hackers Sun Dec 15 15:13:06 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id PAA12858 for hackers-outgoing; Sun, 15 Dec 1996 15:13:06 -0800 (PST) Received: from dfw.dfw.net (aleph1@dfw.dfw.net [198.175.15.10]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id PAA12853; Sun, 15 Dec 1996 15:12:59 -0800 (PST) Received: from localhost by dfw.dfw.net (4.1/SMI-4.1) id AA29130; Sun, 15 Dec 96 17:10:51 CST Date: Sun, 15 Dec 1996 17:10:51 -0600 (CST) From: Aleph One To: Terry Lambert Cc: rb@gid.co.uk, proff@iq.org, security@FreeBSD.ORG, hackers@FreeBSD.ORG Subject: Re: vulnerability in new pw suite In-Reply-To: <199612152221.PAA24138@phaeton.artisoft.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Sun, 15 Dec 1996, Terry Lambert wrote: > Try five failed login attempts to telnet on a Sun machine. It delays > (and reports) each failed attempt, and drops the connection (after as > huge delay) after the fifth. Try su on a Solaris machine and if it takes to long hit ^C. The attempt will not be logged. You assume all such attems will be logged and trigger some alarm. You also assume the are trigger on all system that can verify a password. Thats a lot of assumtions. Its easier to cut bad passwords at the source. > Regards, > Terry Lambert > terry@lambert.org > --- > Any opinions in this posting are my own and not those of my present > or previous employers. > Aleph One / aleph1@dfw.net http://underground.org/ KeyID 1024/948FD6B5 Fingerprint EE C9 E8 AA CB AF 09 61 8C 39 EA 47 A8 6A B8 01 From owner-freebsd-hackers Sun Dec 15 15:30:50 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id PAA14628 for hackers-outgoing; Sun, 15 Dec 1996 15:30:50 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id PAA14623; Sun, 15 Dec 1996 15:30:47 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id QAA00303; Sun, 15 Dec 1996 16:25:42 -0700 From: Terry Lambert Message-Id: <199612152325.QAA00303@phaeton.artisoft.com> Subject: Re: vulnerability in new pw suite To: dreamer@garrison.inetcan.net (Digital Dreamer) Date: Sun, 15 Dec 1996 16:25:42 -0700 (MST) Cc: terry@lambert.org, rb@gid.co.uk, proff@iq.org, security@FreeBSD.ORG, hackers@FreeBSD.ORG In-Reply-To: from "Digital Dreamer" at Dec 15, 96 05:10:04 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-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > Just my opinion about anal passwd programs... > > The idea, from what I understand, is to act as if you don't have shadow > passwords, and therefore not rely on them. Security through obscurity > and all that. > > For example, let's say someone breaks root on your machine. Ok, you're > in a lot of trouble. But let's attempt to minimize the damage by not > giving them 6e12 accounts to log on as in the future when/if they're > discovered by handing over the passwords for them on a silver plate. It > takes a lot longer to get all your users to change passwords than it > takes to fix a backdoored /bin/login. A backdoored /bin/login can be nothing more than a program that mails account/password pairs. Be that as it may, by logical extension, we should act as if we didn't have passwords, and therefore not rely on them. Didn't know you were a radical Stallmanite... 8-) 8-). The reductio-ad-absurdum of this is wondering if someone has bribed the person who digs the rocks that are used to manufacture the nitric acid that is used for soaking the gun cotton at the ammunition plant that supplies the bullets to the Government you got your Marine guards from so their guns don't go off when the person who did the bribing comes to break in to the 10M drive on your PC-XT. You could also worry that someone would fake an accident so that while delivering the pick to the store where the guy who digs the rocks boss'es purchasing agent got his pick, they could substitute a different pick so that the rocks it was used on would fail to make good nitric acid. Not to mention the guy who planted the tree 120 years ago, which was milled into the handle for that pick... after all, this could be a wide-ranging conspiricy which has been in planning for centuries. ...like they wouldn't just send masked ninjas to get your disk. 8-P. 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-hackers Sun Dec 15 15:32:16 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id PAA14861 for hackers-outgoing; Sun, 15 Dec 1996 15:32:16 -0800 (PST) Received: from garrison.inetcan.net (dreamer@garrison.inetcan.net [206.186.215.2]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id PAA14840; Sun, 15 Dec 1996 15:32:11 -0800 (PST) Received: (from dreamer@localhost) by garrison.inetcan.net (8.8.4/8.8.4) id RAA11139; Sun, 15 Dec 1996 17:36:12 -0700 Date: Sun, 15 Dec 1996 17:36:12 -0700 (MST) From: Digital Dreamer To: Terry Lambert cc: terry@lambert.org, rb@gid.co.uk, proff@iq.org, security@FreeBSD.ORG, hackers@FreeBSD.ORG Subject: Re: vulnerability in new pw suite In-Reply-To: <199612152325.QAA00303@phaeton.artisoft.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Sun, 15 Dec 1996, Terry Lambert wrote: > > For example, let's say someone breaks root on your machine. Ok, you're > > in a lot of trouble. But let's attempt to minimize the damage by not > > giving them 6e12 accounts to log on as in the future when/if they're > > discovered by handing over the passwords for them on a silver plate. It > > takes a lot longer to get all your users to change passwords than it > > takes to fix a backdoored /bin/login. > > A backdoored /bin/login can be nothing more than a program that mails > account/password pairs. Really? In a lot of places, /bin/login is suid. It's a common trick to have a backdoored login that will let you in as any user if you supply the correct backdoor password, and even better, it neglects to put your login in utmp so a 'w' won't show you. > Be that as it may, by logical extension, we should act as if we didn't > have passwords, and therefore not rely on them. In fact, it seems to be that is a rather good idea for places where security is imperative. Secure your system from the inside as well, so if someone does break in to your machine, they can't get root. Secure it from the inside, even if you don't (think you have) any holes allowing those from the outside to get in. > from so their guns don't go off when the person who did the bribing > comes to break in to the 10M drive on your PC-XT. It's 2MB, and the ST-506 controller went last week. dreamer From owner-freebsd-hackers Sun Dec 15 15:44:54 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id PAA16124 for hackers-outgoing; Sun, 15 Dec 1996 15:44:54 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id PAA16115; Sun, 15 Dec 1996 15:44:51 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id QAA00213; Sun, 15 Dec 1996 16:36:04 -0700 From: Terry Lambert Message-Id: <199612152336.QAA00213@phaeton.artisoft.com> Subject: Re: vulnerability in new pw suite To: dreamer@garrison.inetcan.net (Digital Dreamer) Date: Sun, 15 Dec 1996 16:36:04 -0700 (MST) Cc: terry@lambert.org, rb@gid.co.uk, proff@iq.org, security@FreeBSD.ORG, hackers@FreeBSD.ORG In-Reply-To: from "Digital Dreamer" at Dec 15, 96 05:36:12 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-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > from so their guns don't go off when the person who did the bribing > > comes to break in to the 10M drive on your PC-XT. > > It's 2MB, and the ST-506 controller went last week. Fool! Your machine is not safe... all ninjas worth their salt carry extra ST-506 controllers! Do you know nothing of Tai-Kwan Leap? 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-hackers Sun Dec 15 16:18:52 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id QAA20970 for hackers-outgoing; Sun, 15 Dec 1996 16:18:52 -0800 (PST) Received: from isbalham.ist.co.uk (isbalham.ist.co.uk [192.31.26.1]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id QAA20910; Sun, 15 Dec 1996 16:18:36 -0800 (PST) Received: from gid.co.uk (uucp@localhost) by isbalham.ist.co.uk (8.8.4/8.8.4) with UUCP id AAA03019; Mon, 16 Dec 1996 00:04:03 GMT Date: Mon, 16 Dec 1996 00:03:01 GMT Received: from [194.32.164.2] by seagoon.gid.co.uk; Mon, 16 Dec 1996 00:03:01 GMT X-Sender: rb@194.32.164.1 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: Terry Lambert From: rb@gid.co.uk (Bob Bishop) Subject: Re: vulnerability in new pw suite Cc: proff@iq.org, security@freebsd.org, hackers@freebsd.org Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk At 1:39 pm 15/12/96, Terry Lambert wrote: >Heh. > >Please define "unsafe" in the context of a functional (inaccessible for >pre-salt-based attacks) shadow password system. > >8-) 8-). > >I'm tired of having passwd not let me use whatever password I want, >considering that with a shadow file, the user will have to brute-force >it through /bin/login or equivalent. It seems the harder it becomes to >see my post-encryption password, the more anal the passwd command >becomes about making post-encryption passwords "safe" from attacks >which are impossible to institute unless root has been compromised. Yeah, fine on an isolated machine, but those pesky users also insist on using the same weak password on lots of different systems. So if some sleaze does manage to get root on your system and thus access to your shadow file, five gets you ten the user passwords he can now derive will work on neighbouring systems. -- 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-hackers Sun Dec 15 16:53:37 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id QAA24012 for hackers-outgoing; Sun, 15 Dec 1996 16:53:37 -0800 (PST) Received: from zen.nash.org (nash.pr.mcs.net [204.95.47.72]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id QAA24007 for ; Sun, 15 Dec 1996 16:53:30 -0800 (PST) Received: from zen.nash.org (localhost [127.0.0.1]) by zen.nash.org (8.8.3/8.6.12) with SMTP id SAA00386; Sun, 15 Dec 1996 18:51:04 -0600 (CST) Message-ID: <32B49CF8.41C67EA6@mcs.com> Date: Sun, 15 Dec 1996 18:51:04 -0600 From: Alex Nash X-Mailer: Mozilla 3.01Gold (X11; I; FreeBSD 2.1.6.1-RELEASE i386) MIME-Version: 1.0 To: Terry Lambert CC: Peter Wemm , freebsd-hackers@FreeBSD.ORG Subject: Re: poll(2) References: <199612152053.NAA23897@phaeton.artisoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Terry Lambert wrote: > This would be the modification of the remaining time for a non-null, > non-zero timeval struct? > > You should note that this will not work for much of the software in the > known universe... I think even Linux backed this one out after it caused > problems with ...oh... Netscape. Unless this has changed very recently, I don't think this is true. I just looked at Linux 2.1.5 and it still seems to return time remaining. Peter, if you do change the semantics of select(), you might also want to yank out the extra code in the Linux emulator's select(). Alex From owner-freebsd-hackers Sun Dec 15 17:17:41 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id RAA26202 for hackers-outgoing; Sun, 15 Dec 1996 17:17:41 -0800 (PST) Received: from spinner.DIALix.COM (root@spinner.DIALix.COM [192.203.228.67]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id RAA26171 for ; Sun, 15 Dec 1996 17:17:31 -0800 (PST) Received: from spinner.DIALix.COM (peter@localhost.DIALix.oz.au [127.0.0.1]) by spinner.DIALix.COM (8.8.4/8.8.4) with ESMTP id JAA24385; Mon, 16 Dec 1996 09:16:34 +0800 (WST) Message-Id: <199612160116.JAA24385@spinner.DIALix.COM> X-Mailer: exmh version 1.6.9 8/22/96 To: Terry Lambert cc: freebsd-hackers@freebsd.org Subject: Re: poll(2) In-reply-to: Your message of "Sun, 15 Dec 1996 13:53:59 MST." <199612152053.NAA23897@phaeton.artisoft.com> Date: Mon, 16 Dec 1996 09:16:33 +0800 From: Peter Wemm Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Terry Lambert wrote: > > I did some code to do this about 6 months ago, it's still in my checked > > out -current kernel and still works. I had seen OpenBSD's code (a lot) > > so it's not purely independent, but it is quite different in certain > > areas. While I was there, I got carried away and implemented the feature > > described in the "BUGS" section right at the end of the select(2) man page. > > This would be the modification of the remaining time for a non-null, > non-zero timeval struct? Yes.. > You should note that this will not work for much of the software in the > known universe... I think even Linux backed this one out after it caused > problems with ...oh... Netscape. No... we emulate the copyout for the linux code. They have two select syscalls, the "new" select copies out, the "old" one doesn't. I think the old one is visible as "bsd_select()" in libc, but I'm not 100% sure.. For what it's worth, the entire time that I've been running this code, the only things that broke were "/usr/bin/tail -f" and I vaguely remember suspecting the rpc timeout code in libc. I think there was one other program, but I can't remember what it was. Netscape works fine, as does just about everything else that runs on Linux (which is damn near everything these days) with it's copyout by default. > Terry Lambert > terry@lambert.org Cheers, -Peter From owner-freebsd-hackers Sun Dec 15 17:18:29 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id RAA26341 for hackers-outgoing; Sun, 15 Dec 1996 17:18:29 -0800 (PST) Received: from apolo.biblos.unal.edu.co ([168.176.37.75]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id RAA26309; Sun, 15 Dec 1996 17:18:20 -0800 (PST) Received: from unalmodem.usc.unal.edu.co ([168.176.3.47]) by apolo.biblos.unal.edu.co (8.8.2/8.8.2) with SMTP id UAA04911; Sun, 15 Dec 1996 20:19:11 -0500 (EST) Message-ID: <32B4CCDA.D64@fps.biblos.unal.edu.co> Date: Sun, 15 Dec 1996 20:15:22 -0800 From: "Pedro Giffuni S." Organization: Universidad Nacional de Colombia X-Mailer: Mozilla 3.0 (Win16; I) MIME-Version: 1.0 To: Terry Lambert CC: hackers@freebsd.org, fs@freebsd.org Subject: Re: Other filesystems under FreeBSD References: <199612152211.PAA24071@phaeton.artisoft.com> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Terry Lambert wrote: > > > You also seem a bit confused about what I said, vs. what I meant. > This is probably my fault, so I'll clarify a bit. > Yes I was, thanks for clarifying. > > If you find you have specific questions on implementation that aren't > answered in the Heidemann thesis in the FICUS project directory on > ftp.cs.ucla.edu, or in the book "The Design and Implementation of the > 4.4BSD Operating System", then send me mail. If I don't already > have the answer archived, I will find one for you (the SCO FS's are > rather important; HPFS has been dropped from BT 4.x and so is about > as important as OS/2: not very). > Thanks for the links, the only document I had was the thesis used to implement SYSV under Linux. Paul Monday said there it was easy to implement due to Linuxīs FS structure, so I (incorrectly) assumed Linux was better. My interest in HPFS was due to WinNTīs support for that filesystem (Microsoft also has his hands dirty on that): I am not interested in NTFS, so the decent option seemed HPFS. Both MS and IBM agree that HPFS is better than FAT, but only OS2 can format HPFS, which makes it almost useless. Perhaps before killing by system I should play to convert our FAT to VFAT , that way Iīll learn more in the process (and erase win95). best regards, Pedro. > 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-hackers Sun Dec 15 17:20:27 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id RAA26530 for hackers-outgoing; Sun, 15 Dec 1996 17:20:27 -0800 (PST) Received: from Octopussy.MI.Uni-Koeln.DE (Octopussy.MI.Uni-Koeln.DE [134.95.166.20]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id RAA26473; Sun, 15 Dec 1996 17:19:45 -0800 (PST) Received: from x14.mi.uni-koeln.de (annexr3-16.slip.Uni-Koeln.DE) by Octopussy.MI.Uni-Koeln.DE with SMTP id AA20157 (5.67b/IDA-1.5); Mon, 16 Dec 1996 02:19:38 +0100 Received: (from se@localhost) by x14.mi.uni-koeln.de (8.8.4/8.6.9) id CAA12692; Mon, 16 Dec 1996 02:19:30 +0100 (CET) Message-Id: Date: Mon, 16 Dec 1996 02:19:30 +0100 From: se@FreeBSD.org (Stefan Esser) To: p.richards@elsevier.co.uk (Paul Richards) Cc: se@FreeBSD.org (Stefan Esser), wilko@yedi.iaf.nl (Wilko Bulte), FreeBSD-hackers@FreeBSD.org (FreeBSD hackers list) Subject: Re: Racal Interlan ethernet card: any good? References: <199611302336.AAA25716@yedi.iaf.nl> <57bucec9na.fsf@tees.elsevier.co.uk> X-Mailer: Mutt 0.53 Mime-Version: 1.0 In-Reply-To: <57bucec9na.fsf@tees.elsevier.co.uk>; from Paul Richards on Dec 1, 1996 20:06:01 +0000 Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk On Dec 1, p.richards@elsevier.co.uk (Paul Richards) wrote: > se@FreeBSD.org (Stefan Esser) writes: > > > I've seen them offered for less than $50 (by mail order). > > They should be much better than the NE2000 PCI clones, which > > require port I/O accesses to the on-board SRAM (and cost less > > than $30). > > Where from? I've searched high and low for PCI cards and > can't find them anywhere in the UK mags. ALl ads are for the Dec chips > or NE2000 clones. If I could find one of these cards I'd do some more > work on the driver, like implementing a 32 bit version for a start. Sorry for the late reply. I had to find the information again, myself, and now I just visited the web server that I had in mind ... Try http://www.mint-data.de/rest.html You'll see an "AMD PCnet AM79C970KC Netzwerkkarte" offered for 89DM or $50 + 15% VAT (which you don't have to pay if you buy the card for a company ...) Regards, STefan From owner-freebsd-hackers Sun Dec 15 17:40:06 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id RAA28001 for hackers-outgoing; Sun, 15 Dec 1996 17:40:06 -0800 (PST) Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id RAA27955 for ; Sun, 15 Dec 1996 17:40:00 -0800 (PST) Received: (from msmith@localhost) by genesis.atrad.adelaide.edu.au (8.8.2/8.7.3) id MAA19083; Mon, 16 Dec 1996 12:09:29 +1030 (CST) From: Michael Smith Message-Id: <199612160139.MAA19083@genesis.atrad.adelaide.edu.au> Subject: Re: notebook: which one In-Reply-To: <199612131252.NAA04767@gvr.win.tue.nl> from Guido van Rooij at "Dec 13, 96 01:52:53 pm" To: guido@gvr.win.tue.nl (Guido van Rooij) Date: Mon, 16 Dec 1996 12:09:28 +1030 (CST) Cc: freebsd-hackers@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-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Guido van Rooij stands accused of saying: > I am looking for a notebook that is well supported under FreeBSD. > It should have 16 mb and a decent screen and have either a 0.5 or 1.0 > gigabyte fixed disk. I am particularly interested in which brand is the best > to choose. Well, I'll play my old tune and recommend the older Sharp PC90x0 series (9000/9030/9070, not the 9020 etc.); these systems have served us very well indeed. They're all pentia (100/120/133) with 256K L2 cache, 2 memory slots (8/16/32 per slot), 800x600 displays (passive 8-bit on the 9000, active 16-bit on the others), PCI IDE interfaces etc etc etc. Bear in mind that newer non-bargain systems will almost certainly be CardBus machines, not PCMCIA, and thus you will have to get down and dirty writing drivers for the bus interface if you want to use plugin cards. Sharp's units seem to be pretty good, plenty of people have said nice things about NEC, and modulo some percieved mechanical problems locally (flimsy construction mostly) Toshiba are good too. The new Acer machines are getting a mixed review; in particular they seem to have poor disk performance. > -Guido -- ]] 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-hackers Sun Dec 15 18:02:25 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id SAA29721 for hackers-outgoing; Sun, 15 Dec 1996 18:02:25 -0800 (PST) Received: from odin.thor.net (root@[206.26.114.1]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id SAA29713 for ; Sun, 15 Dec 1996 18:02:21 -0800 (PST) Received: from odin.thor.net (Wolman@async42.thor.net [206.26.114.141]) by odin.thor.net (8.7.4/8.6.9) with SMTP id UAA22430 for ; Sun, 15 Dec 1996 20:06:15 -0600 (CST) Date: Sun, 15 Dec 1996 20:06:15 -0600 (CST) Message-Id: <199612160206.UAA22430@odin.thor.net> X-Sender: wolman@206.26.114.1 X-Mailer: Windows Eudora Pro Version 2.1.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: hackers@FreeBSD.org From: Rich Subject: atapi.flp Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk My FreeBSD manual says that I need to use the file atapi.flp and the atapiflp.bat ti install 2.1.5 with my ide cdrom drive. I have looked on the cd (got it from Owl Creek) For the file and its not there (/floppies). I have also checked numerous ftp sites for it.. Why Cant I find it? Does it exist? Please Help! From owner-freebsd-hackers Sun Dec 15 18:07:05 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id SAA00198 for hackers-outgoing; Sun, 15 Dec 1996 18:07:05 -0800 (PST) Received: from austin.polstra.com (austin.polstra.com [206.213.73.10]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id SAA00191 for ; Sun, 15 Dec 1996 18:07:00 -0800 (PST) Received: from austin.polstra.com (jdp@localhost) by austin.polstra.com (8.8.3/8.8.3) with ESMTP id SAA00330; Sun, 15 Dec 1996 18:06:49 -0800 (PST) Message-Id: <199612160206.SAA00330@austin.polstra.com> To: roberto@keltia.freenix.fr Subject: Re: Fwd: CVSup with SSH Newsgroups: polstra.freebsd.hackers In-Reply-To: References: <199612121657.IAA17705@austin.polstra.com> <199612151539.JAA21675@bonkers.taronga.com> Organization: Polstra & Co., Seattle, WA Cc: hackers@freebsd.org Date: Sun, 15 Dec 1996 18:06:49 -0800 From: John Polstra Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In article roberto@keltia.freenix.fr writes: > ssh compression + CVSup is great. You should turn off compression either in ssh or in CVSup. (Maybe you already did.) If both of them are doing compression, it's just a big waste of CPU cycles. 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-hackers Sun Dec 15 19:41:32 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id TAA04482 for hackers-outgoing; Sun, 15 Dec 1996 19:41:32 -0800 (PST) Received: from novell.com (prv-mail20.Provo.Novell.COM [137.65.40.4]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id TAA04477 for ; Sun, 15 Dec 1996 19:41:30 -0800 (PST) Received: from INET-PRV-Message_Server by novell.com with Novell_GroupWise; Sun, 15 Dec 1996 20:40:51 -0700 Message-Id: X-Mailer: Novell GroupWise 4.1 Date: Sun, 15 Dec 1996 20:40:17 -0700 From: Darren Davis To: msmith@atrad.adelaide.edu.au, joerg_wunsch@uriah.heep.sax.de Cc: freebsd-hackers@freebsd.org Subject: Re: Novell offers free NDS, just a thought... -Reply Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I am not certain what all the details of the NDS license is all about. I suspect there would be some restrictions to the distribution of the source, but who knows? Novell may suprise even me! I will see what I can find out. Darren R. Davis Senior Software Engineer Novell, Inc. From owner-freebsd-hackers Sun Dec 15 19:46:37 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id TAA04735 for hackers-outgoing; Sun, 15 Dec 1996 19:46:37 -0800 (PST) Received: from deceased.hb.north.de (deceased.hb.north.de [194.94.232.249]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id TAA04724 for ; Sun, 15 Dec 1996 19:46:34 -0800 (PST) Received: from jelal.hb.north.de by deceased.hb.north.de with uucp (Smail3.2) id m0vZU0E-0016CFC; Mon, 16 Dec 1996 04:46:06 +0100 (MET) Received: by jelal.hb.north.de (SMail-ST 0.95gcc/2.5+) id AA00699; Mon, 16 Dec 1996 04:44:42 +0100 (CET) Received: (from nox@localhost) by saturn.hb.north.de (8.7.5/8.7.3) id EAA02143; Mon, 16 Dec 1996 04:41:28 +0100 (MET) From: Juergen Lock Message-Id: <199612160341.EAA02143@saturn.hb.north.de> Subject: ping o'death, variation on a theme... and less deadly things (bisdn) To: isdn@muc.ditec.de Date: Mon, 16 Dec 1996 04:41:28 +0100 (MET) Cc: hackers@freebsd.org 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 X-Loop: FreeBSD.org Precedence: bulk And you thoght BSD's ip is immune to those right? :) I still haven't got around tracking this down further but here is what happens: 2.1.6-stable kernel with bisdn-0.97 and bpf, start tcpdump -i ipi0 then send it a 32k ping from the other end (a dos ka9q + ispa in this case). you see the fragments coming in and then it dies, apparently having overwritten the stack trying to copy the entire(?) outgoing packet to bpf. Also the bisdntrc didnt start properly with the included start_if script, this is what i'm using now: (and its running just perfect as long as i leave bpf alone. i like it!) Index: sys-i386-isa/teles.c @@ -563,6 +563,10 @@ chan_t *chan = &sc->sc_chan[c]; caddr_t hscx = chan->hscx; + /* tel_init gets called from all over the place. We don't want an */ + /* interrupt to occur in the middle of changing these pointers */ + /* mask all interrupts */ + (*sc->put)(hscx, 0x20, 0xff); /* MASK */ if (chan->obuf) m_freem(chan->obuf); if (chan->ibuf) Index: sys-bisdn/b_isdnipi.c @@ -444,6 +444,7 @@ register struct mbuf *m1 = m; register u_char *cp = bpfbuf; + u_int left = sizeof(bpfbuf) - 4; u_int af = dst->sa_family; /* prepend the address family to bpf buffer */ @@ -455,10 +456,12 @@ { register int mlen = m1->m_len; + if (mlen > left) + mlen = left; bcopy(mtod(m1, caddr_t), cp, mlen); cp += mlen; len += mlen; - } while((m1 = m1->m_next) != NULL); + } while((m1 = m1->m_next) != NULL && left > 0); } #endif /* NBPFILTER */ Index: bisdntrc/bisdntrc.c @@ -148,7 +148,23 @@ } } +#if 1 + if((setvbuf(stdout, (char *)NULL, _IOLBF, 0)) != 0) + { + char buffer[80]; + + sprintf(buffer, "Error setting stdout to line-buffered"); + perror(buffer); + exit(1); + } + if (signal(SIGHUP, catchsig) == SIG_IGN) { + /* write(1, "signal(SIGHUP, SIG_IGN)\n", + sizeof "signal(SIGHUP, SIG_IGN)\n" - 1); */ + signal(SIGHUP, SIG_IGN); + }; +#else (void) signal(SIGHUP, catchsig); +#endif (void) signal(SIGTERM, catchsig); (void) signal(SIGKILL, catchsig); (void) signal(SIGINT, catchsig); Index: etc/start_if.ipi0 @@ -1,3 +1,4 @@ +#! /bin/sh #--------------------------------------------------------------------------- # # /etc/start_if.ipi0 - startup script for bisdn daemon @@ -10,7 +11,8 @@ # output device for fullscreen mode out_dev=/dev/ttyv6 # terminal type for fullscreen mode -out_typ=pcvt25h +#out_typ=pcvt25h +out_typ=cons25 # enable lowlevel ISDN tracing isdn_trace=YES @@ -18,10 +20,10 @@ echo '---------- enter /etc/start_if.ipi0 -----------------------------------' -if [ -f /etc/rc.ipfw ] -then - sh /etc/rc.ipfw -fi +#if [ -f /etc/rc.ipfw ] +#then +# sh /etc/rc.ipfw +#fi # start the isdn daemon if [ -x /usr/local/bin/bisdnd ] @@ -36,7 +38,8 @@ if [ -x /usr/local/bin/bisdntrc -a X${isdn_trace} = X"YES" ] then echo 'starting ISDN tracing ...' - nohup /usr/local/bin/bisdntrc -n4 -r -o/tmp/isdn.trace >/dev/null 2>&1 & + #nohup /usr/local/bin/bisdntrc -n4 -r -o/tmp/isdn.trace >/dev/null 2>&1 & + (cd /etc/bisdn; sh -c 'nohup /usr/local/bin/bisdntrc -n4 -r >>/var/log/bisdn/isdn.trace 2>&1 &') sleep 1 fi thanx + cheers, Juergen From owner-freebsd-hackers Sun Dec 15 20:28:49 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id UAA05935 for hackers-outgoing; Sun, 15 Dec 1996 20:28:49 -0800 (PST) Received: from cliff.cris.com (cliff.cris.com [199.3.12.45]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id UAA05930 for ; Sun, 15 Dec 1996 20:28:46 -0800 (PST) Received: from larknor-ii (cnc111042.concentric.net [206.173.46.42]) by cliff.cris.com (8.8.3/(96/11/08 1.11)) id XAA01146; Sun, 15 Dec 1996 23:28:42 -0500 (EST) [1-800-745-2747 The Concentric Network] Message-Id: <199612160428.XAA01146@cliff.cris.com> Comments: Authenticated sender is From: "Rafael Portales" To: hackers@freebsd.org Date: Sun, 15 Dec 1996 23:29:51 +0500 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: FreeBSD and Hitachi IDE CD-ROM drive... Reply-to: raf1@cris.com CC: gsieb@cris.com Priority: normal X-mailer: Pegasus Mail for Win32 (v2.42a) Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi, We have recently purchased a copy of FreeBSD 2.1.5 on CD-ROM from Walnut Creek Publishing. I have a Hitachi IDE CD-ROM drive and it seems that my drive isn't supported with 2.1.5? I know I can copy the \dists\bin directory off the CD-ROM and run an install off of my 1st hard drive (I'm installing FreeBSD on my second hard drive), but I'm concerned about support for my CD-ROM drive. I have heard that 2.1.6 will support most IDE CD-ROM drives, but kind of blanch at the thought of downloading that much over my 28.8 modem --I'm sure you understand :}. Is there any way that I can install 2.1.5 and "upgrade" to 2.1.6 without needing tons and tons of HD space? Or should I go ahead, install 2.1.5 and then download 2.1.6 and install over it? Thank you in advance for your help. Glenn Sieb / Rafael Portales From owner-freebsd-hackers Sun Dec 15 20:53:19 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id UAA06580 for hackers-outgoing; Sun, 15 Dec 1996 20:53:19 -0800 (PST) Received: from austin.polstra.com (austin.polstra.com [206.213.73.10]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id UAA06575 for ; Sun, 15 Dec 1996 20:53:16 -0800 (PST) Received: from austin.polstra.com (jdp@localhost) by austin.polstra.com (8.8.3/8.8.3) with ESMTP id UAA01018 for ; Sun, 15 Dec 1996 20:53:15 -0800 (PST) Message-Id: <199612160453.UAA01018@austin.polstra.com> To: freebsd-hackers@freebsd.org Subject: Warning: src-release and src-tools collections to be removed Date: Sun, 15 Dec 1996 20:53:15 -0800 From: John Polstra Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I've been working on organizing a unified setup for all of the FreeBSD CVSup mirror sites. In the process, I noticed that the obsolete "src-release" and "src-tools" collections still exist. Everything in these collections is already provided by the "src-etc" collection. If you have been CVSup/supping "src-release" or "src-tools", please change your supfile and get "src-etc" instead. I am going to delete the two obsolete collections within a few days. -- John Polstra jdp@polstra.com John D. Polstra & Co., Inc. Seattle, Washington USA "Self-knowledge is always bad news." -- John Barth From owner-freebsd-hackers Sun Dec 15 21:40:47 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id VAA08128 for hackers-outgoing; Sun, 15 Dec 1996 21:40:47 -0800 (PST) Received: from rover.village.org (rover.village.org [204.144.255.49]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id VAA08108; Sun, 15 Dec 1996 21:40:42 -0800 (PST) Received: from rover.village.org [127.0.0.1] by rover.village.org with esmtp (Exim 0.56 #1) id E0vZVj9-00049U-00; Sun, 15 Dec 1996 22:36:35 -0700 To: Terry Lambert Subject: Re: vulnerability in new pw suite Cc: dreamer@garrison.inetcan.net (Digital Dreamer), rb@gid.co.uk, proff@iq.org, security@freebsd.org, hackers@freebsd.org In-reply-to: Your message of "Sun, 15 Dec 1996 16:36:04 MST." <199612152336.QAA00213@phaeton.artisoft.com> References: <199612152336.QAA00213@phaeton.artisoft.com> Date: Sun, 15 Dec 1996 22:36:35 -0700 From: Warner Losh Message-Id: Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In message <199612152336.QAA00213@phaeton.artisoft.com> Terry Lambert writes: : Fool! Your machine is not safe... all ninjas worth their salt carry : extra ST-506 controllers! Do you know nothing of Tai-Kwan Leap? And to Terry Lambert, I leave a boot to the head... :-) Warner "I learned Tai-Kwan Leap to kick some bootie" Losh From owner-freebsd-hackers Sun Dec 15 22:04:31 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id WAA08815 for hackers-outgoing; Sun, 15 Dec 1996 22:04:31 -0800 (PST) Received: from mexico.brainstorm.eu.org (root@mexico.brainstorm.fr [193.56.58.253]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id WAA08808 for ; Sun, 15 Dec 1996 22:04:28 -0800 (PST) Received: from brasil.brainstorm.eu.org (brasil.brainstorm.fr [193.56.58.33]) by mexico.brainstorm.eu.org (8.7.5/8.7.3) with ESMTP id HAA30935 for ; Mon, 16 Dec 1996 07:04:15 +0100 Received: (from uucp@localhost) by brasil.brainstorm.eu.org (8.6.12/8.6.12) with UUCP id HAA16416 for hackers@freebsd.org; Mon, 16 Dec 1996 07:03:55 +0100 Received: (from roberto@localhost) by keltia.freenix.fr (8.8.4/keltia-uucp-2.9) id GAA08797; Mon, 16 Dec 1996 06:37:05 +0100 (CET) Message-ID: Date: Mon, 16 Dec 1996 06:37:04 +0100 From: roberto@keltia.freenix.fr (Ollivier Robert) To: hackers@freebsd.org Subject: Re: Fwd: CVSup with SSH References: <199612121657.IAA17705@austin.polstra.com> <199612151539.JAA21675@bonkers.taronga.com> <199612160206.SAA00330@austin.polstra.com> X-Mailer: Mutt 0.54 Mime-Version: 1.0 X-Operating-System: FreeBSD 3.0-CURRENT ctm#2815 In-Reply-To: <199612160206.SAA00330@austin.polstra.com>; from John Polstra on Dec 15, 1996 18:06:49 -0800 Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk According to John Polstra: > You should turn off compression either in ssh or in CVSup. (Maybe you > already did.) If both of them are doing compression, it's just a big > waste of CPU cycles. I've turn off the compression in CVSup. -- Ollivier ROBERT -=- The daemon is FREE! -=- roberto@keltia.freenix.fr FreeBSD keltia.freenix.fr 3.0-CURRENT #31: Tue Dec 3 23:52:58 CET 1996 From owner-freebsd-hackers Sun Dec 15 22:38:09 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id WAA09957 for hackers-outgoing; Sun, 15 Dec 1996 22:38:09 -0800 (PST) Received: from alpha.xerox.com (alpha.Xerox.COM [13.1.64.93]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id WAA09952 for ; Sun, 15 Dec 1996 22:38:06 -0800 (PST) Received: from crevenia.parc.xerox.com ([13.2.116.11]) by alpha.xerox.com with SMTP id <16904(2)>; Sun, 15 Dec 1996 22:37:35 PST Received: from localhost by crevenia.parc.xerox.com with SMTP id <177711>; Sun, 15 Dec 1996 22:37:27 -0800 To: Marc Slemko cc: hackers@freebsd.org Subject: Re: TCP FIN/ACK storm oddity In-reply-to: Your message of "Wed, 11 Dec 96 16:45:49 PST." Date: Sun, 15 Dec 1996 22:37:19 PST From: Bill Fenner Message-Id: <96Dec15.223727pst.177711@crevenia.parc.xerox.com> Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Sounds like what Peter Wemm saw in PR kern/1940. Can you replicate the exchange from the second message, but use "tcpdump -S" so that tcpdump doesn't try to be smart about the sequence numbers? A "tcpdump -w" might be even better. Bill From owner-freebsd-hackers Sun Dec 15 22:43:21 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id WAA10201 for hackers-outgoing; Sun, 15 Dec 1996 22:43:21 -0800 (PST) Received: from alpha.xerox.com (alpha.Xerox.COM [13.1.64.93]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id WAA10196 for ; Sun, 15 Dec 1996 22:43:18 -0800 (PST) Received: from crevenia.parc.xerox.com ([13.2.116.11]) by alpha.xerox.com with SMTP id <16651(2)>; Sun, 15 Dec 1996 22:42:47 PST Received: from localhost by crevenia.parc.xerox.com with SMTP id <177711>; Sun, 15 Dec 1996 22:42:42 -0800 To: Charles Henrich cc: freebsd-hackers@freebsd.org Subject: Re: Intelligent source IP's in multinet singlephysicalnet connections? In-reply-to: Your message of "Mon, 09 Dec 96 19:21:08 PST." <199612100321.WAA25837@crh.cl.msu.edu> Date: Sun, 15 Dec 1996 22:42:32 PST From: Bill Fenner Message-Id: <96Dec15.224242pst.177711@crevenia.parc.xerox.com> Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Stupid question, but what version of FreeBSD are you running? There's a bug in 2.1.x that ARP requests get sent with the last address assigned to the interface, as opposed to the applicable address on the interface. Bill From owner-freebsd-hackers Mon Dec 16 01:24:22 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id BAA14285 for hackers-outgoing; Mon, 16 Dec 1996 01:24:22 -0800 (PST) Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id BAA14276 for ; Mon, 16 Dec 1996 01:24:15 -0800 (PST) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id KAA07949; Mon, 16 Dec 1996 10:23:15 +0100 Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id KAA10536; Mon, 16 Dec 1996 10:23:14 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.8.4/8.6.9) id KAA06597; Mon, 16 Dec 1996 10:19:53 +0100 (MET) From: J Wunsch Message-Id: <199612160919.KAA06597@uriah.heep.sax.de> Subject: Re: FreeBSD and Hitachi IDE CD-ROM drive... To: freebsd-hackers@freebsd.org (FreeBSD hackers) Date: Mon, 16 Dec 1996 10:19:53 +0100 (MET) Cc: raf1@cris.com, gsieb@cris.com Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199612160428.XAA01146@cliff.cris.com> from Rafael Portales at "Dec 15, 96 11:29:51 pm" 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 X-Mailer: ELM [version 2.4ME+ PL17 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk As Rafael Portales wrote: > I have heard that 2.1.6 will support most IDE CD-ROM drives, but kind > of blanch at the thought of downloading that much over my 28.8 modem > --I'm sure you understand :}. Sorry, you have heard wrong. It's 2.2 that has the much better ATAPI driver. You can however download just the installation floppy, and see whether it's willing to work with your drive. (You have to explicitly hit the button before it will destroy anything, so don't worry.) Simply boot it, then Alt-F2, and look whether sysinstall announces that it's found a device of type CD-ROM. -- 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 Mon Dec 16 01:25:49 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id BAA14381 for hackers-outgoing; Mon, 16 Dec 1996 01:25:49 -0800 (PST) Received: from labinfo.iet.unipi.it (labinfo.iet.unipi.it [131.114.9.5]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id BAA14371 for ; Mon, 16 Dec 1996 01:25:39 -0800 (PST) Received: from localhost (luigi@localhost) by labinfo.iet.unipi.it (8.6.5/8.6.5) id JAA00321; Mon, 16 Dec 1996 09:41:54 +0100 From: Luigi Rizzo Message-Id: <199612160841.JAA00321@labinfo.iet.unipi.it> Subject: Re: A question on diskless boot To: phk@critter.tfs.com (Poul-Henning Kamp) Date: Mon, 16 Dec 1996 09:41:53 +0100 (MET) Cc: hackers@freebsd.org In-Reply-To: <9207.850642949@critter.tfs.com> from "Poul-Henning Kamp" at Dec 15, 96 10:42:10 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > There is some preliminary support for PCI devices, but probably only > for NE2000 kind of stuff in the netboot code. I've never heard from > anybody if it even works. yes, I wrote it for my bridge code (available from my home page) and then ported it to the netboot code. About its status: it works with some combinations of motherboards/ethernet cards, but not with others. Apparently there are different levels of compliance to the PCI specs, at least for the detection of boot ROMs. ... > > Finally, you may want to try to see if you can get any kind > of boot-proms for the de0 cards, and use whatever method they > use to get live. the ones I have don't even have a socket :(! Luigi -----------------------------+-------------------------------------- Luigi Rizzo | Dip. di Ingegneria dell'Informazione email: luigi@iet.unipi.it | Universita' di Pisa tel: +39-50-568533 | via Diotisalvi 2, 56126 PISA (Italy) fax: +39-50-568522 | http://www.iet.unipi.it/~luigi/ _____________________________|______________________________________ From owner-freebsd-hackers Mon Dec 16 01:31:10 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id BAA14670 for hackers-outgoing; Mon, 16 Dec 1996 01:31:10 -0800 (PST) Received: from tfs.com (tfs.com [140.145.250.1]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id BAA14665 for ; Mon, 16 Dec 1996 01:31:08 -0800 (PST) Received: from critter.tfs.com by tfs.com (smail3.1.28.1) with SMTP id m0vZZNH-0003vxC; Mon, 16 Dec 96 01:30 PST Received: from critter.tfs.com (localhost.phk.dk [127.0.0.1]) by critter.tfs.com (8.8.2/8.8.2) with ESMTP id KAA11421; Mon, 16 Dec 1996 10:33:23 +0100 (MET) To: Luigi Rizzo cc: hackers@freebsd.org Subject: Re: A question on diskless boot In-reply-to: Your message of "Mon, 16 Dec 1996 09:41:53 +0100." <199612160841.JAA00321@labinfo.iet.unipi.it> Date: Mon, 16 Dec 1996 10:33:22 +0100 Message-ID: <11419.850728802@critter.tfs.com> From: Poul-Henning Kamp Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In message <199612160841.JAA00321@labinfo.iet.unipi.it>, Luigi Rizzo writes: >> >> Finally, you may want to try to see if you can get any kind >> of boot-proms for the de0 cards, and use whatever method they >> use to get live. > >the ones I have don't even have a socket :(! That pretty much settles it I guess... -- 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-hackers Mon Dec 16 03:39:51 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id DAA20301 for hackers-outgoing; Mon, 16 Dec 1996 03:39:51 -0800 (PST) Received: from time.cdrom.com (time.cdrom.com [204.216.27.226]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id DAA20291 for ; Mon, 16 Dec 1996 03:39:46 -0800 (PST) Received: from time.cdrom.com (localhost [127.0.0.1]) by time.cdrom.com (8.8.4/8.6.9) with ESMTP id DAA04291; Mon, 16 Dec 1996 03:39:40 -0800 (PST) To: Rich cc: hackers@FreeBSD.org Subject: Re: atapi.flp In-reply-to: Your message of "Sun, 15 Dec 1996 20:06:15 CST." <199612160206.UAA22430@odin.thor.net> Date: Mon, 16 Dec 1996 03:39:40 -0800 Message-ID: <4288.850736380@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk atapi.flp is dead - it was merged into boot.flp. root.flp is dead too. > My FreeBSD manual says that I need to use the file atapi.flp and the > atapiflp.bat ti install 2.1.5 with my ide cdrom drive. I have looked on the > cd (got it from Owl Creek) For the file and its not there (/floppies). I > have also checked numerous ftp sites for it.. Why Cant I find it? Does it exi st? > Please Help! > From owner-freebsd-hackers Mon Dec 16 04:54:57 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id EAA25692 for hackers-outgoing; Mon, 16 Dec 1996 04:54:57 -0800 (PST) Received: from eel.dataplex.net (eel.dataplex.net [208.2.87.2]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id EAA25685 for ; Mon, 16 Dec 1996 04:54:55 -0800 (PST) Received: from [208.2.87.4] (cod [208.2.87.4]) by eel.dataplex.net (8.7.5/8.7.3) with ESMTP id GAA23658; Mon, 16 Dec 1996 06:55:00 -0600 (CST) X-Sender: rkw@mail.dataplex.net Message-Id: In-Reply-To: <199612160428.XAA01146@cliff.cris.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 16 Dec 1996 06:53:44 -0600 To: raf1@cris.com From: Richard Wackerbarth Subject: Re: FreeBSD and Hitachi IDE CD-ROM drive... Cc: hackers@freebsd.org Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >Is there any way that I can install 2.1.5 and "upgrade" to 2.1.6 >without needing tons and tons of HD space? Or should I go ahead, >install 2.1.5 and then download 2.1.6 and install over it? The only "incremental" thing that you can do is to produce 2.1.6 from the sources. To do this, you should use either CTM or CVSup. The baseline of the source is on the 2nd CD. The CTM updates can be found on ftp.freebsd.org (and mirrors) under FreeBSD-stable. If you want to use CVSup, first download the current version of it. Unfortunately, both of these solutions require a significant amount of HD. However, HD is not all that expensive and 500Meg+ would be a good investment. From owner-freebsd-hackers Mon Dec 16 05:33:09 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id FAA29563 for hackers-outgoing; Mon, 16 Dec 1996 05:33:09 -0800 (PST) Received: from www.hsc.wvu.edu (www.hsc.wvu.edu [157.182.105.122]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id FAA29556 for ; Mon, 16 Dec 1996 05:33:06 -0800 (PST) Received: (from jsigmon@localhost) by www.hsc.wvu.edu (8.7.5/8.7.3) id IAA27393; Mon, 16 Dec 1996 08:32:58 -0500 (EST) Date: Mon, 16 Dec 1996 08:32:57 -0500 (EST) From: Jeremy Sigmon To: "Jordan K. Hubbard" cc: hackers@freebsd.org Subject: Re: atapi.flp In-Reply-To: <4288.850736380@time.cdrom.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > atapi.flp is dead - it was merged into boot.flp. > root.flp is dead too. ln -s atapi.flp boot.flp :) I see this question alot. Is the handbook ever going to be reprinted? I would assume so after the current supply runs low. From owner-freebsd-hackers Mon Dec 16 05:43:36 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id FAA01176 for hackers-outgoing; Mon, 16 Dec 1996 05:43:36 -0800 (PST) Received: from palrel1.hp.com (palrel1.hp.com [15.253.72.10]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id FAA01165 for ; Mon, 16 Dec 1996 05:43:33 -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 FAA02019; Mon, 16 Dec 1996 05:43:27 -0800 (PST) Received: from localhost by fakir.india.hp.com with SMTP (1.37.109.16/15.5+ECS 3.3) id AA106675713; Mon, 16 Dec 1996 19:15:13 +0500 Message-Id: <199612161415.AA106675713@fakir.india.hp.com> To: Terry Lambert Cc: freebsd-hackers@freefall.freebsd.org Subject: Heidemann Framework integration (Re: Other filesystems under FreeBSD) In-Reply-To: Your message of "Sun, 15 Dec 1996 15:11:35 MST." <199612152211.PAA24071@phaeton.artisoft.com> Date: Mon, 16 Dec 1996 19:15:13 +0500 From: A JOSEPH KOSHY Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >>>> "tl" == "Terry Lambert" said: tl> FreeBSD is well suited to other file systems. What I was discussing tl> was a number of small changes to the mechanism to seperate the tl> implementation from the instantiation. Basically, I wanted to be tl> able to simplify the code I needed to write to write a new FS, even tl> more than it is already simplified over that for Linux. This is not tl> the same thing as the code being impossible without the changes, tl> only "more difficult than it would be in Terry's ideal world". Do we have any plans of integrating the Heidemann framework more completely into the 3.0 development tree? IMO this would be a good idea. Koshy From owner-freebsd-hackers Mon Dec 16 05:55:17 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id FAA02619 for hackers-outgoing; Mon, 16 Dec 1996 05:55:17 -0800 (PST) Received: from mailgate.so-net.or.jp (mailgate.so-net.or.jp [202.238.95.22]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id FAA02599 for ; Mon, 16 Dec 1996 05:55:14 -0800 (PST) Received: from mail.ca2.so-net.or.jp (mail.ca2.so-net.or.jp [202.238.95.34]) by mailgate.so-net.or.jp (8.7.5/3.4W396121217) with ESMTP id WAA21379; Mon, 16 Dec 1996 22:55:11 +0900 (JST) Received: from chiota.signet.or.jp (ppp912a.pppp.ap.so-net.or.jp [210.132.145.42]) by mail.ca2.so-net.or.jp (8.7.3/3.4W396110722) with ESMTP id WAA20754; Mon, 16 Dec 1996 22:55:08 +0900 (JST) Received: from localhost (localhost [127.0.0.1]) by chiota.signet.or.jp (8.7.5/) with SMTP id WAA01012; Mon, 16 Dec 1996 22:55:26 +0900 (JST) Message-Id: <199612161355.WAA01012@chiota.signet.or.jp> To: hackers@freebsd.org Cc: shigio@wafu.netgate.net Subject: GLOBAL-1.5 for FreeBSD(2.0.5R, 2.1.0R, 2.1.5R) Date: Mon, 16 Dec 1996 22:55:25 +0900 From: Shigio Yamaguchi Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hello, this is Yamaguchi. GLOBAL-1.5 for FreeBSD(2.0.5R, 2.1.0R, 2.1.5R) is available in: http://wafu.netgate.net/tama/unix/indexe.html = (Don't forget this 'e'.) What's New since 1.4. o Hyper text generator is available. (Sample output of hyper text is in above site. Please try it.) o Some bugs fixed. If you cannot get the file, please send me (shigio@wafu.netgate.net) E-mail. --------------------------------------------------------------------------- Global is a tool which find the locations of function definitions and functions references in C source files. It supports following environments. o shell command line o vi editor o web browser I think it is useful to hack a large project containing many subdirectories like MH, X or BSD kernel. [Features] o Global can find the locations of specified function quickly. o Global can locate not only function definitions but also function references o Global can treat a source tree containing subdirectories and you can get a relative path of object from anywhere within the tree. o Global allow duplicate entries. o Global can understand perl's regular expression. o Global can also locate functions in library paths if the function not found in your source directory. o Global can treat yacc file too. Please enjoy. -- Shigio Yamaguchi E-Mail: shigio@wafu.netgate.net Home Page: http://wafu.netgate.net/tama/ From owner-freebsd-hackers Mon Dec 16 06:01:20 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id GAA03417 for hackers-outgoing; Mon, 16 Dec 1996 06:01:20 -0800 (PST) Received: from hq.icb.chel.su (hq.icb.chel.su [193.125.10.33]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id GAA03360 for ; Mon, 16 Dec 1996 06:00:43 -0800 (PST) Received: (babkin@localhost) by hq.icb.chel.su (8.8.3/8.6.5) id SAA10516; Mon, 16 Dec 1996 18:59:59 +0500 (ESK) From: "Serge A. Babkin" Message-Id: <199612161359.SAA10516@hq.icb.chel.su> Subject: Digiboard: anyone wants to try the new patches for -current ? To: hackers@freebsd.org Date: Mon, 16 Dec 1996 18:59:59 +0500 (ESK) Cc: helg@tav.kiev.ua, max@hawk.rnd.runnet.ru X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi! Finally I have completed the (mostly cosmetical) changes to merge the improvements from 2.1.5 driver into -current. Does anyone want to try them (I do not have a Digi now) ? BTW, there is one change that must significantly lower the overhead of reading data from card. -SB From owner-freebsd-hackers Mon Dec 16 06:29:53 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id GAA06968 for hackers-outgoing; Mon, 16 Dec 1996 06:29:53 -0800 (PST) Received: from mailhost4.BayNetworks.COM (lobster.corpeast.baynetworks.com [192.32.253.3]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id GAA06955 for ; Mon, 16 Dec 1996 06:29:50 -0800 (PST) Received: from pobox.BayNetworks.com (pobox [192.32.151.199]) by mailhost4.BayNetworks.COM (8.8.3/BNET-96/12/06-E) with SMTP id JAA08304 Posted-Date: Mon, 16 Dec 1996 09:32:36 -0500 (EST) Received: from tuva.engeast.baynetworks.com by pobox.BayNetworks.com (SMI-8.6/SMI-SVR4) id JAA26925; Mon, 16 Dec 1996 09:27:52 -0500 Received: from tuva.engeast.baynetworks.com (localhost [127.0.0.1]) by tuva.engeast.baynetworks.com (8.7.5/8.7.3) with ESMTP id JAA13086; Mon, 16 Dec 1996 09:27:49 -0500 (EST) Message-Id: <199612161427.JAA13086@tuva.engeast.baynetworks.com> X-Mailer: exmh version 1.6.7 5/3/96 To: Christoph Kukulies cc: bwithrow@BayNetworks.COM (Robert Withrow), hackers@FreeBSD.org Subject: Re: Objdump for 2.1.5 or 2.1.6? In-reply-to: Your message of "Wed, 27 Nov 1996 10:00:23 +0100." <199611270900.KAA02981@gilberto.physik.rwth-aachen.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 16 Dec 1996 09:27:48 -0500 From: Robert Withrow Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk A long time ago you said: kuku@gilberto.physik.rwth-aachen.de said: :- Look into freefall/incoming. I've put up there some binutils binaries :- (compiled fro 2.2-current) but thet oughta work under 2.1.6 as well. Do you have patches? -- Robert Withrow -- (+1 508 436 8256) BWithrow@BayNetworks.com From owner-freebsd-hackers Mon Dec 16 06:53:05 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id GAA10176 for hackers-outgoing; Mon, 16 Dec 1996 06:53:05 -0800 (PST) Received: from bugs.us.dell.com (bugs.us.dell.com [143.166.169.147]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id GAA10161 for ; Mon, 16 Dec 1996 06:53:00 -0800 (PST) Received: from ant.us.dell.com (ant.us.dell.com [198.64.66.34]) by bugs.us.dell.com (8.6.12/8.6.12) with SMTP id IAA16298; Mon, 16 Dec 1996 08:50:03 -0600 Message-Id: <3.0.1.32.19961216085001.0067ee14@bugs.us.dell.com> X-Sender: tony@bugs.us.dell.com X-Mailer: Windows Eudora Light Version 3.0.1 beta 4 (32) Date: Mon, 16 Dec 1996 08:50:04 -0500 To: Terry Lambert From: Tony Overfield Subject: Boot loader hacks was: Re: MAXMEM Cc: eivind@dimaga.com, hackers@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk At 01:41 PM 12/15/96 -0700, Terry Lambert wrote: >> There are standardized BIOS calls to obtain the correct amount of >> memory, even when it exceeds 65 MB. I think the boot loader should >> make these BIOS calls and pass the correct information to the kernel. > >Go ahead and add it. Make sure the boot code doesn't grow over >the 8k limit imposed on it by the fact that there isn't any more >space between the start of the BSD area on the disk and the disklabel >on everyone's hardrives for several years now... > > Regards, > Terry Lambert > terry@lambert.org >--- >Any opinions in this posting are my own and not those of my present >or previous employers. I think that boot2 can only be 7 KB. Even so, there seems to be plenty of space to do this. So I started hacking on FreeBSD. (There should be a mailing list for this kind of thing.) My first quick attempt, which still needs improvement, though it works fine on my 96 MB system :-), adds about 160 bytes of bloat to boot2 to bring it from 6576 to 6736 bytes. I only coded in the E820h function, and not the E801h function, since E820h is the harder one. There's still over 400 bytes left for more stuff! My code doesn't fully comprehend the E820h call, it just looks for any valid system memory descriptor that starts at 1 MB and it takes that one. Extra code to merge in overlaps and adjacencies would consume several more bytes :-(. Ironically, it looks like fully generalizing the function to pass the entire table of information to the kernel for processing would probably be smaller. Unfortunately, if (bootinfo.bi_extmem != biosextmem) printf("BIOS extmem (%ldK) != RTC extmem (%dK)\n", bootinfo.bi_extmem, biosextmem); this code in machdep.c complains about my boot loader patches but doesn't choose the bigger value. Does anyone know why the comment, "Prefer the RTC value for extended memory." appears near this code? Well I didn't, so I added these lines right afterwards: if (bootinfo.bi_extmem > biosextmem) biosextmem = bootinfo.bi_extmem; I can send diffs if anybody wants them. I'm not very proud of how I drew the line between the .c and the .S code, so I didn't put them up here in front of everybody. - Tony From owner-freebsd-hackers Mon Dec 16 07:56:34 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id HAA13890 for hackers-outgoing; Mon, 16 Dec 1996 07:56:34 -0800 (PST) Received: from ccr.dsi.uanl.mx (ccr.dsi.uanl.mx [148.234.15.4]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id HAA13885; Mon, 16 Dec 1996 07:56:31 -0800 (PST) Date: Mon, 16 Dec 1996 07:56:31 -0800 (PST) Message-Id: <199612161556.HAA13885@freefall.freebsd.org> Received: from RAMCLUB43.dsi.uanl.mx ([148.234.25.97]) by ccr.dsi.uanl.mx (MX V4.2 VAX) with SMTP; Mon, 16 Dec 1996 09:56:28 CST6 X-Sender: engarcia@ccr.dsi.uanl.mx X-Mailer: Windows Eudora Light Version 1.5.2 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: hackers@freebsd.org, bugs@freebsd.orgs, questions@freebsd.org From: Dirk Hans Krakaur Floranes Subject: SOS for a Freebsd instalation Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk ok, this is a bigone so readit if you have time... this is a (REAL) history of a friend of my called johny 5 and its obsesion whit a failed intent of installing freebsd 2.1.5. like 4 months ago jonhy and a freind called jimbo, tried to install freebsd 2.1.5 in the jimbo's "pentium-166-16-ram-1.6-gigabyte-windows-95-equiped" computer... they didnt have enougth money to bougth the cd so they downloded the system from one of the ftp of freebsd.org in brazil. they downloaded the boot4.flp fixit.flp and all the /bin subdirectory and for some reason the boot.flp didnt function so they used the boot4.flp and evrythings was going so far so good until they discover thath didnt have space for another partition.. they didn't know of the fips utility so after a week they get 23 diskettes & backup all in the backup was all the bin.?? files and some of the information that jimbo didnt want to loose... so they runed again the boot.flp that they already have rawrite in a disk.. the from the partitions utility in the novice window of the installation program they erased all of the dos partition and then settled 300 megabytes for a partition of freebsd... then they reiniciated formated the rest of the disk installed installed windows 95 filesystem only from a boot disk with the A:> sys c: command , and with A:>pkunzip -d freebsd.zip c: they restored the backup then they formated all the 20 diskettes whit the C:>format a: /u they was specialy carefull in that none of it had a bad cluster or something in this case they used another... all the diskettes was perfect and formated so they created the bin subdirectory in each one and copied in it the bin files. 5 bin in each one... exactly like the instalation.txt indicates evrything was going well and they was very (i mean very) ilusioneted, motivated, all this proccess took like five or 6 hours since the begging until then... then the bug came out... it was the worst thing that you could imagine. the most frustrating one. all the installation process was going well... the partition, the labeling / they read it all the menus so they worked well whit evrything in the media the chosee flopy disks set in the distribution the one marked as bin. and then it happen evrything was going well until the menu "please insert the flopy disk" they inserted the first diskette whit the A:\BIN\BIN.AA A:\BIN\BIN.AB A:\BIN\BIN.AC A:\BIN\BIN.AD A:\BIN\BIN.AE files in the drive and then hit the enter whit sweat int he face and the heart pumping. and a menu that says "Couldn't extract the following distributions this maybe becouse they were not available on the instalation media you have chosen" bin they were fully determined so they tried evrything from changing the directory of a:\bin to a:\dist & then to a:\dist\bin, a:\bin.aa, a:\freebsd\bin a:\freebsd i mean evrything then they tried installing from a msdos partition they created the C:\FREEBSD\BIN directory and then copied the bin files to it the same thing happen. the same awful menu. the worst was that the instalation program didnt find a kernel image to link so they have to boot from the flopies constantly after a few hours triying they give it up and tried whit the fixit flopie the floppie replied whit a # and they didn't know enougth unix to fixit.. after all they didn't have been root's never. so they give up heartbrokenly. that was 4 months ago... the last week jhony tried in his own computer the same thing... this time he had readit all of the install.txt and most of the freebsd online handbook in fact. so whit the fips utility he created another partion of 480 megabytes in the 1.6 Gb (IDE) of his pentium /133 24-ram computer and tried exactly the same thing. and exactly the same thing happened: he had downloaded the fips. the boot.flp, fixit.flp and bin.aa to bin.ee from ftp mirror #2 in a near computer that had internet conection, compressed put it back in home uncompresed and installed. the version was again the 2.1.5 & this time he had special careful in formating the diskkets from a ms-dos (6.22) based machine. (this time the boot.flp works well and the help files where available something that wasn't in the boot4.flp) and exactly the same thing happened... he tried again changing the ms-dos subdirectorys and installing from a ms-dos partition there where no diferrence. but this time johny 5 was fully determined. he find a old unix SVR5 reference manual put the fixit floppie inside and tried for over 12 continuos hours to learn enough unix to make the install proccess from the hostile # prompt. he tried mounting and umounting, making nfs to the hard disk, whit fsck, changing the path removing the floppie & trying of copy the kernel from the boot.. then mounting the ms-dos partition and coping the bin. files to a new bin directory in /dev/wd0s2 mounted as /mnt and then trying to uncompress it with restore & rrestore the with gunzip, whit zcat he look evrywhere for a command like the 'sys' of ms-dos so he dont have to boot from floppie some of this functioned... but none enougth to install the bin files or to link the kernel in the hard disk he become obsesionated whit it and since then he is still trying but now had become pale and thin. he didnt ate or drink nothing or almost nothing, if some one speaks to him he didn't answer or says something about 'the kernel' im worried about im and his live so i decided to write this letter to those fellows in freebsd.org that surely could help. what should johny do where was the mistake? in compressing the files at the beggining? should he downloaded it again and try it all? its a bug in the installation program? should the bin files go in another subdirectory? i mean it was in a:\bin should it be in a:\dist? or something its a bug in the instalation program? are somewhere a procedure to install the kernel and the all the system in the hard disk trougth the fixit # prompt ? and finally... to install freebsd, what should he done? From owner-freebsd-hackers Mon Dec 16 08:48:17 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id IAA16594 for hackers-outgoing; Mon, 16 Dec 1996 08:48:17 -0800 (PST) Received: from fang.cs.sunyit.edu (fang.cs.sunyit.edu [192.52.220.66]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id IAA16586 for ; Mon, 16 Dec 1996 08:48:10 -0800 (PST) Received: (from chuck@localhost) by fang.cs.sunyit.edu (8.7.6/8.7.3) id LAA00451 for hackers@freebsd.org; Mon, 16 Dec 1996 11:46:27 -0500 (EST) Date: Mon, 16 Dec 1996 11:46:27 -0500 (EST) From: Charles Green Message-Id: <199612161646.LAA00451@fang.cs.sunyit.edu> X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: hackers@freebsd.org Subject: NIC confusion Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I have a question, maybe someone can help me out. I was reading through some advertisements at some 10/100Mb NE2000 compatable NICs. Correct me if I'm wrong but wouldn't a NIC running in NE2000 compatablility mode be running at only 10Mb? Or is there a NE2000 spec. for 100Mb? -- Charles Green, PRC Inc. Rome Laboratory, NY From owner-freebsd-hackers Mon Dec 16 09:11:15 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id JAA18048 for hackers-outgoing; Mon, 16 Dec 1996 09:11:15 -0800 (PST) Received: from usa.nai.net (usa.nai.net [204.71.21.10]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id JAA18043 for ; Mon, 16 Dec 1996 09:11:11 -0800 (PST) Received: from SIGGINS.nai.net (Putnam-Usr1-6.nai.net [208.133.169.15]) by usa.nai.net (8.6.12/8.6.5) with SMTP id MAA13843 for ; Mon, 16 Dec 1996 12:10:57 -0500 Message-ID: <32B581F8.56BA@ct2.nai.net> Date: Mon, 16 Dec 1996 12:08:08 -0500 From: "Douglas A. $iggins" Reply-To: siggins@mail2.nai.net Organization: Tempest Harding Inc. X-Mailer: Mozilla 3.0Gold (Win95; I) MIME-Version: 1.0 To: hackers@freebsd.org Subject: HELP WITH X windows on installation. Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk When installing FreeBSD I get the binaries all installed, but when it goes for the installation and configuration of Xwindows. IE resetting screen for use with XWindows config, it pops out of the installation (never gets to Xwindows) and prints this error about 6 times: _X111TransSocket UNIX Connect: can't connect: err no = 61 Any ideas on what is wrong or what I am doing wrong? Thanks. From owner-freebsd-hackers Mon Dec 16 09:34:34 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id JAA19705 for hackers-outgoing; Mon, 16 Dec 1996 09:34:34 -0800 (PST) Received: from etinc.com (et-gw-fr1.etinc.com [204.141.244.98]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id JAA19688 for ; Mon, 16 Dec 1996 09:34:31 -0800 (PST) Received: from ntws (ntws.etinc.com [204.141.95.142]) by etinc.com (8.6.12/8.6.9) with SMTP id MAA16091; Mon, 16 Dec 1996 12:37:23 -0500 Message-Id: <3.0.32.19961216123446.00ac3c10@etinc.com> X-Sender: dennis@etinc.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Mon, 16 Dec 1996 12:34:49 -0500 To: Charles Green From: dennis Subject: Re: NIC confusion Cc: hackers@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk At 11:46 AM 12/16/96 -0500, you wrote: > I have a question, maybe someone can help me out. I was reading >through some advertisements at some 10/100Mb NE2000 compatable NICs. Correct >me if I'm wrong but wouldn't a NIC running in NE2000 compatablility mode be >running at only 10Mb? Or is there a NE2000 spec. for 100Mb? I think that the word "compatible" is being used rather poorly here.... Dennis >-- >Charles Green, PRC Inc. >Rome Laboratory, NY > > From owner-freebsd-hackers Mon Dec 16 09:36:13 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id JAA20006 for hackers-outgoing; Mon, 16 Dec 1996 09:36:13 -0800 (PST) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id JAA19950 for ; Mon, 16 Dec 1996 09:36:04 -0800 (PST) Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.3/8.6.9) id EAA18177; Tue, 17 Dec 1996 04:33:00 +1100 Date: Tue, 17 Dec 1996 04:33:00 +1100 From: Bruce Evans Message-Id: <199612161733.EAA18177@godzilla.zeta.org.au> To: terry@lambert.org, tony@dell.com Subject: Re: Boot loader hacks was: Re: MAXMEM Cc: eivind@dimaga.com, hackers@FreeBSD.ORG Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >>Go ahead and add it. Make sure the boot code doesn't grow over >>the 8k limit imposed on it by the fact that there isn't any more >>space between the start of the BSD area on the disk and the disklabel >>on everyone's hardrives for several years now... >I think that boot2 can only be 7 KB. Even so, there seems to be plenty >of space to do this. So I started hacking on FreeBSD. (There should >be a mailing list for this kind of thing.) It can be of almost any size, but is currently limited to 7.5K (or 4.5K on 9-sector floppies :-). BSD file systems have a reserved area for boot blocks at the front of them. Unfortunately, the size has been hard-coded as 8K in the key utilities (disklabel, newfs and sysinstall) for many years, so there is little space to spare for new boot blocks on old disks. The utilities also don't support putting the boot blocks on a separate partition or keeping them outside of all partitions very well. There is also a 7.5K limit because the boot blocks are too stupid to load themselves if they cross a track boundary. >My first quick attempt, which still needs improvement, though it works >fine on my 96 MB system :-), adds about 160 bytes of bloat to boot2 to >bring it from 6576 to 6736 bytes. I only coded in the E820h function, >and not the E801h function, since E820h is the harder one. There's >still over 400 bytes left for more stuff! Don't forget to compile it with all the options :-). I think it's already over 7.5K if they are all enabled. >Unfortunately, > > if (bootinfo.bi_extmem != biosextmem) > printf("BIOS extmem (%ldK) != RTC extmem (%dK)\n", > bootinfo.bi_extmem, biosextmem); > >this code in machdep.c complains about my boot loader patches but >doesn't choose the bigger value. Does anyone know why the comment, >"Prefer the RTC value for extended memory." appears near this code? > >Well I didn't, so I added these lines right afterwards: > > if (bootinfo.bi_extmem > biosextmem) > biosextmem = bootinfo.bi_extmem; Because of the rule "never change a ``working'' system". It's just as well that it wasn't changed - memsize() doesn't clear the top 16 bits properly, even for the base memory size. Bruce From owner-freebsd-hackers Mon Dec 16 10:24:34 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id KAA22761 for hackers-outgoing; Mon, 16 Dec 1996 10:24:34 -0800 (PST) Received: from passer.osg.gov.bc.ca (0@passer.osg.gov.bc.ca [142.32.110.29]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id KAA22751; Mon, 16 Dec 1996 10:24:25 -0800 (PST) Received: from localhost (15005@localhost [127.0.0.1]) by passer.osg.gov.bc.ca (8.8.4/8.6.10) with SMTP id KAA19084; Mon, 16 Dec 1996 10:19:58 -0800 (PST) From: Cy Schubert - ITSD Open Systems Group Message-Id: <199612161819.KAA19084@passer.osg.gov.bc.ca> X-Authentication-Warning: passer.osg.gov.bc.ca: 15005@localhost [127.0.0.1] didn't use HELO protocol Reply-to: cschuber@uumail.gov.bc.ca X-Mailer: MH X-Sender: cschuber To: Terry Lambert cc: rb@gid.co.uk (Bob Bishop), proff@iq.org, security@FreeBSD.ORG, hackers@FreeBSD.ORG Subject: Re: vulnerability in new pw suite In-reply-to: Your message of "Sun, 15 Dec 96 13:39:04 MST." <199612152039.NAA23837@phaeton.artisoft.com> Date: Mon, 16 Dec 96 10:19:57 -0800 X-Mts: smtp Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk DEC UNIX, with C2 security enabled, allows the user to decide whether to use a system generated password or a user picked password. One could take this concept one step further than DEC has done and have it controlled by a configuration file with either global or per-user defaults. passer$ passwd Old password: Last successful password change for cschuber: Mon Dec 2 07:06:07 1996 Last unsuccessful password change for cschuber: Fri Mar 1 08:03:27 1996 Do you want (choose one letter only): Pronounceable passwords generated for you (g) A string of characters generated for you (c) A string of letters generated for you (l) ? To pick your password (p) ? Enter choice here (q to quit): q Password not changed: user aborted program. passer$ Just my $0.02 worth. Regards, Phone: (250)387-8437 Cy Schubert OV/VM: BCSC02(CSCHUBER) Open Systems Support BITNET: CSCHUBER@BCSC02.BITNET ITSD Internet: cschuber@uumail.gov.bc.ca cschuber@bcsc02.gov.bc.ca "Quit spooling around, JES do it." From owner-freebsd-hackers Mon Dec 16 10:36:44 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id KAA23356 for hackers-outgoing; Mon, 16 Dec 1996 10:36:44 -0800 (PST) Received: from gaia.coppe.ufrj.br (root@cisigw.coppe.ufrj.br [146.164.2.31]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id KAA23351 for ; Mon, 16 Dec 1996 10:36:41 -0800 (PST) Received: (from jonny@localhost) by gaia.coppe.ufrj.br (8.8.3/8.7.3) id QAA25314; Mon, 16 Dec 1996 16:33:56 -0200 (EDT) From: Joao Carlos Mendes Luis Message-Id: <199612161833.QAA25314@gaia.coppe.ufrj.br> Subject: Re: Boot loader hacks was: Re: MAXMEM To: tony@dell.com (Tony Overfield) Date: Mon, 16 Dec 1996 16:33:55 -0200 (EDT) Cc: terry@lambert.org, eivind@dimaga.com, hackers@FreeBSD.ORG In-Reply-To: <3.0.1.32.19961216085001.0067ee14@bugs.us.dell.com> from Tony Overfield at "Dec 16, 96 08:50:04 am" X-Mailer: ELM [version 2.4ME+ PL22 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Just a stupid question: Why does the boot loader should know if there's more than 64M or not on the system ? Why couldn't it simply detect 64M at most, and let the kernel find the rest by itself ? Anyway, is what's done with the MAXMEM option, isn't it ? Moreover: Is there any STRONG reason to ask the BIOS for the memory amount ? Couldn't it search for the memory ? At 01:41 PM 12/15/96 -0700, Terry Lambert wrote: >> There are standardized BIOS calls to obtain the correct amount of >> memory, even when it exceeds 65 MB. I think the boot loader should >> make these BIOS calls and pass the correct information to the kernel. > >Go ahead and add it. Make sure the boot code doesn't grow over >the 8k limit imposed on it by the fact that there isn't any more >space between the start of the BSD area on the disk and the disklabel >on everyone's hardrives for several years now... > > Regards, > Terry Lambert > terry@lambert.org Jonny -- Joao Carlos Mendes Luis jonny@gta.ufrj.br +55 21 290-4698 ( Job ) jonny@cisi.coppe.ufrj.br Network Manager UFRJ/COPPE/CISI Universidade Federal do Rio de Janeiro From owner-freebsd-hackers Mon Dec 16 10:36:57 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id KAA23380 for hackers-outgoing; Mon, 16 Dec 1996 10:36:57 -0800 (PST) Received: from iafnl.es.iaf.nl (uucp@iafnl.es.iaf.nl [195.108.17.20]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id KAA23373 for ; Mon, 16 Dec 1996 10:36:54 -0800 (PST) Received: by iafnl.es.iaf.nl with UUCP id AA23426 (5.67b/IDA-1.5 for FreeBSD-hackers@freebsd.org); Mon, 16 Dec 1996 19:36:32 +0100 Received: (from wilko@localhost) by yedi.iaf.nl (8.7.5/8.6.12) id TAA01062 for FreeBSD-hackers@freebsd.org; Mon, 16 Dec 1996 19:31:37 +0100 (MET) From: Wilko Bulte Message-Id: <199612161831.TAA01062@yedi.iaf.nl> Subject: Running Linux' Acrobat reader under 215R? To: FreeBSD-hackers@freebsd.org (FreeBSD hackers list) Date: Mon, 16 Dec 1996 19:31:37 +0100 (MET) X-Mailer: ELM [version 2.4 PL24 ME8a] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi there I would like to run Adobe's Linux version of acroread. It's V3.0 and 'file' sez: bash# file acroread acroread: ELF 32-bit LSB executable i386 (386 and up) Version 1 I did not pay much attention to Linux emulation in the past, so I'm wondering if ELF linux binaries have any chance of working anyway. This is on 2.1.5R with COMPAT_LINUX etc in the kernel. Would have searched the mail archives but: bash# traceroute www.freebsd.org traceroute to freefall.FreeBSD.org (204.216.27.18), 30 hops max, 40 byte packets 1 i0481p82.universal.nl (194.151.8.82) 244.194 ms 226.153 ms 218.995 ms 2 elstrouter.universal.nl (194.151.8.65) 229.131 ms 217.538 ms 218.779 ms 3 Arnhem1.unisrc.net (194.151.241.29) 228.905 ms 587.063 ms 339.000 ms 4 Amsterdam6.unisrc.net (194.151.254.12) 248.940 ms 347.195 ms 808.990 ms 5 Amsterdam-EBS.Ebone.net (193.148.15.67) 708.929 ms 507.618 ms 329.218 ms 6 Stockholm-ebs.Ebone.NET (192.121.155.10) 569.126 ms 588.076 ms 469.181 ms 7 * * * 8 * * * etc Wilko _ ____________________________________________________________________ | / o / / _ Bulte email: wilko@yedi.iaf.nl - Arnhem, The Netherlands |/|/ / / /( (_) Do, or do not. There is no 'try' - Yoda -------------------------------------------------------------------------- From owner-freebsd-hackers Mon Dec 16 10:56:09 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id KAA24521 for hackers-outgoing; Mon, 16 Dec 1996 10:56:09 -0800 (PST) Received: from gaia.coppe.ufrj.br (root@cisigw.coppe.ufrj.br [146.164.2.31]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id KAA24514 for ; Mon, 16 Dec 1996 10:56:04 -0800 (PST) Received: (from jonny@localhost) by gaia.coppe.ufrj.br (8.8.3/8.7.3) id QAA26056; Mon, 16 Dec 1996 16:55:10 -0200 (EDT) From: Joao Carlos Mendes Luis Message-Id: <199612161855.QAA26056@gaia.coppe.ufrj.br> Subject: Re: talk and talkd To: joerg_wunsch@uriah.heep.sax.de Date: Mon, 16 Dec 1996 16:55:09 -0200 (EDT) Cc: freebsd-hackers@freebsd.org, mgessner@aristar.com In-Reply-To: <199612130915.KAA17346@uriah.heep.sax.de> from J Wunsch at "Dec 13, 96 10:15:42 am" X-Mailer: ELM [version 2.4ME+ PL22 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk #define quoting(J Wunsch) // As Warner Losh wrote: // // > : I think you need to provide more data. talk is fairly fragile, but // > : nevertheless works (apparently) for most of us out of the box. // > // > There are also multiple talk protocols that are used by talk. And the // > one that Sun uses is not compatible with anybody :-( // // ytalk is supposed to speak the Sun protocol as well (including the // required byte order changes Sun was so proud to forget). ytalk is X, right ? I'd like to use something text-oriented. The default inetd.conf mentions a /usr/old/talkd, but I could not find any reference about it. Does it really exists ? // // -- // 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. ;-) // Jonny -- Joao Carlos Mendes Luis jonny@gta.ufrj.br +55 21 290-4698 ( Job ) jonny@cisi.coppe.ufrj.br Network Manager UFRJ/COPPE/CISI Universidade Federal do Rio de Janeiro From owner-freebsd-hackers Mon Dec 16 11:06:13 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id LAA25043 for hackers-outgoing; Mon, 16 Dec 1996 11:06:13 -0800 (PST) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id LAA25030 for ; Mon, 16 Dec 1996 11:06:07 -0800 (PST) Received: from current1.whistle.com (current1.whistle.com [207.76.205.22]) by alpo.whistle.com (8.8.2/8.8.2) with SMTP id KAA01910; Mon, 16 Dec 1996 10:55:58 -0800 (PST) Message-ID: <32B59B10.167EB0E7@whistle.com> Date: Mon, 16 Dec 1996 10:55:12 -0800 From: Julian Elischer Organization: Whistle Communications X-Mailer: Mozilla 3.0Gold (X11; I; FreeBSD 2.2-CURRENT i386) MIME-Version: 1.0 To: Tony Overfield CC: Terry Lambert , eivind@dimaga.com, hackers@FreeBSD.ORG Subject: Re: Boot loader hacks was: Re: MAXMEM References: <3.0.1.32.19961216085001.0067ee14@bugs.us.dell.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Tony Overfield wrote: > > > My first quick attempt, which still needs improvement, though it works > fine on my 96 MB system :-), adds about 160 bytes of bloat to boot2 to > bring it from 6576 to 6736 bytes. I only coded in the E820h function, > and not the E801h function, since E820h is the harder one. There's > still over 400 bytes left for more stuff! > > now try compile it with a mix of other options.... (specifically NAMEBLOCK and PROBE_KEYBOARD etc.) and see if it STILL fits.... From owner-freebsd-hackers Mon Dec 16 11:08:23 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id LAA25168 for hackers-outgoing; Mon, 16 Dec 1996 11:08:23 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id LAA25149; Mon, 16 Dec 1996 11:08:19 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id MAA01753; Mon, 16 Dec 1996 12:05:06 -0700 From: Terry Lambert Message-Id: <199612161905.MAA01753@phaeton.artisoft.com> Subject: Re: Other filesystems under FreeBSD To: pgiffuni@fps.biblos.unal.edu.co (Pedro Giffuni S.) Date: Mon, 16 Dec 1996 12:05:06 -0700 (MST) Cc: terry@lambert.org, hackers@freebsd.org, fs@freebsd.org In-Reply-To: <32B4CCDA.D64@fps.biblos.unal.edu.co> from "Pedro Giffuni S." at Dec 15, 96 08:15:22 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-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > My interest in HPFS was due to WinNT=B4s support for that filesystem > (Microsoft also has his hands dirty on that): I am not interested in > NTFS, so the decent option seemed HPFS. Both MS and IBM agree that HPFS > is better than FAT, but only OS2 can format HPFS, which makes it almost > useless. > Perhaps before killing by system I should play to convert our FAT to > VFAT , that way I=B4ll learn more in the process (and erase win95). Note: as I said previously, NT 4.x drops support for HPFS; therefore you will not find it useful if your intent was to run it under NT after 3.51. As far as converting FAT to VFAT, Robert Nordier has already been doing this (done it?). The problem on VFAT is that the algortihm used for generating the short names depends on being able to look up in the second name space independently of the first while holding the lock on the entilre directory so other processes don't change it. Currently, the structure of the namei/lookup interface in FreeBSD is such that FS is expected to free resources allocated at the system call (FS consumer) layer... the nameidata buffer. I have a set of patches that apply against an older-that-current kernel that fix this problem, but the lookups are still not capable of supporting multiple name spaces without additional work. The full VFAT support and Windows 95/NT interoperability problem is non-trivial to solve. There is also the question of case insensitivity on lookup and case sensitivity on storage. I believe a proper implementation would have to take this into account, since the "long names" of "Foo" and "foo" will cause only the first to be found if you remount it under Win95 or WinNT. Probably the correct way to do this is to put a name space switch into the FS itself. In any case, when you lookup "foo" for the create, it needs to return "Foo" as a matching name so that you don't get the collision when you run NT/95. This is somewhat problematic for BSD (or Linux) because of the getdents interface (which ends up being the VOP_READDIR interface), which only holds on a directory block at a time. There is a semantic fix (needed to get rid of the lookup cookies for NFS, actually) which would also partially alleviate this problem. I say partially because globbing in BSD is done in user space, not in the kernel... quite wasteful, really, since it means pushing large amounts of non-matching data over the user/kernel boundry 8-(. One block at a time won't work because two creates could occur in seperate blocks based on the first create having a longer name and traversing further into the directory, while a second create might be able to occur in a block that was passed by the first, but which is large enough for the shorter second name. This is a problem because the collision resoloution on short names means that if the lookup operation does not contain both the short and the long name on lookup, a long name could hash to a short name, and a second create with a "long name" that was the same value as the hash result for the short name, would collide (ie: "VERYLONGNAME.TXT" and the hash value "VERYLO~1.TXT"). Clearly, if process 1 creates the long file name "VERYLONGNAME.TXT" and process 2 creates the long file "VERYLO~1.TXT", if they are created at the right time, there would be a lookup race (both in the system call code, the "vncalls" layer, and the NFS server code -- both of which are VFS clients). In any case, this is more of a problem only when you want to expose the multiple name spaces outside the kernel (which you *do* want, if, for instance, you are running a SAMBA server or NetWare server on your FreeBSD box). Otherwise, you never export the short name space, and internally lock the directory against reentrancy (bah!). A generic soloution to this would require fixing stacking so that you could attribute regular FFS files with additional "short names" using a stacking layer, instead of hacking up the FFS directory structure (I've done both for commercial software I've worked on; it's a performance/elegance trade off that is better made on the side of elegance everywhere but as a plug-in FS on a Microsoft OS). 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-hackers Mon Dec 16 12:10:39 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id MAA29115 for hackers-outgoing; Mon, 16 Dec 1996 12:10:39 -0800 (PST) Received: from apolo.biblos.unal.edu.co ([168.176.37.75]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id MAA29108; Mon, 16 Dec 1996 12:10:21 -0800 (PST) Received: from unalmodem.usc.unal.edu.co ([168.176.3.45]) by apolo.biblos.unal.edu.co (8.8.2/8.8.2) with SMTP id PAA11552; Mon, 16 Dec 1996 15:09:07 -0500 (EST) Message-ID: <32B5D5B4.5379@fps.biblos.unal.edu.co> Date: Mon, 16 Dec 1996 15:05:25 -0800 From: "Pedro Giffuni S." Organization: Universidad Nacional de Colombia X-Mailer: Mozilla 3.0 (Win16; I) MIME-Version: 1.0 To: Guido van Rooij CC: fs@freebsd.org, hackers@freebsd.org Subject: Re: Flash File System References: <199612161846.TAA25197@gvr.win.tue.nl> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Guido van Rooij wrote: > > Pedro Giffuni S. wrote: > > Hi, > > While I continue to look which parts of the MSDN are freely > > distributable some of you may find useful the Specification for MSīs > > Flash File System, now available in: > > ftp://freefall.freebsd.org/pub/incoming/msffs.ps.gz > > > > Nothing there... > > -Guido Evidently that directory was cleaned, if some else needs the MS Flash System Specification, or the PnP Specification, just email me where to drop it. My network is becoming intermittent and I canīt grant anything, but weīll see. Pedro. From owner-freebsd-hackers Mon Dec 16 12:46:05 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id MAA01288 for hackers-outgoing; Mon, 16 Dec 1996 12:46:05 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id MAA01283; Mon, 16 Dec 1996 12:46:03 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id NAA01965; Mon, 16 Dec 1996 13:42:51 -0700 From: Terry Lambert Message-Id: <199612162042.NAA01965@phaeton.artisoft.com> Subject: Re: vulnerability in new pw suite To: rb@gid.co.uk (Bob Bishop) Date: Mon, 16 Dec 1996 13:42:51 -0700 (MST) Cc: terry@lambert.org, proff@iq.org, security@freebsd.org, hackers@freebsd.org In-Reply-To: from "Bob Bishop" at Dec 16, 96 00:03:01 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-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > Yeah, fine on an isolated machine, but those pesky users also insist on > using the same weak password on lots of different systems. So if some > sleaze does manage to get root on your system and thus access to your > shadow file, five gets you ten the user passwords he can now derive will > work on neighbouring systems. Five gets you ten that he'll just use rlogin instead, and go for root on the new system from the user account, never knowing the user's password (or caring). 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-hackers Mon Dec 16 12:50:29 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id MAA01588 for hackers-outgoing; Mon, 16 Dec 1996 12:50:29 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id MAA01583; Mon, 16 Dec 1996 12:50:27 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id NAA01987; Mon, 16 Dec 1996 13:47:23 -0700 From: Terry Lambert Message-Id: <199612162047.NAA01987@phaeton.artisoft.com> Subject: Re: vulnerability in new pw suite To: imp@village.org (Warner Losh) Date: Mon, 16 Dec 1996 13:47:23 -0700 (MST) Cc: terry@lambert.org, dreamer@garrison.inetcan.net, rb@gid.co.uk, proff@iq.org, security@freebsd.org, hackers@freebsd.org In-Reply-To: from "Warner Losh" at Dec 15, 96 10:36: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-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > In message <199612152336.QAA00213@phaeton.artisoft.com> Terry Lambert writes: > : Fool! Your machine is not safe... all ninjas worth their salt carry > : extra ST-506 controllers! Do you know nothing of Tai-Kwan Leap? > > And to Terry Lambert, I leave a boot to the head... :-) > > Warner "I learned Tai-Kwan Leap to kick some bootie" Losh Aie! One of me alone can not hope to defeat you! 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-hackers Mon Dec 16 13:02:18 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id NAA02491 for hackers-outgoing; Mon, 16 Dec 1996 13:02:18 -0800 (PST) Received: from quackerjack.cc.vt.edu (quackerjack.cc.vt.edu [198.82.160.250]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id NAA02483 for ; Mon, 16 Dec 1996 13:02:13 -0800 (PST) Received: from sable.cc.vt.edu (sable.cc.vt.edu [128.173.16.30]) by quackerjack.cc.vt.edu (8.7.1/8.7.1) with SMTP id QAA15315; Mon, 16 Dec 1996 16:01:59 -0500 (EST) Received: from localhost (jandrese.async.vt.edu [128.173.20.208]) by sable.cc.vt.edu (8.6.12/8.6.12) with SMTP id QAA15508; Mon, 16 Dec 1996 16:01:58 -0500 Date: Mon, 16 Dec 1996 16:01:06 +0000 () From: Nessus X-Sender: jandrese@localhost To: Joao Carlos Mendes Luis cc: joerg_wunsch@uriah.heep.sax.de, freebsd-hackers@freebsd.org, mgessner@aristar.com Subject: Re: talk and talkd In-Reply-To: <199612161855.QAA26056@gaia.coppe.ufrj.br> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Mon, 16 Dec 1996, Joao Carlos Mendes Luis wrote: =)ytalk is X, right ? =) =)I'd like to use something text-oriented. The default inetd.conf mentions =)a /usr/old/talkd, but I could not find any reference about it. Does it =)really exists ? =) ytalk -x to run ytalk in text mode. Or add the line: turn X off in your .ytalkrc to make it command line I use ytalk whenever I can, because many stupid terminals (like the ones I have to use on Macs and NT machines in the lab) tend to put a lot of ^H's up on the screen, while ytalk doesn't. Ytalk also has the shell option, which I find very usefull in illustrating points. The only problem is that talk and ytalk don't talk to each other, and whenver you ring someone with ytalk, it says' ... type talk jandrese@jandrese.async.vt.edu to respond... where they should type ytalk instead. :::::::::::::::::::::::::::. . . . . ..:::::::::::::::::::::::::::: :: Jason Andresen :. . . . . . . . . : Running FreeBSD and :: :: jandrese@vt.edu :.:.:.:.:.:.:.:.:.:: loving every minute! :: :.........................: Quote of the day :..........................: A dozen, a gross, and a score, Plus three times the square root of four, Divided by seven, Plus five times eleven, Equals nine squared plus zero, no more. :::::::::::.:.:.:.:.:.:.:.........................:.:.:.:.:.:.:.::::::::::: From owner-freebsd-hackers Mon Dec 16 13:05:07 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id NAA02778 for hackers-outgoing; Mon, 16 Dec 1996 13:05:07 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id NAA02755 for ; Mon, 16 Dec 1996 13:04:59 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id OAA02010; Mon, 16 Dec 1996 14:01:47 -0700 From: Terry Lambert Message-Id: <199612162101.OAA02010@phaeton.artisoft.com> Subject: Re: Boot loader hacks was: Re: MAXMEM To: jonny@mailhost.coppe.ufrj.br (Joao Carlos Mendes Luis) Date: Mon, 16 Dec 1996 14:01:47 -0700 (MST) Cc: tony@dell.com, terry@lambert.org, eivind@dimaga.com, hackers@freebsd.org In-Reply-To: <199612161833.QAA25314@gaia.coppe.ufrj.br> from "Joao Carlos Mendes Luis" at Dec 16, 96 04:33:55 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-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > Just a stupid question: Why does the boot loader should know if > there's more than 64M or not on the system ? So it can tell the kernel. > Why couldn't it simply detect 64M at most, and let the kernel > find the rest by itself ? Anyway, is what's done with the > MAXMEM option, isn't it ? No; the kernel assumes what you tell it is true. If you use the MAXMEM option, you are eternally stuck with that memory for that particular kernel. Take it to a machine with more memory, and you don't use the extra; take it to a machine with less, and you are screwed. > Moreover: Is there any STRONG reason to ask the BIOS for the > memory amount ? Couldn't it search for the memory ? You ask the BIOS because it's the only part of the system that *knows*, without a doubt, how much RAM there is. That's because it has POST code to search for the memory in a motherboard specific way which is known to work. You can't search it from protected mode because: 1) You don't know the correct algorithm for the particular motherboard 2) The correct algorithm for the particular motherboard which is in the BIOS can not be called from protected mode, and there's not even an entry point for it to be "magically" converted so it can run in protected mode. What *is* true is that you can add memory to the KVA space later, so there should be no problem in knowing about up to 16M reliably from the CMOS value, then making the BIOS calls to find out the real amount from protected mode, using a VM86 virtual machine to make virtual real mode BIOS calls. At that point, there's no limit on the amount of resource detection code you could put in the kernel. Note that once segment tagging and kernel paging is supported, the resource detection code space could be marked "run once"... meaning all space used for it could be recovered after it had been run. That is, I think, the correct long-term soloution to the problem; anything else is band-aid. 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-hackers Mon Dec 16 13:19:57 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id NAA03649 for hackers-outgoing; Mon, 16 Dec 1996 13:19:57 -0800 (PST) Received: from george.lbl.gov (george-gs.lbl.gov [131.243.40.130]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id NAA03636 for ; Mon, 16 Dec 1996 13:19:52 -0800 (PST) Received: (jin@localhost) by george.lbl.gov (8.6.10/8.6.5) id NAA29129; Mon, 16 Dec 1996 13:19:33 -0800 Date: Mon, 16 Dec 1996 13:19:33 -0800 From: "Jin Guojun[ITG]" Message-Id: <199612162119.NAA29129@george.lbl.gov> To: erich@lodgenet.com Subject: Re: Q for loadable network driver Cc: hackers@freebsd.org Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Another question is that is necessary to link the newly loaded driver to the kernel control block -- /sys/pci.c:155:static struct pcicb *pcicb; ------------------------------------------------------------- pci/pci.c: unmodified: line 704 -- /* ** allocate bus descriptor for bus behind the bridge */ link = &pcicb->pcicb_down; while (*link && (*link)->pcicb_bus < secondary) link = &(*link)->pcicb_next; this = malloc (sizeof (*this), M_DEVBUF, M_WAITOK); ... ... /* ** Link it in chain. */ *link=this; pci/pci.c: unmodified: line 819 -- ----------------------------------------------------------------- Without an interface to get the PCI control block address -- &pcicb -- it is hardly to link the new information into the kernel PCI chain. Also, is the segment above (pci/pci.c line 704 - 819) necessary for loading a loadable device driver? Thanks for any information, -Jin }>I have a question in writing a loadable network driver. }>How is the PCI device table is load into pcidevice_set list -- }> pcidevice_set.ls_items } }it's a linker set, see the archives for Terry's good explanation }of what these are and how they work. } }>That is, what is the mechanism to replace these lines : }> }>struct pci_device xyz_device = { }> OEM_DRVNAME, }> xyz_probe, }> xyz_attach, }> &xyz_count, }> xyz_shutdown }>}; }> }>DATA_SET(pcidevice_set, xyz_device); } }I believe that they're only used during the autoconf phase of }the pci bus. The pci subsystem gets a signature of all devices }on the bus; then asks each driver in the pcidevice_set, `hey }is this your device?' by calling the probe/attach members. } }I think they can savely be #ifdef'ed out for the lkm case, because }you're not autoconf'ing. Then lkm equivalent is done in the }xyz_load call. You might be able to peruse a pci data structure that }has a list of `found but not claimed' devices where you should find }your device's signature, or you may be able to play with /usr/bin/pciconf }to determine if your device exists before attempting the modload. From owner-freebsd-hackers Mon Dec 16 13:22:41 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id NAA04082 for hackers-outgoing; Mon, 16 Dec 1996 13:22:41 -0800 (PST) Received: from mexico.brainstorm.eu.org (root@mexico.brainstorm.fr [193.56.58.253]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id NAA04073 for ; Mon, 16 Dec 1996 13:22:35 -0800 (PST) Received: from brasil.brainstorm.eu.org (brasil.brainstorm.fr [193.56.58.33]) by mexico.brainstorm.eu.org (8.7.5/8.7.3) with ESMTP id WAA01129 for ; Mon, 16 Dec 1996 22:22:27 +0100 Received: (from uucp@localhost) by brasil.brainstorm.eu.org (8.6.12/8.6.12) with UUCP id WAA29170 for FreeBSD-hackers@FreeBSD.ORG; Mon, 16 Dec 1996 22:22:15 +0100 Received: (from roberto@localhost) by keltia.freenix.fr (8.8.4/keltia-uucp-2.9) id VAA11267; Mon, 16 Dec 1996 21:58:01 +0100 (CET) Message-ID: Date: Mon, 16 Dec 1996 21:58:00 +0100 From: roberto@keltia.freenix.fr (Ollivier Robert) To: FreeBSD-hackers@FreeBSD.ORG (FreeBSD hackers list) Subject: Re: Running Linux' Acrobat reader under 215R? References: <199612161831.TAA01062@yedi.iaf.nl> X-Mailer: Mutt 0.54 Mime-Version: 1.0 X-Operating-System: FreeBSD 3.0-CURRENT ctm#2815 In-Reply-To: <199612161831.TAA01062@yedi.iaf.nl>; from Wilko Bulte on Dec 16, 1996 19:31:37 +0100 Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk According to Wilko Bulte: > I did not pay much attention to Linux emulation in the past, so I'm > wondering if ELF linux binaries have any chance of working anyway. > This is on 2.1.5R with COMPAT_LINUX etc in the kernel. Forget about ELF in 2.1.*. Only 2.2+ versions are able to run ELF binaries, be they FreeBSD or Linux ones. There is a port for 3.0-CURRENT of acroread in ports/print/acroread. -- Ollivier ROBERT -=- The daemon is FREE! -=- roberto@keltia.freenix.fr FreeBSD keltia.freenix.fr 3.0-CURRENT #31: Tue Dec 3 23:52:58 CET 1996 From owner-freebsd-hackers Mon Dec 16 14:32:43 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id OAA09361 for hackers-outgoing; Mon, 16 Dec 1996 14:32:43 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id OAA09355 for ; Mon, 16 Dec 1996 14:32:38 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id PAA02172; Mon, 16 Dec 1996 15:29:12 -0700 From: Terry Lambert Message-Id: <199612162229.PAA02172@phaeton.artisoft.com> Subject: Re: Heidemann Framework integration (Re: Other filesystems under FreeBSD) To: koshy@india.hp.com (A JOSEPH KOSHY) Date: Mon, 16 Dec 1996 15:29:12 -0700 (MST) Cc: terry@lambert.org, freebsd-hackers@freefall.freebsd.org In-Reply-To: <199612161415.AA106675713@fakir.india.hp.com> from "A JOSEPH KOSHY" at Dec 16, 96 07:15:13 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-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > tl> FreeBSD is well suited to other file systems. What I was discussing > tl> was a number of small changes to the mechanism to seperate the > tl> implementation from the instantiation. Basically, I wanted to be > tl> able to simplify the code I needed to write to write a new FS, even > tl> more than it is already simplified over that for Linux. This is not > tl> the same thing as the code being impossible without the changes, > tl> only "more difficult than it would be in Terry's ideal world". > > Do we have any plans of integrating the Heidemann framework more completely > into the 3.0 development tree? > > IMO this would be a good idea. The default VFS framework in BSD *is* the Heidemann framework. The problems with it are all interface issues, where CSRG pounded it into 4.4BSD in reaction to the USL/UCB consent decree. One of the terms of the decree was that UCB agreed to drop files, effectively rendering inoperable 5 major kernel subsystems, including the file system. My take on this is that USL's intent was to damage the ability of 4.4BSD-Lite derived code to be (easily) converted into a running system. CSRG was routing around the damage under heavy time pressure; the results were to be expected. The main problem areas in the 4.4BSD/FreeBSD implementation of the Heidemann framework are: 1) The size of the vnode_op_desc structure is determined from the FFS vfs structures in vfs_init.c. This is in error because: o The FFS must be compiled into the kernel o The FFS must be recompiled when vnode_if.c and vnode_if.h are recreated to add ne vfsops types to the vector, since the structure size in a precompiled FFS will not account for these new ops otherwise o There is a requirement for at least one FS to be compiled into the kernel, even if the FFS explicit dependency were to be removed, since the initialization code depends on a static FS declaration for sizing no matter what Corrective actions are: o Get the size of the vnode_op_desc structure from a generated integer value from vnode_if.c; the actual implementation is to add two output lines (one of them blank) to vnode_if.c to declare and make a manifest divide by the element size, and to add an extern declaration (two more lines, one of them blank) to vnode_if.h. This is accomplished by a four line change to vnode_if.sh. o Change the initialization so that FS's self-register using the same interface that LKM's do. Cause a linker set of FS's wanting to be registered to be created (and then called) through init_main.c; a side effect of this will be that all LKM and non-LKM FS modules can be the same object code; that is, it is a link time, rather than a config-time, descision about whether or not an FS is a module or statically bound. o You must still link one FS with the kernel (the one that mounts / for you), but this is only a temporary requirement until the boot blocks can preload modules from the boot media before jumping to the kernel. 2) The vnode_op_desc structure is used to make the VOP calls order independent in the structure; basically, as long as you put the right calls in there, the order doesn't matter. This was done to allow insertion of new VOPs without damaging the ability of structure users to use them. This is wrong because: o It also depends on the vnode_if.c being recompiled for each change. o The intentional order independence denies linker set technology, which was unavailable to (or unused by) the 4.4BSD team. Compared to use of linker sets, it is a royal kludge to have to recompile the vnode_if.c each time. o The use of dynamic ordering means that the VOP reference must be made by descriptor. This is the reason for the inline functions in vnode_if.h, and the additional overhead of their use (non-manifest array dereference, repush of arguments), as opposed to direct function dereference. o Kill vclean. It requires VOCALL, which is evil. Corrective actions are: o Change the vnode_if.src/vnode_if.sh to use a linker set to gather the VOPs so that VOPS can be added to a running kernel. o Destroy the order dependence; this can be easily done by *sorting* the descriptor list for each FS at time of insertion to make the VOP offset constant (and consistent with the gathered list). o Allow runtime gathering of the list by reallocating the linker set as necessary. This means putting the VOP list into rallocable memory in the first place, or doing so during init (init_main.c) before use. o By using constant offsets in the internalized reference copy of the desc vector for each FS, the vnode_if.h can be changes to make the references direct references instead of through descriptors o In lieu of the immediate death of vclean, the use of the struct fileops should be discontinued. This should be discontinued anyway, when devfs becomes default, and specfs is destroyed. The remaining filesops can be rolled back out; vclean will have to use a flag marker on vnodes it wishes to invalidate, instead. 3) The VFS is not treated as a consumer interface; specifically, it's objects are treated non-opaquely. The biggest offender is struct nameidata, which is allocated by the caller, but freed by the callee. This is bad because: o It locks BSD into a single name space (ie: it can not support, easily, multiple name spaces for a single file system object. That is, it can not support, easily, VFAT, HPFS, NTFS, or MACFS. o It prevents the use of alternate storage for name space objects by making their appearance visible to the VFS consumers (currently, the system calls and the kernel NFS server code). That is, it can not support Unicode storage of data. This is an error for VFAT and NTFS, and for most modern FS work being done in the rest of the academic community. In fact, CIFS (the successor to LANMan) uses native Unicode wire data. Corrective actions are: o Change the nameidata interface to implement a corresponding nameifree() for each namei(). Make equivalents for the NFS server code, which is also a VFS consumer interface and expect the VFS to free its allocated data. o Change every file system's interfaces for those interfaces which operate on nameidata, so that the FS's themselves never free the data. o Allow namei()/nameifree() to deal with Unicode and name space conversions, transparently. 4) The VFS stacking is broken. The VFS stacking fails, mainly because of bad interactions with the FS specific VOP_LOCK and VOP_ADVLOCK code. o The VOP_LOCK code fails because it maintains a promiscuous lock knowledge for use by vclean. This is not a per-FS issue. o The VOP_ADVLOCK is "corrected" in 4.4BSD-Lite2 by moving to a "common interface"; unfortunately, the "common interface" is accessed via call-down... that is, code in the FS calls code in kern_lock.c. This is a violation of interface direction, and mans that anyone writing an FS stacking module must implement similar code, and, further, if stacking occurs, treat a stacked FS differently than an FS that accesses physical media. Corrective actions are: o Murder vclean. Alternately, move the vclean locking into the VOP_LOCK inline function (or if you have corrected #2, above, then put it in the macro definition that replaces the inline function; at least that way, the crap is out of the FS. o Change each FS to not attempt the locking. Not all FS's do it correctly (or at all) anyway, leading to lots of bad behaviours. In particular, because directory entries *are* inodes in FAT/VFAT, there is a nice race condition that it is impossible to get rid of if the FS specific VOP_LOCK code is expected to manage the vclean lock. o Convert the VOP_ADVLOCK interface into a veto interface; in other words, the default code would assert the lock on the top level vnode, then call down the stack. By default, the stack call would be a NULL function returning success to allow the lock. For stacked FS's, the same is true. For FS stacking layers that "fan out" from one inode to two or more (union FS, quota FS, umsdos FS), they would specifically iterate the veto calls to each underlying vnode down. Any failure and all locks are released, and the lock operation fails all the way up; the upper layer is free to retry after sleeping on the first node down. This prevents a deadly embrace deadlock, which is not possible with the call-down code. If it is a non-blocking lock request, the top level code does not sleep. In case of a VOP_LOCK calldown failure, the top level lock is released, and the failure propagates back to the caller. 5) SMP and kernel multithreading issues regarding VFS reentrancy have not been considered in the current design: o They should be considered before much longer Corrective actions are: o Consider them. One possible simplification exercise to make it much easier to debug would be to make all FS subsystem functions single entry/single exit, prepatory to "pushing down" the global entrancy mutex through the trap code for the system call interface. Another would be comment documentation of expected lock state for all objects going into functions, and resulting lock states for objects on the way out (for instance, you must lock the dir vnode on the way into a lookup, and the resulting vnode will be locked coming out, with the parent vnode for the resulting vnode (the second-to-terminal path component) potentially being left locked as well. This is not well documented, and the reasons are unclear (the actual reasons are related to call for create or rename returning instead of failing if the file exists, but the create parameters from the user specify that the call should fail if the file exists). 6) Etc. (exclusion interfaces, VOP_READDIR interfaces and the "cookie" hack for NFS directory iteration restart, and so on, and so on...). 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-hackers Mon Dec 16 14:54:10 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id OAA11160 for hackers-outgoing; Mon, 16 Dec 1996 14:54:10 -0800 (PST) Received: from rover.village.org (rover.village.org [204.144.255.49]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id OAA11147 for ; Mon, 16 Dec 1996 14:54:06 -0800 (PST) Received: from rover.village.org [127.0.0.1] by rover.village.org with esmtp (Exim 0.56 #1) id E0vZlun-0005ZA-00; Mon, 16 Dec 1996 15:53:41 -0700 To: Joao Carlos Mendes Luis Subject: Re: talk and talkd Cc: joerg_wunsch@uriah.heep.sax.de, freebsd-hackers@freebsd.org, mgessner@aristar.com In-reply-to: Your message of "Mon, 16 Dec 1996 16:55:09 -0200." <199612161855.QAA26056@gaia.coppe.ufrj.br> References: <199612161855.QAA26056@gaia.coppe.ufrj.br> Date: Mon, 16 Dec 1996 15:53:41 -0700 From: Warner Losh Message-Id: Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In message <199612161855.QAA26056@gaia.coppe.ufrj.br> Joao Carlos Mendes Luis writes: : I'd like to use something text-oriented. The default inetd.conf mentions : a /usr/old/talkd, but I could not find any reference about it. Does it : really exists ? even if you had old/talkd (which may be on one of the Lite CDs), it wouldn't help you talk to suns. Unless your compiler pads things exactly the same way as the sun compiler, it won't work :-(. Warner From owner-freebsd-hackers Mon Dec 16 15:14:56 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id PAA12728 for hackers-outgoing; Mon, 16 Dec 1996 15:14:56 -0800 (PST) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id PAA12720 for ; Mon, 16 Dec 1996 15:14:41 -0800 (PST) Received: from current1.whistle.com (current1.whistle.com [207.76.205.22]) by alpo.whistle.com (8.8.2/8.8.2) with SMTP id PAA06478; Mon, 16 Dec 1996 15:02:42 -0800 (PST) Message-ID: <32B5D4E4.167EB0E7@whistle.com> Date: Mon, 16 Dec 1996 15:01:56 -0800 From: Julian Elischer Organization: Whistle Communications X-Mailer: Mozilla 3.0Gold (X11; I; FreeBSD 2.2-CURRENT i386) MIME-Version: 1.0 To: Terry Lambert CC: Joao Carlos Mendes Luis , tony@dell.com, eivind@dimaga.com, hackers@freebsd.org Subject: Re: Boot loader hacks was: Re: MAXMEM References: <199612162101.OAA02010@phaeton.artisoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Terry Lambert wrote: > > > Just a stupid question: Why does the boot loader should know if > > there's more than 64M or not on the system ? > > So it can tell the kernel. > > > Why couldn't it simply detect 64M at most, and let the kernel > > find the rest by itself ? Anyway, is what's done with the > > MAXMEM option, isn't it ? > > No; the kernel assumes what you tell it is true. If you use the > MAXMEM option, you are eternally stuck with that memory for that > particular kernel. Take it to a machine with more memory, and > you don't use the extra; take it to a machine with less, and you > are screwed. > I added code to OSF1/x86 to look for more ram and add it to the ammount reported by the bios.. it wasn't that hard!! the problem is that it needs to be done very early so that an access to non-existant memory doesn't produce an NMI when read from (on parity systems) or other similar problems.. julian From owner-freebsd-hackers Mon Dec 16 15:35:06 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id PAA14007 for hackers-outgoing; Mon, 16 Dec 1996 15:35:06 -0800 (PST) Received: from offensive.communica.com.au (offensive-eth1.adl.communica.com.au [192.82.222.18]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id PAA13980 for ; Mon, 16 Dec 1996 15:34:53 -0800 (PST) Received: from communica.com.au (frenzy.communica.com.au [192.82.222.65]) by offensive.communica.com.au (8.7.6/8.7.3) with SMTP id KAA00354 for ; Tue, 17 Dec 1996 10:03:08 +1030 (CST) Received: by communica.com.au (4.1/SMI-4.1) id AA20060; Tue, 17 Dec 96 10:02:45 CDT Date: Tue, 17 Dec 96 10:02:45 CDT From: newton@communica.com.au (Mark Newton) Message-Id: <9612162332.AA20060@communica.com.au> To: freebsd-hackers@freebsd.org Subject: Problems with TCP? Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I experienced a problem on one of my machines this morning. The machine has had bpf in its kernel for quite some time now; I removed the packet filter over the weekend, thinking it wouldn't cause any problems since the need for me to have it installed has passed (I used to boot a Sun diskless, but now it has a disk). So -- I removed the "pseudo-device bpfilter" line from the kernel config file, config, make depend, make, make install and reboot. When the system came up, it was unable to carry out TCP conversations with a number of systems it must regularly talk to; I didn't find this out 'til later in the weekend when I started getting bouncemail messages caused by the fact that sendmail was unable to flush its queue at those machines. The bounce messages complained of a timeout exceeded while waiting for a 250 response to the EHLO command. Thinking it might be the fault of the machine at the other end, I attempted to manually duplicate the problem: newton@atdot> telnet ns.satech.net.au. smtp Trying 203.1.91.3... Connected to ns.satech.net.au. Escape character is '^]'. 220 box.satech.net.au ESMTP Sendmail Tue, 17 Dec 1996 09:45:54 +1030 HELO atdot.dotat.org 250 box.satech.net.au Hello dotat-gw.apana.org.au [203.14.159.1], pleased to mee ... and there it sat, half way through the response to the "HELO" command, with the cursor at the end of the line presumably waiting for the next few bytes to say "t you\n" Looking at my logs, it seemed apparent that this problem started when I booted my new kernel, so I pulled it out and rebooted with my old kernel. Hey presto, problem went away. Just to make sure, I rebuilt a new kernel after adding the bpfilter line back to the config file (just in case I had made some other change I had forgotten about prior to making the bpfilter change). Result: Can't talk TCP to satech anymore (not just the SMTP service either, although I'd hope that that would be an intuitive assumption for readers here :-) My problem: Without bpf in the kernel I can't get packet dumps to diagnose the problem that seems to occur without bpf in the kernel . As a result, it's difficult to provide more information than version numbers with my setup :-/ FYI - ns.satech.net.au is a Linux 2.0.23 system. Another system which presented exactly the same problem to me was bunux.senet.com.au, which (I think) also runs Linux, but I'm sending out some email to verify that. Do we have a basic incompatibility between FreeBSD and Linux TCP which asserts itself when the packet filter is enabled? Could TTCP modifications have caused bogosity like this? - mark --- Mark Newton Email: newton@communica.com.au Systems Engineer Phone: +61-8-8373-2523 Communica Systems WWW: http://www.communica.com.au From owner-freebsd-hackers Mon Dec 16 16:05:04 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id QAA16810 for hackers-outgoing; Mon, 16 Dec 1996 16:05:04 -0800 (PST) Received: from zen.nash.org (nash.pr.mcs.net [204.95.47.72]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id QAA16789 for ; Mon, 16 Dec 1996 16:04:59 -0800 (PST) Received: from zen.nash.org (localhost [127.0.0.1]) by zen.nash.org (8.8.3/8.6.12) with SMTP id SAA05464; Mon, 16 Dec 1996 18:03:42 -0600 (CST) Message-ID: <32B5E35E.167EB0E7@mcs.com> Date: Mon, 16 Dec 1996 18:03:42 -0600 From: Alex Nash X-Mailer: Mozilla 3.01Gold (X11; I; FreeBSD 2.1.6.1-RELEASE i386) MIME-Version: 1.0 To: Jeremy Sigmon CC: "Jordan K. Hubbard" , hackers@FreeBSD.ORG Subject: Re: atapi.flp References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Jeremy Sigmon wrote: > > > atapi.flp is dead - it was merged into boot.flp. > > root.flp is dead too. > > ln -s atapi.flp boot.flp :) That's not very helpful for someone using rawrite under DOS. How about adding an atapi.txt that points users to boot.flp? Alex From owner-freebsd-hackers Mon Dec 16 16:10:46 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id QAA17391 for hackers-outgoing; Mon, 16 Dec 1996 16:10:46 -0800 (PST) Received: from time.cdrom.com (time.cdrom.com [204.216.27.226]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id QAA17383 for ; Mon, 16 Dec 1996 16:10:42 -0800 (PST) Received: from time.cdrom.com (localhost [127.0.0.1]) by time.cdrom.com (8.8.4/8.6.9) with ESMTP id QAA06881; Mon, 16 Dec 1996 16:10:05 -0800 (PST) To: Alex Nash cc: Jeremy Sigmon , hackers@FreeBSD.ORG Subject: Re: atapi.flp In-reply-to: Your message of "Mon, 16 Dec 1996 18:03:42 CST." <32B5E35E.167EB0E7@mcs.com> Date: Mon, 16 Dec 1996 16:10:04 -0800 Message-ID: <6877.850781404@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > That's not very helpful for someone using rawrite under DOS. > > How about adding an atapi.txt that points users to boot.flp? The user is talking about an older version of FreeBSD's docs being incorrectly placed with a newer release, which had atapi.flp folded into boot.flp. This has been fixed, the documentation updated. We should now simply forget that atapi.flp ever existed and be happy. ;-) Jordan From owner-freebsd-hackers Mon Dec 16 16:29:14 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id QAA18806 for hackers-outgoing; Mon, 16 Dec 1996 16:29:14 -0800 (PST) Received: from tyger.inna.net (root@tyger.inna.net [206.151.66.1]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id QAA18794 for ; Mon, 16 Dec 1996 16:29:06 -0800 (PST) Received: from tyger.inna.net (jamie@tyger.inna.net [206.151.66.1]) by tyger.inna.net (8.8.3/8.7.3) with SMTP id TAA24455; Mon, 16 Dec 1996 19:36:06 -0500 (EST) Date: Mon, 16 Dec 1996 19:36:05 -0500 (EST) From: Jamie Bowden To: Warner Losh cc: Joao Carlos Mendes Luis , joerg_wunsch@uriah.heep.sax.de, freebsd-hackers@freebsd.org, mgessner@aristar.com Subject: Re: talk and talkd In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Mon, 16 Dec 1996, Warner Losh wrote: > In message <199612161855.QAA26056@gaia.coppe.ufrj.br> Joao Carlos Mendes Luis writes: > : I'd like to use something text-oriented. The default inetd.conf mentions > : a /usr/old/talkd, but I could not find any reference about it. Does it > : really exists ? > even if you had old/talkd (which may be on one of the Lite CDs), it > wouldn't help you talk to suns. Unless your compiler pads things > exactly the same way as the sun compiler, it won't work :-(. Fortunately, most suns have standard ntalkd put on them by their admins. At least, all the ones I admin'd ended up with it on them. Most of the other sun admins I know did/do the same. Jamie Bowden Network Administrator, TBI Ltd. From owner-freebsd-hackers Mon Dec 16 17:01:45 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id RAA21047 for hackers-outgoing; Mon, 16 Dec 1996 17:01:45 -0800 (PST) Received: from parkplace.cet.co.jp (parkplace.cet.co.jp [202.32.64.1]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id RAA21042 for ; Mon, 16 Dec 1996 17:01:42 -0800 (PST) Received: from localhost (michaelh@localhost) by parkplace.cet.co.jp (8.8.3/CET-v2.1) with SMTP id AAA00632; Tue, 17 Dec 1996 00:58:50 GMT Date: Tue, 17 Dec 1996 09:58:49 +0900 (JST) From: Michael Hancock To: Terry Lambert cc: A JOSEPH KOSHY , freebsd-hackers@freefall.freebsd.org Subject: Re: Heidemann Framework integration (Re: Other filesystems under FreeBSD) In-Reply-To: <199612162229.PAA02172@phaeton.artisoft.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Mon, 16 Dec 1996, Terry Lambert wrote: > The main problem areas in the 4.4BSD/FreeBSD implementation of the > Heidemann framework are: > There are also vops that don't take a vp as a parameter. bwrite and bstrategy. Regards, Mike Hancock From owner-freebsd-hackers Mon Dec 16 17:04:08 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id RAA21146 for hackers-outgoing; Mon, 16 Dec 1996 17:04:08 -0800 (PST) Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id RAA21131 for ; Mon, 16 Dec 1996 17:04:04 -0800 (PST) Received: (from msmith@localhost) by genesis.atrad.adelaide.edu.au (8.8.2/8.7.3) id LAA23727; Tue, 17 Dec 1996 11:33:57 +1030 (CST) From: Michael Smith Message-Id: <199612170103.LAA23727@genesis.atrad.adelaide.edu.au> Subject: Re: NIC confusion In-Reply-To: <199612161646.LAA00451@fang.cs.sunyit.edu> from Charles Green at "Dec 16, 96 11:46:27 am" To: green@fang.cs.sunyit.edu (Charles Green) Date: Tue, 17 Dec 1996 11:33:57 +1030 (CST) Cc: hackers@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-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Charles Green stands accused of saying: > I have a question, maybe someone can help me out. I was reading > through some advertisements at some 10/100Mb NE2000 compatable NICs. Correct > me if I'm wrong but wouldn't a NIC running in NE2000 compatablility mode be > running at only 10Mb? Or is there a NE2000 spec. for 100Mb? No. "NE2000 compatible" just means it has a register set that looks like the 8390. The actual data rate is a function of the hardware on the card. > Charles Green, PRC Inc. -- ]] 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-hackers Mon Dec 16 17:04:58 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id RAA21203 for hackers-outgoing; Mon, 16 Dec 1996 17:04:58 -0800 (PST) Received: from whqvax.picker.com (whqvax.picker.com [144.54.1.1]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id RAA21186; Mon, 16 Dec 1996 17:04:53 -0800 (PST) Received: from ct.picker.com by whqvax.picker.com with SMTP; Mon, 16 Dec 1996 20:04:22 -0500 (EST) Received: from elmer.ct.picker.com ([144.54.57.34]) by ct.picker.com (4.1/SMI-4.1) id AA04380; Mon, 16 Dec 96 20:04:19 EST Received: by elmer.ct.picker.com (SMI-8.6/SMI-SVR4) id UAA10855; Mon, 16 Dec 1996 20:03:17 -0500 Message-Id: Date: Mon, 16 Dec 1996 20:03:17 -0500 From: rhh@ct.picker.com (Randall Hopper) To: hackers@freebsd.org, emulation@freebsd.org Subject: APPLIXWARE on FreeBSD? X-Mailer: Mutt 0.54 Mime-Version: 1.0 Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Has anyone successfully run Applixware for Redhat Linux on FreeBSD? If so (with good or bad results) I'd be interested in hearing from you. Thanks, Randall Hopper rhh@ct.picker.com From owner-freebsd-hackers Mon Dec 16 17:10:06 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id RAA21528 for hackers-outgoing; Mon, 16 Dec 1996 17:10:06 -0800 (PST) Received: from misery.sdf.com (misery.sdf.com [204.244.210.193]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id RAA21523 for ; Mon, 16 Dec 1996 17:10:03 -0800 (PST) Received: from misery.sdf.com ([204.244.213.33]) by misery.sdf.com with SMTP id <1298-486>; Mon, 16 Dec 1996 17:09:34 -0800 Date: Mon, 16 Dec 1996 17:09:30 -0800 (PST) From: Tom Samplonius To: Mark Newton cc: freebsd-hackers@freebsd.org Subject: Re: Problems with TCP? In-Reply-To: <9612162332.AA20060@communica.com.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Tue, 17 Dec 1996, Mark Newton wrote: > > > I experienced a problem on one of my machines this morning. No mention of the version of FreeBSD used. I suspect that your sources are corrupt, or your kernel config file is out of date. Tom From owner-freebsd-hackers Mon Dec 16 17:11:15 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id RAA21618 for hackers-outgoing; Mon, 16 Dec 1996 17:11:15 -0800 (PST) Received: from gaia.coppe.ufrj.br (root@cisigw.coppe.ufrj.br [146.164.2.31]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id RAA21613 for ; Mon, 16 Dec 1996 17:11:11 -0800 (PST) Received: (from jonny@localhost) by gaia.coppe.ufrj.br (8.8.3/8.7.3) id XAA02226; Mon, 16 Dec 1996 23:10:07 -0200 (EDT) From: Joao Carlos Mendes Luis Message-Id: <199612170110.XAA02226@gaia.coppe.ufrj.br> Subject: Re: talk and talkd To: jamie@inna.net (Jamie Bowden) Date: Mon, 16 Dec 1996 23:10:07 -0200 (EDT) Cc: imp@village.org, jonny@mailhost.coppe.ufrj.br, joerg_wunsch@uriah.heep.sax.de, freebsd-hackers@freebsd.org, mgessner@aristar.com In-Reply-To: from Jamie Bowden at "Dec 16, 96 07:36:05 pm" X-Mailer: ELM [version 2.4ME+ PL22 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk #define quoting(Jamie Bowden) // On Mon, 16 Dec 1996, Warner Losh wrote: // // > In message <199612161855.QAA26056@gaia.coppe.ufrj.br> Joao Carlos Mendes Luis writes: // > : I'd like to use something text-oriented. The default inetd.conf mentions // > : a /usr/old/talkd, but I could not find any reference about it. Does it // > : really exists ? // // > even if you had old/talkd (which may be on one of the Lite CDs), it // > wouldn't help you talk to suns. Unless your compiler pads things // > exactly the same way as the sun compiler, it won't work :-(. // // Fortunately, most suns have standard ntalkd put on them by their admins. // At least, all the ones I admin'd ended up with it on them. Most of the // other sun admins I know did/do the same. Yup, but my problem is when my users want to talk with someone on a Sun system which does not have such a good manager. :) Since we can't change all Sun system in world, let's try to make our system at least able to talk with them. I've not yet taken a look at ytalk, but if the other side needs to use ytalk also, does not solve my problem. // // Jamie Bowden // // Network Administrator, TBI Ltd. // Jonny -- Joao Carlos Mendes Luis jonny@gta.ufrj.br +55 21 290-4698 ( Job ) jonny@cisi.coppe.ufrj.br Network Manager UFRJ/COPPE/CISI Universidade Federal do Rio de Janeiro From owner-freebsd-hackers Mon Dec 16 17:13:06 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id RAA21757 for hackers-outgoing; Mon, 16 Dec 1996 17:13:06 -0800 (PST) Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id RAA21752 for ; Mon, 16 Dec 1996 17:13:02 -0800 (PST) Received: (from msmith@localhost) by genesis.atrad.adelaide.edu.au (8.8.2/8.7.3) id LAA23769; Tue, 17 Dec 1996 11:41:09 +1030 (CST) From: Michael Smith Message-Id: <199612170111.LAA23769@genesis.atrad.adelaide.edu.au> Subject: Re: Boot loader hacks was: Re: MAXMEM In-Reply-To: <199612161833.QAA25314@gaia.coppe.ufrj.br> from Joao Carlos Mendes Luis at "Dec 16, 96 04:33:55 pm" To: jonny@mailhost.coppe.ufrj.br (Joao Carlos Mendes Luis) Date: Tue, 17 Dec 1996 11:41:08 +1030 (CST) Cc: tony@dell.com, terry@lambert.org, eivind@dimaga.com, hackers@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-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Joao Carlos Mendes Luis stands accused of saying: > Just a stupid question: Why does the boot loader should know if > there's more than 64M or not on the system ? Because many of the memory-detecting interfaces require real-mode calls, and the kernel has no means of performing these. > Why couldn't it simply detect 64M at most, and let the kernel > find the rest by itself ? Anyway, is what's done with the > MAXMEM option, isn't it ? > > Moreover: Is there any STRONG reason to ask the BIOS for the > memory amount ? Couldn't it search for the memory ? You can't safely "search" for memory. Systems with parity/ECC will usually NMI you if you hit a region with no memory in it, but a number of systems will just spontaneously reboot. Others will 'mirror' memory from lower locations, requiring you to write into the memory as you perform your search. Only this can disturb memory-mapped peripherals, and so it goes on. Because the BIOS has intimate knowledge of the board and chipset, it's the only authority on the subject. > Joao Carlos Mendes Luis jonny@gta.ufrj.br -- ]] 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-hackers Mon Dec 16 17:17:15 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id RAA21966 for hackers-outgoing; Mon, 16 Dec 1996 17:17:15 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id RAA21960 for ; Mon, 16 Dec 1996 17:17:13 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id SAA04996; Mon, 16 Dec 1996 18:13:37 -0700 From: Terry Lambert Message-Id: <199612170113.SAA04996@phaeton.artisoft.com> Subject: Re: Heidemann Framework integration (Re: Other filesystems under FreeBSD) To: michaelh@cet.co.jp (Michael Hancock) Date: Mon, 16 Dec 1996 18:13:37 -0700 (MST) Cc: terry@lambert.org, koshy@india.hp.com, freebsd-hackers@freefall.freebsd.org In-Reply-To: from "Michael Hancock" at Dec 17, 96 09:58:49 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-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > The main problem areas in the 4.4BSD/FreeBSD implementation of the > > Heidemann framework are: > > > > There are also vops that don't take a vp as a parameter. bwrite and > bstrategy. They should; more likely, blocked I/O should be implemented as a layer above the FS. The devfs code is a very special case if you don't have specfs or allow device nodes on other FS's (you can use symlinks for the same effect). Given that, if there were still a need for it, and it couldn't be represented in the uio struct, or in the name space by virtue of the vp that came back from the open, then VOP_IOCTL on the vp seems right. Anyway... that's part of "and so on...". 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-hackers Mon Dec 16 17:21:02 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id RAA22152 for hackers-outgoing; Mon, 16 Dec 1996 17:21:02 -0800 (PST) Received: from hub.org (root@hub.org [207.107.138.200]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id RAA22147 for ; Mon, 16 Dec 1996 17:21:00 -0800 (PST) Received: from localhost (scrappy@localhost) by hub.org (8.8.2/8.7.5) with SMTP id UAA13292 for ; Mon, 16 Dec 1996 20:20:57 -0500 (EST) Date: Mon, 16 Dec 1996 20:20:55 -0500 (EST) From: "Marc G. Fournier" To: hackers@freebsd.org Subject: Almost have mmap() figured, I think... Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Evening... Altho I really hate to ask, I think I almost have this licked, but there is something I'm still missing, so the code isn't *quite* working the way it should. Essentially, to simplify things while I "understand it better", I've created n mmap()'d regions, each representing a frame. There are n corresponding mmap()'d regions, each of which correspond to the *size* of the frame. (I know, inelegant, but I can make it more elegant *after* I know better that which I'm doing...) The regions are being created as: ====== while(ii < FRAMES) { sprintf(framestr, "/tmp/frame-%02d", ii); /* Setup Video Stream Buffer */ if((fd = open(framestr, O_RDWR|O_CREAT, 0666)) < 0) { fprintf(stderr, "cannot open %s\n", framestr); exit(-1); } ftruncate(fd, FRAMESIZE); if((frame[ii] = mmap(0, FRAMESIZE, PROT_READ|PROT_WRITE, MAP_SHARED, fd, 0)) == (caddr_t) -1) { fprintf(stderr, "cannot mmap frame buffer #%02d\n", ii); exit(-1); } close(fd); } ===== Where frame[ii] is declared as "caddr_t frame[FRAMES];":$ Now, the information that is being written to each frame is coming from a socket, which all worked before I switched over to mmap(), and is read in as: ----- void readn(int fd, char *buf, size_t bytes) { int n; char *p = buf; while (bytes) { n = read(fd, p, bytes); if (n < 0) fprintf(stderr, "read failed in send-photo.cgi"); if (n == 0 && bytes != 0) fprintf(stderr, "short file on read, %d bytes left", bytes); bytes -= n; p += n; } } ---- And is being called as: ===== readn(sockfd, frame[ii], datasize); ===== Now, this is where I think I'm making my mistake, because the results of running this code is: hub> ./client Frame == 000, ii == 00, datasize == 1944, Size == 1944 Frame == 001, ii == 01, datasize == 1981, Size == 1981 Frame == 002, ii == 02, datasize == 1972, Size == 1972 Frame == 003, ii == 03, datasize == 1990, Size == 1990 Frame == 004, ii == 04, datasize == 2006, Size == 2006 Frame == 005, ii == 05, datasize == 1985, Size == 1985 Frame == 006, ii == 06, datasize == 2021, Size == 2021 Frame == 007, ii == 07, datasize == 2034, Size == 2034 Frame == 008, ii == 08, datasize == 1984, Size == 1984 Frame == 009, ii == 09, datasize == 2023, Size == 2023 Frame == 010, ii == 10, datasize == 2047, Size == 2047 datasize is what I got from the remote server, through the socket, Size is what the 'size' mmap()'d region sees, so that mapping is working fine. The 'client' that is reading the mmap()'d region is seeing the exact same size value as the server is writting to it...so that aspect is working right. The problem comes up when I try and print out the frame itself, using 'printf("%s\n", frame[ii]);'...the value printed out each time is exactly the same: Ack, okay...just tried something quickly, and changed %s to %d, and the results are: hub> ./client Frame == 000, ii == 00, datasize == 1944, Size == 1944 134840320 Frame == 001, ii == 01, datasize == 1981, Size == 1981 134860800 Frame == 002, ii == 02, datasize == 1972, Size == 1972 134881280 Frame == 003, ii == 03, datasize == 1990, Size == 1990 134905856 Frame == 004, ii == 04, datasize == 2006, Size == 2006 134930432 So...am I accurate in assuming that what I'm getting is the memory location? I still don't understand this fully, so please bear with me...I'm *purely* guessing here :( So, I'm making the assumption that either the way I'm calling, or using, readn() is incorrect for use with mmap()'d regions...would I be better off to read in the socket, then memcpy() the data, or strncpy()? Or is what I'm missing even more simple then that? Thanks again... Marc G. Fournier scrappy@hub.org Systems Administrator @ hub.org scrappy@freebsd.org From owner-freebsd-hackers Mon Dec 16 18:03:29 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id SAA24539 for hackers-outgoing; Mon, 16 Dec 1996 18:03:29 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id SAA24534 for ; Mon, 16 Dec 1996 18:03:25 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id TAA07421; Mon, 16 Dec 1996 19:01:54 -0700 From: Terry Lambert Message-Id: <199612170201.TAA07421@phaeton.artisoft.com> Subject: Re: Almost have mmap() figured, I think... To: scrappy@hub.org (Marc G. Fournier) Date: Mon, 16 Dec 1996 19:01:54 -0700 (MST) Cc: hackers@freebsd.org In-Reply-To: from "Marc G. Fournier" at Dec 16, 96 08:20:55 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-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > Altho I really hate to ask, I think I almost have this licked, but > there is something I'm still missing, so the code isn't *quite* working the > way it should. > > Essentially, to simplify things while I "understand it better", > I've created n mmap()'d regions, each representing a frame. There are > n corresponding mmap()'d regions, each of which correspond to the > *size* of the frame. (I know, inelegant, but I can make it more > elegant *after* I know better that which I'm doing...) [ ... ] > The regions are being created as: > > ====== > while(ii < FRAMES) { > sprintf(framestr, "/tmp/frame-%02d", ii); > > /* Setup Video Stream Buffer */ > if((fd = open(framestr, O_RDWR|O_CREAT, 0666)) < 0) { > fprintf(stderr, "cannot open %s\n", framestr); > exit(-1); > } > ftruncate(fd, FRAMESIZE); > if((frame[ii] = > mmap(0, FRAMESIZE, PROT_READ|PROT_WRITE, MAP_SHARED, fd, 0)) > == (caddr_t) -1) { > fprintf(stderr, "cannot mmap frame buffer #%02d\n", ii); > exit(-1); > } > close(fd); > } Alternately: start = mmap( 0, FRAMESIZE * FRAMES, PROT_READ|PROT_WRITE, MAP_SHARED, fd, 0)); for( i = 0; i < FRAMES; i++) frame[i] = start + i * FRAMESIZE; And use one file... 8-). Also: Are you mapping in both the client and the server? Or just the server? > The problem comes up when I try and print out the frame itself, > using 'printf("%s\n", frame[ii]);'...the value printed out each time > is exactly the same: What is the data in the frame? Maybe that's right? printf("%s", ...) will stop printing if it hit a <00>... > So, I'm making the assumption that either the way I'm calling, or > using, readn() is incorrect for use with mmap()'d regions...would I be > better off to read in the socket, then memcpy() the data, or strncpy()? Or > is what I'm missing even more simple then that? No; reading directly is a win. 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-hackers Mon Dec 16 19:11:38 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id TAA21741 for hackers-outgoing; Mon, 16 Dec 1996 19:11:38 -0800 (PST) Received: from who.cdrom.com (who.cdrom.com [204.216.27.3]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id TAA21731 for ; Mon, 16 Dec 1996 19:11:35 -0800 (PST) Received: from hub.org (root@hub.org [207.107.138.200]) by who.cdrom.com (8.7.5/8.6.11) with ESMTP id SAA26868 for ; Mon, 16 Dec 1996 18:40:36 -0800 (PST) Received: from localhost (scrappy@localhost) by hub.org (8.8.2/8.7.5) with SMTP id VAA17390; Mon, 16 Dec 1996 21:38:36 -0500 (EST) Date: Mon, 16 Dec 1996 21:38:34 -0500 (EST) From: "Marc G. Fournier" To: Terry Lambert cc: hackers@FreeBSD.ORG Subject: Re: Almost have mmap() figured, I think... In-Reply-To: <199612170201.TAA07421@phaeton.artisoft.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Mon, 16 Dec 1996, Terry Lambert wrote: > start = mmap( 0, FRAMESIZE * FRAMES, PROT_READ|PROT_WRITE, MAP_SHARED, fd, 0)); > for( i = 0; i < FRAMES; i++) > frame[i] = start + i * FRAMESIZE; > Okay, that one makes sense... Then, would it make sense to also have: size = mmap( 0, sizeof(int) * FRAMES, PROT_READ|PROT_WRITE, MAP_SHARED, fd, 0)); for(i = 0; i < FRAMES; i++) framesize[i] = start + i * sizeof(int); ? > And use one file... 8-). > Okay, will convert that over...makes for one less point of failure :) > Also: Are you mapping in both the client and the server? Or just the server? > Not quite sure what you mean here...client has: ==== while(ii < FRAMES) { if((fd = open(framestr, O_RDONLY)) < 0) { exit(-1); } if((video[ii] = mmap(0, FRAMESIZE, PROT_READ, MAP_SHARED, fd, 0)) == (caddr_t) -1) { exit(-1); } close(fd); /* Get Video Stream Buffer */ if((fd = open(framestr, O_RDONLY)) < 0) { exit(-1); } if((vsize[ii] = mmap(0, sizeof(int), PROT_READ, MAP_SHARED, fd, 0)) == (caddr_t) -1) { exit(-1); } close(fd); ii++; } ==== I'm using "Advanced Programming in the Unix Environment" by Stevens as my new "bible", and it states that "MAP_SHARED or MAP_PRIVATE must be specified"...unfortunately, his only "example" happens to have two different files MMAP'd, and then he's doing an memcpy() between them :( Is the above incorrect? > > The problem comes up when I try and print out the frame itself, > > using 'printf("%s\n", frame[ii]);'...the value printed out each time > > is exactly the same: > > What is the data in the frame? Maybe that's right? printf("%s", ...) > will stop printing if it hit a <00>... > Binary data, so this may be correct, since the "data" that I'm getting on the opposite end is exactly the same as the data on the server end... Marc G. Fournier scrappy@hub.org Systems Administrator @ hub.org scrappy@freebsd.org From owner-freebsd-hackers Mon Dec 16 19:35:24 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id TAA22855 for hackers-outgoing; Mon, 16 Dec 1996 19:35:24 -0800 (PST) Received: from cactus.fi.uba.ar (cactus.fi.uba.ar [157.92.49.108]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id TAA22847; Mon, 16 Dec 1996 19:35:18 -0800 (PST) Received: (from msagre@localhost) by cactus.fi.uba.ar (8.6.12/8.6.12) id AAA29907; Tue, 17 Dec 1996 00:34:41 -0300 Date: Tue, 17 Dec 1996 00:34:40 -0300 (ARST) From: Miguel Angel Sagreras To: Randall Hopper cc: hackers@freebsd.org, emulation@freebsd.org Subject: Re: APPLIXWARE on FreeBSD? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Mon, 16 Dec 1996, Randall Hopper wrote: > Has anyone successfully run Applixware for Redhat Linux on FreeBSD? If so > (with good or bad results) I'd be interested in hearing from you. > > Thanks, > > Randall Hopper > rhh@ct.picker.com > It works fine. Miguel A. Sagreras Facultad de ingenieria Universidad de Buenos Aires e-mail : msagre@cactus.fi.uba.ar From owner-freebsd-hackers Mon Dec 16 20:54:49 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id UAA27250 for hackers-outgoing; Mon, 16 Dec 1996 20:54:49 -0800 (PST) Received: from nike.efn.org (resnet.uoregon.edu [128.223.170.28]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id UAA27236 for ; Mon, 16 Dec 1996 20:54:36 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by nike.efn.org (8.8.3/8.8.3) with SMTP id TAA07496; Mon, 16 Dec 1996 19:32:43 -0800 (PST) Date: Mon, 16 Dec 1996 19:32:41 -0800 (PST) From: John-Mark Gurney X-Sender: jmg@nike Reply-To: John-Mark Gurney To: Joao Carlos Mendes Luis cc: freebsd-hackers@freebsd.org Subject: Re: talk and talkd In-Reply-To: <199612161855.QAA26056@gaia.coppe.ufrj.br> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Mon, 16 Dec 1996, Joao Carlos Mendes Luis wrote: > ytalk is X, right ? it uses X if you have it... but it also supports text interface also... John-Mark gurney_j@efn.org http://resnet.uoregon.edu/~gurney_j/ Modem/FAX: (541) 683-6954 (FreeBSD Box) Live in Peace, destroy Micro$oft, support free software, run FreeBSD (unix) From owner-freebsd-hackers Mon Dec 16 21:19:20 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id VAA28612 for hackers-outgoing; Mon, 16 Dec 1996 21:19:20 -0800 (PST) Received: from cyclone.degnet.baynet.de (root@cyclone.degnet.baynet.de [194.95.214.129]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id VAA28607 for ; Mon, 16 Dec 1996 21:19:16 -0800 (PST) Received: from nada (ppp3 [194.95.214.133]) by cyclone.degnet.baynet.de (8.6.12/8.6.9) with SMTP id HAA18540; Tue, 17 Dec 1996 07:20:56 +0100 Message-Id: <3.0.32.19961217061222.006b43d0@cyclone.degnet.baynet.de> X-Sender: moos@cyclone.degnet.baynet.de X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Tue, 17 Dec 1996 06:12:23 -0100 To: roberto@keltia.freenix.fr (Ollivier Robert) From: Darius Moos Subject: Re: Running Linux' Acrobat reader under 215R? Cc: freebsd-hackers@FreeBSD.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk If you just want to read .pdf-files, you could use xpdf. Darius Moos. At 21:58 16.12.96 +0100, you wrote: >According to Wilko Bulte: >> I did not pay much attention to Linux emulation in the past, so I'm >> wondering if ELF linux binaries have any chance of working anyway. >> This is on 2.1.5R with COMPAT_LINUX etc in the kernel. > >Forget about ELF in 2.1.*. Only 2.2+ versions are able to run ELF binaries, >be they FreeBSD or Linux ones. There is a port for 3.0-CURRENT of acroread >in ports/print/acroread. > >-- >Ollivier ROBERT -=- The daemon is FREE! -=- roberto@keltia.freenix.fr > FreeBSD keltia.freenix.fr 3.0-CURRENT #31: Tue Dec 3 23:52:58 CET 1996 > > From owner-freebsd-hackers Mon Dec 16 23:26:44 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id XAA05694 for hackers-outgoing; Mon, 16 Dec 1996 23:26:44 -0800 (PST) Received: from Campino.Informatik.RWTH-Aachen.DE (campino.Informatik.RWTH-Aachen.DE [137.226.116.240]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id XAA05688 for ; Mon, 16 Dec 1996 23:26:41 -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 IAA11715; Tue, 17 Dec 1996 08:28:22 +0100 (MET) Received: (from kuku@localhost) by gilberto.physik.rwth-aachen.de (8.8.3/8.6.9) id IAA18027; Tue, 17 Dec 1996 08:40:41 +0100 (MET) From: Christoph Kukulies Message-Id: <199612170740.IAA18027@gilberto.physik.rwth-aachen.de> Subject: Re: Running Linux' Acrobat reader under 215R? In-Reply-To: <3.0.32.19961217061222.006b43d0@cyclone.degnet.baynet.de> from Darius Moos at "Dec 17, 96 06:12:23 am" To: moos@webmore.com (Darius Moos) Date: Tue, 17 Dec 1996 08:40:41 +0100 (MET) Cc: roberto@keltia.freenix.fr, freebsd-hackers@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-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > If you just want to read .pdf-files, you could use xpdf. xpdf is known to be inadequate or insufficient in some respects. > > Darius Moos. > > At 21:58 16.12.96 +0100, you wrote: > >According to Wilko Bulte: > >> I did not pay much attention to Linux emulation in the past, so I'm > >> wondering if ELF linux binaries have any chance of working anyway. > >> This is on 2.1.5R with COMPAT_LINUX etc in the kernel. > > > >Forget about ELF in 2.1.*. Only 2.2+ versions are able to run ELF binaries, > >be they FreeBSD or Linux ones. There is a port for 3.0-CURRENT of acroread > >in ports/print/acroread. > > > >-- > >Ollivier ROBERT -=- The daemon is FREE! -=- roberto@keltia.freenix.fr > > FreeBSD keltia.freenix.fr 3.0-CURRENT #31: Tue Dec 3 23:52:58 CET 1996 > > > > > --Chris Christoph P. U. Kukulies kuku@gil.physik.rwth-aachen.de From owner-freebsd-hackers Mon Dec 16 23:51:26 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id XAA07030 for hackers-outgoing; Mon, 16 Dec 1996 23:51:26 -0800 (PST) Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id XAA07023 for ; Mon, 16 Dec 1996 23:51:22 -0800 (PST) Received: (from msmith@localhost) by genesis.atrad.adelaide.edu.au (8.8.2/8.7.3) id SAA25768; Tue, 17 Dec 1996 18:16:41 +1030 (CST) From: Michael Smith Message-Id: <199612170746.SAA25768@genesis.atrad.adelaide.edu.au> Subject: Re: Running Linux' Acrobat reader under 215R? In-Reply-To: <199612170740.IAA18027@gilberto.physik.rwth-aachen.de> from Christoph Kukulies at "Dec 17, 96 08:40:41 am" To: kuku@gilberto.physik.rwth-aachen.de Date: Tue, 17 Dec 1996 18:16:39 +1030 (CST) Cc: moos@webmore.com, roberto@keltia.freenix.fr, freebsd-hackers@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-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Christoph Kukulies stands accused of saying: > > If you just want to read .pdf-files, you could use xpdf. > > xpdf is known to be inadequate or insufficient in some respects. This is mostly in connection with "encrypted" PDF files, and is due to the usual anal export restrictions. I don't know what Adobe do with Acrobat; I read PDF files with gv and ghostscript and the RC4 patch. > --Chris Christoph P. U. Kukulies kuku@gil.physik.rwth-aachen.de -- ]] 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-hackers Mon Dec 16 23:58:02 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id XAA07226 for hackers-outgoing; Mon, 16 Dec 1996 23:58:02 -0800 (PST) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id XAA07220 for ; Mon, 16 Dec 1996 23:57:55 -0800 (PST) Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.3/8.6.9) id SAA13178; Tue, 17 Dec 1996 18:55:12 +1100 Date: Tue, 17 Dec 1996 18:55:12 +1100 From: Bruce Evans Message-Id: <199612170755.SAA13178@godzilla.zeta.org.au> To: julian@whistle.com, terry@lambert.org Subject: Re: Boot loader hacks was: Re: MAXMEM Cc: eivind@dimaga.com, hackers@freebsd.org, jonny@mailhost.coppe.ufrj.br, tony@dell.com Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >> No; the kernel assumes what you tell it is true. If you use the >> MAXMEM option, you are eternally stuck with that memory for that >> particular kernel. Take it to a machine with more memory, and >> you don't use the extra; take it to a machine with less, and you >> are screwed. This has been fixed for a month or two. You can now set the memory size using `iosize npx0 whatever' in userconfig. >I added code to OSF1/x86 to look for more ram and add it to the ammount >reported by the bios.. it wasn't that hard!! > >the problem is that it needs to be done very early so that >an access to non-existant memory doesn't produce an NMI >when read from (on parity systems) or other similar problems.. The problem is that it can't be done in general. The main problem is that probing device memory may damage devices. Other problems include: - you have to distinguish read/write device memory from RAM. - you have to do something machine-dependent turn off the parity checking or handle NMIs very carefully. - you have to handle discontiguous memory. - you may have to handle mirrors (memory repeating every 256M or so). I'm not sure if this is a problem on 386 systems. Bruce From owner-freebsd-hackers Tue Dec 17 01:03:09 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id BAA09721 for hackers-outgoing; Tue, 17 Dec 1996 01:03:09 -0800 (PST) Received: from ghpc6.ihf.rwth-aachen.de (ghpc6.ihf.RWTH-Aachen.DE [134.130.90.6]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id BAA09713 for ; Tue, 17 Dec 1996 01:03:00 -0800 (PST) Received: (from thomas@localhost) by ghpc6.ihf.rwth-aachen.de (8.6.12/8.6.9) id JAA24959; Tue, 17 Dec 1996 09:33:28 +0100 From: Thomas Gellekum Message-Id: <199612170833.JAA24959@ghpc6.ihf.rwth-aachen.de> Subject: Re: Running Linux' Acrobat reader under 215R? To: msmith@atrad.adelaide.edu.au (Michael Smith) Date: Tue, 17 Dec 1996 09:33:26 +0100 (MET) Cc: kuku@gilberto.physik.RWTH-Aachen.DE, moos@webmore.com, roberto@keltia.freenix.fr, freebsd-hackers@freebsd.org In-Reply-To: <199612170746.SAA25768@genesis.atrad.adelaide.edu.au> from Michael Smith at "Dec 17, 96 06:16:39 pm" Organization: Institut f. Hochfrequenztechnik, RWTH Aachen X-Mailer: ELM [version 2.4ME+ PL11 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Michael Smith wrote: > Christoph Kukulies stands accused of saying: > > > If you just want to read .pdf-files, you could use xpdf. > > > > xpdf is known to be inadequate or insufficient in some respects. > > This is mostly in connection with "encrypted" PDF files, and is due > to the usual anal export restrictions. I don't know what Adobe do with > Acrobat; I read PDF files with gv and ghostscript and the RC4 patch. Well, last week I came across a damaged PDF file, which acrobat could fix. gs just barfed on it. tg, who is glad that there are many tools for one task From owner-freebsd-hackers Tue Dec 17 03:06:05 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id DAA15203 for hackers-outgoing; Tue, 17 Dec 1996 03:06:05 -0800 (PST) Received: from news.IAEhv.nl (root@news.IAEhv.nl [194.151.64.4]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id DAA15198 for ; Tue, 17 Dec 1996 03:06:02 -0800 (PST) Received: from truk.brandinnovators.com (uucp@localhost) by news.IAEhv.nl (8.6.13/1.63) with IAEhv.nl; pid 6931 on Tue, 17 Dec 1996 11:42:52 +0100; id LAA06931 efrom: hans@truk.brandinnovators.com; eto: freebsd-hackers@freebsd.org Received: by truk.brandinnovators.com (8.7.5/BI96070101) for id LAA00895; Tue, 17 Dec 1996 11:37:45 GMT Message-Id: <199612171137.LAA00895@truk.brandinnovators.com> From: hans@brandinnovators.com (Hans Zuidam) Subject: Re: Running Linux' Acrobat reader under 215R? To: freebsd-hackers@freebsd.org Date: Tue, 17 Dec 1996 11:37:45 +0000 () In-Reply-To: <199612170833.JAA24959@ghpc6.ihf.rwth-aachen.de> from Thomas Gellekum at "Dec 17, 96 09:33:26 am" X-Mailer: ELM [version 2.4ME+ PL22 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > Thomas Gellekum wrote: > Michael Smith wrote: > > Christoph Kukulies stands accused of saying: > > > > If you just want to read .pdf-files, you could use xpdf. > > > > > > xpdf is known to be inadequate or insufficient in some respects. > > > > This is mostly in connection with "encrypted" PDF files, and is due > > to the usual anal export restrictions. I don't know what Adobe do with > > Acrobat; I read PDF files with gv and ghostscript and the RC4 patch. > > Well, last week I came across a damaged PDF file, which acrobat could > fix. gs just barfed on it. Hmmm... I've got some pdf files that make acrobat (v2 and v3!) barf while xpdf simply spits out warnings and continues with the next page... > tg, who is glad that there are many tools for one task hz, who is very glad that the freely available tools are often more robust than their commercial counterparts -- H. Zuidam E-Mail: hans@brandinnovators.com Brand Innovators B.V. P-Mail: P.O. Box 1377 de Pinckart 54 5602 BJ Eindhoven, The Netherlands 5674 CC Nuenen Tel. +31 40 2631134, Fax. +31 40 2831138 From owner-freebsd-hackers Tue Dec 17 04:02:38 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id EAA18287 for hackers-outgoing; Tue, 17 Dec 1996 04:02:38 -0800 (PST) Received: from pdx1.world.net (pdx1.world.net [192.243.32.18]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id EAA18280 for ; Tue, 17 Dec 1996 04:02:35 -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 EAA29817 for ; Tue, 17 Dec 1996 04:02:41 -0800 (PST) Received: (qmail 4780 invoked by uid 110); 17 Dec 1996 12:01:30 -0000 Message-ID: <19961217120130.4779.qmail@suburbia.net> Subject: Re: sendmail... In-Reply-To: <199612170931.KAA05839@tiger.cert.dfn.de> from Wolfgang Ley at "Dec 17, 96 10:31:24 am" To: ley@cert.dfn.de (Wolfgang Ley) Date: Tue, 17 Dec 1996 23:01:30 +1100 (EST) Cc: vitjok@fasts.com, freebsd-security@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-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk -- Start of PGP signed section. > Victor Rotanov wrote: > > > > Hello. > > > > Why sendmail can't be replaced with something more secure by default? > > I'd suggest Zmailer which can be fount at > > ftp://ftp.funet.fi/pub/unix/mail/zmailer > > It is also seems to be faster than sendmail on high loads. > > Proof that Zmailer ist more secure than sendmail (note: "there are no/less > *known* security bugs" doesn't count because people most probably haven't > bothered to investigate Zmailer/Smail/Qmail/... in the same depth as > sendmail). > > Bye, > Wolfgang. > -- > Wolfgang Ley, DFN-CERT, Vogt-Koelln-Str. 30, 22527 Hamburg, Germany Proof that you haven't investigated Qmail (I can't comment on Zmailer, and I wouldn't trust Smail any more than sendmail, although apparently Debian linux does) - Qmail is a well thought out example of functional compartmentalisation and least-privilege. I strongly suggest people take a good look at the code, and consider making qmail the default MTA for FreeBSD. Qmail handles virtual domains, mail-tables etc, without any sendmail.cf trickery, which even after 10 years and m4 is not something I do in my sleep. Sendmail is a monolithic suid patchwork quilt. Qmail is very much in keeping with the unix paradigm of division of labours and despite it's strong security stance actually seems more efficient than sendmail. Someone suggested on this subject that FreeBSD would be the laughing stock of the network community if it dropped sendmail8(!). This is strange perspective. I had thought *sendmail* was the laughing stock of the networking, security and cracker communities. -Julian (proff@suburbia.net) // attached: qmail/SECURITY Background: Every few months CERT announces Yet Another Security Hole In Sendmail---something that lets local or even remote users take complete control of the machine. I'm sure there are many more holes waiting to be discovered; sendmail's design means that any minor bug in 46000 lines of code is a major security risk. Other popular mailers, such as Smail, and even mailing-list managers, such as Majordomo, seem just as bad. I started working on qmail because I was sick of this cycle of doom. Here are some of the things I did to make sure that qmail will never let an intruder into your machine. 1. Programs and files are not addresses. Don't treat them as addresses. sendmail treats programs and files as addresses. Obviously random people can't be allowed to execute arbitrary programs or write to arbitrary files, so sendmail goes through horrendous contortions trying to keep track of whether a local user was ``responsible'' for an address. This has proven to be an unmitigated disaster. In qmail, programs and files are not addresses. The local delivery agent, qmail-alias, can run programs or write to files as directed by ~user/.qmail, but it's always running as that user. (The notion of ``user'' is configurable, but root is never a user. To prevent silly mistakes, qmail-alias makes sure that neither ~user nor ~user/.qmail is group-writable or world-writable.) Security impact: .qmail, like .cshrc and .exrc and various other files, means that anyone who can write arbitrary files as a user can execute arbitrary programs as that user. That's it. 2. Do as little as possible in setuid programs. A setuid program must operate in a very dangerous environment: a user is under complete control of its fds, args, environ, cwd, tty, rlimits, timers, signals, and more. Even worse, the list of controlled items varies from one vendor's UNIX to the next, so it is very difficult to write portable code that cleans up everything. Of the twelve most recent sendmail security holes, six worked only because the entire sendmail system is setuid. Only one qmail program is setuid: qmail-queue. Its only purpose is to add a new mail message to the outgoing queue. 3. Do as little as possible as root. The entire sendmail system runs as root, so there's no way that its mistakes can be caught by the operating system's built-in protections. In contrast, only two qmail programs, qmail-start and qmail-lspawn, run as root. 4. Move separate functions into mutually untrusting programs. Five of the qmail programs---qmail-smtpd, qmail-send, qmail-rspawn, qmail-remote, and tcp-env---are not security-critical. Even if all of these programs are completely compromised, so that an intruder has control over the qmaild, qmails, and qmailr accounts and the mail queue, he still can't take over your system. None of the other programs trust the results from these five. In fact, these programs don't even trust each other. They are in three groups: tcp-env and qmail-smtpd, which run as qmaild; qmail-rspawn and qmail-remote, which run as qmailr; and qmail-send, the queue manager, which runs as qmails. Each group is immune from attacks by the others. (From root's point of view, as long as root doesn't send any mail, only qmail-start and qmail-lspawn are security-critical. They don't write any files or start any other programs as root.) 5. Don't parse. I have discovered that there are two types of command interfaces in the world of computing: good interfaces and user interfaces. The essence of user interfaces is _parsing_---converting an unstructured sequence of commands, in a format usually determined more by psychology than by solid engineering, into structured data. When another programmer wants to talk to a user interface, he has to _quote_: convert his structured data into an unstructured sequence of commands that the parser will, he hopes, convert back into the original structured data. This situation is a recipe for disaster. The parser often has bugs: it fails to handle some inputs according to the documented interface. The quoter often has bugs: it produces outputs that do not have the right meaning. Only on rare joyous occasions does it happen that the parser and the quoter both misinterpret the interface in the same way. When the original data is controlled by a malicious user, many of these bugs translate into security holes. Some examples: the Linux login -froot security hole; the classic find | xargs rm security hole; the recent Majordomo security hole. Even a simple parser like getopt is complicated enough for people to screw up the quoting. In qmail, all the internal file structures are incredibly simple: text0 lines beginning with single-character commands. (text0 format means that lines are separated by a 0 byte instead of line feed.) The program-level interfaces don't take options. All the complexity of parsing RFC 822 address lists and rewriting headers is in the qmail-inject program, which runs without privileges and is essentially part of the UA. The only nasty case is .qmail, qmail's answer to .forward. I tried to make this as simple as possible, but unfortunately it still has to be edited by users. As a result, the qlist mailing-list-management program has to be careful to exclude subscriber addresses that contain newlines. 6. Keep it simple, stupid. See BLURB for some of the reasons that qmail is so much smaller than sendmail. There's nothing inherently complicated about writing a mailer. (Except RFC 822 support; but that's only in qmail-inject.) Security holes can't show up in features that don't exist. 7. Write bug-free code. I've mostly given up on the standard C library. Many of its facilities, particularly stdio, seem designed to encourage bugs. A big chunk of qmail is stolen from a basic C library that I've been developing for several years for a variety of applications. The stralloc concept and getline2() make it very easy to avoid buffer overruns, memory leaks, and artificial line length limits. From owner-freebsd-hackers Tue Dec 17 04:55:40 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id EAA21991 for hackers-outgoing; Tue, 17 Dec 1996 04:55:40 -0800 (PST) Received: from Campino.Informatik.RWTH-Aachen.DE (campino.Informatik.RWTH-Aachen.DE [137.226.116.240]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id EAA21960 for ; Tue, 17 Dec 1996 04:54:19 -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 NAA19511 for ; Tue, 17 Dec 1996 13:03:02 +0100 (MET) Received: (from kuku@localhost) by gilberto.physik.rwth-aachen.de (8.8.3/8.6.9) id NAA19291 for freebsd-hackers@freefall.cdrom.com; Tue, 17 Dec 1996 13:14:12 +0100 (MET) Date: Tue, 17 Dec 1996 13:14:12 +0100 (MET) From: Christoph Kukulies Message-Id: <199612171214.NAA19291@gilberto.physik.rwth-aachen.de> To: freebsd-hackers@freefall.FreeBSD.org Subject: PPRO lat_mem_rd figures? Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk I'm still seeking for the mistery why my PPRO 200/256 seems slow: (ASUS P6NP5) lat_mem_rd 8 128: $Id: lat_mem_rd.c,v 1.1 1994/11/18 08:49:48 lm Exp $ $Id: mhz.c,v 1.1 1994/11/18 08:51:55 lm Exp $ "stride=128 0.00049 10 <-- 0.00098 10 <-- 0.00195 10 <-- 0.00293 10 0.00391 10 0.00586 10 0.00781 10 0.00977 22 0.01172 30 0.01367 30 0.01562 30 0.01758 30 0.01953 30 0.02148 30 0.02344 30 0.02539 30 0.02734 30 0.02930 30 0.03125 30 0.03516 30 0.03906 30 0.04297 30 0.04688 30 0.05078 30 0.05469 30 0.05859 30 0.06250 30 0.07031 30 0.07812 30 0.08594 67 0.09375 64 0.10156 61 0.10938 59 0.11719 57 0.12500 55 0.14062 75 0.15625 79 0.17188 93 0.18750 91 0.20312 106 0.21875 106 0.23438 131 0.25000 125 0.28125 146 0.31250 159 0.34375 166 0.37500 180 0.40625 177 0.43750 175 0.46875 181 0.50000 186 1.00000 197 1.50000 197 2.00000 196 2.50000 197 3.00000 197 3.50000 196 4.00000 196 4.50000 197 5.00000 197 5.50000 199 6.00000 197 6.50000 196 7.00000 197 7.50000 197 8.00000 197 clk=5.04 A P166 with 512K external cache gives this (ASUS P55TP4N) : $Id: lat_mem_rd.c,v 1.1 1994/11/18 08:49:48 lm Exp $ $Id: mhz.c,v 1.1 1994/11/18 08:51:55 lm Exp $ "stride=128 0.00049 6 0.00098 6 0.00195 6 0.00293 6 0.00391 6 0.00586 6 0.00781 6 0.00977 59 0.01172 95 0.01367 95 Any better PPRO figures welcome. --Chris Christoph P. U. Kukulies kuku@gil.physik.rwth-aachen.de From owner-freebsd-hackers Tue Dec 17 05:04:10 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id FAA22343 for hackers-outgoing; Tue, 17 Dec 1996 05:04:10 -0800 (PST) Received: from gw.muc.ditec.de (gw.muc.ditec.de [194.120.126.3]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id FAA22331 for ; Tue, 17 Dec 1996 05:04:03 -0800 (PST) Received: (from nobody@localhost) by gw.muc.ditec.de (8.7.5/8.6.9) id OAA29414 for ; Tue, 17 Dec 1996 14:04:11 +0100 (MET) X-Authentication-Warning: gw.muc.ditec.de: nobody set sender to using -f Received: from tartufo.muc.ditec.de(134.98.18.2) by gw.muc.ditec.de via smap (V2.0alpha) id sma029412; Tue Dec 17 14:03:51 1996 Received: by tartufo.muc.ditec.de (/\=-/\ Smail3.1.16.1 #16.39) id ; Tue, 17 Dec 96 10:56 MEZ Message-Id: Date: Tue, 17 Dec 96 14:06 MEZ From: me@tartufo.muc.ditec.de (Michael Elbel) To: guido@gvr.win.tue.nl Cc: hackers@freebsd.org Subject: Re: notebook: which one Newsgroups: lists.freebsd.hackers References: <199612131252.NAA04767@gvr.win.tue.nl> Reply-To: me@gw.muc.ditec.de X-Newsreader: NN version 6.5.0 #1 (NOV) Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In lists.freebsd.hackers you write: >I am looking for a notebook that is well supported under FreeBSD. >It should have 16 mb and a decent screen and have either a 0.5 or 1.0 >gigabyte fixed disk. I am particularly interested in which brand is the best >to choose. Just one for the record. We've had good results with NEC Versas here. The (albeit a bit pricey) Versa 6030X (P133, 1.4GB Disk, 16 MB RAM standard, upgraded it to 48MB, 1024x768@16bpp Display) works like a charm. The latest XFree86 is running nicely in 1024x768 mode. Nate Williams originally recommended the NEC units, I haven't regretted it. Michael -- Michael Elbel, DITEC, Muenchen, Germany - me@muc.ditec.de Fermentation fault (coors dumped) From owner-freebsd-hackers Tue Dec 17 05:54:58 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id FAA24566 for hackers-outgoing; Tue, 17 Dec 1996 05:54:58 -0800 (PST) Received: from terra.Sarnoff.COM (terra.sarnoff.com [130.33.11.203]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id FAA24552 for ; Tue, 17 Dec 1996 05:54:54 -0800 (PST) Received: (from rminnich@localhost) by terra.Sarnoff.COM (8.6.12/8.6.12) id IAA07141; Tue, 17 Dec 1996 08:53:47 -0500 Date: Tue, 17 Dec 1996 08:53:46 -0500 (EST) From: "Ron G. Minnich" X-Sender: rminnich@terra To: "Marc G. Fournier" cc: hackers@freebsd.org Subject: Re: Almost have mmap() figured, I think... In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > The problem comes up when I try and print out the frame itself, >using 'printf("%s\n", frame[ii]);'...the value printed out each time >is exactly the same: actually everything is right but your printf. This will print the pointer. to get data, e.g. the first word, ... unsigned long something; something = * (unsigned long *) frame[ii]; and so on. ron Ron Minnich |"Failure is not an option" -- Gene Kranz rminnich@sarnoff.com | -- except, of course, on Microsoft products (609)-734-3120 | ftp://ftp.sarnoff.com/pub/mnfs/www/docs/cluster.html From owner-freebsd-hackers Tue Dec 17 06:04:45 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id GAA24933 for hackers-outgoing; Tue, 17 Dec 1996 06:04:45 -0800 (PST) Received: from terra.Sarnoff.COM (terra.sarnoff.com [130.33.11.203]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id GAA24928 for ; Tue, 17 Dec 1996 06:04:41 -0800 (PST) Received: (from rminnich@localhost) by terra.Sarnoff.COM (8.6.12/8.6.12) id JAA07192; Tue, 17 Dec 1996 09:03:38 -0500 Date: Tue, 17 Dec 1996 09:03:38 -0500 (EST) From: "Ron G. Minnich" X-Sender: rminnich@terra To: "Marc G. Fournier" cc: hackers@freebsd.org Subject: Re: Almost have mmap() figured, I think... In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk whoops, sorry, i just realized i did not have enough coffee. Anyways, everything in your program looks like something I've tried and had work. I don't understand the %s results, but the %d results will print the pointer value unless you did dereference the frame[ii] pointer. Why not use 0x%x, make sure you deref the pointer, and let us see that result. note that: terra{rminnich}1: dc 16 o 134840320 p 8098000 So the second print you show is != the first. is your /tmp just a plain old ufs mount? nothing special there? Sure you're not just printing some frame header junk? Most picture files I deal with have a couple bytes of descriptors at the front. ron Ron Minnich |"Failure is not an option" -- Gene Kranz rminnich@sarnoff.com | -- except, of course, on Microsoft products (609)-734-3120 | ftp://ftp.sarnoff.com/pub/mnfs/www/docs/cluster.html From owner-freebsd-hackers Tue Dec 17 06:20:18 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id GAA25693 for hackers-outgoing; Tue, 17 Dec 1996 06:20:18 -0800 (PST) Received: from bacall.lodgenet.com (bacall.lodgenet.com [205.138.147.242]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id GAA25680 for ; Tue, 17 Dec 1996 06:20:09 -0800 (PST) Received: (from mail@localhost) by bacall.lodgenet.com (8.6.12/8.6.12) id IAA13689; Tue, 17 Dec 1996 08:18:47 -0600 Received: from garbo.lodgenet.com(204.124.123.250) by bacall via smap (V1.3) id sma013679; Tue Dec 17 08:18:42 1996 Received: from jake.lodgenet.com (jake.lodgenet.com [10.0.11.30]) by garbo.lodgenet.com (8.6.12/8.6.9) with ESMTP id IAA03773; Tue, 17 Dec 1996 08:19:03 -0600 Received: from jake.lodgenet.com (localhost [127.0.0.1]) by jake.lodgenet.com (8.8.3/8.6.12) with ESMTP id IAA08984; Tue, 17 Dec 1996 08:19:33 -0600 (CST) Message-Id: <199612171419.IAA08984@jake.lodgenet.com> X-Mailer: exmh version 1.6.9 8/22/96 To: "Marc G. Fournier" cc: Terry Lambert , hackers@freebsd.org Subject: Re: Almost have mmap() figured, I think... In-reply-to: Your message of "Mon, 16 Dec 1996 21:38:34 EST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 17 Dec 1996 08:19:33 -0600 From: "Eric L. Hernes" Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk "Marc G. Fournier" writes: >On Mon, 16 Dec 1996, Terry Lambert wrote: > >> start = mmap( 0, FRAMESIZE * FRAMES, PROT_READ|PROT_WRITE, MAP_SHARED, fd, 0 >)); >> for( i = 0; i < FRAMES; i++) >> frame[i] = start + i * FRAMESIZE; >> > Okay, that one makes sense... > > Then, would it make sense to also have: > >size = mmap( 0, sizeof(int) * FRAMES, PROT_READ|PROT_WRITE, MAP_SHARED, fd, 0) >); >for(i = 0; i < FRAMES; i++) > framesize[i] = start + i * sizeof(int); ^^^^^ you mean size, right? I think you could just make framesize an `int *' rather than an `int []', then `framesize = mmap(0, sizeof(int)*FRAMES ...);' and skip the for loop. then you should be able to refer to framesize[frameno] just as before... I think Terry was assuming that all your frames were the same size, I'm not sure that they are. It's a little more complicated when they're different sizes, but not impossible. you'll want to do something like int *framesize, total; caddr_t alldata, framedata[FRAMES]; framesize = mmap(0, sizeof(int) * FRAMES, ..., sizefd, 0); for(i=0; i The problem comes up when I try and print out the frame itself, >using 'printf("%s\n", frame[ii]);'...the value printed out each time >is exactly the same: this is probably right as Terry pointed out. > > Ack, okay...just tried something quickly, and changed %s to %d, and >the results are: > >hub> ./client >Frame == 000, ii == 00, datasize == 1944, Size == 1944 >134840320 ^^^^^^^^^ this should be an address. %s dereferences a pointer, %d prints the value. You could gdb attach to the process and examin the memory at this address just to see, it should start with (I think ;-) ) > So...am I accurate in assuming that what I'm getting is the memory >location? I still don't understand this fully, so please bear with me...I'm >*purely* guessing here :( Yes, mmap returns a pointer to the data, not the data directly. You can (have to) use it as any other pointer. Just as if you had malloc'ed it. These use structures, because it's easier to show when a pointer is being dereferenced versus just an offset of with structures than arrays. correct: struct mystruct *mystructp; mystructp=mmap(...); /*useful stuff with mystructp->members */ *incorrect*: struct mystruct mystruct; mystruct=mmap(...); /* useful stuff with mystruct.members*/ this will generate a compiler warning, because you're stuffing a pointer into a structure. (The first will too, but only because the mmap should have a cast) also correct (but clumsier): struct mystruct mystruct, *mystructp; mystructp=mmap(...); bcopy(mystructp, &mystruct, sizeof(mystruct)); /* useful stuff with mystruct.members */ > > So, I'm making the assumption that either the way I'm calling, or >using, readn() is incorrect for use with mmap()'d regions...would I be >better off to read in the socket, then memcpy() the data, or strncpy()? Or >is what I'm missing even more simple then that? No readn() should be ok. You can read directly instead of read/memcpy. strncpy() is almost certainly wrong unless you can be guaranteed there are no zeros in your data ;-) > >Marc G. Fournier scrappy@hub.org >Systems Administrator @ hub.org scrappy@freebsd.org > > eric. -- erich@lodgenet.com http://rrnet.com/~erich erich@rrnet.com From owner-freebsd-hackers Tue Dec 17 08:51:51 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id IAA05238 for hackers-outgoing; Tue, 17 Dec 1996 08:51:51 -0800 (PST) Received: from agora.rdrop.com (root@agora.rdrop.com [199.2.210.241]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id IAA05233 for ; Tue, 17 Dec 1996 08:51:50 -0800 (PST) Received: from austin.polstra.com by agora.rdrop.com with smtp (Smail3.1.29.1 #17) id m0va2k3-0008uoC; Tue, 17 Dec 96 08:51 PST Received: from austin.polstra.com (jdp@localhost) by austin.polstra.com (8.8.3/8.8.3) with ESMTP id IAA18388 for ; Tue, 17 Dec 1996 08:47:59 -0800 (PST) Message-Id: <199612171647.IAA18388@austin.polstra.com> To: freebsd-hackers@freebsd.org Subject: Location of the cvsup-14.0 package Date: Tue, 17 Dec 1996 08:47:59 -0800 From: John Polstra Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk A few people have told me that they can't find the package for the CVSup 14.0 port. (I mean package as in "the FreeBSD ports and packages collection.") Here's where it is: ftp://ftp.freebsd.org/pub/FreeBSD/packages-2.2/All/cvsup-14.0.tgz New packages all seem to be going into packages-2.2 these days. The newest package in packages-current is over a month old. I don't make the news, I just report it. :-) -- John Polstra jdp@polstra.com John D. Polstra & Co., Inc. Seattle, Washington USA "Self-knowledge is always bad news." -- John Barth From owner-freebsd-hackers Tue Dec 17 09:05:04 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id JAA06159 for hackers-outgoing; Tue, 17 Dec 1996 09:05:04 -0800 (PST) Received: from who.cdrom.com (who.cdrom.com [204.216.27.3]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id JAA06148 for ; Tue, 17 Dec 1996 09:05:01 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by who.cdrom.com (8.7.5/8.6.11) with SMTP id JAA27973 for ; Tue, 17 Dec 1996 09:04:46 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id KAA08511; Tue, 17 Dec 1996 10:01:37 -0700 From: Terry Lambert Message-Id: <199612171701.KAA08511@phaeton.artisoft.com> Subject: Re: Almost have mmap() figured, I think... To: scrappy@hub.org (Marc G. Fournier) Date: Tue, 17 Dec 1996 10:01:37 -0700 (MST) Cc: terry@lambert.org, hackers@freebsd.org In-Reply-To: from "Marc G. Fournier" at Dec 16, 96 09:38:34 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-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > size = mmap( 0, sizeof(int) * FRAMES, PROT_READ|PROT_WRITE, MAP_SHARED, fd, 0)); > for(i = 0; i < FRAMES; i++) > framesize[i] = start + i * sizeof(int); > > ? or: start = mmap( 0, (sizeof(int)+FRAMESIZE)*FRAMES, PROT_READ|PROT_WRITE,... for(i = 0; i < FRAMES; i++) { framesize[i] = start; start += sizeof(int); } for(i = 0; i < FRAMES; i++) { frame[i] = start; start += FRAMESIZE; } ...and again, use only one mapping. > > Also: Are you mapping in both the client and the server? Or just > > the server? > > Not quite sure what you mean here...client has: [ ... ] OK, you are mapping in both. I don't know if you are allowed to have PROT_READ|PROT_WRITE in one and only PROT_READ in the other; John Dyson would be the guy to ask... > I'm using "Advanced Programming in the Unix Environment" by > Stevens as my new "bible", and it states that "MAP_SHARED or MAP_PRIVATE > must be specified"...unfortunately, his only "example" happens to have > two different files MMAP'd, and then he's doing an memcpy() between > them :( Is the above incorrect? The Stevens book is the bible... but that example you might want to consider most relevent is in the cp code in /src/bin/cp/utils.c. John: there is still "#ifdef VM_AND_BUFFER_CACHE_SYNCHRONIZED" in that code... is that right now? > Binary data, so this may be correct, since the "data" that I'm > getting on the opposite end is exactly the same as the data on the server > end... Hey, if it's working, don't fix it. Also: look in the -current list archive for the mmap() functionality testing code that was posted a while back... 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-hackers Tue Dec 17 10:31:52 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id KAA10976 for hackers-outgoing; Tue, 17 Dec 1996 10:31:52 -0800 (PST) Received: from bacall.lodgenet.com (bacall.lodgenet.com [205.138.147.242]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id KAA10967 for ; Tue, 17 Dec 1996 10:31:48 -0800 (PST) Received: (from mail@localhost) by bacall.lodgenet.com (8.6.12/8.6.12) id MAA18710; Tue, 17 Dec 1996 12:30:47 -0600 Received: from garbo.lodgenet.com(204.124.123.250) by bacall via smap (V1.3) id sma018705; Tue Dec 17 12:30:38 1996 Received: from jake.lodgenet.com (jake.lodgenet.com [10.0.11.30]) by garbo.lodgenet.com (8.6.12/8.6.9) with ESMTP id MAA09327; Tue, 17 Dec 1996 12:31:00 -0600 Received: from jake.lodgenet.com (localhost [127.0.0.1]) by jake.lodgenet.com (8.8.3/8.6.12) with ESMTP id MAA17829; Tue, 17 Dec 1996 12:31:34 -0600 (CST) Message-Id: <199612171831.MAA17829@jake.lodgenet.com> X-Mailer: exmh version 1.6.9 8/22/96 To: "Jin Guojun[ITG]" cc: erich@lodgenet.com, hackers@freebsd.org Subject: Re: Q for loadable network driver In-reply-to: Your message of "Mon, 16 Dec 1996 13:19:33 PST." <199612162119.NAA29129@george.lbl.gov> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 17 Dec 1996 12:31:32 -0600 From: "Eric L. Hernes" Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk "Jin Guojun[ITG]" writes: >Another question is that is necessary to link the newly loaded driver to >the kernel control block -- >----------------------------------------------------------------- >Without an interface to get the PCI control block address -- &pcicb -- it is >hardly to link the new information into the kernel PCI chain. >Also, is the segment above (pci/pci.c line 704 - 819) necessary for loading >a loadable device driver? > I'm kind of going out on a limb here, having never done a pci device (yet) but... It looks like you want to use (amongst others) the kernel support functions pci_conf_read() and pci_conf_write(), which take pci tags. You'll need to use pcibus->pb_tags(bus, device, func) to get a tag. You might be able to get bus and device by looking at the /dev/pci entry points. I *think* the pci subsystem will report your device exists but `no driver assigned'. pciconf should report something like: (ttyp1@jake)$ pciconf -l pci0:0:0: class=0x060000 card=0x00000000 chip=0x04a38086 rev=0x11 hdr=0xff pci0:2:0: class=0x000000 card=0x00000000 chip=0x04828086 rev=0x04 hdr=0xff pci0:3:0: class=0x01010a card=0x00000000 chip=0x06401095 rev=0x02 hdr=0xff pci0:6:0: class=0x010000 card=0x00000000 chip=0x1040104b rev=0x00 hdr=0xff pci0:7:0: class=0x030000 card=0x00000000 chip=0x88f05333 rev=0x00 hdr=0xff (ttyp1@jake)$ One of those devices should be yours. It may be clumsy/awkward to get this information at first, but you should be able to use hardcoded numbers from the pciconf output as a `proof of concept' before you get too far. It's probably time to get one of the PCI wizards in here... >Thanks for any information, > >-Jin eric. -- erich@lodgenet.com http://rrnet.com/~erich erich@rrnet.com From owner-freebsd-hackers Tue Dec 17 10:41:51 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id KAA11379 for hackers-outgoing; Tue, 17 Dec 1996 10:41:51 -0800 (PST) Received: from iafnl.es.iaf.nl (uucp@iafnl.es.iaf.nl [195.108.17.20]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id KAA11373 for ; Tue, 17 Dec 1996 10:41:48 -0800 (PST) Received: by iafnl.es.iaf.nl with UUCP id AA12727 (5.67b/IDA-1.5 for freebsd-hackers@freebsd.org); Tue, 17 Dec 1996 19:41:18 +0100 Received: (from wilko@localhost) by yedi.iaf.nl (8.7.5/8.6.12) id TAA00594; Tue, 17 Dec 1996 19:01:17 +0100 (MET) From: Wilko Bulte Message-Id: <199612171801.TAA00594@yedi.iaf.nl> Subject: Re: Running Linux' Acrobat reader under 215R? To: hans@brandinnovators.com (Hans Zuidam) Date: Tue, 17 Dec 1996 19:01:17 +0100 (MET) Cc: freebsd-hackers@freebsd.org In-Reply-To: <199612171137.LAA00895@truk.brandinnovators.com> from "Hans Zuidam" at Dec 17, 96 11:37:45 am X-Mailer: ELM [version 2.4 PL24 ME8a] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk As Hans Zuidam wrote... > > Thomas Gellekum wrote: > > Michael Smith wrote: > > > Christoph Kukulies stands accused of saying: > > > > > If you just want to read .pdf-files, you could use xpdf. > > > > > > > > xpdf is known to be inadequate or insufficient in some respects. Like producing anything printable (preferably postscript). That was my reason for looking into Adobe's Linux version. Ah well, I'll wait for 2.2*R for this to get working. > > > This is mostly in connection with "encrypted" PDF files, and is due > > > to the usual anal export restrictions. I don't know what Adobe do with > > > Acrobat; I read PDF files with gv and ghostscript and the RC4 patch. > > > > Well, last week I came across a damaged PDF file, which acrobat could > > fix. gs just barfed on it. > Hmmm... I've got some pdf files that make acrobat (v2 and v3!) barf > while xpdf simply spits out warnings and continues with the next page... PDF is becoming an 'interesting standard' these days. Wilko _ ____________________________________________________________________ | / o / / _ Bulte email: wilko@yedi.iaf.nl - Arnhem, The Netherlands |/|/ / / /( (_) Do, or do not. There is no 'try' - Yoda -------------------------------------------------------------------------- From owner-freebsd-hackers Tue Dec 17 10:50:18 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id KAA11687 for hackers-outgoing; Tue, 17 Dec 1996 10:50:18 -0800 (PST) Received: from labinfo.iet.unipi.it (labinfo.iet.unipi.it [131.114.9.5]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id KAA11655 for ; Tue, 17 Dec 1996 10:49:51 -0800 (PST) Received: from localhost (luigi@localhost) by labinfo.iet.unipi.it (8.6.5/8.6.5) id TAA05125 for hackers@freebsd.org; Tue, 17 Dec 1996 19:07:57 +0100 From: Luigi Rizzo Message-Id: <199612171807.TAA05125@labinfo.iet.unipi.it> Subject: NFS traffic... To: hackers@freebsd.org Date: Tue, 17 Dec 1996 19:07:56 +0100 (MET) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Just a curiosity. I just ran mkisofs on a partition mounted over NFS using TCP. Since my kernel logs dup traffic per connection, on the server I noticed this: == dup:rx 136:47615878 dup:tx 37052:615632570 == 131.114.9.236:2049 131.114.83.21:1025 i.e. 587MB out, 45MB in (this is TCP payload, excluding headers). Kind of surprising that 8% of input data, considering that the partition is readonly! There seems to be an explaination -- many files in that partition were small ones. Luigi -----------------------------+-------------------------------------- Luigi Rizzo | Dip. di Ingegneria dell'Informazione email: luigi@iet.unipi.it | Universita' di Pisa tel: +39-50-568533 | via Diotisalvi 2, 56126 PISA (Italy) fax: +39-50-568522 | http://www.iet.unipi.it/~luigi/ _____________________________|______________________________________ From owner-freebsd-hackers Tue Dec 17 11:30:20 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id LAA13228 for hackers-outgoing; Tue, 17 Dec 1996 11:30:20 -0800 (PST) Received: from labinfo.iet.unipi.it (labinfo.iet.unipi.it [131.114.9.5]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id LAA13164 for ; Tue, 17 Dec 1996 11:29:45 -0800 (PST) Received: from localhost (luigi@localhost) by labinfo.iet.unipi.it (8.6.5/8.6.5) id TAA05241; Tue, 17 Dec 1996 19:47:51 +0100 From: Luigi Rizzo Message-Id: <199612171847.TAA05241@labinfo.iet.unipi.it> Subject: Re: A question on diskless boot To: phk@critter.tfs.com (Poul-Henning Kamp) Date: Tue, 17 Dec 1996 19:47:51 +0100 (MET) Cc: hackers@freebsd.org In-Reply-To: <9207.850642949@critter.tfs.com> from "Poul-Henning Kamp" at Dec 15, 96 10:42:10 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > >One of our labs has a number of machines with a network card (21140 > >based, if_de driver) which is unsupported by netboot. I am looking for > >some alternative ways to setup these machines as diskless, i.e mounting > >root at the very least from a remote server. ... > >I am willing to work on it, and would just like a bit of advice. > > Let me tell you what I would do: > > Make a kernel with a builtin MFS filesystem, just like > the one on boot.flp. Boot this kernel from wherever you > want (floppy ?) Honestly I don't like much this solution. One of the nice thing in the move from 1.1 to 2.1 in the diskless code is that you could use the same exact kernel for ordinary and diskless systems. I'd like to preserve this feature as much as possible. > Add generic code to the ethernet support in the kernel > so that one can say > ifconfig -bootp de0 > /etc/bootp.reply In any case this (or the kernel equivalent) requires the bootp request be sent before having an address. Now, is it reasonable to use 255.255.255.255 as the IP address until the reply has come ? I have tried ifconfig ed0 255.255.255.255 alias and it does not seem to complain. Haven't tried to use it to communicate though... if this works, then it seems relatively trivial (not asking for someone to do, just need a bit of advice!) to add the following code in nfs/nfs_vfsops.c near the beginning of nfs_mountroot(): - add a call to ifioctl(so, SIOCAIFADDR, ...) to assign an IP of 255.255.255.255 - collect an IP address using bootp - delete the 255.255.255.255 address - call ifioctl(so, SIOCAIFADDR, ...) with the right IP - merge in the netboot code to get the relevant info on the server and then continue with the current code. This shouldn't cause a large bloat in the kernel, since the whole netboot stuff is 8-10KB including the driver for the card, printf and many other things. Luigi -----------------------------+-------------------------------------- Luigi Rizzo | Dip. di Ingegneria dell'Informazione email: luigi@iet.unipi.it | Universita' di Pisa tel: +39-50-568533 | via Diotisalvi 2, 56126 PISA (Italy) fax: +39-50-568522 | http://www.iet.unipi.it/~luigi/ _____________________________|______________________________________ From owner-freebsd-hackers Tue Dec 17 11:49:12 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id LAA14428 for hackers-outgoing; Tue, 17 Dec 1996 11:49:12 -0800 (PST) Received: from tfs.com (tfs.com [140.145.250.1]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id LAA14410 for ; Tue, 17 Dec 1996 11:48:41 -0800 (PST) Received: from critter.tfs.com by tfs.com (smail3.1.28.1) with SMTP id m0va5Uh-0003w3C; Tue, 17 Dec 96 11:48 PST Received: from critter.tfs.com (localhost.phk.dk [127.0.0.1]) by critter.tfs.com (8.8.2/8.8.2) with ESMTP id UAA16294; Tue, 17 Dec 1996 20:51:45 +0100 (MET) To: Luigi Rizzo cc: hackers@freebsd.org Subject: Re: A question on diskless boot In-reply-to: Your message of "Tue, 17 Dec 1996 19:47:51 +0100." <199612171847.TAA05241@labinfo.iet.unipi.it> Date: Tue, 17 Dec 1996 20:51:45 +0100 Message-ID: <16292.850852305@critter.tfs.com> From: Poul-Henning Kamp Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In message <199612171847.TAA05241@labinfo.iet.unipi.it>, Luigi Rizzo writes: >> Add generic code to the ethernet support in the kernel >> so that one can say >> ifconfig -bootp de0 > /etc/bootp.reply > >In any case this (or the kernel equivalent) requires the bootp request >be sent before having an address. Now, is it reasonable to use >255.255.255.255 as the IP address until the reply has come ? I have >tried > > ifconfig ed0 255.255.255.255 alias > >and it does not seem to complain. Haven't tried to use it to >communicate though... if this works, then it seems relatively >trivial (not asking for someone to do, just need a bit of advice!) >to add the following code in nfs/nfs_vfsops.c near the beginning >of nfs_mountroot(): > >- add a call to ifioctl(so, SIOCAIFADDR, ...) to assign an IP > of 255.255.255.255 >- collect an IP address using bootp >- delete the 255.255.255.255 address >- call ifioctl(so, SIOCAIFADDR, ...) with the right IP >- merge in the netboot code to get the relevant info on the > server > >and then continue with the current code. This shouldn't cause a large >bloat in the kernel, since the whole netboot stuff is 8-10KB including >the driver for the card, printf and many other things. I belive that you actually use IP# 0.0.0.0 as dest IP with bootp, but the RFC will tell I'm sure. You may have to add special-case code somewhere deep in the ip stuff, but try it out and see what happens. I would prefer if the same code could be made to work with ifconfig for the non-diskless case as well. -- 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-hackers Tue Dec 17 11:58:55 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id LAA14975 for hackers-outgoing; Tue, 17 Dec 1996 11:58:55 -0800 (PST) Received: from labinfo.iet.unipi.it (labinfo.iet.unipi.it [131.114.9.5]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id LAA14950 for ; Tue, 17 Dec 1996 11:58:19 -0800 (PST) Received: from localhost (luigi@localhost) by labinfo.iet.unipi.it (8.6.5/8.6.5) id UAA05377; Tue, 17 Dec 1996 20:16:01 +0100 From: Luigi Rizzo Message-Id: <199612171916.UAA05377@labinfo.iet.unipi.it> Subject: Re: A question on diskless boot To: phk@critter.tfs.com (Poul-Henning Kamp) Date: Tue, 17 Dec 1996 20:16:00 +0100 (MET) Cc: hackers@freebsd.org In-Reply-To: <16292.850852305@critter.tfs.com> from "Poul-Henning Kamp" at Dec 17, 96 08:51:26 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > >- delete the 255.255.255.255 address > >- call ifioctl(so, SIOCAIFADDR, ...) with the right IP > >- merge in the netboot code to get the relevant info on the > > server > > > >and then continue with the current code. This shouldn't cause a large > >bloat in the kernel, since the whole netboot stuff is 8-10KB including > >the driver for the card, printf and many other things. > > I belive that you actually use IP# 0.0.0.0 as dest IP with bootp, > but the RFC will tell I'm sure. You may have to add special-case I was talking about the source IP. But yes, the RFC (or netboot code) can tell this, I was only worried about something in the ip stuff which might prevent these addresses to get assigned to the interface. > I would prefer if the same code could be made to work with ifconfig > for the non-diskless case as well. If i get it right you want a new flag "ifconfig -bootp", it's a different thing but _extremely_ useful when you have a lab of machines. Luigi -----------------------------+-------------------------------------- Luigi Rizzo | Dip. di Ingegneria dell'Informazione email: luigi@iet.unipi.it | Universita' di Pisa tel: +39-50-568533 | via Diotisalvi 2, 56126 PISA (Italy) fax: +39-50-568522 | http://www.iet.unipi.it/~luigi/ _____________________________|______________________________________ From owner-freebsd-hackers Tue Dec 17 12:22:06 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id MAA16338 for hackers-outgoing; Tue, 17 Dec 1996 12:22:06 -0800 (PST) Received: from tdc.on.ca (tdc.on.ca [204.92.242.39]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id MAA16314 for ; Tue, 17 Dec 1996 12:21:23 -0800 (PST) Received: (from martin@localhost) by tdc.on.ca (8.7.5/8.6.6) id PAA16649; Tue, 17 Dec 1996 15:20:40 -0500 (EST) From: Martin Renters Message-Id: <199612172020.PAA16649@tdc.on.ca> Subject: Re: A question on diskless boot To: luigi@labinfo.iet.unipi.it (Luigi Rizzo) Date: Tue, 17 Dec 1996 15:20:40 -0500 (EST) Cc: phk@critter.tfs.com, hackers@freebsd.org In-Reply-To: <199612171916.UAA05377@labinfo.iet.unipi.it> from "Luigi Rizzo" at Dec 17, 96 08:16:00 pm X-Mailer: ELM [version 2.4 PL24 ME8a] Content-Type: text Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > I would prefer if the same code could be made to work with ifconfig > > for the non-diskless case as well. > > If i get it right you want a new flag "ifconfig -bootp", it's a > different thing but _extremely_ useful when you have a lab of > machines. The PCCARD stuff already seems to have the ability to do this via DHCP. Look in /etc/pccard_ether from the PAO distribution. As for adding DEC chipset support to netboot, I don't think it would be impossible, I just don't have such a card at the moment, but I will look into borrowing one. I already have the programming docs (at least for the older chips). I suppose if you don't have a socket for a bootrom, you're still out of luck though. Martin From owner-freebsd-hackers Tue Dec 17 13:21:31 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id NAA19963 for hackers-outgoing; Tue, 17 Dec 1996 13:21:31 -0800 (PST) Received: from dyson.iquest.net (dyson.iquest.net [198.70.144.127]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id NAA19949 for ; Tue, 17 Dec 1996 13:20:53 -0800 (PST) Received: (from root@localhost) by dyson.iquest.net (8.8.2/8.6.9) id QAA05589; Tue, 17 Dec 1996 16:19:17 -0500 (EST) From: John Dyson Message-Id: <199612172119.QAA05589@dyson.iquest.net> Subject: Re: Almost have mmap() figured, I think... To: terry@lambert.org (Terry Lambert) Date: Tue, 17 Dec 1996 16:19:17 -0500 (EST) Cc: scrappy@hub.org, terry@lambert.org, hackers@freebsd.org In-Reply-To: <199612171701.KAA08511@phaeton.artisoft.com> from "Terry Lambert" at Dec 17, 96 10:01:37 am Reply-To: dyson@freebsd.org X-Mailer: ELM [version 2.4 PL24 ME8] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > The Stevens book is the bible... but that example you might want to > consider most relevent is in the cp code in /src/bin/cp/utils.c. > > John: there is still "#ifdef VM_AND_BUFFER_CACHE_SYNCHRONIZED" in that > code... is that right now? > The ifdef can go away now -- no problem. The problem is a performance issue where copying a large file will cause lots of memory usage... The buffer cache is better tuned for file I/O. John From owner-freebsd-hackers Tue Dec 17 13:31:56 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id NAA20549 for hackers-outgoing; Tue, 17 Dec 1996 13:31:56 -0800 (PST) Received: from agora.rdrop.com (root@agora.rdrop.com [199.2.210.241]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id NAA20452; Tue, 17 Dec 1996 13:30:23 -0800 (PST) Received: from austin.polstra.com by agora.rdrop.com with smtp (Smail3.1.29.1 #17) id m0va75T-0008tyC; Tue, 17 Dec 96 13:30 PST Received: (from jdp@localhost) by austin.polstra.com (8.8.3/8.8.3) id NAA19462; Tue, 17 Dec 1996 13:26:17 -0800 (PST) To: freebsd-hackers@freebsd.org Path: not-for-mail From: jdp@polstra.com (John Polstra) Newsgroups: polstra.freebsd.hackers Subject: Correction: src-release and src-tools will REMAIN Date: 17 Dec 1996 13:26:16 -0800 Organization: Polstra & Co., Seattle, WA Lines: 49 Distribution: local Message-ID: <59735o$j03@austin.polstra.com> References: <199612160453.UAA01018@austin.polstra.com> In-reply-to: <199612160453.UAA01018@austin.polstra.com> Fcc: outbox Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In article <199612160453.UAA01018@austin.polstra.com>, John Polstra , to his regret, wrote: > If you have been CVSup/supping "src-release" or "src-tools", please > change your supfile and get "src-etc" instead. I am going to delete the > two obsolete collections within a few days. False alarm -- this is not happening after all. I had asked about it on core a few days before, but I guess I didn't wait long enough for somebody to object. The "src-release" and "src-tools" collections are going to remain distinct from "src-etc". I am going to eliminate the overlap that currently exists between src-etc and the other two, by modifying what is included in src-etc. That is going to happen on freefall this coming Saturday, December 21. There is going to be a hiccup when this happens. When sup and CVSup notice the change to src-etc, they will proceed to delete the affected files on the client machines. Most people won't care about that. Neither src-release nor src-tools is really a part of the system. If you want to continue to get them anyway, you'll have to add those collections to your supfile. Here's the nasty part: If you have src-etc AND the other two in your supfile, the files are going to be deleted (in connection with src-etc) and then sent to you again (as part of src-release and src-tools). Sorry, that's just the way things work under the sup model. It doesn't recognize relationships between files in different collections. With CVSup at least (and I think with sup too), you can avoid having the files retransmitted to you as follows: 1. Before Saturday: Copy the "src/release" and "src/tools" trees to a backup area. 2. After Saturday: Do a CVSup run of only the src-etc collection. It will delete the files in src/release and src/tools. 3. Copy the files back into place from the backup area. 4. Get on with your life. Thanks for your patience. -- John Polstra jdp@polstra.com John D. Polstra & Co., Inc. Seattle, Washington USA "Self-knowledge is always bad news." -- John Barth From owner-freebsd-hackers Tue Dec 17 13:51:20 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id NAA21747 for hackers-outgoing; Tue, 17 Dec 1996 13:51:20 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id NAA21707; Tue, 17 Dec 1996 13:50:29 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id OAA08978; Tue, 17 Dec 1996 14:48:58 -0700 From: Terry Lambert Message-Id: <199612172148.OAA08978@phaeton.artisoft.com> Subject: Re: Almost have mmap() figured, I think... To: dyson@freebsd.org Date: Tue, 17 Dec 1996 14:48:58 -0700 (MST) Cc: terry@lambert.org, scrappy@hub.org, hackers@freebsd.org In-Reply-To: <199612172119.QAA05589@dyson.iquest.net> from "John Dyson" at Dec 17, 96 04:19:17 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-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > The Stevens book is the bible... but that example you might want to > > consider most relevent is in the cp code in /src/bin/cp/utils.c. > > > > John: there is still "#ifdef VM_AND_BUFFER_CACHE_SYNCHRONIZED" in that > > code... is that right now? > > The ifdef can go away now -- no problem. The problem is a performance > issue where copying a large file will cause lots of memory usage... The > buffer cache is better tuned for file I/O. Any chance of per vnode working set restrictions? They would be easy to implement by keeping a page count and changing lru insertion order over the count, it seems to me. The SVR4 ld thrashed the cache by mmap'ing a bunch of files; the UnixWare folks seems to head off into the weeds at that point, including coming up with an entirely new scheduling class for their X server to fix the "move mouse, wiggle cursor" problem cause by it swapping the whole X server out while servicing the ld. A trivial working set restriction (no LRU on a per vnode basis) cleaned it right up without needing new scheduling classes and all that crap that they had added. 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-hackers Tue Dec 17 14:21:14 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id OAA23338 for hackers-outgoing; Tue, 17 Dec 1996 14:21:14 -0800 (PST) Received: from isbalham.ist.co.uk (isbalham.ist.co.uk [192.31.26.1]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id OAA23196; Tue, 17 Dec 1996 14:19:18 -0800 (PST) Received: from gid.co.uk (uucp@localhost) by isbalham.ist.co.uk (8.8.4/8.8.4) with UUCP id WAA12852; Tue, 17 Dec 1996 22:03:44 GMT Date: Tue, 17 Dec 1996 22:05:13 GMT Received: from [194.32.164.2] by seagoon.gid.co.uk; Tue, 17 Dec 1996 22:05:13 GMT X-Sender: rb@194.32.164.1 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: Terry Lambert From: rb@gid.co.uk (Bob Bishop) Subject: Re: vulnerability in new pw suite Cc: proff@iq.org, security@freebsd.org, hackers@freebsd.org Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >Five gets you ten that he'll just use rlogin instead, and go for root >on the new system from the user account, never knowing the user's >password (or caring). Well OK, but that just sounds to me like a(nother) good reason to eschew rlogin and co. -- 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-hackers Tue Dec 17 15:17:44 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id PAA27111 for hackers-outgoing; Tue, 17 Dec 1996 15:17:44 -0800 (PST) Received: from trinity.radio-do.de (fn@trinity.Radio-do.de [193.101.164.3]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id PAA26730 for ; Tue, 17 Dec 1996 15:12:56 -0800 (PST) Received: by trinity.radio-do.de (8.7.6/CLIENT-1.2.7-h) via EUnet id AAA01499; Wed, 18 Dec 1996 00:11:58 +0100 (MET) To: hackers@freebsd.org Subject: Weired c++ behaviour regarding iostreams From: Frank Nobis Date: 18 Dec 1996 00:11:58 +0100 Message-ID: Lines: 61 X-Mailer: Red Gnus v0.74/XEmacs 19.14 Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi there, I have a weired problem using the iostream lib. I have a small program wich opens a file and print out the context. On my 2.2-961014-SNAP with g++ 2.7.2.1 and on a Sun runnning Solaris 5.5 same gcc version, EOF is not recognized and the program hangs until ^C is pressed. I have checked against a fresh installed 2.1.5-RELEASE with gcc version 2.6.3. Everything is running as expected. Here is my small test program. ------------------------------------------------------------------------------ // stream1.cc #include #include #include #include int main(int argc, char **argv) { char c; int fd; ifstream file; // fd = open("/etc/motd", 0444, O_RDONLY); // cout << "File descriptor is: " << fd << "\n"; file.ifstream("stream1.cc"); // file.sync_with_stdio(); while (file.get(c)) { if (file.eof()) break; // cout.put(c); cout << c; } exit (0); } ------------------------------------------------------------------------------ Has someone an idea what is going wrong? Regards Frank -- Frank Nobis Email: fn@Radio-do.de PGP AVAILABLE Landgrafenstr. 130 dg3dcn http://www.radio-do.de/~fn/ 44139 Dortmund Powered by FreeBSD Fax: +49 231 7213816 From owner-freebsd-hackers Tue Dec 17 16:09:32 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id QAA02498 for hackers-outgoing; Tue, 17 Dec 1996 16:09:32 -0800 (PST) Received: from who.cdrom.com (who.cdrom.com [204.216.27.3]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id QAA02488 for ; Tue, 17 Dec 1996 16:09:29 -0800 (PST) Received: from kctgw.kagoshima-ct.ac.jp (kctgw.kagoshima-ct.ac.jp [202.17.208.1]) by who.cdrom.com (8.7.5/8.6.11) with ESMTP id QAA28774 for ; Tue, 17 Dec 1996 16:09:21 -0800 (PST) Received: from kctmgw.kagoshima-ct.ac.jp (kctm [202.17.208.2]) by kctgw.kagoshima-ct.ac.jp (8.8.4/8.8.4) with SMTP id JAA00608 for ; Wed, 18 Dec 1996 09:08:07 +0900 (JST) Received: by kctmgw.kagoshima-ct.ac.jp (4.2/SMI-4.0) id AA22680; Wed, 18 Dec 96 09:03:03 JST Date: Wed, 18 Dec 96 09:03:03 JST From: yuda@kagoshima-ct.ac.jp (Toshiyuki Yuda) Message-Id: <9612180003.AA22680@kctmgw.kagoshima-ct.ac.jp> To: hackers@FreeBSD.org Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk Hello, My name is Toshiyuki Yuda who depends on Kagoshima National College of Thchnology. I have any questions. I want to ride BSD/386 on PC-9801NS/T. Please tell me possible or impossible. Sincerely, Kagoshima National College of Thchnology Depatment of Electrical Engineering Research Associate Toshiyuki Yuda(yuda@kagoshima-ct.ac.jp) From owner-freebsd-hackers Tue Dec 17 16:12:31 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id QAA02940 for hackers-outgoing; Tue, 17 Dec 1996 16:12:31 -0800 (PST) Received: from hub.org (root@hub.org [207.107.138.200]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id QAA02935 for ; Tue, 17 Dec 1996 16:12:27 -0800 (PST) Received: from localhost (scrappy@localhost) by hub.org (8.8.2/8.7.5) with SMTP id TAA11784 for ; Tue, 17 Dec 1996 19:12:26 -0500 (EST) Date: Tue, 17 Dec 1996 19:12:25 -0500 (EST) From: "Marc G. Fournier" Reply-To: "Marc G. Fournier" To: hackers@freebsd.org Subject: Thanks to all (re: MMAP) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi... Thanks to everyone for the invaluable help with getting this mmap() stuff understood... The most recent problem that I was seeing was *purely* a coding error, and nothing more :( Everything else works like a charm :) Terry...thanks for the pointers about how to reduce the number of maps required...will implement that final one, of merging sizeof(int) + FRAMESIZE, tonight... But, have one question concerning that first. When I do the socket and want to send the size across the socket, I use: write(sockfd, (char *)&datasize, sizeof(datasize)); How would I do similar with the mmap()'d region? What I'm doing right now is, other then inefficient: for (;;) { for(ii = 0; ii < FRAMES; ii++) { readn(sockfd, (char *)&datasize, sizeof(datasize)); if (datasize == 0) break; sprintf(vsize + (ii * sizeof(int)), "%d", datasize); readn(sockfd, video + (ii * FRAMESIZE), datasize); } } Is this as correct as any other way? I know it works, but if I merge the two into one mmap'd region, I would think I'd be looking at something like: for (;;) { for(ii = 0; ii < FRAMES; ii++) { readn(sockfd, (char *)&datasize, sizeof(datasize)); if (datasize == 0) break; sprintf(vsize + (ii * (sizeof(int) + FRAMESIZE)), "%d", datasize); readn(sockfd, video + (ii * (sizeof(int) + FRAMESIZE)) + sizeof(int), datasize); } } But I would have thought that there was a better method of doing the sprintf() above? Somehow, it *feels* wrong... Marc G. Fournier scrappy@hub.org Systems Administrator @ hub.org scrappy@freebsd.org From owner-freebsd-hackers Tue Dec 17 16:57:36 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id QAA05173 for hackers-outgoing; Tue, 17 Dec 1996 16:57:36 -0800 (PST) Received: from narcissus.ml.org (brosenga.st.pitzer.edu [134.173.120.201]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id QAA05168 for ; Tue, 17 Dec 1996 16:57:30 -0800 (PST) Received: (from ben@localhost) by narcissus.ml.org (8.7.5/8.7.3) id QAA04081; Tue, 17 Dec 1996 16:56:23 -0800 (PST) Date: Tue, 17 Dec 1996 16:56:23 -0800 (PST) From: Snob Art Genre To: Toshiyuki Yuda cc: hackers@FreeBSD.org Subject: Re: your mail In-Reply-To: <9612180003.AA22680@kctmgw.kagoshima-ct.ac.jp> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk On Wed, 18 Dec 1996, Toshiyuki Yuda wrote: > Hello, My name is Toshiyuki Yuda who depends on Kagoshima National College of Thchnology. > I have any questions. > I want to ride BSD/386 on PC-9801NS/T. What is a PC-9801NS/T? Unless it uses Micro Channel Architecture you're probably fine. > Please tell me possible or impossible. > > Sincerely, > Kagoshima National College of Thchnology > Depatment of Electrical Engineering > Research Associate > Toshiyuki Yuda(yuda@kagoshima-ct.ac.jp) > > Ben The views expressed above are not those of the Worker's Compensation Board of Queensland, Australia. From owner-freebsd-hackers Tue Dec 17 17:36:12 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id RAA07126 for hackers-outgoing; Tue, 17 Dec 1996 17:36:12 -0800 (PST) Received: from fallout.campusview.indiana.edu (fallout.campusview.indiana.edu [149.159.1.1]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id RAA07113 for ; Tue, 17 Dec 1996 17:36:08 -0800 (PST) Received: from localhost (jfieber@localhost) by fallout.campusview.indiana.edu (8.8.4/8.8.4) with SMTP id UAA04627; Tue, 17 Dec 1996 20:36:01 -0500 (EST) Date: Tue, 17 Dec 1996 20:36:01 -0500 (EST) From: John Fieber To: Frank Nobis cc: hackers@freebsd.org Subject: Re: Weired c++ behaviour regarding iostreams In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On 18 Dec 1996, Frank Nobis wrote: > ifstream file; ... > file.ifstream("stream1.cc"); It works if you combine these to: ifstream file("stream1.cc"); Off the top of my head, the original looks a bit suspicious, calling a constructor after the object is already constructed, but I'm a C++ novice... The original bit of code wouldn't even compile on SunPRO CC: "stream1.cc", line 19: Error: ifstream is not a member of ifstream. -john From owner-freebsd-hackers Tue Dec 17 19:08:51 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id TAA12291 for hackers-outgoing; Tue, 17 Dec 1996 19:08:51 -0800 (PST) Received: from po1.glue.umd.edu (root@po1.glue.umd.edu [129.2.128.44]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id TAA12277 for ; Tue, 17 Dec 1996 19:08:45 -0800 (PST) Received: from thurston.eng.umd.edu (thurston.eng.umd.edu [129.2.103.25]) by po1.glue.umd.edu (8.8.3/8.7.3) with ESMTP id WAA23465; Tue, 17 Dec 1996 22:08:37 -0500 (EST) Received: from localhost (chuckr@localhost) by thurston.eng.umd.edu (8.8.3/8.7.3) with SMTP id WAA21017; Tue, 17 Dec 1996 22:08:36 -0500 (EST) X-Authentication-Warning: thurston.eng.umd.edu: chuckr owned process doing -bs Date: Tue, 17 Dec 1996 22:08:36 -0500 (EST) From: Chuck Robey X-Sender: chuckr@thurston.eng.umd.edu To: Frank Nobis cc: hackers@freebsd.org Subject: Re: Weired c++ behaviour regarding iostreams In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On 18 Dec 1996, Frank Nobis wrote: > > Hi there, > > I have a weired problem using the iostream lib. > > I have a small program wich opens a file and print out the context. > > On my 2.2-961014-SNAP with g++ 2.7.2.1 and on a Sun runnning Solaris > 5.5 same gcc version, EOF is not recognized and the program hangs > until ^C is pressed. > > I have checked against a fresh installed 2.1.5-RELEASE with gcc > version 2.6.3. Everything is running as expected. > > Here is my small test program. Trouble is, you try to use both stdio.h (which is C's i/o functions) and iostream.h (which is C++'s i/o functions). Since they both try to do buffering of their own, outside of the operating system buffering, this is a big no-no. Choose your poison, either stdio.h (which works fine with C++) or iostreams, but not both. I like stdio.h myself, because I think it's better documented, but I think most C++ coders like iostreams. When I see man pages on the C++ iostreams functions appear, I'll probably consider going over, but not until then. ----------------------------+----------------------------------------------- Chuck Robey | Interests include any kind of voice or data chuckr@eng.umd.edu | communications topic, C programming, and Unix. 9120 Edmonston Ct #302 | Greenbelt, MD 20770 | I run Journey2 and picnic, both FreeBSD (301) 220-2114 | version 3.0 current -- and great FUN! ----------------------------+----------------------------------------------- From owner-freebsd-hackers Tue Dec 17 22:30:32 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id WAA19685 for hackers-outgoing; Tue, 17 Dec 1996 22:30:32 -0800 (PST) Received: from labinfo.iet.unipi.it (labinfo.iet.unipi.it [131.114.9.5]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id WAA19680 for ; Tue, 17 Dec 1996 22:30:28 -0800 (PST) Received: from localhost (luigi@localhost) by labinfo.iet.unipi.it (8.6.5/8.6.5) id GAA06355; Wed, 18 Dec 1996 06:48:16 +0100 From: Luigi Rizzo Message-Id: <199612180548.GAA06355@labinfo.iet.unipi.it> Subject: Re: A question on diskless boot To: martin@tdc.on.ca (Martin Renters) Date: Wed, 18 Dec 1996 06:48:16 +0100 (MET) Cc: phk@critter.tfs.com, hackers@FreeBSD.org In-Reply-To: <199612172020.PAA16649@tdc.on.ca> from "Martin Renters" at Dec 17, 96 03:20:21 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > The PCCARD stuff already seems to have the ability to do this via DHCP. > Look in /etc/pccard_ether from the PAO distribution. thanks for the pointer. > As for adding DEC chipset support to netboot, I don't think it would > be impossible, I just don't have such a card at the moment, but I will > look into borrowing one. I already have the programming docs (at least that would be great, since then I could integrate the "driver" into my bridge code and have a cheap multiport 10-100Mbit switch! > for the older chips). I suppose if you don't have a socket for a bootrom, > you're still out of luck though. In this case I would use the .COM version, either from a floppy or from a HD. Besides, many motherboards now have a flash bios, I could always try to patch the netboot stuff into the bios (sw only) or, for those MB with a ROM, burn a new Eprom including the netboot. Luigi -----------------------------+-------------------------------------- Luigi Rizzo | Dip. di Ingegneria dell'Informazione email: luigi@iet.unipi.it | Universita' di Pisa tel: +39-50-568533 | via Diotisalvi 2, 56126 PISA (Italy) fax: +39-50-568522 | http://www.iet.unipi.it/~luigi/ _____________________________|______________________________________ From owner-freebsd-hackers Tue Dec 17 22:31:47 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id WAA19731 for hackers-outgoing; Tue, 17 Dec 1996 22:31:47 -0800 (PST) Received: from eve.speakeasy.org (cgray@eve.speakeasy.org [199.238.226.1]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id WAA19726 for ; Tue, 17 Dec 1996 22:31:44 -0800 (PST) Received: from localhost (cgray@localhost) by eve.speakeasy.org (8.8.4/8.7.3) with SMTP id WAA26915; Tue, 17 Dec 1996 22:30:54 -0800 (PST) Date: Tue, 17 Dec 1996 22:30:53 -0800 (PST) From: Cyrus Gray To: hackers@freebsd.org Subject: Network Cards Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Thanks for all of the help setting up my HD. Now my next (and hopefully last question) Does FreeBSD Support the Intel Pro/100 100 Mbs PCI Nic? Thank you Cyrus Gray From owner-freebsd-hackers Tue Dec 17 22:37:15 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id WAA19903 for hackers-outgoing; Tue, 17 Dec 1996 22:37:15 -0800 (PST) Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id WAA19898 for ; Tue, 17 Dec 1996 22:37:11 -0800 (PST) Received: (from msmith@localhost) by genesis.atrad.adelaide.edu.au (8.8.2/8.7.3) id RAA29514 for hackers@freebsd.org; Wed, 18 Dec 1996 17:07:06 +1030 (CST) From: Michael Smith Message-Id: <199612180637.RAA29514@genesis.atrad.adelaide.edu.au> Subject: Nasty gotcha with CVS/CVSup setup To: hackers@freebsd.org Date: Wed, 18 Dec 1996 17:07:04 +1030 (CST) 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-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In trying to keep the footprint of my CVS repository down to a reasonable level, I've listed Attic directories in my CVSup 'Refuse' files. But this comes back to bite me when I check out, say, RELENG_2_2, where files have been subsequently deleted. In the case of 2.2, it makes the world unbuildable. Grr. Not blaming anyone in particular, just being cross. -- ]] 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-hackers Tue Dec 17 23:28:37 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id XAA21670 for hackers-outgoing; Tue, 17 Dec 1996 23:28:37 -0800 (PST) Received: from scanner.worldgate.com (scanner.worldgate.com [198.161.84.3]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id XAA21665 for ; Tue, 17 Dec 1996 23:28:35 -0800 (PST) Received: from znep.com (uucp@localhost) by scanner.worldgate.com (8.7.5/8.7.3) with UUCP id AAA16365 for hackers@freebsd.org; Wed, 18 Dec 1996 00:28:28 -0700 (MST) Received: from localhost (marcs@localhost) by alive.ampr.ab.ca (8.7.5/8.7.3) with SMTP id AAA20619 for ; Wed, 18 Dec 1996 00:28:16 -0700 (MST) Date: Wed, 18 Dec 1996 00:28:16 -0700 (MST) From: Marc Slemko X-Sender: marcs@alive.ampr.ab.ca To: hackers@freebsd.org Subject: any race conditions in this code? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Off the top of my head: char *foo; foo = mktemp(strdup("/tmp/foo.XXXXXX")); if (mkdir(foo, DEFFILEMODE) != 0) { /* die a horrible death */ exit(1); } /* do something with the directory */ I don't see any race conditions in there that could cause a security problem; the mkdir could be made to fail, but then it simply exits. It isn't as if it were creating a file and writing to it. Anyone care to disagree? From owner-freebsd-hackers Tue Dec 17 23:42:09 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id XAA22093 for hackers-outgoing; Tue, 17 Dec 1996 23:42:09 -0800 (PST) Received: from trinity.radio-do.de (fn@trinity.Radio-do.de [193.101.164.3]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id XAA22085 for ; Tue, 17 Dec 1996 23:41:58 -0800 (PST) Received: by trinity.radio-do.de (8.7.6/CLIENT-1.2.7-h) via EUnet id IAA08972; Wed, 18 Dec 1996 08:41:39 +0100 (MET) To: John Fieber Cc: hackers@freebsd.org Subject: Re: Weired c++ behaviour regarding iostreams References: From: Frank Nobis Date: 18 Dec 1996 08:41:39 +0100 In-Reply-To: John Fieber's message of Tue, 17 Dec 1996 20:36:01 -0500 (EST) Message-ID: Lines: 37 X-Mailer: Red Gnus v0.74/XEmacs 19.14 Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >>>>> "John" == John Fieber writes: John> On 18 Dec 1996, Frank Nobis wrote: >> ifstream file; John> ... >> file.ifstream("stream1.cc"); John> It works if you combine these to: John> ifstream file("stream1.cc"); John> Off the top of my head, the original looks a bit suspicious, John> calling a constructor after the object is already John> constructed, but I'm a C++ novice... That is the point. One can't call an constructor twice. John> The original bit of code wouldn't even compile on SunPRO CC: John> "stream1.cc", line 19: Error: ifstream is not a member of John> ifstream. Looks like different implementation. Even compiling with -O -Wall gives no warning with gcc. John> -john Thanks for your help Regards Frank -- Frank Nobis Email: fn@Radio-do.de PGP AVAILABLE Landgrafenstr. 130 dg3dcn http://www.radio-do.de/~fn/ 44139 Dortmund Powered by FreeBSD Fax: +49 231 7213816 From owner-freebsd-hackers Wed Dec 18 00:57:21 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id AAA24623 for hackers-outgoing; Wed, 18 Dec 1996 00:57:21 -0800 (PST) Received: from ns.pa-consulting.com (ns.pa-consulting.com [193.118.224.1]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id AAA24618 for ; Wed, 18 Dec 1996 00:57:16 -0800 (PST) Received: from SMTPGATE.PA-CONSULTING.COM by ns.pa-consulting.com (8.6.4) id JAA04378; Wed, 18 Dec 1996 09:08:25 GMT Received: by SMTPGATE.PA-CONSULTING.COM with Microsoft Mail id <32B82315@SMTPGATE.PA-CONSULTING.COM>; Wed, 18 Dec 96 09:00:05 PST From: Duncan Barclay To: freebsd-hackers Subject: IDE CDROM on 2.1.5R Date: Wed, 18 Dec 96 08:53:00 PST Message-ID: <32B82315@SMTPGATE.PA-CONSULTING.COM> Encoding: 33 TEXT X-Mailer: Microsoft Mail V3.0 Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi Another snippet of trivia if anyone is interested. I have 2.1.5R and a Sony CDU-77 IDE CDROM drive which does sort of work and IDE disks (this is my home machine). I wanted to mount a CDROM but /etc/wekly had started up and was doing a mkwhatis. Doing the mount generated the usual /dev/wcd0c: device not configured. Usually a reboot clears this so I waited until the mkwhatis finished. Just before rebooting I tried remounting the CDROM and it worked! So I played with that for a while and then wanted to use another CDROM. The first time I tried the mount it failed as above, so I thought lets just do an ls and see what happens...it worked. I then tried to repeat this a sequence a few times and it seems to work reliably. ie. $ mount /cdrom /dev/wcd0c: device not configured $ ls / $ mount /cdrom $ ls /cdrom .... I know that 2.2 ATAPI support should fix all these but for those of us still on 2.1.5R then this may be useful. Duncan Barclay From owner-freebsd-hackers Wed Dec 18 01:11:31 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id BAA25091 for hackers-outgoing; Wed, 18 Dec 1996 01:11:31 -0800 (PST) Received: from haldjas.folklore.ee (Haldjas.folklore.ee [193.40.6.121]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id BAA25079 for ; Wed, 18 Dec 1996 01:11:25 -0800 (PST) Received: from localhost (narvi@localhost) by haldjas.folklore.ee (8.8.2/8.6.12) with SMTP id LAA15068; Wed, 18 Dec 1996 11:16:58 +0200 (EET) Date: Wed, 18 Dec 1996 11:16:58 +0200 (EET) From: Narvi To: Joao Carlos Mendes Luis cc: Jamie Bowden , imp@village.org, joerg_wunsch@uriah.heep.sax.de, freebsd-hackers@freebsd.org, mgessner@aristar.com Subject: Re: talk and talkd In-Reply-To: <199612170110.XAA02226@gaia.coppe.ufrj.br> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Mon, 16 Dec 1996, Joao Carlos Mendes Luis wrote: > #define quoting(Jamie Bowden) > // On Mon, 16 Dec 1996, Warner Losh wrote: > // > // > In message <199612161855.QAA26056@gaia.coppe.ufrj.br> Joao Carlos Mendes Luis writes: > // > : I'd like to use something text-oriented. The default inetd.conf mentions > // > : a /usr/old/talkd, but I could not find any reference about it. Does it > // > : really exists ? > // > // > even if you had old/talkd (which may be on one of the Lite CDs), it > // > wouldn't help you talk to suns. Unless your compiler pads things > // > exactly the same way as the sun compiler, it won't work :-(. > // > // Fortunately, most suns have standard ntalkd put on them by their admins. > // At least, all the ones I admin'd ended up with it on them. Most of the > // other sun admins I know did/do the same. > > Yup, but my problem is when my users want to talk with someone on a Sun > system which does not have such a good manager. :) Then you are fried. Unless you can make ytalk work. > > Since we can't change all Sun system in world, let's try to make our > system at least able to talk with them. > > I've not yet taken a look at ytalk, but if the other side needs to use > ytalk also, does not solve my problem. I have tried making talking to a Sun possible with ytalk. I did not succeed :-( And yes, there was neither ntalk nor ytalk on the Sun. Sander > > // > // Jamie Bowden > // > // Network Administrator, TBI Ltd. > // > > > Jonny > > -- > Joao Carlos Mendes Luis jonny@gta.ufrj.br > +55 21 290-4698 ( Job ) jonny@cisi.coppe.ufrj.br > Network Manager UFRJ/COPPE/CISI > Universidade Federal do Rio de Janeiro > From owner-freebsd-hackers Wed Dec 18 01:29:13 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id BAA25806 for hackers-outgoing; Wed, 18 Dec 1996 01:29:13 -0800 (PST) Received: from root.com (implode.root.com [198.145.90.17]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id BAA25801 for ; Wed, 18 Dec 1996 01:29:11 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by root.com (8.7.6/8.6.5) with SMTP id BAA10909; Wed, 18 Dec 1996 01:28:49 -0800 (PST) Message-Id: <199612180928.BAA10909@root.com> X-Authentication-Warning: implode.root.com: Host localhost [127.0.0.1] didn't use HELO protocol To: Cyrus Gray cc: hackers@freebsd.org Subject: Re: Network Cards In-reply-to: Your message of "Tue, 17 Dec 1996 22:30:53 PST." From: David Greenman Reply-To: dg@root.com Date: Wed, 18 Dec 1996 01:28:49 -0800 Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >Thanks for all of the help setting up my HD. > >Now my next (and hopefully last question) >Does FreeBSD Support the Intel Pro/100 100 Mbs PCI Nic? FreeBSD supports the Pro/100 model "B". We don't support the old original Pro/100 (which is a completely different animal). -DG David Greenman Core-team/Principal Architect, The FreeBSD Project From owner-freebsd-hackers Wed Dec 18 01:37:30 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id BAA26144 for hackers-outgoing; Wed, 18 Dec 1996 01:37:30 -0800 (PST) Received: from rah.star-gate.com ([204.188.121.18]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id BAA26127; Wed, 18 Dec 1996 01:37:25 -0800 (PST) Received: from rah.star-gate.com (localhost.star-gate.com [127.0.0.1]) by rah.star-gate.com (8.7.6/8.7.3) with ESMTP id BAA03625; Wed, 18 Dec 1996 01:37:12 -0800 (PST) Message-Id: <199612180937.BAA03625@rah.star-gate.com> X-Mailer: exmh version 1.6.9 8/22/96 To: hackers@freebsd.org cc: multimedia@freebsd.org Subject: mmap problems? Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 18 Dec 1996 01:37:12 -0800 From: Amancio Hasty Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I have an old program "tv" which used to work okay. frame_size = 38896; if ((video = open("/dev/meteor0", O_RDONLY)) < 0) { fprintf(stderr, "open failed: %s\n", strerror(errno)); exit(1); } After running the program several times, tv exits with a a memory access violation. It looks like the system is not giving me access to the last page of the frame buffer. Any hints? Tnks Amancio From owner-freebsd-hackers Wed Dec 18 01:48:52 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id BAA26553 for hackers-outgoing; Wed, 18 Dec 1996 01:48:52 -0800 (PST) Received: from korin.warman.org.pl (korin.warman.org.pl [148.81.160.10]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id BAA26548 for ; Wed, 18 Dec 1996 01:48:42 -0800 (PST) Received: from localhost (abial@localhost) by korin.warman.org.pl (8.8.3/8.7.3) with SMTP id KAA00418 for ; Wed, 18 Dec 1996 10:48:27 +0100 (MET) Date: Wed, 18 Dec 1996 10:48:27 +0100 (MET) From: Andrzej Bialecki To: freebsd-hackers@FreeBSD.ORG Subject: 2.2-ALPHA hangs while calibrating clocks... Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hello, I'm trying to install FreeBSD 2.2-ALPHA on my machine. Here is configuration: * MB SOYO Intel Triton HX, Pentium 120MHz, BIOS Award * 64MB RAM EDO, pipeline burst cache 512k * HDD IDE WDC32100 (2.1 GB) LBA mode 4, floppy drive etc... * 3c509 ISA ethernet adapter (ep0) The kernel is, of course, GENERIC 2.2-ALPHA. So, the installation itself goes well (although I used 2.1.6 install floppy), and then, after rebooting with newly installed system, it hangs almost forever (at least for 15 minutes :-) ) saying: Calibrating clock(s) relative to mc146818A clock... and then says it failed. So my question is: do I have a broken motherboard? Are there any options in kernel config that I should change in order to avoid this looong waiting? Thanks for help Andy +-------------------------------------------------------------------------+ Andrzej Bialecki _) _) _)_) _)_)_) _) _) --------------------------------------- _)_) _) _) _) _)_) _)_) Research and Academic Network in Poland _) _)_) _)_)_)_) _) _) _) Bartycka 18, 00-716 Warsaw, Poland _) _) _) _) _)_)_) _) _) +-------------------------------------------------------------------------+ From owner-freebsd-hackers Wed Dec 18 03:10:47 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id DAA29942 for hackers-outgoing; Wed, 18 Dec 1996 03:10:47 -0800 (PST) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id DAA29936 for ; Wed, 18 Dec 1996 03:10:43 -0800 (PST) Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.3/8.6.9) id WAA31169; Wed, 18 Dec 1996 22:00:55 +1100 Date: Wed, 18 Dec 1996 22:00:55 +1100 From: Bruce Evans Message-Id: <199612181100.WAA31169@godzilla.zeta.org.au> To: abial@korin.warman.org.pl, freebsd-hackers@FreeBSD.ORG Subject: Re: 2.2-ALPHA hangs while calibrating clocks... Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >I'm trying to install FreeBSD 2.2-ALPHA on my machine. Here is >configuration: > >* MB SOYO Intel Triton HX, Pentium 120MHz, BIOS Award >* 64MB RAM EDO, pipeline burst cache 512k >* HDD IDE WDC32100 (2.1 GB) LBA mode 4, floppy drive etc... >* 3c509 ISA ethernet adapter (ep0) > >The kernel is, of course, GENERIC 2.2-ALPHA. > >So, the installation itself goes well (although I used 2.1.6 install >floppy), and then, after rebooting with newly installed system, it hangs >almost forever (at least for 15 minutes :-) ) saying: > >Calibrating clock(s) relative to mc146818A clock... > >and then says it failed. > >So my question is: do I have a broken motherboard? Are there any options >in kernel config that I should change in order to avoid this looong >waiting? The RTC seems to be broken after the reboot. The calibration routine just waits for the seconds counter to change twice. It apparently didn't change for 15 minutes. There is a generous timeout of 100 million reads of the seconds counter to give it a chance to change. Change it to 1 million (in clock.c). Bruce From owner-freebsd-hackers Wed Dec 18 05:48:42 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id FAA06943 for hackers-outgoing; Wed, 18 Dec 1996 05:48:42 -0800 (PST) Received: (from davidn@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id FAA06937 for freebsd-hackers@freebsd.org; Wed, 18 Dec 1996 05:48:41 -0800 (PST) From: David Nugent Message-Id: <199612181348.FAA06937@freefall.freebsd.org> Subject: 8-bit characters in gecos field To: freebsd-hackers@freebsd.org Date: Thu, 19 Dec 1996 00:48:41 +1100 (EST) X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I've been entertaining the idea of having pw(8) allow 8-bit characters in the passwd GECOS field. It was suggested earlier that this might cause problems in email, but as far as I can determine, sendmail handles this correctly by conversion to quoted-printable. Other MIME mailers seem to do much the same thing (ie. zmailer 2.99.x). Whether or not this is readable on the receiving system depends of course on the character-set header, but this becomes more an issue to do with user/system configuration. Are there any other areas of possible breakage that this could cause? Some testing here suggests not, and I've already noticed a few posts in the freeebsd mailing lists from people who are using 8-bit in gecos (or overriding it via their user agent). Please let me know if tehre are any objections. The other issue this raises is how gecos entries with 8-bit should be interpreted. I think this could be well covered by using the user's login class via a lang= entry. I already have a working login class implementation, and after some associated changes elsewhere in the source tree, I hope to be committing it to the -current branch. Regards, David Nugent - Unique Computing Pty Ltd - Melbourne, Australia Voice +61-3-9791-9547 Data/BBS +61-3-9792-3507 3:632/348@fidonet davidn@freefall.org davidn@blaze.net.au http://www.blaze.net.au/~davidn/ From owner-freebsd-hackers Wed Dec 18 06:21:57 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id GAA08640 for hackers-outgoing; Wed, 18 Dec 1996 06:21:57 -0800 (PST) Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id GAA08634 for ; Wed, 18 Dec 1996 06:21:38 -0800 (PST) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id PAA17896; Wed, 18 Dec 1996 15:21:08 +0100 Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id PAA02452; Wed, 18 Dec 1996 15:21:03 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.8.4/8.6.9) id JAA21158; Wed, 18 Dec 1996 09:39:57 +0100 (MET) From: J Wunsch Message-Id: <199612180839.JAA21158@uriah.heep.sax.de> Subject: Re: your mail To: freebsd-hackers@freebsd.org (FreeBSD hackers) Date: Wed, 18 Dec 1996 09:39:57 +0100 (MET) Cc: yuda@kagoshima-ct.ac.jp Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: from Snob Art Genre at "Dec 17, 96 04:56:23 pm" 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 X-Mailer: ELM [version 2.4ME+ PL17 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk As Snob Art Genre wrote: > > Hello, My name is Toshiyuki Yuda who depends on Kagoshima National College of Thchnology. > > I have any questions. > > I want to ride BSD/386 on PC-9801NS/T. > > What is a PC-9801NS/T? Unless it uses Micro Channel Architecture you're > probably fine. Judging from the name, i would instantly assume that it belongs to the ``PC98'' family. So no, it's certainly not MCA, and yes, FreeBSD probably runs on it. There's a special version called ``FreeBSD(98)'' for it. Since these machines are (to the best of my knowledge) only available and most useful in Japan, many of the baseline FreeBSD developers throughout the world don't know very much about FreeBSD(98), even though the sources are kept in the same CVS repository now. I hope our Japanese team members, like asami@freebsd.org or max@freebsd.org might give you a pointer for FreeBSD(98). -- 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 Wed Dec 18 06:40:54 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id GAA09347 for hackers-outgoing; Wed, 18 Dec 1996 06:40:54 -0800 (PST) Received: from Octopussy.MI.Uni-Koeln.DE (Octopussy.MI.Uni-Koeln.DE [134.95.166.20]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id GAA09322 for ; Wed, 18 Dec 1996 06:40:43 -0800 (PST) Received: from x14.mi.uni-koeln.de (annexr2-41.slip.Uni-Koeln.DE) by Octopussy.MI.Uni-Koeln.DE with SMTP id AA24847 (5.67b/IDA-1.5 for ); Wed, 18 Dec 1996 15:37:08 +0100 Received: (from se@localhost) by x14.mi.uni-koeln.de (8.8.4/8.6.9) id PAA02898; Wed, 18 Dec 1996 15:24:09 +0100 (CET) Message-Id: Date: Wed, 18 Dec 1996 15:22:48 +0100 From: se@freebsd.org (Stefan Esser) To: jin@george.lbl.gov (Jin Guojun[ITG]) Cc: erich@lodgenet.com, hackers@freebsd.org Subject: Re: Q for loadable network driver References: <199612162119.NAA29129@george.lbl.gov> X-Mailer: Mutt 0.53 Mime-Version: 1.0 In-Reply-To: <199612162119.NAA29129@george.lbl.gov>; from Jin Guojun[ITG] on Dec 16, 1996 13:19:33 -0800 Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Dec 16, jin@george.lbl.gov (Jin Guojun[ITG]) wrote: > Another question is that is necessary to link the newly loaded driver to > the kernel control block -- > /sys/pci.c:155:static struct pcicb *pcicb; > ------------------------------------------------------------- > pci/pci.c: unmodified: line 704 -- > /* > ** allocate bus descriptor for bus behind the bridge > */ > link = &pcicb->pcicb_down; > while (*link && (*link)->pcicb_bus < secondary) > link = &(*link)->pcicb_next; > > this = malloc (sizeof (*this), M_DEVBUF, M_WAITOK); > > ... ... > > /* > ** Link it in chain. > */ > *link=this; > pci/pci.c: unmodified: line 819 -- > ----------------------------------------------------------------- > Without an interface to get the PCI control block address -- &pcicb -- it is > hardly to link the new information into the kernel PCI chain. > Also, is the segment above (pci/pci.c line 704 - 819) necessary for loading > a loadable device driver? I've been thinking about PCI LKMs, and my proposed solution would work this way: - Have a user land command retrieve information about PCI devices that got no driver assigned (easy, use ioctl() on /dev/pci after I apply a simple patch :) - This user land program will then scan for a file with the correct driver. This will most probably be done by having a PCI LKM config file under /etc, which contains the LKM name that corresponds to some PCI vendor+device ID (or the subvendorid). Something along the lines of: 0x00011000 pci_ncr.o 0x000f1000 pci_ncr.o 0x802910ec pci_ed.o Then a modload is performed, which will add the driver to the list of known PCI drivers. I think the device driver should just be loaded, and a PCI bus rescan be initiated, which will find the new driver, and will attach all devices it is able to support. (This is already prepared for in the current PCI code.) So, all you need (IMHO) is: - The patch to pci_ioctl(), which puts the information whether there was a driver for some device into the pciconf struct. - A function to call from the LKM to register the new driver. The PCI code will test drivers on a linked list (and prefer them to compiled in code) for this to become effective. - A function that initiates a PCI bus rescan. Possibly combined with the previous one, but I would in fact prefer to have a separate load, unload and rescan function ... (Or would having rescan implied by load, and stopping the driver before unload be better ??? Possible ...) What do you think about these changes ? The result will be, that your PCI LKM is called with the corresponding PCI tag. The driver must receive the &pcibus to be able to call back into the PCI code, and this may either be by making pcibus a global variable again, or by making it an additional parameter of the attach function. Would this help ? Regards, STefan From owner-freebsd-hackers Wed Dec 18 07:45:59 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id HAA11854 for hackers-outgoing; Wed, 18 Dec 1996 07:45:59 -0800 (PST) Received: from fang.cs.sunyit.edu (fang.cs.sunyit.edu [192.52.220.66]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id HAA11846 for ; Wed, 18 Dec 1996 07:45:56 -0800 (PST) Received: (from chuck@localhost) by fang.cs.sunyit.edu (8.7.6/8.7.3) id KAA14647 for hackers@freebsd.org; Wed, 18 Dec 1996 10:45:15 -0500 (EST) Date: Wed, 18 Dec 1996 10:45:15 -0500 (EST) From: Charles Green Message-Id: <199612181545.KAA14647@fang.cs.sunyit.edu> X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: hackers@freebsd.org Subject: Bootloaders Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Has anyone considered grub? It seems like a handy piece of software. It's GPL'd but the author states "GRUB is currently available under the GNU General Public License. This should not be an issue for OS evelopers or users who dislike the terms of the GPL, as it is a separate package, and will not have any icensing impact upon their own work or installation. If it is still an issue, send me e-mail and maybe we canwork something out." -- Charles Green, PRC Inc. Rome Laboratory, NY From owner-freebsd-hackers Wed Dec 18 07:50:52 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id HAA12190 for hackers-outgoing; Wed, 18 Dec 1996 07:50:52 -0800 (PST) Received: from fallout.campusview.indiana.edu (fallout.campusview.indiana.edu [149.159.1.1]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id HAA12183 for ; Wed, 18 Dec 1996 07:50:48 -0800 (PST) Received: from localhost (jfieber@localhost) by fallout.campusview.indiana.edu (8.8.4/8.8.4) with SMTP id KAA06605; Wed, 18 Dec 1996 10:50:29 -0500 (EST) Date: Wed, 18 Dec 1996 10:50:29 -0500 (EST) From: John Fieber To: Chuck Robey cc: Frank Nobis , hackers@FreeBSD.ORG Subject: Re: Weired c++ behaviour regarding iostreams In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Tue, 17 Dec 1996, Chuck Robey wrote: > Trouble is, you try to use both stdio.h (which is C's i/o functions) and > iostream.h (which is C++'s i/o functions). Since they both try to do > buffering of their own, outside of the operating system buffering, this is > a big no-no. Choose your poison, either stdio.h (which works fine with > C++) or iostreams, but not both. In *theory*, the gnu iostreams are supposed to (by default) work with C i/o, but with a performance penalty. I've just been experimenting a bit and if you only use iostreams, you can set ios::sync_with_stdio(0); for a substantial performance boost. I just discovered the iostreams info file last night which documents the library quite nicely. :) -john From owner-freebsd-hackers Wed Dec 18 10:00:30 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id KAA19302 for hackers-outgoing; Wed, 18 Dec 1996 10:00:30 -0800 (PST) Received: from gatekeeper.sciatl.com (Gatekeeper.SciAtl.COM [192.133.190.1]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id KAA19296 for ; Wed, 18 Dec 1996 10:00:24 -0800 (PST) From: nishika@sm10.sciatl.com Received: from smap@localhost by gatekeeper.sciatl.com via smapdV1.3 id MAA00543; Wed, 18 Dec 1996 12:59:34 -0500 Received: from nethost1.sm10.sciatl.com by gatekeeper.sciatl.com for via SMTP (smap V1.3) id sma000497; Wed Dec 18 12:59:30 1996 Received: from sachi.sm10.sciatl.com by sm10.sciatl.com (5.x/SMI-SVR4.drj) id AA29032; Wed, 18 Dec 1996 12:59:17 -0500 Message-Id: <32B832D1.3374@sm10.sciatl.com> Date: Wed, 18 Dec 1996 13:07:13 -0500 X-Mailer: Mozilla 2.01I [ja] (Win95; I) Mime-Version: 1.0 To: freebsd-hackers@freebsd.org Cc: yuda@kagoshima-ct.ac.jp Subject: Re: your mail Content-Type: text/plain; charset=iso-2022-jp Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk J Wunsch wrote: > > > I want to ride BSD/386 on PC-9801NS/T. > > > > What is a PC-9801NS/T? Unless it uses Micro Channel Architecture you're > > probably fine. > > Judging from the name, i would instantly assume that it belongs to the > ``PC98'' family. So no, it's certainly not MCA, and yes, FreeBSD > probably runs on it. There's a special version called ``FreeBSD(98)'' > for it. Since these machines are (to the best of my knowledge) only > available and most useful in Japan, many of the baseline FreeBSD > developers throughout the world don't know very much about > FreeBSD(98), even though the sources are kept in the same CVS > repository now. I believe all of them are true. I'm not FreeBSD(98) user, but FreeBSD user. Now I'm in US and I can't contact my friends, good 98-users, right now. I think followings are more helpful for this question: http://www.jp.freebsd.org/ - Japan FreeBSD User's Group http://www.jp.freebsd.org/ml.html - FreeBSD and FreeBSD(98) Japanese Mailing List http://zephyr.elcom.nitech.ac.jp/~yuki/FreeBSD/search.html - Search Engine for FreeBSD and FreeBSD Japanese Mailing List --- #! /usr/local/bin/nishika # Katsuji Nishikawa # E-Mail: nishika@sm10.sciatl.com, [Not currently:katsuji@mie-com.co.jp] # - If it's somewhere, I'll use it. If it's nowhere, I'll make it. - From owner-freebsd-hackers Wed Dec 18 10:14:26 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id KAA19957 for hackers-outgoing; Wed, 18 Dec 1996 10:14:26 -0800 (PST) Received: from sequent.kiae.su (sequent.kiae.su [193.125.152.6]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id KAA19947 for ; Wed, 18 Dec 1996 10:14:24 -0800 (PST) Received: by sequent.kiae.su id AA26907 (5.65.kiae-2 ); Wed, 18 Dec 1996 21:49:56 +0400 Received: by sequent.KIAE.su (UUMAIL/2.0); Wed, 18 Dec 96 21:49:50 +0400 Received: from localhost (nagual.ru [127.0.0.1]) by nagual.ru (8.8.4/8.8.4) with ESMTP id UAA00925; Wed, 18 Dec 1996 20:47:58 +0300 (MSK) Date: Wed, 18 Dec 1996 20:47:57 +0300 (MSK) From: =?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7=2C_Andrey_Chernov?= To: David Nugent Cc: freebsd-hackers@freebsd.ORG Subject: Re: 8-bit characters in gecos field In-Reply-To: <199612181348.FAA06937@freefall.freebsd.org> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=KOI8-R Content-Transfer-Encoding: 8BIT Sender: owner-hackers@freebsd.ORG X-Loop: FreeBSD.org Precedence: bulk On Thu, 19 Dec 1996, David Nugent wrote: > I've been entertaining the idea of having pw(8) allow 8-bit > characters in the passwd GECOS field. It was suggested earlier > that this might cause problems in email, but as far as I can > determine, sendmail handles this correctly by conversion to > quoted-printable. Other MIME mailers seem to do much the same > thing (ie. zmailer 2.99.x). Whether or not this is readable > on the receiving system depends of course on the character-set > header, but this becomes more an issue to do with user/system > configuration. There is no break as I see, but no sense too, because it is unclear what character set you use for names. I.e. when finger sends you some 8bit codes like this: áÎÄŌÅĘ þÅŌÎÏŨ, what do you do with them? -- Andrey A. Chernov http://www.nagual.ru/~ache/ From owner-freebsd-hackers Wed Dec 18 10:39:09 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id KAA20910 for hackers-outgoing; Wed, 18 Dec 1996 10:39:09 -0800 (PST) Received: from austin.polstra.com (austin.polstra.com [206.213.73.10]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id KAA20902 for ; Wed, 18 Dec 1996 10:38:59 -0800 (PST) Received: (from jdp@localhost) by austin.polstra.com (8.8.3/8.8.3) id KAA26882; Wed, 18 Dec 1996 10:38:58 -0800 (PST) To: freebsd-hackers@freebsd.org Path: not-for-mail From: jdp@polstra.com (John Polstra) Newsgroups: polstra.freebsd.hackers Subject: Re: Nasty gotcha with CVS/CVSup setup Date: 18 Dec 1996 10:38:58 -0800 Organization: Polstra & Co., Seattle, WA Lines: 20 Distribution: local Message-ID: <599do2$q7v@austin.polstra.com> References: <199612180637.RAA29514@genesis.atrad.adelaide.edu.au> Fcc: outbox Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In article <199612180637.RAA29514@genesis.atrad.adelaide.edu.au>, Michael Smith wrote: > > In trying to keep the footprint of my CVS repository down to a reasonable > level, I've listed Attic directories in my CVSup 'Refuse' files. > > But this comes back to bite me when I check out, say, RELENG_2_2, where > files have been subsequently deleted. In the case of 2.2, it makes the > world unbuildable. Grr. Yup, it always seems like a good idea to suppress those "useless" Attic files. But if you do that, the only thing you're guaranteed to be able to check out and build is today's version of -current. If that's all you want, there's no point in maintaining a repository at all. 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-hackers Wed Dec 18 10:55:20 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id KAA21513 for hackers-outgoing; Wed, 18 Dec 1996 10:55:20 -0800 (PST) Received: from pat.uio.no (6089@pat.uio.no [129.240.2.50]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id KAA21507 for ; Wed, 18 Dec 1996 10:55:17 -0800 (PST) Received: from ulrik.uio.no by pat.uio.no with local-SMTP (PP) id <15986-0@pat.uio.no>; Wed, 18 Dec 1996 19:55:07 +0100 Received: from cray.svaar.no (cray.svaar.no [194.19.7.150]) by gilgamesj.uio.no ; Wed, 18 Dec 1996 19:55:04 +0100 (MET) Date: Wed, 18 Dec 1996 19:55:04 +0100 (MET) Message-Id: <199612181855.TAA13170@gilgamesj.uio.no> X-Sender: svaar@gilgamesj.uio.no X-Mailer: Windows Eudora Version 1.4.4 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: hackers@freebsd.org From: svaar@math.uio.no (Peter Svaar) Subject: PPP problem Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk ok, I admit, I'm a jerk. but hey, jerks want to run FreeBSD too! I've been running linux for quite some time now (a couple of years) and I've been into both slackware, debian and red hat. for my expanding computing needs, they do not cope. so FreeBSD must be it. well, I downloadet boot.flp and configured an FTP install. I am constantly connected to the net (not dialup) thorough a two-thread line (28.8). I go for PPP install, everything OK, but the program can't detect my modem. I try to change "set device" to /dev/cuaa0, /dev/cuaa1 and so further, nothing works. I can't seem to get in contact with the modem. I try "term" and "dial", I think I virtually have tried everything, changing the modem from com2 to com1, trying all sorts of combinations, trying slip. It won't work. I use 2.1.6. what should I do? I've tried all sorts of changing speed machine <-> modem, changing ports, setting device in the PPP program, configuring the kernel to remove conflicts, everything.. -- Peter Svaar | Contact Information: svaar@math.uio.no | http://www.math.uio.no/~svaar From owner-freebsd-hackers Wed Dec 18 12:38:36 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id MAA25555 for hackers-outgoing; Wed, 18 Dec 1996 12:38:36 -0800 (PST) Received: from bugs.us.dell.com (bugs.us.dell.com [143.166.169.147]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id MAA25547 for ; Wed, 18 Dec 1996 12:38:34 -0800 (PST) Received: from ant.us.dell.com (ant.us.dell.com [198.64.66.34]) by bugs.us.dell.com (8.6.12/8.6.12) with SMTP id OAA22968; Wed, 18 Dec 1996 14:37:37 -0600 Message-Id: <3.0.1.32.19961218143733.0068f0ac@bugs.us.dell.com> X-Sender: tony@bugs.us.dell.com X-Mailer: Windows Eudora Light Version 3.0.1 beta 4 (32) Date: Wed, 18 Dec 1996 14:37:46 -0500 To: Bruce Evans , julian@whistle.com From: Tony Overfield Subject: Re: Boot loader hacks was: Re: MAXMEM Cc: hackers@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Tony Overfield wrote: >>I think that boot2 can only be 7 KB. Even so, there seems to be plenty >>of space to do this. With all the options enabled, I'll now say that "plenty" was a wee bit optimistic. At 04:33 AM 12/17/96 +1100, Bruce Evans wrote: >It can be of almost any size, but is currently limited to 7.5K (or >4.5K on 9-sector floppies :-). >[snip] >There is also a 7.5K limit because the boot blocks are too stupid to >load themselves if they cross a track boundary. Are you talking about the size limit of boot1 + boot2 combined, or is this check wrong? This check seems to limit boot2 to 7 KB. @dd if=boot2 skip=14 of=sizetest 2> /dev/null @if [ -s sizetest ] ; then \ echo "boot2 is too big" >&2 ; \ rm boot2 ; \ exit 2 ; \ fi >Don't forget to compile it with all the options :-). I think it's >already over 7.5K if they are all enabled. It looks like it fits in 7 (7.5) KB with all the options enabled. >> Does anyone know why the comment, >>"Prefer the RTC value for extended memory." appears near this code? >> >>Well I didn't, so I added these lines right afterwards: >> >> if (bootinfo.bi_extmem > biosextmem) >> biosextmem = bootinfo.bi_extmem; > >Because of the rule "never change a ``working'' system". It's just as >well that it wasn't changed - memsize() doesn't clear the top 16 bits >properly, even for the base memory size. Believe it or not, I did notice that, but it's ok since real_to_prot() clobbers the upper half for us (unless the level-one cache is turned off using cr0 :-o). Well, it's not really ok, but it does work. At 10:55 AM 12/16/96 -0800, Julian Elischer wrote: >now try compile it with a mix of other options.... >(specifically NAMEBLOCK and PROBE_KEYBOARD etc.) >and see if it STILL fits.... It still fits (barely). Here's a sample of the make output showing the options I enabled. cc -O2 -malign-functions=0 -malign-jumps=0 -malign-loops=0 -DDO_BAD144 -DBOOTWAIT=5000 -DTIMEOUT= -DBOOTSEG=0x1000 -DBOOTSTACK=0xFFF0 -I/usr/src/sys/i386/newboot/biosboot/../../.. -W -Wreturn-type -Wcomment -Wredundant-decls -Wimplicit -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Winline -Wpointer-arith -DPROBE_KEYBOARD -DPROBE_KEYBOARD_LOCK -DFORCE_COMCONSOLE -DCOMCONSOLE=0x3F8 -DCONSPEED=9600 -DNAMEBLOCK -DNAMEBLOCK_WRITEBACK -DBOOT_HD_BIAS=1 -c boot.c Will all the options listed above (including my hacks), the boot2 file is 7152 bytes. That means there are still over 15 bytes left for additional features, error checking and bug fixes. ;-) I'll withdraw my suggestion, since the space is so tight. I'll be plenty happy using it by myself, however. After I decided that a three stage boot process would be an easy to implement band-aid for the space problem, I decided to check the archives to see why nobody has done it yet. Though it was difficult to follow the threads, I got the impression that the three stage boot proposals seemed more complicated than they needed to be. Was there some kind of trouble keeping the feature list small when imagining so much more code space for the boot loader. Don't bother responding to this point if it's an already beaten (and dead) horse. Tony - From owner-freebsd-hackers Wed Dec 18 12:40:46 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id MAA25788 for hackers-outgoing; Wed, 18 Dec 1996 12:40:46 -0800 (PST) Received: from anacreon.sol.net (anacreon.sol.net [206.55.64.116]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id MAA25778 for ; Wed, 18 Dec 1996 12:40:43 -0800 (PST) Received: from solaria.sol.net (solaria.sol.net [206.55.65.75]) by anacreon.sol.net (8.6.12/8.6.12) with ESMTP id OAA05672; Wed, 18 Dec 1996 14:40:40 -0600 Received: from localhost by solaria.sol.net (8.5/8.5) id OAA16877; Wed, 18 Dec 1996 14:40:37 -0600 From: Joe Greco Message-Id: <199612182040.OAA16877@solaria.sol.net> Subject: Re: A question on diskless boot To: luigi@labinfo.iet.unipi.it (Luigi Rizzo) Date: Wed, 18 Dec 96 14:40:34 CST Cc: phk@critter.tfs.com, hackers@FreeBSD.org In-Reply-To: <199612160841.JAA00321@labinfo.iet.unipi.it> from "Luigi Rizzo" at Dec 16, 96 09:41:53 am X-Mailer: ELM [version 2.4dev PL65] MIME-Version: 1.0 Content-Type: text Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > > Finally, you may want to try to see if you can get any kind > > of boot-proms for the de0 cards, and use whatever method they > > use to get live. > > the ones I have don't even have a socket :(! I am reasonably certain that the new SMC 10/100 EtherPower's do. I was very curious about this very issue myself, but haven't had the time to do anything much yet. ... JG From owner-freebsd-hackers Wed Dec 18 12:46:48 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id MAA26225 for hackers-outgoing; Wed, 18 Dec 1996 12:46:48 -0800 (PST) Received: from time.cdrom.com (time.cdrom.com [204.216.27.226]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id MAA26220 for ; Wed, 18 Dec 1996 12:46:46 -0800 (PST) Received: from time.cdrom.com (localhost [127.0.0.1]) by time.cdrom.com (8.8.4/8.6.9) with ESMTP id MAA06090; Wed, 18 Dec 1996 12:44:26 -0800 (PST) To: Paul Richards cc: Michael Smith , hackers@FreeBSD.org Subject: Re: text, menu/dialog/windowing, library, ideas? In-reply-to: Your message of "02 Dec 1996 13:00:21 GMT." <57ybfht82i.fsf@tees.elsevier.co.uk> Date: Wed, 18 Dec 1996 12:44:26 -0800 Message-ID: <6086.850941866@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > libforms had this working. Objects inherited properties of the parent so > you could create a box object that encapsulated a border drawing widget > and a label widget etc. Yeah, I remember the data structures looked clean enough, we just never got anything working below it well enough to give it any actual degree of usability for anything. :-( > On the html front, html is not a good way to go about this. You could > not do what you did with libdialog using html. Don't fall into the > trap of believing html is a display language, at heart it's SGML but > with bells and whistles thrown in by some browser developers. It's a > really naff way to spec a user interface. I've come to the same conclusion. I'm not saying that HTML driven interfaces won't somewhere come into play anyway (since there are people actually working on that), but if they do tie an HTML browser into this system administration tool then it definitely shouldn't be through pretending to be just another GUI abstraction. The CGI stuff can simply call the CLI commands. > Hmm, if you still want something like this I'd be interested in > digging it up again. It already had all the infrastructure, the things > it was lacking were widgets for different display classes. It's been > on my list of future projects anyway to dig it up and finish it off as > libpui (portable user interface). I'm always happy to look at stuff.. :-) Jordan From owner-freebsd-hackers Wed Dec 18 12:50:47 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id MAA26483 for hackers-outgoing; Wed, 18 Dec 1996 12:50:47 -0800 (PST) Received: from iafnl.es.iaf.nl (uucp@iafnl.es.iaf.nl [195.108.17.20]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id MAA26468 for ; Wed, 18 Dec 1996 12:50:43 -0800 (PST) Received: by iafnl.es.iaf.nl with UUCP id AA00783 (5.67b/IDA-1.5 for FreeBSD-hackers@freebsd.org); Wed, 18 Dec 1996 21:50:15 +0100 Received: (from wilko@localhost) by yedi.iaf.nl (8.7.5/8.6.12) id UAA01730 for FreeBSD-hackers@freebsd.org; Wed, 18 Dec 1996 20:39:35 +0100 (MET) From: Wilko Bulte Message-Id: <199612181939.UAA01730@yedi.iaf.nl> Subject: anyone using an Ultrastor U24f EISA under 215R To: FreeBSD-hackers@freebsd.org (FreeBSD hackers list) Date: Wed, 18 Dec 1996 20:39:34 +0100 (MET) X-Mailer: ELM [version 2.4 PL24 ME8a] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi there, Is anyone successfully using an Ultrastor U24f with 215R? I get things like: "USC024 unknown device" during EISA probe. And subsequently things like uha0: cmd fail, uha_abort, board is not responding. Things work OK with MSDOZE. Then the whole thing hangs during the open of the root device (which is sd0 on the U24f). The U24f worked OK with 2.1R if I remember correctly (In case someone wonders why I bother to use the U24f: it looks like I can trade the current Adaptec 1740A for a Compaq 486/33 portable. An old one (with ISA bus) in a sort of shoebox, but still servicable) Input appreciated. Wilko _ ____________________________________________________________________ | / o / / _ Bulte email: wilko@yedi.iaf.nl - Arnhem, The Netherlands |/|/ / / /( (_) Do, or do not. There is no 'try' - Yoda -------------------------------------------------------------------------- From owner-freebsd-hackers Wed Dec 18 12:50:50 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id MAA26509 for hackers-outgoing; Wed, 18 Dec 1996 12:50:50 -0800 (PST) Received: from iafnl.es.iaf.nl (uucp@iafnl.es.iaf.nl [195.108.17.20]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id MAA26482 for ; Wed, 18 Dec 1996 12:50:47 -0800 (PST) Received: by iafnl.es.iaf.nl with UUCP id AA00880 (5.67b/IDA-1.5 for FreeBSD-hackers@freebsd.org); Wed, 18 Dec 1996 21:50:29 +0100 Received: (from wilko@localhost) by yedi.iaf.nl (8.7.5/8.6.12) id VAA02364 for FreeBSD-hackers@freebsd.org; Wed, 18 Dec 1996 21:49:14 +0100 (MET) From: Wilko Bulte Message-Id: <199612182049.VAA02364@yedi.iaf.nl> Subject: more on Ultrastor U24f and a solution (sort of) To: FreeBSD-hackers@freebsd.org (FreeBSD hackers list) Date: Wed, 18 Dec 1996 21:49:14 +0100 (MET) X-Mailer: ELM [version 2.4 PL24 ME8a] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi Did some more testing 'n hacking on the Ultrastor 24f. It has proven to be a combination of the U24f driver and the Toshiba CDROM I have in this box: During boot/probe the SCSI CD driver does: ... /* * Use the subdriver to request information regarding * the drive. We cannot use interrupts yet, so the * request must specify this. * * XXX dufault@hda.com: * Need to handle this better in the case of no record. Rather than * a state driven sense handler I think we should make it so that * the command can get the sense back so that it can selectively log * errors. */ cd_get_parms(unit, SCSI_NOSLEEP | SCSI_NOMASK); if (dp->disksize) { printf("cd present.[%ld x %ld byte records]", cd->params.disksize, cd->params.blksize); } else { printf("can't get the size\n"); } ... The Toshiba's (I have multiple, all behave the same) report something like: (ncr0:4:0): "TOSHIBA CD-ROM XM-5301TA 0925" type 5 removable SCSI 2 cd0(ncr0:4:0): CD-ROM cd0(ncr0:4:0): 250ns (4 Mb/sec) offset 8. cd0(ncr0:4:0): NOT READY asc:4,1 cd0(ncr0:4:0): Logical unit is in process of becoming ready can't get the size This is how it works with the Pentium machine. The 486 EISA however locks up the U24f driver during the check for a loaded CDROM. This only seems to happen if the system has been power cycled and then booted. Whether a CD is loaded or not makes no difference. Uncommenting piece of code that does this probe results in a working system. So, for now I assume the lower level U24f driver cannot handle somewhat special reqs the cd_get_parms() has. It's somewhat nasty because the bootfloppy kills itself in a similar fashion. My question: is there any reason to do this cd_get_parms() in this early stage of probing? Why not do this on a first normal open() when the kernel is up & running? Fixing the ultra14f.c to not lockup is of course also an option ;-) Wilko _ ____________________________________________________________________ | / o / / _ Bulte email: wilko@yedi.iaf.nl - Arnhem, The Netherlands |/|/ / / /( (_) Do, or do not. There is no 'try' - Yoda -------------------------------------------------------------------------- From owner-freebsd-hackers Wed Dec 18 13:04:22 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id NAA27490 for hackers-outgoing; Wed, 18 Dec 1996 13:04:22 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id NAA27450; Wed, 18 Dec 1996 13:04:15 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id OAA10384; Wed, 18 Dec 1996 14:01:51 -0700 From: Terry Lambert Message-Id: <199612182101.OAA10384@phaeton.artisoft.com> Subject: Re: mmap problems? To: hasty@rah.star-gate.com (Amancio Hasty) Date: Wed, 18 Dec 1996 14:01:51 -0700 (MST) Cc: hackers@freebsd.org, multimedia@freebsd.org In-Reply-To: <199612180937.BAA03625@rah.star-gate.com> from "Amancio Hasty" at Dec 18, 96 01:37:12 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-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > I have an old program "tv" which used to work okay. > > frame_size = 38896; > if ((video = open("/dev/meteor0", O_RDONLY)) < 0) { > fprintf(stderr, "open failed: %s\n", strerror(errno)); > exit(1); > } > > After running the program several times, tv exits with a a memory access > violation. It looks like the system is not > giving me access to the last page of the frame buffer. Any hints? Look at the meteor driver; the page range limitation is imposed at that level. 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-hackers Wed Dec 18 13:06:09 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id NAA27595 for hackers-outgoing; Wed, 18 Dec 1996 13:06:09 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id NAA27589 for ; Wed, 18 Dec 1996 13:06:04 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id OAA10394; Wed, 18 Dec 1996 14:04:22 -0700 From: Terry Lambert Message-Id: <199612182104.OAA10394@phaeton.artisoft.com> Subject: Re: 8-bit characters in gecos field To: davidn@freefall.freebsd.org (David Nugent) Date: Wed, 18 Dec 1996 14:04:22 -0700 (MST) Cc: freebsd-hackers@freebsd.org In-Reply-To: <199612181348.FAA06937@freefall.freebsd.org> from "David Nugent" at Dec 19, 96 00:48:41 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-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > I've been entertaining the idea of having pw(8) allow 8-bit > characters in the passwd GECOS field. It was suggested earlier > that this might cause problems in email, but as far as I can > determine, sendmail handles this correctly by conversion to > quoted-printable. Other MIME mailers seem to do much the same > thing (ie. zmailer 2.99.x). Whether or not this is readable > on the receiving system depends of course on the character-set > header, but this becomes more an issue to do with user/system > configuration. This assumes that it supports the ESMTP extention "8BITMIME"; the unextended RFC821 (minimal implementation, no RFC1425 "EHLO") does not allow 8 bit characters. You might also see problems with POP3 (but not IMAP4). 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-hackers Wed Dec 18 13:08:06 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id NAA27720 for hackers-outgoing; Wed, 18 Dec 1996 13:08:06 -0800 (PST) Received: from rah.star-gate.com ([204.188.121.18]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id NAA27653; Wed, 18 Dec 1996 13:08:00 -0800 (PST) Received: from rah.star-gate.com (localhost.star-gate.com [127.0.0.1]) by rah.star-gate.com (8.7.6/8.7.3) with ESMTP id NAA06275; Wed, 18 Dec 1996 13:06:11 -0800 (PST) Message-Id: <199612182106.NAA06275@rah.star-gate.com> X-Mailer: exmh version 1.6.9 8/22/96 To: Terry Lambert cc: hackers@freebsd.org, multimedia@freebsd.org Subject: Re: mmap problems? In-reply-to: Your message of "Wed, 18 Dec 1996 14:01:51 MST." <199612182101.OAA10384@phaeton.artisoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 18 Dec 1996 13:06:11 -0800 From: Amancio Hasty Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >From The Desk Of Terry Lambert : > > I have an old program "tv" which used to work okay. > > > > frame_size = 38896; > > if ((video = open("/dev/meteor0", O_RDONLY)) < 0) { > > fprintf(stderr, "open failed: %s\n", strerror(errno)); > > exit(1); > > } > > > > After running the program several times, tv exits with a a memory access > > violation. It looks like the system is not > > giving me access to the last page of the frame buffer. Any hints? > > Look at the meteor driver; the page range limitation is imposed at > that level. > > > Terry Lambert > terry@lambert.org > --- Hi, I am a little confuse . Why would "tv" work 3 or 5 times then fail to run because the driver did not mmap properly the pages? From owner-freebsd-hackers Wed Dec 18 13:25:23 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id NAA28470 for hackers-outgoing; Wed, 18 Dec 1996 13:25:23 -0800 (PST) Received: from anacreon.sol.net (anacreon.sol.net [206.55.64.116]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id NAA28463 for ; Wed, 18 Dec 1996 13:25:20 -0800 (PST) Received: from solaria.sol.net (solaria.sol.net [206.55.65.75]) by anacreon.sol.net (8.6.12/8.6.12) with ESMTP id PAA05911; Wed, 18 Dec 1996 15:25:14 -0600 Received: from localhost by solaria.sol.net (8.5/8.5) id PAA17161; Wed, 18 Dec 1996 15:25:11 -0600 From: Joe Greco Message-Id: <199612182125.PAA17161@solaria.sol.net> Subject: DEC 21140-AC (SMC EtherPower 10/100 9332BDT) To: luigi@labinfo.iet.unipi.it Date: Wed, 18 Dec 96 15:25:08 CST Cc: hackers@freebsd.org X-Mailer: ELM [version 2.4dev PL65] MIME-Version: 1.0 Content-Type: text Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi, The "new" SMC EtherPower 10/100 card has a socket for a _flash_ ROM. :-) It appears that SMC provides a ROM with something called "BootWare", that apparently is designed to ease the difficulty of doing diskless stuff.. >From the manual, TCP/IP Mode * TCP/IP mode requires a TFTP daemon and a BOOTP daemon to be loaded at the host. Most versions of DOS can be remote booted, along with a communication service such as NFS. For whatever that is worth. ... JG From owner-freebsd-hackers Wed Dec 18 13:58:29 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id NAA00353 for hackers-outgoing; Wed, 18 Dec 1996 13:58:29 -0800 (PST) Received: from rah.star-gate.com ([204.188.121.18]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id NAA00348 for ; Wed, 18 Dec 1996 13:58:21 -0800 (PST) Received: from rah.star-gate.com (localhost.star-gate.com [127.0.0.1]) by rah.star-gate.com (8.7.6/8.7.3) with ESMTP id NAA06578 for ; Wed, 18 Dec 1996 13:58:00 -0800 (PST) Message-Id: <199612182158.NAA06578@rah.star-gate.com> X-Mailer: exmh version 1.6.9 8/22/96 To: hackers@freebsd.org Subject: mmap and meteor. Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 18 Dec 1996 13:58:00 -0800 From: Amancio Hasty Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Prabably the problem is on the VM system given that mmap seems to work the first few times and then it fails to map all the pages requested. Amancio james@miller.cs.uwm.edu said: > From: Jim Lowe To: hasty@rah.star-gate.com > Subject: Re: Jim's mixer (jmix) > Yes, I beleive there is something wrong with the mmap system call and > the vm system. I can't tell exactly what it is or why it happens, > but it is a pain in the butt. > About a month ago, I started to investigate the problem, but havn't > been able to pin the darn thing down. I suspect John Dyson might be > able to find it, but I don't think he has a meteor card or uses mmap > quite the way we do. It is a real twisted type problem and the > solution doesn't seem real obvious to me. From owner-freebsd-hackers Wed Dec 18 14:07:47 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id OAA01078 for hackers-outgoing; Wed, 18 Dec 1996 14:07:47 -0800 (PST) Received: from time.cdrom.com (time.cdrom.com [204.216.27.226]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id OAA01073 for ; Wed, 18 Dec 1996 14:07:43 -0800 (PST) Received: from time.cdrom.com (localhost [127.0.0.1]) by time.cdrom.com (8.8.4/8.6.9) with ESMTP id OAA14497; Wed, 18 Dec 1996 14:06:35 -0800 (PST) To: Tony Overfield cc: Bruce Evans , julian@whistle.com, hackers@FreeBSD.org Subject: Re: Boot loader hacks was: Re: MAXMEM In-reply-to: Your message of "Wed, 18 Dec 1996 14:37:46 EST." <3.0.1.32.19961218143733.0068f0ac@bugs.us.dell.com> Date: Wed, 18 Dec 1996 14:06:34 -0800 Message-ID: <14493.850946794@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > After I decided that a three stage boot process would be an > easy to implement band-aid for the space problem, I decided to > check the archives to see why nobody has done it yet. Though it http://uruk.uruk.org/grub/ Doing something with this is something which has been discussed on a number of occasions, but only discussed. Perhaps its GPL'd status has a chilling effect on its import, I don't know! :) I think it also suffers from BDLI (Bruce Doesn't Like It). Jordan From owner-freebsd-hackers Wed Dec 18 14:31:43 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id OAA02213 for hackers-outgoing; Wed, 18 Dec 1996 14:31:43 -0800 (PST) Received: from mexico.brainstorm.eu.org (root@mexico.brainstorm.fr [193.56.58.253]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id OAA02198 for ; Wed, 18 Dec 1996 14:31:39 -0800 (PST) Received: from brasil.brainstorm.eu.org (brasil.brainstorm.fr [193.56.58.33]) by mexico.brainstorm.eu.org (8.7.5/8.7.3) with ESMTP id XAA08741 for ; Wed, 18 Dec 1996 23:31:29 +0100 Received: (from uucp@localhost) by brasil.brainstorm.eu.org (8.6.12/8.6.12) with UUCP id XAA20821 for hackers@freebsd.org; Wed, 18 Dec 1996 23:31:11 +0100 Received: (from roberto@localhost) by keltia.freenix.fr (8.8.4/keltia-uucp-2.9) id XAA19270; Wed, 18 Dec 1996 23:16:08 +0100 (CET) Message-ID: Date: Wed, 18 Dec 1996 23:16:08 +0100 From: roberto@keltia.freenix.fr (Ollivier Robert) To: hackers@freebsd.org Subject: Re: Network Cards References: X-Mailer: Mutt 0.54 Mime-Version: 1.0 X-Operating-System: FreeBSD 3.0-CURRENT ctm#2815 In-Reply-To: ; from Cyrus Gray on Dec 17, 1996 22:30:53 -0800 Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk According to Cyrus Gray: > Now my next (and hopefully last question) > Does FreeBSD Support the Intel Pro/100 100 Mbs PCI Nic? The 100B is indeed supported as told David and works great. I installed by 2.2-ALPHA machine at work (now 3.0-CURRENT) without any problem with it. -- Ollivier ROBERT -=- The daemon is FREE! -=- roberto@keltia.freenix.fr FreeBSD keltia.freenix.fr 3.0-CURRENT #31: Tue Dec 3 23:52:58 CET 1996 From owner-freebsd-hackers Wed Dec 18 14:57:23 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id OAA04500 for hackers-outgoing; Wed, 18 Dec 1996 14:57:23 -0800 (PST) Received: from wgold.demon.co.uk (wgold.demon.co.uk [158.152.96.124]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id OAA04488 for ; Wed, 18 Dec 1996 14:57:18 -0800 (PST) Received: from [127.0.0.1] by wgold.demon.co.uk (NTMail 3.01.03) id wa000984; Wed, 18 Dec 1996 12:18:38 +0000 Message-ID: <32B7E11E.22@wgold.demon.co.uk> Date: Wed, 18 Dec 1996 12:18:38 +0000 From: James Mansion Organization: Westongold Ltd X-Mailer: Mozilla 3.0Gold (WinNT; I) MIME-Version: 1.0 To: hackers@freebsd.org Subject: mmap pain Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Info: Westongold Ltd: +44 1992 620025 www.westongold.com Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I have a 'well known' shared memory area that is in the file system and mapped using mmap. It is dynamically created if necessary. I'd like to tidy it up, too. I can quite easily detect if a process has opened it by placing locks at hashed offsets in the file and checking to see if there are any locks in place. If not, then it should be safe to delete since I'm the last user. However, locks aren't inherited over a fork, so maybe the memory is still mapped into some child process and might be used. It is just about feasible to require a child to reapply new locks after the fork and for the parent to wait for it to do so, but really I'd like to bury this in a library. Is there any (preferably generic) way to tell whether a file has no (other) open descriptors attached to it and can be unlinked? James From owner-freebsd-hackers Wed Dec 18 15:58:16 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id PAA12299 for hackers-outgoing; Wed, 18 Dec 1996 15:58:16 -0800 (PST) Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id PAA12288 for ; Wed, 18 Dec 1996 15:58:13 -0800 (PST) Received: (from msmith@localhost) by genesis.atrad.adelaide.edu.au (8.8.2/8.7.3) id KAA01883; Thu, 19 Dec 1996 10:27:56 +1030 (CST) From: Michael Smith Message-Id: <199612182357.KAA01883@genesis.atrad.adelaide.edu.au> Subject: Re: mmap pain In-Reply-To: <32B7E11E.22@wgold.demon.co.uk> from James Mansion at "Dec 18, 96 12:18:38 pm" To: james@wgold.demon.co.uk (James Mansion) Date: Thu, 19 Dec 1996 10:27:55 +1030 (CST) Cc: hackers@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-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk James Mansion stands accused of saying: > > Is there any (preferably generic) way to tell whether a file > has no (other) open descriptors attached to it and can be unlinked? Um, if you unlink it and someone else has it open, that's not going to hurt them; it'll disappear from the filesystem namespace (as intended), but will still exist until they close it or exit. It's actually quite common to mmap a file for parent/child communication, unlink it and then fork. > James -- ]] 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-hackers Wed Dec 18 16:24:11 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id QAA17000 for hackers-outgoing; Wed, 18 Dec 1996 16:24:11 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id QAA16917; Wed, 18 Dec 1996 16:23:56 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id RAA10646; Wed, 18 Dec 1996 17:21:42 -0700 From: Terry Lambert Message-Id: <199612190021.RAA10646@phaeton.artisoft.com> Subject: Re: mmap problems? To: hasty@rah.star-gate.com (Amancio Hasty) Date: Wed, 18 Dec 1996 17:21:42 -0700 (MST) Cc: terry@lambert.org, hackers@freebsd.org, multimedia@freebsd.org In-Reply-To: <199612182106.NAA06275@rah.star-gate.com> from "Amancio Hasty" at Dec 18, 96 01:06:11 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-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > I am a little confuse . Why would "tv" work 3 or 5 times then fail to run > because the driver did not mmap properly the pages? Because the VM space was exhausted because the cleanup-on-close never happened like it was supposed to... And/or the VM space has to be contiguously allocated, and the necessary memory could not be allocated after a couple of runs because it was too fragmented. You'll have to look carefully at the driver to see which is happening (if either is the correct reason). 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-hackers Wed Dec 18 17:40:48 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id RAA21848 for hackers-outgoing; Wed, 18 Dec 1996 17:40:48 -0800 (PST) Received: from monk.via.net (monk.via.net [140.174.204.10]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id RAA21843 for ; Wed, 18 Dec 1996 17:40:46 -0800 (PST) Received: (from joe@localhost) by monk.via.net (8.6.11/8.6.12) id RAA19872 for hackers@freebsd.org; Wed, 18 Dec 1996 17:40:14 -0800 Date: Wed, 18 Dec 1996 17:40:14 -0800 From: Joe McGuckin Message-Id: <199612190140.RAA19872@monk.via.net> To: hackers@freebsd.org Subject: NAT with FreeBSD? X-Sun-Charset: US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk How can I do this? Do I need 2 ethernets or can I do it with just one? T1 --------- Token Ring -----------------| Cisco |------------------------------- --------- | |Ethernet | --------- | FreeBSD | --------- I'd like to number everything behind the Cisco with 10.0.0.0 I'd like to FreeBSD box to translate IP's. Possible?? -joe From owner-freebsd-hackers Wed Dec 18 17:57:40 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id RAA22751 for hackers-outgoing; Wed, 18 Dec 1996 17:57:40 -0800 (PST) Received: from dyson.iquest.net (dyson.iquest.net [198.70.144.127]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id RAA22746 for ; Wed, 18 Dec 1996 17:57:37 -0800 (PST) Received: (from root@localhost) by dyson.iquest.net (8.8.2/8.6.9) id UAA03663; Wed, 18 Dec 1996 20:57:25 -0500 (EST) From: "John S. Dyson" Message-Id: <199612190157.UAA03663@dyson.iquest.net> Subject: Re: mmap pain To: james@wgold.demon.co.uk (James Mansion) Date: Wed, 18 Dec 1996 20:57:23 -0500 (EST) Cc: hackers@FreeBSD.ORG In-Reply-To: <32B7E11E.22@wgold.demon.co.uk> from "James Mansion" at Dec 18, 96 12:18:38 pm Reply-To: dyson@FreeBSD.ORG X-Mailer: ELM [version 2.4 PL24 ME8] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > However, locks aren't inherited over a fork, so maybe the memory > is still mapped into some child process and might be used. > > It is just about feasible to require a child to reapply new locks > after the fork and for the parent to wait for it to do so, but > really I'd like to bury this in a library. > > Is there any (preferably generic) way to tell whether a file > has no (other) open descriptors attached to it and can be unlinked? > Anytime a program has a file mapped, it is kind-of equiv to the file being open. If you unlink a file that is mapped or open, you will immediately remove the directory entry, but the file will remain until the last process closes or unmaps the file. You unmap or close a file either by an explicit action or by the program exiting. It is also possible that a new reference can be gained by a process forking even after a file directory entry has been unlinked. John From owner-freebsd-hackers Wed Dec 18 18:12:54 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id SAA23444 for hackers-outgoing; Wed, 18 Dec 1996 18:12:54 -0800 (PST) Received: from itsdsv1.enc.edu (itsdsv1.enc.edu [207.95.42.241]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id SAA23436 for ; Wed, 18 Dec 1996 18:12:51 -0800 (PST) Received: from dingo.its.enc.edu (dingo.its.enc.edu [207.95.222.250]) by itsdsv1.enc.edu (8.7.5/8.7.3) with SMTP id VAA10101 for ; Wed, 18 Dec 1996 21:10:41 -0500 (EST) Date: Wed, 18 Dec 1996 15:08:59 -0500 (EST) From: Charles Owens X-Sender: owensc@dingo.its.enc.edu Reply-To: Charles Owens To: questions list FreeBSD Subject: multi-group file access techniques Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII ReSent-Date: Wed, 18 Dec 1996 21:13:14 -0500 (EST) ReSent-From: Charles Owens ReSent-To: hackers list FreeBSD ReSent-Message-ID: Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Howdy, I'm trying to grapple with the challenge of how to allow multiple groups and users (but not everyone) to have access to a directory hierarchy. We don't have ACL's in FreeBSD, so I'm finding it a bit tricky. Below is an example of what I need to do. If you have any insights, alternate approaches, please let me know! My goal is to set up a flexible way of organizing permissions such that collections of users can share files with security where needed. An integral part of the picture is http access, so the user (or group) 'www' also needs read access (unless I run Apache as root, which I don't think I want to do). [Web access permissions (via .htaccess or access.conf) are a separate issue -- let's just limit the discussion to file system access issues]. First let's define what I mean by a "group hierarchy". Basicly, it's a collection of groups associated with a single entity, such as a department, each with a different privilege level. An example: Group Hierarchy 'Engineering' Group Name Membership eng anyone associated with department eng1 full time staff eng2 managers eng3 administrators In implementing this, member users would belong to all groups within the hierarchy down to the level appropriate for them (so a manager would belong to groups eng, eng1, and eng2). What would this look like in practice? Owner Group Mode /dept/eng root eng drwxrwx--- | +- man_only eng2_member eng2 drwxrwx--- | | | (files) | +- man_readable_c eng2_member eng1 drwxr-x--- | +- man_readable eng2_member eng2 drwxrwxr-x | (files) Here managers (members of eng, eng1 and eng2 groups) can have full access to everything. Staff (belonging to eng and eng1) have RW access to /dept/eng, but just read to /dept/eng/man_readable_c/man_readable. .../man_readable_c is a "control directory," a technique that seems obvious to me now but was new to me when I read of it in "Techniques for Simulating Multiple Group Ownership," by Doug Morris, from the October issue of SysAdmin magazine. This seems reasonably workable, but there's no provision to allow the user or group 'www' to have read access. Adding this access into the above scheme seems possible, but a bit goofy. I've achieved it below simply by making 'www' the owner of all "choke point" directories: Owner Group Mode /dept/eng_c www eng dr-xrwx--- | +- man_only www eng2 dr-xrwx--- | | | (files) | +- man_readable_c www eng1 dr-xr-x--- | +- man_readable eng2_member eng2 drwxrwxr-x | (files) This does work, but has two obvious flaws: 1. Security - the user "www" should _not_ have to own the directories 2. Ease of use - a normal user could not achieve the above configuration with normal file system commands. Certainly, though, a few setuid utilities could be written to make this possible... What other approaches exist? Comments? Critiques? In his article, Doug Morris also speaks of a technique of using hard links of directories to achieve a similar effect. This technique could be used in tandem with the above to add more flexibility, but we all know the GREAT EVIL that hard linked directories are. :-) (Morris's article forces me to ask, though, if hard linked directories are actually okay for other OS's, perhaps non-BSD ones?) Thanks in advance for any and all response, --- ------------------------------------------------------------------------- Charles Owens Email: owensc@enc.edu "I read somewhere to learn is to Information Technology Services remember... and I've learned that Eastern Nazarene College we've all forgot..." - King's X ------------------------------------------------------------------------- From owner-freebsd-hackers Wed Dec 18 18:12:56 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id SAA23459 for hackers-outgoing; Wed, 18 Dec 1996 18:12:56 -0800 (PST) Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id SAA23440 for ; Wed, 18 Dec 1996 18:12:53 -0800 (PST) Received: (from msmith@localhost) by genesis.atrad.adelaide.edu.au (8.8.2/8.7.3) id MAA02473; Thu, 19 Dec 1996 12:42:44 +1030 (CST) From: Michael Smith Message-Id: <199612190212.MAA02473@genesis.atrad.adelaide.edu.au> Subject: Re: NAT with FreeBSD? In-Reply-To: <199612190140.RAA19872@monk.via.net> from Joe McGuckin at "Dec 18, 96 05:40:14 pm" To: joe@via.net (Joe McGuckin) Date: Thu, 19 Dec 1996 12:42:43 +1030 (CST) Cc: hackers@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-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Joe McGuckin stands accused of saying: > > How can I do this? Do I need 2 ethernets or can I do it with just one? > > T1 --------- Token Ring > -----------------| Cisco |------------------------------- > --------- > | > |Ethernet > | > --------- > | FreeBSD | > --------- > > I'd like to number everything behind the Cisco with 10.0.0.0 > > I'd like to FreeBSD box to translate IP's. > > Possible?? Yup. Drop a second address onto the BSD box's ethernet interface (hint: ifconfig alias), and use ipfilter to do your NAT. > -joe -- ]] 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-hackers Wed Dec 18 19:08:09 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id TAA25795 for hackers-outgoing; Wed, 18 Dec 1996 19:08:09 -0800 (PST) Received: from root.com (implode.root.com [198.145.90.17]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id TAA25790 for ; Wed, 18 Dec 1996 19:08:07 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by root.com (8.7.6/8.6.5) with SMTP id TAA13547; Wed, 18 Dec 1996 19:06:33 -0800 (PST) Message-Id: <199612190306.TAA13547@root.com> X-Authentication-Warning: implode.root.com: Host localhost [127.0.0.1] didn't use HELO protocol To: "Jordan K. Hubbard" cc: Tony Overfield , Bruce Evans , julian@whistle.com, hackers@FreeBSD.org Subject: Re: Boot loader hacks was: Re: MAXMEM In-reply-to: Your message of "Wed, 18 Dec 1996 14:06:34 PST." <14493.850946794@time.cdrom.com> From: David Greenman Reply-To: dg@root.com Date: Wed, 18 Dec 1996 19:06:33 -0800 Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk >> After I decided that a three stage boot process would be an >> easy to implement band-aid for the space problem, I decided to >> check the archives to see why nobody has done it yet. Though it > >http://uruk.uruk.org/grub/ > >Doing something with this is something which has been discussed on a >number of occasions, but only discussed. Perhaps its GPL'd status has >a chilling effect on its import, I don't know! :) I think it also >suffers from BDLI (Bruce Doesn't Like It). Erich agreed to release all the parts that he could under BSD-style copyright. The part that he can't is the part that does the ELF loading (if I recall correctly), which we won't be needing right now anyway. So GPL is not something that should effect our use of it. -DG David Greenman Core-team/Principal Architect, The FreeBSD Project From owner-freebsd-hackers Wed Dec 18 19:12:19 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id TAA25996 for hackers-outgoing; Wed, 18 Dec 1996 19:12:19 -0800 (PST) Received: from oneida.internet.com (oneida.internet.com [198.183.190.138]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id TAA25991 for ; Wed, 18 Dec 1996 19:12:17 -0800 (PST) Received: (qmail 27146 invoked by uid 1000); 19 Dec 1996 03:12:16 -0000 Message-ID: <19961219031216.27145.qmail@oneida.internet.com> Subject: unlink by inodes? To: freebsd-hackers@freebsd.org Date: Wed, 18 Dec 1996 22:12:16 -0500 (EST) From: reichert@internet.com (Brian Reichert) X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Howdy, folks - Is there a way of unlinking a file, given it's _inode_ ? I was exploring news expiration alternatives, and was wondering how to avoid the overhead of path -> inode lookup... From owner-freebsd-hackers Wed Dec 18 20:18:57 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id UAA28536 for hackers-outgoing; Wed, 18 Dec 1996 20:18:57 -0800 (PST) Received: from asstdc.scgt.oz.au (root@asstdc.scgt.oz.au [202.14.234.65]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id UAA28530 for ; Wed, 18 Dec 1996 20:18:54 -0800 (PST) Received: (from imb@localhost) by asstdc.scgt.oz.au (8.7.6/BSD4.4) id PAA22239 Thu, 19 Dec 1996 15:18:40 +1100 (EST) From: michael butler Message-Id: <199612190418.PAA22239@asstdc.scgt.oz.au> Subject: Re: unlink by inodes? In-Reply-To: <19961219031216.27145.qmail@oneida.internet.com> from Brian Reichert at "Dec 18, 96 10:12:16 pm" To: reichert@internet.com (Brian Reichert) Date: Thu, 19 Dec 1996 15:18:40 +1100 (EST) Cc: freebsd-hackers@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-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Brian Reichert writes: > Howdy, folks - > Is there a way of unlinking a file, given it's _inode_ ? I was > exploring news expiration alternatives, and was wondering how to > avoid the overhead of path -> inode lookup... Consider that you must find each directory referencing this inode in order to remove the (possibly multiple) entries pointing to it, michael From owner-freebsd-hackers Wed Dec 18 20:42:51 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id UAA29317 for hackers-outgoing; Wed, 18 Dec 1996 20:42:51 -0800 (PST) Received: (from davidn@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id UAA29262; Wed, 18 Dec 1996 20:41:58 -0800 (PST) From: David Nugent Message-Id: <199612190441.UAA29262@freefall.freebsd.org> Subject: Re: 8-bit characters in gecos field To: ache@nagual.ru (=?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7=2C_Andrey_Chernov?=) Date: Thu, 19 Dec 1996 15:41:58 +1100 (EST) Cc: freebsd-hackers@freebsd.org In-Reply-To: from "=?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7=2C_Andrey_Chernov?=" at Dec 18, 96 08:47:57 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > I've been entertaining the idea of having pw(8) allow 8-bit > > characters in the passwd GECOS field. It was suggested earlier > > There is no break as I see, but no sense too, because it is > unclear what character set you use for names. I.e. when finger > sends you some 8bit codes like this: áÎÄŌÅĘ > þÅŌÎÏŨ, what do you do with them? By the same token, what do you do with these characters in a .plan or .project file? Finger, however, is easy to fix, by sending quoted printable with =?char-set rather than 8-bit characrters. The character set indicator should reflect the default language applicable for the user class. Regards, David From owner-freebsd-hackers Wed Dec 18 20:49:16 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id UAA29481 for hackers-outgoing; Wed, 18 Dec 1996 20:49:16 -0800 (PST) Received: (from davidn@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id UAA29473; Wed, 18 Dec 1996 20:49:09 -0800 (PST) From: David Nugent Message-Id: <199612190449.UAA29473@freefall.freebsd.org> Subject: Re: 8-bit characters in gecos field To: terry@lambert.org (Terry Lambert) Date: Thu, 19 Dec 1996 15:49:09 +1100 (EST) Cc: freebsd-hackers@freebsd.org In-Reply-To: <199612182104.OAA10394@phaeton.artisoft.com> from "Terry Lambert" at Dec 18, 96 02:04:22 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > I've been entertaining the idea of having pw(8) allow 8-bit > > characters in the passwd GECOS field. It was suggested earlier > > This assumes that it supports the ESMTP extention "8BITMIME"; the > unextended RFC821 (minimal implementation, no RFC1425 "EHLO") > does not allow 8 bit characters. So there is a provision that if you wish to use 8-bit in gecos, you need a MIME mailer. I don't think that's such a big deal. FreeBSD's default mailer (sendmail) supports it, and MIME support is almost mandatory in most non-English speaking countries anyway if you want to use anything other than English. > You might also see problems with POP3 (but not IMAP4). Perhaps our ports can be patched to do q-p translation if they don't already? Most imap2bis servers support MIME in any case. Regards, David From owner-freebsd-hackers Wed Dec 18 20:59:13 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id UAA29938 for hackers-outgoing; Wed, 18 Dec 1996 20:59:13 -0800 (PST) Received: from eve.speakeasy.org (cgray@eve.speakeasy.org [199.238.226.1]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id UAA29933 for ; Wed, 18 Dec 1996 20:59:12 -0800 (PST) Received: from localhost (cgray@localhost) by eve.speakeasy.org (8.8.4/8.7.3) with SMTP id UAA13547 Date: Wed, 18 Dec 1996 20:58:17 -0800 (PST) From: Cyrus Gray To: David Greenman cc: hackers@freebsd.org Subject: Re: Network Cards In-Reply-To: <199612180928.BAA10909@root.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I should have included the "b" it is a Intel PRO/100b If there are drivers how do I set them up? They are not in LINT so I assume I'll need a newer snapshot? I'm Running 2.1.0-RELEASE Thank you once again for any info On Wed, 18 Dec 1996, David Greenman wrote: > >Thanks for all of the help setting up my HD. > > > >Now my next (and hopefully last question) > >Does FreeBSD Support the Intel Pro/100 100 Mbs PCI Nic? > > FreeBSD supports the Pro/100 model "B". We don't support the old original > Pro/100 (which is a completely different animal). > > -DG > > David Greenman > Core-team/Principal Architect, The FreeBSD Project > From owner-freebsd-hackers Wed Dec 18 21:15:19 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id VAA00685 for hackers-outgoing; Wed, 18 Dec 1996 21:15:19 -0800 (PST) Received: from rover.village.org (rover.village.org [204.144.255.49]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id VAA00680 for ; Wed, 18 Dec 1996 21:15:11 -0800 (PST) Received: from rover.village.org [127.0.0.1] by rover.village.org with esmtp (Exim 0.56 #1) id E0vaap3-0002fv-00; Wed, 18 Dec 1996 22:15:09 -0700 To: freebsd-hackers@freebsd.org Subject: [John Gilmore ] EFF: Bernstein court declares crypto restrictions unconstitutional Date: Wed, 18 Dec 1996 22:15:09 -0700 From: Warner Losh Message-Id: Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk FYI. I don't think this is necessarily the best place to talk about this, but since it comes up from time to time here, I thought I'd pass this along. It would likely not be prudent to rush right out and export crypto code, since this is likely to be appealed, and the court in question isn't the Supreme Court. Warner ------- Forwarded Message Message-Id: <199612190153.RAA08519@toad.com> To: cypherpunks@toad.com Subject: EFF: Bernstein court declares crypto restrictions unconstitutional Date: Wed, 18 Dec 1996 17:53:13 -0800 From: John Gilmore COURT DECLARES CRYPTO RESTRICTIONS UNCONSTITUTIONAL Free Speech Trumps Clinton Wiretap Plan December 18, 1996 Electronic Frontier Foundation Contacts: Shari Steele, Staff Attorney 301/375-8856, ssteele@eff.org John Gilmore, Founding Board Member 415/221-6524, gnu@toad.com Cindy Cohn, McGlashan & Sarrail 415/341-2585, cindy@mcglashan.com San Francisco - On Monday, Judge Marilyn Hall Patel struck down Cold War export restrictions on the privacy technology called cryptography. Her decision knocks out a major part of the Clinton Administration's effort to force companies to build "wiretap-ready" computers, set-top boxes, telephones, and consumer electronics. The decision is a victory for free speech, academic freedom, and the prevention of crime. American scientists and engineers will now be free to collaborate with their peers in the United States and in other countries. This will enable them to build a new generation of tools for protecting the privacy and security of communications. The Clinton Administration has been using the export restrictions to goad companies into building wiretap-ready "key recovery" technology. In a November Executive Order, President Clinton offered limited administrative exemptions from these restrictions to companies which agree to undermine the privacy of their customers. Federal District Judge Patel's ruling knocks both the carrot and the stick out of Clinton's hand, because the restrictions were unconstitutional in the first place. The Cold War law and regulations at issue in the case prevented American researchers and companies from exporting cryptographic software and hardware. Export is normally thought of as the physical carrying of an object across a national border. However, the regulations define "export" to include simple publication in the U.S., as well as discussions with foreigners inside the U.S. They also define "software" to include printed English-language descriptions and diagrams, as well as the traditional machine-readable object code and human-readable source code. The secretive National Security Agency has built up an arcane web of complex and confusing laws, regulations, standards, and secret interpretations for years. These are used to force, persuade, or confuse individuals, companies, and government departments into making it easy for NSA to wiretap and decode all kinds of communications. Their tendrils reach deep into the White House, into numerous Federal agencies, and into the Congressional Intelligence Committees. In recent years this web is unraveling in the face of increasing visibility, vocal public disagreement with the spy agency's goals, commercial and political pressure, and judicial scrutiny. Civil libertarians have long argued that encryption should be widely deployed on the Internet and throughout society to protect privacy, prove the authenticity of transactions, and improve computer security. Industry has argued that the restrictions hobble them in building secure products, both for U.S. and worldwide use, risking America's current dominant position in computer technology. Government officials in the FBI and NSA argue that the technology is too dangerous to permit citizens to use it, because it provides privacy to criminals as well as ordinary citizens. "We're pleased that Judge Patel understands that our national security requires protecting our basic rights of free speech and privacy," said John Gilmore, co-founder of the Electronic Frontier Foundation, which backed the suit. "There's no sense in `burning the Constitution in order to save it'. The secretive bureaucrats who have restricted these rights for decades in the name of national security must come to a larger understanding of how to support and preserve our democracy." Reactions to the decision "This is a positive sign in the crypto wars -- the first rational statement concerning crypto policy to come out of any part of the government," said Jim Bidzos, President of RSA Data Security, one of the companies most affected by crypto policy. "It's nice to see that the executive branch does not get to decide whether we have the right of free speech," said Philip Zimmermann, Chairman of PGP, Inc. "It shows that my own common sense interpretation of the constitution was correct five years ago when I thought it was safe to publish my own software, PGP. If only US Customs had seen it that way." Mr. Zimmermann is a civil libertarian who was investigated by the government under these laws when he wrote and gave away a program for protecting the privacy of e-mail. His "Pretty Good Privacy" program is used by human rights activists worldwide to protect their workers and informants from torture and murder by their own countries' secret police. "Judge Patel's decision furthers our efforts to enable secure electronic commerce," said Asim Abdullah, executive director of CommerceNet. Jerry Berman, Executive Director of the Center for Democracy and Technology, a Washington-based Internet advocacy group, hailed the victory. "The Bernstein ruling illustrates that the Administration continues to embrace an encryption policy that is not only unwise, but also unconstitutional. We congratulate Dan Bernstein, the Electronic Frontier Foundation, and all of the supporters who made this victory for free speech and privacy on the Internet possible." "The ability to publish is required in any vibrant academic discipline," This ruling re-affirming our obvious academic right will help American researchers publish without worrying," said Bruce Schneier, author of the popular textbook _Applied Cryptography_, and a director of the International Association for Cryptologic Research, a professional organization of cryptographers. Kevin McCurley, President of the International Association for Cryptologic Research, said, "Basic research to further the understanding of fundamental notions in information should be welcomed by our society. The expression of such work is closely related to one of the fundamental values of our society, namely freedom of speech." Effect of the decision Judge Patel's decision today only legally applies to Prof. Bernstein. Other people and companies are still technically required to follow the export restrictions when speaking or publishing about cryptography, or when speaking or publishing cryptographic source code. However, the decision sends a strong signal that if the government tried to enforce these rules against other people, the courts are likely to strike them down again. Judge Patel has specifically not decided whether the export controls on object code (the executable form of computer programs which source code is automatically translated into) are constitutional. Existing export controls will continue to apply to runnable software products, such as Netscape's broswer, until another court case challenges that part of the restrictions. Background on the case The plaintiff in the case, Daniel J. Bernstein, Research Assistant Professor at the University of Illinois at Chicago, developed an "encryption algorithm" (a recipe or set of instructions) that he wanted to publish in printed journals as well as on the Internet. Bernstein sued the government, claiming that the government's requirements that he register as an arms dealer and seek government permission before publication was a violation of his First Amendment right of free speech. This is required by the Arms Export Control Act and its implementing regulations, the International Traffic in Arms Regulations. In the first phase of this litigation, the government argued that since Bernstein's ideas were expressed, in part, in computer language (source code), they were not protected by the First Amendment. On April 15, 1996, Judge Patel rejected that argument and held for the first time that computer source code is protected speech for purposes of the First Amendment. Details of Monday's Decision Judge Patel ruled that the Arms Export Control Act is an unconstitutional prior restraint on speech, because it requires Bernstein to submit his ideas about cryptography to the government for review, to register as an arms dealer, and to apply for and obtain from the government a license to publish his ideas. Using the Pentagon Papers case as precedent, she ruled that the government's "interest of national security alone does not justify a prior restraint." Under the Constitution, he is now free to publish his ideas without asking the government's permission first. Judge Patel also held that the government's required licensing procedure fails to provide adequate procedural safeguards. When the Government acts legally to suppress protected speech, it must reduce the chance of illegal censorship by the bureacrats involved. Her decision states, "Because the ITAR licensing scheme fails to provide for a time limit on the licensing decision, for prompt judicial review and for a duty on the part of the ODTC to go to court and defend a denial of a license, the ITAR licensing scheme as applied to Category XIII(b) acts as an unconstitutional prior restraint in violation of the First Amendment." She also ruled that the export controls restrict speech based on the content of the speech, not for any other reason. "Category XIII(b) is directed very specifically at applied scientific research and speech on the topic of encryption." The Government had argued that it restricts the speech because of its function, not its content. The judge also found that the ITAR is vague, because it does not adequately define how information that is available to the public "through fundamental research in science and engineering" is exempt from the export restrictions. "This subsection ... does not give people ... a reasonable opportunity to know what is prohibited." The failure to precisely define what objects and actions are being regulated creates confusion and a chilling effect. Bernstein has been unable to publish his encryption algorithm for over three years. Many other cryptographers and ordinary programmers have also been restrained from publishing because of the vagueness of the ITAR. Brian Behlendorf, a maintainer of the popular public domain "Apache" web server program, stated, "No cryptographic source code was ever distributed by the Apache project. Despite this, the Apache server code was deemed by the NSA to violate the ITAR." Judge Patel also adopted a narrower definition of the term "defense service" in order to save it from unconstitutional vagueness. The immediate effect of this decision is that Bernstein now is free to teach his January 13th cryptography class in his usual way. He can post his class materials on the Internet, and discuss the upcoming class's materials with other professors, without being held in violation of the ITAR. "I'm very pleased," Bernstein said. "Now I won't have to tell my students to burn their notebooks." ABOUT THE ATTORNEYS Lead counsel on the case is Cindy Cohn of the San Mateo law firm of McGlashan & Sarrail, who is offering her services pro bono. Major additional pro bono legal assistance is being provided by Lee Tien of Berkeley; M. Edward Ross of the San Francisco law firm of Steefel, Levitt & Weiss; James Wheaton and Elizabeth Pritzker of the First Amendment Project in Oakland; and Robert Corn-Revere of the Washington, DC, law firm of Hogan & Hartson. ABOUT THE ELECTRONIC FRONTIER FOUNDATION The Electronic Frontier Foundation (EFF) is a nonprofit civil liberties organization working in the public interest to protect privacy, free expression, and access to online resources and information. EFF is a primary sponsor of the Bernstein case. EFF helped to find Bernstein pro bono counsel, is a member of the Bernstein legal team, and helped collect members of the academic community and computer industry to support this case. Full text of the lawsuit and other paperwork filed in the case is available from EFF's online archives at http://www.eff.org/pub/EFF/Policy/Crypto/ITAR_export/Bernstein_case/ The full text of Monday's decision will be posted there as soon as we scan it in. ------- End of Forwarded Message From owner-freebsd-hackers Wed Dec 18 21:19:11 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id VAA00811 for hackers-outgoing; Wed, 18 Dec 1996 21:19:11 -0800 (PST) Received: from sequent.kiae.su (sequent.kiae.su [193.125.152.6]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id VAA00806 for ; Wed, 18 Dec 1996 21:19:08 -0800 (PST) Received: by sequent.kiae.su id AA19145 (5.65.kiae-2 ); Thu, 19 Dec 1996 08:59:19 +0400 Received: by sequent.KIAE.su (UUMAIL/2.0); Thu, 19 Dec 96 08:59:17 +0400 Received: from localhost (nagual.ru [127.0.0.1]) by nagual.ru (8.8.4/8.8.4) with ESMTP id HAA00775; Thu, 19 Dec 1996 07:58:25 +0300 (MSK) Date: Thu, 19 Dec 1996 07:58:24 +0300 (MSK) From: =?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7=2C_Andrey_Chernov?= To: David Nugent Cc: freebsd-hackers@freebsd.org Subject: Re: 8-bit characters in gecos field In-Reply-To: <199612190441.UAA29262@freefall.freebsd.org> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=KOI8-R Content-Transfer-Encoding: 8BIT Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Thu, 19 Dec 1996, David Nugent wrote: > > > I've been entertaining the idea of having pw(8) allow 8-bit > > > characters in the passwd GECOS field. It was suggested earlier > > > > > There is no break as I see, but no sense too, because it is > > unclear what character set you use for names. I.e. when finger > > sends you some 8bit codes like this: áÎÄŌÅĘ > > þÅŌÎÏŨ, what do you do with them? > > By the same token, what do you do with these characters in > a .plan or .project file? Currently they are illegal places for 8bit characters. > Finger, however, is easy to fix, by sending quoted printable > with =?char-set rather than 8-bit characrters. The character > set indicator should reflect the default language applicable > for the user class. In this case you need to parse QP into finger client and yet one passwd field to store default charset. It will be nice to set MM_CHARSET environment variable to this value at login stage. To continue thinking in this direction: nice thing will be default locale name stored into passwd instead. Since locale > charset, we can automatically set both LANG and MM_CHARSET environment variables at login stage. -- Andrey A. Chernov http://www.nagual.ru/~ache/ From owner-freebsd-hackers Wed Dec 18 21:42:35 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id VAA01617 for hackers-outgoing; Wed, 18 Dec 1996 21:42:35 -0800 (PST) Received: from root.com (implode.root.com [198.145.90.17]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id VAA01612 for ; Wed, 18 Dec 1996 21:42:34 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by root.com (8.7.6/8.6.5) with SMTP id VAA14018; Wed, 18 Dec 1996 21:42:06 -0800 (PST) Message-Id: <199612190542.VAA14018@root.com> X-Authentication-Warning: implode.root.com: Host localhost [127.0.0.1] didn't use HELO protocol To: Cyrus Gray cc: hackers@freebsd.org Subject: Re: Network Cards In-reply-to: Your message of "Wed, 18 Dec 1996 20:58:17 PST." From: David Greenman Reply-To: dg@root.com Date: Wed, 18 Dec 1996 21:42:06 -0800 Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >I should have included the "b" it is a Intel PRO/100b >If there are drivers how do I set them up? They are not in >LINT so I assume I'll need a newer snapshot? > >I'm Running >2.1.0-RELEASE You'll need to upgrade to 2.1.6. It's the 'fxp' driver you're after. -DG David Greenman Core-team/Principal Architect, The FreeBSD Project From owner-freebsd-hackers Wed Dec 18 22:00:20 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id WAA02278 for hackers-outgoing; Wed, 18 Dec 1996 22:00:20 -0800 (PST) Received: from austin.polstra.com (austin.polstra.com [206.213.73.10]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id WAA02264 for ; Wed, 18 Dec 1996 22:00:16 -0800 (PST) Received: from austin.polstra.com (jdp@localhost) by austin.polstra.com (8.8.3/8.8.3) with ESMTP id WAA29797 for ; Wed, 18 Dec 1996 22:00:14 -0800 (PST) Message-Id: <199612190600.WAA29797@austin.polstra.com> To: freebsd-hackers@freebsd.org Subject: Re: Correction: src-release and src-tools will REMAIN In-Reply-To: <59735o$j03@austin.polstra.com> References: <199612160453.UAA01018@austin.polstra.com> <59735o$j03@austin.polstra.com> Organization: Polstra & Co., Seattle, WA Date: Wed, 18 Dec 1996 22:00:14 -0800 From: John Polstra Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Sigh, this does not seem to be a good week for me to make announcements about things. I keep getting them wrong and having to post corrections. Here's the latest one: In article <59735o$j03@austin.polstra.com> I wrote: > The "src-release" and "src-tools" collections are going to remain > distinct from "src-etc". I am going to eliminate the overlap that > currently exists between src-etc and the other two, by modifying > what is included in src-etc. That is going to happen on freefall > this coming Saturday, December 21. > > There is going to be a hiccup when this happens. When sup and > CVSup notice the change to src-etc, they will proceed to delete > the affected files on the client machines. Most people won't care > about that. Neither src-release nor src-tools is really a part > of the system. If you want to continue to get them anyway, you'll > have to add those collections to your supfile. > > Here's the nasty part: If you have src-etc AND the other two in > your supfile, the files are going to be deleted (in connection with > src-etc) and then sent to you again (as part of src-release and > src-tools). Sorry, that's just the way things work under the sup > model. It doesn't recognize relationships between files in different > collections. I was suffering from faulty memory, and the above warning about files getting deleted is wrong, at least for CVSup. I tried it here, just to be sure, and the transition went very smoothly. No files got deleted. You don't have to take any special action to keep the files from being re-transmitted to you. In fact, if you want those files to be deleted, you're going to have to delete them manually. My error was in confusing what happens when a set of files is removed from a CVSup collection, as opposed to the physical files being removed from the repository itself. In the former case, CVSup leaves the files alone. They're not in the collection (any more), so CVSup is neither obligated nor permitted to do anything to them. Sorry for yet another false alarm. I'll go away and be quiet 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-hackers Wed Dec 18 22:21:02 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id WAA03191 for hackers-outgoing; Wed, 18 Dec 1996 22:21:02 -0800 (PST) Received: from rah.star-gate.com ([204.188.121.18]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id WAA03174; Wed, 18 Dec 1996 22:20:58 -0800 (PST) Received: from rah.star-gate.com (localhost.star-gate.com [127.0.0.1]) by rah.star-gate.com (8.7.6/8.7.3) with ESMTP id WAA08457; Wed, 18 Dec 1996 22:19:32 -0800 (PST) Message-Id: <199612190619.WAA08457@rah.star-gate.com> X-Mailer: exmh version 1.6.9 8/22/96 To: Terry Lambert cc: hackers@freebsd.org, multimedia@freebsd.org Subject: Re: mmap problems? In-reply-to: Your message of "Wed, 18 Dec 1996 17:21:42 MST." <199612190021.RAA10646@phaeton.artisoft.com> Date: Wed, 18 Dec 1996 22:19:32 -0800 From: Amancio Hasty Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >From The Desk Of Terry Lambert : > > I am a little confuse . Why would "tv" work 3 or 5 times then fail to run > > because the driver did not mmap properly the pages? > > Because the VM space was exhausted because the cleanup-on-close never > happened like it was supposed to... > > And/or the VM space has to be contiguously allocated, and the necessary > memory could not be allocated after a couple of runs because it was > too fragmented. > > You'll have to look carefully at the driver to see which is happening > (if either is the correct reason). > First, the driver used to work and it was recent change in the system not in the driver which is causing the problem. At attach, the meteor executes: define RANGE_BOUNDARY (1<<22) static vm_offset_t get_meteor_mem(int unit, unsigned size) { vm_offset_t addr = 0; addr = vm_page_alloc_contig(size, 0x100000, 0xffffffff, 1<<24); if(addr == 0) addr = vm_page_alloc_contig(size, 0x100000, 0xffffffff, PAGE_SIZE); if(addr == 0) { printf("meteor%d: Unable to allocate %d bytes of memory.\n", unit, size); } return addr; } This call is executed once at boot time. The mmap call in the driver is: meteor_mmap(dev_t dev, int offset, int nprot) { int unit; meteor_reg_t *mtr; unit = UNIT(minor(dev)); if (unit >= NMETEOR) /* at this point could this happen? */ return(-1); mtr = &(meteor[unit]); if(nprot & PROT_EXEC) return -1; if(offset >= mtr->alloc_pages * PAGE_SIZE) return -1; return i386_btop(vtophys(mtr->bigbuf) + offset); } ------ The application mmaps a region from the driver : yuv_data = (uint8 *)mmap((caddr_t)0, frame_size, PROT_READ,0, video, (off_t)0); What this does is mmaps a region of memory which was allocated by the driver at boot time. No further attempts is made by the driver to allocate more memory. So in our scenario , starting /killing the application a few times the system fails to mmap properly all the requested pages. Mind you I am asking for the same number of pages so that pretty much leaves the problem to either mmap or the VM system. Tnks Amancio From owner-freebsd-hackers Wed Dec 18 22:58:47 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id WAA04422 for hackers-outgoing; Wed, 18 Dec 1996 22:58:47 -0800 (PST) Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id WAA04416 for ; Wed, 18 Dec 1996 22:58:41 -0800 (PST) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id HAA19939; Thu, 19 Dec 1996 07:51:08 +0100 Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id HAA17846; Thu, 19 Dec 1996 07:51:08 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.8.4/8.6.9) id HAA26525; Thu, 19 Dec 1996 07:46:43 +0100 (MET) From: J Wunsch Message-Id: <199612190646.HAA26525@uriah.heep.sax.de> Subject: Re: unlink by inodes? To: freebsd-hackers@freebsd.org (FreeBSD hackers) Date: Thu, 19 Dec 1996 07:46:43 +0100 (MET) Cc: reichert@internet.com Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199612190418.PAA22239@asstdc.scgt.oz.au> from michael butler at "Dec 19, 96 03:18:40 pm" 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 X-Mailer: ELM [version 2.4ME+ PL17 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk As michael butler wrote: > > Is there a way of unlinking a file, given it's _inode_ ? I was > > exploring news expiration alternatives, and was wondering how to > > avoid the overhead of path -> inode lookup... > > Consider that you must find each directory referencing this inode in order > to remove the (possibly multiple) entries pointing to it, ...short of running clri(8) and fsck(8). :-)) -- 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 Thu Dec 19 03:02:22 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id DAA15725 for hackers-outgoing; Thu, 19 Dec 1996 03:02:22 -0800 (PST) Received: from Campino.Informatik.RWTH-Aachen.DE (campino.Informatik.RWTH-Aachen.DE [137.226.116.240]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id DAA15720 for ; Thu, 19 Dec 1996 03:02:19 -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 MAA11425 for ; Thu, 19 Dec 1996 12:04:07 +0100 (MET) Received: (from kuku@localhost) by gilberto.physik.rwth-aachen.de (8.8.3/8.6.9) id MAA29230 for freebsd-hackers@freefall.cdrom.com; Thu, 19 Dec 1996 12:17:14 +0100 (MET) Date: Thu, 19 Dec 1996 12:17:14 +0100 (MET) From: Christoph Kukulies Message-Id: <199612191117.MAA29230@gilberto.physik.rwth-aachen.de> To: freebsd-hackers@freefall.FreeBSD.org Subject: tcsh NIS strangeness Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk I updated tcsh since in the old version of tcsh I was running I had problems with NIS/YP. In the old version typing toots> ls ~jolitz Unknown user: jolitz. (starting a csh and then typing the above gave the expected result) Now with the just compiled tcsh-6.07-02 I get the follwomg strangeness: toots> ls ~jolitz toots> Only when I once have done a cd ~jolitz ; ls then subsequent ls ~jolitz deliver the expected ls listing. It appears to happen only on the NIS client machines, not the server. The respective home dirs are NFS mounted BTW. The behaviour looks like tcsh directory caching problem. --Chris Christoph P. U. Kukulies kuku@gil.physik.rwth-aachen.de From owner-freebsd-hackers Thu Dec 19 03:29:20 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id DAA16767 for hackers-outgoing; Thu, 19 Dec 1996 03:29:20 -0800 (PST) Received: from friley216.res.iastate.edu (friley216.res.iastate.edu [129.186.78.216]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id DAA16761 for ; Thu, 19 Dec 1996 03:29:18 -0800 (PST) Received: from friley216.res.iastate.edu (loopback [127.0.0.1]) by friley216.res.iastate.edu (8.8.3/8.7.3) with ESMTP id FAA06565; Thu, 19 Dec 1996 05:26:50 -0600 (CST) Message-Id: <199612191126.FAA06565@friley216.res.iastate.edu> X-Mailer: exmh version 1.6.9 8/22/96 To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) cc: freebsd-hackers@freebsd.org (FreeBSD hackers), reichert@internet.com Subject: Re: unlink by inodes? In-reply-to: Your message of Thu, 19 Dec 1996 07:46:43 +0100. <199612190646.HAA26525@uriah.heep.sax.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 19 Dec 1996 05:26:50 -0600 From: Chris Csanady Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >As michael butler wrote: > >> > Is there a way of unlinking a file, given it's _inode_ ? I was >> > exploring news expiration alternatives, and was wondering how to >> > avoid the overhead of path -> inode lookup... >> >> Consider that you must find each directory referencing this inode in order >> to remove the (possibly multiple) entries pointing to it, > >...short of running clri(8) and fsck(8). :-)) Yeah. :) You really should try to use the fs as it was intended anyway. BTW, does anyone know the status of McKusick's soft updates integration? I think this would make a lot of people happy.. --Chris Csanady > >-- >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 Thu Dec 19 05:37:08 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id FAA22353 for hackers-outgoing; Thu, 19 Dec 1996 05:37:08 -0800 (PST) Received: from fang.cs.sunyit.edu (fang.cs.sunyit.edu [192.52.220.66]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id FAA22348 for ; Thu, 19 Dec 1996 05:37:05 -0800 (PST) Received: (from chuck@localhost) by fang.cs.sunyit.edu (8.7.6/8.7.3) id IAA20462 for hackers@freebsd.org; Thu, 19 Dec 1996 08:36:41 -0500 (EST) Resent-Date: Thu, 19 Dec 1996 08:36:41 -0500 (EST) Resent-From: Charles Green Resent-Message-Id: <199612191336.IAA20462@fang.cs.sunyit.edu> X-Mailer: Mail User's Shell (7.2.5 10/14/92) Resent-To: hackers@freebsd.org Received: from toad.com (toad.com [140.174.2.1]) by fang.cs.sunyit.edu (8.7.6/8.7.3) with ESMTP id VAA17725 for ; Wed, 18 Dec 1996 21:35:41 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by toad.com (8.7.5/8.7.3) with SMTP id RAA08591 for ; Wed, 18 Dec 1996 17:55:31 -0800 (PST) Message-Id: <199612190155.RAA08591@toad.com> X-Authentication-Warning: toad.com: Host localhost [127.0.0.1] didn't use HELO protocol To: cypherpunks-announce@toad.com Subject: EFF: Bernstein court declares crypto restrictions unconstitutional Date: Wed, 18 Dec 1996 17:55:29 -0800 From: John Gilmore Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk COURT DECLARES CRYPTO RESTRICTIONS UNCONSTITUTIONAL Free Speech Trumps Clinton Wiretap Plan December 18, 1996 Electronic Frontier Foundation Contacts: Shari Steele, Staff Attorney 301/375-8856, ssteele@eff.org John Gilmore, Founding Board Member 415/221-6524, gnu@toad.com Cindy Cohn, McGlashan & Sarrail 415/341-2585, cindy@mcglashan.com San Francisco - On Monday, Judge Marilyn Hall Patel struck down Cold War export restrictions on the privacy technology called cryptography. Her decision knocks out a major part of the Clinton Administration's effort to force companies to build "wiretap-ready" computers, set-top boxes, telephones, and consumer electronics. The decision is a victory for free speech, academic freedom, and the prevention of crime. American scientists and engineers will now be free to collaborate with their peers in the United States and in other countries. This will enable them to build a new generation of tools for protecting the privacy and security of communications. The Clinton Administration has been using the export restrictions to goad companies into building wiretap-ready "key recovery" technology. In a November Executive Order, President Clinton offered limited administrative exemptions from these restrictions to companies which agree to undermine the privacy of their customers. Federal District Judge Patel's ruling knocks both the carrot and the stick out of Clinton's hand, because the restrictions were unconstitutional in the first place. The Cold War law and regulations at issue in the case prevented American researchers and companies from exporting cryptographic software and hardware. Export is normally thought of as the physical carrying of an object across a national border. However, the regulations define "export" to include simple publication in the U.S., as well as discussions with foreigners inside the U.S. They also define "software" to include printed English-language descriptions and diagrams, as well as the traditional machine-readable object code and human-readable source code. The secretive National Security Agency has built up an arcane web of complex and confusing laws, regulations, standards, and secret interpretations for years. These are used to force, persuade, or confuse individuals, companies, and government departments into making it easy for NSA to wiretap and decode all kinds of communications. Their tendrils reach deep into the White House, into numerous Federal agencies, and into the Congressional Intelligence Committees. In recent years this web is unraveling in the face of increasing visibility, vocal public disagreement with the spy agency's goals, commercial and political pressure, and judicial scrutiny. Civil libertarians have long argued that encryption should be widely deployed on the Internet and throughout society to protect privacy, prove the authenticity of transactions, and improve computer security. Industry has argued that the restrictions hobble them in building secure products, both for U.S. and worldwide use, risking America's current dominant position in computer technology. Government officials in the FBI and NSA argue that the technology is too dangerous to permit citizens to use it, because it provides privacy to criminals as well as ordinary citizens. "We're pleased that Judge Patel understands that our national security requires protecting our basic rights of free speech and privacy," said John Gilmore, co-founder of the Electronic Frontier Foundation, which backed the suit. "There's no sense in `burning the Constitution in order to save it'. The secretive bureaucrats who have restricted these rights for decades in the name of national security must come to a larger understanding of how to support and preserve our democracy." Reactions to the decision "This is a positive sign in the crypto wars -- the first rational statement concerning crypto policy to come out of any part of the government," said Jim Bidzos, President of RSA Data Security, one of the companies most affected by crypto policy. "It's nice to see that the executive branch does not get to decide whether we have the right of free speech," said Philip Zimmermann, Chairman of PGP, Inc. "It shows that my own common sense interpretation of the constitution was correct five years ago when I thought it was safe to publish my own software, PGP. If only US Customs had seen it that way." Mr. Zimmermann is a civil libertarian who was investigated by the government under these laws when he wrote and gave away a program for protecting the privacy of e-mail. His "Pretty Good Privacy" program is used by human rights activists worldwide to protect their workers and informants from torture and murder by their own countries' secret police. "Judge Patel's decision furthers our efforts to enable secure electronic commerce," said Asim Abdullah, executive director of CommerceNet. Jerry Berman, Executive Director of the Center for Democracy and Technology, a Washington-based Internet advocacy group, hailed the victory. "The Bernstein ruling illustrates that the Administration continues to embrace an encryption policy that is not only unwise, but also unconstitutional. We congratulate Dan Bernstein, the Electronic Frontier Foundation, and all of the supporters who made this victory for free speech and privacy on the Internet possible." "The ability to publish is required in any vibrant academic discipline," This ruling re-affirming our obvious academic right will help American researchers publish without worrying," said Bruce Schneier, author of the popular textbook _Applied Cryptography_, and a director of the International Association for Cryptologic Research, a professional organization of cryptographers. Kevin McCurley, President of the International Association for Cryptologic Research, said, "Basic research to further the understanding of fundamental notions in information should be welcomed by our society. The expression of such work is closely related to one of the fundamental values of our society, namely freedom of speech." Effect of the decision Judge Patel's decision today only legally applies to Prof. Bernstein. Other people and companies are still technically required to follow the export restrictions when speaking or publishing about cryptography, or when speaking or publishing cryptographic source code. However, the decision sends a strong signal that if the government tried to enforce these rules against other people, the courts are likely to strike them down again. Judge Patel has specifically not decided whether the export controls on object code (the executable form of computer programs which source code is automatically translated into) are constitutional. Existing export controls will continue to apply to runnable software products, such as Netscape's broswer, until another court case challenges that part of the restrictions. Background on the case The plaintiff in the case, Daniel J. Bernstein, Research Assistant Professor at the University of Illinois at Chicago, developed an "encryption algorithm" (a recipe or set of instructions) that he wanted to publish in printed journals as well as on the Internet. Bernstein sued the government, claiming that the government's requirements that he register as an arms dealer and seek government permission before publication was a violation of his First Amendment right of free speech. This is required by the Arms Export Control Act and its implementing regulations, the International Traffic in Arms Regulations. In the first phase of this litigation, the government argued that since Bernstein's ideas were expressed, in part, in computer language (source code), they were not protected by the First Amendment. On April 15, 1996, Judge Patel rejected that argument and held for the first time that computer source code is protected speech for purposes of the First Amendment. Details of Monday's Decision Judge Patel ruled that the Arms Export Control Act is an unconstitutional prior restraint on speech, because it requires Bernstein to submit his ideas about cryptography to the government for review, to register as an arms dealer, and to apply for and obtain from the government a license to publish his ideas. Using the Pentagon Papers case as precedent, she ruled that the government's "interest of national security alone does not justify a prior restraint." Under the Constitution, he is now free to publish his ideas without asking the government's permission first. Judge Patel also held that the government's required licensing procedure fails to provide adequate procedural safeguards. When the Government acts legally to suppress protected speech, it must reduce the chance of illegal censorship by the bureacrats involved. Her decision states, "Because the ITAR licensing scheme fails to provide for a time limit on the licensing decision, for prompt judicial review and for a duty on the part of the ODTC to go to court and defend a denial of a license, the ITAR licensing scheme as applied to Category XIII(b) acts as an unconstitutional prior restraint in violation of the First Amendment." She also ruled that the export controls restrict speech based on the content of the speech, not for any other reason. "Category XIII(b) is directed very specifically at applied scientific research and speech on the topic of encryption." The Government had argued that it restricts the speech because of its function, not its content. The judge also found that the ITAR is vague, because it does not adequately define how information that is available to the public "through fundamental research in science and engineering" is exempt from the export restrictions. "This subsection ... does not give people ... a reasonable opportunity to know what is prohibited." The failure to precisely define what objects and actions are being regulated creates confusion and a chilling effect. Bernstein has been unable to publish his encryption algorithm for over three years. Many other cryptographers and ordinary programmers have also been restrained from publishing because of the vagueness of the ITAR. Brian Behlendorf, a maintainer of the popular public domain "Apache" web server program, stated, "No cryptographic source code was ever distributed by the Apache project. Despite this, the Apache server code was deemed by the NSA to violate the ITAR." Judge Patel also adopted a narrower definition of the term "defense service" in order to save it from unconstitutional vagueness. The immediate effect of this decision is that Bernstein now is free to teach his January 13th cryptography class in his usual way. He can post his class materials on the Internet, and discuss the upcoming class's materials with other professors, without being held in violation of the ITAR. "I'm very pleased," Bernstein said. "Now I won't have to tell my students to burn their notebooks." ABOUT THE ATTORNEYS Lead counsel on the case is Cindy Cohn of the San Mateo law firm of McGlashan & Sarrail, who is offering her services pro bono. Major additional pro bono legal assistance is being provided by Lee Tien of Berkeley; M. Edward Ross of the San Francisco law firm of Steefel, Levitt & Weiss; James Wheaton and Elizabeth Pritzker of the First Amendment Project in Oakland; and Robert Corn-Revere of the Washington, DC, law firm of Hogan & Hartson. ABOUT THE ELECTRONIC FRONTIER FOUNDATION The Electronic Frontier Foundation (EFF) is a nonprofit civil liberties organization working in the public interest to protect privacy, free expression, and access to online resources and information. EFF is a primary sponsor of the Bernstein case. EFF helped to find Bernstein pro bono counsel, is a member of the Bernstein legal team, and helped collect members of the academic community and computer industry to support this case. Full text of the lawsuit and other paperwork filed in the case is available from EFF's online archives at http://www.eff.org/pub/EFF/Policy/Crypto/ITAR_export/Bernstein_case/ The full text of Monday's decision will be posted there as soon as we scan it in. From owner-freebsd-hackers Thu Dec 19 05:48:09 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id FAA22686 for hackers-outgoing; Thu, 19 Dec 1996 05:48:09 -0800 (PST) Received: from nic.follonett.no (nic.follonett.no [194.198.43.10]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id FAA22675 for ; Thu, 19 Dec 1996 05:48:05 -0800 (PST) Received: (from uucp@localhost) by nic.follonett.no (8.8.3/8.8.3) with UUCP id OAA04947; Thu, 19 Dec 1996 14:46:54 +0100 (MET) Received: from oo7 (oo7.dimaga.com [192.0.0.65]) by dimaga.com (8.7.5/8.7.2) with SMTP id OAA23617; Thu, 19 Dec 1996 14:30:56 +0100 (MET) Message-Id: <3.0.32.19961219143019.009bd450@dimaga.com> X-Sender: eivind@dimaga.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Thu, 19 Dec 1996 14:30:20 +0100 To: svaar@math.uio.no (Peter Svaar) From: Eivind Eklund Subject: Re: PPP problem Cc: hackers@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk At 07:55 PM 12/18/96 +0100, you wrote: [Original message moved further down] This probably didn't belong in hackers (I didn't tell him to send it here), but the following probably do (relating to the same system): I dropped by and looked the system over, and found that the problem wasn't that he couldn't speak to the modem. Rather, it was that the modem is already connected to his provider which is still running PPP from the previous session (remember, he is on a leased line). Power-cycling the modem make no difference; ping packets sent to his IP address still show up as noise in the PPP term :) (There is a Linux pppd in the other end of it, if that is of importance.) However, both Linux pppd (he used to run Linux) and Trumpet Winsock is able to force the other end to handshake and connect, even if it already think it is connected. I was unable to get the standard PPP from boot.flp to re-initiate that connection. Do anybody know how to force this? A way to do this from the existing floppies are preferred, but if nescessary I can patch PPP and vuild new boot floppies. (The long term solution, but I'd like a short-term solution for now, as I want FreeBSD user penetration in Norway.) Original message with technical expansions >well, I downloaded boot.flp and configured an FTP install. I am constantly >connected to the net (not dialup) thorough a two-thread line (28.8). Constantly connected to his service provider, which run a patched dial-up modems as leased line modem, and run a Linux box with pppd as their connectivity. This box do NOT 'feel' a modem poweroff or recycle. [Rest of message snipped as only containing irrelevant or incorrect information] -- Eivind Eklund gopher://nic.follonett.no:79/0eivind Work: eivind@dimaga.com http://www.dimaga.com/ Home: perhaps@yes.no http://maybes.yes.no/perhaps/ All of the above is a product of either your or my imagination, and not official. From owner-freebsd-hackers Thu Dec 19 05:51:29 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id FAA22834 for hackers-outgoing; Thu, 19 Dec 1996 05:51:29 -0800 (PST) Received: from nic.follonett.no (nic.follonett.no [194.198.43.10]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id FAA22829 for ; Thu, 19 Dec 1996 05:51:26 -0800 (PST) Received: (from uucp@localhost) by nic.follonett.no (8.8.3/8.8.3) with UUCP id OAA05000; Thu, 19 Dec 1996 14:50:20 +0100 (MET) Received: from oo7 (oo7.dimaga.com [192.0.0.65]) by dimaga.com (8.7.5/8.7.2) with SMTP id OAA23734; Thu, 19 Dec 1996 14:51:15 +0100 (MET) Message-Id: <3.0.32.19961219145037.009b7b70@dimaga.com> X-Sender: eivind@dimaga.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Thu, 19 Dec 1996 14:50:41 +0100 To: David Nugent From: Eivind Eklund Subject: Re: 8-bit characters in gecos field Cc: hackers@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by freefall.freebsd.org id FAA22830 Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk At 03:41 PM 12/19/96 +1100, you wrote: >> > I've been entertaining the idea of having pw(8) allow 8-bit >> > characters in the passwd GECOS field. It was suggested earlier > >> >> There is no break as I see, but no sense too, because it is >> unclear what character set you use for names. I.e. when finger >> sends you some 8bit codes like this: áÎÄŌÅĘ >> þÅŌÎÏŨ, what do you do with them? > >By the same token, what do you do with these characters in >a .plan or .project file? > >Finger, however, is easy to fix, by sending quoted printable >with =?char-set rather than 8-bit characrters. The character >set indicator should reflect the default language applicable >for the user class. If somebody is going to implement this, PLEASE do not use quot=65ed=65d unr=65adable as actual encoding; use 8-bit, and if you really feel it nescessary, use quoted unreadable to indicate character set. This will not work, but it will do less damage. :) (No american should come here and tell me to transfer my .plan or .project as 7-bit encoded until he has had his own .plan transferred with MIME-escapes used for all vowels for at least 6 months.) -- Eivind Eklund gopher://nic.follonett.no:79/0eivind Work: eivind@dimaga.com http://www.dimaga.com/ Home: perhaps@yes.no http://maybes.yes.no/perhaps/ All of the above is a product of either your or my imagination, and not official. From owner-freebsd-hackers Thu Dec 19 05:52:11 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id FAA22888 for hackers-outgoing; Thu, 19 Dec 1996 05:52:11 -0800 (PST) Received: from skynet.ctr.columbia.edu (skynet.ctr.columbia.edu [128.59.64.70]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id FAA22883 for ; Thu, 19 Dec 1996 05:52:07 -0800 (PST) Received: (from wpaul@localhost) by skynet.ctr.columbia.edu (8.6.12/8.6.9) id IAA07641; Thu, 19 Dec 1996 08:48:47 -0500 From: Bill Paul Message-Id: <199612191348.IAA07641@skynet.ctr.columbia.edu> Subject: Re: tcsh NIS strangeness To: kuku@gilberto.physik.rwth-aachen.de (Christoph Kukulies) Date: Thu, 19 Dec 1996 08:48:45 -0500 (EST) Cc: hackers@freebsd.org In-Reply-To: <199612191117.MAA29230@gilberto.physik.rwth-aachen.de> from "Christoph Kukulies" at Dec 19, 96 12:17:14 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Of all the gin joints in all the towns in all the world, Christoph Kukulies had to walk into mine and say: > > I updated tcsh since in the old version of tcsh I was running I > had problems with NIS/YP. In the old version typing > > toots> ls ~jolitz > Unknown user: jolitz. > (starting a csh and then typing the above gave the expected result) You either linked tcsh against an old compat version of libc.so or you linked it static against an old version of libc.a. > Now with the just compiled tcsh-6.07-02 I get the follwomg strangeness: > > toots> ls ~jolitz > toots> > > Only when I once have done a cd ~jolitz ; ls then subsequent > ls ~jolitz deliver the expected ls listing. > > It appears to happen only on the NIS client machines, > not the server. The respective home dirs are NFS mounted BTW. > The behaviour looks like tcsh directory caching problem. Is the NIS server also the NFS server? What version of FreeBSD are the clients and server running? If you recompile the old version of tcsh, does that work? If you put user 'jolitz' in the /etc/master.passwd database on one of the clients, does it work then? If you leave user 'jolitz' in NIS and give him a dummy home directory on the clients (instead of mounting it via NFS) does it work then? How is the server configured? Are you using /etc/master.passwd as the source file for the NIS passwd maps (meaning that the NIS server can see user 'jolitz' as a local user) or are you using a seperate file (meaning that the NIS server also has to get his passwd entry from NIS)? -Bill -- ============================================================================= -Bill Paul (212) 854-6020 | System Manager, Master of Unix-Fu Work: wpaul@ctr.columbia.edu | Center for Telecommunications Research Home: wpaul@skynet.ctr.columbia.edu | Columbia University, New York City ============================================================================= "It is not I who am crazy; it is I who am mad!" - Ren Hoek, "Space Madness" ============================================================================= From owner-freebsd-hackers Thu Dec 19 06:05:12 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id GAA23293 for hackers-outgoing; Thu, 19 Dec 1996 06:05:12 -0800 (PST) Received: from vector.jhs.no_domain (slip139-92-4-122.mu.de.ibm.net [139.92.4.122]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id GAA23267 for ; Thu, 19 Dec 1996 06:04:57 -0800 (PST) Received: (from jhs@localhost) by vector.jhs.no_domain (8.7.5/8.6.9) id DAA16690; Thu, 19 Dec 1996 03:04:07 +0100 (MET) Date: Thu, 19 Dec 1996 03:04:07 +0100 (MET) Message-Id: <199612190204.DAA16690@vector.jhs.no_domain> To: hackers@freebsd.org Subject: 1 gig IDE won't install with 1993 < 500M BIOs From: "Julian H. Stacey" Reply-To: "Julian H. Stacey" X-Organization: Vector Systems Ltd. X-Mailer: EXMH 1.6.7, PGP available X-Address: Holz Strasse 27d, 80469 Munich, Germany X-Phone: +49.89.268616 X-Fax: +49.89.2608126 X-ISDN: +49.89.26023276 X-Web: http://www.freebsd.org/~jhs/ Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I've been given a 486 with 1 Gig IDE drive, dragging me away from my `SCSI exclusively & forever stance', & forcing me to learn about foul stuff like my BIOS C. 1993 doesn't support > 530Meg etc, EZ.exe & other DOS/Intel/PC/Gates nasties ... Rel. 2.1.6 won't install on the IDE, so I've cloned current on an 80M SCSI disc, & can now poke at the IDE from a FreeBSD platform, Suggestions as to what to poke, & what to RTFM would be appreciated, I've already cruised the handbook, & FAQ, but found nothing Re. booting > 500M drives on old bioses with < 500M capability . PS please leave me on the CC line, as I posted this to hackers (but I'm only subscribed to current etc) Thanks Julian --- Julian H. Stacey jhs@freebsd.org http://www.freebsd.org/~jhs/ From owner-freebsd-hackers Thu Dec 19 06:26:06 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id GAA23998 for hackers-outgoing; Thu, 19 Dec 1996 06:26:06 -0800 (PST) Received: from Campino.Informatik.RWTH-Aachen.DE (campino.Informatik.RWTH-Aachen.DE [137.226.116.240]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id GAA23993 for ; Thu, 19 Dec 1996 06:26:02 -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 PAA16347; Thu, 19 Dec 1996 15:27:32 +0100 (MET) Received: (from kuku@localhost) by gilberto.physik.rwth-aachen.de (8.8.3/8.6.9) id PAA29931; Thu, 19 Dec 1996 15:40:38 +0100 (MET) From: Christoph Kukulies Message-Id: <199612191440.PAA29931@gilberto.physik.rwth-aachen.de> Subject: Re: tcsh NIS strangeness In-Reply-To: <199612191348.IAA07641@skynet.ctr.columbia.edu> from Bill Paul at "Dec 19, 96 08:48:45 am" To: wpaul@skynet.ctr.columbia.edu (Bill Paul) Date: Thu, 19 Dec 1996 15:40:38 +0100 (MET) Cc: kuku@gilberto.physik.rwth-aachen.de, hackers@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-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > Of all the gin joints in all the towns in all the world, Christoph > Kukulies had to walk into mine and say: > > > > > I updated tcsh since in the old version of tcsh I was running I > > had problems with NIS/YP. In the old version typing > > > > toots> ls ~jolitz > > Unknown user: jolitz. > > (starting a csh and then typing the above gave the expected result) > > You either linked tcsh against an old compat version of libc.so or > you linked it static against an old version of libc.a. I was already suspecting this (that my tcsh was too old). Thta's why I recompiled. > > > Now with the just compiled tcsh-6.07-02 I get the follwomg strangeness: > > > > toots> ls ~jolitz > > toots> > > > > Only when I once have done a cd ~jolitz ; ls then subsequent > > ls ~jolitz deliver the expected ls listing. > > > > It appears to happen only on the NIS client machines, > > not the server. The respective home dirs are NFS mounted BTW. > > The behaviour looks like tcsh directory caching problem. > > Is the NIS server also the NFS server? What version of FreeBSD are > the clients and server running? If you recompile the old version of The server is running some 2.2-current of 23rd Oct. The clients are most 2.2 of same vintage, one client is 3.0 one week old. I believe it wouldn't be possible to me to build an old version of tcsh now (unless I take an old package of tcsh).. > tcsh, does that work? If you put user 'jolitz' in the /etc/master.passwd > database on one of the clients, does it work then? If you leave user Yes, it works for local users, if they have their home dir on a local drive or NFS mounted doesn't count. > 'jolitz' in NIS and give him a dummy home directory on the clients > (instead of mounting it via NFS) does it work then? > > How is the server configured? Are you using /etc/master.passwd as > the source file for the NIS passwd maps (meaning that the NIS server I'm using MASTER_PASSWD=/etc/master.passwd all users are kept there. > can see user 'jolitz' as a local user) or are you using a seperate > file (meaning that the NIS server also has to get his passwd entry > from NIS)? > > -Bill > > -- > ============================================================================= > -Bill Paul (212) 854-6020 | System Manager, Master of Unix-Fu > Work: wpaul@ctr.columbia.edu | Center for Telecommunications Research > Home: wpaul@skynet.ctr.columbia.edu | Columbia University, New York City > ============================================================================= > "It is not I who am crazy; it is I who am mad!" - Ren Hoek, "Space Madness" > ============================================================================= > --Chris Christoph P. U. Kukulies kuku@gil.physik.rwth-aachen.de From owner-freebsd-hackers Thu Dec 19 07:05:33 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id HAA25621 for hackers-outgoing; Thu, 19 Dec 1996 07:05:33 -0800 (PST) Received: from maelstrom.CC.McGill.CA (maelstrom.CC.McGill.CA [132.206.35.2]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id HAA25615 for ; Thu, 19 Dec 1996 07:05:31 -0800 (PST) Received: (from yves@localhost) by maelstrom.CC.McGill.CA (8.7.1/8.6.10) id KAA00925 for freebsd-hackers@freebsd.org; Thu, 19 Dec 1996 10:05:30 -0500 (EST) Message-Id: <199612191505.KAA00925@maelstrom.CC.McGill.CA> Content-Type: text/plain MIME-Version: 1.0 (NeXT Mail 3.3 v118.2) Received: by NeXT.Mailer (1.118.2) From: Yves Lepage Date: Thu, 19 Dec 96 10:05:24 -0500 To: freebsd-hackers@freebsd.org Subject: Please, tell me I am wrong Reply-To: yves@CC.McGill.CA Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi all, After my browsing of the various mail archives, I saw a number of things worth mentionning: - NFS on FreeBSD does not support file locking. Maybe it will in the future but it probably won't inter-operate with Sun's. - There isn't a port of smbfs to FreeBSD yet. Does that mean that there is currently no mechanism in FreeBSD that would do the equivalent of a distributed file system that would also do proper file locking? Please, tell me it isn't so and that I missed the references to that great thing that FreeBSD has :-) Thanks a lot, Yves Lepage From owner-freebsd-hackers Thu Dec 19 08:05:00 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id IAA27917 for hackers-outgoing; Thu, 19 Dec 1996 08:05:00 -0800 (PST) Received: from terra.Sarnoff.COM (terra.sarnoff.com [130.33.11.203]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id IAA27912 for ; Thu, 19 Dec 1996 08:04:57 -0800 (PST) Received: (from rminnich@localhost) by terra.Sarnoff.COM (8.6.12/8.6.12) id LAA18508; Thu, 19 Dec 1996 11:03:44 -0500 Date: Thu, 19 Dec 1996 11:03:44 -0500 (EST) From: "Ron G. Minnich" X-Sender: rminnich@terra To: Yves Lepage cc: freebsd-hackers@freebsd.org Subject: Re: Please, tell me I am wrong In-Reply-To: <199612191505.KAA00925@maelstrom.CC.McGill.CA> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Thu, 19 Dec 1996, Yves Lepage wrote: > Hi all, > - NFS on FreeBSD does not support file locking. Maybe it will in the future > but it probably won't inter-operate with Sun's. you need to distinguish two things. 1) It is true that NFS on freebsd does not have a 'lock' protocol compatible with Sun's. 2) BUT: last time I tried it, sun's lockd etc. didn't work all that well either. and they never have. Not for lack of trying on sun's part, it is a hard problem, esp. in a stateless system such as nfs. ron From owner-freebsd-hackers Thu Dec 19 08:06:39 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id IAA27988 for hackers-outgoing; Thu, 19 Dec 1996 08:06:39 -0800 (PST) Received: from gateman.zeus.leitch.com (gateman.zeus.leitch.com [204.187.61.193]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id IAA27981 for ; Thu, 19 Dec 1996 08:06:34 -0800 (PST) Received: from zeus.leitch.com (0@tap.zeus.leitch.com [204.187.60.10]) by gateman.zeus.leitch.com (8.7.6/8.7.3/1.0) with ESMTP id LAA11291 for ; Thu, 19 Dec 1996 11:07:04 -0500 (EST) Received: from bitter.zeus.leitch.com (bitter.zeus.leitch.com [204.187.61.66]) by zeus.leitch.com (8.7.5/8.7.3/1.0) with ESMTP id LAA27485 for ; Thu, 19 Dec 1996 11:07:04 -0500 (EST) From: Tony Holmes Received: (tholmes@localhost) by bitter.zeus.leitch.com (8.7.5/8.6.9) id LAA00511 for FreeBSD-hackers@freebsd.org; Thu, 19 Dec 1996 11:07:04 -0500 (EST) Message-Id: <199612191607.LAA00511@bitter.zeus.leitch.com> Subject: Question about mbufs To: FreeBSD-hackers@freebsd.org (FreeBSD hackers list) Date: Thu, 19 Dec 1996 11:07:03 -0500 (EST) X-Mailer: ELM [version 2.4ME+ PL14 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hello, I am a novice to the FreeBSD kernel and as my first foray into kernel development, I have the unfortunate task to port a driver from Linux into FreeBSD. The driver was originally a port from DOS (ack!). Anyways, I'm porting a network driver/protocol and have run into a problem with understanding mbufs and their usage. I am unclear as how to convert a standard, linear buffer, into an mbuf chain (and vice-versa) appropriately. Since what I am doing is a gross HACK and has no real advantage to readers of this group, I would appreciate direct contact at tholmes@zeus.leitch.com Thanks in advance for the help. Tony Holmes From owner-freebsd-hackers Thu Dec 19 08:40:18 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id IAA29339 for hackers-outgoing; Thu, 19 Dec 1996 08:40:18 -0800 (PST) Received: from grolsch.cs.ubc.ca (grolsch.cs.ubc.ca [142.103.6.9]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id IAA29334 for ; Thu, 19 Dec 1996 08:40:16 -0800 (PST) Received: (from ean@localhost) by grolsch.cs.ubc.ca (8.8.3/8.6.9) id IAA16843 for hackers@freebsd.org; Thu, 19 Dec 1996 08:40:11 -0800 (PST) X400-Received: by /PRMD=ca/ADMD=telecom.canada/C=ca/; Relayed; Thu, 19 Dec 1996 8:40:09 UTC-0800 Date: Thu, 19 Dec 1996 8:40:09 UTC-0800 X400-Originator: neufeld@cs.ubc.ca X400-Recipients: non-disclosure:; X400-Content-Type: P2-1984 (2) X400-MTS-Identifier: [/PRMD=ca/ADMD=telecom.canada/C=ca/;961219084009] Content-Identifier: 14690 From: Gerald Neufeld To: hackers@freebsd.org (return) Message-ID: <"14690*neufeld@cs.ubc.ca"@MHS> Subject: DHCP? MIME-Version: 1.0 (Generated by Ean X.400 to MIME gateway) Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk The good news is that I now have an ADSL line into my FreeBSD box at home. The bad news is that the ISP supports only DHCP. From what I can tell, FreeBSD does not directly support DHCP (is this correct?). However, there is the WIDE project that supports it (DHCP) on a variety of UNIXs but not very well (it seems) on FreeBSD. I did get it. It does not compile out of the box but I think I got around that. Now it seems to need Berkeley Packet Filters (bpf). My question is: has anyone got DHCP operational (I only need the client part). If you have, please let me know. I would also be interested in knowing if there are any future plans for DHCP and FreeBSD. (Our university has put Ethernet plugs into all the libraries for lap-tops; again only supporting DHCP.) Thanks, Gerald From owner-freebsd-hackers Thu Dec 19 08:48:53 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id IAA29637 for hackers-outgoing; Thu, 19 Dec 1996 08:48:53 -0800 (PST) Received: from zed.ludd.luth.se (zed.ludd.luth.se [130.240.16.33]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id IAA29627; Thu, 19 Dec 1996 08:48:49 -0800 (PST) Received: from father.ludd.luth.se (father.ludd.luth.se [130.240.16.18]) by zed.ludd.luth.se (8.8.3/8.8.3) with ESMTP id RAA26505; Thu, 19 Dec 1996 17:48:47 +0100 From: Tomas Klockar Received: (dateck@localhost) by father.ludd.luth.se (8.6.11/8.6.11) id RAA10566; Thu, 19 Dec 1996 17:48:45 +0100 Message-Id: <199612191648.RAA10566@father.ludd.luth.se> Subject: Re: 1 gig IDE won't install with 1993 < 500M BIOs To: jhs@FreeBSD.org Date: Thu, 19 Dec 1996 17:48:44 +0100 (MET) Cc: hackers@FreeBSD.org In-Reply-To: <199612190204.DAA16690@vector.jhs.no_domain> from "Julian H. Stacey" at "Dec 19, 96 03:04:07 am" X-Mailer: ELM [version 2.4ME+ PL15 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk According to Julian H. Stacey: > I've been given a 486 with 1 Gig IDE drive, dragging me away from my > `SCSI exclusively & forever stance', & forcing me to learn about foul stuff > like my BIOS C. 1993 doesn't support > 530Meg etc, > EZ.exe & other DOS/Intel/PC/Gates nasties ... > > Rel. 2.1.6 won't install on the IDE, so I've cloned current on an 80M SCSI > disc, & can now poke at the IDE from a FreeBSD platform, > > Suggestions as to what to poke, & what to RTFM would be appreciated, > I've already cruised the handbook, & FAQ, but found nothing Re. > booting > 500M drives on old bioses with < 500M capability . > > PS please leave me on the CC line, as I posted this to hackers > (but I'm only subscribed to current etc) > Thanks > I had no problem installing. I had the same problem. On my harddrive there were this stupid program that where overriding bios options. It made it impossible to use the disc to anything but dos. The program where a special bootsector that poked around. When I had reformated the harddrive and set the bios settings as a 512 MB disc I could install freebsd and use the upper half of the disc, as long as the partition starts below the 512 MB limit. I use freebsd bootselector. I have a dos parttion before the freebsdone. If you do it this way it should work. /Tomas -- Tomas Klockar can be found at the following adresses: Kårhusvägen 4:23 | Furuvägen 102 | dateck@ludd.luth.se 977 54 Luleå | 871 52 Härnösand | dateck@solace.mh.se Tel: +46-920-231335 | Tel: +46-611-13393 | d94-tkl@sm.luth.se From owner-freebsd-hackers Thu Dec 19 09:13:11 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id JAA00600 for hackers-outgoing; Thu, 19 Dec 1996 09:13:11 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id JAA00583; Thu, 19 Dec 1996 09:13:07 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id KAA11716; Thu, 19 Dec 1996 10:10:34 -0700 From: Terry Lambert Message-Id: <199612191710.KAA11716@phaeton.artisoft.com> Subject: Re: mmap problems? To: hasty@rah.star-gate.com (Amancio Hasty) Date: Thu, 19 Dec 1996 10:10:33 -0700 (MST) Cc: terry@lambert.org, hackers@freebsd.org, multimedia@freebsd.org In-Reply-To: <199612190619.WAA08457@rah.star-gate.com> from "Amancio Hasty" at Dec 18, 96 10:19: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-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > You'll have to look carefully at the driver to see which is happening > > (if either is the correct reason). [ ... ] Well, I did say "if". Personally, I'd: meteor_mmap(dev_t dev, int offset, int nprot) { int unit; meteor_reg_t *mtr; unit = UNIT(minor(dev)); printf( "meteor_mmap: unit=%d of %d, offset=%d, nprot=%08x\n", unit, NMETEOR, offset, nprot); if (unit >= NMETEOR) /* at this point could this happen? */ { printf( "meteor_mmap: failed: unit exceeded possible units\n"); return(-1); } mtr = &(meteor[unit]); if(nprot & PROT_EXEC) { printf("meteor_mmap: can't map a device PROT_EXEC!\n"); return -1; } printf("meteor_mmap: device pages(%08x)\n", mtr->alloc_pages * page_size); if(offset >= mtr->alloc_pages * PAGE_SIZE) { printf("meteor_mmap: offset (%08x) exceeds device pages\n", offset); return -1; } return i386_btop(vtophys(mtr->bigbuf) + offset); } This leaves a possible failure of (vtophys() + offset) to be valid; you can check that, but it's unlikely (the pages are wired). 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-hackers Thu Dec 19 09:32:50 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id JAA01212 for hackers-outgoing; Thu, 19 Dec 1996 09:32:50 -0800 (PST) Received: from mexico.brainstorm.eu.org (root@mexico.brainstorm.fr [193.56.58.253]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id JAA01201 for ; Thu, 19 Dec 1996 09:32:43 -0800 (PST) Received: from brasil.brainstorm.eu.org (brasil.brainstorm.fr [193.56.58.33]) by mexico.brainstorm.eu.org (8.7.5/8.7.3) with ESMTP id SAA12217 for ; Thu, 19 Dec 1996 18:32:25 +0100 Received: (from uucp@localhost) by brasil.brainstorm.eu.org (8.6.12/8.6.12) with UUCP id SAA01548 for hackers@freebsd.org; Thu, 19 Dec 1996 18:32:10 +0100 Received: (from roberto@localhost) by keltia.freenix.fr (8.8.4/keltia-uucp-2.9) id HAA20843; Thu, 19 Dec 1996 07:26:02 +0100 (CET) Message-ID: Date: Thu, 19 Dec 1996 07:26:01 +0100 From: roberto@keltia.freenix.fr (Ollivier Robert) To: hackers@freebsd.org Subject: Re: Network Cards References: <199612180928.BAA10909@root.com> X-Mailer: Mutt 0.54 Mime-Version: 1.0 X-Operating-System: FreeBSD 3.0-CURRENT ctm#2815 In-Reply-To: ; from Cyrus Gray on Dec 18, 1996 20:58:17 -0800 Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk According to Cyrus Gray: > I should have included the "b" it is a Intel PRO/100b > If there are drivers how do I set them up? They are not in > LINT so I assume I'll need a newer snapshot? > > I'm Running > 2.1.0-RELEASE Try 2.2-ALPHA, I'm not sure whether the fxp driver was brought into 2.1-STABLE or not (I don't think so). -- Ollivier ROBERT -=- The daemon is FREE! -=- roberto@keltia.freenix.fr FreeBSD keltia.freenix.fr 3.0-CURRENT #31: Tue Dec 3 23:52:58 CET 1996 From owner-freebsd-hackers Thu Dec 19 09:33:01 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id JAA01244 for hackers-outgoing; Thu, 19 Dec 1996 09:33:01 -0800 (PST) Received: from mexico.brainstorm.eu.org (root@mexico.brainstorm.fr [193.56.58.253]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id JAA01226 for ; Thu, 19 Dec 1996 09:32:56 -0800 (PST) Received: from brasil.brainstorm.eu.org (brasil.brainstorm.fr [193.56.58.33]) by mexico.brainstorm.eu.org (8.7.5/8.7.3) with ESMTP id SAA12222 for ; Thu, 19 Dec 1996 18:32:31 +0100 Received: (from uucp@localhost) by brasil.brainstorm.eu.org (8.6.12/8.6.12) with UUCP id SAA01549 for freebsd-hackers@freebsd.org; Thu, 19 Dec 1996 18:32:10 +0100 Received: (from roberto@localhost) by keltia.freenix.fr (8.8.4/keltia-uucp-2.9) id HAA20852; Thu, 19 Dec 1996 07:29:00 +0100 (CET) Message-ID: Date: Thu, 19 Dec 1996 07:29:00 +0100 From: roberto@keltia.freenix.fr (Ollivier Robert) To: freebsd-hackers@freebsd.org Subject: Re: 8-bit characters in gecos field References: <199612182104.OAA10394@phaeton.artisoft.com> <199612190449.UAA29473@freefall.freebsd.org> X-Mailer: Mutt 0.54 Mime-Version: 1.0 X-Operating-System: FreeBSD 3.0-CURRENT ctm#2815 In-Reply-To: <199612190449.UAA29473@freefall.freebsd.org>; from David Nugent on Dec 19, 1996 15:49:09 +1100 Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk According to David Nugent: > Perhaps our ports can be patched to do q-p translation if they > don't already? Most imap2bis servers support MIME in any case. Automatic conversion is not always a good idea. The PGP/MIME future standard encodes somethings in QP when signing in order to preserve characters and converting them means that you lose the signature. -- Ollivier ROBERT -=- The daemon is FREE! -=- roberto@keltia.freenix.fr FreeBSD keltia.freenix.fr 3.0-CURRENT #31: Tue Dec 3 23:52:58 CET 1996 From owner-freebsd-hackers Thu Dec 19 10:07:01 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id KAA02561 for hackers-outgoing; Thu, 19 Dec 1996 10:07:01 -0800 (PST) Received: from frig.mt.cs.keio.ac.jp (frig.mt.cs.keio.ac.jp [131.113.32.7]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id KAA02546 for ; Thu, 19 Dec 1996 10:06:55 -0800 (PST) Received: (from hosokawa@localhost) by frig.mt.cs.keio.ac.jp (8.6.12+2.4W/3.4Wbeta3) id DAA25828; Fri, 20 Dec 1996 03:06:40 +0900 Date: Fri, 20 Dec 1996 03:06:40 +0900 Message-Id: <199612191806.DAA25828@frig.mt.cs.keio.ac.jp> To: neufeld@cs.ubc.ca Cc: hackers@freebsd.org, hosokawa@mt.cs.keio.ac.jp Subject: Re: DHCP? In-Reply-To: Your message of Thu, 19 Dec 1996 8:40:09 UTC-0800. <"14690*neufeld@cs.ubc.ca"@MHS> From: hosokawa@mt.cs.keio.ac.jp (HOSOKAWA Tatsumi) X-Mailer: mnews [version 1.18PL3] 1994-08/01(Mon) Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In article <"14690*neufeld@cs.ubc.ca"@MHS> neufeld@cs.ubc.ca writes: >> My question is: has anyone got DHCP operational (I only need the client >> part). If you have, please let me know. I would also be interested in knowing >> if there are any future plans for DHCP and FreeBSD. (Our university has >> put Ethernet plugs into all the libraries for lap-tops; again only supporting >> DHCP.) FYI: I'm using WIDE DHCP (in ports collection) with 2.2-ALPHA (and PAO-961215 package). Please see /etc/pccard_ether and /sys/i386/conf/PAO in PAO package. When I plug an Ethernet card into laptop, WIDE DHCP client successfully gets IP addresses and other network configurations from DHCP server running on Sun workstation. PAO-961215 for 2.2-ALPHA ftp://ryukyu.mt.cs.keio.ac.jp/pub/FreeBSD/PAO/PAO-961215.tar.gz -- HOSOKAWA, Tatsumi E-mail: hosokawa@mt.cs.keio.ac.jp WWW homepage: http://www.mt.cs.keio.ac.jp/person/hosokawa.html Department of Computer Science, Keio University, Yokohama, Japan From owner-freebsd-hackers Thu Dec 19 10:11:33 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id KAA02937 for hackers-outgoing; Thu, 19 Dec 1996 10:11:33 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id KAA02929 for ; Thu, 19 Dec 1996 10:11:31 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id LAA11816; Thu, 19 Dec 1996 11:08:52 -0700 From: Terry Lambert Message-Id: <199612191808.LAA11816@phaeton.artisoft.com> Subject: Re: 8-bit characters in gecos field To: eivind@dimaga.com (Eivind Eklund) Date: Thu, 19 Dec 1996 11:08:52 -0700 (MST) Cc: davidn@freefall.freebsd.org, hackers@freebsd.org In-Reply-To: <3.0.32.19961219145037.009b7b70@dimaga.com> from "Eivind Eklund" at Dec 19, 96 02:50:41 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-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > If somebody is going to implement this, PLEASE do not use quot=3D65ed=3D6= > 5d > unr=3D65adable as actual encoding; use 8-bit, and if you really feel it > nescessary, use quoted unreadable to indicate character set. This will n= > ot > work, but it will do less damage. :) (No american should come here and > tell me to transfer my .plan or .project as 7-bit encoded until he has ha= > d > his own .plan transferred with MIME-escapes used for all vowels for at > least 6 months.) The quoting is for sticking outherwise invalid values into a range restricted data stream. In other words, it's useful for the 'F' in a leading "From" or the '.' in a line starting with a '.' (to avoid invoking a byte stuffing state machine on top of the quoting one that has to be there anyway) inside a message body followin a DATA command in an RFC821 connection. So it's not just GECOS data. The problem with GECOS data is that if I have an ISP account that I use to fan out mail for several users, and I use the address form: To: Fred Smith and To: Wilma Smith And fan out using the long name, I am using the GECOS data. RFC822 specifies: "Each header field can be viewed as a single, logical line of ASCII characters" ... ASCII == 7 bits Therefore the "To:" line GECOS ("long name") data must be 7 bit; 8 bit data may be transfered, but if it is, it must be quoted. 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-hackers Thu Dec 19 10:13:30 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id KAA03064 for hackers-outgoing; Thu, 19 Dec 1996 10:13:30 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id KAA03053 for ; Thu, 19 Dec 1996 10:13:27 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id LAA11829; Thu, 19 Dec 1996 11:10:56 -0700 From: Terry Lambert Message-Id: <199612191810.LAA11829@phaeton.artisoft.com> Subject: Re: Please, tell me I am wrong To: yves@CC.McGill.CA Date: Thu, 19 Dec 1996 11:10:56 -0700 (MST) Cc: freebsd-hackers@freebsd.org In-Reply-To: <199612191505.KAA00925@maelstrom.CC.McGill.CA> from "Yves Lepage" at Dec 19, 96 10:05:24 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-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > After my browsing of the various mail archives, I saw a number of things worth mentionning: > > - NFS on FreeBSD does not support file locking. Maybe it will in the future > but it probably won't inter-operate with Sun's. > > - There isn't a port of smbfs to FreeBSD yet. > > > Does that mean that there is currently no mechanism in FreeBSD that would do > the equivalent of a distributed file system that would also do proper > file locking? > > Please, tell me it isn't so and that I missed the references to that great > thing that FreeBSD has :-) You missed the patches I posted to -current about a year ago the implement the fcntl() interfaces necessary for NFS server locking on a clients behalf, and you missed the fact that there is a working rpc.statd and a stubbed rpc.lockd in the source tree. 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-hackers Thu Dec 19 10:23:53 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id KAA03587 for hackers-outgoing; Thu, 19 Dec 1996 10:23:53 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id KAA03582 for ; Thu, 19 Dec 1996 10:23:49 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id LAA11849; Thu, 19 Dec 1996 11:20:18 -0700 From: Terry Lambert Message-Id: <199612191820.LAA11849@phaeton.artisoft.com> Subject: Re: Please, tell me I am wrong To: rminnich@Sarnoff.COM (Ron G. Minnich) Date: Thu, 19 Dec 1996 11:20:18 -0700 (MST) Cc: yves@CC.McGill.CA, freebsd-hackers@freebsd.org In-Reply-To: from "Ron G. Minnich" at Dec 19, 96 11:03:44 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-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > Hi all, > > - NFS on FreeBSD does not support file locking. Maybe it will in the future > > but it probably won't inter-operate with Sun's. > > you need to distinguish two things. > 1) It is true that > NFS on freebsd does not have a 'lock' protocol compatible with Sun's. > 2) BUT: last time I tried it, sun's lockd etc. didn't work all that well > either. and they never have. Not for lack of trying on sun's part, > it is a hard problem, esp. in a stateless system such as nfs. Bah humbug. 1) The rpc.lockd and rpc.statd currently in the source tree correctly interoperate with Sun's locking implementation. 2) The Sun locking works correctly if you obey order of operation protocols in your client code. If it doesn't work for someone, it's pilot error, not an unclosable hole in the code. 3) The FreeBSD implementation of rpc.lockd (for the NFS server) always returns "success" to the NFS client instead of making local fcntl() calls to assert the locks on the local system on the clients behalf. 4) Patches to do this were submitted, but never integrated. They remain available in the -current list archive for anyone who is interested in integrating them. 5) FreeBSD does not support making client RPC calls to a remote lockd, mostly because there is not a remote lockd to test against, and even if there were, the VOP_ADVLOCK code can not be used in an FS stacking layer to implement NFS client locking until VOP_ADVLOCK is changed, per my suggested patches of June, 1994. This is because NFS client locking requires a local assert/remote veto ordering to ensure that there is not an unrecoverable race condition in lock assertion over the wire. 6) NFS locking is not stateless. 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-hackers Thu Dec 19 10:28:18 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id KAA03827 for hackers-outgoing; Thu, 19 Dec 1996 10:28:18 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id KAA03821 for ; Thu, 19 Dec 1996 10:28:15 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id LAA11873; Thu, 19 Dec 1996 11:26:08 -0700 From: Terry Lambert Message-Id: <199612191826.LAA11873@phaeton.artisoft.com> Subject: Re: 8-bit characters in gecos field To: roberto@keltia.freenix.fr (Ollivier Robert) Date: Thu, 19 Dec 1996 11:26:08 -0700 (MST) Cc: freebsd-hackers@FreeBSD.ORG In-Reply-To: from "Ollivier Robert" at Dec 19, 96 07:29:00 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-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > According to David Nugent: > > Perhaps our ports can be patched to do q-p translation if they > > don't already? Most imap2bis servers support MIME in any case. > > Automatic conversion is not always a good idea. The PGP/MIME future > standard encodes somethings in QP when signing in order to preserve > characters and converting them means that you lose the signature. The signature is encapsulating data. You could make the same argument about byte-stuffing the '.' at the front of lines to make sure a naked '.' not intended as a DATA state terminator was not seen as such. The point of fact is that the quoting is reversed when the data leaves the RFC821 transport encapsulation. Issues of ^">From" and ^" From" conversion of ^"From" are an issue of the local MDA (Mail Delivery Agent), and are only a problem if the MDA (incorrectly) dumps all mail in a single file so that the ^"From" is used (also incorrectly) as a message seperator. Which is to say, the message body should be unaltered after being unquoted following quoting for transport. The same arguments apply to a quoting "fingerd" and an unquoting "finger". 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-hackers Thu Dec 19 11:21:46 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id LAA06026 for hackers-outgoing; Thu, 19 Dec 1996 11:21:46 -0800 (PST) Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id LAA06021 for ; Thu, 19 Dec 1996 11:21:43 -0800 (PST) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id UAA11428 for ; Thu, 19 Dec 1996 20:21:40 +0100 Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id UAA00224 for freebsd-hackers@freebsd.org; Thu, 19 Dec 1996 20:21:38 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.8.4/8.6.9) id UAA28344 for freebsd-hackers@freebsd.org; Thu, 19 Dec 1996 20:17:12 +0100 (MET) From: J Wunsch Message-Id: <199612191917.UAA28344@uriah.heep.sax.de> Subject: Re: unlink by inodes? To: freebsd-hackers@freebsd.org (FreeBSD hackers) Date: Thu, 19 Dec 1996 20:17:12 +0100 (MET) Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199612191126.FAA06565@friley216.res.iastate.edu> from Chris Csanady at "Dec 19, 96 05:26:50 am" 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 X-Mailer: ELM [version 2.4ME+ PL17 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk As Chris Csanady wrote: > Yeah. :) You really should try to use the fs as it was intended anyway. BTW, > does anyone know the status of McKusick's soft updates integration? I think > this would make a lot of people happy.. Do you perchance mean `mount -o async'? -- 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 Thu Dec 19 11:28:53 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id LAA06306 for hackers-outgoing; Thu, 19 Dec 1996 11:28:53 -0800 (PST) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id LAA06301 for ; Thu, 19 Dec 1996 11:28:50 -0800 (PST) Received: from current1.whistle.com (current1.whistle.com [207.76.205.22]) by alpo.whistle.com (8.8.2/8.8.2) with SMTP id LAA24969; Thu, 19 Dec 1996 11:11:21 -0800 (PST) Message-ID: <32B99324.446B9B3D@whistle.com> Date: Thu, 19 Dec 1996 11:10:28 -0800 From: Julian Elischer Organization: Whistle Communications X-Mailer: Mozilla 3.0Gold (X11; I; FreeBSD 2.2-CURRENT i386) MIME-Version: 1.0 To: yves@CC.McGill.CA CC: freebsd-hackers@freebsd.org Subject: Re: Please, tell me I am wrong References: <199612191505.KAA00925@maelstrom.CC.McGill.CA> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Yves Lepage wrote: > > > - There isn't a port of smbfs to FreeBSD yet. samba supports locking if you are EXPORTING a filesystem... > > Does that mean that there is currently no mechanism in FreeBSD that would do > the equivalent of a distributed file system that would also do proper > file locking? not between FreeBSD machines. (though I remember hearing about someone (terry?) having a lockd partly written. > From owner-freebsd-hackers Thu Dec 19 11:32:08 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id LAA06547 for hackers-outgoing; Thu, 19 Dec 1996 11:32:08 -0800 (PST) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id LAA06496 for ; Thu, 19 Dec 1996 11:31:59 -0800 (PST) Received: from current1.whistle.com (current1.whistle.com [207.76.205.22]) by alpo.whistle.com (8.8.2/8.8.2) with SMTP id LAA25060; Thu, 19 Dec 1996 11:15:28 -0800 (PST) Message-ID: <32B9941B.3F54BC7E@whistle.com> Date: Thu, 19 Dec 1996 11:14:35 -0800 From: Julian Elischer Organization: Whistle Communications X-Mailer: Mozilla 3.0Gold (X11; I; FreeBSD 2.2-CURRENT i386) MIME-Version: 1.0 To: Tony Holmes CC: FreeBSD hackers list Subject: Re: Question about mbufs References: <199612191607.LAA00511@bitter.zeus.leitch.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Tony Holmes wrote: > > Hello, > > I am a novice to the FreeBSD kernel and as my first foray into kernel > development, I have the unfortunate task to port a driver from Linux > into FreeBSD. The driver was originally a port from DOS (ack!). > > Anyways, I'm porting a network driver/protocol and have run into a > problem with understanding mbufs and their usage. I am unclear as how > to convert a standard, linear buffer, into an mbuf chain (and vice-versa) > appropriately. > > Since what I am doing is a gross HACK and has no real advantage to readers > of this group, I would appreciate direct contact at tholmes@zeus.leitch.com > > Thanks in advance for the help. > > Tony Holmes you should get the BSD book (see the bibliography on the www page) also look at teh various utility functions in /sys/kern/uipc_mbuf.c and the macro's in /sys/sys/mbuf.h there are functions to load a linear buffer into an mbuf chain and visa versa julian From owner-freebsd-hackers Thu Dec 19 12:01:24 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id MAA08123 for hackers-outgoing; Thu, 19 Dec 1996 12:01:24 -0800 (PST) Received: from plains.nodak.edu (tinguely@plains.NoDak.edu [134.129.111.64]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id MAA08116 for ; Thu, 19 Dec 1996 12:01:21 -0800 (PST) Received: (from tinguely@localhost) by plains.nodak.edu (8.8.3/8.8.3) id OAA07557; Thu, 19 Dec 1996 14:01:15 -0600 (CST) Date: Thu, 19 Dec 1996 14:01:15 -0600 (CST) From: Mark Tinguely Message-Id: <199612192001.OAA07557@plains.nodak.edu> To: hackers@FreeBSD.ORG, neufeld@cs.ubc.ca Subject: Re: DHCP? Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk The Wide DHCP client works for me on FreeBSD 2.1.5 using an ethernet port. If you want the compiled binary file, I can make it availble for ftp. Berekley Packet Filter need to be compiled into your kernel. Add: pseudo-device bpfilter 4 #Berkeley packet filter to your kernel configuration file. --mark. From owner-freebsd-hackers Thu Dec 19 12:22:23 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id MAA08937 for hackers-outgoing; Thu, 19 Dec 1996 12:22:23 -0800 (PST) Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id MAA08915 for ; Thu, 19 Dec 1996 12:22:07 -0800 (PST) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id VAA16853 for ; Thu, 19 Dec 1996 21:21:57 +0100 Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id VAA01144 for freebsd-hackers@freebsd.org; Thu, 19 Dec 1996 21:21:56 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.8.4/8.6.9) id VAA00894 for freebsd-hackers@freebsd.org; Thu, 19 Dec 1996 21:04:35 +0100 (MET) From: J Wunsch Message-Id: <199612192004.VAA00894@uriah.heep.sax.de> Subject: Re: 8-bit characters in gecos field To: freebsd-hackers@freebsd.org (FreeBSD hackers) Date: Thu, 19 Dec 1996 21:04:34 +0100 (MET) Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: from "[?KOI8-R?]" at "Dec 19, 96 07:58:24 am" 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 X-Mailer: ELM [version 2.4ME+ PL17 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk As [?KOI8-R?] wrote: [Charset KOI8-R unsupported, skipping...] :-) Perhaps mutt handles this situation better than elm? ;) Anyway: > > Finger, however, is easy to fix, by sending quoted printable > > with =?char-set rather than 8-bit characrters. The character > > set indicator should reflect the default language applicable > > for the user class. > > In this case you need to parse QP into finger client and > yet one passwd field to store default charset. > It will be nice to set MM_CHARSET environment variable to this > value at login stage. > > To continue thinking in this direction: > nice thing will be default locale name stored into passwd instead. > Since locale > charset, we can automatically set both LANG and MM_CHARSET > environment variables at login stage. Yep, that's basically what David was suggesting (but you've probably been missing). He wrote that he's got a working login class implementation, and that the login charset could be stored there. This way, Andrey Chernov, Satoshi Asami, and Joerg Wunsch could, for example, store their GECOS names in their native charactersets on freefall. People fingering the respective entries with an appropriate finger client, and with an agreeing local charset will then be able to see it in the right language. -- 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 Thu Dec 19 12:23:42 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id MAA09081 for hackers-outgoing; Thu, 19 Dec 1996 12:23:42 -0800 (PST) Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id MAA09026 for ; Thu, 19 Dec 1996 12:23:21 -0800 (PST) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id VAA16970 for ; Thu, 19 Dec 1996 21:23:11 +0100 Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id VAA01156 for freebsd-hackers@freebsd.org; Thu, 19 Dec 1996 21:23:11 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.8.4/8.6.9) id VAA00914 for freebsd-hackers@freebsd.org; Thu, 19 Dec 1996 21:05:41 +0100 (MET) From: J Wunsch Message-Id: <199612192005.VAA00914@uriah.heep.sax.de> Subject: Re: 8-bit characters in gecos field To: freebsd-hackers@freebsd.org (FreeBSD hackers) Date: Thu, 19 Dec 1996 21:05:40 +0100 (MET) Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: from Ollivier Robert at "Dec 19, 96 07:29:00 am" 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 X-Mailer: ELM [version 2.4ME+ PL17 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk As Ollivier Robert wrote: > According to David Nugent: > > Perhaps our ports can be patched to do q-p translation if they > > don't already? Most imap2bis servers support MIME in any case. > > Automatic conversion is not always a good idea. Since mail headers are by definition restricted to 7 bit, it's the best one could do. (Remember, we were only speaking about the GECOS name that appears in a mail header.) -- 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 Thu Dec 19 12:32:28 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id MAA09931 for hackers-outgoing; Thu, 19 Dec 1996 12:32:28 -0800 (PST) Received: from terra.Sarnoff.COM (terra.sarnoff.com [130.33.11.203]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id MAA09918 for ; Thu, 19 Dec 1996 12:32:22 -0800 (PST) Received: (from rminnich@localhost) by terra.Sarnoff.COM (8.6.12/8.6.12) id PAA19745; Thu, 19 Dec 1996 15:30:03 -0500 Date: Thu, 19 Dec 1996 15:30:02 -0500 (EST) From: "Ron G. Minnich" X-Sender: rminnich@terra To: Terry Lambert cc: freebsd-hackers@freebsd.org Subject: rpc.lockd in nfs in freebsd vs. sun nfs locking In-Reply-To: <199612191820.LAA11849@phaeton.artisoft.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Terry points out that: > 1) The rpc.lockd and rpc.statd currently in the source tree > correctly interoperate with Sun's locking implementation. No argument. I'm not sure this really helps that much, because just interoperating with sun's implementation does not really mean you have useful locking, which is what the original question really concerned. > 2) The Sun locking works correctly if you obey order of operation > protocols in your client code. If it doesn't work for someone, > it's pilot error, not an unclosable hole in the code. Hmm, there still seem to be problems as late as solaris 2.5. All I can say is friends of mine are still trying to use the locking stuff and still having problems, and I can't see any obvious things wrong in what they're doing. As late as Solaris 2.4, we were still seeing an occasional 'lock storm', where RPC lock traffic would eat the wire on one particular error condition that would occur when a client rebooted. This was elicited by sendmail locking in /var/spool/mail. We just had a lockup the other day on a 2.5 machine, we're not sure why but the process that was hung was ... sendmail. The guy who rebooted the machine didn't get me a core dump though. > 3) The FreeBSD implementation of rpc.lockd (for the NFS server) > always returns "success" to the NFS client instead of making > local fcntl() calls to assert the locks on the local system on > the clients behalf. Yes, BUT: is it locking or not? If so, that's great. If not, then it's hard to see how this helps an application writer -- and that's the real end goal. > 4) Patches to do this were submitted, but never integrated. They > remain available in the -current list archive for anyone who > is interested in integrating them. So: locking does not work. Anyway seems you know what to do in order to fix it, but it's still not really there, right? It would be nice to see this go in -- people keep asking for it. > 6) NFS locking is not stateless. Not what I said. What I said is, given that NFS is stateless (which you can argue over the merits of), locking gets to be messy, since you have to glue on an inherently stateful set of operations (locking) over a stateless base. Having modified NFS servers to be stateful, and having then used that state to support application-level locking via locks in mmap()-ed files, I can tell you locking is a bit easier with a stateful server. And yes, I know that locks in files are different than locks on files. But I think the experiences are applicable. Anyways, thanks for the note. It sounds like freebsd is close but not quite there ... maybe the changes will make it in next time. ron From owner-freebsd-hackers Thu Dec 19 13:42:33 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id NAA13394 for hackers-outgoing; Thu, 19 Dec 1996 13:42:33 -0800 (PST) Received: from home.winc.com (mgessner@home.winc.com [204.178.182.2]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id NAA13371 for ; Thu, 19 Dec 1996 13:41:34 -0800 (PST) Received: (from mgessner@localhost) by home.winc.com (8.8.4/8.8.4) id QAA00915 for hackers@freebsd.org; Thu, 19 Dec 1996 16:41:23 -0500 Message-Id: <199612192141.QAA00915@home.winc.com> Subject: Plug n Play modem? To: hackers@freebsd.org (FreeBSD Hackers) Date: Thu, 19 Dec 1996 16:41:22 -0500 (EST) From: mgessner@aristar.com Organization: Aristar Software Development, Inc. Reply-To: mgessner@aristar.com 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 X-Loop: FreeBSD.org Precedence: bulk Hi, all, I just bought a Best Data Plug n Play 33.6 modem, which I want to run under 2.1.5-RELEASE. When I boot, it doesn't see the modem, but under DOS/Windoze, it does, b/c there's an Intel PnP driver that loads under config.sys. Can anyone help me with this, or should I take thing back and exchange it for something that isn't PnP? TIA, and Merry Christmas! Matt From owner-freebsd-hackers Thu Dec 19 13:55:39 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id NAA14093 for hackers-outgoing; Thu, 19 Dec 1996 13:55:39 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id NAA14087 for ; Thu, 19 Dec 1996 13:55:37 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id OAA12245; Thu, 19 Dec 1996 14:53:00 -0700 From: Terry Lambert Message-Id: <199612192153.OAA12245@phaeton.artisoft.com> Subject: Re: rpc.lockd in nfs in freebsd vs. sun nfs locking To: rminnich@Sarnoff.COM (Ron G. Minnich) Date: Thu, 19 Dec 1996 14:53:00 -0700 (MST) Cc: terry@lambert.org, freebsd-hackers@freebsd.org In-Reply-To: from "Ron G. Minnich" at Dec 19, 96 03:30:02 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-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > 2) The Sun locking works correctly if you obey order of operation > > protocols in your client code. If it doesn't work for someone, > > it's pilot error, not an unclosable hole in the code. > > Hmm, there still seem to be problems as late as solaris 2.5. All I can say > is friends of mine are still trying to use the locking stuff and still > having problems, and I can't see any obvious things wrong in what they're > doing. Have your friends applied the undocumented debugger-based kernel patch to turn of async responses on NFS writes and slow down their writes by as much as a factor of 3? If not, then they are not obeying the order of operation protocols. Sun followed SVR4 in their NFS server code by defaulting async writes on to get better benchmarks. There is a Sun release note to this effect, but it is hidden in a problem report response (ie: "undocumented"). > As late as Solaris 2.4, we were still seeing an occasional 'lock storm', > where RPC lock traffic would eat the wire on one particular error > condition that would occur when a client rebooted. This was elicited by > sendmail locking in /var/spool/mail. We just had a lockup the other day on > a 2.5 machine, we're not sure why but the process that was hung was ... > sendmail. The guy who rebooted the machine didn't get me a core dump > though. Certainly, when the rpc.statd notes the server death and the client comes back up, all clients will relock everything they had open (that's why NFS locking is stateful). When a client dies, the client doesn't have lock state and therefore can not reestablish locks, so that can't be the cause of your "lock storm" problems. > > 3) The FreeBSD implementation of rpc.lockd (for the NFS server) > > always returns "success" to the NFS client instead of making > > local fcntl() calls to assert the locks on the local system on > > the clients behalf. > > Yes, BUT: is it locking or not? If so, that's great. If not, then > it's hard to see how this helps an application writer -- and that's > the real end goal. No, it's not locking. That was Jordan's class project: to integrate my patches and maintain a flatened lock graph in the rpc.lockd code (ie: he intended to un-stub the code and collapse multipl open file references to a single lockd descriptor). > > 4) Patches to do this were submitted, but never integrated. They > > remain available in the -current list archive for anyone who > > is interested in integrating them. > > So: locking does not work. Works on my box... but then again, so do union FS and Unicode namespaces; doesn't do anyone else a lot of good if they won't take the code. > Anyway seems you know what to do in order to fix it, but it's still not > really there, right? It would be nice to see this go in -- people keep > asking for it. Talk to Jordan. > Anyways, thanks for the note. It sounds like freebsd is close but not > quite there ... maybe the changes will make it in next time. Yes; it is very close. I estimated once that it would be less than 20 hours of actual work. No one is doing it, and no one is letting the supporting patches into the kernel code. Since I don't need the locking myself, I just decided it's a core team problem, and they can resolve it or not... I'm not going to get an ulcer over trying to get my code committed. 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-hackers Thu Dec 19 14:04:24 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id OAA14933 for hackers-outgoing; Thu, 19 Dec 1996 14:04:24 -0800 (PST) Received: from unix.guru.org (kmitch@unix.guru.org [198.82.200.65]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id OAA14927 for ; Thu, 19 Dec 1996 14:04:22 -0800 (PST) Received: (from kmitch@localhost) by unix.guru.org (8.8.2/8.7.3) id RAA03690 for hackers@freebsd.org; Thu, 19 Dec 1996 17:04:20 -0500 (EST) From: Keith Mitchell Message-Id: <199612192204.RAA03690@unix.guru.org> Subject: Proxy-ARP (LAN) question To: hackers@freebsd.org Date: Thu, 19 Dec 1996 17:04:20 -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-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I have a network of PCs connected to the internet through Proxy-ARP. Right now the network consits of systems using FreeBSD and Ultrix. I just tried to add a Digital Unix machine and I get the following error message on the proxy-arp server: Dec 19 16:58:31 unix /kernel: arplookup 198.82.200.132 failed: host is not on local network The way this is setup is every computer has an "outside" address and an "inside" address. The outside address is on the 198.82.200 network and the inside address is on the 10 network. Both Ultrix and Digital Unix have the bug/feature that all packets have the same outgoing address, but the ultrix boxes seem to work fine. Other than the above error which appears everytime an arp lookup for the server is done everything appears to work fine. Users can get in and out fine. Does anyone have ANY idea what is wrong????? Thanks. From owner-freebsd-hackers Thu Dec 19 15:21:27 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id PAA19542 for hackers-outgoing; Thu, 19 Dec 1996 15:21:27 -0800 (PST) Received: from time.cdrom.com (time.cdrom.com [204.216.27.226]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id PAA19532 for ; Thu, 19 Dec 1996 15:21:24 -0800 (PST) Received: from time.cdrom.com (localhost [127.0.0.1]) by time.cdrom.com (8.8.4/8.6.9) with ESMTP id PAA07830; Thu, 19 Dec 1996 15:19:56 -0800 (PST) To: Terry Lambert cc: rminnich@Sarnoff.COM (Ron G. Minnich), freebsd-hackers@freebsd.org Subject: Re: rpc.lockd in nfs in freebsd vs. sun nfs locking In-reply-to: Your message of "Thu, 19 Dec 1996 14:53:00 MST." <199612192153.OAA12245@phaeton.artisoft.com> Date: Thu, 19 Dec 1996 15:19:55 -0800 Message-ID: <7826.851037595@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > No, it's not locking. That was Jordan's class project: to integrate > my patches and maintain a flatened lock graph in the rpc.lockd code > (ie: he intended to un-stub the code and collapse multipl open file > references to a single lockd descriptor). And one of the reasons I dropped that class - I looked at the problem and decided that did *not* want to become Mr. Rpc.lockd. :-) Jordan From owner-freebsd-hackers Thu Dec 19 15:22:16 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id PAA19606 for hackers-outgoing; Thu, 19 Dec 1996 15:22:16 -0800 (PST) Received: from grolsch.cs.ubc.ca (grolsch.cs.ubc.ca [142.103.6.9]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id PAA19596 for ; Thu, 19 Dec 1996 15:22:14 -0800 (PST) Received: (from ean@localhost) by grolsch.cs.ubc.ca (8.8.3/8.6.9) id PAA00907; Thu, 19 Dec 1996 15:21:57 -0800 (PST) X400-Received: by /PRMD=ca/ADMD=telecom.canada/C=ca/; Relayed; Thu, 19 Dec 1996 15:21:50 UTC-0800 Date: Thu, 19 Dec 1996 15:21:50 UTC-0800 X400-Originator: neufeld@cs.ubc.ca X400-Recipients: non-disclosure:; X400-Content-Type: P2-1984 (2) X400-MTS-Identifier: [/PRMD=ca/ADMD=telecom.canada/C=ca/;961219152150] Content-Identifier: 14693 From: Gerald Neufeld To: Mark Tinguely (return) Cc: hackers@FreeBSD.ORG (return) In-Reply-To: <199612192001.OAA07557@plains.nodak.edu> Message-ID: <"14693*neufeld@cs.ubc.ca"@MHS> Subject: Re: DHCP? MIME-Version: 1.0 (Generated by Ean X.400 to MIME gateway) Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >The Wide DHCP client works for me on FreeBSD 2.1.5 using an ethernet >port. If you want the compiled binary file, I can make it availble for >ftp. > >Berekley Packet Filter need to be compiled into your kernel. Add: > > pseudo-device bpfilter 4 #Berkeley packet filter > >to your kernel configuration file. Thanks ... I will give this a try by first upgrading (I am now using 2.0.5) and then trying it out. If I need the binary I will let yoy know. Thanks again, Gerald From owner-freebsd-hackers Thu Dec 19 15:34:27 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id PAA20214 for hackers-outgoing; Thu, 19 Dec 1996 15:34:27 -0800 (PST) Received: from eldorado.net-tel.co.uk ([193.122.171.253]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id PAA20205 for ; Thu, 19 Dec 1996 15:34:22 -0800 (PST) From: Andrew.Gordon@net-tel.co.uk Received: (from root@localhost) by eldorado.net-tel.co.uk (8.6.12/8.6.10) id XAA17679; Thu, 19 Dec 1996 23:28:07 GMT Received: from "/PRMD=NET-TEL/ADMD=GOLD 400/C=GB/" by net-tel.co.uk (Route400-RFCGate); Thu, 19 Dec 96 23:25:44 +0000 X400-Received: by mta "eldorado" in "/PRMD=net-tel/ADMD=gold 400/C=gb/"; Relayed; Thu, 19 Dec 96 23:25:44 +0000 X400-Received: by mta "net-tel cambridge" in "/PRMD=net-tel/ADMD=gold 400/C=gb/"; Relayed; Thu, 19 Dec 96 23:25:42 +0000 X400-Received: by "/PRMD=NET-TEL/ADMD=Gold 400/C=GB/"; Relayed; Thu, 19 Dec 96 23:25:41 +0000 X400-MTS-Identifier: ["/PRMD=NET-TEL/ADMD=Gold 400/C=GB/";hst:21271-961219232541-0D12] X400-Content-Type: P2-1984 (2) X400-Originator: Andrew.Gordon@net-tel.co.uk Original-Encoded-Information-Types: IA5-Text X400-Recipients: non-disclosure:; Date: Thu, 19 Dec 96 23:25:41 +0000 X400-Content-Identifier: Re(2): rpc.lockd Message-Id: <"67ad-961219232530-7084*/G=Andrew/S=Gordon/O=NET-TEL Computer Systems Ltd/PRMD=NET-TEL/ADMD=Gold 400/C=GB/"@MHS> To: list:; Cc: "Ron G. Minnich" , terry@lambert.org, freebsd-hackers@freebsd.org In-Reply-To: <199612192153.OAA12245@phaeton.artisoft.com> Subject: Re(2): rpc.lockd in nfs in freebsd vs. sun nfs locking Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > As late as Solaris 2.4, we were still seeing an occasional 'lock storm', > > where RPC lock traffic would eat the wire on one particular error > > condition that would occur when a client rebooted. This was elicited by > > sendmail locking in /var/spool/mail. We just had a lockup the other day > on > > a 2.5 machine, we're not sure why but the process that was hung was ... > > sendmail. The guy who rebooted the machine didn't get me a core dump > > though. > > Certainly, when the rpc.statd notes the server death and the client > comes back up, all clients will relock everything they had open > (that's why NFS locking is stateful). > > When a client dies, the client doesn't have lock state and therefore > can not reestablish locks, so that can't be the cause of your > "lock storm" problems. However, when the client comes up the client rpc.statd is supposed to notify the server rpc.statd which in turn notifies the server rpc.lockd so that it can release any locks previously held by the server. Of course, this shouldn't cause any further traffic unless the server thought it had some locks on the client too (ie. both machines were exporting FSs to each other). Can you get a trace of the traffic on the wire when this happens? I can't see anything in the protocol that could lead to a lock storm, but it would be useful to understand it (if nothing else, to avoid duplicating Solaris bugs in the FreeBSD implementation!). From owner-freebsd-hackers Thu Dec 19 15:51:51 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id PAA20993 for hackers-outgoing; Thu, 19 Dec 1996 15:51:51 -0800 (PST) Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id PAA20974 for ; Thu, 19 Dec 1996 15:51:41 -0800 (PST) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id AAA04275; Fri, 20 Dec 1996 00:51:26 +0100 Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id AAA04724; Fri, 20 Dec 1996 00:51:26 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.8.4/8.6.9) id AAA01126; Fri, 20 Dec 1996 00:33:50 +0100 (MET) From: J Wunsch Message-Id: <199612192333.AAA01126@uriah.heep.sax.de> Subject: Re: PPP problem To: freebsd-hackers@freebsd.org (FreeBSD hackers) Date: Fri, 20 Dec 1996 00:33:50 +0100 (MET) Cc: svaar@math.uio.no Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <3.0.32.19961219143019.009bd450@dimaga.com> from Eivind Eklund at "Dec 19, 96 02:30:20 pm" 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 X-Mailer: ELM [version 2.4ME+ PL17 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk As Eivind Eklund wrote: > I dropped by and looked the system over, and found that the problem wasn't > that he couldn't speak to the modem. Rather, it was that the modem is > already connected to his provider which is still running PPP from the > previous session (remember, he is on a leased line). Try `disable pred1' and `deny pred1'. -- 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 Thu Dec 19 16:15:54 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id QAA22193 for hackers-outgoing; Thu, 19 Dec 1996 16:15:54 -0800 (PST) Received: from friley216.res.iastate.edu (friley216.res.iastate.edu [129.186.78.216]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id QAA22188 for ; Thu, 19 Dec 1996 16:15:51 -0800 (PST) Received: from friley216.res.iastate.edu (loopback [127.0.0.1]) by friley216.res.iastate.edu (8.8.3/8.7.3) with ESMTP id SAA09604; Thu, 19 Dec 1996 18:14:54 -0600 (CST) Message-Id: <199612200014.SAA09604@friley216.res.iastate.edu> X-Mailer: exmh version 1.6.9 8/22/96 To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) cc: freebsd-hackers@freebsd.org (FreeBSD hackers) Subject: Re: unlink by inodes? In-reply-to: Your message of Thu, 19 Dec 1996 20:17:12 +0100. <199612191917.UAA28344@uriah.heep.sax.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 19 Dec 1996 18:14:53 -0600 From: Chris Csanady Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >As Chris Csanady wrote: > >> Yeah. :) You really should try to use the fs as it was intended anyway. BT W, >> does anyone know the status of McKusick's soft updates integration? I think >> this would make a lot of people happy.. > >Do you perchance mean `mount -o async'? No, I was talking about an implementation of delayed ordered writes as described by Ganger/Patt's paper. I'm pretty sure that I've heard someone mention that McKusick was working on this for the FFS. I could be wrong.. http://www.pdos.lcs.mit.edu/~ganger/papers/CSE-TR-254-95/CSE-TR-254-95.ps.Z --Chris Csanady > >-- >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 Thu Dec 19 18:40:10 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id SAA00457 for hackers-outgoing; Thu, 19 Dec 1996 18:40:10 -0800 (PST) Received: from gateway.spnet.com (gateway.spnet.com [204.156.130.1]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id SAA00443 for ; Thu, 19 Dec 1996 18:40:07 -0800 (PST) Received: from gateway.spnet.com (localhost [127.0.0.1]) by gateway.spnet.com (8.7.5/8.6.9) with ESMTP id SAA02146; Thu, 19 Dec 1996 18:40:05 -0800 (PST) Message-Id: <199612200240.SAA02146@gateway.spnet.com> To: hackers@FreeBSD.ORG cc: elh@gateway.spnet.com Subject: current worm info pointers Date: Thu, 19 Dec 1996 18:40:05 -0800 From: Ed Hudson Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk howdy. thanks much to mr. joerg wunsch, and the entire freebsd team, for continuing to make my favorite operating system better and better (i've written my first cd!) now i'm looking for pointers on finding information on current worm developement and applications (particularly audio read/write), or any other info than the handbook and worm.c worm kernel intallation question: to get my philips cdd2000 to be recognized as a worm whilst a "device cd0" is also present in the config file required that i reverse the cd/worm entries in scsiconf.c (this was done within a "make world system" of a top-of-cvsup build from 12/17/96 or so). is there a better way? thanks again for an excellent os, -elh From owner-freebsd-hackers Thu Dec 19 19:17:59 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id TAA02067 for hackers-outgoing; Thu, 19 Dec 1996 19:17:59 -0800 (PST) Received: from root.com (implode.root.com [198.145.90.17]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id TAA02062 for ; Thu, 19 Dec 1996 19:17:56 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by root.com (8.7.6/8.6.5) with SMTP id TAA16893; Thu, 19 Dec 1996 19:17:17 -0800 (PST) Message-Id: <199612200317.TAA16893@root.com> X-Authentication-Warning: implode.root.com: Host localhost [127.0.0.1] didn't use HELO protocol To: roberto@keltia.freenix.fr (Ollivier Robert) cc: hackers@freebsd.org Subject: Re: Network Cards In-reply-to: Your message of "Thu, 19 Dec 1996 07:26:01 +0100." From: David Greenman Reply-To: dg@root.com Date: Thu, 19 Dec 1996 19:17:17 -0800 Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >According to Cyrus Gray: >> I should have included the "b" it is a Intel PRO/100b >> If there are drivers how do I set them up? They are not in >> LINT so I assume I'll need a newer snapshot? >> >> I'm Running >> 2.1.0-RELEASE > >Try 2.2-ALPHA, I'm not sure whether the fxp driver was brought into >2.1-STABLE or not (I don't think so). It's in 2.1.5 and 2.1.6. -DG David Greenman Core-team/Principal Architect, The FreeBSD Project From owner-freebsd-hackers Thu Dec 19 22:49:37 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id WAA07823 for hackers-outgoing; Thu, 19 Dec 1996 22:49:37 -0800 (PST) Received: from whistle.com (s205m131.whistle.com [207.76.205.131]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id WAA07808 for ; Thu, 19 Dec 1996 22:49:34 -0800 (PST) Received: (from smap@localhost) by whistle.com (8.7.5/8.6.12) id WAA12084; Thu, 19 Dec 1996 22:48:29 -0800 (PST) Received: from bubba.whistle.com(207.76.205.7) by whistle.com via smap (V1.3) id sma012082; Thu Dec 19 22:47:59 1996 Received: (from archie@localhost) by bubba.whistle.com (8.7.5/8.6.12) id WAA24016; Thu, 19 Dec 1996 22:47:59 -0800 (PST) From: Archie Cobbs Message-Id: <199612200647.WAA24016@bubba.whistle.com> Subject: Re: DHCP? In-Reply-To: <199612192001.OAA07557@plains.nodak.edu> from Mark Tinguely at "Dec 19, 96 02:01:15 pm" To: tinguely@plains.nodak.edu (Mark Tinguely) Date: Thu, 19 Dec 1996 22:47:58 -0800 (PST) Cc: hackers@freebsd.org, neufeld@cs.ubc.ca 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-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > The Wide DHCP client works for me on FreeBSD 2.1.5 using an ethernet > port. If you want the compiled binary file, I can make it availble for > ftp. Also, ISC's dhcp server is available at ftp://ftp.fugue.com/pub ... This one is pretty good IMHO. -Archie ___________________________________________________________________________ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com From owner-freebsd-hackers Thu Dec 19 23:03:21 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id XAA08286 for hackers-outgoing; Thu, 19 Dec 1996 23:03:21 -0800 (PST) Received: from hemi.com (hemi.com [204.132.158.10]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id XAA08281 for ; Thu, 19 Dec 1996 23:03:19 -0800 (PST) Received: (from mbarkah@localhost) by hemi.com (8.8.4/8.7.3) id AAA01130 for freebsd-hackers@freebsd.org; Fri, 20 Dec 1996 00:03:18 -0700 (MST) From: Ade Barkah Message-Id: <199612200703.AAA01130@hemi.com> Subject: Stupid CVS question... To: freebsd-hackers@freebsd.org Date: Fri, 20 Dec 1996 00:03:17 -0700 (MST) X-Mailer: ELM [version 2.4ME+ PL22 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Sorry for the stupid question... what happened to the cvsinit script ? I can't find it in post 2.1.x machines. What's the correct way to initialize a new repository now ? Thanks, -Ade ------------------------------------------------------------------- Inet: mbarkah@hemi.com - HEMISPHERE ONLINE - ------------------------------------------------------------------- From owner-freebsd-hackers Thu Dec 19 23:32:42 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id XAA09167 for hackers-outgoing; Thu, 19 Dec 1996 23:32:42 -0800 (PST) Received: from rah.star-gate.com ([204.188.121.18]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id XAA09150; Thu, 19 Dec 1996 23:32:39 -0800 (PST) Received: from rah.star-gate.com (localhost.star-gate.com [127.0.0.1]) by rah.star-gate.com (8.7.6/8.7.3) with ESMTP id XAA05257; Thu, 19 Dec 1996 23:31:06 -0800 (PST) Message-Id: <199612200731.XAA05257@rah.star-gate.com> X-Mailer: exmh version 1.6.9 8/22/96 To: Terry Lambert cc: hackers@freebsd.org, multimedia@freebsd.org Subject: Re: mmap problems? In-reply-to: Your message of "Thu, 19 Dec 1996 10:10:33 MST." <199612191710.KAA11716@phaeton.artisoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 19 Dec 1996 23:31:06 -0800 From: Amancio Hasty Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi, Well, I noticed that "tv" manages to map successfully all the required memory. The mmap debugging output looks the same for every run including including the run in which tv fails to run due to not all the pages being mapped in. Regards, Amancio >From The Desk Of Terry Lambert : > > > You'll have to look carefully at the driver to see which is happening > > > (if either is the correct reason). > > [ ... ] > > Well, I did say "if". > > Personally, I'd: > > meteor_mmap(dev_t dev, int offset, int nprot) > { > > int unit; > meteor_reg_t *mtr; > > unit = UNIT(minor(dev)); > printf( "meteor_mmap: unit=%d of %d, offset=%d, nprot=%08x\n", > unit, NMETEOR, offset, nprot); > if (unit >= NMETEOR) /* at this point could this happen? * / > { > printf( "meteor_mmap: failed: unit exceeded possible units\n"); > return(-1); > } > > mtr = &(meteor[unit]); > > > if(nprot & PROT_EXEC) > { > printf("meteor_mmap: can't map a device PROT_EXEC!\n"); > return -1; > } > > printf("meteor_mmap: device pages(%08x)\n", mtr->alloc_pages * page_size); > if(offset >= mtr->alloc_pages * PAGE_SIZE) > { > printf("meteor_mmap: offset (%08x) exceeds device pages\n", offset); > return -1; > } > > return i386_btop(vtophys(mtr->bigbuf) + offset); > } > > This leaves a possible failure of (vtophys() + offset) to be valid; > you can check that, but it's unlikely (the pages are wired). > > > 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-hackers Fri Dec 20 00:19:35 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id AAA10862 for hackers-outgoing; Fri, 20 Dec 1996 00:19:35 -0800 (PST) Received: from rah.star-gate.com ([204.188.121.18]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id AAA10755; Fri, 20 Dec 1996 00:18:11 -0800 (PST) Received: from rah.star-gate.com (localhost.star-gate.com [127.0.0.1]) by rah.star-gate.com (8.7.6/8.7.3) with ESMTP id AAA05455; Fri, 20 Dec 1996 00:16:39 -0800 (PST) Message-Id: <199612200816.AAA05455@rah.star-gate.com> X-Mailer: exmh version 1.6.9 8/22/96 To: Terry Lambert cc: hackers@freebsd.org, multimedia@freebsd.org Subject: Re: mmap problems? In-reply-to: Your message of "Thu, 19 Dec 1996 10:10:33 MST." <199612191710.KAA11716@phaeton.artisoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 20 Dec 1996 00:16:39 -0800 From: Amancio Hasty Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk More info, After the mmap call from tv to the meteor driver , the system upon a page fault calls the meteor's mmap routine or rather the first time that I access the mmapped region. When tv fails to run, the call to mmap is successfull however the system only calls back the meteor's mmap routine once for the first page. Does this make sense to anyone out there ? Tnks, Amancio >From The Desk Of Terry Lambert : > > > You'll have to look carefully at the driver to see which is happening > > > (if either is the correct reason). > > [ ... ] > > Well, I did say "if". > > Personally, I'd: > > meteor_mmap(dev_t dev, int offset, int nprot) > { > > int unit; > meteor_reg_t *mtr; > > unit = UNIT(minor(dev)); > printf( "meteor_mmap: unit=%d of %d, offset=%d, nprot=%08x\n", > unit, NMETEOR, offset, nprot); > if (unit >= NMETEOR) /* at this point could this happen? * / > { > printf( "meteor_mmap: failed: unit exceeded possible units\n"); > return(-1); > } > > mtr = &(meteor[unit]); > > > if(nprot & PROT_EXEC) > { > printf("meteor_mmap: can't map a device PROT_EXEC!\n"); > return -1; > } > > printf("meteor_mmap: device pages(%08x)\n", mtr->alloc_pages * page_size); > if(offset >= mtr->alloc_pages * PAGE_SIZE) > { > printf("meteor_mmap: offset (%08x) exceeds device pages\n", offset); > return -1; > } > > return i386_btop(vtophys(mtr->bigbuf) + offset); > } > > This leaves a possible failure of (vtophys() + offset) to be valid; > you can check that, but it's unlikely (the pages are wired). > > > 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-hackers Fri Dec 20 00:24:29 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id AAA11191 for hackers-outgoing; Fri, 20 Dec 1996 00:24:29 -0800 (PST) Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id AAA11159 for ; Fri, 20 Dec 1996 00:24:09 -0800 (PST) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id JAA17362; Fri, 20 Dec 1996 09:21:15 +0100 Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id JAA10088; Fri, 20 Dec 1996 09:21:14 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.8.4/8.6.9) id JAA03508; Fri, 20 Dec 1996 09:00:11 +0100 (MET) From: J Wunsch Message-Id: <199612200800.JAA03508@uriah.heep.sax.de> Subject: Re: current worm info pointers To: freebsd-hackers@freebsd.org (FreeBSD hackers) Date: Fri, 20 Dec 1996 09:00:11 +0100 (MET) Cc: elh@gateway.spnet.com Reply-To: scsi@freebsd.org In-Reply-To: <199612200240.SAA02146@gateway.spnet.com> from Ed Hudson at "Dec 19, 96 06:40:05 pm" 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 X-Mailer: ELM [version 2.4ME+ PL17 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk (Followups to freebsd-scsi@freebsd.org, please) As Ed Hudson wrote: > now i'm looking for pointers on finding information on current worm > developement and applications (particularly audio read/write), > or any other info than the handbook and worm.c Audio write should already be possible. Wrt. audio read, contact multimedia@freebsd.org. I know that there's at least Charles Henrich's `cdd' suite, and Charles will certainly also point out to you the various brokenesses of the various drives wrt. reading audio data. > worm kernel intallation question: > > to get my philips cdd2000 to be recognized as a worm > whilst a "device cd0" is also present in the config file required > that i reverse the cd/worm entries in scsiconf.c Interesting. That's basically also what PR 2225 says. I wonder why scsiconf.c is now broken... Ahyep! I know why this happens! And yes, changing the two sets of records _is_ the right action. Previously, there was no `catchall' entry for CD devices. This caused some (broken) CD drives to respond on all LUNs where they should only respond on a single LUN, that's why we've now got the catchall entry. Of course, since the list is walked down front to back, this catchall entry now also catches the HP and Philips CD-R drives (since they claim to be of type `Readonly' aka. CDROM). Perhaps it's best if we put all the catchall records to the end of the quirks list? > (this was done within a "make world system" of a top-of-cvsup > build from 12/17/96 or so). > is there a better way? Ouch! Yep, there's no need to revamp everything. It should have been as simple as going into your kernel's compile directory, and type `make' there. Since your sys/scsi/scsiconf.c has been touched, make should notice this fact, and recompile the required portions (not much more than scsiconf.c itself in your case). -- 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 Fri Dec 20 01:14:48 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id BAA12954 for hackers-outgoing; Fri, 20 Dec 1996 01:14:48 -0800 (PST) Received: from serv1.zsb.th-darmstadt.de (server.zsb.th-darmstadt.de [130.83.63.190]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id BAA12937; Fri, 20 Dec 1996 01:14:22 -0800 (PST) Received: from localhost (petzi@localhost) by serv1.zsb.th-darmstadt.de (8.8.2/8.8.2) with SMTP id KAA14349; Fri, 20 Dec 1996 10:12:53 +0100 (MET) Date: Fri, 20 Dec 1996 10:12:51 +0100 (MET) From: Michael Beckmann X-Sender: petzi@serv1.zsb.th-darmstadt.de Reply-To: Michael Beckmann To: isp@freebsd.org, hackers@freebsd.org Subject: innd can't remalloc Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hello, my innd dies almost every day, and in the log I see messages like: Dec 20 08:52:37 news innd: SERVER cant remalloc 2097408 bytes Cannot allocate memory This is always the last message from innd, until I restart rc.news . I am running 2.1.5-RELEASE on this machine, and the problem is the same with inn 1.4 and 1.5.1. It seems to me that the crash occurs when the innd process grows to around 128 MB. I assume I am running into some kernel limitation, something like: "no process may have more than 128 MB RAM resident", but I cannot see any setting for that. Could anyone help me out ? I have already tried increasing some limits with ulimit statements at the beginning of rc.news, but this problem didn't go away. Cheers, Michael From owner-freebsd-hackers Fri Dec 20 05:10:20 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id FAA19562 for hackers-outgoing; Fri, 20 Dec 1996 05:10:20 -0800 (PST) Received: from news.IAEhv.nl (root@news.IAEhv.nl [194.151.64.4]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id FAA19555 for ; Fri, 20 Dec 1996 05:10:11 -0800 (PST) Received: from truk.brandinnovators.com (uucp@localhost) by news.IAEhv.nl (8.6.13/1.63) with IAEhv.nl; pid 9704 on Fri, 20 Dec 1996 13:43:19 +0100; id NAA09704 efrom: hans@truk.brandinnovators.com; eto: freebsd-hackers@freebsd.org Received: by truk.brandinnovators.com (8.7.5/BI96070101) for id NAA00973; Fri, 20 Dec 1996 13:38:50 GMT Message-Id: <199612201338.NAA00973@truk.brandinnovators.com> From: hans@brandinnovators.com (Hans Zuidam) Subject: FIONREAD on tunnel device? To: freebsd-hackers@freebsd.org Date: Fri, 20 Dec 1996 13:38:50 +0000 () X-Mailer: ELM [version 2.4ME+ PL22 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi, While playing with a proprietary TCP/IP stack connected to FreeBSD-2.1.5R I think I stumbled into a bug. When I do: ioctl(fd, FIONREAD, &len); read(fs, buf, len); buf ends up with less data than when I do: len = read(fs, buf, MAXINT); /* or some other large number... */ The problem (as far as I can see) is that (in if_tun.c) FIONREAD returns: tp->tun_if.if_snd.ifq_head->m_len while it should probably be: tp->tun_if.if_snd.ifq_head->m_pkthdr.len Regards, Hans -- H. Zuidam E-Mail: hans@brandinnovators.com Brand Innovators B.V. P-Mail: P.O. Box 1377 de Pinckart 54 5602 BJ Eindhoven, The Netherlands 5674 CC Nuenen Tel. +31 40 2631134, Fax. +31 40 2831138 From owner-freebsd-hackers Fri Dec 20 07:29:48 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id HAA23332 for hackers-outgoing; Fri, 20 Dec 1996 07:29:48 -0800 (PST) Received: from rocky.mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id HAA23327 for ; Fri, 20 Dec 1996 07:29:46 -0800 (PST) Received: (from nate@localhost) by rocky.mt.sri.com (8.7.5/8.7.3) id IAA23427; Fri, 20 Dec 1996 08:29:40 -0700 (MST) Date: Fri, 20 Dec 1996 08:29:40 -0700 (MST) Message-Id: <199612201529.IAA23427@rocky.mt.sri.com> From: Nate Williams To: Ade Barkah Cc: freebsd-hackers@freebsd.org Subject: Re: Stupid CVS question... In-Reply-To: <199612200703.AAA01130@hemi.com> References: <199612200703.AAA01130@hemi.com> Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > Sorry for the stupid question... what happened to the cvsinit > script ? I can't find it in post 2.1.x machines. What's the > correct way to initialize a new repository now ? $ cvs init 'init' is now a builtin command of cvs. Nate From owner-freebsd-hackers Fri Dec 20 07:48:08 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id HAA24165 for hackers-outgoing; Fri, 20 Dec 1996 07:48:08 -0800 (PST) Received: from hemi.com (hemi.com [204.132.158.10]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id HAA24157 for ; Fri, 20 Dec 1996 07:48:05 -0800 (PST) Received: (from mbarkah@localhost) by hemi.com (8.8.4/8.7.3) id IAA14308; Fri, 20 Dec 1996 08:47:54 -0700 (MST) From: Ade Barkah Message-Id: <199612201547.IAA14308@hemi.com> Subject: Re: Stupid CVS question... To: nate@mt.sri.com (Nate Williams) Date: Fri, 20 Dec 1996 08:47:53 -0700 (MST) Cc: freebsd-hackers@freebsd.org In-Reply-To: <199612201529.IAA23427@rocky.mt.sri.com> from Nate Williams at "Dec 20, 96 08:29:40 am" X-Mailer: ELM [version 2.4ME+ PL22 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > Sorry for the stupid question... what happened to the cvsinit > > script ? I can't find it in post 2.1.x machines. What's the > > correct way to initialize a new repository now ? > > $ cvs init > > 'init' is now a builtin command of cvs. Thanks Nate! There doesn't appear to be a description of 'init' in the man pages, so I missed it. =-( Regards, -Ade ------------------------------------------------------------------- Inet: mbarkah@hemi.com - HEMISPHERE ONLINE - ------------------------------------------------------------------- From owner-freebsd-hackers Fri Dec 20 08:36:42 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id IAA26311 for hackers-outgoing; Fri, 20 Dec 1996 08:36:42 -0800 (PST) Received: from border.com (borderware.com [199.71.190.98]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id IAA26304 for ; Fri, 20 Dec 1996 08:36:35 -0800 (PST) Received: by janus.border.com id <30789-1>; Fri, 20 Dec 1996 11:36:03 -0500 Message-Id: <96Dec20.113603est.30789-1@janus.border.com> X-Mailer: exmh version 1.6.7 5/3/96 To: hackers@FreeBSD.org Subject: FreeBSD console device driver. Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 20 Dec 1996 11:37:20 -0500 From: Jerry Kendall Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk I need to take the console device driver that FreeBSD uses and port it to and very old BSDI1.1 system. Can someone please tell me the entire list of files that I need ??? -- -- Jerry Kendall jerry@kcis.com From owner-freebsd-hackers Fri Dec 20 09:01:51 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id JAA27524 for hackers-outgoing; Fri, 20 Dec 1996 09:01:51 -0800 (PST) Received: from nef.ens.fr (nef.ens.fr [129.199.96.12]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id JAA27519 for ; Fri, 20 Dec 1996 09:01:44 -0800 (PST) Received: from clipper.ens.fr (clipper-gw.ens.fr [129.199.1.22]) by nef.ens.fr (8.8.4/jtpda-5.1) with ESMTP id SAA14173 ; Fri, 20 Dec 1996 18:01:40 +0100 (MET) From: espie@clipper.ens.fr (Marc Espie) Received: from drakkar.ens.fr (drakkar [129.199.129.5]) by clipper.ens.fr (8.8.4/jb-1.1) id SAA29971 ; Fri, 20 Dec 1996 18:01:39 +0100 (MET) Received: from (espie@localhost) by drakkar.ens.fr (8.8.4/jb-1.1) Message-Id: <199612201701.SAA20961@drakkar.ens.fr> Subject: tracker To: hackers@freebsd.org Date: Fri, 20 Dec 1996 18:01:37 +0100 (MET) Cc: unix-adm@nic.funet.fi X-Remark: from the ENS, use finger espie@lotus.ens.fr to know if I'm here. Organisation: None X-Mailer: ELM [version 2.4 PL24 ME8a] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I've got some SERIOUS complaints concerning the version of tracker bundled with the 2.2-ALPHA release of FreeBSD. - first, 5.3 is supposed to be a BETA release for private use. It is EMPHATICALLY ****NOT**** to be included with any public releases. It should only be on my site. Quote from the general README in the beta directory: This is a BETA version of the soon-to-be release of tracker. It will change each time it needs to. Use only for beta-testing, do not redistribute ! don't you people know how to read ? - second problem, when you start up this version of tracker, it does say: This is tracker 5.3 This program is NOT to be redistributed without the full documentation I fail to see the full documentation as part of YOUR package. I am perfectly willing to distribute programs I write to the world at large, but ONLY IF YOU ARE PLAYING BY THE RULES. * in case of doubt, please ask. If the latest publically available release of tracker does NOT run on FreeBSD, maybe we can work something through. * leaving the documentation OUT is akin to software piracy. The newer releases of tracker ARE copyrighted AND shareware. You are not supposed to leave this kind of thing out. -- microsoft network is EXPLICITLY forbidden to redistribute this message. `Seiza no matataki kazoe, uranau koi no yuku e.' Marc Espie (Marc.Espie@ens.fr) From owner-freebsd-hackers Fri Dec 20 09:51:37 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id JAA29841 for hackers-outgoing; Fri, 20 Dec 1996 09:51:37 -0800 (PST) Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id JAA29810; Fri, 20 Dec 1996 09:51:24 -0800 (PST) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id SAA13139; Fri, 20 Dec 1996 18:51:16 +0100 Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id SAA17545; Fri, 20 Dec 1996 18:51:15 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.8.4/8.6.9) id SAA04883; Fri, 20 Dec 1996 18:42:12 +0100 (MET) From: J Wunsch Message-Id: <199612201742.SAA04883@uriah.heep.sax.de> Subject: Re: innd can't remalloc To: petzi@apfel.de Date: Fri, 20 Dec 1996 18:42:12 +0100 (MET) Cc: isp@freebsd.org, hackers@freebsd.org Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: from Michael Beckmann at "Dec 20, 96 10:12:51 am" 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 X-Mailer: ELM [version 2.4ME+ PL17 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk As Michael Beckmann wrote: > Dec 20 08:52:37 news innd: SERVER cant remalloc 2097408 bytes Cannot > allocate memory > It seems to me that the crash occurs when the innd process grows to around > 128 MB. j@uriah 107% limit -h cputime unlimited filesize unlimited datasize 131072 kbytes ^^^^^^^^^^^^^ stacksize 65536 kbytes coredumpsize unlimited memoryuse unlimited descriptors unlimited memorylocked 29680 kbytes maxproc 339 You can override this using: options "MAXDSIZ='(256UL*1024*1024)'" (For 2.2 systems, leave out the '' quotes. Should be converted to an official option.) -- 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 Fri Dec 20 10:01:39 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id KAA00460 for hackers-outgoing; Fri, 20 Dec 1996 10:01:39 -0800 (PST) Received: from mexico.brainstorm.eu.org (root@mexico.brainstorm.fr [193.56.58.253]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id KAA00452 for ; Fri, 20 Dec 1996 10:01:29 -0800 (PST) Received: from brasil.brainstorm.eu.org (brasil.brainstorm.fr [193.56.58.33]) by mexico.brainstorm.eu.org (8.7.5/8.7.3) with ESMTP id TAA15874 for ; Fri, 20 Dec 1996 19:01:12 +0100 Received: (from uucp@localhost) by brasil.brainstorm.eu.org (8.6.12/8.6.12) with UUCP id TAA18445 for hackers@FreeBSD.ORG; Fri, 20 Dec 1996 19:00:46 +0100 Received: (from roberto@localhost) by keltia.freenix.fr (8.8.4/keltia-uucp-2.9) id SAA03681; Fri, 20 Dec 1996 18:42:42 +0100 (CET) Message-ID: Date: Fri, 20 Dec 1996 18:42:41 +0100 From: roberto@keltia.freenix.fr (Ollivier Robert) To: hackers@FreeBSD.ORG Subject: Re: HELP! :-( Hitting datasize limit References: <199610261731.MAA08279@solaria.sol.net> <199610261800.NAA01008@dyson.iquest.net> X-Mailer: Mutt 0.54 Mime-Version: 1.0 X-Operating-System: FreeBSD 3.0-CURRENT ctm#2830 In-Reply-To: <199610261800.NAA01008@dyson.iquest.net>; from John S. Dyson on Oct 26, 1996 13:00:21 -0500 Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk According to Michael Beckmann: > It seems to me that the crash occurs when the innd process grows to around > 128 MB. I assume I am running into some kernel limitation, something like: > "no process may have more than 128 MB RAM resident", but I cannot see any > setting for that. Could anyone help me out ? I have already tried > increasing some limits with ulimit statements at the beginning of rc.news, > but this problem didn't go away. Here is John's answer for a similar problem a while ago: According to John S. Dyson: > Sorry, I have been busy with other things: > > > options "MAXDSIZ=(256UL*1024*1024)" > options "DFLDSIZ=(192UL*1024*1024)" -- Ollivier ROBERT -=- The daemon is FREE! -=- roberto@keltia.freenix.fr FreeBSD keltia.freenix.fr 3.0-CURRENT #32: Thu Dec 19 20:47:10 CET 1996 From owner-freebsd-hackers Fri Dec 20 10:05:00 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id KAA00621 for hackers-outgoing; Fri, 20 Dec 1996 10:05:00 -0800 (PST) Received: from who.cdrom.com (who.cdrom.com [204.216.27.3]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id KAA00616 for ; Fri, 20 Dec 1996 10:04:58 -0800 (PST) Received: from simpukka.funet.fi (simpukka.funet.fi [130.230.1.50]) by who.cdrom.com (8.7.5/8.6.11) with ESMTP id KAA04137 for ; Fri, 20 Dec 1996 10:04:56 -0800 (PST) Received: from nic.funet.fi (nic.funet.fi [128.214.248.6]) by simpukka.funet.fi (8.7.5/8.7.3) with SMTP id TAA23350; Fri, 20 Dec 1996 19:57:44 +0200 (EET) From: Harri K Salminen Message-Id: <199612201757.TAA23350@simpukka.funet.fi> X-Authentication-Warning: simpukka.funet.fi: Host nic.funet.fi [128.214.248.6] didn't use HELO protocol To: espie@clipper.ens.fr (Marc Espie) Cc: hackers@freebsd.org, unix-adm@nic.funet.fi Subject: Re: tracker In-reply-to: Your message of Fri, 20 Dec 96 18:01:37 +0100. <199612201701.SAA20961@drakkar.ens.fr> Date: Fri, 20 Dec 96 19:57:43 +0200 X-Mts: smtp Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I can't see the whole 2.2-ALPHA/All directory at nic.funet.fi. Tracker-5.3 seems to be under FreeBSD-current etc. now. Anyway, we are just trying to keep a full mirror of ftp.freebsd.org and we can't read every readme just to find something to exclude. If something is removed at the original site then it should soon disappear here although there seems to be some bugs sometimes preventing it. Harry peacefull christmas as we say here in Finland, I try to soon... Harri Salminen nic.funet.fi coordinator locate tracker-5.3 /mnt/nic/info/ftp/mnt/ftp.funet.fi/pub/mirrors2/ftp.freebsd.org/pub/FreeBSD/distfiles/tracker-5.3.tgz /mnt/nic/info/ftp/mnt/ftp.funet.fi/pub/mirrors2/ftp.freebsd.org/pub/FreeBSD/packages-2.2/All/tracker-5.3.tgz /mnt/nic/info/ftp/mnt/ftp.funet.fi/pub/mirrors2/ftp.freebsd.org/pub/FreeBSD/packages-2.2/audio/tracker-5.3.tgz /mnt/nic/info/ftp/mnt/ftp.funet.fi/pub/mirrors2/ftp.freebsd.org/pub/FreeBSD/packages-current/All/tracker-5.3.tgz /mnt/nic/info/ftp/mnt/ftp.funet.fi/pub/mirrors2/ftp.freebsd.org/pub/FreeBSD/packages-current/audio/tracker-5.3.tgz From owner-freebsd-hackers Fri Dec 20 10:14:32 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id KAA00885 for hackers-outgoing; Fri, 20 Dec 1996 10:14:32 -0800 (PST) Received: from gateway.skipstone.com (root@[198.214.10.129]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id KAA00880 for ; Fri, 20 Dec 1996 10:14:29 -0800 (PST) Received: from bugs.skipstone.com (bugs.skipstone.com [204.69.236.2]) by gateway.skipstone.com (8.7.4/8.6.9) with ESMTP id MAA07219; Fri, 20 Dec 1996 12:13:54 -0600 Received: from [204.69.236.50] (hotapplepie.skipstone.com [204.69.236.50]) by bugs.skipstone.com (8.7.5/8.7.3) with ESMTP id MAA26583; Fri, 20 Dec 1996 12:13:52 -0600 X-Sender: rkw@mail.dataplex.net Message-Id: In-Reply-To: <199612201701.SAA20961@drakkar.ens.fr> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 20 Dec 1996 12:13:50 -0600 To: espie@clipper.ens.fr (Marc Espie) From: Richard Wackerbarth Subject: Re: tracker Cc: hackers@freebsd.org Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >I've got some SERIOUS complaints concerning the version of tracker >bundled with the 2.2-ALPHA release of FreeBSD. I am confused. There is NO version of tracker "bundled" with 2.2-ALPHA. There is included in the ports collection a makefile which will fetch and compile the 5.3 version of the program. However, to do so, it must download the entire tracker-5.3.tgz file. Since it does not delete anything, I fail to see how you can contend that it is leaving out anything. The fact that there are some versions of tracker-*.t*[zZ] on wcarchive is a separate matter. You should take that up with their site administrator. From owner-freebsd-hackers Fri Dec 20 10:34:19 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id KAA01853 for hackers-outgoing; Fri, 20 Dec 1996 10:34:19 -0800 (PST) Received: from hemi.com (hemi.com [204.132.158.10]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id KAA01845 for ; Fri, 20 Dec 1996 10:34:17 -0800 (PST) Received: (from mbarkah@localhost) by hemi.com (8.8.4/8.7.3) id LAA20097; Fri, 20 Dec 1996 11:34:06 -0700 (MST) From: Ade Barkah Message-Id: <199612201834.LAA20097@hemi.com> Subject: Re: tracker To: rkw@dataplex.net (Richard Wackerbarth) Date: Fri, 20 Dec 1996 11:34:05 -0700 (MST) Cc: espie@clipper.ens.fr, hackers@FreeBSD.ORG In-Reply-To: from Richard Wackerbarth at "Dec 20, 96 12:13:50 pm" X-Mailer: ELM [version 2.4ME+ PL22 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > >I've got some SERIOUS complaints concerning the version of tracker > >bundled with the 2.2-ALPHA release of FreeBSD. > > I am confused. There is NO version of tracker "bundled" with 2.2-ALPHA. > > There is included in the ports collection a makefile which will fetch and > compile the 5.3 version of the program. ... There appears to be a package. On wuarchive: | ftp> pwd | 257 "/.16/FreeBSD/packages-current/All" is current directory. | ftp> ls tracker* | 200 PORT command successful. | 150 Opening ASCII mode data connection for /bin/ls. | -rw-r--r-- 1 569 wheel 75657 Dec 18 04:43 tracker-5.3.tgz So that should be removed. Regards, -Ade ------------------------------------------------------------------- Inet: mbarkah@hemi.com - HEMISPHERE ONLINE - ------------------------------------------------------------------- From owner-freebsd-hackers Fri Dec 20 11:08:53 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id LAA03487 for hackers-outgoing; Fri, 20 Dec 1996 11:08:53 -0800 (PST) Received: from smtp02.worldbank.org (smtp02.worldbank.org [138.220.3.17]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id LAA03476; Fri, 20 Dec 1996 11:08:47 -0800 (PST) Received: from bheema.worldbank.org by worldbank.org (PMDF V5.0-7 #16195) id <01ID8HVX3NFY9UNPZ6@worldbank.org>; Fri, 20 Dec 1996 14:07:51 -0500 (EST) Received: from localhost by bheema.worldbank.org; (5.65/1.1.8.2/28Jul95-0113PM) id AA04815; Fri, 20 Dec 1996 14:05:37 -0500 Date: Fri, 20 Dec 1996 15:05:36 -0400 (EDT) From: "Alok K. Dhir" Subject: Partitioning large disk for news... To: hackers@freebsd.org, questions@freebsd.org, stable@freebsd.org Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII Content-transfer-encoding: 7BIT Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hey all - I'm getting ready to install a Pro200 running FreeBSD 2.1.6.1 as our news server here at the World Bank, and have the following questions: I have a Seagate 9 gig disk to use as the news spool, and I'm wondering what the best way to use it will be (the / and /usr partitions are on a separate 2 gig disk). I remember in the past (way back in the 1.1.5.1 - 2.0 days) there was some trouble with partitions larger than 2 gigs. Is this still the case? If so, I'm thinking maybe I can use the ccd driver to serially concatenate 5 partitions on the disk together for use as one large news spool. Which of these options is likely to cause the least amount of headache for me? Thanks for any info - and please respond directly to me, if possible, since I am not subscribed to the lists (I get too much mail already...). Unrelated note: I recently had all sorts of trouble trying to get the BSDI version of Netscape 3.0 running on my 2.1.6.1 box. Turns out I had commented out the 'options "COMPAT_43"' line in my kernel conf file, and for some reason, BSDI (and Linux) compatibility won't work without it. Perhaps there should be mention of this in LINT. Thanks! -------------------------------------------------------------------- \||/_ Alok K. Dhir Phone: +1.202.473.2446 oo \ R7-003, ITSMC Email: adhir@worldbank.org L_ The World Bank Group Washington, DC \/ ---------------------------------------------------------------------- | From owner-freebsd-hackers Fri Dec 20 11:34:52 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id LAA04801 for hackers-outgoing; Fri, 20 Dec 1996 11:34:52 -0800 (PST) Received: from time.cdrom.com (time.cdrom.com [204.216.27.226]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id LAA04795; Fri, 20 Dec 1996 11:34:36 -0800 (PST) Received: from time.cdrom.com (localhost [127.0.0.1]) by time.cdrom.com (8.8.4/8.6.9) with ESMTP id LAA18682; Fri, 20 Dec 1996 11:34:24 -0800 (PST) To: espie@clipper.ens.fr (Marc Espie) cc: hackers@freebsd.org, unix-adm@nic.funet.fi, ache@freebsd.org Subject: Re: tracker In-reply-to: Your message of "Fri, 20 Dec 1996 18:01:37 +0100." <199612201701.SAA20961@drakkar.ens.fr> Date: Fri, 20 Dec 1996 11:34:23 -0800 Message-ID: <18678.851110463@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > I've got some SERIOUS complaints concerning the version of tracker > bundled with the 2.2-ALPHA release of FreeBSD. Sorry, this was probably an oversight. I will ask that tracker be removed entirely from the FreeBSD ports collection, thus eliminating any possibility for further such misunderstandings in the future. Our apologies. Andrey, would you please do the honors? Jordan From owner-freebsd-hackers Fri Dec 20 11:52:17 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id LAA05475 for hackers-outgoing; Fri, 20 Dec 1996 11:52:17 -0800 (PST) Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id LAA05444; Fri, 20 Dec 1996 11:51:52 -0800 (PST) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id UAA24368; Fri, 20 Dec 1996 20:51:06 +0100 Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id UAA20950; Fri, 20 Dec 1996 20:51:05 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.8.4/8.6.9) id UAA05654; Fri, 20 Dec 1996 20:20:05 +0100 (MET) From: J Wunsch Message-Id: <199612201920.UAA05654@uriah.heep.sax.de> Subject: Re: tracker To: freebsd-hackers@freebsd.org (FreeBSD hackers) Date: Fri, 20 Dec 1996 20:20:04 +0100 (MET) Cc: espie@clipper.ens.fr, ache@freebsd.org Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199612201834.LAA20097@hemi.com> from Ade Barkah at "Dec 20, 96 11:34:05 am" 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 X-Mailer: ELM [version 2.4ME+ PL17 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk As Ade Barkah wrote: > There appears to be a package. On wuarchive: > | -rw-r--r-- 1 569 wheel 75657 Dec 18 04:43 tracker-5.3.tgz > > So that should be removed. ...and the port probably be updated to include the requested documentation. It includes the .info file, but i can't get hold of the original distribution right now to see what other documentation could be meant. The dist site is 20 hops away from me behind some very lousy lines. Andrey? -- 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 Fri Dec 20 12:44:59 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id MAA07462 for hackers-outgoing; Fri, 20 Dec 1996 12:44:59 -0800 (PST) Received: from korin.warman.org.pl (korin.warman.org.pl [148.81.160.10]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id MAA07391 for ; Fri, 20 Dec 1996 12:44:07 -0800 (PST) Received: from localhost (abial@localhost) by korin.warman.org.pl (8.8.3/8.7.3) with SMTP id VAA09204; Fri, 20 Dec 1996 21:43:27 +0100 (MET) Date: Fri, 20 Dec 1996 21:43:27 +0100 (MET) From: Andrzej Bialecki To: Bruce Evans cc: freebsd-hackers@FreeBSD.ORG Subject: Re: 2.2-ALPHA hangs while calibrating clocks... In-Reply-To: <199612181100.WAA31169@godzilla.zeta.org.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Wed, 18 Dec 1996, Bruce Evans wrote: > >I'm trying to install FreeBSD 2.2-ALPHA on my machine. Here is > >configuration: > > > >* MB SOYO Intel Triton HX, Pentium 120MHz, BIOS Award > >* 64MB RAM EDO, pipeline burst cache 512k > >* HDD IDE WDC32100 (2.1 GB) LBA mode 4, floppy drive etc... > >* 3c509 ISA ethernet adapter (ep0) > > > >The kernel is, of course, GENERIC 2.2-ALPHA. > > > >So, the installation itself goes well (although I used 2.1.6 install > >floppy), and then, after rebooting with newly installed system, it hangs > >almost forever (at least for 15 minutes :-) ) saying: > > > >Calibrating clock(s) relative to mc146818A clock... > > > >and then says it failed. > > > >So my question is: do I have a broken motherboard? Are there any options > >in kernel config that I should change in order to avoid this looong > >waiting? > > The RTC seems to be broken after the reboot. The calibration routine > just waits for the seconds counter to change twice. It apparently didn't > change for 15 minutes. There is a generous timeout of 100 million reads > of the seconds counter to give it a chance to change. Change it to 1 > million (in clock.c). > > Bruce > Thank you for your advice - I did so, and the problem is less frustrating - though I think I'll complain to the seller of the motherboard. Thanks. Andy, +-------------------------------------------------------------------------+ Andrzej Bialecki _) _) _)_) _)_)_) _) _) --------------------------------------- _)_) _) _) _) _)_) _)_) Research and Academic Network in Poland _) _)_) _)_)_)_) _) _) _) Bartycka 18, 00-716 Warsaw, Poland _) _) _) _) _)_)_) _) _) +-------------------------------------------------------------------------+ From owner-freebsd-hackers Fri Dec 20 12:55:32 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id MAA08227 for hackers-outgoing; Fri, 20 Dec 1996 12:55:32 -0800 (PST) Received: from Journey2.cbr (annex12-5.dial.umd.edu [128.8.23.149]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id MAA08215 for ; Fri, 20 Dec 1996 12:55:29 -0800 (PST) Received: from Journey2.cbr (Journey2.cbr [192.168.64.1]) by Journey2.cbr (8.8.4/8.7.3) with SMTP id PAA04704 for ; Fri, 20 Dec 1996 15:54:36 -0500 (EST) Date: Fri, 20 Dec 1996 15:54:14 -0500 (EST) From: Chuck Robey X-Sender: chuckr@Journey2.cbr To: FreeBSD-hackers@freebsd.org Subject: popping mail Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I am starting finally to use fetchmail and pop my mail from the university here, which seems to work ok. I have one problem that I hope someone could give me a hint as to solving. I use ppp in -auto mode, with fetchmail being kicked off every 30 minutes to get my mail, and pine here on FreeBSD to read it. Whenever I start pine, it causes ppp to dial the university. I don't want that to happen, particularly, unless I actually compose and post a email. Is there any way to stop pine from causing the ppp line to go active? Thanks Chuck From owner-freebsd-hackers Fri Dec 20 13:45:39 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id NAA10599 for hackers-outgoing; Fri, 20 Dec 1996 13:45:39 -0800 (PST) Received: from nef.ens.fr (nef.ens.fr [129.199.96.12]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id NAA10585; Fri, 20 Dec 1996 13:45:30 -0800 (PST) Received: from clipper.ens.fr (clipper-gw.ens.fr [129.199.1.22]) by nef.ens.fr (8.8.4/jtpda-5.1) with ESMTP id WAA25206 ; Fri, 20 Dec 1996 22:45:22 +0100 (MET) From: espie@clipper.ens.fr (Marc Espie) Received: from triere.ens.fr (triere [129.199.128.2]) by clipper.ens.fr (8.8.4/jb-1.1) id WAA09836 ; Fri, 20 Dec 1996 22:45:21 +0100 (MET) Received: from (espie@localhost) by triere.ens.fr (8.8.4/jb-1.1) Message-Id: <199612202145.WAA22932@triere.ens.fr> Subject: Re: tracker To: jkh@time.cdrom.com (Jordan K. Hubbard) Date: Fri, 20 Dec 1996 22:45:16 +0100 (MET) Cc: espie@clipper.ens.fr, hackers@freebsd.org, unix-adm@nic.funet.fi, ache@freebsd.org In-Reply-To: <18678.851110463@time.cdrom.com> from "Jordan K. Hubbard" at Dec 20, 96 11:34:23 am X-Remark: from the ENS, use finger espie@lotus.ens.fr to know if I'm here. Organisation: None X-Mailer: ELM [version 2.4 PL24 ME8a] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk En reponse a Jordan K. Hubbard: > > > I've got some SERIOUS complaints concerning the version of tracker > > bundled with the 2.2-ALPHA release of FreeBSD. > > Sorry, this was probably an oversight. I will ask that tracker be > removed entirely from the FreeBSD ports collection, thus eliminating > any possibility for further such misunderstandings in the future. > > Our apologies. > > Andrey, would you please do the honors? > > Jordan Well, this is only regarding version 5.3, which is definitely a beta which is not ready for public consumption. As long as the documentation as a whole (original readmes, texinfo file for those not willing to suffer through info) is included, and as soon as I manage to get a `public' release, I don't see any other problems. What I am wanting to do is to establish very clearly tracker status: betas such as these should not have reached general release. I already get lots of bug-reports which I have to check... having them come either from `stable' versions or from established beta-testers I know gets it rather easier. Also, I consider it normal that bugs should be left in code at the beta stage. On the other hand, public releases I strive to make crystal-clean. Betas re-packaged as `official' releases reflect badly upon my programming skills, and may be damaging to users expecting quality code. I just wish for that particular beta to vanish from freebsd. I sincerely hope I'll have a regular release ready soon. This one you are obviously free to include with FreeBSD, no problems. In fact, I WILL be interested in eventual porting problems. Also, I understand plainly that the problem appeared at a previous stage, and that you're not responsible for it. No serious harm done... I will just have to suffer through some unneeded bug-reports (probably) as 5.3 has some well-known problems, and I will try to get a `stable' version out soon. -- microsoft network is EXPLICITLY forbidden to redistribute this message. `Seiza no matataki kazoe, uranau koi no yuku e.' Marc Espie (Marc.Espie@ens.fr) From owner-freebsd-hackers Fri Dec 20 14:31:01 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id OAA13049 for hackers-outgoing; Fri, 20 Dec 1996 14:31:01 -0800 (PST) Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id OAA13041 for ; Fri, 20 Dec 1996 14:30:58 -0800 (PST) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id XAA08705; Fri, 20 Dec 1996 23:30:47 +0100 Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id XAA23383; Fri, 20 Dec 1996 23:30:46 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.8.4/8.6.9) id XAA07947; Fri, 20 Dec 1996 23:30:02 +0100 (MET) From: J Wunsch Message-Id: <199612202230.XAA07947@uriah.heep.sax.de> Subject: Re: popping mail To: chuckr@glue.umd.edu (Chuck Robey) Date: Fri, 20 Dec 1996 23:30:02 +0100 (MET) Cc: FreeBSD-hackers@freebsd.org Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: from Chuck Robey at "Dec 20, 96 03:54:14 pm" 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 X-Mailer: ELM [version 2.4ME+ PL17 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk As Chuck Robey wrote: > actually compose and post a email. Is there any way to stop pine from > causing the ppp line to go active? A local (even caching-only) nameserver, i assume. -- 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 Fri Dec 20 16:34:36 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id QAA17078 for hackers-outgoing; Fri, 20 Dec 1996 16:34:36 -0800 (PST) Received: from sunbeam.csusb.edu (sunbeam.csusb.edu [139.182.10.13]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id QAA17073 for ; Fri, 20 Dec 1996 16:34:35 -0800 (PST) Received: (from rmallory@localhost) by sunbeam.csusb.edu (8.8.4/8.7.3) id QAA05979 for freebsd-hackers@freefall.cdrom.com; Fri, 20 Dec 1996 16:39:10 -0800 (PST) From: Rob Mallory Message-Id: <199612210039.QAA05979@sunbeam.csusb.edu> Subject: 3com 3c589b pcmcia support? To: freebsd-hackers@freefall.FreeBSD.org Date: Fri, 20 Dec 1996 16:39:09 -0800 (PST) X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Is Poul still the laptop-God? I just got a toshiba420cds, and am looking to get the etherlink-III/pcmcia , and also this megaheartz modem card running also.. Is anyone working on getting support for the 3c589b pcmcia card? Thanks, Rob Mallory [rob@Qualcomm.com] From owner-freebsd-hackers Fri Dec 20 16:42:04 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id QAA17480 for hackers-outgoing; Fri, 20 Dec 1996 16:42:04 -0800 (PST) Received: from mexico.brainstorm.eu.org (root@mexico.brainstorm.fr [193.56.58.253]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id QAA17473 for ; Fri, 20 Dec 1996 16:41:59 -0800 (PST) Received: from brasil.brainstorm.eu.org (brasil.brainstorm.fr [193.56.58.33]) by mexico.brainstorm.eu.org (8.7.5/8.7.3) with ESMTP id BAA16436; Sat, 21 Dec 1996 01:41:44 +0100 Received: (from uucp@localhost) by brasil.brainstorm.eu.org (8.6.12/8.6.12) with UUCP id BAA22302; Sat, 21 Dec 1996 01:41:31 +0100 Received: (from roberto@localhost) by keltia.freenix.fr (8.8.4/keltia-uucp-2.9) id BAA04501; Sat, 21 Dec 1996 01:36:37 +0100 (CET) Message-ID: Date: Sat, 21 Dec 1996 01:36:36 +0100 From: roberto@keltia.freenix.fr (Ollivier Robert) To: hackers@freebsd.org Cc: adhir@worldbank.org Subject: Re: Partitioning large disk for news... References: X-Mailer: Mutt 0.54 Mime-Version: 1.0 X-Operating-System: FreeBSD 3.0-CURRENT ctm#2830 In-Reply-To: ; from Alok K. Dhir on Dec 20, 1996 15:05:36 -0400 Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk According to Alok K. Dhir: > I have a Seagate 9 gig disk to use as the news spool, and I'm wondering > what the best way to use it will be (the / and /usr partitions are on a > separate 2 gig disk). If you're serious about that news business, ditch the 9 GB drive and get four 4 GB drives or 2 4 GB. They will perform better than one single drive. > I remember in the past (way back in the 1.1.5.1 - 2.0 days) there was some > trouble with partitions larger than 2 gigs. Is this still the case? If Not, it disappeared after the switch to 4.4BSD. -- Ollivier ROBERT -=- The daemon is FREE! -=- roberto@keltia.freenix.fr FreeBSD keltia.freenix.fr 3.0-CURRENT #32: Thu Dec 19 20:47:10 CET 1996 From owner-freebsd-hackers Fri Dec 20 17:06:38 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id RAA18330 for hackers-outgoing; Fri, 20 Dec 1996 17:06:38 -0800 (PST) Received: from rocky.mt.sri.com ([206.127.76.100]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id RAA18325 for ; Fri, 20 Dec 1996 17:06:36 -0800 (PST) Received: (from nate@localhost) by rocky.mt.sri.com (8.7.5/8.7.3) id SAA25266; Fri, 20 Dec 1996 18:06:18 -0700 (MST) Date: Fri, 20 Dec 1996 18:06:18 -0700 (MST) Message-Id: <199612210106.SAA25266@rocky.mt.sri.com> From: Nate Williams To: Rob Mallory Cc: freebsd-hackers@freefall.freebsd.org Subject: Re: 3com 3c589b pcmcia support? In-Reply-To: <199612210039.QAA05979@sunbeam.csusb.edu> References: <199612210039.QAA05979@sunbeam.csusb.edu> Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > Is Poul still the laptop-God? I just got a toshiba420cds, and am > > looking to get the etherlink-III/pcmcia , and also this megaheartz > > modem card running also.. The modem won't work under any of the 2.1* release, but might work under 2.2R or -current. I got my Motorola Power and a Xircom modem working easily last week. > Is anyone working on getting support for the 3c589b pcmcia card? It's been supported since version 2.0. Nate From owner-freebsd-hackers Fri Dec 20 17:12:27 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id RAA18597 for hackers-outgoing; Fri, 20 Dec 1996 17:12:27 -0800 (PST) Received: (from grog@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id RAA18586; Fri, 20 Dec 1996 17:12:24 -0800 (PST) From: Greg Lehey Message-Id: <199612210112.RAA18586@freefall.freebsd.org> Subject: Re: 3com 3c589b pcmcia support? To: rmallory@sunbeam.csusb.edu (Rob Mallory) Date: Fri, 20 Dec 1996 17:12:24 -0800 (PST) Cc: hackers In-Reply-To: <199612210039.QAA05979@sunbeam.csusb.edu> from "Rob Mallory" at Dec 20, 96 04:39:09 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Rob Mallory writes: > > Is Poul still the laptop-God? I'll let somebody else comment on this one :-) > I just got a toshiba420cds, and am > looking to get the etherlink-III/pcmcia , and also this megaheartz > modem card running also.. > > Is anyone working on getting support for the 3c589b pcmcia card? Do you already have a 3c589b? The current version is the 3c589c, and 3Com tell me that the d is on its way out. I'm using a c, and apart from severe problems figuring out how to configure, it works fine (but a little slowly--ftp to /dev/null runs at about 800 kb/s). Greg From owner-freebsd-hackers Fri Dec 20 17:47:54 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id RAA20052 for hackers-outgoing; Fri, 20 Dec 1996 17:47:54 -0800 (PST) Received: from ormail.intel.com (ormail.intel.com [134.134.248.3]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id RAA20046; Fri, 20 Dec 1996 17:47:52 -0800 (PST) Received: from ichips.intel.com (ichips.intel.com [134.134.50.200]) by ormail.intel.com (8.8.4/8.8.4) with ESMTP id RAA00389; Fri, 20 Dec 1996 17:47:46 -0800 (PST) Received: from ichips by ichips.intel.com (8.7.4/jIII) id RAA11578; Fri, 20 Dec 1996 17:44:06 -0800 (PST) Date: Fri, 20 Dec 1996 17:44:06 -0800 (PST) From: Steve Willoughby X-Sender: steve@ichips To: Greg Lehey cc: Rob Mallory , hackers@freefall.freebsd.org Subject: Re: 3com 3c589b pcmcia support? In-Reply-To: <199612210112.RAA18586@freefall.freebsd.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Fri, 20 Dec 1996, Greg Lehey wrote: > Do you already have a 3c589b? The current version is the 3c589c, and > 3Com tell me that the d is on its way out. I'm using a c, and apart > from severe problems figuring out how to configure, it works fine (but > a little slowly--ftp to /dev/null runs at about 800 kb/s). I have a 3c589c-TP, and the default GENERIC kernel finds it, ifconfigs it up, and appears to work (I get a link light on the hub at that point). However, no packets will move in or out of it, as if there was no net there at all. Am I missing something simple? I'm going to config a custom kernel for it, but I'm not sure what to configure differently since it appears to see the card OK, just not talk to it. Any hints would be appreciated. TIA -- Steve Willoughby * Intel MD6 | It's said that the only thing scarier than steve@ichips.intel.com | a sysadmin with a screwdriver is a programmer Unix Systems Administrator | with the root password. MD6 E-Mail Postmaster | Then again, I'm both... Scares *me* anyway... From owner-freebsd-hackers Fri Dec 20 19:28:41 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id TAA23154 for hackers-outgoing; Fri, 20 Dec 1996 19:28:41 -0800 (PST) Received: from tdc.on.ca (tdc.on.ca [204.92.242.39]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id TAA23149 for ; Fri, 20 Dec 1996 19:28:32 -0800 (PST) Received: (from martin@localhost) by tdc.on.ca (8.7.5/8.6.6) id WAA23404; Fri, 20 Dec 1996 22:28:19 -0500 (EST) From: Martin Renters Message-Id: <199612210328.WAA23404@tdc.on.ca> Subject: Re: 3com 3c589b pcmcia support? To: rmallory@sunbeam.csusb.edu (Rob Mallory) Date: Fri, 20 Dec 1996 22:28:19 -0500 (EST) Cc: freebsd-hackers@freefall.freebsd.org In-Reply-To: <199612210039.QAA05979@sunbeam.csusb.edu> from "Rob Mallory" at Dec 20, 96 04:39:09 pm X-Mailer: ELM [version 2.4 PL24 ME8a] Content-Type: text Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > Is Poul still the laptop-God? I just got a toshiba420cds, and am > looking to get the etherlink-III/pcmcia , and also this megaheartz > modem card running also.. > > Is anyone working on getting support for the 3c589b pcmcia card? Don't know about the Megahertz modem, but my 3c589c works fine with the PAO code. The system says that it is using the TP connector when it notices the card, but I found I had to put the ifconfig ep0 192.1.2.3 -link0 -link1 link2 for TP and ifconfig ep0 192.1.2.3 -link0 link1 -link2 for BNC You may also have to play with the IRQ settings in /etc/pccard.conf. I disabled the Infrared Port on my Toshiba to save an IRQ line. Martin From owner-freebsd-hackers Fri Dec 20 21:37:01 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id VAA26489 for hackers-outgoing; Fri, 20 Dec 1996 21:37:01 -0800 (PST) Received: from rocky.mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id VAA26479; Fri, 20 Dec 1996 21:36:59 -0800 (PST) Received: (from nate@localhost) by rocky.mt.sri.com (8.7.5/8.7.3) id WAA25762; Fri, 20 Dec 1996 22:33:14 -0700 (MST) Date: Fri, 20 Dec 1996 22:33:14 -0700 (MST) Message-Id: <199612210533.WAA25762@rocky.mt.sri.com> From: Nate Williams To: Steve Willoughby Cc: Greg Lehey , Rob Mallory , hackers@freefall.freebsd.org Subject: Re: 3com 3c589b pcmcia support? In-Reply-To: References: <199612210112.RAA18586@freefall.freebsd.org> Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > I have a 3c589c-TP, and the default GENERIC kernel finds it, ifconfigs > it up, and appears to work (I get a link light on the hub at that > point). Try messing with the link flags. Usually appending '-link0 link1' *OR* 'link0 -link1' works. Nate From owner-freebsd-hackers Fri Dec 20 23:51:08 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id XAA01087 for hackers-outgoing; Fri, 20 Dec 1996 23:51:08 -0800 (PST) Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id XAA01077 for ; Fri, 20 Dec 1996 23:51:04 -0800 (PST) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id IAA01565 for ; Sat, 21 Dec 1996 08:51:03 +0100 Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id IAA00854 for freebsd-hackers@freebsd.org; Sat, 21 Dec 1996 08:51:02 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.8.4/8.6.9) id IAA10183 for freebsd-hackers@freebsd.org; Sat, 21 Dec 1996 08:50:16 +0100 (MET) From: J Wunsch Message-Id: <199612210750.IAA10183@uriah.heep.sax.de> Subject: Re: 3com 3c589b pcmcia support? To: freebsd-hackers@freebsd.org (FreeBSD hackers) Date: Sat, 21 Dec 1996 08:50:16 +0100 (MET) Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199612210112.RAA18586@freefall.freebsd.org> from Greg Lehey at "Dec 20, 96 05:12:24 pm" 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 X-Mailer: ELM [version 2.4ME+ PL17 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk As Greg Lehey wrote: > > Is Poul still the laptop-God? > > I'll let somebody else comment on this one :-) Why? It's fairly obvious that Nate's got this cap recently, and there's a large crew of Japanese `nomad' hackers, too. -- 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 Sat Dec 21 00:43:32 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id AAA02109 for hackers-outgoing; Sat, 21 Dec 1996 00:43:32 -0800 (PST) Received: from rah.star-gate.com ([204.188.121.18]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id AAA02104 for ; Sat, 21 Dec 1996 00:43:30 -0800 (PST) Received: from rah.star-gate.com (localhost.star-gate.com [127.0.0.1]) by rah.star-gate.com (8.7.6/8.7.3) with ESMTP id AAA10995; Sat, 21 Dec 1996 00:42:41 -0800 (PST) Message-Id: <199612210842.AAA10995@rah.star-gate.com> X-Mailer: exmh version 1.6.9 8/22/96 To: "Ron G. Minnich" cc: hackers@freebsd.org Subject: Re: mmap problems? In-reply-to: Your message of "Fri, 20 Dec 1996 07:48:27 EST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 21 Dec 1996 00:42:40 -0800 From: Amancio Hasty Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Mea Culpa, Tnks for the suggestion. It turns out that if I ctrl-c out of "tv" that I was not freeing up a shared memory segment. All is well now and the VM system lives on 8) Cheers, Amancio >From The Desk Of "Ron G. Minnich" : > can you send me > output from ktrace > ron > > Ron Minnich |"Failure is not an option" -- Gene Kranz > rminnich@sarnoff.com | -- except, of course, on Microsoft products > (609)-734-3120 | > ftp://ftp.sarnoff.com/pub/mnfs/www/docs/cluster.html > > From owner-freebsd-hackers Sat Dec 21 00:52:04 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id AAA02309 for hackers-outgoing; Sat, 21 Dec 1996 00:52:04 -0800 (PST) Received: from spiff.cc.iastate.edu (spiff.cc.iastate.edu [129.186.142.89]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id AAA02288; Sat, 21 Dec 1996 00:51:59 -0800 (PST) Received: by spiff.cc.iastate.edu with sendmail-5.65 id ; Sat, 21 Dec 1996 02:51:58 -0600 Message-Id: <9612210851.AA26623@spiff.cc.iastate.edu> To: questions@freebsd.org Cc: hackers@freebsd.org Reply-To: graphix@iastate.edu Subject: kerberos not working Date: Sat, 21 Dec 1996 02:51:57 CST From: Kent Vander Velden Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On one machine (toybox) kerberos works fine. The same snapshot on a machine (pseudo) which uses toybox as a ppp server does not work. The initial request goes out to kerberos-1 (the main kerberos server) but a response never comes back. I am rather positive that the reequired files are in their proper places and configured correctly. I am using the tun device for ppp. This worked at one point, but stopped a few months ago. The errors I see are: MIT Project Athena (pseudo.cc.iastate.edu) Kerberos Initialization for "graphix" krb_bind_local_addr: bind: Invalid argument krb_bind_local_addr: Can't bind local addresskinit: Can't send request (send_to_kdc) Any help is greatly appreciated. --- Kent Vander Velden graphix@iastate.edu From owner-freebsd-hackers Sat Dec 21 01:29:13 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id BAA03159 for hackers-outgoing; Sat, 21 Dec 1996 01:29:13 -0800 (PST) Received: from spiff.cc.iastate.edu (spiff.cc.iastate.edu [129.186.142.89]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id BAA03153; Sat, 21 Dec 1996 01:29:11 -0800 (PST) Received: by spiff.cc.iastate.edu with sendmail-5.65 id ; Sat, 21 Dec 1996 03:29:11 -0600 Message-Id: <9612210929.AA28379@spiff.cc.iastate.edu> To: questions@freebsd.org Cc: hackers@freebsd.org Reply-To: graphix@iastate.edu Subject: more kerberos Date: Sat, 21 Dec 1996 03:29:10 CST From: "Kent Vander Velden" Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Recently I sent a message about troubles that I was having with Kerberos. I want to add to that original message that my problem occurs when using ppp and not when using pppd. No filters are being used. Thanks. --- Kent Vander Velden graphix@iastate.edu From owner-freebsd-hackers Sat Dec 21 02:49:41 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id CAA04725 for hackers-outgoing; Sat, 21 Dec 1996 02:49:41 -0800 (PST) Received: from ns.rnd.runnet.ru (ns.rnd.runnet.ru [195.208.248.36]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id CAA04720 for ; Sat, 21 Dec 1996 02:49:35 -0800 (PST) Received: from hawk.rnd.runnet.ru by ns.rnd.runnet.ru with SMTP id NAA25258; (8.7.6/vak/1.9) Sat, 21 Dec 1996 13:49:40 +0300 (MSK) Date: Sat, 21 Dec 1996 13:50:08 +0300 (MSK) From: Maxim Bolotin To: freebsd-hackers@freebsd.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk unsubscribe freebsd-hackers From owner-freebsd-hackers Sat Dec 21 08:20:26 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id IAA15215 for hackers-outgoing; Sat, 21 Dec 1996 08:20:26 -0800 (PST) Received: from time.cdrom.com (time.cdrom.com [204.216.27.226]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id IAA15210 for ; Sat, 21 Dec 1996 08:20:23 -0800 (PST) Received: from time.cdrom.com (localhost [127.0.0.1]) by time.cdrom.com (8.8.4/8.6.9) with ESMTP id IAA17042; Sat, 21 Dec 1996 08:20:18 -0800 (PST) To: svaar@math.uio.no (Peter Svaar) cc: hackers@freebsd.org Subject: Re: PPP problem In-reply-to: Your message of "Wed, 18 Dec 1996 19:55:04 +0100." <199612181855.TAA13170@gilgamesj.uio.no> Date: Sat, 21 Dec 1996 08:20:18 -0800 Message-ID: <17039.851185218@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > ok, I admit, I'm a jerk. but hey, jerks want to run FreeBSD too! Not that we'll admit it. > and configured an FTP install. I am constantly connected to the net (not > dialup) thorough a two-thread line (28.8). I go for PPP install, everything > OK, but the program can't detect my modem. I try to change "set device" to > /dev/cuaa0, /dev/cuaa1 and so further, nothing works. I can't seem to get in > contact with the modem. I try "term" and "dial", I think I virtually have > tried everything, changing the modem from com2 to com1, trying all sorts of > combinations, trying slip. It won't work. I use 2.1.6. what should I do? Hmmm. Weird. I have heard similar reports before, but a work-around was always to configure the modem as com1 (sio0), after which stuff just worked. Are you sure on that one? Is your modem even (sioxx) probed at startup time? Jordan From owner-freebsd-hackers Sat Dec 21 11:26:04 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id LAA23426 for hackers-outgoing; Sat, 21 Dec 1996 11:26:04 -0800 (PST) Received: from labinfo.iet.unipi.it (labinfo.iet.unipi.it [131.114.9.5]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id LAA23416 for ; Sat, 21 Dec 1996 11:26:00 -0800 (PST) Received: from localhost (luigi@localhost) by labinfo.iet.unipi.it (8.6.5/8.6.5) id TAA14287; Sat, 21 Dec 1996 19:45:28 +0100 From: Luigi Rizzo Message-Id: <199612211845.TAA14287@labinfo.iet.unipi.it> Subject: Posting to multiple lists To: jkh@time.cdrom.com (Jordan K. Hubbard) Date: Sat, 21 Dec 1996 19:45:28 +0100 (MET) Cc: hackers@freebsd.org In-Reply-To: <26484.851194724@time.cdrom.com> from "Jordan K. Hubbard" at Dec 21, 96 10:58:25 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > I am posting this to questions, current and stable becuase it applies to > > all of them. You can configure majordomo not to send duplicate emails > > for different mail lists. It isn't that hard. > > Nonetheless, we still ask that you stop. Repeated offenses will not > result in a majordomo configuration, they will simply result in you > yourself being filtered at the source. Knock it off or be barred, > it's that simple, and the matter is not open to discussion so Just Do > It Please. I fully second your reply. However, if it is really possible to do what the poster says (configure majordomo not to send duplicate emails for different mail lists) that is something that would be useful anyways. The various lists are surely overlapped, with "questions" and "hackers" probably orthogonal to the various specific lists. Quite often I feel it would be appropriate to post to multiple groups, and I refrain from doing that only because I know the rules. And for the same reason I subscribe to probably more groups than I am strictly interested in just to avoid losing possibly interesting messages. Luigi -----------------------------+-------------------------------------- Luigi Rizzo | Dip. di Ingegneria dell'Informazione email: luigi@iet.unipi.it | Universita' di Pisa tel: +39-50-568533 | via Diotisalvi 2, 56126 PISA (Italy) fax: +39-50-568522 | http://www.iet.unipi.it/~luigi/ _____________________________|______________________________________ From owner-freebsd-hackers Sat Dec 21 11:48:58 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id LAA24723 for hackers-outgoing; Sat, 21 Dec 1996 11:48:58 -0800 (PST) Received: from time.cdrom.com (time.cdrom.com [204.216.27.226]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id LAA24711 for ; Sat, 21 Dec 1996 11:48:55 -0800 (PST) Received: from time.cdrom.com (localhost [127.0.0.1]) by time.cdrom.com (8.8.4/8.6.9) with ESMTP id LAA26834; Sat, 21 Dec 1996 11:48:42 -0800 (PST) To: Luigi Rizzo cc: hackers@freebsd.org Subject: Re: Posting to multiple lists In-reply-to: Your message of "Sat, 21 Dec 1996 19:45:28 +0100." <199612211845.TAA14287@labinfo.iet.unipi.it> Date: Sat, 21 Dec 1996 11:48:42 -0800 Message-ID: <26830.851197722@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > I fully second your reply. However, if it is really possible to do > what the poster says (configure majordomo not to send duplicate > emails for different mail lists) that is something that would be > useful anyways. I'm not sure how it could, unless it always just chose the first mailing list as the "target" and then somehow registered this fact so that a reject would occur for any other mailing lists the user tried to post it to. Jordan From owner-freebsd-hackers Sat Dec 21 12:08:15 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id MAA25820 for hackers-outgoing; Sat, 21 Dec 1996 12:08:15 -0800 (PST) Received: from rah.star-gate.com ([204.188.121.18]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id MAA25815; Sat, 21 Dec 1996 12:08:13 -0800 (PST) Received: from rah.star-gate.com (localhost.star-gate.com [127.0.0.1]) by rah.star-gate.com (8.7.6/8.7.3) with ESMTP id MAA00800; Sat, 21 Dec 1996 12:07:59 -0800 (PST) Message-Id: <199612212007.MAA00800@rah.star-gate.com> X-Mailer: exmh version 1.6.9 8/22/96 To: multimedia@freebsd.org cc: hackers@freebsd.org Subject: Bt848 Lives! Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 21 Dec 1996 12:07:59 -0800 From: Amancio Hasty Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Well, I am watching tv with my Intel Smart Video Capture III PCI board on my PPRO 200MHz 8) The good news is that I seem to be able to take snapshots and it is not crashing my system. The meteor seems to work okay however if I start taking snapshots or if I run vic it will crash my system. My next step is to implement a video mode compatible with vic to verify that the hardware will not crash my system. So far I have implemented 640x480 RGB32, this means that the driver is not done yet and it will be a while before I can finished it or fully qualify the board for FreeBSD. So in summary, there is hope to have decent video capture for PPRO 200MHz running FreeBSD 8) Forgot to mention, I payed $179 for my card (http://www.libiind.com) 8) Enjoy, Amancio From owner-freebsd-hackers Sat Dec 21 12:51:29 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id MAA27405 for hackers-outgoing; Sat, 21 Dec 1996 12:51:29 -0800 (PST) Received: from cray.svaar.no (cray.svaar.no [194.19.7.150]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id MAA27396 for ; Sat, 21 Dec 1996 12:51:23 -0800 (PST) Received: (from peter@localhost) by cray.svaar.no (8.8.4/8.8.4) id VAA05053; Sat, 21 Dec 1996 21:30:00 +0100 To: "Jordan K. Hubbard" Cc: hackers@freebsd.org Subject: Re: PPP problem References: <17039.851185218@time.cdrom.com> From: Peter Svaar Date: 21 Dec 1996 21:30:00 +0100 In-Reply-To: "Jordan K. Hubbard"'s message of Sat, 21 Dec 1996 08:20:18 -0800 Message-ID: Lines: 21 X-Mailer: Gnus v5.3/Emacs 19.34 Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk ["Jordan K. Hubbard" ] | | Hmmm. Weird. I have heard similar reports before, but a work-around | was always to configure the modem as com1 (sio0), after which stuff | just worked. Are you sure on that one? Is your modem even (sioxx) | probed at startup time? thanx a lot to you (and all the others) for good advice. I found that entering "term" and writing "~p" worked, and most of the distribution was successfully downloaded. then, suddenly, the PPP client lost connection, and I was not able to get it up running again no matter what I did. really weird. I'm going on my christmas holiday tomorrow (sunday) and I really had to have my machine up running as to receive mail when I'm away etc. so I put the backup back in. I'll try again in january, I promise. ;-) merry Xmas, -- Peter Svaar | Phone #: +47 22 69 59 94 peter@svaar.no | Pager #: +47 96 76 83 83 peter@bofh.com | WWW: http://www.svaar.no/ From owner-freebsd-hackers Sat Dec 21 13:00:55 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id NAA29487 for hackers-outgoing; Sat, 21 Dec 1996 13:00:55 -0800 (PST) Received: from sunbeam.csusb.edu (sunbeam.csusb.edu [139.182.10.13]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id NAA29482 for ; Sat, 21 Dec 1996 13:00:52 -0800 (PST) Received: (from rmallory@localhost) by sunbeam.csusb.edu (8.8.4/8.7.3) id NAA06649; Sat, 21 Dec 1996 13:05:20 -0800 (PST) From: Rob Mallory Message-Id: <199612212105.NAA06649@sunbeam.csusb.edu> Subject: Re: 3com 3c589b pcmcia support? To: martin@tdc.on.ca (Martin Renters) Date: Sat, 21 Dec 1996 13:05:20 -0800 (PST) Cc: freebsd-hackers@freefall.freebsd.org In-Reply-To: <199612210328.WAA23404@tdc.on.ca> from "Martin Renters" at Dec 20, 96 10:28:19 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > [..] > ifconfig ep0 192.1.2.3 -link0 -link1 link2 for TP > and ifconfig ep0 192.1.2.3 -link0 link1 -link2 for BNC > > You may also have to play with the IRQ settings in /etc/pccard.conf. > I disabled the Infrared Port on my Toshiba to save an IRQ line. > > Martin > Cool.. Thanks for all the replies! I'll give it a try as soon as I'm back.. I know it'l make a bunch of people happy at Qualcomm, especialy me, as everybody has been asking-- if you get that thing working with freebsd, let me know; I'll convert from linux! hehe.. I'll let you guys know how the new QCP-1900 PCS phones work..Its got a built in PPP stack, anda you just plug in a dongle to the phone and laptop, and you can surf the net from the beach!! ...They wont be out for a while,, details later...outa batteries.. -cya! Rob [rmallory@Qualcomm.com] From owner-freebsd-hackers Sat Dec 21 13:36:16 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id NAA02698 for hackers-outgoing; Sat, 21 Dec 1996 13:36:16 -0800 (PST) Received: from server.zsb.th-darmstadt.de (server.zsb.th-darmstadt.de [130.83.63.190]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id NAA02688; Sat, 21 Dec 1996 13:36:07 -0800 (PST) Received: from localhost (petzi@localhost) by server.zsb.th-darmstadt.de (8.8.2/8.8.2) with SMTP id WAA01456; Sat, 21 Dec 1996 22:35:36 +0100 (MET) Date: Sat, 21 Dec 1996 22:35:35 +0100 (MET) From: Michael Beckmann X-Sender: petzi@server.zsb.th-darmstadt.de To: Joerg Wunsch cc: isp@freebsd.org, hackers@freebsd.org Subject: Re: innd can't remalloc In-Reply-To: <199612201742.SAA04883@uriah.heep.sax.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Fri, 20 Dec 1996, J Wunsch wrote: > datasize 131072 kbytes > ^^^^^^^^^^^^^ > You can override this using: > > options "MAXDSIZ='(256UL*1024*1024)'" > > (For 2.2 systems, leave out the '' quotes. Should be converted to an > official option.) It works !! Thank you. Next thing I'm going to upgrade to FreeBSD 2.2, to get the better malloc and some other enhancements from it. The innd doesn't have to be that large. I tried linking my inn with -lgnumalloc , but it was a desaster. Ever seen a sysload of 20 on a FreeBSD box ? I couldn't believe my eyes. 2.2-ALPHA performs very well on my other newsserver, no crashes or problems since I installed it three weeks ago. Cheers, Michael From owner-freebsd-hackers Sat Dec 21 14:04:33 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id OAA03773 for hackers-outgoing; Sat, 21 Dec 1996 14:04:33 -0800 (PST) Received: from hub.org (root@hub.org [207.107.138.200]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id OAA03755 for ; Sat, 21 Dec 1996 14:04:29 -0800 (PST) Received: from thelab.hub.org (thelab.hub.org [207.107.138.221]) by hub.org (8.8.2/8.7.5) with SMTP id RAA24234 for ; Sat, 21 Dec 1996 17:04:35 -0500 (EST) Date: Sat, 21 Dec 1996 17:04:23 -0500 (EST) From: "Marc G. Fournier" To: hackers@freebsd.org Subject: Bug using MMAP'd region, or misunderstanding Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi... I've finally gotten it to the point where I *think* I understand what I'm doing with mmap'd regions, but have now hit a bug that I don't understand. I've got a 'server' that is setting up a mmap region as follows: ----------- if((fd = open("/tmp/video", O_RDWR|O_CREAT, 0666)) < 0) { fprintf(stderr, "cannot open /tmp/video\n"); exit(-1); } vspace = sizeof(int) + ((sizeof(int) + FRAMESIZE) * FRAMES); ftruncate(fd, vspace); if((video = mmap(0, vspace, PROT_READ|PROT_WRITE, MAP_SHARED, fd, 0)) == (caddr_t) -1) { fprintf(stderr, "cannot mmap video buffer\n"); exit(-1); } close(fd); currframe = video; video += sizeof(int); for(ii = 0; ii < FRAMES; ii++) { framesize[ii] = video; video += sizeof(int); } for(ii = 0; ii < FRAMES; ii++) { frame[ii] = video; video += FRAMESIZE; } --------- Simple enough. The client end looks similar, with: --------- if((fd = open("/tmp/video", O_RDONLY)) < 0) { fprintf(stderr, "cannot open /tmp/video\n"); exit(-1); } fstat(fd, &statbuf); if((video = mmap(0, statbuf.st_size, PROT_READ, MAP_SHARED, fd, 0)) == (caddr_t) -1) { fprintf(stderr, "cannot mmap video buffer\n"); exit(-1); } close(fd); currframe = video; video += sizeof(int); for(ii = 0; ii < FRAMES; ii++) { framesize[ii] = video; video += sizeof(int); } for(ii = 0; ii < FRAMES; ii++) { frame[ii] = video; video += FRAMESIZE; } ------- And that's just about where the similarities end right now. currframe and frame[ii] are getting what I believe to be correct values, but framesize[ii] isn't... I'm writting to framesize[ii], in the server, as: ----- sprintf(framesize[ii], "%d", datasize); printf("wrote framesize of %d\n", atoi(framesize[ii])); ----- And the value of atoi(framesize[ii]) is as expected (around 1100bytes), but when the client reads that same location, with the same atoi(): ----- fsize = atoi(framesize[ii]); fprintf(stderr, "frame == %d, currpos == %d, size == %d\n", mmap_pos, currpos, fsize); ----- I'm getting results that look like: ----- frame == 58, currpos == 58, size == 28272847 ----- So, I figure that is something I'm missing(misunderstanding) about mmap, because I would have thought my 'atoi()' test in the server would yeild the same results as the atoi() test in the client, since they are reading the same memory buffer...no? Any comments on what I should be looking at/for? Is there a more correct way of doing the 'sprintf()' above that I should be using? Again, if it was totally incorrect, I would have assumed that the atoi() test in the server would fail too :( Still fighting with the problem, but any suggestions/ideas are most welcome... Thanks in advance... From owner-freebsd-hackers Sat Dec 21 14:13:32 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id OAA04214 for hackers-outgoing; Sat, 21 Dec 1996 14:13:32 -0800 (PST) Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id OAA04191; Sat, 21 Dec 1996 14:13:20 -0800 (PST) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id XAA15625; Sat, 21 Dec 1996 23:13:16 +0100 Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id XAA13880; Sat, 21 Dec 1996 23:13:16 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.8.4/8.6.9) id WAA13620; Sat, 21 Dec 1996 22:56:40 +0100 (MET) From: J Wunsch Message-Id: <199612212156.WAA13620@uriah.heep.sax.de> Subject: Re: innd can't remalloc To: isp@freebsd.org, hackers@freebsd.org Date: Sat, 21 Dec 1996 22:56:40 +0100 (MET) Cc: petzi@apfel.de (Michael Beckmann) Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: from Michael Beckmann at "Dec 21, 96 10:35:35 pm" 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 X-Mailer: ELM [version 2.4ME+ PL17 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk As Michael Beckmann wrote: > Next thing I'm going to upgrade to FreeBSD 2.2, to get the better malloc > and some other enhancements from it. The innd doesn't have to be that > large. I tried linking my inn with -lgnumalloc , but it was a desaster. If the malloc is all you want, you only need to copy over /usr/src/lib/libc/stdlib/malloc.{3,c} from -current. Rebuild your shared libc, and see whether it helped your 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-hackers Sat Dec 21 14:40:02 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id OAA05314 for hackers-outgoing; Sat, 21 Dec 1996 14:40:02 -0800 (PST) Received: from hub.org (root@hub.org [207.107.138.200]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id OAA05276 for ; Sat, 21 Dec 1996 14:39:59 -0800 (PST) Received: from thelab.hub.org (thelab.hub.org [207.107.138.221]) by hub.org (8.8.2/8.7.5) with SMTP id RAA27305; Sat, 21 Dec 1996 17:38:46 -0500 (EST) Date: Sat, 21 Dec 1996 17:38:34 -0500 (EST) From: "Marc G. Fournier" To: "Jordan K. Hubbard" cc: Luigi Rizzo , hackers@freebsd.org Subject: Re: Posting to multiple lists In-Reply-To: <26830.851197722@time.cdrom.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Sat, 21 Dec 1996, Jordan K. Hubbard wrote: > > I fully second your reply. However, if it is really possible to do > > what the poster says (configure majordomo not to send duplicate > > emails for different mail lists) that is something that would be > > useful anyways. > > I'm not sure how it could, unless it always just chose the first > mailing list as the "target" and then somehow registered this fact > so that a reject would occur for any other mailing lists the user > tried to post it to. > Somewhat related, but from an 'end-user' viewpoint, I was finding it annoying to receiving the same email in several 'filtered' mailboxes because of cross posting. Using procmail to do the filtering, if anyone wants to get around this, try at the top of your .procmailrc: ---- DAYFOLDER=`date +%y%m%d` # this will prevent 'crossposted' messages from getting duplicated :0 Whc: msgid.lock | formail -D 8192 msgid.cache # this will backup the duplicates incase the above didn't work :0 a: $MAILDIR/duplicates/$DAYFOLDER # save a copy of everything, just in case :0 c $MAILDIR/backup/$DAYFOLDER ---- The backups are pure paranoia, and have never had to make use of them...YMMV... Not related to Majordomo, but might help some out there to at least control this on their end... From owner-freebsd-hackers Sat Dec 21 14:45:17 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id OAA05572 for hackers-outgoing; Sat, 21 Dec 1996 14:45:17 -0800 (PST) Received: from rocky.mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id OAA05550; Sat, 21 Dec 1996 14:45:13 -0800 (PST) Received: (from nate@localhost) by rocky.mt.sri.com (8.7.5/8.7.3) id PAA28229; Sat, 21 Dec 1996 15:44:52 -0700 (MST) Date: Sat, 21 Dec 1996 15:44:52 -0700 (MST) Message-Id: <199612212244.PAA28229@rocky.mt.sri.com> From: Nate Williams To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) Cc: isp@freebsd.org, hackers@freebsd.org, petzi@apfel.de (Michael Beckmann) Subject: Re: innd can't remalloc In-Reply-To: <199612212156.WAA13620@uriah.heep.sax.de> References: <199612212156.WAA13620@uriah.heep.sax.de> Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > Next thing I'm going to upgrade to FreeBSD 2.2, to get the better malloc > > and some other enhancements from it. The innd doesn't have to be that > > large. I tried linking my inn with -lgnumalloc , but it was a desaster. > > If the malloc is all you want, you only need to copy over > /usr/src/lib/libc/stdlib/malloc.{3,c} from -current. Rebuild > your shared libc, and see whether it helped your problem. Actually, you can't use the malloc in -current in 2.1.* since it now uses some features that only exist in -current. I had to grab the pre phk/3 version which works great on my -stable systems. Nate From owner-freebsd-hackers Sat Dec 21 14:46:54 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id OAA05672 for hackers-outgoing; Sat, 21 Dec 1996 14:46:54 -0800 (PST) Received: from Mail.IDT.NET (mail.idt.net [198.4.75.205]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id OAA05664 for ; Sat, 21 Dec 1996 14:46:52 -0800 (PST) Received: from sequoia (ppp-47.ts-1.mlb.idt.net [169.132.71.47]) by Mail.IDT.NET (8.8.4/8.7.3) with SMTP id RAA19098 for ; Sat, 21 Dec 1996 17:46:49 -0500 (EST) Message-ID: <32BC6919.9EA@mail.idt.net> Date: Sat, 21 Dec 1996 17:47:53 -0500 From: Gary Corcoran Reply-To: garycorc@mail.idt.net X-Mailer: Mozilla 3.0 (WinNT; U) MIME-Version: 1.0 To: hackers@freebsd.org Subject: Re: Posting to multiple lists References: <26830.851197722@time.cdrom.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Jordan K. Hubbard wrote: > > > I fully second your reply. However, if it is really possible to do > > what the poster says (configure majordomo not to send duplicate > > emails for different mail lists) that is something that would be > > useful anyways. > > I'm not sure how it could, unless it always just chose the first > mailing list as the "target" and then somehow registered this fact > so that a reject would occur for any other mailing lists the user > tried to post it to. > I don't know if it's _practical_ to do this, but sure, send it to the first mailing list a recipient is on. Then, when traversing through the next mail list, if a particular recipient has already been "tagged", don't send another copy of the email. This *would* be a useful feature, both for the poster of the mail (who isn't sure which list should get the mail, or who thinks it may legitimately cover several lists), and obviously for the subscribers, who won't get the emailboxes clogged with duplicates... [sorry, I don't know Perl, which I believe majordomo is written in?] Gary From owner-freebsd-hackers Sat Dec 21 15:32:35 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id PAA07856 for hackers-outgoing; Sat, 21 Dec 1996 15:32:35 -0800 (PST) Received: (from jmb@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id PAA07849; Sat, 21 Dec 1996 15:32:32 -0800 (PST) From: "Jonathan M. Bresler" Message-Id: <199612212332.PAA07849@freefall.freebsd.org> Subject: Re: Posting to multiple lists To: garycorc@mail.idt.net Date: Sat, 21 Dec 1996 15:32:32 -0800 (PST) Cc: hackers@freebsd.org In-Reply-To: <32BC6919.9EA@mail.idt.net> from "Gary Corcoran" at Dec 21, 96 05:47:53 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Gary Corcoran wrote: > > Jordan K. Hubbard wrote: > > > > > I fully second your reply. However, if it is really possible to do > > > what the poster says (configure majordomo not to send duplicate > > > emails for different mail lists) that is something that would be > > > useful anyways. > > > > I'm not sure how it could, unless it always just chose the first > > mailing list as the "target" and then somehow registered this fact > > so that a reject would occur for any other mailing lists the user > > tried to post it to. > > > > I don't know if it's _practical_ to do this, but sure, send it to > the first mailing list a recipient is on. Then, when traversing > through the next mail list, if a particular recipient has already > been "tagged", don't send another copy of the email. > This *would* be a useful feature, both for the poster of the mail > (who isn't sure which list should get the mail, or who thinks it > may legitimately cover several lists), and obviously for the > subscribers, who won't get the emailboxes clogged with duplicates... > [sorry, I don't know Perl, which I believe majordomo is written in?] sendmail expands the mail aliases, such as freebsd-hackers and freebsd-questions, not majordomo. by the time the "message" reaches majordomo (actually the resend perl program of majordomo) it is already 2 or more separate, distinct messages. one might do this by having resend note the Message-id: header in a random access data structure stored on disk. entries would be purged after 24 hours, for example. or one could configure a Message-id: server process that each invokation of resend could query. the resultwould determine whether or not the message was killed. the correct solution is not a technical one but rather a human one. trim the cc: list. the original sender may well be in the dark as to which list to send his question to. the responders should be better informed and trim the cc: list accordingly. (this is my opinion, for what it is worth) jmb -- Jonathan M. Bresler FreeBSD Postmaster jmb@FreeBSD.ORG FreeBSD--4.4BSD Unix for PC clones, source included. http://www.freebsd.org/ PGP 2.6.2 Fingerprint: 31 57 41 56 06 C1 40 13 C5 1C E3 E5 DC 62 0E FB From owner-freebsd-hackers Sat Dec 21 16:13:04 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id QAA09388 for hackers-outgoing; Sat, 21 Dec 1996 16:13:04 -0800 (PST) Received: from po2.glue.umd.edu (root@po2.glue.umd.edu [129.2.128.45]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id QAA09382 for ; Sat, 21 Dec 1996 16:13:01 -0800 (PST) Received: from packet.eng.umd.edu (packet.eng.umd.edu [129.2.98.184]) by po2.glue.umd.edu (8.8.3/8.7.3) with ESMTP id TAA15303; Sat, 21 Dec 1996 19:12:58 -0500 (EST) Received: from localhost (chuckr@localhost) by packet.eng.umd.edu (8.8.3/8.7.3) with SMTP id TAA24260; Sat, 21 Dec 1996 19:12:58 -0500 (EST) X-Authentication-Warning: packet.eng.umd.edu: chuckr owned process doing -bs Date: Sat, 21 Dec 1996 19:12:57 -0500 (EST) From: Chuck Robey X-Sender: chuckr@packet.eng.umd.edu To: "Jonathan M. Bresler" cc: garycorc@mail.idt.net, hackers@FreeBSD.ORG Subject: Re: Posting to multiple lists In-Reply-To: <199612212332.PAA07849@freefall.freebsd.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Sat, 21 Dec 1996, Jonathan M. Bresler wrote: > sendmail expands the mail aliases, such as freebsd-hackers and > freebsd-questions, not majordomo. by the time the "message" > reaches majordomo (actually the resend perl program of majordomo) > it is already 2 or more separate, distinct messages. John, would it be possible to ask sendmail to reject any message (with some kindly worded reminder) that is addressed to multiple majordomo targets? Simply reject it out of hand, so if multiple copies get to freebsd.org (with loaded cc lists) majordomo wouldn't have to handle it? If something like that had existed, I would have been stopped from replying to the multiple post (which I admit, I didn't actually even notice the cc list). > > one might do this by having resend note the Message-id: header > in a random access data structure stored on disk. entries > would be purged after 24 hours, for example. or one could > configure a Message-id: server process that each invokation > of resend could query. the resultwould determine whether or > not the message was killed. > > the correct solution is not a technical one but rather a > human one. trim the cc: list. the original sender may well > be in the dark as to which list to send his question to. > the responders should be better informed and trim the cc: > list accordingly. (this is my opinion, for what it is worth) ----------------------------+----------------------------------------------- Chuck Robey | Interests include any kind of voice or data chuckr@eng.umd.edu | communications topic, C programming, and Unix. 9120 Edmonston Ct #302 | Greenbelt, MD 20770 | I run Journey2 and picnic, both FreeBSD (301) 220-2114 | version 3.0 current -- and great FUN! ----------------------------+----------------------------------------------- From owner-freebsd-hackers Sat Dec 21 16:28:40 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id QAA09880 for hackers-outgoing; Sat, 21 Dec 1996 16:28:40 -0800 (PST) Received: from mexico.brainstorm.eu.org (root@mexico.brainstorm.fr [193.56.58.253]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id QAA09874 for ; Sat, 21 Dec 1996 16:28:36 -0800 (PST) Received: from brasil.brainstorm.eu.org (brasil.brainstorm.fr [193.56.58.33]) by mexico.brainstorm.eu.org (8.7.5/8.7.3) with ESMTP id BAA17676 for ; Sun, 22 Dec 1996 01:28:24 +0100 Received: (from uucp@localhost) by brasil.brainstorm.eu.org (8.6.12/8.6.12) with UUCP id BAA05133 for hackers@freebsd.org; Sun, 22 Dec 1996 01:28:01 +0100 Received: (from roberto@localhost) by keltia.freenix.fr (8.8.4/keltia-uucp-2.9) id BAA16839; Sun, 22 Dec 1996 01:25:03 +0100 (CET) Message-ID: Date: Sun, 22 Dec 1996 01:25:03 +0100 From: roberto@keltia.freenix.fr (Ollivier Robert) To: hackers@freebsd.org Subject: Re: innd can't remalloc References: <199612201742.SAA04883@uriah.heep.sax.de> X-Mailer: Mutt 0.54 Mime-Version: 1.0 X-Operating-System: FreeBSD 3.0-CURRENT ctm#2837 In-Reply-To: ; from Michael Beckmann on Dec 21, 1996 22:35:35 +0100 Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk According to Michael Beckmann: > large. I tried linking my inn with -lgnumalloc , but it was a desaster. > Ever seen a sysload of 20 on a FreeBSD box ? I couldn't believe my eyes. Only 20 ? A 2.1.5 with more than 170 sendmail will be at 40... (seen on one of my machines receiving mail report from 5 SPAM cancelbots during an heavy binaries storm in several groups including control itself) :-) The machine was unusable with only 16 MB RAM and 128 MB swap (almost full). While I'm at this, is there a known problem with either pppd or the vn swap files in 2.1.5 ? We've stopped using both for a while and the machine hasn't crahsed yet... -- Ollivier ROBERT -=- The daemon is FREE! -=- roberto@keltia.freenix.fr FreeBSD keltia.freenix.fr 3.0-CURRENT #33: Sat Dec 21 12:57:17 CET 1996 From owner-freebsd-hackers Sat Dec 21 17:28:15 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id RAA12183 for hackers-outgoing; Sat, 21 Dec 1996 17:28:15 -0800 (PST) Received: from hub.org (root@hub.org [207.107.138.200]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id RAA12178 for ; Sat, 21 Dec 1996 17:28:11 -0800 (PST) Received: from thelab.hub.org (thelab.hub.org [207.107.138.221]) by hub.org (8.8.2/8.7.5) with SMTP id UAA10037 for ; Sat, 21 Dec 1996 20:28:17 -0500 (EST) Date: Sat, 21 Dec 1996 20:28:00 -0500 (EST) From: "Marc G. Fournier" To: hackers@freebsd.org Subject: MMAP() problem partially solved... Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi... First off, I've sort of found the problem I was having with storing and recovering the 'int' value from the mmap()'d region... Since I was doing 'sprintf(mem_loc, "%d", value);', I was attempting to store a 5byte char into a 4byte region, so memory overruns. I've changed things so that I'm allocating 10bytes of space instead of 'sizeof(int)' to get around that.. Still curious as to whether there is something better I should be using, mind you...something like 'mem_loc = (char *)&size;'? Oh well...back to the code...sorry for the disruption... From owner-freebsd-hackers Sat Dec 21 17:31:06 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id RAA12357 for hackers-outgoing; Sat, 21 Dec 1996 17:31:06 -0800 (PST) Received: (from jmb@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id RAA12350; Sat, 21 Dec 1996 17:31:00 -0800 (PST) From: "Jonathan M. Bresler" Message-Id: <199612220131.RAA12350@freefall.freebsd.org> Subject: Re: Posting to multiple lists To: chuckr@glue.umd.edu (Chuck Robey) Date: Sat, 21 Dec 1996 17:31:00 -0800 (PST) Cc: garycorc@mail.idt.net, hackers@FreeBSD.ORG In-Reply-To: from "Chuck Robey" at Dec 21, 96 07:12:57 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Chuck Robey wrote: > > John, would it be possible to ask sendmail to reject any message (with > some kindly worded reminder) that is addressed to multiple majordomo > targets? Simply reject it out of hand, so if multiple copies get to > freebsd.org (with loaded cc lists) majordomo wouldn't have to handle it? > > If something like that had existed, I would have been stopped from > replying to the multiple post (which I admit, I didn't actually even > notice the cc list). the problem occurs fairly infrequently. we have all done it at one time or another. accidents happens (to parapharse the bumper stickers). so long as no one persists obstinately in posting to several lists we are okay. for the obstinate, we have a kill filter. i dont believe that the problem is technical. a technical solution is not appropriate. people reading playboy.com during work is not a technical problem. there is a role for management afterall ;) > > On Sat, 21 Dec 1996, Jonathan M. Bresler wrote: > > > > one might do this by having resend note the Message-id: header > > in a random access data structure stored on disk. entries > > would be purged after 24 hours, for example. or one could > > configure a Message-id: server process that each invokation > > of resend could query. the resultwould determine whether or > > not the message was killed. > > > > the correct solution is not a technical one but rather a > > human one. trim the cc: list. the original sender may well > > be in the dark as to which list to send his question to. > > the responders should be better informed and trim the cc: > > list accordingly. (this is my opinion, for what it is worth) jmb From owner-freebsd-hackers Sat Dec 21 17:40:16 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id RAA12637 for hackers-outgoing; Sat, 21 Dec 1996 17:40:16 -0800 (PST) Received: from scanner.worldgate.com (scanner.worldgate.com [198.161.84.3]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id RAA12632 for ; Sat, 21 Dec 1996 17:40:13 -0800 (PST) Received: from znep.com (uucp@localhost) by scanner.worldgate.com (8.7.5/8.7.3) with UUCP id SAA02152; Sat, 21 Dec 1996 18:40:11 -0700 (MST) Received: from localhost (marcs@localhost) by alive.ampr.ab.ca (8.7.5/8.7.3) with SMTP id SAA08684; Sat, 21 Dec 1996 18:40:03 -0700 (MST) Date: Sat, 21 Dec 1996 18:40:02 -0700 (MST) From: Marc Slemko X-Sender: marcs@alive.ampr.ab.ca To: Bill Fenner cc: hackers@freebsd.org Subject: Re: TCP FIN/ACK storm oddity In-Reply-To: <96Dec15.223727pst.177711@crevenia.parc.xerox.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Sun, 15 Dec 1996, Bill Fenner wrote: > Sounds like what Peter Wemm saw in PR kern/1940. Hmm. Perhaps related somehow. > > Can you replicate the exchange from the second message, but use "tcpdump -S" > so that tcpdump doesn't try to be smart about the sequence numbers? A > "tcpdump -w" might be even better. > > Bill > The same exchange as in my previous message, but with -S: 03:49:01.543188 futurity.worldgate.com.telnet > darkly.worldgate.com.1701: F 541865:541865(0) ack 1325056048 win 2048 03:49:01.543392 darkly.worldgate.com.1701 > futurity.worldgate.com.telnet: F 1325056048:1325056048(0) ack 541866 win 17153 (DF) [tos 0x10] 03:49:01.544394 futurity.worldgate.com.telnet > darkly.worldgate.com.1701: . ack 1325056048 win 2048 03:49:01.544596 darkly.worldgate.com.1701 > futurity.worldgate.com.telnet: F 1325056048:1325056048(0) ack 541866 win 17153 (DF) [tos 0x10] 03:49:01.545666 futurity.worldgate.com.telnet > darkly.worldgate.com.1701: . ack 1325056048 win 2048 03:49:01.545877 darkly.worldgate.com.1701 > futurity.worldgate.com.telnet: F 1325056048:1325056048(0) ack 541866 win 17153 (DF) [tos 0x10] 03:49:01.547046 futurity.worldgate.com.telnet > darkly.worldgate.com.1701: . ack 1325056048 win 2048 When I try the same thing between a box running Solaris 2.5 and the Ascend, I get a somewhat similar situation except that the packets are _far_ less frequent. The test with Solaris was over a link with a much higher RTT (~90ms) which may or may not account for the difference. I let the Solaris box and the Ascend go on talking for days, and it simply wouldn't stop on its own. The raw log of the connection shown above was written to disk with -w, which is where I generated the above output from. I can make the raw log (~15 megs) available to anyone who wants to take a look. I am hoping to get the time to go through the connection step by step and state by state within the next few weeks. From owner-freebsd-hackers Sat Dec 21 19:14:44 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id TAA15571 for hackers-outgoing; Sat, 21 Dec 1996 19:14:44 -0800 (PST) Received: from root.com (implode.root.com [198.145.90.17]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id TAA15566 for ; Sat, 21 Dec 1996 19:14:41 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by root.com (8.7.6/8.6.5) with SMTP id TAA21865; Sat, 21 Dec 1996 19:13:47 -0800 (PST) Message-Id: <199612220313.TAA21865@root.com> X-Authentication-Warning: implode.root.com: Host localhost [127.0.0.1] didn't use HELO protocol To: roberto@keltia.freenix.fr (Ollivier Robert) cc: hackers@freebsd.org Subject: Re: innd can't remalloc In-reply-to: Your message of "Sun, 22 Dec 1996 01:25:03 +0100." From: David Greenman Reply-To: dg@root.com Date: Sat, 21 Dec 1996 19:13:47 -0800 Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >While I'm at this, is there a known problem with either pppd or the vn swap >files in 2.1.5 ? We've stopped using both for a while and the machine >hasn't crahsed yet... There is a very good chance that there are problems with both, but you should definately avoid the VN device in 2.1.x if at all possible, especially if it will be used as a swap device (hint: this isn't the first report of problems with it). -DG David Greenman Core-team/Principal Architect, The FreeBSD Project From owner-freebsd-hackers Sat Dec 21 20:34:58 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id UAA18137 for hackers-outgoing; Sat, 21 Dec 1996 20:34:58 -0800 (PST) Received: from nexgen.HiWAAY.net (max2-129.HiWAAY.net [208.147.145.129]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id UAA18131 for ; Sat, 21 Dec 1996 20:34:53 -0800 (PST) Received: from nexgen.HiWAAY.net (localhost [127.0.0.1]) by nexgen.HiWAAY.net (8.7.6/8.7.3) with ESMTP id WAA24254; Sat, 21 Dec 1996 22:19:17 -0600 (CST) Message-Id: <199612220419.WAA24254@nexgen.HiWAAY.net> X-Mailer: exmh version 1.6.9 8/22/96 To: "Marc G. Fournier" cc: "Jordan K. Hubbard" , hackers@FreeBSD.ORG From: dkelly@hiwaay.net Subject: Re: Posting to multiple lists In-reply-to: Message from "Marc G. Fournier" of "Sat, 21 Dec 1996 17:38:34 EST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 21 Dec 1996 22:19:17 -0600 Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk "Marc G. Fournier" wrote: > > Somewhat related, but from an 'end-user' viewpoint, I was finding > it annoying to receiving the same email in several 'filtered' mailboxes > because of cross posting. Using procmail to do the filtering, if anyone > wants to get around this, try at the top of your .procmailrc: One day I'll figure out why the gurus seem to prefer procmail over slocal. Meanwhile I managed to figure out slocal and .maildelivery before procmail and .procmailrc. A problem I have found with slocal is that it apparently does not lock files it writes to. Use fetchmail to download 100 messages via 28.8k PPP and some .mh_sequences files are liely to get whacko. Doesn't seem to be a problem if popclient is used, but I'm aware the potential is there. Maybe I've answered my own question? Asked a couple of weeks ago my slocal was not using its database to filter out duplicate messages. Tonight this thread prompted me to revisit the issue. "man slocal" says: Duplicate Message Suppression slocal is able to detect and supress duplicate messages. To enable this, create two empty files in your $HOME directory: .maildelivery.pag and .maildelivery.dir. These are ndbm files which are used to store the Message-IDs of incoming messages. nexgen: {1027} cd /usr/local/lib/mh nexgen: {1028} strings slocal | grep maildelivery maildelivery file only one maildelivery file at a time! .maildelivery.db .maildelivery /usr/local/lib/mh/maildelivery maildelivery _maildelivery Ok, now I get it, we use a different db than the man page writer. Checked the ports patches and found it there too. System is 2.1.6R. Appears to need a little man page patch. Tried "touch ~/.maildelivery.db", sent a message to myself, and found the .db file had grown. -- 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-hackers Sat Dec 21 21:01:20 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id VAA19102 for hackers-outgoing; Sat, 21 Dec 1996 21:01:20 -0800 (PST) Received: from rocky.mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id VAA19097 for ; Sat, 21 Dec 1996 21:01:17 -0800 (PST) Received: (from nate@localhost) by rocky.mt.sri.com (8.7.5/8.7.3) id WAA29311; Sat, 21 Dec 1996 22:01:01 -0700 (MST) Date: Sat, 21 Dec 1996 22:01:01 -0700 (MST) Message-Id: <199612220501.WAA29311@rocky.mt.sri.com> From: Nate Williams To: roberto@keltia.freenix.fr (Ollivier Robert) Cc: hackers@freebsd.org Subject: Re: innd can't remalloc In-Reply-To: References: <199612201742.SAA04883@uriah.heep.sax.de> Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > While I'm at this, is there a known problem with either pppd or the vn swap > files in 2.1.5 ? We've stopped using both for a while and the machine > hasn't crahsed yet... I ran our dedicated PPP link over the internet using 2.1.5 for months with an uptime of 160+ days using pppd. We recently upgraded to Frame Relay and 2.1.6.1, but I never had any problems with kernel pppd. Nate From owner-freebsd-hackers Sat Dec 21 21:11:50 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id VAA19490 for hackers-outgoing; Sat, 21 Dec 1996 21:11:50 -0800 (PST) Received: from rocky.mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id VAA19485 for ; Sat, 21 Dec 1996 21:11:47 -0800 (PST) Received: (from nate@localhost) by rocky.mt.sri.com (8.7.5/8.7.3) id WAA29323; Sat, 21 Dec 1996 22:11:43 -0700 (MST) Date: Sat, 21 Dec 1996 22:11:43 -0700 (MST) Message-Id: <199612220511.WAA29323@rocky.mt.sri.com> From: Nate Williams To: dkelly@hiwaay.net Cc: hackers@freebsd.org Subject: Re: Posting to multiple lists In-Reply-To: <199612220419.WAA24254@nexgen.HiWAAY.net> References: <199612220419.WAA24254@nexgen.HiWAAY.net> Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk [ Note the little key named the 'return' key. It provides very useful functionality. ] > > Somewhat related, but from an 'end-user' viewpoint, I was finding > > it annoying to receiving the same email in several 'filtered' mailboxes > > because of cross posting. Using procmail to do the filtering, if anyone > > wants to get around this, try at the top of your .procmailrc: > > One day I'll figure out why the gurus seem to prefer procmail over > slocal. I started using procmail a *long* time ago, and I've never heard of slocal (unless that's the filter program in ELM). I started using it because it got glowing reviews and guaranteed to do the correct sort of locking (via it's configuration test) so that it was using the same sort of locking the local mail program was using *AND* that it tested to make sure it worked. > Meanwhile I managed to figure out slocal and .maildelivery > before procmail and .procmailrc. A problem I have found with slocal is > that it apparently does not lock files it writes to. That's why *I* use procmail. It simply works. > Use fetchmail to > download 100 messages via 28.8k PPP and some .mh_sequences files are > liely to get whacko. Doesn't seem to be a problem if popclient is > used, but I'm aware the potential is there. Maybe I've answered my own > question? That's because popclient is the only thing writing to the disk, where with fetchmail it uses the local MDA. I prefer using the local MDA (hence the reason I just switched to using fetchmail on my main email box recently). Losing mail is a very bad thing, and completely unacceptable to me. If I lose some FreeBSD email it's OK, but it's possible that I may lose some work related mail if locking isn't setup correctly, and that's unacceptable. To the best of my ability, I've *never* lost any email due to .procmail that wasn't my own fault. The only time I've lost email in the last 3-4 years is when I filled up my hard-disk, and no piece of software (except rm) can fix that. I've been using procmail for at least 3 years and it has *always* worked. However, Jordan has never gotten it working so I don't know what's different between his setup and mine. Nate From owner-freebsd-hackers Sat Dec 21 21:43:53 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id VAA20304 for hackers-outgoing; Sat, 21 Dec 1996 21:43:53 -0800 (PST) Received: from rover.village.org (rover.village.org [204.144.255.49]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id VAA20299 for ; Sat, 21 Dec 1996 21:43:50 -0800 (PST) Received: from rover.village.org [127.0.0.1] by rover.village.org with esmtp (Exim 0.56 #1) id E0vbghC-0000oI-00; Sat, 21 Dec 1996 22:43:34 -0700 To: Nate Williams Subject: Re: Posting to multiple lists Cc: dkelly@hiwaay.net, hackers@freebsd.org In-reply-to: Your message of "Sat, 21 Dec 1996 22:11:43 MST." <199612220511.WAA29323@rocky.mt.sri.com> References: <199612220511.WAA29323@rocky.mt.sri.com> <199612220419.WAA24254@nexgen.HiWAAY.net> Date: Sat, 21 Dec 1996 22:43:34 -0700 From: Warner Losh Message-Id: Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In message <199612220511.WAA29323@rocky.mt.sri.com> Nate Williams writes: : To the best of my ability, I've *never* lost any email due to .procmail : that wasn't my own fault. The only time I've lost email in the last 3-4 : years is when I filled up my hard-disk, and no piece of software (except : rm) can fix that. I've used slocal for about five years now with the same results... It just works. Warner