From owner-freebsd-current Sun Nov 1 00:59:19 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id AAA00523 for freebsd-current-outgoing; Sun, 1 Nov 1998 00:59:19 -0800 (PST) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from allegro.lemis.com (allegro.lemis.com [192.109.197.134]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id AAA00513 for ; Sun, 1 Nov 1998 00:59:16 -0800 (PST) (envelope-from grog@freebie.lemis.com) Received: from freebie.lemis.com (freebie.lemis.com [192.109.197.137]) by allegro.lemis.com (8.9.1/8.9.0) with ESMTP id TAA05952; Sun, 1 Nov 1998 19:29:10 +1030 (CST) Received: (from grog@localhost) by freebie.lemis.com (8.9.1/8.9.0) id TAA19428; Sun, 1 Nov 1998 19:29:08 +1030 (CST) Message-ID: <19981101192908.D19187@freebie.lemis.com> Date: Sun, 1 Nov 1998 19:29:08 +1030 From: Greg Lehey To: "Kenneth D. Merry" , "John W. DeBoskey" Cc: freebsd-current@FreeBSD.ORG Subject: Re: scsi disk (cam?) problems References: <199811010132.UAA04810@bb01f39.unx.sas.com> <199811010208.TAA27408@panzer.plutotech.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91.1i In-Reply-To: <199811010208.TAA27408@panzer.plutotech.com>; from Kenneth D. Merry on Sat, Oct 31, 1998 at 07:08:50PM -0700 WWW-Home-Page: http://www.lemis.com/~grog Organization: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-41-739-7062 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Saturday, 31 October 1998 at 19:08:50 -0700, Kenneth D. Merry wrote: > John W. DeBoskey wrote... >> Hi, >> >> My -CURRENT system has been experiencing problems since I converted >> it to cam awhile back. The following show up on my console, and then >> my disks are useless until I completely shutdown, powerdown my drive >> array, power it back on, and reboot. I have 4 identical drives configured >> as a ccd. They have been serving me well more about a year... >> >> If anyone has any ideas on how I can track down the problem, please >> let me know! >> >> Thanks, >> John >> >> /dev/ccd0a 2155550 1268428 714678 64% /snap >> /dev/ccd0b 2155550 1020154 962952 51% /usr/obj >> /dev/ccd0d 17244630 12876242 2988818 81% /pub >> >> Snipped from messages: (This kernel was built on the 28th), I'm now on >> a kernel built Oct 31. > [ ... ] > >> Oct 30 10:52:35 FreeBSD /kernel: (da2:ahc0:0:3:0): Invalidating pack >> Oct 30 10:52:35 FreeBSD /kernel: (da2:ahc0:0:3:0): Invalidating pack > > Well, what's happening here is that one of your disks is returning an > error, and keeps returning that error. Reads and writes in the da driver > have a retry count of 4. So by the time we print out the message above, > the command has already been retried four times. We may also have taken a > number of error recovery actions to try to bring the device back. > > Because your disk is in a CCD array, though, you won't be able to access > the CCD array when one disk in the array is marked as invalid. > > For some reason, though, the sense information for the error in question > isn't getting printed out. It may be that there's a bug in the sense code > table somewhere. > > How often does this happen? FWIW, I can reproduce this message (and usually lack of sense information) at will by pulling a data connector during a transfer (why? I'm testing Vinum, which *can* recover from this situation :-). Greg -- See complete headers for address, home page and phone numbers finger grog@lemis.com for PGP public key To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Nov 1 01:22:55 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id BAA02957 for freebsd-current-outgoing; Sun, 1 Nov 1998 01:22:55 -0800 (PST) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from zibbi.mikom.csir.co.za (zibbi.mikom.csir.co.za [146.64.24.58]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id BAA02950 for ; Sun, 1 Nov 1998 01:22:52 -0800 (PST) (envelope-from jhay@zibbi.mikom.csir.co.za) Received: (from jhay@localhost) by zibbi.mikom.csir.co.za (8.9.1/8.9.1) id LAA05107; Sun, 1 Nov 1998 11:22:18 +0200 (SAT) From: John Hay Message-Id: <199811010922.LAA05107@zibbi.mikom.csir.co.za> Subject: Re: IPv6 in -current In-Reply-To: <199810301848.NAA04753@khavrinen.lcs.mit.edu> from Garrett Wollman at "Oct 30, 98 01:48:39 pm" To: wollman@khavrinen.lcs.mit.edu (Garrett Wollman) Date: Sun, 1 Nov 1998 11:22:18 +0200 (SAT) Cc: current@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL32 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > >> > * Full IPv6 implementation in-kernel and libc! > >> * Complete single-copy TCP/IP implementation > > > And even better if we could list both. :-) I think the needs of the > > FreeBSD group is diverse enough that this isn't unreasonable. > > The needs are one thing; the capabilities quite another. Well I'm not sure what you mean with this, but if it is lack of manpower to do it, Itojun from the Kame team did say that he would do the integration into FreeBSD and maintain it (and he already is a committer) and someone said that the INRIA guys was also prepared to do it. So it shouldn't take up your or any of the other's (that aren't interested in IPv6 yet) time, except maybe in the beginning to help decide which stack to use and maybe where in the tree to put things or things like that. It's not a question of "if we are going to support IPv6", but "when are we going to support IPv6"... except if we are going to obsolete ourselves. And at the pace some of our things take, I think the sooner we do it, the better, because then we do get more time to integrate everything, like adding support for IPv6 to the rest of our code like ipfw and ipfilter. But I give up for now and will try again in a few months time, although I expect that we will see a IPv6 stack committed in the middle of one of out BETA cycles in the future. :-) John -- John Hay -- John.Hay@mikom.csir.co.za To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Nov 1 01:34:52 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id BAA03804 for freebsd-current-outgoing; Sun, 1 Nov 1998 01:34:52 -0800 (PST) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from marvin.spacequest.hs (in17.fto.de [193.197.153.146]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id BAA03798 for ; Sun, 1 Nov 1998 01:34:49 -0800 (PST) (envelope-from hschaefer@fto.de) Received: from daneel.spacequest.hs (daneel.spacequest.hs [192.168.0.98]) by marvin.spacequest.hs (8.8.8/8.8.7) with ESMTP id VAA25122; Sat, 31 Oct 1998 21:40:48 +0100 (CET) (envelope-from hschaefer@fto.de) Date: Sat, 31 Oct 1998 21:39:38 +0100 (CET) From: Heiko Schaefer X-Sender: heiko@daneel.spacequest.hs To: Heiko Schaefer cc: freebsd-current@FreeBSD.ORG Subject: Re: Problem with SCSI Harddisk In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi FreeBSD-current comunity again, as no one answered to my question (that i posted here a week ago), i figured out that either this is the wrong place to ask, or no one found this important or no one had anything to say about it. ...just in case anyone has a similar problem sometime, i wanted to write about what i tried, and how i finally found a 'workaround' to my problem today (though it feels a bit funny replying to one's own mails :)). here's the problem once again: > I am using FreeBSD 3.0-CURRENT (of today), and have a problem with one of > my scsi-harddisks. /var/log/messages says: > > Oct 24 10:00:56 daneel /kernel: (da3:ahc0:0:3:0): SCB 0xe1 - timed out > while idle, LASTPHASE == 0x1, SCSISIGI == 0x0 > Oct 24 10:00:56 daneel /kernel: SEQADDR == 0xb > Oct 24 10:00:56 daneel /kernel: SSTAT1 == 0xa > Oct 24 10:00:56 daneel /kernel: (da3:ahc0:0:3:0): Queuing a BDR SCB > Oct 24 10:00:56 daneel /kernel: (da3:ahc0:0:3:0): Bus Device Reset Message > Sent > Oct 24 10:00:56 daneel /kernel: (da3:ahc0:0:3:0): no longer in timeout, > status = 34b > Oct 24 10:00:56 daneel /kernel: ahc0: Bus Device Reset on A:3. 64 SCBs > aborted > Oct 24 10:00:56 daneel /kernel: (da3:ahc0:0:3:0): tagged openings now 64 > > > this message is then repeated for zillions of times (exactly once every > 60 seconds), once it has occured once (it occurs for the first time, when > the harddisk is used a bit more heavily). eventually the whole system > hangs (responds to ping, but not to telnet or anything similar, although > the filesystem on the harddisk contains no part of the system, just data > of a samba-fileserver). i am now quite sure, that the problem started occuring, when i switched from 2.2-STABLE to 3.0-CURRENT (i.e. from the old scsi driver to cam ?!). the first thing i tried to get rid of the messages (and system hangs), i downgraded my system from 3.0-CURRENT (of about 25.10.98) to 3.0-RELEASE by cvsup'ing and making world and a new kernel, but that did not help. then i decided to use another scsi controller. after replacing the 2940UW (a bit older) with a 2940U (quite new), the problem seems to have disappeard. the problem occured when using this one: > ahc0: rev 0x00 int a irq 10 on pci0.12.0 > ahc0: aic7880 Wide Channel A, SCSI Id=7, 16/255 SCBs (but funnily only with one of my four harddisks - a cheap 5 1/4" seagate 9GB harddisk: da3: ... somehow the 2940UW didn't 'like' this harddisk ?! :> ). the controller that i now use is: ahc0: rev 0x01 int a irq 10 on pci0.12.0 ahc0: aic7860 Single Channel A, SCSI Id=7, 3/255 SCBs maybe this is a known problem ?! if not, is it likely to be a hardware defect of some kind, or is it a bug in freebsd ? am i supposed (would it help) to report this to some developer (or are all developers reading this list ?) have a nice day, Heiko To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Nov 1 02:00:05 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id CAA05924 for freebsd-current-outgoing; Sun, 1 Nov 1998 02:00:05 -0800 (PST) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from fep1-orange.clear.net.nz (fep1-orange.clear.net.nz [203.97.32.1]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id CAA05908 for ; Sun, 1 Nov 1998 02:00:01 -0800 (PST) (envelope-from jabley@buddha.clear.net.nz) Received: from buddha.clear.net.nz (buddha.clear.net.nz [192.168.24.106]) by fep1-orange.clear.net.nz (1.5/1.11) with ESMTP id WAA08030; Sun, 1 Nov 1998 22:59:55 +1300 (NZDT) Received: (from jabley@localhost) by buddha.clear.net.nz (8.9.1/8.9.1) id WAA29924 for freebsd-current@freebsd.org; Sun, 1 Nov 1998 22:59:54 +1300 (NZDT) Message-ID: <19981101225954.A29897@clear.co.nz> Date: Sun, 1 Nov 1998 22:59:54 +1300 From: Joe Abley To: freebsd-current@FreeBSD.ORG Subject: Re: kernel compile problem References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i In-Reply-To: ; from Leif Neland on Sun, Nov 01, 1998 at 07:44:52AM +0100 X-Files: the Truth is Out There Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, Nov 01, 1998 at 07:44:52AM +0100, Leif Neland wrote: > > Is the problem that committing isn't 'atomical'? > > How about if the committer started by committing > /usr/src/DONT_MAKE_WORLD_NOW > then committed various stuff, then removed > /usr/src/DONT_MAKE_WORLD_NOW > This file could contain an explanation why the world shouldn't be made. > > The makefile should then check for the existance of this file. > > This could be implemented right now. It won't require updating cvsup and > cvsupd. > > But this will give problems when several people are updating different > parts of the tree... So we need a semaphore; however, a single lock file with a counter in it doesn't sound very practical for cvsup. How about a directory called "lock" in whatever part of the source tree is appropriate, into which committers deposit a file named with their e-mail address, containing a description of why the source tree is locked? bsd.subdir.mk could check for files within this subdirectory and fail quoting the contents of any files that are present. The same branch of the tree could be locked by more than one committer (since their respective lock files would have different names). Having lock directories at appropriate depths in the source tree would be better than one "don't make world" lock file -- that way if I want to rebuild and reinstall /usr/src/usr.bin/ I won't be affected by a transient commit lock in /usr/src/usr.sbin/ (for example). If no "lock" subdirectory is present, this should be interpreted as "there are no locks for this branch". Just an idea :) Whaddayathink? Joe -- Joe Abley Tel +64 9 912-4065, Fax +64 9 912-5008 Network Architect, CLEAR Net http://www.clear.net.nz/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Nov 1 03:17:12 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id DAA16956 for freebsd-current-outgoing; Sun, 1 Nov 1998 03:17:12 -0800 (PST) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from outmail.utsunomiya-u.ac.jp (outmail.utsunomiya-u.ac.jp [160.12.196.3]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id DAA16932 for ; Sun, 1 Nov 1998 03:16:58 -0800 (PST) (envelope-from yokota@zodiac.mech.utsunomiya-u.ac.jp) Received: from zodiac.mech.utsunomiya-u.ac.jp (IDENT:hzbWdVmtCo2n79KURaAD1jcvc3lmwvry@zodiac.mech.utsunomiya-u.ac.jp [160.12.42.1]) by outmail.utsunomiya-u.ac.jp (8.9.1/8.9.1) with ESMTP id UAA27736; Sun, 1 Nov 1998 20:16:20 +0900 (JST) Received: from zodiac.mech.utsunomiya-u.ac.jp (zodiac.mech.utsunomiya-u.ac.jp [160.12.42.1]) by zodiac.mech.utsunomiya-u.ac.jp (8.7.6+2.6Wbeta7/3.4W/zodiac-May96) with ESMTP id UAA15627; Sun, 1 Nov 1998 20:17:43 +0900 (JST) Message-Id: <199811011117.UAA15627@zodiac.mech.utsunomiya-u.ac.jp> To: Dan Nelson cc: Alfred Perlstein , current@FreeBSD.ORG, Mike Smith , yokota@zodiac.mech.utsunomiya-u.ac.jp Subject: Re: if anyone is interested VESA seems broken. In-reply-to: Your message of "Fri, 30 Oct 1998 15:47:41 CST." <19981030154741.A18571@emsphone.com> References: <19981030154741.A18571@emsphone.com> Date: Sun, 01 Nov 1998 20:17:42 +0900 From: Kazutaka YOKOTA Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >> VESA: mode:0x109, flags:0x000b, T 132x25, font:8x16 >> VESA: window A:0xb800 (7), window B:0x0 (0), size:32k, gran:32k >> VESA: mode:0x10b, flags:0x000b, T 132x50, font:8x8 >> VESA: window A:0xb800 (7), window B:0x0 (0), size:32k, gran:32k >> VESA: mode:0x10c, flags:0x000b, T 132x60, font:8x8 >> VESA: window A:0xb800 (7), window B:0x0 (0), size:32k, gran:32k > >Your card definitely should be able to do 132x50, since it claims to >support it here. Maybe check to see that vidcontrol and syscons.c >handle them correctly (I don't have access to 3.0 at the moment) So long as 132x50 and 132x60 modes are listed in "vidcontrol -i mode" and you have loaded 8x8 font, vidcontrol and syscons should be able to set these modes. Kazu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Nov 1 03:39:19 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id DAA20733 for freebsd-current-outgoing; Sun, 1 Nov 1998 03:39:19 -0800 (PST) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from smtp05.wxs.nl (smtp05.wxs.nl [195.121.6.57]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id DAA20720 for ; Sun, 1 Nov 1998 03:39:08 -0800 (PST) (envelope-from asmodai@wxs.nl) Received: from diabolique.ninth-circle.org ([195.121.59.238]) by smtp05.wxs.nl (Netscape Messaging Server 3.6) with ESMTP id AAA19B9; Sun, 1 Nov 1998 11:39:02 +0100 Message-ID: X-Mailer: XFMail 1.3 [p0] on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <199810311915.DAA21351@spinner.netplex.com.au> Date: Sun, 01 Nov 1998 12:42:52 +0100 (CET) Organization: Ninth Circle Enterprises From: Jeroen Ruigrok/Asmodai To: Peter Wemm Subject: Re: sys/msdosfs problems? Cc: FreeBSD Current Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG OK Peter, no more problems in the msdosfs as far as I am able to determine... so ye can spend more time with yer kid ;) Thanks mate, --- Jeroen Ruigrok van der Werven/Asmodai asmodai(at)wxs.nl Junior Network/Security Specialist FreeBSD & picoBSD: The Power to Serve... To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Nov 1 05:02:20 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id FAA02667 for freebsd-current-outgoing; Sun, 1 Nov 1998 05:02:20 -0800 (PST) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from nomad.dataplex.net (nomad.dataplex.net [208.2.87.8]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id FAA02659 for ; Sun, 1 Nov 1998 05:02:18 -0800 (PST) (envelope-from rkw@nomad.dataplex.net) Received: from localhost (rkw@localhost) by nomad.dataplex.net (8.9.1/8.9.1) with ESMTP id HAA08685; Sun, 1 Nov 1998 07:02:10 -0600 (CST) (envelope-from rkw@nomad.dataplex.net) Date: Sun, 1 Nov 1998 07:02:10 -0600 (CST) From: User RKW To: Joe Abley cc: freebsd-current@FreeBSD.ORG Subject: Re: kernel compile problem In-Reply-To: <19981101225954.A29897@clear.co.nz> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >From the point of view of the users, a locking mechanism along these lines would be fine. However, there are SERIOUS complications relating to the archiving and distribution of the source tree. If the locks are maintained as files in the tree, they would further bloat the already unwieldly tree. I do like the idea of having bsd.subdir.mk recognize parts of the tree to avoid. However, the locks, as described, are likely to get in the way of the developer who is testing his changes in order to decide if he can release the lock. On Sun, 1 Nov 1998, Joe Abley wrote: > On Sun, Nov 01, 1998 at 07:44:52AM +0100, Leif Neland wrote: > > > > Is the problem that committing isn't 'atomical'? Generally, yes. Worse, a commiter sometimes makes faulty updates which, although he thinks that they are complete, are missing something. This may well be the result of differences in his environment and that of someone who is extracting from the master tree. > How about a directory called "lock" in whatever part of the source tree > is appropriate, ".locks" might be more appropriate. > into which committers deposit a file named with their e-mail > address, containing a description of why the source tree is locked? > > bsd.subdir.mk could check for files within this subdirectory and fail > quoting the contents of any files that are present. > > The same branch of the tree could be locked by more than one committer > (since their respective lock files would have different names). > > Having lock directories at appropriate depths in the source tree would > be better than one "don't make world" lock file -- that way if I want > to rebuild and reinstall /usr/src/usr.bin/ I won't be affected by a > transient commit lock in /usr/src/usr.sbin/ (for example). > > If no "lock" subdirectory is present, this should be interpreted as > "there are no locks for this branch". > > Just an idea :) Whaddayathink? Terry (and I) would argue that the committer should not be allowed to remove the lock himself. That privledge/duty would belong to the QA dept whose daemon would make at least some rudimentary checks before pulling the lock. Another approach would be to place the cvsup distribution behind a transaction processor which would serially commit atomic changes. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Nov 1 05:24:30 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id FAA07094 for freebsd-current-outgoing; Sun, 1 Nov 1998 05:24:30 -0800 (PST) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from smtp05.wxs.nl (smtp05.wxs.nl [195.121.6.57]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id FAA07084 for ; Sun, 1 Nov 1998 05:24:27 -0800 (PST) (envelope-from asmodai@wxs.nl) Received: from diabolique.ninth-circle.org ([195.121.58.216]) by smtp05.wxs.nl (Netscape Messaging Server 3.6) with ESMTP id AAA47FA; Sun, 1 Nov 1998 13:24:19 +0100 Message-ID: X-Mailer: XFMail 1.3 [p0] on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <199811010226.SAA24541@austin.polstra.com> Date: Sun, 01 Nov 1998 14:28:09 +0100 (CET) Organization: Ninth Circle Enterprises From: Jeroen Ruigrok/Asmodai To: John Polstra Subject: Re: cvsup .4.2 Cc: current@FreeBSD.ORG Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi John, On 01-Nov-98 John Polstra wrote: > > Please let me know what version of FreeBSD you're running. Also 3.0-CURRENT, cvsupped every day. > please send me the output of: > > ident /usr/include/sys/sem.h [diabolique] asmodai $ ident /usr/include/sys/sem.h /usr/include/sys/sem.h: $Id: sem.h,v 1.15 1998/07/15 02:32:32 bde Exp $ $NetBSD: sem.h,v 1.5 1994/06/29 06:45:15 cgd Exp $ > and > > grep define /usr/include/osreldate.h [diabolique] asmodai $ grep define /usr/include/osreldate.h #define __FreeBSD_version 300006 > Then I can help you fix it. Might also be relevant to my Attic/cvsup make world problems... Gonna do yer suggestion and then try it all again... I'll let ye know. In the mean time: thanks. > PS - CVSup problems really should be reported to . Ah, okies, thanks for telling =) --- Jeroen Ruigrok van der Werven/Asmodai asmodai(at)wxs.nl Junior Network/Security Specialist FreeBSD & picoBSD: The Power to Serve... To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Nov 1 05:24:30 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id FAA07095 for freebsd-current-outgoing; Sun, 1 Nov 1998 05:24:30 -0800 (PST) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from smtp04.wxs.nl (smtp04.wxs.nl [195.121.6.59]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id FAA07079 for ; Sun, 1 Nov 1998 05:24:24 -0800 (PST) (envelope-from asmodai@wxs.nl) Received: from diabolique.ninth-circle.org ([195.121.58.216]) by smtp04.wxs.nl (Netscape Messaging Server 3.6) with ESMTP id AAA4901; Sun, 1 Nov 1998 14:24:16 +0100 Message-ID: X-Mailer: XFMail 1.3 [p0] on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <199810311902.LAA22746@austin.polstra.com> Date: Sun, 01 Nov 1998 14:28:06 +0100 (CET) Organization: Ninth Circle Enterprises From: Jeroen Ruigrok/Asmodai To: John Polstra Subject: Re: Another compile error Cc: current@FreeBSD.ORG Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi John, On 31-Oct-98 John Polstra wrote: > But there shouldn't be any directories in your tree named "Attic", and > there shouldn't be any files named "*,v". I think that at some > point when you were first experimenting with CVSup, you must have > done an update without the "tag=." statement in your supfile. Hmmm... Noting =) > I recommend that you do this to clean it up: > > cd /src > find . \( -name '*,v' -o -name .depend -o -type l \) -print | xargs rm -f I went from 78% capacity to 33% on my 1 GB slice for cvsup ;) > find -d . -name Attic | xargs rm -rf that also cleaned some stuff... > cd /usr/obj > rm -rf * # (You will get some error messages -- don't worry Jups, with the libs... > chflags -R 0 * > rm -rf * # (Yes, again) to get rid of the last remnants... gotcha ;) > Now do another CVSup update just for good measure. Then try your > make world, and I think it will work this time. OK, going to do it while I am sending this mail... > Good luck, I needed it? =) Thanks, let ye know how it went... > -- > John Polstra jdp@polstra.com > John D. Polstra & Co., Inc. Seattle, Washington USA > "Nobody ever went broke underestimating the taste of the American public." > -- H. L. Mencken > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-current" in the body of the message --- Jeroen Ruigrok van der Werven/Asmodai asmodai(at)wxs.nl Junior Network/Security Specialist FreeBSD & picoBSD: The Power to Serve... To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Nov 1 05:38:51 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id FAA08203 for freebsd-current-outgoing; Sun, 1 Nov 1998 05:38:51 -0800 (PST) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from pcnet1.pcnet.com (pcnet1.pcnet.com [204.213.232.3]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id FAA08197 for ; Sun, 1 Nov 1998 05:38:49 -0800 (PST) (envelope-from eischen@vigrid.com) Received: (from eischen@localhost) by pcnet1.pcnet.com (8.8.7/PCNet) id IAA02419; Sun, 1 Nov 1998 08:38:39 -0500 (EST) Date: Sun, 1 Nov 1998 08:38:39 -0500 (EST) From: Daniel Eischen Message-Id: <199811011338.IAA02419@pcnet1.pcnet.com> To: jkh@time.cdrom.com, lists@tar.com Subject: Re: Kernel threading (was Re: Thread Scheduler bug) Cc: current@FreeBSD.ORG, jb@cimlogic.com.au Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Richard Seaman, Jr. wrote: > On Sat, 31 Oct 1998 14:08:43 -0800, Jordan K. Hubbard wrote: > > >I agree. While not perhaps adopting the perfect approach, at least > >Richard brings some very welcome *movement* to an issue which has been > >stalled for a regrettably long period of time. Let's try to run > >(cooperatively) with this and hopefully arrive at some working, > >architecturally clean kernel threads for FreeBSD! > > Just to be clear. I'm happy to co-operate and share code with anyone. > In fact, I'd be happy for someone else to just handle it all. In the > absence of someone else will to handle it all, I'm happy to contribute > what I can. > > The *only* reason I'd be hesitant to share any code at this moment > is that its still pretty messy, and I'd be embarrassed, and since > its barely tested, people would rightfully shoot all kinds of holes > in it. When its in a better state I'd be happy to post it somewhere > where anyone can whack at it. > I'd like to help in this effort, but I'd first like to see exactly what threading model is desired. Do we want a Solaris lightweight process model with the ability have both bound and unbound user threads? Or do we want libpthread to keep a one-one mapping of threads to kernel threads? After some decision on what direction kernel threads should take, we can then talk about the design and implementation. Dan Eischen eischen@vigrid.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Nov 1 05:53:56 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id FAA10069 for freebsd-current-outgoing; Sun, 1 Nov 1998 05:53:56 -0800 (PST) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from myrddin.demon.co.uk (myrddin.demon.co.uk [158.152.54.180]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id FAA10057 for ; Sun, 1 Nov 1998 05:53:54 -0800 (PST) (envelope-from dom@myrddin.demon.co.uk) Received: from localhost (myrddin.demon.co.uk) [127.0.0.1] by myrddin.demon.co.uk with esmtp (Exim 1.92 #1) id 0zZEbk-00004B-00; Fri, 30 Oct 1998 13:28:52 +0000 To: chet@po.CWRU.Edu Cc: chuckr@mat.net, Kurt@OpenLDAP.Org, current@FreeBSD.ORG Subject: Re: Changing sh for compatibility sake References: <981027145600.AA08055.SM@nike.ins.cwru.edu> From: Dom Mitchell In-Reply-To: Chet Ramey's message of "Tue, 27 Oct 1998 09:56:00 -0500" X-Mailer: Gnus v5.5/XEmacs 20.4 - "Emerald" Date: Fri, 30 Oct 1998 13:28:52 +0000 Message-Id: Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Chet Ramey writes: > > Have you ever seen an installer script written by a company that > > *didn't* supply the entire OS, be written in any shell BUT sh? > > Checkpoint writes all of its Firewall-1 installation (and other) > scripts in csh. As did the veritas netbackup I recently installed at work; it's quite a disturbing trend. -Dom To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Nov 1 06:19:39 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id GAA12934 for freebsd-current-outgoing; Sun, 1 Nov 1998 06:19:39 -0800 (PST) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from porkfriedrice.ny.genx.net (porkfriedrice.ny.genx.net [206.64.4.30]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id GAA12928 for ; Sun, 1 Nov 1998 06:19:38 -0800 (PST) (envelope-from bright@hotjobs.com) Received: from localhost (bright@localhost) by porkfriedrice.ny.genx.net (8.9.1/8.9.1) with ESMTP id JAA14768; Sun, 1 Nov 1998 09:22:20 -0500 (EST) (envelope-from bright@hotjobs.com) X-Authentication-Warning: porkfriedrice.ny.genx.net: bright owned process doing -bs Date: Sun, 1 Nov 1998 09:22:20 -0500 (EST) From: Alfred Perlstein X-Sender: bright@porkfriedrice.ny.genx.net To: Kazutaka YOKOTA cc: current@FreeBSD.ORG Subject: Re: if anyone is interested VESA seems broken. In-Reply-To: <199811011117.UAA15627@zodiac.mech.utsunomiya-u.ac.jp> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG yes i don't think freebsd by default loads a 8x8 font, i didn't realize this. it'd be nice however if vidcontrol had some way to report this. Alfred Perlstein - Programmer, HotJobs Inc. - www.hotjobs.com -- There are operating systems, and then there's FreeBSD. -- http://www.freebsd.org/ 3.0-current On Sun, 1 Nov 1998, Kazutaka YOKOTA wrote: > > >> VESA: mode:0x109, flags:0x000b, T 132x25, font:8x16 > >> VESA: window A:0xb800 (7), window B:0x0 (0), size:32k, gran:32k > >> VESA: mode:0x10b, flags:0x000b, T 132x50, font:8x8 > >> VESA: window A:0xb800 (7), window B:0x0 (0), size:32k, gran:32k > >> VESA: mode:0x10c, flags:0x000b, T 132x60, font:8x8 > >> VESA: window A:0xb800 (7), window B:0x0 (0), size:32k, gran:32k > > > >Your card definitely should be able to do 132x50, since it claims to > >support it here. Maybe check to see that vidcontrol and syscons.c > >handle them correctly (I don't have access to 3.0 at the moment) > > So long as 132x50 and 132x60 modes are listed in "vidcontrol -i mode" > and you have loaded 8x8 font, vidcontrol and syscons should be able > to set these modes. > > Kazu > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Nov 1 06:22:04 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id GAA13160 for freebsd-current-outgoing; Sun, 1 Nov 1998 06:22:04 -0800 (PST) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from time.cdrom.com (time.cdrom.com [204.216.27.226]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id GAA13153 for ; Sun, 1 Nov 1998 06:22:02 -0800 (PST) (envelope-from jkh@time.cdrom.com) Received: from time.cdrom.com (jkh@localhost.cdrom.com [127.0.0.1]) by time.cdrom.com (8.8.8/8.8.8) with ESMTP id GAA18897; Sun, 1 Nov 1998 06:22:00 -0800 (PST) (envelope-from jkh@time.cdrom.com) To: Mike Smith cc: Andrzej Bialecki , current@FreeBSD.ORG Subject: Re: BootForth (was Re: New boot loader and alternate kernels) In-reply-to: Your message of "Sat, 31 Oct 1998 21:37:12 PST." <199811010537.VAA01330@dingo.cdrom.com> Date: Sun, 01 Nov 1998 06:21:59 -0800 Message-ID: <18893.909930119@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > So, how do I integrate it into the loader? Do we want to make it > optional? Do we want to strip the loader back to the bare essentials > and use BootFORTH for as much as possible? Is a "middle road" approach > preferred? Well, you could probably save some space by registering all your existing builtins as forth words and chucking the existing interpreter in favor of the more traditional INTERPRET word. Not sure how you'd do that initial timeout behavior thing though - probably some gross hack. :-) > Any Forth hackers want to play with something new and funky? In > particular, some ideas on "standard" system-interface words would be > handy. If you get it to the point where it's launching from the boot blocks, I'd certainly be willing to look into some of the ergnonomic and extensibility issues. - Jordan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Nov 1 06:38:52 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id GAA14351 for freebsd-current-outgoing; Sun, 1 Nov 1998 06:38:52 -0800 (PST) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from picnic.mat.net (picnic.mat.net [206.246.122.117]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id GAA14345 for ; Sun, 1 Nov 1998 06:38:50 -0800 (PST) (envelope-from chuckr@mat.net) Received: from localhost (chuckr@localhost) by picnic.mat.net (8.9.1/8.8.5) with ESMTP id JAA01424; Sun, 1 Nov 1998 09:37:41 -0500 (EST) Date: Sun, 1 Nov 1998 09:37:41 -0500 (EST) From: Chuck Robey To: John Hay cc: Garrett Wollman , current@FreeBSD.ORG Subject: Re: IPv6 in -current In-Reply-To: <199811010922.LAA05107@zibbi.mikom.csir.co.za> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, 1 Nov 1998, John Hay wrote: > > > > >> > * Full IPv6 implementation in-kernel and libc! > > >> * Complete single-copy TCP/IP implementation > > > > > And even better if we could list both. :-) I think the needs of the > > > FreeBSD group is diverse enough that this isn't unreasonable. > > > > The needs are one thing; the capabilities quite another. OK, is this all true then? 1) We all want IPv6 added to the kernel. 2) There are two good contenders for the role of provider for this code, and they've both given quite a bit of work. They both could and would have their own committer do the work. 3) One reason for the delay, then, is a reasonable unwillingness to choose between 2 good possibilities (and possibly insult the losing team of developers, who clearly don't deserve any kind of insult). Would it be a reasonable thing to ask, that there be held an electronic debate? It need not be broadcast realtime ... the idea being that each team of developers be given the clearest possible chance to put forward their ideas in a sort of a debate-type encounter. This could be done via email to a 3rd party, a moderator, who would accumulate the results. If it was done via email, then (although it would be slower) it would not turn on momentary mistakes in phrasing so much as ability to present themselves; such a dialog could take up to a week or more to actually accumulate some presentable weight. At the end of some prearranged time, or on agreement (earlier) of both participants that they've given their best shots, the results could be made public. A decision could be made by a prequalified user base, either everyone who registers (register for voting? what an idea) or maybe committers. This would serve to give the ideas their best airing, allow the developers to present their cases in the lowest possible pressure consistent with public disclosure, and probably give the loser at least the feeling that they'd certainly been listened to, so their would be less likelihood of injured feelings. And, FreeBSD would most likely to get the best IPv6 implementation from it. ----------------------------+----------------------------------------------- Chuck Robey | Interests include any kind of voice or data chuckr@glue.umd.edu | communications topic, C programming, and Unix. 213 Lakeside Drive Apt T-1 | Greenbelt, MD 20770 | I run Journey2 and picnic (FreeBSD-current) (301) 220-2114 | and jaunt (NetBSD). ----------------------------+----------------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Nov 1 06:52:39 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id GAA16246 for freebsd-current-outgoing; Sun, 1 Nov 1998 06:52:39 -0800 (PST) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from ocean.campus.luth.se (ocean.campus.luth.se [130.240.194.116]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id GAA16239 for ; Sun, 1 Nov 1998 06:52:36 -0800 (PST) (envelope-from karpen@ocean.campus.luth.se) Received: (from karpen@localhost) by ocean.campus.luth.se (8.9.1/8.9.1) id PAA21479; Sun, 1 Nov 1998 15:47:20 +0100 (CET) (envelope-from karpen) From: Mikael Karpberg Message-Id: <199811011447.PAA21479@ocean.campus.luth.se> Subject: Re: New boot loader and alternate kernels In-Reply-To: <199810302013.MAA01772@dingo.cdrom.com> from Mike Smith at "Oct 30, 98 12:13:09 pm" To: mike@smith.net.au (Mike Smith) Date: Sun, 1 Nov 1998 15:47:20 +0100 (CET) Cc: current@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL32 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG According to Mike Smith: > > > (Yes, I agree that Forth would be more powerful. Compromises...) > > > > Ah, well. I guess I'm proposing Forth so strongly because it's so powerful > > and compact, and fast... and so incredibly extensible when you need it. No > > need to reinvent the same things each time, writing yet another > > incompatible language... > > > > I think this is important opportunity - let's not miss it without good > > reasons... As I said, there are people among us who can even write small > > enough Forth kernel for our purposes. > > I have no desire to miss it. Give me a compact Forth interpreter that > links against libstand and you'll be seeing it everywhere Real Soon. Eeep! Umm... what exactly does this mean? I mean... I don't know anyone that knows forth... lots of people know sh. And a logical special language (whic resembles sh and the other script languages) is not real hard to learn either. Why mess it up and get forth in there? And to do what exactly? /Mikael To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Nov 1 07:03:04 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id HAA18002 for freebsd-current-outgoing; Sun, 1 Nov 1998 07:03:04 -0800 (PST) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.40.131]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id HAA17996 for ; Sun, 1 Nov 1998 07:03:02 -0800 (PST) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.9.1/8.8.5) with ESMTP id QAA18028; Sun, 1 Nov 1998 16:01:01 +0100 (CET) To: Mikael Karpberg cc: mike@smith.net.au (Mike Smith), current@FreeBSD.ORG Subject: Re: New boot loader and alternate kernels In-reply-to: Your message of "Sun, 01 Nov 1998 15:47:20 +0100." <199811011447.PAA21479@ocean.campus.luth.se> Date: Sun, 01 Nov 1998 16:01:00 +0100 Message-ID: <18026.909932460@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >Eeep! Umm... what exactly does this mean? I mean... I don't know anyone >that knows forth... lots of people know sh. And a logical special >language (whic resembles sh and the other script languages) is not >real hard to learn either. Why mess it up and get forth in there? And >to do what exactly? The scoop about forth is that you can implement it in virtually no bytes (well, physically too of course.) The "Open" boot prom on Suns and the various spinoffs from that use forth for that reason. It's compact, it can be made machine independent and there is a standard (several actually) so you don't have to invent the host plate and the deep water all over again. -- Poul-Henning Kamp FreeBSD coreteam member phk@FreeBSD.ORG "Real hackers run -current on their laptop." "ttyv0" -- What UNIX calls a $20K state-of-the-art, 3D, hi-res color terminal To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Nov 1 07:18:50 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id HAA19644 for freebsd-current-outgoing; Sun, 1 Nov 1998 07:18:50 -0800 (PST) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from nomad.dataplex.net (nomad.dataplex.net [208.2.87.8]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id HAA19638 for ; Sun, 1 Nov 1998 07:18:48 -0800 (PST) (envelope-from rkw@nomad.dataplex.net) Received: from localhost (rkw@localhost) by nomad.dataplex.net (8.9.1/8.9.1) with ESMTP id JAA17201; Sun, 1 Nov 1998 09:18:28 -0600 (CST) (envelope-from rkw@nomad.dataplex.net) Date: Sun, 1 Nov 1998 09:18:28 -0600 (CST) From: User RKW To: "Jordan K. Hubbard" cc: Mike Smith , Andrzej Bialecki , current@FreeBSD.ORG Subject: Re: BootForth (was Re: New boot loader and alternate kernels) In-Reply-To: <18893.909930119@time.cdrom.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, 1 Nov 1998, Jordan K. Hubbard wrote: > > So, how do I integrate it into the loader? Do we want to make it > > optional? Do we want to strip the loader back to the bare essentials > > and use BootFORTH for as much as possible? Is a "middle road" approach > > preferred? > > Well, you could probably save some space by registering all your existing > builtins as forth words and chucking the existing interpreter in favor > of the more traditional INTERPRET word. Not sure how you'd do that initial > timeout behavior thing though - probably some gross hack. :-) To make it small, that is the approach I would follow. Mixing languages leads to "bloat" because you end up supporting multiple ways to accomplish the same thing. KISS. As for the timeout, run a "word" that delays until its counter runs out or it finds a key. When that routine returns, test ?KEY to either read the actual input or fake it in the case of a timeout. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Nov 1 07:30:18 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id HAA20741 for freebsd-current-outgoing; Sun, 1 Nov 1998 07:30:18 -0800 (PST) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from spinner.netplex.com.au (spinner.netplex.com.au [202.12.86.3]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id HAA20734 for ; Sun, 1 Nov 1998 07:30:14 -0800 (PST) (envelope-from peter@netplex.com.au) Received: from spinner.netplex.com.au (localhost [127.0.0.1]) by spinner.netplex.com.au (8.9.1/8.9.1/Spinner) with ESMTP id XAA25055; Sun, 1 Nov 1998 23:29:40 +0800 (WST) (envelope-from peter@spinner.netplex.com.au) Message-Id: <199811011529.XAA25055@spinner.netplex.com.au> X-Mailer: exmh version 2.0.2 2/24/98 To: Daniel Eischen cc: lists@tar.com, current@FreeBSD.ORG, jb@cimlogic.com.au Subject: Re: Kernel threading (was Re: Thread Scheduler bug) In-reply-to: Your message of "Sun, 01 Nov 1998 08:38:39 EST." <199811011338.IAA02419@pcnet1.pcnet.com> Date: Sun, 01 Nov 1998 23:29:39 +0800 From: Peter Wemm Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Daniel Eischen wrote: > Richard Seaman, Jr. wrote: > > On Sat, 31 Oct 1998 14:08:43 -0800, Jordan K. Hubbard wrote: > > > > >I agree. While not perhaps adopting the perfect approach, at least > > >Richard brings some very welcome *movement* to an issue which has been > > >stalled for a regrettably long period of time. Let's try to run > > >(cooperatively) with this and hopefully arrive at some working, > > >architecturally clean kernel threads for FreeBSD! > > > > Just to be clear. I'm happy to co-operate and share code with anyone. > > In fact, I'd be happy for someone else to just handle it all. In the > > absence of someone else will to handle it all, I'm happy to contribute > > what I can. > > > > The *only* reason I'd be hesitant to share any code at this moment > > is that its still pretty messy, and I'd be embarrassed, and since > > its barely tested, people would rightfully shoot all kinds of holes > > in it. When its in a better state I'd be happy to post it somewhere > > where anyone can whack at it. > > > > I'd like to help in this effort, but I'd first like to see > exactly what threading model is desired. Do we want a Solaris > lightweight process model with the ability have both bound > and unbound user threads? Or do we want libpthread to keep > a one-one mapping of threads to kernel threads? I'm not familiar with Solaris threads but have seen the man pages for the SVR4.2-whatever-it-is-this-week as used in Unixware. What I had in mind was something along the lines of: - the kernel context switching entity would become a 'thread' rather than a 'proc'. - a "process" (struct proc) would have one or more threads, all using the same address space, pid, signals, etc. - The logistics of doing this are ugly. I don't expect that a global 's/sturct proc/struct thread/g' would go down well. - the boundaries between the present 'struct proc', pcb, upages, etc would get muddied a bit in the process. The context that a thread would need would be something like a superset of the pcb at present. - A thread would have just enough context for making syscalls etc. - context switching between threads would be bloody quick, as good or better than switching between rfork shared address space siblings. - There would be one kernel stack per thread, up to a limit of the number of present CPU in operation. If you had 4 cpus and 1000 threads, you still only need 4 stacks and other associated things (PTD etc). - It would be nice to have some sort of cooperative kernel<->user scheduling interface so that it would be possible to have the libpthread "engine" schedule it's pthreads onto kernel threads. Suppose one wants a few thousand pthreads, but only realistically needs 10 or 20 of them to block in syscalls at any given time. I'd love to get more involved in this from the kernel side of this, but surviving from day to day is number one priority at the moment. Cheers, -Peter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Nov 1 07:41:10 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id HAA22344 for freebsd-current-outgoing; Sun, 1 Nov 1998 07:41:10 -0800 (PST) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from picnic.mat.net (picnic.mat.net [206.246.122.117]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id HAA22329 for ; Sun, 1 Nov 1998 07:41:06 -0800 (PST) (envelope-from chuckr@mat.net) Received: from localhost (chuckr@localhost) by picnic.mat.net (8.9.1/8.8.5) with ESMTP id KAA01571 for ; Sun, 1 Nov 1998 10:40:24 -0500 (EST) Date: Sun, 1 Nov 1998 10:40:24 -0500 (EST) From: Chuck Robey To: freebsd-current@FreeBSD.ORG Subject: boot flags Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG My boot.conf looks like: load kernel autoboot 10 so far (I'll add modules next), but what's the syntax in that file to add boot flags? I specifically (right now) want to add -v. If this is defined somewhere, a pointer there would be fine. Thanks. ----------------------------+----------------------------------------------- Chuck Robey | Interests include any kind of voice or data chuckr@glue.umd.edu | communications topic, C programming, and Unix. 213 Lakeside Drive Apt T-1 | Greenbelt, MD 20770 | I run Journey2 and picnic (FreeBSD-current) (301) 220-2114 | and jaunt (NetBSD). ----------------------------+----------------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Nov 1 07:47:30 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id HAA23271 for freebsd-current-outgoing; Sun, 1 Nov 1998 07:47:30 -0800 (PST) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from whizzo.transsys.com (whizzo.TransSys.COM [144.202.42.10]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id HAA23259 for ; Sun, 1 Nov 1998 07:47:28 -0800 (PST) (envelope-from louie@whizzo.transsys.com) Received: from whizzo.transsys.com (localhost.transsys.com [127.0.0.1]) by whizzo.transsys.com (8.9.1/8.9.1) with ESMTP id KAA15557 for ; Sun, 1 Nov 1998 10:47:15 -0500 (EST) (envelope-from louie@whizzo.transsys.com) Message-Id: <199811011547.KAA15557@whizzo.transsys.com> X-Mailer: exmh version 2.0.2 2/24/98 To: freebsd-current@FreeBSD.ORG From: "Louis A. Mamakos" Subject: Re: boot flags References: In-reply-to: Your message of "Sun, 01 Nov 1998 10:40:24 EST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 01 Nov 1998 10:47:14 -0500 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > My boot.conf looks like: > > load kernel > autoboot 10 > > so far (I'll add modules next), but what's the syntax in that file to > add boot flags? I specifically (right now) want to add -v. If this is > defined somewhere, a pointer there would be fine. And while the question is being asked.. is there a way with the new 3 stage boot loader to pass in a USERCONFIG configuration file? I used to do this to configure some PNP peripherals. I'm guessing that this function will probably now happen in /boot/loader, but that code doesn't seem to be functional for this purpose yet. I'd be happy to hear otherwise. louie To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Nov 1 07:55:54 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id HAA24615 for freebsd-current-outgoing; Sun, 1 Nov 1998 07:55:54 -0800 (PST) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from picnic.mat.net (picnic.mat.net [206.246.122.117]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id HAA24608 for ; Sun, 1 Nov 1998 07:55:50 -0800 (PST) (envelope-from chuckr@mat.net) Received: from localhost (chuckr@localhost) by picnic.mat.net (8.9.1/8.8.5) with ESMTP id KAA01590; Sun, 1 Nov 1998 10:54:28 -0500 (EST) Date: Sun, 1 Nov 1998 10:54:28 -0500 (EST) From: Chuck Robey To: Peter Wemm cc: Daniel Eischen , lists@tar.com, current@FreeBSD.ORG, jb@cimlogic.com.au Subject: Re: Kernel threading (was Re: Thread Scheduler bug) In-Reply-To: <199811011529.XAA25055@spinner.netplex.com.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, 1 Nov 1998, Peter Wemm wrote: > > I'd like to help in this effort, but I'd first like to see > > exactly what threading model is desired. Do we want a Solaris > > lightweight process model with the ability have both bound > > and unbound user threads? Or do we want libpthread to keep > > a one-one mapping of threads to kernel threads? > > I'm not familiar with Solaris threads but have seen the man pages for the > SVR4.2-whatever-it-is-this-week as used in Unixware. > > What I had in mind was something along the lines of: > - the kernel context switching entity would become a 'thread' rather than > a 'proc'. > - a "process" (struct proc) would have one or more threads, all using the > same address space, pid, signals, etc. > - The logistics of doing this are ugly. I don't expect that a global > 's/sturct proc/struct thread/g' would go down well. > - the boundaries between the present 'struct proc', pcb, upages, etc would > get muddied a bit in the process. The context that a thread would need > would be something like a superset of the pcb at present. > - A thread would have just enough context for making syscalls etc. > - context switching between threads would be bloody quick, as good or > better than switching between rfork shared address space siblings. > - There would be one kernel stack per thread, up to a limit of the number > of present CPU in operation. If you had 4 cpus and 1000 threads, you > still only need 4 stacks and other associated things (PTD etc). > - It would be nice to have some sort of cooperative kernel<->user > scheduling interface so that it would be possible to have the libpthread > "engine" schedule it's pthreads onto kernel threads. Suppose one wants a > few thousand pthreads, but only realistically needs 10 or 20 of them to > block in syscalls at any given time. The way it's put, it *seems* like you're saying that a thread needs more context than a proc, but since the proc context really must be shared among all it's threads, you wouldn't want to duplicate the proc context, you'd just want to make the right proc context available to the right threads, right? The idea is that threads have less context, meaning less complicated context switching (and lower overhead for that context switching), right? The idea about each thread having it's own kernel stack seems unavoidable, but that stack could be pretty limited in size, and actually settable size, right? I'm wondering about memory allocation here for threads ... in a proc now, if you run out of stack, it grows for you. I think that would be too big a hammer on the system for each thread, wouldn't it? If a thread ran out of stack, would it just give a signal indicating the problem, and let the thread itself (or a thread managing thread) handle new stack problems. I mean, threads handle stack setup themselves, when they start, unlike processes, and it ought to be as lightweight as possible. I'm not an expert, these are questions. I don't want threads to become little processes with implicitly shared memories, I want them to be lightweight, as they were originally intended. The only reason to move to kernel threads at all is to make the signal management lighter in weight, and get single thread blocking on syscalls, right? I guess I'm trying to emphasize "lightweight". I'm going to go hunting in the mail archives, Terry *must have* written one of his email-books on this sometime. > > I'd love to get more involved in this from the kernel side of this, but > surviving from day to day is number one priority at the moment. > > Cheers, > -Peter > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-current" in the body of the message > > ----------------------------+----------------------------------------------- Chuck Robey | Interests include any kind of voice or data chuckr@glue.umd.edu | communications topic, C programming, and Unix. 213 Lakeside Drive Apt T-1 | Greenbelt, MD 20770 | I run Journey2 and picnic (FreeBSD-current) (301) 220-2114 | and jaunt (NetBSD). ----------------------------+----------------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Nov 1 08:14:46 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id IAA26497 for freebsd-current-outgoing; Sun, 1 Nov 1998 08:14:46 -0800 (PST) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from lamb.sas.com (lamb.sas.com [192.35.83.8]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id IAA26489 for ; Sun, 1 Nov 1998 08:14:43 -0800 (PST) (envelope-from jwd@unx.sas.com) Received: from mozart (mozart.unx.sas.com [192.58.184.8]) by lamb.sas.com (8.9.1/8.9.1) with SMTP id LAA23712; Sun, 1 Nov 1998 11:14:38 -0500 (EST) Received: from bb01f39.unx.sas.com by mozart (5.65c/SAS/Domains/5-6-90) id AA17727; Sun, 1 Nov 1998 11:14:38 -0500 Received: (from jwd@localhost) by bb01f39.unx.sas.com (8.9.1/8.9.1) id LAA13897; Sun, 1 Nov 1998 11:14:38 -0500 (EST) (envelope-from jwd) From: "John W. DeBoskey" Message-Id: <199811011614.LAA13897@bb01f39.unx.sas.com> Subject: Re: scsi disk (cam?) problems (inodes & swap?) In-Reply-To: To: freebsd-current@FreeBSD.ORG Date: Sun, 1 Nov 1998 11:14:37 -0500 (EST) Cc: ken@plutotech.com X-Mailer: ELM [version 2.4ME+ PL38 (25)] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hello, Since rebooting last evenning and running: cd /usr/src && make world && cd release && make release my system hasn't died, but the following have shown up in messages. fyi: my system has 256Meg of memory and I seriously doubt it ran out of swap, and the ccd filesystems fsck'd clean twice before I started the build. The cvsup msgs are normal, and left in for timing info only. Comments, critiques, & useful ideas are welcome... Thanks! John FreeBSD FreeBSD.pc.sas.com 3.0-CURRENT FreeBSD 3.0-CURRENT #0: Sat Oct 31 13:51:35 EST 1998 Oct 31 21:18:41 FreeBSD cvsupd[225]: CVSup server started Oct 31 21:18:41 FreeBSD cvsupd[225]: Software version: REL_15_2 Oct 31 21:18:41 FreeBSD cvsupd[225]: Protocol version: 15.4 Oct 31 21:18:41 FreeBSD cvsupd[225]: Ready to service requests Nov 1 02:22:21 FreeBSD /kernel: (da0:ahc0:0:1:0): tagged openings now 64 Nov 1 02:22:21 FreeBSD /kernel: (da0:ahc0:0:1:0): tagged openings now 63 Nov 1 02:22:53 FreeBSD /kernel: (da1:ahc0:0:2:0): tagged openings now 64 Nov 1 02:22:53 FreeBSD /kernel: (da1:ahc0:0:2:0): tagged openings now 63 Nov 1 02:23:58 FreeBSD /kernel: (da2:ahc0:0:3:0): tagged openings now 64 Nov 1 02:23:58 FreeBSD /kernel: (da2:ahc0:0:3:0): tagged openings now 63 Nov 1 02:26:07 FreeBSD /kernel: (da3:ahc0:0:4:0): tagged openings now 64 Nov 1 02:26:07 FreeBSD /kernel: (da3:ahc0:0:4:0): tagged openings now 63 Nov 1 04:31:32 FreeBSD /kernel: free inode /snap/47709 had 208 blocks Nov 1 04:32:51 FreeBSD /kernel: free inode /snap/119072 had 4672 blocks . . Lots of 'free inode' msgs deleted ::: NOTE the pager msg below . Nov 1 08:33:01 FreeBSD /kernel: free inode /snap/51301 had 224 blocks Nov 1 08:35:54 FreeBSD /kernel: swap_pager: suggest more swap space: 513 MB Nov 1 08:37:53 FreeBSD /kernel: free inode /snap/265813 had 96 blocks Nov 1 09:23:12 FreeBSD /kernel: free inode /snap/35330 had 32 blocks Nov 1 10:27:36 FreeBSD /kernel: free inode /pub/1745922 had 288 blocks Nov 1 10:27:38 FreeBSD /kernel: free inode /pub/1785601 had 288 blocks . . Lots of 'free inode' msgs deleted . Nov 1 10:40:23 FreeBSD /kernel: free inode /pub/1706322 had 128 blocks Nov 1 10:55:53 FreeBSD /kernel: free inode /pub/1777665 had 2688 blocks To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Nov 1 08:23:16 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id IAA27573 for freebsd-current-outgoing; Sun, 1 Nov 1998 08:23:16 -0800 (PST) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from spinner.netplex.com.au (spinner.netplex.com.au [202.12.86.3]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id IAA27560 for ; Sun, 1 Nov 1998 08:23:08 -0800 (PST) (envelope-from peter@netplex.com.au) Received: from spinner.netplex.com.au (localhost [127.0.0.1]) by spinner.netplex.com.au (8.9.1/8.9.1/Spinner) with ESMTP id AAA25247; Mon, 2 Nov 1998 00:22:11 +0800 (WST) (envelope-from peter@spinner.netplex.com.au) Message-Id: <199811011622.AAA25247@spinner.netplex.com.au> X-Mailer: exmh version 2.0.2 2/24/98 To: Chuck Robey cc: Daniel Eischen , lists@tar.com, current@FreeBSD.ORG, jb@cimlogic.com.au Subject: Re: Kernel threading (was Re: Thread Scheduler bug) In-reply-to: Your message of "Sun, 01 Nov 1998 10:54:28 EST." Date: Mon, 02 Nov 1998 00:22:11 +0800 From: Peter Wemm Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Chuck Robey wrote: > On Sun, 1 Nov 1998, Peter Wemm wrote: > > > > I'd like to help in this effort, but I'd first like to see > > > exactly what threading model is desired. Do we want a Solaris > > > lightweight process model with the ability have both bound > > > and unbound user threads? Or do we want libpthread to keep > > > a one-one mapping of threads to kernel threads? > > > > I'm not familiar with Solaris threads but have seen the man pages for the > > SVR4.2-whatever-it-is-this-week as used in Unixware. > > > > What I had in mind was something along the lines of: > > - the kernel context switching entity would become a 'thread' rather than > > a 'proc'. > > - a "process" (struct proc) would have one or more threads, all using the > > same address space, pid, signals, etc. > > - The logistics of doing this are ugly. I don't expect that a global > > 's/sturct proc/struct thread/g' would go down well. > > - the boundaries between the present 'struct proc', pcb, upages, etc would > > get muddied a bit in the process. The context that a thread would need > > would be something like a superset of the pcb at present. > > - A thread would have just enough context for making syscalls etc. > > - context switching between threads would be bloody quick, as good or > > better than switching between rfork shared address space siblings. > > - There would be one kernel stack per thread, up to a limit of the number > > of present CPU in operation. If you had 4 cpus and 1000 threads, you > > still only need 4 stacks and other associated things (PTD etc). > > - It would be nice to have some sort of cooperative kernel<->user > > scheduling interface so that it would be possible to have the libpthread > > "engine" schedule it's pthreads onto kernel threads. Suppose one wants a > > few thousand pthreads, but only realistically needs 10 or 20 of them to > > block in syscalls at any given time. > > The way it's put, it *seems* like you're saying that a thread needs more > context than a proc, but since the proc context really must be shared > among all it's threads, you wouldn't want to duplicate the proc context, > you'd just want to make the right proc context available to the right > threads, right? Err, a thread needs much less context than a proc, otherwise large numbers of them become very expensive. A process, as it presently exists, consists of all the VM, permissions, state, execution context, signals, etc etc. Part of the process context is in the struct proc, part is in the pcb and upages with the kernel stack. What would be ideal would be that a 'process' could gain multiple execution contexts, and each of these could make syscalls and block on IO etc. > The idea is that threads have less context, meaning less complicated > context switching (and lower overhead for that context switching), > right? Yes. > The idea about each thread having it's own kernel stack seems > unavoidable, but that stack could be pretty limited in size, and > actually settable size, right? I'm wondering about memory allocation > here for threads ... in a proc now, if you run out of stack, it grows > for you. I think that would be too big a hammer on the system for each > thread, wouldn't it? If a thread ran out of stack, would it just give a > signal indicating the problem, and let the thread itself (or a thread > managing thread) handle new stack problems. I mean, threads handle > stack setup themselves, when they start, unlike processes, and it ought > to be as lightweight as possible. The tricky part comes when you try and get this to fly on a SMP system, where the same process could really be executing in parallel on multiple cpus at once. The kernel stack and user stack are two different things. The processes switch to the kernel stack for interrupts, traps and syscalls. This is in the UPAGES at present, 8K of kvm per process. The pcb and signal state live in the first part of the first page, so there's less than 8K of kernel stack per process - actually there is no guard at all, the kernel stack could conceivably grow down and clobber the snot out of the signal handlers and the pcb, but the system would be in big trouble by then and a process coredump would be the last thing on your mind. You need a kernel stack per thread in the lightweight model, up to a limit of the number of cpus running, because it's needed for each possibly active thread to make a syscall. > I'm not an expert, these are questions. I don't want threads to become > little processes with implicitly shared memories, I want them to be > lightweight, as they were originally intended. The only reason to move > to kernel threads at all is to make the signal management lighter in > weight, and get single thread blocking on syscalls, right? Two reasons.. blocking on syscalls, and SMP support. A select() buzz loop scheduler like in libc_r gets no gain from a SMP system, and that's the main gain to be had. There are other problems that need to be resolved for SMP address space sharing. Activating the same PTD from a single address space blows away the per-cpu private pages and this really screws things up since both cpus aquire the same cpuid and explode. Teaching the pmap code about multiple PTD's per process (per shared rfork() thread, up to a max of numcpus again) is an interesting problem - I wonder if it might be easier to simply have a different PTD for the kernel for each CPU and switch from the user PTD to the kernel one at trap/syscall/interrupt time. This means major changes to the protection interface, copyin/out etc are presently done by having the kernel read the user pages and faulting if needed. Under a per-cpu kernel space PTD, the kernel would have to do much more work to access the current user process address space. > I guess I'm trying to emphasize "lightweight". I know, so am I. Cheers, -Peter -- Peter Wemm Netplex Consulting "No coffee, No workee!" :-) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Nov 1 08:40:27 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id IAA00558 for freebsd-current-outgoing; Sun, 1 Nov 1998 08:40:27 -0800 (PST) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from frmug.org (frmug-gw.frmug.org [193.56.58.252]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id IAA00550 for ; Sun, 1 Nov 1998 08:40:24 -0800 (PST) (envelope-from roberto@keltia.freenix.fr) Received: (from uucp@localhost) by frmug.org (8.9.1/frmug-2.3/nospam) with UUCP id RAA08027 for freebsd-current@FreeBSD.ORG; Sun, 1 Nov 1998 17:40:18 +0100 (CET) (envelope-from roberto@keltia.freenix.fr) Received: by keltia.freenix.fr (VMailer, from userid 101) id 14DAB145A; Sun, 1 Nov 1998 16:59:53 +0100 (CET) Date: Sun, 1 Nov 1998 16:59:52 +0100 From: Ollivier Robert To: freebsd-current@FreeBSD.ORG Subject: Re: boot flags Message-ID: <19981101165952.A8580@keltia.freenix.fr> Mail-Followup-To: freebsd-current@FreeBSD.ORG References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.94.4i In-Reply-To: ; from Chuck Robey on Sun, Nov 01, 1998 at 10:40:24AM -0500 X-Operating-System: FreeBSD 3.0-BETA/ELF ctm#4772 AMD-K6 MMX @ 200 MHz Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG According to Chuck Robey: > load kernel > autoboot 10 > > so far (I'll add modules next), but what's the syntax in that file to > add boot flags? I specifically (right now) want to add -v. If this is > defined somewhere, a pointer there would be fine. Add a line like the following: set verbose -- Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- roberto@keltia.freenix.fr FreeBSD keltia.freenix.fr 3.0-BETA #4: Thu Oct 15 01:36:57 CEST 1998 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Nov 1 08:53:30 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id IAA01941 for freebsd-current-outgoing; Sun, 1 Nov 1998 08:53:30 -0800 (PST) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from austin.polstra.com (austin.polstra.com [206.213.73.10]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id IAA01934 for ; Sun, 1 Nov 1998 08:53:29 -0800 (PST) (envelope-from jdp@austin.polstra.com) Received: from austin.polstra.com (jdp@localhost) by austin.polstra.com (8.9.1/8.9.1) with ESMTP id IAA29300; Sun, 1 Nov 1998 08:53:22 -0800 (PST) (envelope-from jdp) Message-Id: <199811011653.IAA29300@austin.polstra.com> To: Jeroen Ruigrok/Asmodai cc: current@FreeBSD.ORG Subject: Re: cvsup .4.2 In-reply-to: Your message of "Sun, 01 Nov 1998 14:28:09 +0100." Date: Sun, 01 Nov 1998 08:53:22 -0800 From: John Polstra Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > Please let me know what version of FreeBSD you're running. Also > > 3.0-CURRENT, cvsupped every day. > > > please send me the output of: > > > > ident /usr/include/sys/sem.h > > [diabolique] asmodai $ ident /usr/include/sys/sem.h > /usr/include/sys/sem.h: > $Id: sem.h,v 1.15 1998/07/15 02:32:32 bde Exp $ > $NetBSD: sem.h,v 1.5 1994/06/29 06:45:15 cgd Exp $ > > > > and > > > > grep define /usr/include/osreldate.h > > [diabolique] asmodai $ grep define /usr/include/osreldate.h > #define __FreeBSD_version 300006 Thanks, that clears it up. I think your modula-3-lib port must be out of date. I fixed this problem in early June. Check your file "modula-3-lib/patches/patch-ab" with /sbin/md5 and you should get this: vashon$ /sbin/md5 patch-ab MD5 (patch-ab) = d15b35461b0e8df99ae9d2707e2660dd But I don't think that's what you'll see. :-) Grab the current modula-3-lib port from the web site. While you're at it, get the latest modula-3 and cvsup ports too. Then I think it will all work fine. > Might also be relevant to my Attic/cvsup make world problems... Nope, I don't think there's any connection between the two problems. John -- John Polstra jdp@polstra.com John D. Polstra & Co., Inc. Seattle, Washington USA "Nobody ever went broke underestimating the taste of the American public." -- H. L. Mencken To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Nov 1 08:56:50 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id IAA02375 for freebsd-current-outgoing; Sun, 1 Nov 1998 08:56:50 -0800 (PST) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from lamb.sas.com (lamb.sas.com [192.35.83.8]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id IAA02368 for ; Sun, 1 Nov 1998 08:56:46 -0800 (PST) (envelope-from jwd@unx.sas.com) Received: from mozart (mozart.unx.sas.com [192.58.184.8]) by lamb.sas.com (8.9.1/8.9.1) with SMTP id LAA29976; Sun, 1 Nov 1998 11:56:36 -0500 (EST) Received: from bb01f39.unx.sas.com by mozart (5.65c/SAS/Domains/5-6-90) id AA19182; Sun, 1 Nov 1998 11:56:35 -0500 Received: (from jwd@localhost) by bb01f39.unx.sas.com (8.9.1/8.9.1) id LAA14169; Sun, 1 Nov 1998 11:56:31 -0500 (EST) (envelope-from jwd) From: "John W. DeBoskey" Message-Id: <199811011656.LAA14169@bb01f39.unx.sas.com> Subject: Re: Changing sh for compatibility sake In-Reply-To: From Brian Feldman at "Oct 27, 98 07:31:15 am" To: green@zone.syracuse.net (Brian Feldman) Date: Sun, 1 Nov 1998 11:56:31 -0500 (EST) Cc: freebsd-current@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL38 (25)] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi, I sent mail to this list a few months ago... pdksh doesn't run the tail-end of a pipe in the current shell environment, thus the following doesn't work as expected: export FOUND=0 ls | wc -l | while read fcnt; do export FOUND=$fcnt done echo $FOUND So, the comment below might need a slight modification to say which scripts don't break... :-) Thanks! John > Let me repeat this once more: not a SINGLE script breaks with pdksh! > > Brian Feldman > > On Mon, 26 Oct 1998, Kurt D. Zeilenga wrote: > > > Chuck wrote: > > >I'm sorry, that's not true. Ask anyone who writes shell scripts that > > >install software (or perform any necessarily portable function) across > > >multiple platforms. sh is the shell to use ONLY BECAUSE it's the lowest > > >common denominator. Why else would they use the dumbest shell? > > > > I've written numerous system/install sh scripts. But it's not to > > one specific implementation, its many. It seems like every OS > > has it's own variant of sh. I do not know of any version of sh > > that can reliable used as a golden target sh. Each and very > > implementation of sh has its quirks that have to be dealt with. > > FreeBSD sh definitely has its, as do the others. > > > > Any change will likely cause problems in some existing scripts. > > Also, any change will cause developers to deal with additional > > portability issues. This is life. Most multiple platform sh > > developers have already adapted to specific quicks of popular > > sh implementations. Changing from one to another should not > > be that big of a deal. I suspect a few FreeBSD-only sh scripts > > will choke. > > > > Don't change sh for compatibility sake, our scripts are already > > compatible! Do change for functionality sake, we'll adapt as > > necessary. > > > > Kurt > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-current" in the body of the message > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-current" in the body of the message > > ------------------------------ > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Nov 1 09:11:20 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id JAA03996 for freebsd-current-outgoing; Sun, 1 Nov 1998 09:11:20 -0800 (PST) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from lamb.sas.com (lamb.sas.com [192.35.83.8]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id JAA03988 for ; Sun, 1 Nov 1998 09:11:13 -0800 (PST) (envelope-from jwd@unx.sas.com) Received: from mozart (mozart.unx.sas.com [192.58.184.8]) by lamb.sas.com (8.9.1/8.9.1) with SMTP id MAA01486; Sun, 1 Nov 1998 12:10:57 -0500 (EST) Received: from bb01f39.unx.sas.com by mozart (5.65c/SAS/Domains/5-6-90) id AA19576; Sun, 1 Nov 1998 12:10:57 -0500 Received: (from jwd@localhost) by bb01f39.unx.sas.com (8.9.1/8.9.1) id MAA14627; Sun, 1 Nov 1998 12:10:54 -0500 (EST) (envelope-from jwd) From: "John W. DeBoskey" Message-Id: <199811011710.MAA14627@bb01f39.unx.sas.com> Subject: Re: scsi disk (cam?) problems (inodes & swap?) In-Reply-To: <199811011628.AAA25291@spinner.netplex.com.au> from Peter Wemm at "Nov 2, 98 00:28:55 am" To: peter@netplex.com.au (Peter Wemm) Date: Sun, 1 Nov 1998 12:10:54 -0500 (EST) Cc: freebsd-current@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL38 (25)] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi, I do not use softupdates, and my machine is not smp. The build completed to the end of the 'make release', requiring 9 hours. However, I have not verified the contents of the distribution area. Yes, this build process works/worked correctly... I've been running it for about a year... failures are usually related to bad code... :-) # ls /pub/FreeBSD 3.0-19981027-SNAP 3.0-19981029-SNAP 3.0-19981030-SNAP 3.0-19981101-SNAP I'm more than happy to put some tracing code in, I'm just not real familiar with where it really needs to go to track these problems down... Thanks! John > "John W. DeBoskey" wrote: > > Hello, > > > > Since rebooting last evenning and running: > > > > cd /usr/src && make world && cd release && make release > > > > my system hasn't died, but the following have shown up in messages. > > fyi: my system has 256Meg of memory and I seriously doubt it ran out > > of swap, and the ccd filesystems fsck'd clean twice before I started > > the build. > > > > The cvsup msgs are normal, and left in for timing info only. > > > > Comments, critiques, & useful ideas are welcome... > > Thanks! > > John > > Did you have softupdates on? SMP? > > If you do not, then my immediate suspicion would be the changes I made > yesterday, perhaps loosing some metadata updates. > > On the other hand, the swap pager message is worrying, we've seen this > turning up before in the middle of other "strange" events. Did this > release build process work before the changes yesterday? > > Cheers, > -Peter > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Nov 1 10:01:16 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id KAA10384 for freebsd-current-outgoing; Sun, 1 Nov 1998 10:01:16 -0800 (PST) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from korin.warman.org.pl (korin.nask.waw.pl [148.81.160.10]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id KAA10370 for ; Sun, 1 Nov 1998 10:01:13 -0800 (PST) (envelope-from abial@nask.pl) Received: from localhost (abial@localhost) by korin.warman.org.pl (8.9.1/8.8.5) with SMTP id TAA00655; Sun, 1 Nov 1998 19:06:43 +0100 (CET) X-Authentication-Warning: korin.warman.org.pl: abial owned process doing -bs Date: Sun, 1 Nov 1998 19:06:42 +0100 (CET) From: Andrzej Bialecki X-Sender: abial@korin.warman.org.pl To: Mike Smith cc: current@FreeBSD.ORG Subject: Re: New boot loader and alternate kernels In-Reply-To: <199811010315.TAA00686@dingo.cdrom.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sat, 31 Oct 1998, Mike Smith wrote: > > abial# size libficl.a > > text data bss dec hex filename > > 2403 0 0 2403 963 dict.o (ex libficl.a) > > 989 20 0 1009 3f1 ficl.o (ex libficl.a) > > 892 0 0 892 37c math64.o (ex libficl.a) > > 63 3130 0 3193 c79 softcore.o (ex libficl.a) > > 674 0 0 674 2a2 stack.o (ex libficl.a) > > 253 0 0 253 fd sysdep.o (ex libficl.a) > > 2154 44 0 2198 896 vm.o (ex libficl.a) > > 18222 92 0 18314 478a words.o (ex libficl.a) > > > > (this can be still reduced if we limit ourselves to CORE words - I think > > 1/3 of words.o would go away). > > It builds a little bigger here; it weighs in at about 40k. If you > strip the OO extensions out it comes down to about 22k. I don't know I stripped LOCALS, multithreading, stack checking, but added KEY... Well, this is still around 20k. > whether there's much we can strip from the core wordset; I'll leave > that for the FORTH guruen to argue over. At 22k (plus whatever it As I said above, we probably can strip CORE-EXT and SEARCH - I wouldn't touch the CORE itself, however. > costs to bind it in) I think we have a goer. Doug's resolved the Alpha > space issues too, so it should be comfy. Great! I think we won't regret it... > > U __assert > > We need an assert. You mean: "anyway"? Because it's only as a diagnostics and can be defined as no-op. Andrzej Bialecki -------------------- ++-------++ ------------------------------------- ||PicoBSD|| FreeBSD in your pocket? Go and see: Research & Academic |+-------+| "Small & Embedded FreeBSD" Network in Poland | |TT~~~| | http://www.freebsd.org/~picobsd/ -------------------- ~-+==---+-+ ------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Nov 1 10:40:43 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id KAA15060 for freebsd-current-outgoing; Sun, 1 Nov 1998 10:40:43 -0800 (PST) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from smtp01.wxs.nl (smtp01.wxs.nl [195.121.6.61]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id KAA15054 for ; Sun, 1 Nov 1998 10:40:41 -0800 (PST) (envelope-from asmodai@wxs.nl) Received: from diabolique.ninth-circle.org ([195.121.59.72]) by smtp01.wxs.nl (Netscape Messaging Server 3.6) with ESMTP id AAA5CC; Sun, 1 Nov 1998 19:40:34 +0100 Message-ID: X-Mailer: XFMail 1.3 [p0] on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: Date: Sun, 01 Nov 1998 19:44:26 +0100 (CET) Organization: Ninth Circle Enterprises From: Jeroen Ruigrok/Asmodai To: Leif Neland Subject: Re: kernel compile problem Cc: Dmitry Valdov , freebsd-current@FreeBSD.ORG, Peter Wemm Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 01-Nov-98 Leif Neland wrote: >> > You got a cvsup in between commits.. Try again and you should be OK. >> >> just spotted this one too ;) >> >> How can ye make sure ye ain't between commits? cvsup it about 15-30 minutes >> later and try again to make? >> > How about if the committer started by committing > /usr/src/DONT_MAKE_WORLD_NOW > then committed various stuff, then removed > /usr/src/DONT_MAKE_WORLD_NOW > This file could contain an explanation why the world shouldn't be made. Nah, that wouldn't work that well... > The makefile should then check for the existance of this file. > > This could be implemented right now. It won't require updating cvsup and > cvsupd. > > But this will give problems when several people are updating different > parts of the tree... Exactly, then ye are going against what makes the commit system of cvsup work. > To make it more clean, it should be done in cvsupd and perhaps cvsup. > > It could be implemented by modifying using cvsupd's ability to check out > the version of the tree as it were on a certain time. > > The committer sends it a command/file/signal, and then new additions > made after that time is not seen by someone who requests the latest > versions. Exactly, does the term commit-relay express the idea completely? > After everything is committed, the committer removes the lock. Why the commiter? Make it so that the cvsupd places a lock temporarily whenever a commit finds place. Then after the person is through with his or her commits it makes all those updated files available to the public for cvsup. Make it so that the daemon does the work and not the commiter. This saves hassle. > Perhaps this should lock be on committer-resolution, so one committer > forgetting a lock/being hit by an 18-wheeler won't lock the entire tree. Well, what does cvsup do? It monitors versions. So the lock must be based on versioning too... > If somebody _really_ wants the latest versions, one could specify an > date=-1 or something instead of date=. > > What happens if somebody starts a cvsup, and files gets committed before > the cvsup is finished? Are those updates seen? If the lock is removed within the current session it might. Depends on what the cvsup already fetched... > The tag date=. shouldn't mean "as late as possible", but "at the start of > this cvsup-run", so to get a consistent snapshot of the tree. That will solve the above problem. But the daemon must tag all the files or queue them for every cvsup to know which files to send to which connection. > cvsupd should keep track of each clients starttime, and not supply later > checkouts. Indeed. This may require significant improvements to cvsupd and cvsup. But they might make the whole process more stable at any given point in time. Comments? --- Jeroen Ruigrok van der Werven/Asmodai asmodai(at)wxs.nl Junior Network/Security Specialist FreeBSD & picoBSD: The Power to Serve... To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Nov 1 10:52:31 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id KAA16175 for freebsd-current-outgoing; Sun, 1 Nov 1998 10:52:31 -0800 (PST) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from news2.du.gtn.com (news2.du.gtn.com [194.77.9.57] (may be forged)) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id KAA16160 for ; Sun, 1 Nov 1998 10:52:28 -0800 (PST) (envelope-from ticso@cicely5.cicely.de) Received: from cicely.cicely.de (cicely.de [194.231.9.142]) by news2.du.gtn.com (8.8.6/8.8.6) with ESMTP id TAA21109; Sun, 1 Nov 1998 19:52:09 +0100 (MET) Received: from cicely5.cicely.de (cicely5.cicely.de [10.1.1.7]) by cicely.cicely.de (8.8.8/8.8.8) with ESMTP id TAA20650; Sun, 1 Nov 1998 19:52:53 +0100 (CET) Received: (from ticso@localhost) by cicely5.cicely.de (8.9.0/8.9.0) id TAA15719; Sun, 1 Nov 1998 19:52:47 +0100 (CET) Message-ID: <19981101195246.10586@cicely.de> Date: Sun, 1 Nov 1998 19:52:46 +0100 From: Bernd Walter To: "Kenneth D. Merry" , "John W. DeBoskey" Cc: freebsd-current@FreeBSD.ORG Subject: Re: scsi disk (cam?) problems References: <199811010132.UAA04810@bb01f39.unx.sas.com> <199811010208.TAA27408@panzer.plutotech.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.89i In-Reply-To: <199811010208.TAA27408@panzer.plutotech.com>; from Kenneth D. Merry on Sat, Oct 31, 1998 at 07:08:50PM -0700 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sat, Oct 31, 1998 at 07:08:50PM -0700, Kenneth D. Merry wrote: > John W. DeBoskey wrote... > > Hi, > > > > My -CURRENT system has been experiencing problems since I converted > > it to cam awhile back. The following show up on my console, and then > > my disks are useless until I completely shutdown, powerdown my drive > > array, power it back on, and reboot. I have 4 identical drives configured > > as a ccd. They have been serving me well more about a year... > > > > If anyone has any ideas on how I can track down the problem, please > > let me know! > > > > Thanks, > > John > > > > /dev/ccd0a 2155550 1268428 714678 64% /snap > > /dev/ccd0b 2155550 1020154 962952 51% /usr/obj > > /dev/ccd0d 17244630 12876242 2988818 81% /pub > > > > Snipped from messages: (This kernel was built on the 28th), I'm now on > > a kernel built Oct 31. > [ ... ] > > > Oct 30 10:52:35 FreeBSD /kernel: (da2:ahc0:0:3:0): Invalidating pack > > Oct 30 10:52:35 FreeBSD /kernel: (da2:ahc0:0:3:0): Invalidating pack > > Well, what's happening here is that one of your disks is returning an > error, and keeps returning that error. Reads and writes in the da driver > have a retry count of 4. So by the time we print out the message above, > the command has already been retried four times. We may also have taken a > number of error recovery actions to try to bring the device back. > Very interesting. I've saw the same message yesterday: Oct 31 20:10:18 cicely5 /kernel: (da23:ahc4:0:1:0): Invalidating pack I was writing to a mounted fs on da23 during that I received this message. Can't unmount: root@cicely5# umount /mnt umount: /mnt: Device not configured But I can send commands via camcontrol to the drive. Rescan won't help. Havn't rebooted yet. Is there any way to get this drive working again without rebooting? > How often does this happen? Could you try booting with -v, and see if you > can reproduce the problem? I think that that (booting with -v) should > cause the error to be printed out. If I know the error, I may be able to > help you work around it, or at least tell you that one of your disks is on > the blink. For me it's the first and only one till now. -- Mfg B.Walter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Nov 1 11:03:02 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA17652 for freebsd-current-outgoing; Sun, 1 Nov 1998 11:03:02 -0800 (PST) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from narnia.plutotech.com (narnia.plutotech.com [206.168.67.130]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id LAA17647 for ; Sun, 1 Nov 1998 11:03:01 -0800 (PST) (envelope-from gibbs@narnia.plutotech.com) Received: (from gibbs@localhost) by narnia.plutotech.com (8.9.1/8.7.3) id LAA08811; Sun, 1 Nov 1998 11:56:01 -0700 (MST) Date: Sun, 1 Nov 1998 11:56:01 -0700 (MST) From: "Justin T. Gibbs" Message-Id: <199811011856.LAA08811@narnia.plutotech.com> To: Heiko Schaefer cc: current@FreeBSD.ORG Subject: Re: Problem with SCSI Harddisk X-Newsgroups: pluto.freebsd.current In-Reply-To: User-Agent: tin/pre-1.4-980818 ("Laura") (UNIX) (FreeBSD/3.0-BETA (i386)) Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In article you wrote: > Hello all, > > after checking the archives of this list (as well as freebsd-scsi), i > finally decided to post a problem that i have here. > i hope this is the right place and way to search for advice (and/or help). You should have posted to FreeBSD-scsi. The SCSI developers pay much more attention to that list (lower volume you know) than this one. > i have used this harddisk for quite some time without any problems that i > could notice under 2.2-STABLE. the problem seems to have started exactly > when updating my system to 3.0-CURRENT. > (by the way is there a 3.0-STABLE or will there be sometime soon ?!) ... > da3: Fixed Direct Access SCSI2 device > da3: 10.0MB/s transfers (10.0MHz, offset 15), Tagged Queueing Enabled > da3: 8669MB (17755614 512 byte sectors: 255H 63S/T 1105C) Seagate's web page doesn't list this drive model number... do you know the 'family name' for the drive? This drive shows a similar problem to the Seagate Elite 9 with certain levels of firmware. Essentially it wedges when you hit it wil a high tag load. I would suggest contacting Seagate technical support about this drive to see if later firmware is available. In the mean time, you should try adding a quirk entry to the table in sys/cam/cam_xpt.c that matches your drive. It may be that simply reducing the number of transactions to something less than 64 will prevent the drive from going nuts. Once you have a quirk entry that works for you, I'll commit it to the tree. BTW, the reason the 2940AU worked for you and the 2940UW did not is that the 2940AU cannot dish out transactions as quickly as the 2940UW. If you want high performance, I would suggest switching back to the 2940UW. See the chip comparison chart in the ahc(4) man page for more details. -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Nov 1 11:03:18 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA17716 for freebsd-current-outgoing; Sun, 1 Nov 1998 11:03:18 -0800 (PST) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from smtp05.wxs.nl (smtp05.wxs.nl [195.121.6.57]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id LAA17703 for ; Sun, 1 Nov 1998 11:03:14 -0800 (PST) (envelope-from asmodai@wxs.nl) Received: from diabolique.ninth-circle.org ([195.121.59.72]) by smtp05.wxs.nl (Netscape Messaging Server 3.6) with ESMTP id AAA1C03; Sun, 1 Nov 1998 19:03:07 +0100 Message-ID: X-Mailer: XFMail 1.3 [p0] on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <19981101225954.A29897@clear.co.nz> Date: Sun, 01 Nov 1998 20:06:59 +0100 (CET) Organization: Ninth Circle Enterprises From: Jeroen Ruigrok/Asmodai To: Joe Abley , John Polstra Subject: CVSup(d) (was: Re: kernel compile problem) Cc: freebsd-current@FreeBSD.ORG Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 01-Nov-98 Joe Abley wrote: > On Sun, Nov 01, 1998 at 07:44:52AM +0100, Leif Neland wrote: >> >> Is the problem that committing isn't 'atomical'? >> >> How about if the committer started by committing >> /usr/src/DONT_MAKE_WORLD_NOW >> then committed various stuff, then removed >> /usr/src/DONT_MAKE_WORLD_NOW >> This file could contain an explanation why the world shouldn't be made. >> >> The makefile should then check for the existance of this file. >> >> This could be implemented right now. It won't require updating cvsup and >> cvsupd. >> >> But this will give problems when several people are updating different >> parts of the tree... > > So we need a semaphore; however, a single lock file with a counter in it > doesn't sound very practical for cvsup. > > How about a directory called "lock" in whatever part of the source tree > is appropriate, into which committers deposit a file named with their e-mail > address, containing a description of why the source tree is locked? This will generate extra overhead and deletion of files. > bsd.subdir.mk could check for files within this subdirectory and fail > quoting the contents of any files that are present. > > The same branch of the tree could be locked by more than one committer > (since their respective lock files would have different names). > > Having lock directories at appropriate depths in the source tree would > be better than one "don't make world" lock file -- that way if I want > to rebuild and reinstall /usr/src/usr.bin/ I won't be affected by a > transient commit lock in /usr/src/usr.sbin/ (for example). Ye need to have it configurable at the lowest leaves possible instead of branches... > If no "lock" subdirectory is present, this should be interpreted as > "there are no locks for this branch". OK, what can we discern? 1) Need for multiple locks 2) The ability to cvsup a source tree that is commit free 3) The ability to commit changes regardless of the state of the tree 4) The ability for cvsupd to monitor versions every more carefully Did I miss somthing? --- Jeroen Ruigrok van der Werven/Asmodai asmodai(at)wxs.nl Junior Network/Security Specialist FreeBSD & picoBSD: The Power to Serve... To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Nov 1 11:09:48 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA18551 for freebsd-current-outgoing; Sun, 1 Nov 1998 11:09:48 -0800 (PST) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from smtp05.wxs.nl (smtp05.wxs.nl [195.121.6.57]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id LAA18486 for ; Sun, 1 Nov 1998 11:09:39 -0800 (PST) (envelope-from asmodai@wxs.nl) Received: from diabolique.ninth-circle.org ([195.121.59.72]) by smtp05.wxs.nl (Netscape Messaging Server 3.6) with ESMTP id AAA20F5; Sun, 1 Nov 1998 19:09:30 +0100 Message-ID: X-Mailer: XFMail 1.3 [p0] on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: Date: Sun, 01 Nov 1998 20:13:22 +0100 (CET) Organization: Ninth Circle Enterprises From: Jeroen Ruigrok/Asmodai To: current@FreeBSD.ORG Subject: Re: Another compile error Cc: John Polstra Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG OK, that did the trick, I haven't spotted Attic in the make run no more Now I am stuck with this: install -c -o root -g wheel -m 644 lkm/syscall/test/testsyscall.c /usr/share/examples/lkm/syscall/test/testsyscall.c install -c -o root -g wheel -m 644 lkm/syscall/TRANS.TBL /usr/share/examples/lkm/syscall/TRANS.TBL install -c -o root -g wheel -m 644 lkm/syscall/Makefile /usr/share/examples/lkm/syscall/Makefile install -c -o root -g wheel -m 644 lkm/syscall/README /usr/share/examples/lkm/syscall/README install -c -o root -g wheel -m 644 lkm/vfs/module/TRANS.TBL /usr/share/examples/lkm/vfs/module/TRANS.TBL install: /usr/share/examples/lkm/vfs/module/TRANS.TBL: No such file or directory *** Error code 71 Stop. *** Error code 1 If I look in src/share/examples/lkm/vfs/module/ of my cvs slice I see TRANS.TBL What could cause this error then? Thanks in advance, --- Jeroen Ruigrok van der Werven/Asmodai asmodai(at)wxs.nl Junior Network/Security Specialist FreeBSD & picoBSD: The Power to Serve... To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Nov 1 11:23:08 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA20679 for freebsd-current-outgoing; Sun, 1 Nov 1998 11:23:08 -0800 (PST) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from narnia.plutotech.com (narnia.plutotech.com [206.168.67.130]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id LAA20672 for ; Sun, 1 Nov 1998 11:23:07 -0800 (PST) (envelope-from gibbs@narnia.plutotech.com) Received: (from gibbs@localhost) by narnia.plutotech.com (8.9.1/8.7.3) id MAA08880; Sun, 1 Nov 1998 12:16:00 -0700 (MST) Date: Sun, 1 Nov 1998 12:16:00 -0700 (MST) From: "Justin T. Gibbs" Message-Id: <199811011916.MAA08880@narnia.plutotech.com> To: Peter Wemm cc: current@FreeBSD.ORG Subject: Re: Kernel threading (was Re: Thread Scheduler bug) X-Newsgroups: pluto.freebsd.current In-Reply-To: <199811011622.AAA25247@spinner.netplex.com.au> User-Agent: tin/pre-1.4-980818 ("Laura") (UNIX) (FreeBSD/3.0-BETA (i386)) Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In article <199811011622.AAA25247@spinner.netplex.com.au> you wrote: > > You need a kernel stack per thread in the lightweight model, up to a limit > of the number of cpus running, because it's needed for each possibly > active thread to make a syscall. I don't see how you can achieve such a limited number of stacks without a thread continuation model. If a thread calls tsleep while in kernel context, where does it's kernel stack go? If you always restart the thread from a thread continuation point, you can throw its stack away. This is certainly very desirable, but the impact on the kernel would be extremely large. -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Nov 1 11:25:30 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA20909 for freebsd-current-outgoing; Sun, 1 Nov 1998 11:25:30 -0800 (PST) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from pimout1-int.prodigy.net (pimout1-ext.prodigy.net [207.115.58.53]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id LAA20903 for ; Sun, 1 Nov 1998 11:25:28 -0800 (PST) (envelope-from ttran@usa.net) Received: from bigdog (HRFRB102-37.splitrock.net [209.156.68.37]) by pimout1-int.prodigy.net (8.8.5/8.8.5) with SMTP id OAA10310 for ; Sun, 1 Nov 1998 14:23:16 -0500 Reply-To: From: "Tho Tran" To: Date: Sun, 1 Nov 1998 14:31:19 -0500 Message-ID: <000001be05ce$33440450$010201c0@bigdog.shaolin.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Nov 1 11:26:51 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA21127 for freebsd-current-outgoing; Sun, 1 Nov 1998 11:26:51 -0800 (PST) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id LAA21121 for ; Sun, 1 Nov 1998 11:26:50 -0800 (PST) (envelope-from julian@whistle.com) Received: (from daemon@localhost) by alpo.whistle.com (8.8.5/8.8.5) id LAA18368; Sun, 1 Nov 1998 11:25:29 -0800 (PST) Received: from current1.whistle.com(207.76.205.22) via SMTP by alpo.whistle.com, id smtpds18365; Sun Nov 1 19:25:28 1998 Date: Sun, 1 Nov 1998 11:25:06 -0800 (PST) From: Julian Elischer To: "Richard Seaman, Jr." cc: John Birrell , "current@freebsd.org" Subject: Re: Kernel threading (was Re: Thread Scheduler bug) In-Reply-To: <199810312126.PAA23692@ns.tar.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I disagree slightly with the thought that syscalls can be unwrapped with kernel threads. The thread implementation I've seen discussed before is that where new threads are spawned by the kernel, until a limit is reached, after which user-level threading techniques are used to multiplex userlevel threads over a number of kernel level threads. julian On Sat, 31 Oct 1998, Richard Seaman, Jr. wrote: > On Sun, 1 Nov 1998 07:43:04 +1100 (EST), John Birrell wrote: > > >Richard Seaman, Jr. wrote: > > >Kernel threads should use libpthread and libc, not libc_r. > > Agreed, sort of. I don't use libc_r. If you're going to implement > deferred cancellation points, I think you still need to wrap some > syscalls, so you still need to generate a separate libc somewhere. > The "kernel" syscalls drop into libpthread, in a manner analagous > to what happens in libc_r, but the wrappers are different, and the > syscalls that are wrapped are different. > > >You can't mix > >kernel thread syscalls with user-thread syscalls because the styles are > >incompatible (blocking vs non-blocking). > > Agreed. A pure kernel thread implementation seems much simpler because > you just get rid of all the syscall wrapping that's needed to implement > user thread blocking i/o. Or, am I missing something? > > >You can't mix kernel thread > >scheduling with user-thread scheduling. > > Agreed. In kernel threads the kernel scheduler does all the work. > You can get rid of all the 19 pages of user thread scheduling code. > > >It doesn't sound like you have > >made any attempt to update the user-space knowledge of the running thread. > >As a result you will mix all errno codes and all user-space locking. This > >is a fundamental issue that needs to be designed, not hacked. > > Well, the user-space knowledge of the running thread comes from pthread_self, > which in the case I've implemented this comes from the code John Dyson > provided to the list a while back. errno codes are returned on the > thread stack, if I understand his code. > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-current" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Nov 1 11:29:24 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA21328 for freebsd-current-outgoing; Sun, 1 Nov 1998 11:29:24 -0800 (PST) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id LAA21322 for ; Sun, 1 Nov 1998 11:29:22 -0800 (PST) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.9.1/8.9.1) id OAA05742; Sun, 1 Nov 1998 14:29:09 -0500 (EST) (envelope-from wollman) Date: Sun, 1 Nov 1998 14:29:09 -0500 (EST) From: Garrett Wollman Message-Id: <199811011929.OAA05742@khavrinen.lcs.mit.edu> To: Chuck Robey Cc: John Hay , Garrett Wollman , current@FreeBSD.ORG Subject: Re: IPv6 in -current In-Reply-To: References: <199811010922.LAA05107@zibbi.mikom.csir.co.za> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG < said: > This would serve to give the ideas their best airing, allow the > developers to present their cases in the lowest possible pressure > consistent with public disclosure, and probably give the loser at least > the feeling that they'd certainly been listened to, so their would be > less likelihood of injured feelings. And, FreeBSD would most likely to > get the best IPv6 implementation from it. I frankly don't care that much which IPv6 implementation is chosen. My concerns are the following: 2) that we don't screw any of the existing developers 1) that we make whatever necessary fundamental advances we can in the network stack before taking on additional deadweight -GAWollman -- Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same wollman@lcs.mit.edu | O Siem / The fires of freedom Opinions not those of| Dance in the burning flame MIT, LCS, CRS, or NSA| - Susan Aglukark and Chad Irschick To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Nov 1 11:31:08 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA21533 for freebsd-current-outgoing; Sun, 1 Nov 1998 11:31:08 -0800 (PST) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from narnia.plutotech.com (narnia.plutotech.com [206.168.67.130]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id LAA21527 for ; Sun, 1 Nov 1998 11:31:07 -0800 (PST) (envelope-from gibbs@narnia.plutotech.com) Received: (from gibbs@localhost) by narnia.plutotech.com (8.9.1/8.7.3) id MAA08917; Sun, 1 Nov 1998 12:24:09 -0700 (MST) Date: Sun, 1 Nov 1998 12:24:09 -0700 (MST) From: "Justin T. Gibbs" Message-Id: <199811011924.MAA08917@narnia.plutotech.com> To: Bernd Walter cc: current@FreeBSD.ORG Subject: Re: scsi disk (cam?) problems X-Newsgroups: pluto.freebsd.current In-Reply-To: <199811010132.UAA04810@bb01f39.unx.sas.com> <199811010208.TAA27408@panzer.plutotech.com> <19981101195246.10586@cicely.de> User-Agent: tin/pre-1.4-980818 ("Laura") (UNIX) (FreeBSD/3.0-BETA (i386)) Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In article <19981101195246.10586@cicely.de> you wrote: > Very interesting. > I've saw the same message yesterday: > Oct 31 20:10:18 cicely5 /kernel: (da23:ahc4:0:1:0): Invalidating pack What kinds of power supplies are all of you using? The reason the pack is being invalidated is that the drive in question is not responding within a selection timeout period (250ms). This is usually because of a device no being there, but I suspect in this case the cause is a parallel I/O load that pushes your drives to their maximum power rating, saturating your power supply leaving one or more devices starving for power. Any I/O attempted while the drive is going through a power-on reset is likely to fail with a selection timeout. I will change the error handler for the selection timeout case to return EIO instead of ENXIO, but this is just a temporary work around until we can provide a better pack invalidation scheme in the system. -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Nov 1 11:57:47 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA26194 for freebsd-current-outgoing; Sun, 1 Nov 1998 11:57:47 -0800 (PST) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from dingo.cdrom.com (castles355.castles.com [208.214.167.55]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id LAA26186 for ; Sun, 1 Nov 1998 11:57:44 -0800 (PST) (envelope-from mike@dingo.cdrom.com) Received: from dingo.cdrom.com (LOCALHOST [127.0.0.1]) by dingo.cdrom.com (8.9.1/8.8.8) with ESMTP id LAA05322; Sun, 1 Nov 1998 11:57:16 -0800 (PST) (envelope-from mike@dingo.cdrom.com) Message-Id: <199811011957.LAA05322@dingo.cdrom.com> X-Mailer: exmh version 2.0.2 2/24/98 To: Chuck Robey cc: freebsd-current@FreeBSD.ORG Subject: Re: boot flags In-reply-to: Your message of "Sun, 01 Nov 1998 10:40:24 EST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 01 Nov 1998 11:57:15 -0800 From: Mike Smith Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > My boot.conf looks like: > > load kernel > autoboot 10 > > so far (I'll add modules next), but what's the syntax in that file to > add boot flags? I specifically (right now) want to add -v. If this is > defined somewhere, a pointer there would be fine. You can supply arguments when you load the kernel: load kernel -v You can also set many of them using environment variables: set boot_verbose and if you're using the 'boot' command, you can pass them there too: boot -v -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Nov 1 12:00:21 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id MAA26651 for freebsd-current-outgoing; Sun, 1 Nov 1998 12:00:21 -0800 (PST) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from dingo.cdrom.com (castles355.castles.com [208.214.167.55]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id MAA26641 for ; Sun, 1 Nov 1998 12:00:18 -0800 (PST) (envelope-from mike@dingo.cdrom.com) Received: from dingo.cdrom.com (LOCALHOST [127.0.0.1]) by dingo.cdrom.com (8.9.1/8.8.8) with ESMTP id LAA05344; Sun, 1 Nov 1998 11:59:50 -0800 (PST) (envelope-from mike@dingo.cdrom.com) Message-Id: <199811011959.LAA05344@dingo.cdrom.com> X-Mailer: exmh version 2.0.2 2/24/98 To: "Louis A. Mamakos" cc: freebsd-current@FreeBSD.ORG Subject: Re: boot flags In-reply-to: Your message of "Sun, 01 Nov 1998 10:47:14 EST." <199811011547.KAA15557@whizzo.transsys.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 01 Nov 1998 11:59:50 -0800 From: Mike Smith Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > My boot.conf looks like: > > > > load kernel > > autoboot 10 > > > > so far (I'll add modules next), but what's the syntax in that file to > > add boot flags? I specifically (right now) want to add -v. If this is > > defined somewhere, a pointer there would be fine. > > And while the question is being asked.. is there a way with the new > 3 stage boot loader to pass in a USERCONFIG configuration file? I used to > do this to configure some PNP peripherals. I'm guessing that this > function will probably now happen in /boot/loader, but that code doesn't > seem to be functional for this purpose yet. I'd be happy to hear otherwise. There isn't at this point in time. Unless you're constantly cycling kernels, the PnP information is saved into the booted kernel by dset, so you only need to set it once. Now that the kernel can receive arbitrary information passed in from the loader, you'll do something like this: load -t userconfig_script /boot/userconfi.script and userconfig will just run down the list of userconfig_script objects, executing commands out of them. I'll aim to get this done today. -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Nov 1 12:11:04 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id MAA28547 for freebsd-current-outgoing; Sun, 1 Nov 1998 12:11:04 -0800 (PST) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from pinhead.parag.codegen.com (ppp-asfm08--202.sirius.net [205.134.241.202]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id MAA28538 for ; Sun, 1 Nov 1998 12:11:02 -0800 (PST) (envelope-from parag@pinhead.parag.codegen.com) Received: from pinhead.parag.codegen.com (localhost.parag.codegen.com [127.0.0.1]) by pinhead.parag.codegen.com (8.9.1/8.8.8) with ESMTP id MAA17513; Sun, 1 Nov 1998 12:06:35 -0800 (PST) (envelope-from parag@pinhead.parag.codegen.com) Message-Id: <199811012006.MAA17513@pinhead.parag.codegen.com> X-Mailer: exmh version 2.0.2 2/24/98 To: Poul-Henning Kamp cc: Mikael Karpberg , mike@smith.net.au (Mike Smith), current@FreeBSD.ORG Subject: Re: New boot loader and alternate kernels In-reply-to: Your message of "Sun, 01 Nov 1998 16:01:00 +0100." <18026.909932460@critter.freebsd.dk> X-Face: =O'Kj74icvU|oS*<7gS/8'\Pbpm}okVj*@UC!IgkmZQAO!W[|iBiMs*|)n*`X ]pW%m>Oz_mK^Gdazsr.Z0/JsFS1uF8gBVIoChGwOy{EK=<6g?aHE`[\S]C]T0Wm X-URL: http://www.codegen.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 01 Nov 1998 12:06:35 -0800 From: Parag Patel Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <18026.909932460@critter.freebsd.dk>, Poul-Henning Kamp writes: >The "Open" boot prom on Suns and the various spinoffs from that use >forth for that reason. It's compact, it can be made machine independent >and there is a standard (several actually) so you don't have to invent >the host plate and the deep water all over again. Well, that was the original intention, but if you look at the OpenFirmware standard (IEEE-1275), the added stuff greatly expands the size. Our C implementation (SmartFirmware) is actually smaller than their native Forth implementation, both in code size and run-time data size (which was a big surprise to us) but is still bigger than a traditional Forth implementation. IEEE-1275 adds quite a lot on top of the ANS Forth spec. I think the main reason they went to Forth is to support plug-in boot ROMs using a byte-coded Forth called Fcode. It's the best choice if you want to have a machine-independent boot ROM on a plug-in card. They could have gone with a byte-encoded Lisp or BASIC or anything else, but Sun has a tendancy to base systems around Forth for some reason (Openview, Java, etc :-). -- Parag Patel To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Nov 1 12:29:00 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id MAA01287 for freebsd-current-outgoing; Sun, 1 Nov 1998 12:29:00 -0800 (PST) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id MAA01281 for ; Sun, 1 Nov 1998 12:28:57 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.1a/8.9.1) with ESMTP id VAA21674; Sun, 1 Nov 1998 21:28:48 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id VAA28186; Sun, 1 Nov 1998 21:28:47 +0100 (MET) Message-ID: <19981101212847.14447@follo.net> Date: Sun, 1 Nov 1998 21:28:47 +0100 From: Eivind Eklund To: Chuck Robey , John Hay Cc: Garrett Wollman , current@FreeBSD.ORG Subject: Re: IPv6 in -current References: <199811010922.LAA05107@zibbi.mikom.csir.co.za> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.89.1i In-Reply-To: ; from Chuck Robey on Sun, Nov 01, 1998 at 09:37:41AM -0500 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, Nov 01, 1998 at 09:37:41AM -0500, Chuck Robey wrote: > On Sun, 1 Nov 1998, John Hay wrote: > Would it be a reasonable thing to ask, that there be held an electronic > debate? It need not be broadcast realtime ... the idea being that each > team of developers be given the clearest possible chance to put forward > their ideas in a sort of a debate-type encounter. This could be done > via email to a 3rd party, a moderator, who would accumulate the results. > If it was done via email, then (although it would be slower) it would > not turn on momentary mistakes in phrasing so much as ability to present > themselves; such a dialog could take up to a week or more to actually > accumulate some presentable weight. This kind of debate is what I would like to see in freebsd-arch (with its new status as moderated but open to subscription by anybody). I don't think a moderated but open discussion would be a problem; I hope all of us (including the developers of each of the stacks) want to get an as good as possible result for FreeBSD, not just a result in the favour of ones 'original horse'. Eivind. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Nov 1 12:37:18 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id MAA02642 for freebsd-current-outgoing; Sun, 1 Nov 1998 12:37:18 -0800 (PST) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from whizzo.transsys.com (whizzo.TransSys.COM [144.202.42.10]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id MAA02636 for ; Sun, 1 Nov 1998 12:37:16 -0800 (PST) (envelope-from louie@whizzo.transsys.com) Received: from whizzo.transsys.com (localhost.transsys.com [127.0.0.1]) by whizzo.transsys.com (8.9.1/8.9.1) with ESMTP id PAA16366; Sun, 1 Nov 1998 15:37:03 -0500 (EST) (envelope-from louie@whizzo.transsys.com) Message-Id: <199811012037.PAA16366@whizzo.transsys.com> X-Mailer: exmh version 2.0.2 2/24/98 To: Mike Smith cc: freebsd-current@FreeBSD.ORG From: "Louis A. Mamakos" Subject: Re: boot flags References: <199811011959.LAA05344@dingo.cdrom.com> In-reply-to: Your message of "Sun, 01 Nov 1998 11:59:50 PST." <199811011959.LAA05344@dingo.cdrom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 01 Nov 1998 15:37:02 -0500 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG This is exactly what I had in mind, thanks! louie > Now that the kernel can receive arbitrary information passed in from > the loader, you'll do something like this: > > > load -t userconfig_script /boot/userconfi.script > > and userconfig will just run down the list of userconfig_script > objects, executing commands out of them. > > I'll aim to get this done today. > > -- > \\ Sometimes you're ahead, \\ Mike Smith > \\ sometimes you're behind. \\ mike@smith.net.au > \\ The race is long, and in the \\ msmith@freebsd.org > \\ end it's only with yourself. \\ msmith@cdrom.com > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Nov 1 13:21:13 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id NAA07864 for freebsd-current-outgoing; Sun, 1 Nov 1998 13:21:13 -0800 (PST) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from picnic.mat.net (picnic.mat.net [206.246.122.117]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id NAA07858 for ; Sun, 1 Nov 1998 13:21:11 -0800 (PST) (envelope-from chuckr@mat.net) Received: from localhost (chuckr@localhost) by picnic.mat.net (8.9.1/8.8.5) with ESMTP id QAA02201; Sun, 1 Nov 1998 16:19:57 -0500 (EST) Date: Sun, 1 Nov 1998 16:19:57 -0500 (EST) From: Chuck Robey To: Garrett Wollman cc: John Hay , current@FreeBSD.ORG Subject: Re: IPv6 in -current In-Reply-To: <199811011929.OAA05742@khavrinen.lcs.mit.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, 1 Nov 1998, Garrett Wollman wrote: > < said: > > > This would serve to give the ideas their best airing, allow the > > developers to present their cases in the lowest possible pressure > > consistent with public disclosure, and probably give the loser at least > > the feeling that they'd certainly been listened to, so their would be > > less likelihood of injured feelings. And, FreeBSD would most likely to > > get the best IPv6 implementation from it. > > I frankly don't care that much which IPv6 implementation is chosen. > My concerns are the following: > > 2) that we don't screw any of the existing developers > > 1) that we make whatever necessary fundamental advances we can in the > network stack before taking on additional deadweight That's true ... however, we need a balance between making sure things are right, and very long delays in getting things to that point. Garrett, you're obviously point man on #1, and we recognize it's a good point. Do you think we're in some sort of condition to wait for the kernel improvements (will some reasonable extra delay give us those fundamental advances, or just extra delay)? Are we talking a month, 3 months, a year, what? Need at least a feeling, I know asking for accuracy is ludicrous. Can't really evaluate the weight of your statement without some feeling about the chances of delay versus the chances of getting the improvements. ----------------------------+----------------------------------------------- Chuck Robey | Interests include any kind of voice or data chuckr@glue.umd.edu | communications topic, C programming, and Unix. 213 Lakeside Drive Apt T-1 | Greenbelt, MD 20770 | I run Journey2 and picnic (FreeBSD-current) (301) 220-2114 | and jaunt (NetBSD). ----------------------------+----------------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Nov 1 13:31:39 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id NAA09099 for freebsd-current-outgoing; Sun, 1 Nov 1998 13:31:39 -0800 (PST) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from ns11.rim.or.jp (ns11.rim.or.jp [202.247.130.230]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id NAA09094 for ; Sun, 1 Nov 1998 13:31:37 -0800 (PST) (envelope-from masafumi@aslm.rim.or.jp) Received: from rayearth.rim.or.jp (rayearth.rim.or.jp [202.247.130.242]) by ns11.rim.or.jp (8.8.5/3.5Wpl2-ns11/RIMNET-2) with ESMTP id GAA00223; Mon, 2 Nov 1998 06:31:32 +0900 (JST) Received: (from uucp@localhost) by rayearth.rim.or.jp (8.8.5/3.5Wpl2-uucp1/RIMNET) with UUCP id GAA28121; Mon, 2 Nov 1998 06:31:31 +0900 (JST) Received: from localhost (localhost [127.0.0.1]) by mail.aslm.rim.or.jp (8.9.1/3.5Wpl3-SMTP) with ESMTP id GAA01110; Mon, 2 Nov 1998 06:28:43 +0900 (JST) To: current@FreeBSD.ORG Cc: max@wide.ad.jp Subject: Panic on -current kernel From: Masafumi =?iso-2022-jp?B?TkFLQU5FLxskQkNmOiwybUo4GyhC?= X-Mailer: Mew version 1.93 on Emacs 20.3 / Mule 4.0 (HANANOEN) X-PGP-Fingerprint: 00 D8 2C CA C7 75 D4 40 5C 34 39 BA A5 46 C0 CC Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <19981102062842J.masafumi@aslm.rim.or.jp> Date: Mon, 02 Nov 1998 06:28:42 +0900 X-Dispatcher: imput version 980905(IM100) Lines: 189 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi, As I updated my system to -current as of about a week ago, it started to fail to boot up. I'm using a custom kernel and it dies as follows. It didn't have any problem before the update, and the situation remained the same when I tried to boot the box with kernel built from the latest sources. The latest GENERIC kernel, however, worked. The only major difference between the GENERIC and my custom one is the use of softupdates. So I disabled and retried, but it was not successful. The kernel configuration file is attached following the resulting output of the failure. If anyone has any idea what I may be doing wrong, I appreciate your suggestion. ---------------------------------------------------------------------- boot: Booting 0:sd(0,a)kernel @ 0x100000 text=0xff000 data=0x17000 bss=0x221f0 symbols=[+0xe10+0x4+0x135cc+0x4+0x1d134] total=0x269708 entry point=0x100000 BIOS basemem (637K) != RTC basemem (640K), setting to BIOS value Copyright (c) 1992-1998 FreeBSD Inc. Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. FreeBSD 3.0-CURRENT #34: Mon Nov 2 05:59:45 JST 1998 max@monster.jp.FreeBSD.ORG:/usr/src/sys/compile/MONSTER Timecounter "i8254" frequency 1193182 Hz Timecounter "TSC" frequency 299608746 Hz CPU: Pentium II (299.61-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x633 Stepping=3 Features=0x80fbff real memory = 268435456 (262144K bytes) avail memory = 258940928 (252872K bytes) Probing for devices on PCI bus 0: Correcting Natoma config for non-SMP chip0: rev 0x02 on pci0.0.0 chip1: rev 0x01 on pci0.1.0 chip2: rev 0x02 on pci0.13.0 vga0: rev 0x41 on pci0.14.0 Probing for devices on PCI bus 1: de0: rev 0x23 int a irq 10 on pci1.6.0 de0: ACCTON EN1203 21040 [10Mb/s] pass 2.3 de0: address 00:00:e8:0d:7d:e3 ncr0: rev 0x04 int a irq 0 on pci1.8.0 ncr1: rev 0x04 int a irq 11 on pci1.9.0 Probing for devices on the ISA bus: sc0 at 0x60-0x6f irq 1 on motherboard sc0: VGA color <16 virtual consoles, flags=0x0> sio0 at 0x3f8-0x3ff irq 4 flags 0x10 on isa sio0: type 16550A, console sio1 at 0x2f8-0x2ff irq 3 on isa sio1: type 16550A lpt0 at 0x378-0x37f irq 7 on isa lpt0: Interrupt-driven port lp0: TCP/IP capable interface fdc0 at 0x3f0-0x3f7 irq 6 drq 2 on isa fdc0: FIFO enabled, 8 bytes threshold fd0: 1.44MB 3.5in npx0 on motherboard npx0: INT 16 interface Waiting 8 seconds for SCSI devices to settle de0: enabling 10baseT port changing root devida0 at ncr1 bus 0 target 1 lun 0 da0: Fixed Direct Access SCSI2 device da0: 20.0MB/s transfers (20.0MHz, offset 15), Tagged Queueing Enabled da0: 4134MB (8467200 512 byte sectors: 255H 63S/T 527C) da1 at ncr1 bus 0 target 2 lun 0 da1: Fixed Direct Access SCSI2 device da1: 20.0MB/s transfers (20.0MHz, offset 15), Tagged Queueing Enabled da1: 4134MB (8467200 512 byte sectors: 255H 63S/T 527C) ce to da0s1a swapon: adding /dev/sd0s1b as swap device swapon: /dev/sd2s1b: Device not configured Automatic reboot in progress... /dev/rsd0s1a: clean, 9712 free (216 frags, 1187 blocks, 0.7% fragmentation) /dev/rsd0s1h: clean, 708954 free (13898 frags, 86882 blocks, 0.8% fragmentation) /dev/rsd0s1f: clean, 63502 free (14 frags, 7936 blocks, 0.0% fragmentation) /dev/rsd0s1g: clean, 549642 free (53154 frags, 62061 blocks, 3.3% fragmentation) /dev/rsd0s1e: clean, 251010 free (162 frags, 31356 blocks, 0.1% fragmentation) ffs_mountfs: superblock updated for soft updates ffs_mountfs: superblock updated for soft updates Doing initial network setup: hostname. lo0: flags=8049 mtu 16384 inet 127.0.0.1 netmask 0xff000000 de0: flags=8c43 mtu 1500 inet 203.178.141.172 netmask 0xffffffe0 broadcast 203.178.141.191 ether 00:00:e8:0d:7d:e3 media: autoselect (10baseT/UTP) status: active supported media: autoselect 10base5/AUI manual 10baseT/UTP 10baseT/UTP add net default: gateway 203.178.141.161 Additional routing options: tcp extensions=NO. routing daemons:. Mounting NFS file systems. clearing /tmp recording kernel -c changes additional daemons: syslogd. Doing additional network setup: ntpdate xntpd portmap. Starting final network daemons: mountd nfsd rpc.statd Fatal double fault: eip = 0xf01e1f40 esp = 0xf8802fb8 ebp = 0xefbfddb4 panic: double fault syncing disks... Fatal trap 12: page fault while in kernel mode fault virtual address = 0xb8 fault code = supervisor read, page not present instruction pointer = 0x8:0xf0129f6f stack pointer = 0x10:0xf022eec8 frame pointer = 0x10:0xf022eedc code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = nested task, resume, IOPL = 0 current process = Idle interrupt mask = net tty bio cam trap number = 12 panic: page fault Automatic reboot in 15 seconds - press a key on the console to abort Rebooting... ---------------------------------------------------------------------- The kernel config with all comment lines stripped. ---------------------------------------------------------------------- machine "i386" cpu "I686_CPU" ident MONSTER maxusers 50 options INET #InterNETworking options FFS #Berkeley Fast Filesystem options SOFTUPDATES options NFS #Network Filesystem options MFS #Memory File System options MSDOSFS #MSDOS Filesystem options "CD9660" #ISO 9660 Filesystem options PROCFS #Process filesystem options "COMPAT_43" #Compatible with BSD 4.3 [KEEP THIS!] options SCSI_DELAY=8000 #Be pessimistic about Joe SCSI device options UCONSOLE #Allow users to grab the console options FAILSAFE #Be conservative options USERCONFIG #boot -c editor options VISUAL_USERCONFIG #visual boot -c editor config kernel root on da0 controller isa0 controller eisa0 controller pci0 controller fdc0 at isa? port "IO_FD1" bio irq 6 drq 2 vector fdintr disk fd0 at fdc0 drive 0 disk fd1 at fdc0 drive 1 options "CMD640" # work around CMD640 chip deficiency controller ncr0 controller scbus0 device da0 device cd0 #Only need one of these, the code dynamically grows device sc0 at isa? port "IO_KBD" tty irq 1 vector scintr device npx0 at isa? port "IO_NPX" irq 13 vector npxintr device sio0 at isa? port "IO_COM1" tty flags 0x10 irq 4 vector siointr device sio1 at isa? port "IO_COM2" tty irq 3 vector siointr device lpt0 at isa? port? tty irq 7 vector lptintr device de0 pseudo-device loop pseudo-device ether pseudo-device pty 128 pseudo-device gzip # Exec gzipped a.out's pseudo-device bpfilter 16 #Berkeley packet filter options SYSVSHM options SYSVSEM options SYSVMSG options KTRACE #kernel tracing ---------------------------------------------------------------------- Cheers, Max To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Nov 1 14:10:22 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id OAA14942 for freebsd-current-outgoing; Sun, 1 Nov 1998 14:10:22 -0800 (PST) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from smtp04.wxs.nl (smtp04.wxs.nl [195.121.6.59]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id OAA14921 for ; Sun, 1 Nov 1998 14:10:16 -0800 (PST) (envelope-from asmodai@wxs.nl) Received: from diabolique.ninth-circle.org ([195.121.59.131]) by smtp04.wxs.nl (Netscape Messaging Server 3.6) with ESMTP id AAA2EDE for ; Sun, 1 Nov 1998 23:10:07 +0100 Message-ID: X-Mailer: XFMail 1.3 [p0] on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Date: Sun, 01 Nov 1998 23:14:01 +0100 (CET) Organization: Ninth Circle Enterprises From: Jeroen Ruigrok/Asmodai To: FreeBSD Current Subject: make install world problems Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Sorry to bug ye guys again, but make installworld is being a meanie to me ;) Apparantly from time to time the install goes well untill it reaches certain directories that do not exist: install -c -o root -g wheel -m 644 removeuser/TRANS.TBL /usr/share/examples/removeuser/TRANS.TBL install: /usr/share/examples/removeuser/TRANS.TBL: No such file or directory *** Error code 71 Stop. *** Error code 1 This is the same problem as the lkm/vfs/module directory problem I mentioned earlier. For some reasons these directories are not created. Any reason why they are being forgotten in the creation process? Because after I manually mkdir the directory the make installworld continues... install -c -o root -g wheel -m 644 sup/TRANS.TBL /usr/share/examples/sup/TRANS.TBL install: /usr/share/examples/sup/TRANS.TBL: No such file or directory *** Error code 71 And then it fails on a next one... It's not for every directory however... So I think I'll manage =) Hope someone can explain this behaviour. --- Jeroen Ruigrok van der Werven/Asmodai asmodai(at)wxs.nl Junior Network/Security Specialist FreeBSD & picoBSD: The Power to Serve... To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Nov 1 14:18:27 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id OAA15865 for freebsd-current-outgoing; Sun, 1 Nov 1998 14:18:27 -0800 (PST) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from mordred.cs.ucla.edu (Mordred.CS.UCLA.EDU [131.179.48.34]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id OAA15859 for ; Sun, 1 Nov 1998 14:18:26 -0800 (PST) (envelope-from scottm@mordred.cs.ucla.edu) Received: from mordred.cs.ucla.edu (localhost [127.0.0.1]) by mordred.cs.ucla.edu (8.9.1/8.9.1) with ESMTP id OAA16854; Sun, 1 Nov 1998 14:17:09 -0800 (PST) (envelope-from scottm@mordred.cs.ucla.edu) Message-Id: <199811012217.OAA16854@mordred.cs.ucla.edu> X-Mailer: exmh version 2.0.2 2/24/98 To: Chuck Robey cc: Garrett Wollman , John Hay , current@FreeBSD.ORG Subject: Re: IPv6 in -current In-reply-to: Your message of "Sun, 01 Nov 1998 16:19:57 EST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 01 Nov 1998 14:17:08 -0800 From: Scott Michel Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG There are a couple of people at UCLA CS in Lixia Zhang's lab who have experience working on the INRIA IPv6 code, as well as the CAIRN people who have been actively doing IPv6 and IPSEC in their version of the FreeBSD kernel (http://www.cairn.net/). I've posted a message to our UCLA Internet Research Lab list to see if anyone's interested/willing to do the integration. -scooter > On Sun, 1 Nov 1998, Garrett Wollman wrote: > > > < said: > > > > > This would serve to give the ideas their best airing, allow the > > > developers to present their cases in the lowest possible pressure > > > consistent with public disclosure, and probably give the loser at least > > > the feeling that they'd certainly been listened to, so their would be > > > less likelihood of injured feelings. And, FreeBSD would most likely to > > > get the best IPv6 implementation from it. > > > > I frankly don't care that much which IPv6 implementation is chosen. > > My concerns are the following: > > > > 2) that we don't screw any of the existing developers > > > > 1) that we make whatever necessary fundamental advances we can in the > > network stack before taking on additional deadweight > > That's true ... however, we need a balance between making sure things > are right, and very long delays in getting things to that point. > > Garrett, you're obviously point man on #1, and we recognize it's a good > point. Do you think we're in some sort of condition to wait for the > kernel improvements (will some reasonable extra delay give us those > fundamental advances, or just extra delay)? > > Are we talking a month, 3 months, a year, what? Need at least a > feeling, I know asking for accuracy is ludicrous. Can't really evaluate > the weight of your statement without some feeling about the chances of > delay versus the chances of getting the improvements. > > ----------------------------+----------------------------------------------- > Chuck Robey | Interests include any kind of voice or data > chuckr@glue.umd.edu | communications topic, C programming, and Unix. > 213 Lakeside Drive Apt T-1 | > Greenbelt, MD 20770 | I run Journey2 and picnic (FreeBSD-current) > (301) 220-2114 | and jaunt (NetBSD). > ----------------------------+----------------------------------------------- > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Nov 1 14:52:14 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id OAA20288 for freebsd-current-outgoing; Sun, 1 Nov 1998 14:52:14 -0800 (PST) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from gina.swimsuit.internet.dk (mail.swimsuit.internet.dk [194.255.12.232]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id OAA20282 for ; Sun, 1 Nov 1998 14:52:11 -0800 (PST) (envelope-from leifn@swimsuit.internet.dk) Received: from localhost (localhost.swimsuit.internet.dk [127.0.0.1]) by gina.swimsuit.internet.dk (8.9.1/8.9.1) with ESMTP id XAA01606; Sun, 1 Nov 1998 23:48:54 +0100 (CET) (envelope-from leifn@swimsuit.internet.dk) Date: Sun, 1 Nov 1998 23:48:54 +0100 (CET) From: Leif Neland To: Jeroen Ruigrok/Asmodai cc: Dmitry Valdov , freebsd-current@FreeBSD.ORG, Peter Wemm Subject: Re: kernel compile problem In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > It could be implemented by modifying using cvsupd's ability to check out > > the version of the tree as it were on a certain time. > > > > The committer sends it a command/file/signal, and then new additions > > made after that time is not seen by someone who requests the latest > > versions. > > Exactly, does the term commit-relay express the idea completely? > Nah, not really... I don't understand the word... > > After everything is committed, the committer removes the lock. > > Why the commiter? Make it so that the cvsupd places a lock temporarily whenever > a commit finds place. Then after the person is through with his or her commits > it makes all those updated files available to the public for cvsup. Make it so > that the daemon does the work and not the commiter. This saves hassle. > Not having done any committing, I guess a committer could make several changes in different parts of the tree, in smaller chunks. Only the committer will know when all the chunks have been committed. So only the committer should unlock the changes. As equivalent in the Oracle database, one session could make several changesin different table, but only after issuing a commit, all changes get visible for other sessions, and all at the same time. Leif To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Nov 1 15:04:19 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA21540 for freebsd-current-outgoing; Sun, 1 Nov 1998 15:04:19 -0800 (PST) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from smtp.datacomm.ch (unix.datacomm.ch [212.40.5.52]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id PAA21532 for ; Sun, 1 Nov 1998 15:04:16 -0800 (PST) (envelope-from tseidmann@simultan.ch) Received: from simultan.ch (line327.datacomm.ch [212.254.1.147]) by smtp.datacomm.ch (8.9.0/8.9.0) with ESMTP id AAA27777; Mon, 2 Nov 1998 00:02:22 +0100 Message-ID: <363CE849.B76F70FF@simultan.ch> Date: Mon, 02 Nov 1998 00:01:29 +0100 From: Thomas Seidmann X-Mailer: Mozilla 4.5 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Scott Michel CC: current@FreeBSD.ORG Subject: Re: IPv6 in -current References: <199811012217.OAA16854@mordred.cs.ucla.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Scott Michel wrote: > > There are a couple of people at UCLA CS in Lixia Zhang's lab who > have experience working on the INRIA IPv6 code, as well as the > CAIRN people who have been actively doing IPv6 and IPSEC in their > version of the FreeBSD kernel (http://www.cairn.net/). > > I've posted a message to our UCLA Internet Research Lab list to > see if anyone's interested/willing to do the integration. No matter how this discussion ends up, I'm starting to integrate INRIA IPv6 into current (on my local src tree, of course) starting from tomorrow. Whatever it will be used for :-) I am the one who started this thread and you'll hear from me. > -scooter Regards, Thomas To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Nov 1 15:11:43 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA22581 for freebsd-current-outgoing; Sun, 1 Nov 1998 15:11:43 -0800 (PST) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from news2.du.gtn.com (news2.du.gtn.com [194.77.9.57]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id PAA22573 for ; Sun, 1 Nov 1998 15:11:36 -0800 (PST) (envelope-from ticso@cicely5.cicely.de) Received: from cicely.cicely.de (cicely.de [194.231.9.142]) by news2.du.gtn.com (8.8.6/8.8.6) with ESMTP id AAA01037; Mon, 2 Nov 1998 00:11:08 +0100 (MET) Received: from cicely5.cicely.de (cicely5.cicely.de [10.1.1.7]) by cicely.cicely.de (8.8.8/8.8.8) with ESMTP id AAA21882; Mon, 2 Nov 1998 00:10:59 +0100 (CET) Received: (from ticso@localhost) by cicely5.cicely.de (8.9.0/8.9.0) id AAA15927; Mon, 2 Nov 1998 00:10:59 +0100 (CET) Message-ID: <19981102001058.41129@cicely.de> Date: Mon, 2 Nov 1998 00:10:58 +0100 From: Bernd Walter To: "Justin T. Gibbs" Cc: current@FreeBSD.ORG Subject: Re: scsi disk (cam?) problems References: <199811010132.UAA04810@bb01f39.unx.sas.com> <199811011924.MAA08917@narnia.plutotech.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.89i In-Reply-To: <199811011924.MAA08917@narnia.plutotech.com>; from Justin T. Gibbs on Sun, Nov 01, 1998 at 12:24:09PM -0700 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, Nov 01, 1998 at 12:24:09PM -0700, Justin T. Gibbs wrote: > In article <19981101195246.10586@cicely.de> you wrote: > > Very interesting. > > I've saw the same message yesterday: > > Oct 31 20:10:18 cicely5 /kernel: (da23:ahc4:0:1:0): Invalidating pack > > What kinds of power supplies are all of you using? The reason the It's a new Power-Supply so maybe it's broken. The supply has only this SCSI-Chain with 4-CDOMs 1 Streamer 1 HDD and this MO Drive. Only the MO Drive was used from this Supply at the time of the error. Don't shure about the cabeling, because it's only up for 2 days. I'll check it. > pack is being invalidated is that the drive in question is not > responding within a selection timeout period (250ms). This is That's long - but I don't know how the drive handles media-errors. At least my Win-NT Host on which the drive was connected before has done serveral bus-resets in case of an media-problem. They were reproduceable on the same sectors. So maybe the firmware s broken. > usually because of a device no being there, but I suspect in this > case the cause is a parallel I/O load that pushes your drives > to their maximum power rating, saturating your power supply leaving > one or more devices starving for power. Any I/O attempted while > the drive is going through a power-on reset is likely to fail with > a selection timeout. If it was a complete power-on reset the old SCSI-code would have given me some information about during the next access - I asume CAM is doing the same. In case of a bus-problem I'm used to see things like bus-resets. I don't realy like them - especialy with Streamers on the same bus - but I'm shure sometimes they are sensefull. What I don't understand is why the system can't recover from that failure. as mentioned earlier the drive is still accessable via camcontrol but not via the mounted fsdriver. > > I will change the error handler for the selection timeout case to > return EIO instead of ENXIO, but this is just a temporary work around By the way I'm not so deep into this - what are the differences? > until we can provide a better pack invalidation scheme in the system. > > -- > Justin -- Mfg B.Walter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Nov 1 15:19:57 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA24008 for freebsd-current-outgoing; Sun, 1 Nov 1998 15:19:57 -0800 (PST) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from smtp04.wxs.nl (smtp04.wxs.nl [195.121.6.59]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id PAA24000 for ; Sun, 1 Nov 1998 15:19:55 -0800 (PST) (envelope-from asmodai@wxs.nl) Received: from diabolique.ninth-circle.org ([195.121.59.131]) by smtp04.wxs.nl (Netscape Messaging Server 3.6) with ESMTP id AAA54E3; Mon, 2 Nov 1998 00:19:48 +0100 Message-ID: X-Mailer: XFMail 1.3 [p0] on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: Date: Mon, 02 Nov 1998 00:23:42 +0100 (CET) Organization: Ninth Circle Enterprises From: Jeroen Ruigrok/Asmodai To: Leif Neland Subject: Re: kernel compile problem Cc: Peter Wemm , freebsd-current@FreeBSD.ORG, Dmitry Valdov Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 01-Nov-98 Leif Neland wrote: >> > After everything is committed, the committer removes the lock. >> >> Why the commiter? Make it so that the cvsupd places a lock temporarily >> whenever >> a commit finds place. Then after the person is through with his or her >> commits >> it makes all those updated files available to the public for cvsup. Make it >> so >> that the daemon does the work and not the commiter. This saves hassle. >> > Not having done any committing, I guess a committer could make several > changes in different parts of the tree, in smaller chunks. Only the > committer will know when all the chunks have been committed. So only the > committer should unlock the changes. > > As equivalent in the Oracle database, one session could make several > changesin different table, but only after issuing a commit, all changes > get visible for other sessions, and all at the same time. That's what I meant =) Except the Daemon (in this case the Oracle database) allowed the changes. That's what I meant with the CVSupd too... The committer is expected to comm it. The Daemon is expected to handle all the administivia of the allowance/versioning. Hope this makes it clearer for the both of us. And the others offcourse =) --- Jeroen Ruigrok van der Werven/Asmodai asmodai(at)wxs.nl Junior Network/Security Specialist FreeBSD & picoBSD: The Power to Serve... To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Nov 1 15:34:55 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA25645 for freebsd-current-outgoing; Sun, 1 Nov 1998 15:34:55 -0800 (PST) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id PAA25639 for ; Sun, 1 Nov 1998 15:34:53 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.1a/8.9.1) with ESMTP id AAA23004; Mon, 2 Nov 1998 00:34:27 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id AAA29055; Mon, 2 Nov 1998 00:34:26 +0100 (MET) Message-ID: <19981102003426.04544@follo.net> Date: Mon, 2 Nov 1998 00:34:26 +0100 From: Eivind Eklund To: Jeroen Ruigrok/Asmodai , Leif Neland Cc: Peter Wemm , freebsd-current@FreeBSD.ORG, Dmitry Valdov Subject: Re: kernel compile problem References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.89.1i In-Reply-To: ; from Jeroen Ruigrok/Asmodai on Mon, Nov 02, 1998 at 12:23:42AM +0100 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, Nov 02, 1998 at 12:23:42AM +0100, Jeroen Ruigrok/Asmodai wrote: > Except the Daemon (in this case the Oracle database) allowed the changes. > That's what I meant with the CVSupd too... The committer is expected to comm > it. The Daemon is expected to handle all the administivia of the > allowance/versioning. Hope this makes it clearer for the both of us. And the > others offcourse =) Sorry - this discussion is getting sort of useless. It _is_ possible to handle this within cvs/cvsup, but if we are to do that, we will have to create a lock for a single commit, and have cvsup grab the previous version if this lock is present (a commit is in progress). Making this will be a large set of changes both to cvs and cvsup. Due to the time available to the relevant developers, I believe this is to be very unlikely to happen. Besides this, I believe it would be less work to replace all of cvs and cvsup than to implement this within the present framework (if we allow the replacement to work against a real database instead of working with a self-made database). Eivind. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Nov 1 15:49:15 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA27439 for freebsd-current-outgoing; Sun, 1 Nov 1998 15:49:15 -0800 (PST) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from awfulhak.org (awfulhak.force9.co.uk [195.166.136.63]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id PAA27416 for ; Sun, 1 Nov 1998 15:49:11 -0800 (PST) (envelope-from brian@Awfulhak.org) Received: from woof.lan.awfulhak.org (root@woof.lan.Awfulhak.org [172.16.0.7]) by awfulhak.org (8.8.8/8.8.8) with ESMTP id XAA21034; Sun, 1 Nov 1998 23:47:53 GMT (envelope-from brian@Awfulhak.org) Received: from woof.lan.awfulhak.org (brian@localhost [127.0.0.1]) by woof.lan.awfulhak.org (8.9.1/8.9.1) with ESMTP id XAA29687; Sun, 1 Nov 1998 23:48:29 GMT (envelope-from brian@woof.lan.awfulhak.org) Message-Id: <199811012348.XAA29687@woof.lan.awfulhak.org> X-Mailer: exmh version 2.0.2 2/24/98 To: "John W. DeBoskey" cc: green@zone.syracuse.net (Brian Feldman), freebsd-current@FreeBSD.ORG Subject: Re: Changing sh for compatibility sake In-reply-to: Your message of "Sun, 01 Nov 1998 11:56:31 EST." <199811011656.LAA14169@bb01f39.unx.sas.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 01 Nov 1998 23:48:28 +0000 From: Brian Somers Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Hi, > > I sent mail to this list a few months ago... pdksh doesn't run > the tail-end of a pipe in the current shell environment, thus the > following doesn't work as expected: > > export FOUND=0 > ls | wc -l | while read fcnt; do > export FOUND=$fcnt > done > echo $FOUND [.....] The *only* shell I've ever seen that does this is the original ksh. I think it's a *great* feature, but it's also non-standard. With it, you can also echo hello there | read a b and get $a and $b back. Certainly, any version of sh, ash, zsh, bash and pdksh that I've seen execute everything in the pipe in a subshell. -- Brian , , Don't _EVER_ lose your sense of humour.... To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Nov 1 16:10:24 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id QAA02534 for freebsd-current-outgoing; Sun, 1 Nov 1998 16:10:24 -0800 (PST) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from pluto.plutotech.com (mail.plutotech.com [206.168.67.137]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id QAA02528 for ; Sun, 1 Nov 1998 16:10:22 -0800 (PST) (envelope-from gibbs@plutotech.com) Received: from narnia.plutotech.com (narnia.plutotech.com [206.168.67.130]) by pluto.plutotech.com (8.8.7/8.8.5) with ESMTP id RAA04209; Sun, 1 Nov 1998 17:10:12 -0700 (MST) Message-Id: <199811020010.RAA04209@pluto.plutotech.com> X-Mailer: exmh version 2.0.2 2/24/98 To: Bernd Walter cc: "Justin T. Gibbs" , current@FreeBSD.ORG Subject: Re: scsi disk (cam?) problems In-reply-to: Your message of "Mon, 02 Nov 1998 00:10:58 +0100." <19981102001058.41129@cicely.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 01 Nov 1998 17:03:23 -0700 From: "Justin T. Gibbs" Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >> pack is being invalidated is that the drive in question is not >> responding within a selection timeout period (250ms). This is >That's long - but I don't know how the drive handles media-errors. >At least my Win-NT Host on which the drive was connected before >has done serveral bus-resets in case of an media-problem. >They were reproduceable on the same sectors. >So maybe the firmware s broken. A media error may result in a command timeout, but not a selection timeout. A selection timeout occurs when you attempt to select a device in order to pass it a command. A command timeout occurs once you have issues a command to a device and are waiting for it to complete. If this MO device does not support tagged queuing, the selection timeout could only occur when we attempted to select it and the device was idle. >If it was a complete power-on reset the old SCSI-code would have given >me some information about during the next access - I asume CAM is doing >the same. It should print out an error, yes. In this case, we get the selection timeout first and stop talking to the device before we can even see that a unit attention event has occurred. >What I don't understand is why the system can't recover from that failure. >as mentioned earlier the drive is still accessable via camcontrol but not >via the mounted fsdriver. Because the driver wants to be sure you, the user, validate that the device has not been changed. You must unmount the device and remount it in order to use it. Only once all clients that had the da device open when the 'catastrophic' error occurred have closed the device will it accept and open and I/O again. The pass-thru device, as used by camcontrol, just passes commands directly to the device, and it doesn't perform the same kinds of tracking that the 'da' block device driver does. Just because the underlying device is the same does not mean that you are talking through the same driver. Multiple drivers can share the same underlying SCSI device in CAM. >> I will change the error handler for the selection timeout case to >> return EIO instead of ENXIO, but this is just a temporary work around > >By the way I'm not so deep into this - what are the differences? One says that there is no device there. The other indicates a per -transaction I/O error. EIO is retried, ENXIO is not. -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Nov 1 16:46:20 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id QAA07836 for freebsd-current-outgoing; Sun, 1 Nov 1998 16:46:20 -0800 (PST) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from dingo.cdrom.com (castles33.castles.com [208.214.165.33]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id QAA07826 for ; Sun, 1 Nov 1998 16:46:18 -0800 (PST) (envelope-from mike@dingo.cdrom.com) Received: from dingo.cdrom.com (LOCALHOST [127.0.0.1]) by dingo.cdrom.com (8.9.1/8.8.8) with ESMTP id QAA06857; Sun, 1 Nov 1998 16:45:47 -0800 (PST) (envelope-from mike@dingo.cdrom.com) Message-Id: <199811020045.QAA06857@dingo.cdrom.com> X-Mailer: exmh version 2.0.2 2/24/98 To: Mikael Karpberg cc: current@FreeBSD.ORG Subject: Re: New boot loader and alternate kernels In-reply-to: Your message of "Sun, 01 Nov 1998 15:47:20 +0100." <199811011447.PAA21479@ocean.campus.luth.se> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 01 Nov 1998 16:45:47 -0800 From: Mike Smith Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > According to Mike Smith: > > I have no desire to miss it. Give me a compact Forth interpreter that > > links against libstand and you'll be seeing it everywhere Real Soon. > > Eeep! Umm... what exactly does this mean? I mean... I don't know anyone > that knows forth... lots of people know sh. And a logical special > language (whic resembles sh and the other script languages) is not > real hard to learn either. Why mess it up and get forth in there? And > to do what exactly? Forth is a candidate because it can be implemented in a very compact fashion, and bytecoded Forth is also very compact. In situations where space is an issue, this gives it an enormous advantage. eg. the current trivial interpreter is about 10k (minus command implementations); this is about the same size as the complete Forth interpreter we're looking at. Using Forth gives us two major advantages: - Because we can construct bindings between primitives economically, additional functionality can be added with a correspondingly smaller accumulation of bloat. - The behaviour of the bootloader can be extended without having to rebuild it. It becomes possible to attach extra intelligence to the boot process allowing customisation eg. on a per-product or per-module basis. This is all very experimental, and I take your point about the learning curve very seriously. If you can propose an extensible language with a "traditional" syntax which can compete on a size basis (code, runtime usage and bytecode size) then I would be happy to consider it. -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Nov 1 16:47:45 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id QAA07968 for freebsd-current-outgoing; Sun, 1 Nov 1998 16:47:45 -0800 (PST) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from relay.nuxi.com (nuxi.cs.ucdavis.edu [128.120.56.38]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id QAA07959 for ; Sun, 1 Nov 1998 16:47:43 -0800 (PST) (envelope-from obrien@NUXI.com) Received: (from obrien@localhost) by relay.nuxi.com (8.9.1/8.9.1) id QAA22872; Sun, 1 Nov 1998 16:47:33 -0800 (PST) (envelope-from obrien) Message-ID: <19981101164732.A22829@nuxi.com> Date: Sun, 1 Nov 1998 16:47:32 -0800 From: "David O'Brien" To: Dom Mitchell Cc: current@FreeBSD.ORG Subject: Re: Shells for you and shells for me Reply-To: obrien@NUXI.com References: <3633C8F8.EF8E14D5@null.net> <19981026125133.A2717@netmonger.net> <19981029012621.A26396@nuxi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i In-Reply-To: ; from Dom Mitchell on Fri, Oct 30, 1998 at 01:25:20PM +0000 X-Operating-System: FreeBSD 3.0-CURRENT Organization: The NUXI BSD group X-PGP-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Keyid: 34F9F9D5 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, Oct 30, 1998 at 01:25:20PM +0000, Dom Mitchell wrote: > To be frank, I think that pdksh is definitely something that we should > be looking at for that reason alone. If we import it into the tree > and leave it installed as /bin/ksh, then people can test it at their > leisure to see if it is worth replacing /bin/sh, and we also gain a > ksh. It's a good situation. This sounds like a good compromise. Unless there is serious objections, I'll look into doing this. -- -- David (obrien@NUXI.ucdavis.edu -or- obrien@FreeBSD.org) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Nov 1 17:04:01 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id RAA09808 for freebsd-current-outgoing; Sun, 1 Nov 1998 17:04:01 -0800 (PST) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from foobar.franken.de (foobar.franken.de [194.94.249.81]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id RAA09789 for ; Sun, 1 Nov 1998 17:03:56 -0800 (PST) (envelope-from logix@foobar.franken.de) Received: (from logix@localhost) by foobar.franken.de (8.8.8/8.8.5) id CAA19372 for freebsd-current@FreeBSD.ORG; Mon, 2 Nov 1998 02:03:47 +0100 (CET) Message-ID: <19981102020346.A19337@foobar.franken.de> Date: Mon, 2 Nov 1998 02:03:46 +0100 From: Harold Gutch To: freebsd-current@FreeBSD.ORG Subject: ELF-kgdb on a.out-kernel Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i X-Organisation: BatmanSystemDistribution X-Mission: To free the world from the Penguin Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi, how do i use an ELF-gdb on an a.out-kernel ? Setting OBJFORMAT to "aout" doesn't help and gdb doesn't recognize the commandline-switch "-aout" (as other tools like nm do). -- bye, logix Sleep is an abstinence syndrome wich occurs due to lack of caffein. Wed Mar 4 04:53:33 CET 1998 #unix, ircnet To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Nov 1 17:14:04 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id RAA10612 for freebsd-current-outgoing; Sun, 1 Nov 1998 17:14:04 -0800 (PST) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id RAA10605 for ; Sun, 1 Nov 1998 17:14:01 -0800 (PST) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.9.1/8.9.1) id UAA08774; Sun, 1 Nov 1998 20:13:51 -0500 (EST) (envelope-from wollman) Date: Sun, 1 Nov 1998 20:13:51 -0500 (EST) From: Garrett Wollman Message-Id: <199811020113.UAA08774@khavrinen.lcs.mit.edu> To: Chuck Robey Cc: current@FreeBSD.ORG Subject: Re: IPv6 in -current In-Reply-To: References: <199811011929.OAA05742@khavrinen.lcs.mit.edu> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG < said: > Are we talking a month, 3 months, a year, what? Need at least a Hard to tell -- it depends on a lot of external factors. I'm currently working on a number of other things, and I know David Greenman has his own agenda as well. -GAWollman -- Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same wollman@lcs.mit.edu | O Siem / The fires of freedom Opinions not those of| Dance in the burning flame MIT, LCS, CRS, or NSA| - Susan Aglukark and Chad Irschick To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Nov 1 17:32:41 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id RAA12162 for freebsd-current-outgoing; Sun, 1 Nov 1998 17:32:41 -0800 (PST) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from dingo.cdrom.com (castles33.castles.com [208.214.165.33]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id RAA12154 for ; Sun, 1 Nov 1998 17:32:38 -0800 (PST) (envelope-from mike@dingo.cdrom.com) Received: from dingo.cdrom.com (LOCALHOST [127.0.0.1]) by dingo.cdrom.com (8.9.1/8.8.8) with ESMTP id RAA07047; Sun, 1 Nov 1998 17:31:52 -0800 (PST) (envelope-from mike@dingo.cdrom.com) Message-Id: <199811020131.RAA07047@dingo.cdrom.com> X-Mailer: exmh version 2.0.2 2/24/98 To: Andrzej Bialecki cc: Mike Smith , current@FreeBSD.ORG Subject: Re: New boot loader and alternate kernels In-reply-to: Your message of "Sun, 01 Nov 1998 19:06:42 +0100." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 01 Nov 1998 17:31:51 -0800 From: Mike Smith Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > It builds a little bigger here; it weighs in at about 40k. If you > > strip the OO extensions out it comes down to about 22k. I don't know > > I stripped LOCALS, multithreading, stack checking, but added KEY... Well, > this is still around 20k. Ok. Should I commit my working version so that we have a central place to perform the strip-down and integration? > > whether there's much we can strip from the core wordset; I'll leave > > that for the FORTH guruen to argue over. At 22k (plus whatever it > > As I said above, we probably can strip CORE-EXT and SEARCH - I wouldn't > touch the CORE itself, however. Again, being not much of a Forth head it's not clear whether we should keep all of the compiled-in functionality and just strip the things that can be reloaded at runtime. I guess that items that are of principal interest to a programmer should be conditionalised out, ie. produce a BFDK and a BFRT. 8) > > costs to bind it in) I think we have a goer. Doug's resolved the Alpha > > space issues too, so it should be comfy. > > Great! I think we won't regret it... I hope not. 8) I'm all in favour of extension languages but I'm still in two minds about whether Forth is going to be the right one for this job. > > > U __assert > > > > We need an assert. > > You mean: "anyway"? Because it's only as a diagnostics and can be defined > as no-op. I noticed. It should certainly be enabled in the BFDK. -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Nov 1 17:39:14 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id RAA12608 for freebsd-current-outgoing; Sun, 1 Nov 1998 17:39:14 -0800 (PST) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from baerenklau.de.freebsd.org (baerenklau.de.freebsd.org [195.185.195.14]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id RAA12601; Sun, 1 Nov 1998 17:39:09 -0800 (PST) (envelope-from wosch@panke.de.freebsd.org) Received: (from uucp@localhost) by baerenklau.de.freebsd.org (8.8.8/8.8.8) with UUCP id CAA26891; Mon, 2 Nov 1998 02:39:04 +0100 (CET) (envelope-from wosch@panke.de.freebsd.org) Received: (from wosch@localhost) by campa.panke.de.freebsd.org (8.8.8/8.8.8) id VAA03612; Sun, 1 Nov 1998 21:47:27 +0100 (MET) (envelope-from wosch) Message-ID: <19981101214725.A3577@panke.de.freebsd.org> Date: Sun, 1 Nov 1998 21:47:25 +0100 From: Wolfram Schneider To: current@FreeBSD.ORG Cc: wosch@FreeBSD.ORG Subject: Re: Missing IDE CD-ROM after 3.0 upgrade References: <19981025183809.A1096@panke.de.freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.1i In-Reply-To: <19981025183809.A1096@panke.de.freebsd.org>; from Wolfram Schneider on Sun, Oct 25, 1998 at 06:38:09PM +0100 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 1998-10-25 18:38:09 +0100, Wolfram Schneider wrote: > I just updated from 2.2.6R to 3.0. The new 3.0 kernel > does not find the CD-ROM anymore ;-( I tracked down the problem to a patch in Sep 1997. Before the patch my IDE CD-ROM was detected by the kernel. After the commit not ... Any change to fix this? Wolfram dyson 1997/09/20 00:41:58 PDT Modified files: sys/i386/conf LINT sys/i386/isa wd.c wdreg.h sys/pci ide_pci.c pcireg.h Log: Addition of support of the slightly rogue Promise IDE interface(Dyson), support of multiple PCI IDE controllers(Dyson), and some updates and cleanups from John Hood, who originally made our IDE DMA stuff work :-). I have run tests with 7 IDE drives connected to my system, all in DMA mode, with no errors. Modulo any bugs, this stuff makes IDE look really good (within it's limitations.) Submitted by: John Hood Revision Changes Path 1.368 +17 -2 src/sys/i386/conf/LINT 1.139 +55 -33 src/sys/i386/isa/wd.c 1.20 +7 -3 src/sys/i386/isa/wdreg.h 1.4 +1092 -614 src/sys/pci/ide_pci.c 1.19 +2 -1 src/sys/pci/pcireg.h To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Nov 1 18:46:44 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id SAA18714 for freebsd-current-outgoing; Sun, 1 Nov 1998 18:46:44 -0800 (PST) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from zeus.theinternet.com.au (zeus.theinternet.com.au [203.34.176.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id SAA18701 for ; Sun, 1 Nov 1998 18:46:40 -0800 (PST) (envelope-from akm@zeus.theinternet.com.au) Received: (from akm@localhost) by zeus.theinternet.com.au (8.8.7/8.8.7) id MAA19222 for freebsd-current@freebsd.org; Mon, 2 Nov 1998 12:45:45 +1000 (EST) (envelope-from akm) From: Andrew Kenneth Milton Message-Id: <199811020245.MAA19222@zeus.theinternet.com.au> Subject: Booting Elf Kernel To: freebsd-current@FreeBSD.ORG Date: Mon, 2 Nov 1998 12:45:45 +1000 (EST) X-Mailer: ELM [version 2.4ME+ PL32 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Is it possible to boot an ELF kernel? The Release Notes say that the kernel is still in aout format, but, is there a way? I don't have any active LKM's to worry about, and I'm reinstalling most of my stuff in ELF format anyway. -- Totally Holistic Enterprises Internet| P:+61 7 3870 0066 | Andrew The Internet (Aust) Pty Ltd | F:+61 7 3870 4477 | Milton ACN: 082 081 472 | M:+61 416 022 411 |72 Col .Sig PO Box 837 Indooroopilly QLD 4068 |akm@theinternet.com.au|Specialist To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Nov 1 19:07:36 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id TAA20822 for freebsd-current-outgoing; Sun, 1 Nov 1998 19:07:36 -0800 (PST) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from dan.emsphone.com (dan.emsphone.com [199.67.51.101]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id TAA20809 for ; Sun, 1 Nov 1998 19:07:32 -0800 (PST) (envelope-from dan@dan.emsphone.com) Received: (from dan@localhost) by dan.emsphone.com (8.9.1/8.9.1) id VAA21370; Sun, 1 Nov 1998 21:05:12 -0600 (CST) Date: Sun, 1 Nov 1998 21:05:12 -0600 From: Dan Nelson To: Brian Somers , "John W. DeBoskey" Cc: Brian Feldman , freebsd-current@FreeBSD.ORG Subject: Re: Changing sh for compatibility sake Message-ID: <19981101210512.A21213@emsphone.com> References: <199811011656.LAA14169@bb01f39.unx.sas.com> <199811012348.XAA29687@woof.lan.awfulhak.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.94.3i In-Reply-To: <199811012348.XAA29687@woof.lan.awfulhak.org>; from "Brian Somers" on Sun Nov 1 23:48:28 GMT 1998 X-OS: FreeBSD 2.2.7-STABLE Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In the last episode (Nov 01), Brian Somers said: > The *only* shell I've ever seen that does this is the original ksh. > I think it's a *great* feature, but it's also non-standard. With it, > you can also > > echo hello there | read a b > > and get $a and $b back. Certainly, any version of sh, ash, zsh, bash > and pdksh that I've seen execute everything in the pipe in a subshell. ? I thought standard procedure was to execute the last command in a pipe in the parent shell. Your command runs fine on zsh and bash (not ash though). -Dan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Nov 1 19:22:13 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id TAA22123 for freebsd-current-outgoing; Sun, 1 Nov 1998 19:22:13 -0800 (PST) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from lamb.sas.com (lamb.sas.com [192.35.83.8]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id TAA22116 for ; Sun, 1 Nov 1998 19:22:09 -0800 (PST) (envelope-from jwd@unx.sas.com) Received: from mozart (mozart.unx.sas.com [192.58.184.8]) by lamb.sas.com (8.9.1/8.9.1) with SMTP id WAA07719; Sun, 1 Nov 1998 22:21:48 -0500 (EST) Received: from bb01f39.unx.sas.com by mozart (5.65c/SAS/Domains/5-6-90) id AA14761; Sun, 1 Nov 1998 22:21:47 -0500 Received: (from jwd@localhost) by bb01f39.unx.sas.com (8.9.1/8.9.1) id WAA16023; Sun, 1 Nov 1998 22:21:40 -0500 (EST) (envelope-from jwd) From: "John W. DeBoskey" Message-Id: <199811020321.WAA16023@bb01f39.unx.sas.com> Subject: Re: scsi disk (cam?) problems (inodes & swap?) In-Reply-To: <199811011628.AAA25291@spinner.netplex.com.au> from Peter Wemm at "Nov 2, 98 00:28:55 am" To: peter@netplex.com.au (Peter Wemm) Date: Sun, 1 Nov 1998 22:21:40 -0500 (EST) Cc: freebsd-current@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL38 (25)] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi, A 2nd reply to this same msg: Softupdates: No SMP: No Anyways, just for grins, I 'umount'ed the 3 file systems I have on the ccd (they went down cleanly). Then I fsck'd them. The 1st two went fine. The 3rd gave: FreeBSD# umount /snap FreeBSD# fsck -y /dev/ccd0a ** /dev/rccd0a ** Last Mounted on /snap ** Phase 1 - Check Blocks and Sizes ** Phase 2 - Check Pathnames ** Phase 3 - Check Connectivity ** Phase 4 - Check Reference Counts LINK COUNT FILE I=146063 OWNER=root MODE=100444 SIZE=1771 MTIME=Oct 30 08:00 1998 COUNT 2 SHOULD BE 1 ADJUST? yes LINK COUNT FILE I=146065 OWNER=root MODE=100444 SIZE=2311 MTIME=Oct 30 08:00 1998 COUNT 2 SHOULD BE 1 ADJUST? yes ..... About 50 more of these deleted ... LINK COUNT FILE I=251568 OWNER=root MODE=100444 SIZE=1461 MTIME=Oct 30 08:00 1998 COUNT 2 SHOULD BE 1 ADJUST? yes LINK COUNT FILE I=257185 OWNER=root MODE=100444 SIZE=3727 MTIME=Oct 30 07:58 1998 COUNT 2 SHOULD BE 1 ADJUST? yes ** Phase 5 - Check Cyl groups 1628 files, 32592 used, 1045183 free (4143 frags, 130130 blocks, 0.4% fragmentation) ***** FILE SYSTEM WAS MODIFIED ***** FreeBSD# So, this make me wonder if we're really getting all the data to disk properly (and this from a clean umount). Comments, Critiques, and even stupid user remarks are welcome. Thanks! John > "John W. DeBoskey" wrote: > > Hello, > > > > Since rebooting last evenning and running: > > > > cd /usr/src && make world && cd release && make release > > > > my system hasn't died, but the following have shown up in messages. > > fyi: my system has 256Meg of memory and I seriously doubt it ran out > > of swap, and the ccd filesystems fsck'd clean twice before I started > > the build. > > > > The cvsup msgs are normal, and left in for timing info only. > > > > Comments, critiques, & useful ideas are welcome... > > Thanks! > > John > > Did you have softupdates on? SMP? > > If you do not, then my immediate suspicion would be the changes I made > yesterday, perhaps loosing some metadata updates. > > On the other hand, the swap pager message is worrying, we've seen this > turning up before in the middle of other "strange" events. Did this > release build process work before the changes yesterday? > > Cheers, > -Peter > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Nov 1 19:43:15 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id TAA24429 for freebsd-current-outgoing; Sun, 1 Nov 1998 19:43:15 -0800 (PST) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from rip.psg.com (rip.psg.com [147.28.0.39]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id TAA24421 for ; Sun, 1 Nov 1998 19:43:11 -0800 (PST) (envelope-from randy@psg.com) Received: from localhost (651 bytes) by rip.psg.com via sendmail with P:stdio/R:inet_resolve/T:smtp (sender: ) (ident using unix) id for ; Sun, 1 Nov 1998 19:43:05 -0800 (PST) (Smail-3.2.0.101 1997-Dec-17 #1 built 1998-Oct-13) Message-Id: Date: Sun, 1 Nov 1998 19:43:05 -0800 (PST) From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: freebsd-current@FreeBSD.ORG Subject: kerberos rlogin requires auth.conf Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG in kerberized rlogin there is the following fragment: k = auth_getval("auth_list"); if (k && !strstr(k, "kerberos")) use_kerberos = 0; this means that, for me to do a kerberos login from A to B, that A must have auth_list = .* kerberos in /etc/auth.conf i thought that auth.conf controlled how folk get access TO the system, not from it. randy To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Nov 1 20:12:54 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id UAA28953 for freebsd-current-outgoing; Sun, 1 Nov 1998 20:12:54 -0800 (PST) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from zone.syracuse.net (zone.syracuse.net [205.232.47.17]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id UAA28925 for ; Sun, 1 Nov 1998 20:12:51 -0800 (PST) (envelope-from green@zone.syracuse.net) Received: from localhost (green@localhost) by zone.syracuse.net (8.8.8/8.8.7) with ESMTP id XAA06386 for ; Sun, 1 Nov 1998 23:12:39 -0500 (EST) Date: Sun, 1 Nov 1998 23:12:38 -0500 (EST) From: Brian Feldman To: current@FreeBSD.ORG Subject: Linux clone() Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Okay, guys, I think I've gotten a linux clone() syscall implemented... As of now, I have nothing to test it with :( The only thing I have to try it with is MpegTV, and for some really crazy reason: linux_clone()->(1569, 1570); child eip=0xf00, esp=0x80ed0b4 Now come on, passing 0xf00 as the void *fn (really int (*fn)(void *)) is pretty damned bogus (but hey, it's not zero, so it turns into the child's instruction pointer...) If anyone has any REALY examples of programs to test with this, let me know.... This is a pretty important thing to have, when lots more apps use linuxthreads (i.e. StarOffice 5.0). Oh, BTW, someone tell me if this would be something really terrible to accidentally do in kernel space: printf("%d %d %#x %#x"); note no arguments... so far I don't notice any destabilization but I sure hope I didn't fudge up the kernel stack! Cheers, Brian Feldman ---patch follows--- diff -ur /usr/src/sys/i386/linux/linux_dummy.c usr/src/sys/i386/linux/linux_dummy.c --- /usr/src/sys/i386/linux/linux_dummy.c Thu Nov 6 14:28:52 1997 +++ usr/src/sys/i386/linux/linux_dummy.c Sun Nov 1 17:07:31 1998 @@ -212,13 +212,6 @@ } int -linux_clone(struct proc *p, struct linux_clone_args *args) -{ - printf("Linux-emul(%d): clone() not supported\n", p->p_pid); - return ENOSYS; -} - -int linux_uname(struct proc *p, struct linux_uname_args *args) { printf("Linux-emul(%d): uname() not supported\n", p->p_pid); diff -ur /usr/src/sys/i386/linux/linux_misc.c usr/src/sys/i386/linux/linux_misc.c --- /usr/src/sys/i386/linux/linux_misc.c Mon Oct 5 08:40:42 1998 +++ usr/src/sys/i386/linux/linux_misc.c Sun Nov 1 23:06:00 1998 @@ -41,6 +41,7 @@ #include #include #include +#include #include #include #include @@ -557,6 +558,31 @@ return error; if (p->p_retval[1] == 1) p->p_retval[0] = 0; + return 0; +} + +int +linux_clone(struct proc *p, struct linux_clone_args *args) +{ + int error; + struct proc *p2; + + if (error = fork1(p, RFPROC | RFMEM)) + return error; + p2 = pfind(p->p_retval[0]); + if (p2 == 0) + return ESRCH; + if (args->stack) + p2->p_md.md_regs->tf_esp = (int)args->stack; + if (args->fn) { + p2->p_md.md_regs->tf_eip = (int)args->fn; + copyout(&args->arg, (void *)p2->p_md.md_regs->tf_esp, sizeof(void *)); + p2->p_md.md_regs->tf_esp -= sizeof(void *); + } +#ifdef DEBUG_CLONE + printf("linux_clone()->(%d, %d); child eip=%#x, esp=%#x\n", p->p_pid, + p2->p_pid, p2->p_md.md_regs->tf_eip, p2->p_md.md_regs->tf_esp); +#endif return 0; } diff -ur /usr/src/sys/i386/linux/linux_proto.h usr/src/sys/i386/linux/linux_proto.h --- /usr/src/sys/i386/linux/linux_proto.h Fri Jul 10 18:30:04 1998 +++ usr/src/sys/i386/linux/linux_proto.h Sun Nov 1 17:07:31 1998 @@ -2,7 +2,7 @@ * System call prototypes. * * DO NOT EDIT-- this file is automatically generated. - * created from Id: syscalls.master,v 1.11 1998/06/09 03:28:14 bde Exp + * created from Id: syscalls.master,v 1.12 1998/07/10 22:30:08 jkh Exp */ #ifndef _LINUX_SYSPROTO_H_ @@ -301,7 +301,10 @@ struct linux_sigcontext * scp; char scp_[PAD_(struct linux_sigcontext *)]; }; struct linux_clone_args { - register_t dummy; + void * fn; char fn_[PAD_(void *)]; + void * stack; char stack_[PAD_(void *)]; + int flags; char flags_[PAD_(int)]; + void * arg; char arg_[PAD_(void *)]; }; struct linux_newuname_args { struct linux_newuname_t * buf; char buf_[PAD_(struct linux_newuname_t *)]; Only in usr/src/sys/i386/linux/: linux_proto.h.bak diff -ur /usr/src/sys/i386/linux/linux_syscall.h usr/src/sys/i386/linux/linux_syscall.h --- /usr/src/sys/i386/linux/linux_syscall.h Fri Jul 10 18:30:06 1998 +++ usr/src/sys/i386/linux/linux_syscall.h Sun Nov 1 17:07:31 1998 @@ -2,7 +2,7 @@ * System call numbers. * * DO NOT EDIT-- this file is automatically generated. - * created from Id: syscalls.master,v 1.11 1998/06/09 03:28:14 bde Exp + * created from Id: syscalls.master,v 1.12 1998/07/10 22:30:08 jkh Exp */ #define LINUX_SYS_linux_setup 0 Only in usr/src/sys/i386/linux/: linux_syscall.h.bak diff -ur /usr/src/sys/i386/linux/linux_sysent.c usr/src/sys/i386/linux/linux_sysent.c --- /usr/src/sys/i386/linux/linux_sysent.c Fri Jul 10 18:30:07 1998 +++ usr/src/sys/i386/linux/linux_sysent.c Sun Nov 1 17:07:31 1998 @@ -2,7 +2,7 @@ * System call switch table. * * DO NOT EDIT-- this file is automatically generated. - * created from Id: syscalls.master,v 1.11 1998/06/09 03:28:14 bde Exp + * created from Id: syscalls.master,v 1.12 1998/07/10 22:30:08 jkh Exp */ #include "opt_compat.h" @@ -134,7 +134,7 @@ { 5, (sy_call_t *)linux_ipc }, /* 117 = linux_ipc */ { 1, (sy_call_t *)fsync }, /* 118 = fsync */ { 1, (sy_call_t *)linux_sigreturn }, /* 119 = linux_sigreturn */ - { 0, (sy_call_t *)linux_clone }, /* 120 = linux_clone */ + { 4, (sy_call_t *)linux_clone }, /* 120 = linux_clone */ { 2, (sy_call_t *)setdomainname }, /* 121 = setdomainname */ { 1, (sy_call_t *)linux_newuname }, /* 122 = linux_newuname */ { 3, (sy_call_t *)linux_modify_ldt }, /* 123 = linux_modify_ldt */ Only in usr/src/sys/i386/linux/: linux_sysent.c.bak diff -ur /usr/src/sys/i386/linux/syscalls.master usr/src/sys/i386/linux/syscalls.master --- /usr/src/sys/i386/linux/syscalls.master Fri Jul 10 18:30:08 1998 +++ usr/src/sys/i386/linux/syscalls.master Sun Nov 1 17:07:31 1998 @@ -171,7 +171,8 @@ caddr_t ptr); } 118 NOPROTO LINUX { int fsync(int fd); } 119 STD LINUX { int linux_sigreturn(struct linux_sigcontext *scp); } -120 STD LINUX { int linux_clone(void); } +120 STD LINUX { int linux_clone(void *fn, void *stack,\ + int flags, void *arg); } 121 NOPROTO LINUX { int setdomainname(char *name, \ int len); } 122 STD LINUX { int linux_newuname(struct linux_newuname_t *buf); } To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Nov 1 20:15:16 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id UAA29245 for freebsd-current-outgoing; Sun, 1 Nov 1998 20:15:16 -0800 (PST) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from zone.syracuse.net (zone.syracuse.net [205.232.47.17]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id UAA29233 for ; Sun, 1 Nov 1998 20:15:14 -0800 (PST) (envelope-from green@zone.syracuse.net) Received: from localhost (green@localhost) by zone.syracuse.net (8.8.8/8.8.7) with ESMTP id XAA06405; Sun, 1 Nov 1998 23:15:06 -0500 (EST) Date: Sun, 1 Nov 1998 23:15:05 -0500 (EST) From: Brian Feldman To: "John W. DeBoskey" cc: freebsd-current@FreeBSD.ORG Subject: Re: Changing sh for compatibility sake In-Reply-To: <199811011656.LAA14169@bb01f39.unx.sas.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Well this is an interesting matter of discussion that is currently going around among pdksh developers, and is f course known. The "problem" is that pdksh uses seperate processes for reading, so they wouldn't be able to send data back. Stay tuned to pdksh development team news :) Cheers, Brian Feldman On Sun, 1 Nov 1998, John W. DeBoskey wrote: > Hi, > > I sent mail to this list a few months ago... pdksh doesn't run > the tail-end of a pipe in the current shell environment, thus the > following doesn't work as expected: > > export FOUND=0 > ls | wc -l | while read fcnt; do > export FOUND=$fcnt > done > echo $FOUND > > So, the comment below might need a slight modification to say > which scripts don't break... :-) > > Thanks! > John > > > Let me repeat this once more: not a SINGLE script breaks with pdksh! > > > > Brian Feldman > > > > On Mon, 26 Oct 1998, Kurt D. Zeilenga wrote: > > > > > Chuck wrote: > > > >I'm sorry, that's not true. Ask anyone who writes shell scripts that > > > >install software (or perform any necessarily portable function) across > > > >multiple platforms. sh is the shell to use ONLY BECAUSE it's the lowest > > > >common denominator. Why else would they use the dumbest shell? > > > > > > I've written numerous system/install sh scripts. But it's not to > > > one specific implementation, its many. It seems like every OS > > > has it's own variant of sh. I do not know of any version of sh > > > that can reliable used as a golden target sh. Each and very > > > implementation of sh has its quirks that have to be dealt with. > > > FreeBSD sh definitely has its, as do the others. > > > > > > Any change will likely cause problems in some existing scripts. > > > Also, any change will cause developers to deal with additional > > > portability issues. This is life. Most multiple platform sh > > > developers have already adapted to specific quicks of popular > > > sh implementations. Changing from one to another should not > > > be that big of a deal. I suspect a few FreeBSD-only sh scripts > > > will choke. > > > > > > Don't change sh for compatibility sake, our scripts are already > > > compatible! Do change for functionality sake, we'll adapt as > > > necessary. > > > > > > Kurt > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > > with "unsubscribe freebsd-current" in the body of the message > > > > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-current" in the body of the message > > > > ------------------------------ > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Nov 1 20:56:44 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id UAA04097 for freebsd-current-outgoing; Sun, 1 Nov 1998 20:56:44 -0800 (PST) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from rip.psg.com (rip.psg.com [147.28.0.39]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id UAA04085 for ; Sun, 1 Nov 1998 20:56:41 -0800 (PST) (envelope-from randy@psg.com) Received: from localhost (2831 bytes) by rip.psg.com via sendmail with P:stdio/R:inet_resolve/T:smtp (sender: ) (ident using unix) id for ; Sun, 1 Nov 1998 20:56:30 -0800 (PST) (Smail-3.2.0.101 1997-Dec-17 #1 built 1998-Oct-13) Message-Id: Date: Sun, 1 Nov 1998 20:56:30 -0800 (PST) From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: freebsd-current@FreeBSD.ORG Subject: screen not restored on exit of (less|more|vi|.*) Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG xserver on CURRENT, two xterms, each running current bash etc. o one to a bsdi 3.1 system (same on sunos, ...) o one to the same freebsd host say 'less foo' (or vi foo, or ...) o quit less on bsdi and the screen is restored. i.e., you see foo% more iddd.patch foo% i.e. all the remnants of less's output are gone, and the screen is restored exactly as it was before the command ran, with a new prompt right below the one that issued the command, even if it is mid-screen. o after running less on freebsd the screen is not restored. i.e. the remnants of less fill the screen with the new prompt on the bottom line of the xterm, and the previous prompt and screen obliterated. i prefer the former behavior, but do not understand how to cause the freebsd system to adopt it. looking at stty parms, the only differences are as follows: bsdi oflags: opost onlcr oxtabs ^^^^^^ cflags: cread cs8 -parenb -parodd hupcl -clocal -noclocal -cstopb ^^^^^^^^^ -cts_oflow -rts_iflow -mdmbuf ^^^^^^^^^^^^^^^^^^^^^ freebsd oflags: opost onlcr -oxtabs ^^^^^^^ cflags: cread cs8 -parenb -parodd hupcl -clocal -cstopb -crtscts -dsrflow -dtrflow -mdmbuf ^^^^^^^^^^^^^^^^^^^^^^^^^^ nothing tasty there. how about termcap? bsdi :al@:dl@:im=:ei=:mi@:ic=\E[@:\ :AL=\E[%dL:DC=\E[%dP:DL=\E[%dM:DO=\E[%dB:IC=\E[%d@:UP=\E[%dA:\ :al=\E[L:am:\ :bs:cd=\E[J:ce=\E[K:cl=\E[H\E[2J:cm=\E[%i%d;%dH:co#80:\ :cs=\E[%i%d;%dr:ct=\E[3k:\ :dc=\E[P:dl=\E[M:\ :im=\E[4h:ei=\E[4l:mi:\ :ho=\E[H:\ :is=\E[m\E[?7h\E[?1;3;4l\E[4l:\ :rs=\E[r\E[m\E[2J\E[H\E[?7h\E[?1;3;4;6l\E[4l\E<:\ :kb=^H:kd=\EOB:ke=\E[?1l\E>:\ :k1=\E[11~:k2=\E[12~:k3=\E[13~:k4=\E[14~:k5=\E[15~:\ :k6=\E[16~:k7=\E[17~:k8=\E[18~:\ :kl=\EOD:km:kn#8:kr=\EOC:ks=\E[?1h\E=:ku=\EOA:\ :li#65:md=\E[1m:me=\E[m:mr=\E[7m:ms:nd=\E[C:pt:\ :sc=\E7:rc=\E8:sf=\n:so=\E[7m:se=\E[m:sr=\EM:\ :te=\E[2J\E[?47l\E8:ti=\E7\E[?47h:\ :up=\E[A:us=\E[4m:ue=\E[m:xn: freebsd :li#65:\ :kh=\EOH:@7=\EOF:kb=^H:kD=^?:\ :k1=\EOP:k2=\EOQ:k3=\EOR:k4=\EOS:\ :hs:km:ts=\E[?E\E[?%i%dT:fs=\E[?F:es:ds=\E[?E:\ :is=\E>\E[?1;3;4;5l\E[?7;8h\E[1;65r\E[65;1H:\ :rs=\E>\E[?1;3;4;5l\E[?7;8h:\ :tc=vt220: but o replacing freebsd's with bsdi's (noting the te/ti) o rebuilding termcap.db o and starting a new xterm gives me the same result. any clues? randy To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Nov 1 21:07:28 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id VAA05722 for freebsd-current-outgoing; Sun, 1 Nov 1998 21:07:28 -0800 (PST) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from garman.dyn.ml.org (pm106-19.dialip.mich.net [192.195.231.221]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id VAA05715 for ; Sun, 1 Nov 1998 21:07:25 -0800 (PST) (envelope-from garman@garman.dyn.ml.org) Message-Id: <199811020507.VAA05715@hub.freebsd.org> Received: (qmail 22392 invoked from smtpd); 2 Nov 1998 05:08:08 -0000 Received: from localhost.garman.net (HELO garman.dyn.ml.org) (127.0.0.1) by localhost.garman.net with SMTP; 2 Nov 1998 05:08:08 -0000 Date: Mon, 2 Nov 1998 00:08:07 -0500 (EST) From: garman@earthling.net Reply-To: garman@earthling.net Subject: still problems with inetd & malloc... To: current@FreeBSD.ORG MIME-Version: 1.0 Content-Type: TEXT/plain; CHARSET=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG on my home machine (running -current as of yesterday) i'm still having problems with inetd... bash# telnet localhost 25 Trying 127.0.0.1... Connected to localhost. Escape character is '^]'. inetd in realloc(): warning: junk pointer, too low to make sense. inetd in free(): warning: junk pointer, too low to make sense. ... this is with only: bash# uptime 12:07AM up 7:23, 8 users, load averages: 0.34, 0.29, 0.21 is there anything I can do to help diagnose this? My machine is a pentiumII/300 with 96MB of memory, 150MB of swap (~50-60% in use at any time) running -current aout (haven't had the guts to upgrade to elf yet :)) my machine is not heavily loaded, it is simply my home workstation. inetd is used for the most part simply to invoke qmail for my incoming mail- around 200 msgs/day average. compiling inetd with debugging symbols and attaching gdb to it while running doesn't seem to resolve the symbols right... is there something i'm missing there? thanks -- Jason Garman http://garman.dyn.ml.org/ Student, University of Maryland garman@earthling.net And now... for the stupid-patent-of-the-week: Whois: JAG145 "...an attache case with destruct means for destroying the contents therein in response to a signal" -- patent no. US3643609, filed in 1969 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Nov 1 21:13:06 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id VAA06551 for freebsd-current-outgoing; Sun, 1 Nov 1998 21:13:06 -0800 (PST) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from relay.nuxi.com (nuxi.cs.ucdavis.edu [128.120.56.38]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id VAA06545 for ; Sun, 1 Nov 1998 21:13:04 -0800 (PST) (envelope-from obrien@NUXI.com) Received: (from obrien@localhost) by relay.nuxi.com (8.9.1/8.9.1) id VAA03306; Sun, 1 Nov 1998 21:12:57 -0800 (PST) (envelope-from obrien) Message-ID: <19981101211257.A3217@nuxi.com> Date: Sun, 1 Nov 1998 21:12:57 -0800 From: "David O'Brien" To: Garrett Wollman Cc: current@FreeBSD.ORG Subject: Re: IPv6 in -current Reply-To: obrien@NUXI.com References: <199811010922.LAA05107@zibbi.mikom.csir.co.za> <199811011929.OAA05742@khavrinen.lcs.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i In-Reply-To: <199811011929.OAA05742@khavrinen.lcs.mit.edu>; from Garrett Wollman on Sun, Nov 01, 1998 at 02:29:09PM -0500 X-Operating-System: FreeBSD 3.0-CURRENT Organization: The NUXI BSD group X-PGP-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Keyid: 34F9F9D5 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > I frankly don't care that much which IPv6 implementation is chosen. > My concerns are the following: So is sounds like those interested in IPv6 have the go-ahead to bring it into -CURRENT. -- -- David (obrien@NUXI.ucdavis.edu -or- obrien@FreeBSD.org) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Nov 1 21:23:50 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id VAA08362 for freebsd-current-outgoing; Sun, 1 Nov 1998 21:23:50 -0800 (PST) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id VAA08350 for ; Sun, 1 Nov 1998 21:23:48 -0800 (PST) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.9.1/8.9.1) id AAA18222; Mon, 2 Nov 1998 00:23:38 -0500 (EST) (envelope-from wollman) Date: Mon, 2 Nov 1998 00:23:38 -0500 (EST) From: Garrett Wollman Message-Id: <199811020523.AAA18222@khavrinen.lcs.mit.edu> To: obrien@NUXI.com Cc: Garrett Wollman , current@FreeBSD.ORG Subject: Re: IPv6 in -current In-Reply-To: <19981101211257.A3217@nuxi.com> References: <199811010922.LAA05107@zibbi.mikom.csir.co.za> <199811011929.OAA05742@khavrinen.lcs.mit.edu> <19981101211257.A3217@nuxi.com> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG < said: >> I frankly don't care that much which IPv6 implementation is chosen. >> My concerns are the following: > So is sounds like those interested in IPv6 have the go-ahead to bring it > into -CURRENT. No, they don't. Read what I wrote (and you oh-so-conveniently deleted). -GAWollman -- Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same wollman@lcs.mit.edu | O Siem / The fires of freedom Opinions not those of| Dance in the burning flame MIT, LCS, CRS, or NSA| - Susan Aglukark and Chad Irschick To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Nov 1 22:42:55 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id WAA19490 for freebsd-current-outgoing; Sun, 1 Nov 1998 22:42:55 -0800 (PST) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from paert.tse-online.de (paert.tse-online.de [194.97.69.172]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id WAA19386 for ; Sun, 1 Nov 1998 22:42:51 -0800 (PST) (envelope-from ab@paert.tse-online.de) Received: (qmail 7179 invoked by uid 1000); 2 Nov 1998 06:42:07 -0000 Message-ID: <19981102074207.B471@paert.tse-online.de> Date: Mon, 2 Nov 1998 07:42:07 +0100 From: Andreas Braukmann To: freebsd-current@FreeBSD.ORG Subject: Re: Changing sh for compatibility sake Mail-Followup-To: freebsd-current@FreeBSD.ORG References: <199811011656.LAA14169@bb01f39.unx.sas.com> <199811012348.XAA29687@woof.lan.awfulhak.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93i In-Reply-To: <199811012348.XAA29687@woof.lan.awfulhak.org>; from Brian Somers on Sun, Nov 01, 1998 at 11:48:28PM +0000 Organization: TSE TeleService GmbH Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi, On Sun, Nov 01, 1998 at 11:48:28PM +0000, Brian Somers wrote: > > pdksh doesn't run the tail-end of a pipe in the current shell > > environment, > you can also > echo hello there | read a b > and get $a and $b back. > Certainly, any version of sh, ash, zsh, bash and pdksh that > I've seen execute everything in the pipe in a subshell. Since I'm using constructions like this all the time (it is definitely a great feature), I just have to state: paert:[~] > echo hello there | read a b paert:[~] > echo $a $b hello there paert:[~] > I'm running zsh 3.0.5 as my interactive shell. -ab -- /// TSE TeleService GmbH | Gsf: Arne Reuter | /// Hovestrasse 14 | Andreas Braukmann | We do it with /// D-48351 Everswinkel | HRB: 1430, AG WAF | FreeBSD/SMP /// ------------------------------------------------------------------- /// PGP-Key: http://www.tse-online.de/~ab/public-key /// Key fingerprint: 12 13 EF BC 22 DD F4 B6 3C 25 C9 06 DC D3 45 9B To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Nov 1 23:17:22 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id XAA23042 for freebsd-current-outgoing; Sun, 1 Nov 1998 23:17:22 -0800 (PST) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from solaris.matti.ee (solaris.matti.ee [194.126.98.135]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id XAA23032 for ; Sun, 1 Nov 1998 23:17:19 -0800 (PST) (envelope-from vallo@myhakas.matti.ee) Received: from myhakas.matti.ee (vallo@myhakas [194.126.98.150]) by solaris.matti.ee (8.8.8/8.8.8.s) with ESMTP id JAA04570; Mon, 2 Nov 1998 09:17:12 +0200 (EET) Received: (from vallo@localhost) by myhakas.matti.ee (8.9.1/8.9.1) id JAA02732; Mon, 2 Nov 1998 09:17:12 +0200 (EET) (envelope-from vallo) Message-ID: <19981102091712.A2614@matti.ee> Date: Mon, 2 Nov 1998 09:17:12 +0200 From: Vallo Kallaste To: "Justin T. Gibbs" Cc: current@FreeBSD.ORG Subject: Re: scsi disk (cam?) problems Reply-To: vallo@matti.ee References: <199811010132.UAA04810@bb01f39.unx.sas.com> <199811011924.MAA08917@narnia.plutotech.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i In-Reply-To: <199811011924.MAA08917@narnia.plutotech.com>; from Justin T. Gibbs on Sun, Nov 01, 1998 at 12:24:09PM -0700 Organization: =?iso-8859-1?Q?AS_Matti_B=FCrootehnika?= Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG "Justin T. Gibbs" wrote: > What kinds of power supplies are all of you using? The reason the > pack is being invalidated is that the drive in question is not > responding within a selection timeout period (250ms). This is I'm using new ATX power supply and it may be defective. I don't know exactly because I have only 48 hours of uptime using this supply. If my hardware configuration matters anyhow, I have dual processor motherboard with two processors inserted, two Quantum UW disks, Toshiba cdrom and floppy. Nothing extraordinary which can suck all the power the supply can provide. I forgot to explain one thing while reporting error: I got the panic just after executing copy command 'copy -R * /opt2'. I mounted Windows95 cd and tried to copy all contents to hard drive. My cdrom drive is connected to an ncr scsi controller and hard disks to onboard adaptec. At that time all the filesystems were mounted with softupdates enabled. Vallo Kallaste vallo@matti.ee To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Nov 1 23:30:59 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id XAA24387 for freebsd-current-outgoing; Sun, 1 Nov 1998 23:30:59 -0800 (PST) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from spinner.netplex.com.au (spinner.netplex.com.au [202.12.86.3]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id XAA24373 for ; Sun, 1 Nov 1998 23:30:52 -0800 (PST) (envelope-from peter@netplex.com.au) Received: from spinner.netplex.com.au (localhost [127.0.0.1]) by spinner.netplex.com.au (8.9.1/8.9.1/Spinner) with ESMTP id PAA17256; Mon, 2 Nov 1998 15:30:17 +0800 (WST) (envelope-from peter@spinner.netplex.com.au) Message-Id: <199811020730.PAA17256@spinner.netplex.com.au> X-Mailer: exmh version 2.0.2 2/24/98 To: "Justin T. Gibbs" cc: current@FreeBSD.ORG Subject: Re: Kernel threading (was Re: Thread Scheduler bug) In-reply-to: Your message of "Sun, 01 Nov 1998 12:16:00 MST." <199811011916.MAA08880@narnia.plutotech.com> Date: Mon, 02 Nov 1998 15:30:16 +0800 From: Peter Wemm Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG "Justin T. Gibbs" wrote: > In article <199811011622.AAA25247@spinner.netplex.com.au> you wrote: > > > > You need a kernel stack per thread in the lightweight model, up to a limit > > of the number of cpus running, because it's needed for each possibly > > active thread to make a syscall. > > I don't see how you can achieve such a limited number of stacks > without a thread continuation model. If a thread calls tsleep > while in kernel context, where does it's kernel stack go? If you > always restart the thread from a thread continuation point, you > can throw its stack away. This is certainly very desirable, but > the impact on the kernel would be extremely large. Yes, sorry about that, I managed to confuse myself. I wasn't talking about thread continuation points, that's just too much work. I was more thinking more how the present arrangement of having the PCB, signal vectors, and pstats and kstack co-habitating the same pages would have to be revisited and that only a maximum of numcpu kstacks would be in memory at once. The hassle is the signal vectors etc would be per process, some of the pstats per thread, the rest per process, the pcb per thread, kstack per thread, etc. Trying to seperate it all out, keeping track of what goes where, while still perserving the ability to swap out the process and all it's stacks, upages, etc to keep the unswappable per-thread and per-process state to a minimum. The way to do this is probably to take the UPAGES out of kvm managed space and have a chunk of address space (next to the per-cpu pages perhaps) at a fixed address that holds swappable process state, all the kstacks wired in as needed etc. Doing swapping would be pretty easy then, and all this would be machdep parts right next to the existing UPAGES swap support. It would probably be worthwhile having idle thread kstack pages individually pageable, as well as 'swap the whole damn lot out'. Going down this path would probably require some sort of 'max kthreads per process' limit to enable address space layout. Cheers, -Peter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Nov 2 00:11:34 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id AAA29512 for freebsd-current-outgoing; Mon, 2 Nov 1998 00:11:34 -0800 (PST) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from dingo.cdrom.com (castles312.castles.com [208.214.167.12]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id AAA29506 for ; Mon, 2 Nov 1998 00:11:32 -0800 (PST) (envelope-from mike@dingo.cdrom.com) Received: from dingo.cdrom.com (LOCALHOST [127.0.0.1]) by dingo.cdrom.com (8.9.1/8.8.8) with ESMTP id AAA08861; Mon, 2 Nov 1998 00:10:39 -0800 (PST) (envelope-from mike@dingo.cdrom.com) Message-Id: <199811020810.AAA08861@dingo.cdrom.com> X-Mailer: exmh version 2.0.2 2/24/98 To: Randy Bush cc: freebsd-current@FreeBSD.ORG Subject: Re: screen not restored on exit of (less|more|vi|.*) In-reply-to: Your message of "Sun, 01 Nov 1998 20:56:30 PST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 02 Nov 1998 00:10:38 -0800 From: Mike Smith Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > xserver on CURRENT, two xterms, each running current bash etc. > o one to a bsdi 3.1 system (same on sunos, ...) > o one to the same freebsd host > > say 'less foo' (or vi foo, or ...) > > o quit less on bsdi and the screen is restored. i.e., you see > > foo% more iddd.patch > foo% > > i.e. all the remnants of less's output are gone, and the screen is > restored exactly as it was before the command ran, with a new prompt > right below the one that issued the command, even if it is mid-screen. > > o after running less on freebsd the screen is not restored. i.e. the > remnants of less fill the screen with the new prompt on the bottom > line of the xterm, and the previous prompt and screen obliterated. > > i prefer the former behavior, but do not understand how to cause the freebsd > system to adopt it. [... termcap ...] > but > o replacing freebsd's with bsdi's (noting the te/ti) > o rebuilding termcap.db > o and starting a new xterm > gives me the same result. > > any clues? It is indeed the te/ti escapes. I don't know what you've done, but it was decided by many people that the use of te/ti was basically ugly (and it has some bad associated bugs) so it was disabled. -- \\