From owner-freebsd-current Sun Oct 15 05:36:30 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id FAA23160 for current-outgoing; Sun, 15 Oct 1995 05:36:30 -0700 Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id FAA23155 for ; Sun, 15 Oct 1995 05:36:27 -0700 Received: from msmith@localhost by genesis.atrad.adelaide.edu.au (8.6.9/8.6.9) id WAA04392; Sun, 15 Oct 1995 22:38:20 +0930 From: Michael Smith Message-Id: <199510151308.WAA04392@genesis.atrad.adelaide.edu.au> Subject: Re: Boot floppy broken? To: root@io.cts.com (Morgan Davis) Date: Sun, 15 Oct 1995 22:38:19 +0930 (CST) Cc: current@freebsd.org In-Reply-To: <199510140853.BAA00175@io.cts.com> from "Morgan Davis" at Oct 14, 95 01:53:31 am Content-Type: text Content-Length: 842 Sender: owner-current@freebsd.org Precedence: bulk Morgan Davis stands accused of saying: > > I downloaded the 2.1.0-SNAP-951005 boot.flp and built a disk. Upon > booting it, I get the Boot prompt, but when it starts proceeding, the > cursor twirls about three or our characters-worth and then the > computer reboots everytime. > > I tried the same disk on another machine and it exhibited the same > behavior. Any ideas? I get the same results on an Amiga 4000 around here - maybe you're using one of them? -- ]] Mike Smith, Software Engineer msmith@atrad.adelaide.edu.au [[ ]] Genesis Software genesis@atrad.adelaide.edu.au [[ ]] High-speed data acquisition and [[ ]] realtime instrument control (ph/fax) +61-8-267-3039 [[ ]] My car has "demand start" -Terry Lambert UNIX: live FreeBSD or die! [[ From owner-freebsd-current Sun Oct 15 12:25:10 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id MAA06076 for current-outgoing; Sun, 15 Oct 1995 12:25:10 -0700 Received: from gilberto.physik.rwth-aachen.de (gilberto.physik.rwth-aachen.de [137.226.31.2]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id MAA06071 for ; Sun, 15 Oct 1995 12:25:03 -0700 Received: (from kuku@localhost) by gilberto.physik.rwth-aachen.de (8.6.11/8.6.9) id UAA06850 for freebsd-current@freefall.cdrom.com; Sun, 15 Oct 1995 20:22:49 +0100 Date: Sun, 15 Oct 1995 20:22:49 +0100 From: "Christoph P. Kukulies" Message-Id: <199510151922.UAA06850@gilberto.physik.rwth-aachen.de> To: freebsd-current@freefall.FreeBSD.org Subject: Re: make world bombs with -pipe option Sender: owner-current@FreeBSD.org Precedence: bulk OK, it isn't a MALLOC_OPTION thing. I changed everything back, no MALLOC_OPTIONS, -pipe in /etc/make.conf enabled and had /usr/obj as a directory on the same FS as /usr/src again. Make world ran fine. So it turns out that it must have to do something with having /usr/obj being a soft link to a different FS. (e.g. mkdir /u/obj ; ln -s /u/obj /usr/obj) Whenever I do that, make world fails with that said *** Error Code 139 after making libmsun. If anyone out there is using a similar configuration, could he do that next time he's making world, please? I'm clueless at the moment. /u is a WD 1.2 GB IDE disk here just for the record. Filesystem 1K-blocks Used Avail Capacity Mounted on /dev/wd0a 38991 19441 16430 54% / /dev/wd0s1e 38991 1889 33982 5% /var /dev/wd0s1f 649247 496745 100562 83% /usr /dev/wd1g 1209791 859764 253243 77% /u /dev/wd2g 257647 145007 99757 59% /home procfs 4 4 0 100% /proc --Chris Christoph P. U. Kukulies kuku@gil.physik.rwth-aachen.de From owner-freebsd-current Sun Oct 15 14:02:00 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id OAA10776 for current-outgoing; Sun, 15 Oct 1995 14:02:00 -0700 Received: from mailhub.cts.com (root@mailhub.cts.com [192.188.72.25]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id OAA10755 for ; Sun, 15 Oct 1995 14:01:51 -0700 Received: from io.cts.com by mailhub.cts.com with smtp (Smail3.1.29.1 #20) id m0t4aAb-000V3VC; Sun, 15 Oct 95 14:00 PDT Received: (from root@localhost) by io.cts.com (8.6.12/8.6.9) id OAA00977 for current@freebsd.org; Sun, 15 Oct 1995 14:01:50 -0700 From: Morgan Davis Message-Id: <199510152101.OAA00977@io.cts.com> Subject: top To: current@freebsd.org Date: Sun, 15 Oct 1995 14:01:49 -0700 (PDT) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 83 Sender: owner-current@freebsd.org Precedence: bulk Is there a version of top that runs under -current? If so, where could I find it? From owner-freebsd-current Sun Oct 15 14:08:33 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id OAA11325 for current-outgoing; Sun, 15 Oct 1995 14:08:33 -0700 Received: from grunt.grondar.za (grunt.grondar.za [196.7.18.129]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id OAA11315 for ; Sun, 15 Oct 1995 14:08:24 -0700 Received: from grumble.grondar.za (grumble.grondar.za [196.7.18.130]) by grunt.grondar.za (8.6.12/8.6.9) with ESMTP id XAA22827; Sun, 15 Oct 1995 23:08:02 +0200 Received: from localhost (localhost [127.0.0.1]) by grumble.grondar.za (8.6.12/8.6.9) with SMTP id XAA24893; Sun, 15 Oct 1995 23:08:01 +0200 Message-Id: <199510152108.XAA24893@grumble.grondar.za> X-Authentication-Warning: grumble.grondar.za: Host localhost didn't use HELO protocol To: Morgan Davis cc: current@FreeBSD.ORG Subject: Re: top Date: Sun, 15 Oct 1995 23:08:01 +0200 From: Mark Murray Sender: owner-current@FreeBSD.ORG Precedence: bulk > Is there a version of top that runs under -current? If so, where > could I find it? The one in ports works just fine. You may have to recompile it... M -- Mark Murray 46 Harvey Rd, Claremont, Cape Town 7700, South Africa +27 21 61-3768 GMT+0200 Finger mark@grumble.grondar.za for PGP key From owner-freebsd-current Sun Oct 15 21:32:56 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id VAA25351 for current-outgoing; Sun, 15 Oct 1995 21:32:56 -0700 Received: from sovcom.kiae.su (sovcom.kiae.su [144.206.136.1]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id VAA25345 for ; Sun, 15 Oct 1995 21:32:52 -0700 Received: by sovcom.kiae.su id AA26165 (5.65.kiae-1 for current@freebsd.org); Mon, 16 Oct 1995 07:18:11 +0300 Received: by sovcom.KIAE.su (UUMAIL/2.0); Mon, 16 Oct 95 07:18:11 +0300 Received: (from ache@localhost) by ache.dialup.demos.ru (8.6.11/8.6.9) id HAA00222 for current@freebsd.org; Mon, 16 Oct 1995 07:16:40 +0300 To: current@freebsd.org Message-Id: Organization: Olahm Ha-Yetzirah Date: Mon, 16 Oct 1995 07:16:39 +0300 (MSK) X-Mailer: Mail/@ [v2.40 FreeBSD] From: =?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?= (aka Andrey A. Chernov, Black Mage) X-Class: Fast Subject: I plan to change ENABLE_STARTUP_LOCALE behaviour... Lines: 17 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 738 Sender: owner-current@freebsd.org Precedence: bulk Since it is very hard to explain to user that he must set ENABLE_STARTUP_LOCALE additionly to LANG variable to make LANG locale active for ctype-oriented programs, I plan to make ENABLE_STARTUP_LOCALE as *default* case and introduce new variable DISABLE_STARTUP_LOCALE to disable thins thing (for debugging purposes f.e.). We need correct ctype as *default* because too many ctype-programs actively used now. If we agree on that, I'll do it. -- Andrey A. Chernov : And I rest so composedly, /Now, in my bed, ache@astral.msk.su : That any beholder /Might fancy me dead - FidoNet: 2:5020/230.3 : Might start at beholding me, /Thinking me dead. RELCOM Team,FreeBSD Team : E.A.Poe From "For Annie" 1849 From owner-freebsd-current Mon Oct 16 01:11:13 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id BAA29345 for current-outgoing; Mon, 16 Oct 1995 01:11:13 -0700 Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id BAA29317 for ; Mon, 16 Oct 1995 01:10:58 -0700 Received: from sax.sax.de by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id JAA13111; Mon, 16 Oct 1995 09:10:54 +0100 Received: by sax.sax.de (8.6.11/8.6.12-s1) with UUCP id JAA15623; Mon, 16 Oct 1995 09:10:53 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.6.12/8.6.9) id JAA24523; Mon, 16 Oct 1995 09:07:43 +0100 From: J Wunsch Message-Id: <199510160807.JAA24523@uriah.heep.sax.de> Subject: Re: I plan to change ENABLE_STARTUP_LOCALE behaviour... To: ache@astral.msk.su (=?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?=) Date: Mon, 16 Oct 1995 09:07:41 +0100 (MET) Cc: current@FreeBSD.ORG Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: from "=?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?=" at Oct 16, 95 07:16:39 am X-Phone: +49-351-2012 669 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 1064 Sender: owner-current@FreeBSD.ORG Precedence: bulk As =?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?= wrote: > > I plan to make ENABLE_STARTUP_LOCALE as *default* case > and introduce new variable DISABLE_STARTUP_LOCALE > to disable thins thing (for debugging purposes f.e.). I'm against it. You wrote: 3) It is useful only for <=8bit locales, so you can't call setlocale, multichars becomes damaged, you need to call reduced to 8bit setlocale version as done in crt0. 4) Using non-standard (non-POSIX/ANSI/etc) reduced setlocale in all sources cause portability problems. So either this is broken, and we cannot make it the default, or we should really put a ``setlocale(LC_CTYPE, "");'' on top of all system utilities that use functions. This is effectively the same as your crt0.o hack, but then it's obvious that it's part of the program. Right now, part of the utilities does the right thing (e.g. "vi"), and most others don't. -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-current Mon Oct 16 01:17:25 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id BAA29604 for current-outgoing; Mon, 16 Oct 1995 01:17:25 -0700 Received: from tfs.com (tfs.com [140.145.250.1]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id BAA29599 for ; Mon, 16 Oct 1995 01:17:21 -0700 Received: from critter.tfs.com by tfs.com (smail3.1.28.1) with SMTP id m0t4kjE-0003wJC; Mon, 16 Oct 95 01:17 PDT Received: from localhost (localhost [127.0.0.1]) by critter.tfs.com (8.6.11/8.6.9) with SMTP id JAA00296; Mon, 16 Oct 1995 09:17:08 +0100 X-Authentication-Warning: critter.tfs.com: Host localhost didn't use HELO protocol To: =?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?= (aka Andrey A. Chernov, Black Mage) cc: current@freebsd.org Subject: Re: I plan to change ENABLE_STARTUP_LOCALE behaviour... In-reply-to: Your message of "Mon, 16 Oct 1995 07:16:39 +0300." Date: Mon, 16 Oct 1995 09:17:08 +0100 Message-ID: <294.813831428@critter.tfs.com> From: Poul-Henning Kamp Sender: owner-current@freebsd.org Precedence: bulk > Since it is very hard to explain to user that he must > set ENABLE_STARTUP_LOCALE additionly to LANG variable > to make LANG locale active for ctype-oriented programs, > I plan to make ENABLE_STARTUP_LOCALE as *default* case > and introduce new variable DISABLE_STARTUP_LOCALE > to disable thins thing (for debugging purposes f.e.). > > We need correct ctype as *default* because too many > ctype-programs actively used now. > > If we agree on that, I'll do it. We don't agree, and don't do it until we do! -- Poul-Henning Kamp | phk@FreeBSD.ORG FreeBSD Core-team. http://www.freebsd.org/~phk | phk@login.dknet.dk Private mailbox. whois: [PHK] | phk@ref.tfs.com TRW Financial Systems, Inc. It will be some time yet before progress goes too far... (Poul Henningsen) From owner-freebsd-current Mon Oct 16 02:02:37 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id CAA01383 for current-outgoing; Mon, 16 Oct 1995 02:02:37 -0700 Received: from sequent.kiae.su (sequent.kiae.su [144.206.136.6]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id CAA01358 for ; Mon, 16 Oct 1995 02:02:23 -0700 Received: by sequent.kiae.su id AA28935 (5.65.kiae-2 ); Mon, 16 Oct 1995 12:46:17 +0400 Received: by sequent.KIAE.su (UUMAIL/2.0); Mon, 16 Oct 95 12:46:16 +0400 Received: (from ache@localhost) by ache.dialup.demos.ru (8.6.11/8.6.9) id LAA02051; Mon, 16 Oct 1995 11:35:22 +0300 To: Joerg Wunsch Cc: current@FreeBSD.ORG References: <199510160807.JAA24523@uriah.heep.sax.de> In-Reply-To: <199510160807.JAA24523@uriah.heep.sax.de>; from J Wunsch at Mon, 16 Oct 1995 09:07:41 +0100 (MET) Message-Id: Organization: Olahm Ha-Yetzirah Date: Mon, 16 Oct 1995 11:35:22 +0300 (MSK) X-Mailer: Mail/@ [v2.40 FreeBSD] From: =?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?= (aka Andrey A. Chernov, Black Mage) X-Class: Fast Subject: Re: I plan to change ENABLE_STARTUP_LOCALE behaviour... Lines: 46 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 2008 Sender: owner-current@FreeBSD.ORG Precedence: bulk In message <199510160807.JAA24523@uriah.heep.sax.de> J Wunsch writes: >As =?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?= wrote: >> >> I plan to make ENABLE_STARTUP_LOCALE as *default* case >> and introduce new variable DISABLE_STARTUP_LOCALE >> to disable thins thing (for debugging purposes f.e.). >I'm against it. You wrote: >3) It is useful only for <=8bit locales, so you can't call setlocale, >multichars becomes damaged, you need to call reduced to 8bit >setlocale version as done in crt0. >4) Using non-standard (non-POSIX/ANSI/etc) reduced setlocale in >all sources cause portability problems. >So either this is broken, and we cannot make it the default, or we >should really put a ``setlocale(LC_CTYPE, "");'' on top of all system >utilities that use functions. This is effectively the same >as your crt0.o hack, but then it's obvious that it's part of the >program. >Right now, part of the utilities does the right thing (e.g. "vi"), and >most others don't. Really, I don't understand, how 3) and 4) related anyhow to my proposal. 'Broken' is result of your intention to put 'setlocale' call to all main()s. It is broken because of 3). If you change it to call used in crt0, it will be broken because of 4). In my case: 1) I don't put anything non-standard into main(). (crt0 already full of non-standard things). 2) I do right thing when LANG not set or set to "C" (ASCII per POSIX). 3) I do right thing for >8bit charsets (ASCII per POSIX). 4) I do right thing for pgms wich calls setlocale by itself like vi. 5) It is more easy to users and don't involve explanation each time. (I am already tired to say "setenv ENABLE_STARTUP_LOCALE" on each "fix" comes to -hackers list). -- Andrey A. Chernov : And I rest so composedly, /Now, in my bed, ache@astral.msk.su : That any beholder /Might fancy me dead - FidoNet: 2:5020/230.3 : Might start at beholding me, /Thinking me dead. RELCOM Team,FreeBSD Team : E.A.Poe From "For Annie" 1849 From owner-freebsd-current Mon Oct 16 02:04:24 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id CAA01501 for current-outgoing; Mon, 16 Oct 1995 02:04:24 -0700 Received: from sequent.kiae.su (sequent.kiae.su [144.206.136.6]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id CAA01490 for ; Mon, 16 Oct 1995 02:04:01 -0700 Received: by sequent.kiae.su id AA04097 (5.65.kiae-2 ); Mon, 16 Oct 1995 13:03:09 +0400 Received: by sequent.KIAE.su (UUMAIL/2.0); Mon, 16 Oct 95 13:03:08 +0300 Received: (from ache@localhost) by ache.dialup.demos.ru (8.6.11/8.6.9) id LAA02150; Mon, 16 Oct 1995 11:56:11 +0300 To: Poul-Henning Kamp Cc: current@freebsd.org References: <294.813831428@critter.tfs.com> In-Reply-To: <294.813831428@critter.tfs.com>; from Poul-Henning Kamp at Mon, 16 Oct 1995 09:17:08 +0100 Message-Id: Organization: Olahm Ha-Yetzirah Date: Mon, 16 Oct 1995 11:56:11 +0300 (MSK) X-Mailer: Mail/@ [v2.40 FreeBSD] From: =?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?= (aka Andrey A. Chernov, Black Mage) X-Class: Fast Subject: Re: I plan to change ENABLE_STARTUP_LOCALE behaviour... Lines: 26 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 1037 Sender: owner-current@freebsd.org Precedence: bulk In message <294.813831428@critter.tfs.com> Poul-Henning Kamp writes: >> Since it is very hard to explain to user that he must >> set ENABLE_STARTUP_LOCALE additionly to LANG variable >> to make LANG locale active for ctype-oriented programs, >> I plan to make ENABLE_STARTUP_LOCALE as *default* case >> and introduce new variable DISABLE_STARTUP_LOCALE >> to disable thins thing (for debugging purposes f.e.). >> >> We need correct ctype as *default* because too many >> ctype-programs actively used now. >> >> If we agree on that, I'll do it. >We don't agree, and don't do it until we do! If I asking for agreement, I don't plan to change it regardles of result, I assume it is pretty clear and don't understand purpose of this answer. -- Andrey A. Chernov : And I rest so composedly, /Now, in my bed, ache@astral.msk.su : That any beholder /Might fancy me dead - FidoNet: 2:5020/230.3 : Might start at beholding me, /Thinking me dead. RELCOM Team,FreeBSD Team : E.A.Poe From "For Annie" 1849 From owner-freebsd-current Mon Oct 16 02:14:20 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id CAA01884 for current-outgoing; Mon, 16 Oct 1995 02:14:20 -0700 Received: from eikon.e-technik.tu-muenchen.de (root@eikon.regent.e-technik.tu-muenchen.de [129.187.42.3]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id CAA01751 ; Mon, 16 Oct 1995 02:11:03 -0700 Received: from vector.eikon.e-technik.tu-muenchen.de (vector.eikon.e-technik.tu-muenchen.de [129.187.142.36]) by eikon.e-technik.tu-muenchen.de (8.6.12/8.6.9) with ESMTP id IAA10677; Mon, 16 Oct 1995 08:51:32 +0100 Received: (from jhs@localhost) by vector.eikon.e-technik.tu-muenchen.de (8.6.12/8.6.9) id LAA03738; Fri, 13 Oct 1995 11:05:50 +0100 Date: Fri, 13 Oct 1995 11:05:50 +0100 From: "Julian H. Stacey" Message-Id: <199510131005.LAA03738@vector.eikon.e-technik.tu-muenchen.de> To: current@freebsd.org Subject: Malloc warning: free(): already free chunk. Cc: jhs@freebsd.org Sender: owner-current@freebsd.org Precedence: bulk For our Malloc enthusiasts, a datum: I just got 4 of Malloc warning: free(): already free chunk. while doing a !q from vi. My /var partition (that holds var/tmp/vi.recover ) had filled up from other parallel work, so my current vi had a problem with :w (or maybe ZZ same difference really :-) so I made space, did :w again & got the Malloc message. The edited file seems OK. I am running a current system made locally yesterday with a `world', at src-cur CTM 1066 (the ctm is dated 1359 Oct 10 23:50 (TZ=GMT+1) ) Julian --- Julian H. Stacey EMAIL: jhs@freebsd.org WEB: http://www.freebsd.org/~jhs/ From owner-freebsd-current Mon Oct 16 03:48:11 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id DAA04544 for current-outgoing; Mon, 16 Oct 1995 03:48:11 -0700 Received: from tfs.com (tfs.com [140.145.250.1]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id DAA04539 for ; Mon, 16 Oct 1995 03:48:09 -0700 Received: from critter.tfs.com by tfs.com (smail3.1.28.1) with SMTP id m0t4n4f-0003vnC; Mon, 16 Oct 95 03:47 PDT Received: from localhost (localhost [127.0.0.1]) by critter.tfs.com (8.6.11/8.6.9) with SMTP id LAA00368; Mon, 16 Oct 1995 11:47:27 +0100 X-Authentication-Warning: critter.tfs.com: Host localhost didn't use HELO protocol To: =?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?= (aka Andrey A. Chernov, Black Mage) cc: current@freebsd.org Subject: Re: I plan to change ENABLE_STARTUP_LOCALE behaviour... In-reply-to: Your message of "Mon, 16 Oct 1995 11:56:11 +0300." Date: Mon, 16 Oct 1995 11:47:26 +0100 Message-ID: <366.813840446@critter.tfs.com> From: Poul-Henning Kamp Sender: owner-current@freebsd.org Precedence: bulk > >> We need correct ctype as *default* because too many > >> ctype-programs actively used now. > >> > >> If we agree on that, I'll do it. > > >We don't agree, and don't do it until we do! > > If I asking for agreement, I don't plan to change it > regardles of result, I assume it is pretty clear and don't > understand purpose of this answer. > Well, I've learnt that I need to speak up fast with you... :-) -- Poul-Henning Kamp | phk@FreeBSD.ORG FreeBSD Core-team. http://www.freebsd.org/~phk | phk@login.dknet.dk Private mailbox. whois: [PHK] | phk@ref.tfs.com TRW Financial Systems, Inc. It will be some time yet before progress goes too far... (Poul Henningsen) From owner-freebsd-current Mon Oct 16 04:42:07 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id EAA05600 for current-outgoing; Mon, 16 Oct 1995 04:42:07 -0700 Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id EAA05588 for ; Mon, 16 Oct 1995 04:42:01 -0700 Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id VAA24539 for current@freebsd.org; Mon, 16 Oct 1995 21:38:02 +1000 Date: Mon, 16 Oct 1995 21:38:02 +1000 From: Bruce Evans Message-Id: <199510161138.VAA24539@godzilla.zeta.org.au> To: current@freebsd.org Subject: lstat flushes namei cache entry Sender: owner-current@freebsd.org Precedence: bulk lstat() has been inefficient since symlinks were POSIXified. Bruce *** vfs_lookup.c~ Fri Aug 25 16:05:33 1995 --- vfs_lookup.c Mon Oct 16 21:06:30 1995 *************** *** 267,272 **** wantparent = cnp->cn_flags & (LOCKPARENT | WANTPARENT); docache = (cnp->cn_flags & NOCACHE) ^ NOCACHE; if (cnp->cn_nameiop == DELETE || ! (wantparent && cnp->cn_nameiop != CREATE)) docache = 0; rdonly = cnp->cn_flags & RDONLY; --- 280,297 ---- wantparent = cnp->cn_flags & (LOCKPARENT | WANTPARENT); docache = (cnp->cn_flags & NOCACHE) ^ NOCACHE; + /* + * XXX the following seems to be just to recover from not setting + * NOCACHE for the DELETE cases (unlink, rmdir and the rename + * source). In BSD4.4lite[2], docache was also cleared for the + * (wantparent && cnp->cn_nameiop == LOOKUP) case. This case + * seems to only occur for lstat and olstat, when it is wrong + * to clear docache. This case probably didn't occur before + * BSD4.4lite. LOCKPARENT was introduced for lstat to support + * the new behaviour of symlinks (attributes inherited from the + * parent. + */ if (cnp->cn_nameiop == DELETE || ! (wantparent && cnp->cn_nameiop != CREATE && ! cnp->cn_nameiop != LOOKUP)) docache = 0; rdonly = cnp->cn_flags & RDONLY; From owner-freebsd-current Mon Oct 16 06:29:53 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id GAA07923 for current-outgoing; Mon, 16 Oct 1995 06:29:53 -0700 Received: from sovcom.kiae.su (sovcom.kiae.su [144.206.136.1]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id GAA07885 ; Mon, 16 Oct 1995 06:29:13 -0700 Received: by sovcom.kiae.su id AA17580 (5.65.kiae-1 ); Mon, 16 Oct 1995 16:22:46 +0300 Received: by sovcom.KIAE.su (UUMAIL/2.0); Mon, 16 Oct 95 16:22:46 +0300 Received: (from ache@localhost) by ache.dialup.demos.ru (8.6.11/8.6.9) id QAA07025; Mon, 16 Oct 1995 16:21:34 +0300 To: current@freebsd.org Cc: Joerg Wunsch , phk@freebsd.org References: In-Reply-To: ; from =?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?= at Mon, 16 Oct 1995 07:16:39 +0300 (MSK) Message-Id: Organization: Olahm Ha-Yetzirah Date: Mon, 16 Oct 1995 16:21:33 +0300 (MSK) X-Mailer: Mail/@ [v2.40 FreeBSD] From: =?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?= (aka Andrey A. Chernov, Black Mage) X-Class: Fast Subject: Re: I plan to change ENABLE_STARTUP_LOCALE behaviour... Lines: 33 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 1463 Sender: owner-current@freebsd.org Precedence: bulk In message =?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?= writes: >Since it is very hard to explain to user that he must >set ENABLE_STARTUP_LOCALE additionly to LANG variable >to make LANG locale active for ctype-oriented programs, >I plan to make ENABLE_STARTUP_LOCALE as *default* case >and introduce new variable DISABLE_STARTUP_LOCALE >to disable thins thing (for debugging purposes f.e.). Well, I feel somewhat stuck now because I don't see any clear argument against *proposed* change... Please, if you feel somehow unhappy with it, specify more clearly what you have against it _exactly_. I mean Joerg and Paul here first. BTW (I trying guess the questions :-) this change don't enlarge or reduce current bloat, it simple don't touch it at all. What it does is makes user more confortable to not set ENABLE_STARTUP_LOCALE each time when he sets his LANG variable. If you intentionly don't want to see your native language file names in ls output even if you set LANG variable, you can always do it by setting DISABLE_STARTUP_LOCALE. If you don't set LANG variable at all, this change not affect you by any means. -- Andrey A. Chernov : And I rest so composedly, /Now, in my bed, ache@astral.msk.su : That any beholder /Might fancy me dead - FidoNet: 2:5020/230.3 : Might start at beholding me, /Thinking me dead. RELCOM Team,FreeBSD Team : E.A.Poe From "For Annie" 1849 From owner-freebsd-current Mon Oct 16 07:14:41 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id HAA08757 for current-outgoing; Mon, 16 Oct 1995 07:14:41 -0700 Received: from tfs.com (tfs.com [140.145.250.1]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id HAA08752 for ; Mon, 16 Oct 1995 07:14:37 -0700 Received: from critter.tfs.com by tfs.com (smail3.1.28.1) with SMTP id m0t4qIk-0003vtC; Mon, 16 Oct 95 07:14 PDT Received: from localhost (localhost [127.0.0.1]) by critter.tfs.com (8.6.11/8.6.9) with SMTP id PAA00539; Mon, 16 Oct 1995 15:14:12 +0100 X-Authentication-Warning: critter.tfs.com: Host localhost didn't use HELO protocol To: =?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?= (aka Andrey A. Chernov, Black Mage) cc: current@freebsd.org, Joerg Wunsch Subject: Re: I plan to change ENABLE_STARTUP_LOCALE behaviour... In-reply-to: Your message of "Mon, 16 Oct 1995 16:21:33 +0300." Date: Mon, 16 Oct 1995 15:14:12 +0100 Message-ID: <537.813852852@critter.tfs.com> From: Poul-Henning Kamp Sender: owner-current@freebsd.org Precedence: bulk > Well, I feel somewhat stuck now because I don't see any clear > argument against *proposed* change... Neither do I see any clear argument for the proposed change :-) -- Poul-Henning Kamp | phk@FreeBSD.ORG FreeBSD Core-team. http://www.freebsd.org/~phk | phk@login.dknet.dk Private mailbox. whois: [PHK] | phk@ref.tfs.com TRW Financial Systems, Inc. It will be some time yet before progress goes too far... (Poul Henningsen) From owner-freebsd-current Mon Oct 16 08:02:57 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id IAA10469 for current-outgoing; Mon, 16 Oct 1995 08:02:57 -0700 Received: from sequent.kiae.su (sequent.kiae.su [144.206.136.6]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id IAA10459 for ; Mon, 16 Oct 1995 08:02:38 -0700 Received: by sequent.kiae.su id AA07055 (5.65.kiae-2 ); Mon, 16 Oct 1995 19:00:37 +0400 Received: by sequent.KIAE.su (UUMAIL/2.0); Mon, 16 Oct 95 19:00:35 +0300 Received: (from ache@localhost) by ache.dialup.demos.ru (8.6.11/8.6.9) id RAA07563; Mon, 16 Oct 1995 17:52:10 +0300 To: Poul-Henning Kamp Cc: current@freebsd.org, Joerg Wunsch References: <537.813852852@critter.tfs.com> In-Reply-To: <537.813852852@critter.tfs.com>; from Poul-Henning Kamp at Mon, 16 Oct 1995 15:14:12 +0100 Message-Id: Organization: Olahm Ha-Yetzirah Date: Mon, 16 Oct 1995 17:52:10 +0300 (MSK) X-Mailer: Mail/@ [v2.40 FreeBSD] From: =?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?= (aka Andrey A. Chernov, Black Mage) X-Class: Fast Subject: Re: I plan to change ENABLE_STARTUP_LOCALE behaviour... Lines: 36 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 1818 Sender: owner-current@freebsd.org Precedence: bulk In message <537.813852852@critter.tfs.com> Poul-Henning Kamp writes: >> Well, I feel somewhat stuck now because I don't see any clear >> argument against *proposed* change... >Neither do I see any clear argument for the proposed change :-) Ok, I repeat it again maybe slightly different than in original message. (I suggest to read original message too, there was few words about DISABLE_STARTUP_LOCALE. Well, I suggest to read what I write maybe not each time but sometimes). Majority of users not understand (and not supposed to understand) that they need additionly setenv ENABLE_STARTUP_LOCALE when they set their LANG variable. They assumed that only LANG settings is enough for ls/talk/etc. work with national chars. I already tired reply to each "8bit fix" posted to -hackers this one phrase: setenv ENABLE_STARTUP_LOCALE. Some of such "fixes" was even sneaked to source tree and commits was backouted after my explanation. Well, maybe it isn't visible for you, but if you take responsibility on such things, it becomes visible, be shure. I assume here that user are right and it is more easy acts like he suppose than constantly teach everyone in the world. This user intention not breaks any standard, so let it be. I assume that you sometimes like to see your native language well imbedded into various FreeBSD pgms, do you really happy to type setenv ENABLE_STARTUP_LOCALE (well, maybe put it into .login) or explain this feature to everyone who asks instead of simple got-it-automatically when LANG is set? -- Andrey A. Chernov : And I rest so composedly, /Now, in my bed, ache@astral.msk.su : That any beholder /Might fancy me dead - FidoNet: 2:5020/230.3 : Might start at beholding me, /Thinking me dead. RELCOM Team,FreeBSD Team : E.A.Poe From "For Annie" 1849 From owner-freebsd-current Mon Oct 16 09:07:09 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id JAA12722 for current-outgoing; Mon, 16 Oct 1995 09:07:09 -0700 Received: from netrail.net (nathan@netrail.net [204.117.64.3]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id JAA12715 for ; Mon, 16 Oct 1995 09:07:05 -0700 Received: (from nathan@localhost) by netrail.net (8.6.12/8.6.12) id MAA03997; Mon, 16 Oct 1995 12:10:11 -0400 Date: Mon, 16 Oct 1995 12:10:11 -0400 (EDT) From: Nathan Stratton To: current@freebsd.org cc: et-users@netrail.net, freebsd-isp@netrail.net Subject: crash In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@freebsd.org Precedence: bulk I am using a 486 DX4 100 as a router, I have a T1 from sprint and a T1 form mci connected to it. I also have two 10 meg ethernet cards. It is running freebsd 2.0.5 and has about 31,000 routes in it's routing table. Well my problem is every day or so it will crash. My T1 cards need to be reset befoer they reboot so when the system reboots it just locks up becaue the T1 cards were not reset. I changed my reboot command to reset the cards, so if I do a shutdown it works great and resets my cards. But what it looks like when the system crashes it does not run reboot. What does it run? How can I make my system reset my T1 cards just after it crashes and befoer it reboots the system? This is the stuff it put on my screen when it crashed. Fatal trap 12: page fault while in kernel mode fault virtual address = 0x6d2039ca fault code = supervisor read, page no present instruction pointer = 0x8:0xf019ef8d code segmnt = base 0x0, limit 0xfffff, tuype 0x1b = DPL 0, pres 1, def32, gran 1 processor eflags = interupt enabled, resume, IOPL = 0 current process = Idle interrupt mask = net tty panic: page fault Nathan Stratton CEO, NetRail, Inc. Your Gateway to the World! --------------------------------------------------------------------------- Phone (703)524-4800 NetRail, Inc. Fax (703)534-5033 2007 N. 15 St. Suite B-5 Email sales@netrail.net Arlington, Va. 22201 WWW http://www.netrail.net/ Access: (703) 524-4802 guest --------------------------------------------------------------------------- From owner-freebsd-current Mon Oct 16 09:32:15 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id JAA13559 for current-outgoing; Mon, 16 Oct 1995 09:32:15 -0700 Received: from Root.COM (implode.Root.COM [198.145.90.17]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id JAA13554 for ; Mon, 16 Oct 1995 09:32:13 -0700 Received: from corbin.Root.COM (corbin [198.145.90.50]) by Root.COM (8.6.12/8.6.5) with ESMTP id JAA22964; Mon, 16 Oct 1995 09:32:00 -0700 Received: from localhost (localhost [127.0.0.1]) by corbin.Root.COM (8.6.12/8.6.5) with SMTP id JAA05537; Mon, 16 Oct 1995 09:27:05 -0700 Message-Id: <199510161627.JAA05537@corbin.Root.COM> To: Nathan Stratton cc: current@freebsd.org, et-users@netrail.net, freebsd-isp@netrail.net Subject: Re: crash In-reply-to: Your message of "Mon, 16 Oct 95 12:10:11 EDT." From: David Greenman Reply-To: davidg@Root.COM Date: Mon, 16 Oct 1995 09:27:05 -0700 Sender: owner-current@freebsd.org Precedence: bulk >I am using a 486 DX4 100 as a router, I have a T1 from sprint and a T1 >form mci connected to it. I also have two 10 meg ethernet cards. It is >running freebsd 2.0.5 and has about 31,000 routes in it's routing table. >Well my problem is every day or so it will crash. My T1 cards need to be >reset befoer they reboot so when the system reboots it just locks up >becaue the T1 cards were not reset. > >I changed my reboot command to reset the cards, so if I do a shutdown it >works great and resets my cards. But what it looks like when the system >crashes it does not run reboot. What does it run? How can I make my >system reset my T1 cards just after it crashes and befoer it reboots the >system? > >This is the stuff it put on my screen when it crashed. > >Fatal trap 12: page fault while in kernel mode >fault virtual address = 0x6d2039ca >fault code = supervisor read, page no present >instruction pointer = 0x8:0xf019ef8d >code segmnt = base 0x0, limit 0xfffff, tuype 0x1b > = DPL 0, pres 1, def32, gran 1 >processor eflags = interupt enabled, resume, IOPL = 0 >current process = Idle >interrupt mask = net tty >panic: page fault Would you send me a copy of your kernel config file, please? Also, could you do an 'nm /kernel | sort' and find the symbols around 0xf019ef8d and send this to me as well? Regarding resetting things: this should be done in the device driver. There is a driver shutdown hook that is called even when the system crashes, but better yet, the probe/attach in the driver should be fixed to reset the card properly so that this isn't an issue. -DG From owner-freebsd-current Mon Oct 16 11:37:33 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id LAA16880 for current-outgoing; Mon, 16 Oct 1995 11:37:33 -0700 Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id LAA16865 ; Mon, 16 Oct 1995 11:37:25 -0700 Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id LAA25019; Mon, 16 Oct 1995 11:31:03 -0700 From: Terry Lambert Message-Id: <199510161831.LAA25019@phaeton.artisoft.com> Subject: Re: getdtablesize() broken? To: bakul@netcom.com (Bakul Shah) Date: Mon, 16 Oct 1995 11:31:02 -0700 (MST) Cc: terry@lambert.org, bde@zeta.org.au, hackers@freefall.freebsd.org, rdm@ic.net, current@freefall.freebsd.org In-Reply-To: <199510150649.XAA15664@netcom15.netcom.com> from "Bakul Shah" at Oct 14, 95 11:49:24 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 3582 Sender: owner-current@FreeBSD.org Precedence: bulk > > The correct limit on the largest number is FD_SETSIZE, as defined in > > sys/types.h. > > IMHO limiting the fdset bitarray size like this *within* the > kernel is a mistake. I have an application where I run into > this and am forced to use a multi process solution. Imagine > a server handling > FD_SETSIZE (i.e. 256) TCP connections > to clients -- requests are not all that frequent and each > takes just a little bit of time to service so they *can* all > be handled by one process easily. A multi process solution > gets complicated (need to put shared state in shared memory, > use locking etc.) and slower (extra contex switches, > lock/unlock time). > > Using a limit of FD_SETSIZE does not buy you extra > protection or anything. RLIMIT_NOFILE is the right limit to > check against in kern/sys_generic.c:select(). Mercifully > this limit is changeable via sysctl so server machines can > up it. NetBSD, FreeBSD, Linux and may be even bsdi (I > haven't checked recently) are all guilty here. Small upper > limits is another thing that separates PeeCees from serious > server machines. > > Let me say this another way. If I can create N files, I > should damn well be able to select() on any one of them. You should damn well be able to use fopen() instead of open() to get at them as well. Checked out the stdio libraries on every OS from FreeBSD to Solaris to VMS lately? Stdio has a hard limit, generally by use of a character to store the fd. The problem is the same as the "unlimited open FD's" problem: stupid programs like BASH that are too lazy to "chase their tail" on descriptor assignments are going to go to the top end and "work down" on the assumption that they can split the FD domain into two name space. Using FD_SETSIZE or using RLIMIT_NOFILE, or getting the current open descriptor limit from the kernel (when the application has an explicit bitvector element limitation set at compile time, not because of a check for FD_SETSIZE by because declaration of a bit vector uses the FD_SETSIZE to declare the vector length) is equally stupid and equally succeptible to screwups. The "correct" way is to get rid of the interfaces which are succeptible to bad programming style. The user *SHOULD* be using the highest open FD in the set of FD's being selected upon, *NOT* some arbitrary constant. Select's FD count should *NEVER* be coded as a constant. Poll, anyone? Poll is inferior to select, both because of the 10ms limit on timeout resoloution and because select is often used with no descriptors to get a timeout and poll can't be used in this mode. Arguably one would want to use this type of timeout mechanism in place of interval timers to get both interval timers and an I/O timeout at the same time. The correct thing to do for BASH is to push the open FD up by 10 or so each time a collision occurs and to maintain an internal mapping table so that the FD used for the script being executed moves out of the way of collisions cause be explicit descript references in the script itself. Similarly, the correct way to use select is to use the highest open descriptor as the highest open desciptor instead of some stupid arbitrary value (even if it does come from the kerne) and to min(FD_SETSIZE) and that value because if you don't, you are going to run off the end of the bit vector and SIGSEGV (best case) or if into mapped memory, you will potentially destroy data (worst case). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-current Mon Oct 16 11:49:02 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id LAA17111 for current-outgoing; Mon, 16 Oct 1995 11:49:02 -0700 Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id LAA17106 for ; Mon, 16 Oct 1995 11:48:56 -0700 Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id LAA25077; Mon, 16 Oct 1995 11:44:02 -0700 From: Terry Lambert Message-Id: <199510161844.LAA25077@phaeton.artisoft.com> Subject: Re: lstat flushes namei cache entry To: bde@zeta.org.au (Bruce Evans) Date: Mon, 16 Oct 1995 11:44:01 -0700 (MST) Cc: current@freebsd.org In-Reply-To: <199510161138.VAA24539@godzilla.zeta.org.au> from "Bruce Evans" at Oct 16, 95 09:38:02 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2576 Sender: owner-current@freebsd.org Precedence: bulk > lstat() has been inefficient since symlinks were POSIXified. > > Bruce > > *** vfs_lookup.c~ Fri Aug 25 16:05:33 1995 > --- vfs_lookup.c Mon Oct 16 21:06:30 1995 > *************** > *** 267,272 **** > wantparent = cnp->cn_flags & (LOCKPARENT | WANTPARENT); > docache = (cnp->cn_flags & NOCACHE) ^ NOCACHE; > if (cnp->cn_nameiop == DELETE || > ! (wantparent && cnp->cn_nameiop != CREATE)) > docache = 0; > rdonly = cnp->cn_flags & RDONLY; > --- 280,297 ---- > wantparent = cnp->cn_flags & (LOCKPARENT | WANTPARENT); > docache = (cnp->cn_flags & NOCACHE) ^ NOCACHE; > + /* > + * XXX the following seems to be just to recover from not setting > + * NOCACHE for the DELETE cases (unlink, rmdir and the rename > + * source). In BSD4.4lite[2], docache was also cleared for the > + * (wantparent && cnp->cn_nameiop == LOOKUP) case. This case > + * seems to only occur for lstat and olstat, when it is wrong > + * to clear docache. This case probably didn't occur before > + * BSD4.4lite. LOCKPARENT was introduced for lstat to support > + * the new behaviour of symlinks (attributes inherited from the > + * parent. > + */ > if (cnp->cn_nameiop == DELETE || > ! (wantparent && cnp->cn_nameiop != CREATE && > ! cnp->cn_nameiop != LOOKUP)) > docache = 0; > rdonly = cnp->cn_flags & RDONLY; This will INCORRECTLY result in the contents of symlinks being seen as successfully looked up inferior components and entered into the cache. This is *BROKEN*. Consider: cd /tmp mkdir foo cp /etc/ttys foo mkdir fee cd fee ln -s /tmp/foo/ttys xxx ls xxx ls foo The *correct* set of fixes for this is moving the cache lookup into vfs_lookup.c instead of calling it per FS lookup mechanism. If I can't get a simple interface change into -current, it's unlikely that something that large in scope would go in (I would need to have the ability to disable it on a per FS type basis, etc.). Integrate my other changes first, and my patches to nameifree() and nfs_nameifree() to avoid duplicate free's, please. Then we can go off and consider moving the name cache. Also run the "find' I asked for for the cn_pnbuf references *after* the patches are applies so we can missed patches because of parallel development on things like procfs and devfs. Thanks, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-current Mon Oct 16 14:51:21 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id OAA23493 for current-outgoing; Mon, 16 Oct 1995 14:51:21 -0700 Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id OAA23450 for ; Mon, 16 Oct 1995 14:51:05 -0700 Received: from sax.sax.de by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id WAA16291 for ; Mon, 16 Oct 1995 22:50:53 +0100 Received: by sax.sax.de (8.6.11/8.6.12-s1) with UUCP id WAA23137 for freebsd-current@FreeBSD.org; Mon, 16 Oct 1995 22:50:53 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.6.12/8.6.9) id WAA26408 for freebsd-current@FreeBSD.org; Mon, 16 Oct 1995 22:44:58 +0100 From: J Wunsch Message-Id: <199510162144.WAA26408@uriah.heep.sax.de> Subject: My final opinion about this i18n issue To: freebsd-current@FreeBSD.org (FreeBSD-current users) Date: Mon, 16 Oct 1995 22:44:58 +0100 (MET) Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: from "=?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?=" at Oct 16, 95 05:52:10 pm X-Phone: +49-351-2012 669 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 1985 Sender: owner-current@FreeBSD.org Precedence: bulk As =?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?= wrote: > > >Neither do I see any clear argument for the proposed change :-) > > Ok, I repeat it again maybe slightly different than in original message. > (I suggest to read original message too, there was few words about > DISABLE_STARTUP_LOCALE. Well, I suggest to read what I write maybe > not each time but sometimes). Why should somebody even want to have it disabled, provided it's doing the right thing? > I assume that you sometimes like to see your native language > well imbedded into various FreeBSD pgms, do you really happy > to type setenv ENABLE_STARTUP_LOCALE (well, maybe put it > into .login) or explain this feature to everyone who asks > instead of simple got-it-automatically when LANG is set? Putting it into the utilities would do the same. :-) I would perhaps agree to put ENABLE_STARTUP_LOCALE into the default /etc/profile and /etc/csh.cshrc scripts. At the very least, this would still remind people that there's a hidden gotcha here. In the long run, it should be handled right anyway. I cannot see a better time to start making it right than now. 2.1 is gone (from a developer's point of view). No chance to change it there (in particular, given the rather serious xterm bug). There's still an unforeseeable time until 2.2 might complete. Starting to fix the utilities now would give enough time to find about the remaining bogons in all our programs. Hacking something that would yield the same effect, but only in a more obfuscated way, is not something i would like to see. Neither does Poul. And the remainder of the crew appears to be tired about this lengthy discussion anyway... Nobody did vote for your point so far. (Not even me, although i rather like to see the `ö' in my name spelled right and not as an `v'.) -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-current Mon Oct 16 15:59:32 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id PAA26920 for current-outgoing; Mon, 16 Oct 1995 15:59:32 -0700 Received: from Sysiphos (Sysiphos.MI.Uni-Koeln.DE [134.95.212.10]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id PAA26907 for ; Mon, 16 Oct 1995 15:59:23 -0700 Received: by Sysiphos id AA17189 (5.67b/IDA-1.5 for current@freebsd.org); Mon, 16 Oct 1995 23:59:18 +0100 Message-Id: <199510162259.AA17189@Sysiphos> From: se@zpr.uni-koeln.de (Stefan Esser) Date: Mon, 16 Oct 1995 23:59:18 +0100 X-Mailer: Mail User's Shell (7.2.6 alpha(2) 7/9/95) To: current@freebsd.org Subject: PCI probe code Sender: owner-current@freebsd.org Precedence: bulk Well, this is another try to get at least a few reports on the performance of the PCI probe code in -current. I really would like to get that version into 2.1R, if there is evidence it works on all kinds of system ... The last time I asked for your help, I got a surprising number of 0 responses, all of them quite interesting :) The code that cureently is in the 2.1 branch is known to fail on ONE non-PCI system, which happens to have a register just at the place where the PCI specs put the main configuration address register ... :( I've put a modified version into -current, which works on that system, but I've been making a (IMO) reasonable assumption: The PCI bus is in the "normal" working state, and not setup to generate configuration space cycles. If you are running -stable and want to try the new code, then you'll find the patch appended below. It's mostly indentation that changed, BTW :) Now I really would like to know whether this code does the right thing. It should be more cautious to not mess around with some non-PCI system. But it might fail to probe the PCI bus, in case the BIOS did some configuration and did not bother to lock the PCI bus against accidential configuration accesses ... Please do the following the next time you reboot your -current system: Boot with the "-v" option. If the system starts up, send 'dmesg' output to my address: If there really should be a system that fails to boot, then I'd really like to know the chip set brand and model, and those lines from the boot message, that start with a "pcibus_setip()" label ... Please do me the favour and do this simple test. There is no risk of data corruption or other bad things happening. Just reboot /kernel.old in case the probe fails on your system and let me know ... Thanks a lot in advance for your help ! Stefan Index: /sys/i386/isa/pcibus.c =================================================================== RCS file: /usr/cvs/src/sys/i386/isa/pcibus.c,v retrieving revision 1.8.4.3 diff -C2 -r1.8.4.3 pcibus.c *** 1.8.4.3 1995/10/10 01:00:58 --- pcibus.c 1995/10/16 11:13:50 *************** *** 148,152 **** #define CONF1_ENABLE_CHK 0x80000000ul #define CONF1_ENABLE_CHK1 0xFF000001ul ! #define CONF1_ENABLE_MSK1 0x80000000ul #define CONF1_ENABLE_RES1 0x80000000ul --- 148,152 ---- #define CONF1_ENABLE_CHK 0x80000000ul #define CONF1_ENABLE_CHK1 0xFF000001ul ! #define CONF1_ENABLE_MSK1 0x80000001ul #define CONF1_ENABLE_RES1 0x80000000ul *************** *** 182,210 **** pcibus_setup (void) { ! unsigned long mode1res,oldval; ! unsigned char mode2res; ! oldval = inl (CONF1_ADDR_PORT); ! outl (CONF1_ADDR_PORT, CONF1_ENABLE_CHK); ! outb (CONF2_ENABLE_PORT, CONF2_ENABLE_CHK); ! mode1res = inl(CONF1_ADDR_PORT); ! mode2res = inb(CONF2_ENABLE_PORT); ! outb (CONF2_ENABLE_PORT, 0); ! outl (CONF1_ADDR_PORT, oldval); if (bootverbose) { ! printf ("pcibus_setup(1):\tmode1res=0x%08lx (0x%08lx), " ! "mode2res=0x%02x (0x%02x)\n", ! mode1res,CONF1_ENABLE_CHK, ! (int)mode2res,CONF2_ENABLE_CHK); ! } ! ! /*--------------------------------------- ! ** No PCI, if neither mode1res nor mode2res could be read back ! **--------------------------------------- ! */ ! ! if ((mode1res != CONF1_ENABLE_CHK) && (mode2res != CONF2_ENABLE_CHK)) { ! return; } --- 182,192 ---- pcibus_setup (void) { ! unsigned long mode1res,oldval1; ! unsigned char mode2res,oldval2; ! oldval1 = inl (CONF1_ADDR_PORT); if (bootverbose) { ! printf ("pcibus_setup(1):\tmode1 addr port (0x0cf8) is 0x%08lx\n", oldval1); } *************** *** 214,247 **** */ ! pci_mechanism = 1; ! pci_maxdevice = 32; ! outl (CONF1_ADDR_PORT, CONF1_ENABLE_CHK); ! outb (CONF1_ADDR_PORT +3, 0); ! mode1res = inl (CONF1_ADDR_PORT); ! outl (CONF1_ADDR_PORT, oldval); ! ! if (bootverbose) ! printf ("pcibus_setup(2):\tmode1res=0x%08lx (0x%08lx)\n", ! mode1res, CONF1_ENABLE_CHK); ! ! if (mode1res) { ! if (pcibus_check()) ! return; ! }; ! ! outl (CONF1_ADDR_PORT, CONF1_ENABLE_CHK1); ! outl (CONF1_DATA_PORT, 0); ! mode1res = inl(CONF1_ADDR_PORT); ! outl (CONF1_ADDR_PORT, oldval); ! ! if (bootverbose) ! printf ("pcibus_setup(3):\tmode1res=0x%08lx (0x%08lx)\n", ! mode1res, CONF1_ENABLE_CHK1); ! ! if ((mode1res & CONF1_ENABLE_MSK1) == CONF1_ENABLE_RES1) { ! if (pcibus_check()) ! return; ! }; /*--------------------------------------- --- 196,231 ---- */ ! if ((oldval1 & CONF1_ENABLE) == 0) { ! ! pci_mechanism = 1; ! pci_maxdevice = 32; ! outl (CONF1_ADDR_PORT, CONF1_ENABLE_CHK); ! outb (CONF1_ADDR_PORT +3, 0); ! mode1res = inl (CONF1_ADDR_PORT); ! outl (CONF1_ADDR_PORT, oldval1); ! ! if (bootverbose) ! printf ("pcibus_setup(1a):\tmode1res=0x%08lx (0x%08lx)\n", ! mode1res, CONF1_ENABLE_CHK); ! ! if (mode1res) { ! if (pcibus_check()) ! return; ! }; ! ! outl (CONF1_ADDR_PORT, CONF1_ENABLE_CHK1); ! mode1res = inl(CONF1_ADDR_PORT); ! outl (CONF1_ADDR_PORT, oldval1); ! ! if (bootverbose) ! printf ("pcibus_setup(1b):\tmode1res=0x%08lx (0x%08lx)\n", ! mode1res, CONF1_ENABLE_CHK1); ! ! if ((mode1res & CONF1_ENABLE_MSK1) == CONF1_ENABLE_RES1) { ! if (pcibus_check()) ! return; ! }; ! } /*--------------------------------------- *************** *** 250,261 **** */ ! if (bootverbose) ! printf ("pcibus_setup(4):\tnow trying mechanism 2\n"); ! pci_mechanism = 2; ! pci_maxdevice = 16; ! if (pcibus_check()) ! return; /*--------------------------------------- --- 234,264 ---- */ ! oldval2 = inb (CONF2_ENABLE_PORT); ! ! if (bootverbose) { ! printf ("pcibus_setup(2):\tmode 2 enable port (0x0cf8) is 0x%02x\n", oldval2); ! } ! if ((oldval2 & 0xf0) == 0) { ! pci_mechanism = 2; ! pci_maxdevice = 16; ! ! outb (CONF2_ENABLE_PORT, CONF2_ENABLE_CHK); ! mode2res = inb(CONF2_ENABLE_PORT); ! outb (CONF2_ENABLE_PORT, oldval2); ! ! if (bootverbose) ! printf ("pcibus_setup(2a):\tmode2res=0x%02x (0x%02x)\n", ! mode2res, CONF2_ENABLE_CHK); ! ! if (mode2res == CONF2_ENABLE_RES) { ! if (bootverbose) ! printf ("pcibus_setup(2a):\tnow trying mechanism 2\n"); ! ! if (pcibus_check()) ! return; ! } ! } /*--------------------------------------- -- Stefan Esser, Zentrum fuer Paralleles Rechnen Tel: +49 221 4706021 Universitaet zu Koeln, Weyertal 80, 50931 Koeln FAX: +49 221 4705160 ============================================================================== http://www.zpr.uni-koeln.de/staff/esser/esser.html From owner-freebsd-current Mon Oct 16 18:43:58 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id SAA03025 for current-outgoing; Mon, 16 Oct 1995 18:43:58 -0700 Received: from sovcom.kiae.su (sovcom.kiae.su [144.206.136.1]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id SAA03020 for ; Mon, 16 Oct 1995 18:43:54 -0700 Received: by sovcom.kiae.su id AA06090 (5.65.kiae-1 for current@freebsd.org); Tue, 17 Oct 1995 04:31:11 +0300 Received: by sovcom.KIAE.su (UUMAIL/2.0); Tue, 17 Oct 95 04:31:11 +0300 Received: (from ache@localhost) by ache.dialup.demos.ru (8.6.11/8.6.9) id EAA00847 for current@freebsd.org; Tue, 17 Oct 1995 04:26:54 +0300 To: current@freebsd.org References: In-Reply-To: ; from =?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?= at Mon, 16 Oct 1995 07:16:39 +0300 (MSK) Message-Id: Organization: Olahm Ha-Yetzirah Date: Tue, 17 Oct 1995 04:26:53 +0300 (MSK) X-Mailer: Mail/@ [v2.40 FreeBSD] From: =?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?= (aka Andrey A. Chernov, Black Mage) X-Class: Fast Subject: Re: I plan to change ENABLE_STARTUP_LOCALE behaviour... Lines: 6 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 341 Sender: owner-current@freebsd.org Precedence: bulk This proposal withdrawed, I change my decision. -- Andrey A. Chernov : And I rest so composedly, /Now, in my bed, ache@astral.msk.su : That any beholder /Might fancy me dead - FidoNet: 2:5020/230.3 : Might start at beholding me, /Thinking me dead. RELCOM Team,FreeBSD Team : E.A.Poe From "For Annie" 1849 From owner-freebsd-current Mon Oct 16 19:37:22 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id TAA04824 for current-outgoing; Mon, 16 Oct 1995 19:37:22 -0700 Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id TAA04811 for ; Mon, 16 Oct 1995 19:37:16 -0700 Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id MAA20172; Tue, 17 Oct 1995 12:34:16 +1000 Date: Tue, 17 Oct 1995 12:34:16 +1000 From: Bruce Evans Message-Id: <199510170234.MAA20172@godzilla.zeta.org.au> To: bde@zeta.org.au, terry@lambert.org Subject: Re: lstat flushes namei cache entry Cc: current@freebsd.org Sender: owner-current@freebsd.org Precedence: bulk >> + /* >> + * XXX the following seems to be just to recover from not setting >> + * NOCACHE for the DELETE cases (unlink, rmdir and the rename >> + * source). In BSD4.4lite[2], docache was also cleared for the >> + * (wantparent && cnp->cn_nameiop == LOOKUP) case. This case >> + * seems to only occur for lstat and olstat, when it is wrong >> + * to clear docache. This case probably didn't occur before >> + * BSD4.4lite. LOCKPARENT was introduced for lstat to support >> + * the new behaviour of symlinks (attributes inherited from the >> + * parent. >> + */ >> if (cnp->cn_nameiop == DELETE || >> ! (wantparent && cnp->cn_nameiop != CREATE && >> ! cnp->cn_nameiop != LOOKUP)) >> docache = 0; >This will INCORRECTLY result in the contents of symlinks being seen as >successfully looked up inferior components and entered into the cache. >This is *BROKEN*. >Consider: > cd /tmp > mkdir foo > cp /etc/ttys foo > mkdir fee > cd fee > ln -s /tmp/foo/ttys xxx > ls xxx > > ls foo > inferior to fee's vnode> Actually, this prints `ls: foo: No such file or directory'. This is not surprising, since my change just (I hope) restores the caching behaviour of BSD4.3. As I tried to explain in the comment, BSD4.4 wants the parent locked, and setting the LOCKPARENT flag fouled up the caching. My change is only supposed to reenable the caching for lstat(). lstat() is the only LOOKUP case where wantparent is nonzero (unless I've missed a case). Thus my change should be a no-op for everything except lstat(). Bruce From owner-freebsd-current Mon Oct 16 20:54:50 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id UAA08088 for current-outgoing; Mon, 16 Oct 1995 20:54:50 -0700 Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id UAA08081 for ; Mon, 16 Oct 1995 20:54:46 -0700 Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id UAA26625; Mon, 16 Oct 1995 20:49:32 -0700 From: Terry Lambert Message-Id: <199510170349.UAA26625@phaeton.artisoft.com> Subject: Re: lstat flushes namei cache entry To: bde@zeta.org.au (Bruce Evans) Date: Mon, 16 Oct 1995 20:49:32 -0700 (MST) Cc: bde@zeta.org.au, terry@lambert.org, current@freebsd.org In-Reply-To: <199510170234.MAA20172@godzilla.zeta.org.au> from "Bruce Evans" at Oct 17, 95 12:34:16 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2220 Sender: owner-current@freebsd.org Precedence: bulk > >> + /* > >> + * XXX the following seems to be just to recover from not setting > >> + * NOCACHE for the DELETE cases (unlink, rmdir and the rename > >> + * source). In BSD4.4lite[2], docache was also cleared for the > >> + * (wantparent && cnp->cn_nameiop == LOOKUP) case. This case > >> + * seems to only occur for lstat and olstat, when it is wrong > >> + * to clear docache. This case probably didn't occur before > >> + * BSD4.4lite. LOCKPARENT was introduced for lstat to support > >> + * the new behaviour of symlinks (attributes inherited from the > >> + * parent. > >> + */ > >> if (cnp->cn_nameiop == DELETE || > >> ! (wantparent && cnp->cn_nameiop != CREATE && > >> ! cnp->cn_nameiop != LOOKUP)) > >> docache = 0; [ ... my bad example ... ] > Actually, this prints `ls: foo: No such file or directory'. This is not > surprising, since my change just (I hope) restores the caching behaviour > of BSD4.3. As I tried to explain in the comment, BSD4.4 wants the > parent locked, and setting the LOCKPARENT flag fouled up the caching. > My change is only supposed to reenable the caching for lstat(). lstat() > is the only LOOKUP case where wantparent is nonzero (unless I've missed > a case). Thus my change should be a no-op for everything except lstat(). rename, nfs_rename (both disallowed because the DELETE op). lstat/olstat (both allowed because of the LOOKUP op). Mount on nullfs, union, umapfs (all incorrectly enter because of the LOOKUP op and the FOLLOW flag being set). So I picked the wrong example. 8-). I think there are several others because of LOCKPARENT setting wantparent and the implied path save on CREATE/RENAME/MKDIR (see ufs/ufs/ufs_lookup.c). My gut reaction is to remove the implied saves and make them explicit. Then remove the LOCKPARENT from the WANTPARENT flag. This would also resolve the problem (I think). The real problem is the level at which cache entries are made is incorrect. The error case is unlikely in the extreme (considering no one uses the FS's in question). 8-). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-current Mon Oct 16 21:45:34 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id VAA09168 for current-outgoing; Mon, 16 Oct 1995 21:45:34 -0700 Received: from rustic (newt9.planet.net [204.117.105.9]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id VAA09163 for ; Mon, 16 Oct 1995 21:45:30 -0700 Received: (from jlc@localhost) by rustic (8.6.11/8.6.9) id AAA12843; Tue, 17 Oct 1995 00:48:28 -0400 Date: Tue, 17 Oct 1995 00:48:28 -0400 Message-Id: <199510170448.AAA12843@rustic> From: "Johanan L. Codona" To: freebsd-current@FreeBSD.ORG Subject: Re: kern/647 Sound cards fail to work Sender: owner-current@FreeBSD.ORG Precedence: bulk Well I figured it out. I was right in that the interrupt routine was not being called. The routines snd_set_irq_handler(sbc_irq, sbintr) and snd_release_irq (sbc_irq) are red herrings! They don't do the *real* job of setting up audio interrupts, that is done elsewhere. However, register_intr() does get called, and with sensible values. As those who replied to me noticed, my printer was also on the canonical irq 7. I had set the "conflicts" keyword, thinking that that would allow me to share interrupts. But on reading the source for register_intr, I saw that there is no such thing as shared ISA interrupts, unless they are processed by the *same* handler. This was the cause of my confusion. So I reshuffled my IRQs and now it works. I guess I missed where it said that interrupts of different types cannot be shared. I have seen others describe this problem too. Disabling the interrupts on the printer doesn't help because if irq 7 gets assigned to LPT0 first, that's it! All other handlers will be bounced. If there was more to kern/647 I would be curious to find out what. For now, I have a working sound card, and consider the case closed. -- Johanan L. Codona The Stekas Group codona@planet.net From owner-freebsd-current Mon Oct 16 21:56:28 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id VAA09360 for current-outgoing; Mon, 16 Oct 1995 21:56:28 -0700 Received: from hq.icb.chel.su (icb-rich-gw.icb.chel.su [193.125.10.34]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id VAA09349 for ; Mon, 16 Oct 1995 21:56:14 -0700 Received: from localhost (babkin@localhost) by hq.icb.chel.su (8.6.5/8.6.5) id KAA23451; Tue, 17 Oct 1995 10:00:05 +0500 From: "Serge A. Babkin" Message-Id: <199510170500.KAA23451@hq.icb.chel.su> Subject: 3c509 in -current needs patching To: current@freebsd.org Date: Tue, 17 Oct 1995 10:00:04 +0500 (GMT+0500) Cc: jkh@time.cdrom.com, bde@zeta.org.au X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 14485 Sender: owner-current@freebsd.org Precedence: bulk I have already sent this to Jordan but got no answer, so may be the mail was lost. Or may be Jordan is too busy to aooly this patch and had saved it for the future. Excuse me if so. I have found that the 'ep' driver in -current is relatively old and omits many new improvements (including multicasting and understanding of cards with plug-n-play mode on). I have carefully reviewed this patch so that it should preserve all latest improvements in -current. Serge --------------------------- cut here ---------------------------------- *** if_ep.c Thu Sep 7 09:13:34 1995 --- if_ep.c Fri Oct 13 09:02:28 1995 *************** *************** *** 100,105 **** --- 98,104 ---- #include #include #include + #include static int epprobe __P((struct isa_device *)); static int epattach __P((struct isa_device *)); *************** *** 117,122 **** --- 116,122 ---- static int send_ID_sequence __P((int)); static int get_eeprom_data __P((int, int)); + static struct ep_board *ep_look_for_board_at(struct isa_device *); struct ep_softc ep_softc[NEP]; *************** *** 132,145 **** }; static struct kern_devconf kdc_ep[NEP] = { { ! 0, 0, 0, /* filled in by dev_attach */ "ep", 0, { MDDT_ISA, 0, "net" }, isa_generic_externalize, 0, 0, ISA_EXTERNALLEN, ! &kdc_isa0, /* parent */ ! 0, /* parentdata */ ! DC_UNCONFIGURED, /* state */ "3Com 3C509 Ethernet adapter", ! DC_CLS_NETIF /* class */ } }; static inline void --- 132,145 ---- }; static struct kern_devconf kdc_ep[NEP] = { { ! 0, 0, 0, /* filled in by dev_attach */ "ep", 0, { MDDT_ISA, 0, "net" }, isa_generic_externalize, 0, 0, ISA_EXTERNALLEN, ! &kdc_isa0, /* parent */ ! 0, /* parentdata */ ! DC_UNCONFIGURED, /* state */ "3Com 3C509 Ethernet adapter", ! DC_CLS_NETIF /* class */ } }; static inline void *************** *** 154,164 **** int ep_current_tag = EP_LAST_TAG + 1; ! struct { ! int epb_addr; /* address of this board */ ! char epb_used; /* was this entry already used for configuring ? */ ! } ! ep_board[EP_MAX_BOARDS + 1]; static int eeprom_rdy(is) --- 154,160 ---- int ep_current_tag = EP_LAST_TAG + 1; ! struct ep_board ep_board[EP_MAX_BOARDS + 1]; static int eeprom_rdy(is) *************** *** 174,184 **** return (1); } ! static int ep_look_for_board_at(is) struct isa_device *is; { ! int data, i, j, io_base, id_port = EP_ID_PORT; int nisa = 0, neisa = 0; if (ep_current_tag == (EP_LAST_TAG + 1)) { --- 170,180 ---- return (1); } ! static struct ep_board * ep_look_for_board_at(is) struct isa_device *is; { ! int data, i, j, io_base, id_port = ELINK_ID_PORT; int nisa = 0, neisa = 0; if (ep_current_tag == (EP_LAST_TAG + 1)) { *************** *** 203,232 **** * Once activated, all the registers are mapped in the range * x000 - x00F, where x is the slot number. */ ep_board[neisa].epb_used = 0; ep_board[neisa++].epb_addr = j * EP_EISA_START; } ep_current_tag--; /* Look for the ISA boards. Init and leave them actived */ outb(id_port, 0xc0); /* Global reset */ DELAY(10000); for (i = 0; i < EP_MAX_BOARDS; i++) { outb(id_port, 0); outb(id_port, 0); send_ID_sequence(id_port); data = get_eeprom_data(id_port, EEPROM_MFG_ID); if (data != MFG_ID) break; /* resolve contention using the Ethernet address */ for (j = 0; j < 3; j++) ! data = get_eeprom_data(id_port, j); ep_board[neisa+nisa].epb_used = 0; ep_board[neisa+nisa++].epb_addr = ! (get_eeprom_data(id_port, EEPROM_ADDR_CFG) & 0x1f) * 0x10 + 0x200; outb(id_port, ep_current_tag); /* tags board */ outb(id_port, ACTIVATE_ADAPTER_TO_CONFIG); ep_current_tag--; --- 199,260 ---- * Once activated, all the registers are mapped in the range * x000 - x00F, where x is the slot number. */ + ep_board[neisa].epb_isa = 0; ep_board[neisa].epb_used = 0; ep_board[neisa++].epb_addr = j * EP_EISA_START; } ep_current_tag--; /* Look for the ISA boards. Init and leave them actived */ + outb(id_port, 0); + outb(id_port, 0); + + #if 0 + send_ID_sequence(id_port); + #else + elink_idseq(0xCF); + #endif + + #if 0 outb(id_port, 0xc0); /* Global reset */ + #else + elink_reset(); + #endif DELAY(10000); for (i = 0; i < EP_MAX_BOARDS; i++) { outb(id_port, 0); outb(id_port, 0); + #if 0 send_ID_sequence(id_port); + #else + elink_idseq(0xCF); + #endif data = get_eeprom_data(id_port, EEPROM_MFG_ID); if (data != MFG_ID) break; /* resolve contention using the Ethernet address */ + + for (j = 0; j < 3; j++) + get_eeprom_data(id_port, j); + + /* and save this address for later use */ + for (j = 0; j < 3; j++) ! ep_board[neisa+nisa].eth_addr[j] = get_eeprom_data(id_port, j); ! ! ep_board[neisa+nisa].res_cfg = ! get_eeprom_data(id_port, EEPROM_RESOURCE_CFG); ! ! ep_board[neisa+nisa].prod_id = ! get_eeprom_data(id_port, EEPROM_PROD_ID); + ep_board[neisa].epb_isa = 1; ep_board[neisa+nisa].epb_used = 0; ep_board[neisa+nisa++].epb_addr = ! (get_eeprom_data(id_port, EEPROM_ADDR_CFG) & 0x1f) * 0x10 + 0x200; ! outb(id_port, ep_current_tag); /* tags board */ outb(id_port, ACTIVATE_ADAPTER_TO_CONFIG); ep_current_tag--; *************** *** 266,283 **** IS_BASE=ep_board[i].epb_addr; ep_board[i].epb_used=1; ! return 1; } else { for (i=0; ep_board[i].epb_addr && ep_board[i].epb_addr != IS_BASE; i++); ! if( ep_board[i].epb_used || ep_board[i].epb_addr != IS_BASE) return 0; if (inw(IS_BASE + EP_W0_EEPROM_COMMAND) & EEPROM_TST_MODE) printf("ep%d: 3c5x9 at 0x%x in test mode. Erase pencil mark!\n", is->id_unit, IS_BASE); ep_board[i].epb_used=1; ! return 1; } } --- 294,313 ---- IS_BASE=ep_board[i].epb_addr; ep_board[i].epb_used=1; ! ! return &ep_board[i]; } else { for (i=0; ep_board[i].epb_addr && ep_board[i].epb_addr != IS_BASE; i++); ! if( ep_board[i].epb_used || ep_board[i].epb_addr != IS_BASE) return 0; if (inw(IS_BASE + EP_W0_EEPROM_COMMAND) & EEPROM_TST_MODE) printf("ep%d: 3c5x9 at 0x%x in test mode. Erase pencil mark!\n", is->id_unit, IS_BASE); ep_board[i].epb_used=1; ! ! return &ep_board[i]; } } *************** *** 308,327 **** ep_registerdev(is); ! if (!ep_look_for_board_at(is)) return (0); /* * The iobase was found and MFG_ID was 0x6d50. PROD_ID should be * 0x9[0-f]50 */ GO_WINDOW(0); ! k = get_e(is, EEPROM_PROD_ID); if ((k & 0xf0ff) != (PROD_ID & 0xf0ff)) { printf("epprobe: ignoring model %04x\n", k); return (0); } ! k = get_e(is, EEPROM_RESOURCE_CFG); k >>= 12; /* Now we have two cases again: --- 338,358 ---- ep_registerdev(is); ! if(( sc->epb=ep_look_for_board_at(is) )==0) return (0); /* * The iobase was found and MFG_ID was 0x6d50. PROD_ID should be * 0x9[0-f]50 */ GO_WINDOW(0); ! k = sc->epb->epb_isa ? sc->epb->prod_id : get_e(is, EEPROM_PROD_ID); if ((k & 0xf0ff) != (PROD_ID & 0xf0ff)) { printf("epprobe: ignoring model %04x\n", k); return (0); } ! k = sc->epb->epb_isa ? sc->epb->res_cfg : get_e(is, EEPROM_RESOURCE_CFG); ! k >>= 12; /* Now we have two cases again: *************** *** 396,402 **** p = (u_short *) & sc->arpcom.ac_enaddr; for (i = 0; i < 3; i++) { GO_WINDOW(0); ! p[i] = htons(get_e(is, i)); GO_WINDOW(2); outw(BASE + EP_W2_ADDR_0 + (i * 2), ntohs(p[i])); } --- 427,433 ---- p = (u_short *) & sc->arpcom.ac_enaddr; for (i = 0; i < 3; i++) { GO_WINDOW(0); ! p[i] = htons( sc->epb->epb_isa ? sc->epb->eth_addr[i] : get_e(is, i) ); GO_WINDOW(2); outw(BASE + EP_W2_ADDR_0 + (i * 2), ntohs(p[i])); } *************** *** 423,429 **** ifp->if_unit = is->id_unit; ifp->if_name = "ep"; ifp->if_mtu = ETHERMTU; ! ifp->if_flags = IFF_BROADCAST | IFF_SIMPLEX | IFF_NOTRAILERS; ifp->if_init = epinit; ifp->if_output = ether_output; ifp->if_start = epstart; --- 454,461 ---- ifp->if_unit = is->id_unit; ifp->if_name = "ep"; ifp->if_mtu = ETHERMTU; ! ifp->if_flags = IFF_BROADCAST | IFF_MULTICAST | ! IFF_SIMPLEX | IFF_NOTRAILERS; ifp->if_init = epinit; ifp->if_output = ether_output; ifp->if_start = epstart; *************** *** 432,438 **** ifp->if_timer=1; if_attach(ifp); ! kdc_ep[is->id_unit].kdc_state = DC_BUSY; /* * Fill the hardware address into ifa_addr if we find an AF_LINK entry. --- 464,472 ---- ifp->if_timer=1; if_attach(ifp); ! ! /* device attach does transition from UNCONFIGURED to IDLE state */ ! kdc_ep[is->id_unit].kdc_state=DC_IDLE; /* * Fill the hardware address into ifa_addr if we find an AF_LINK entry. *************** *** 475,481 **** #endif ep_fset(F_RX_FIRST); sc->top = sc->mcur = 0; ! #if NBPFILTER > 0 bpfattach(&sc->bpf, ifp, DLT_EN10MB, sizeof(struct ether_header)); #endif --- 509,515 ---- #endif ep_fset(F_RX_FIRST); sc->top = sc->mcur = 0; ! #if NBPFILTER > 0 bpfattach(&sc->bpf, ifp, DLT_EN10MB, sizeof(struct ether_header)); #endif *************** *** 536,547 **** outw(BASE + EP_COMMAND, SET_INTR_MASK | S_5_INTS); ! if(ifp->if_flags & IFF_PROMISC) ! outw(BASE + EP_COMMAND, SET_RX_FILTER | FIL_INDIVIDUAL | ! FIL_GROUP | FIL_BRDCST | FIL_ALL); ! else ! outw(BASE + EP_COMMAND, SET_RX_FILTER | FIL_INDIVIDUAL | ! FIL_GROUP | FIL_BRDCST); /* * S.B. --- 570,581 ---- outw(BASE + EP_COMMAND, SET_INTR_MASK | S_5_INTS); ! if(ifp->if_flags & IFF_PROMISC) ! outw(BASE + EP_COMMAND, SET_RX_FILTER | FIL_INDIVIDUAL | ! FIL_GROUP | FIL_BRDCST | FIL_ALL); ! else ! outw(BASE + EP_COMMAND, SET_RX_FILTER | FIL_INDIVIDUAL | ! FIL_GROUP | FIL_BRDCST); /* * S.B. *************** *** 814,820 **** sc->rx_no_first, sc->rx_no_mbuf, sc->rx_bpf_disc, sc->rx_overrunf, sc->rx_overrunl, sc->tx_underrun); #else ! printf("ep%d: Status: %x\n", unit, status); #endif epinit(unit); splx(x); --- 848,860 ---- sc->rx_no_first, sc->rx_no_mbuf, sc->rx_bpf_disc, sc->rx_overrunf, sc->rx_overrunl, sc->tx_underrun); #else ! ! #ifdef nightmaremessages ! printf("ep%d: Status: %x (input buffer overflow)\n", unit, status); ! #else ! ++sc->arpcom.ac_if.if_ierrors; ! #endif ! #endif epinit(unit); splx(x); *************** *** 1129,1139 **** struct ifreq *ifr = (struct ifreq *) data; int s, error = 0; s = splimp(); switch (cmd) { case SIOCSIFADDR: ifp->if_flags |= IFF_UP; switch (ifa->ifa_addr->sa_family) { #ifdef INET case AF_INET: --- 1169,1183 ---- struct ifreq *ifr = (struct ifreq *) data; int s, error = 0; s = splimp(); switch (cmd) { case SIOCSIFADDR: ifp->if_flags |= IFF_UP; + + /* netifs are BUSY when UP */ + kdc_ep[ifp->if_unit].kdc_state=DC_BUSY; + switch (ifa->ifa_addr->sa_family) { #ifdef INET case AF_INET: *************** *** 1164,1179 **** break; } break; ! case SIOCGIFADDR: ! { ! struct sockaddr *sa; ! ! sa = (struct sockaddr *) & ifr->ifr_data; ! bcopy((caddr_t) sc->arpcom.ac_enaddr, (caddr_t) sa->sa_data, ETHER_ADDR_LEN); } break; case SIOCSIFFLAGS: if ((ifp->if_flags & IFF_UP) == 0 && ifp->if_flags & IFF_RUNNING) { ifp->if_flags &= ~IFF_RUNNING; epstop(ifp->if_unit); --- 1208,1228 ---- break; } break; ! case SIOCSGIFADDR: ! { ! struct sockaddr *sa; ! ! sa = (struct sockaddr *) & ifr->ifr_data; ! bcopy((caddr_t) sc->arpcom.ac_enaddr, (caddr_t) sa->sa_data, ETHER_ADDR_LEN); } break; case SIOCSIFFLAGS: + /* UP controls BUSY/IDLE */ + kdc_ep[ifp->if_unit].kdc_state= ( (ifp->if_flags & IFF_UP) + ? DC_BUSY + : DC_IDLE ); + if ((ifp->if_flags & IFF_UP) == 0 && ifp->if_flags & IFF_RUNNING) { ifp->if_flags &= ~IFF_RUNNING; epstop(ifp->if_unit); *************** *** 1186,1191 **** --- 1235,1241 ---- } /* NOTREACHED */ + #if 0 if (ifp->if_flags & IFF_UP && (ifp->if_flags & IFF_RUNNING) == 0) epinit(ifp->if_unit); *************** *** 1198,1203 **** --- 1248,1254 ---- ep_frst(F_PROMISC); epinit(ifp->if_unit); } + #endif break; #ifdef notdef *************** *** 1216,1223 **** } else { ifp->if_mtu = ifr->ifr_mtu; } ! break; ! default: error = EINVAL; } --- 1267,1281 ---- } else { ifp->if_mtu = ifr->ifr_mtu; } ! break; ! case SIOCADDMULTI: ! case SIOCDELMULTI: ! /* Now this driver has no support for programmable ! * multicast filters. If some day it will gain this ! * support this part of code must be extended. ! */ ! error=0; ! break; default: error = EINVAL; } *** if_epreg.h Thu Sep 7 09:03:48 1995 --- if_epreg.h Fri Aug 4 09:00:36 1995 *************** *************** *** 71,76 **** --- 70,77 ---- #define F_ACCESS_32_BITS 0x100 + struct ep_board *epb; + #ifdef EP_LOCAL_STATS short tx_underrun; short rx_no_first; *************** *** 80,85 **** --- 81,97 ---- short rx_overrunl; #endif }; + + struct ep_board { + int epb_addr; /* address of this board */ + char epb_used; /* was this entry already used for configuring ? */ + /* data from EEPROM for later use */ + char epb_isa; /* flag: this is an ISA card */ + u_short eth_addr[3]; /* Ethernet address */ + u_short prod_id; /* product ID */ + u_short res_cfg; /* resource configuration */ + }; + /* * Some global constants --------------------------- cut here ---------------------------------- From owner-freebsd-current Mon Oct 16 21:58:43 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id VAA09455 for current-outgoing; Mon, 16 Oct 1995 21:58:43 -0700 Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id VAA09448 for ; Mon, 16 Oct 1995 21:58:38 -0700 Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id OAA25759; Tue, 17 Oct 1995 14:56:32 +1000 Date: Tue, 17 Oct 1995 14:56:32 +1000 From: Bruce Evans Message-Id: <199510170456.OAA25759@godzilla.zeta.org.au> To: bde@zeta.org.au, terry@lambert.org Subject: Re: lstat flushes namei cache entry Cc: current@freebsd.org Sender: owner-current@freebsd.org Precedence: bulk >> My change is only supposed to reenable the caching for lstat(). lstat() >> is the only LOOKUP case where wantparent is nonzero (unless I've missed >> a case). Thus my change should be a no-op for everything except lstat(). >rename, nfs_rename (both disallowed because the DELETE op). >lstat/olstat (both allowed because of the LOOKUP op). Note: previously, lstat() of fee/xx removed any existing cache entry for xx, independent of whether xx is a symlink. This is what I'm fixing. If xx is a symlink, then it should still be cached. Symlinks aren't followed for lstat() so there is now danger that for xx -> foo/bar, bar is cached as a directory entry for fee. >Mount on nullfs, union, umapfs (all incorrectly enter because of the LOOKUP >op and the FOLLOW flag being set). Those file systems are broken anyway :-). I think the correct fix is to set NOCACHE for these calls and also for the DELETE calls, and delete the special cases, but I'm concerned about why it isn't already done. NOCACHE seems to be set only for RENAME. BTW, getdirentries() is currently broken for nfs-mounted msdosfs. Is it time for another sermon on the evil cookies? :-) Bruce From owner-freebsd-current Mon Oct 16 22:25:30 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id WAA09961 for current-outgoing; Mon, 16 Oct 1995 22:25:30 -0700 Received: from silvia.HIP.Berkeley.EDU (silvia.HIP.Berkeley.EDU [136.152.64.181]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id WAA09956 for ; Mon, 16 Oct 1995 22:25:26 -0700 Received: (from asami@localhost) by silvia.HIP.Berkeley.EDU (8.6.12/8.6.9) id WAA00732; Mon, 16 Oct 1995 22:25:23 -0700 Date: Mon, 16 Oct 1995 22:25:23 -0700 Message-Id: <199510170525.WAA00732@silvia.HIP.Berkeley.EDU> To: current@freebsd.org Subject: "cannot mount root" From: asami@cs.berkeley.edu (Satoshi Asami) Sender: owner-current@freebsd.org Precedence: bulk Just got this on today's -current: === pcibus_setup(1): mode1 addr port (0x0cf8) is 0x80000840 pcibus_setup(2): mode 2 enable port (0x0cf8) is 0xff panic: cannot mount root === I have an NCR 53C825 controller and two SCSI disks (Quantum XP32150 and Micropolis MC3243W). I've had other problems with this controller before (as Stefan knows well) but have never seen this "cannot mount root". Satoshi From owner-freebsd-current Tue Oct 17 00:55:26 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id AAA12826 for current-outgoing; Tue, 17 Oct 1995 00:55:26 -0700 Received: from netcom17.netcom.com (root@netcom17.netcom.com [192.100.81.130]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id AAA12821 ; Tue, 17 Oct 1995 00:55:19 -0700 Received: from localhost by netcom17.netcom.com (8.6.12/Netcom) id AAA00821; Tue, 17 Oct 1995 00:26:43 -0700 Message-Id: <199510170726.AAA00821@netcom17.netcom.com> To: Terry Lambert cc: hackers@freefall.freebsd.org, current@freefall.freebsd.org Subject: Re: getdtablesize() broken? In-reply-to: Your message of "Mon, 16 Oct 95 11:31:02 PDT." <199510161831.LAA25019@phaeton.artisoft.com> Date: Tue, 17 Oct 95 00:26:42 -0700 From: Bakul Shah Sender: owner-current@FreeBSD.org Precedence: bulk > Using FD_SETSIZE or using RLIMIT_NOFILE, or getting the current open > descriptor limit from the kernel (when the application has an explicit > bitvector element limitation set at compile time, not because of a > check for FD_SETSIZE by because declaration of a bit vector uses the > FD_SETSIZE to declare the vector length) is equally stupid and equally > succeptible to screwups. > The "correct" way is to get rid of the interfaces which are succeptible > to bad programming style. The user *SHOULD* be using the highest open > FD in the set of FD's being selected upon, *NOT* some arbitrary constant. My mistake. I didn't explicitly state that I was bitching about an *in-kernel* limitation. Granted that an application should use what you suggest but the problem is that a {Free|Net}BSD _kernel_ restricts nfds that can be passed to select() to FD_SETSIZE. I can open, say, 1000 sockets, there is no way I can select on an fd >= FD_SETSIZE. Unshar the attached little program and try this test. % cc x.c % limit openefiles 500 # you may need to do `limit descriptors 500' % a.out 500 255 except select(). This happens because of this line in /sys/kern/sys_generic.c:select() if (uap->nd > FD_SETSIZE) It should be replaced with if (uap->nd > p->fd->fd_nfiles) It is this hardwired use of FD_SETSIZE *in* the kernel I am bitching about. There *are* scalability problems with select() and we can use a more scalable interface but regardless, select() needs to work with any valid file descriptor. --bakul #!/bin/sh # This is a shell archive (produced by shar 3.49) # To extract the files from this archive, save it to a file, remove # everything above the "!/bin/sh" line above, and type "sh file_name". # # made 10/17/1995 07:18 UTC by bakul@netcom17 # Source directory /u7/bakul # # existing files will NOT be overwritten unless -c is specified # # This shar contains: # length mode name # ------ ---------- ------------------------------------------ # 502 -rw-r--r-- x.c # # ============= x.c ============== if test -f 'x.c' -a X"$1" != X"-c"; then echo 'x - skipping x.c (File already exists)' else echo 'x - extracting x.c (Text)' sed 's/^X//' << 'SHAR_EOF' > 'x.c' && #include #include #include X int main(int argc, char**argv) { X int n = argc > 1 ? atoi(argv[1]) : 257; X int * bits = calloc((n+31)/32, sizeof(int)); X int i; X X for (i = 3; i < n; i++) { X int fd = dup(0); X if (fd < 0) { X fprintf(stderr, "Can only get %d descriptors\n", i); X exit(1); X } X bits[fd/32] |= 1<<(fd%32); X if (select(fd+1, bits, 0, 0, 0) < 0) { X fprintf(stderr, "select error %s when fd = %d\n", X strerror(errno), fd); X exit(1); X } X } X exit(0); } SHAR_EOF chmod 0644 x.c || echo 'restore of x.c failed' Wc_c="`wc -c < 'x.c'`" test 502 -eq "$Wc_c" || echo 'x.c: original size 502, current size' "$Wc_c" fi exit 0 From owner-freebsd-current Tue Oct 17 01:16:12 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id BAA13743 for current-outgoing; Tue, 17 Oct 1995 01:16:12 -0700 Received: from colin.muc.de (root@colin.muc.de [193.174.4.1]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id BAA13712 for ; Tue, 17 Oct 1995 01:15:32 -0700 Received: from totum by colin.muc.de with UUCP id <41349-2>; Tue, 17 Oct 1995 09:14:53 +0100 Received: (from root@localhost) by totum.muc.de (8.6.12/8.6.9) id IAA22949; Tue, 17 Oct 1995 08:44:11 +0100 Date: Tue, 17 Oct 1995 08:44:11 +0100 From: Michael Reifenberger To: FreeBSD-Current Subject: FLEX Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@freebsd.org Precedence: bulk Does anybody remember my problem report regarding the latest bmaked flex port in my homedir on freefall? You will need it to be able to compile Postgres95. (And maybe some other tools) Bye! ---- Michael Reifenberger From owner-freebsd-current Tue Oct 17 01:16:24 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id BAA13766 for current-outgoing; Tue, 17 Oct 1995 01:16:24 -0700 Received: from colin.muc.de (root@colin.muc.de [193.174.4.1]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id BAA13741 for ; Tue, 17 Oct 1995 01:16:05 -0700 Received: from totum by colin.muc.de with UUCP id <41347-1>; Tue, 17 Oct 1995 09:14:53 +0100 Received: (from root@localhost) by totum.muc.de (8.6.12/8.6.9) id IAA22761; Tue, 17 Oct 1995 08:41:23 +0100 Date: Tue, 17 Oct 1995 08:41:22 +0100 From: Michael Reifenberger To: FreeBSD-Current Subject: current "make all" breaks Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@freebsd.org Precedence: bulk First, you can't do a "make install" with "NOMANCOMPRESS=yes" set. Second, I get during "make all": (I have rebuild all tools/lib-tools/libraries before) "make all" break in some other lkm sections too. (Setting malloc flags makes no difference) ===> usr.sbin/vidcontrol ===> lkm ===> lkm/cd9660 ===> lkm/coff ld -r -o tmp.o coff.o imgact_coff.o symorder -c symb.tmp tmp.o symorder: 1 symbol not found: _ibcs2_coff_mod *** Error code 1 Stop. *** Error code 1 Stop. *** Error code 1 Stop. Bye! ---- Michael Reifenberger From owner-freebsd-current Tue Oct 17 01:26:28 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id BAA14271 for current-outgoing; Tue, 17 Oct 1995 01:26:28 -0700 Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id BAA14250 for ; Tue, 17 Oct 1995 01:26:10 -0700 Received: from sax.sax.de by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id JAA29377 for ; Tue, 17 Oct 1995 09:25:36 +0100 Received: by sax.sax.de (8.6.11/8.6.12-s1) with UUCP id JAA27545 for freebsd-current@FreeBSD.org; Tue, 17 Oct 1995 09:25:36 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.6.12/8.6.9) id JAA00273 for freebsd-current@FreeBSD.org; Tue, 17 Oct 1995 09:20:40 +0100 From: J Wunsch Message-Id: <199510170820.JAA00273@uriah.heep.sax.de> Subject: Re: PCI probe code To: freebsd-current@FreeBSD.org (FreeBSD-current users) Date: Tue, 17 Oct 1995 09:20:40 +0100 (MET) Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199510162259.AA17189@Sysiphos> from "Stefan Esser" at Oct 16, 95 11:59:18 pm X-Phone: +49-351-2012 669 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 475 Sender: owner-current@FreeBSD.org Precedence: bulk As Stefan Esser wrote: > > The last time I asked for your help, I got a surprising > number of 0 responses, all of them quite interesting :) I don't have a PCI machine at home, but one at work. It's running 2.0.5 however. Would it be sufficient stuffing such a kernel onto a boot floppy and see what happens? -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-current Tue Oct 17 01:26:34 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id BAA14290 for current-outgoing; Tue, 17 Oct 1995 01:26:34 -0700 Received: from mail.netvision.net.il (mail.NetVision.net.il [194.90.1.6]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id BAA14268 for ; Tue, 17 Oct 1995 01:26:23 -0700 Received: (from gena@localhost) by mail.netvision.net.il (8.6.12/8.6.9) id KAA26131; Tue, 17 Oct 1995 10:25:06 +0200 Date: Tue, 17 Oct 1995 10:25:06 +0200 Content-Length: 660 Message-ID: X-Mailer: XFMail 0.3-beta [p0] on FreeBSD Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit MIME-Version: 1.0 In-Reply-To: <199510170500.KAA23451@hq.icb.chel.su> Reply-To: gena@NetVision.net.il X-Face: #v>4HN>#D_"[olq9y`HqTYkLVB89Xy|3')Vs9v58JQ*u-xEJVKY`xa.}E?z0RkLI/P&;BJmi0#u=W0).-Y'J4(dw{"54NhSG|YYZG@[)(`e! >jN#L!~qI5fE-JHS+< Organization: NetVision Ltd. From: Gennady Sorokopud To: "Serge A. Babkin" Subject: RE: 3c509 in -current needs patching Cc: Sender: owner-current@freebsd.org Precedence: bulk Hello! When we are on the subject..can you make if_ep.c support IPX? (latest ipx patches adds IPX support only to if_ed.c) On Tue Oct 17 05:14:39 1995 Serge A. Babkin wrote: >>I have already sent this to Jordan but got no answer, so may be the mail >was lost. Or may be Jordan is too busy to aooly this patch and had saved >it for the future. Excuse me if so. > >I have found that the 'ep' driver in -current is relatively old and >omits many new improvements (including multicasting and understanding >of cards with plug-n-play mode on). I have carefully reviewed this patch >so that it should preserve all latest improvements in -current. > Best regards. From owner-freebsd-current Tue Oct 17 03:30:30 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id DAA21907 for current-outgoing; Tue, 17 Oct 1995 03:30:30 -0700 Received: from netcom5.netcom.com (bakul@netcom5.netcom.com [192.100.81.113]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id DAA21888 ; Tue, 17 Oct 1995 03:30:23 -0700 Received: from localhost by netcom5.netcom.com (8.6.12/Netcom) id DAA04795; Tue, 17 Oct 1995 03:28:54 -0700 Message-Id: <199510171028.DAA04795@netcom5.netcom.com> To: Bruce Evans cc: terry@lambert.org, current@freefall.freebsd.org, hackers@freefall.freebsd.org Subject: Re: getdtablesize() broken? In-reply-to: Your message of "Tue, 17 Oct 95 19:29:19 +1000." <199510170929.TAA03697@godzilla.zeta.org.au> Date: Tue, 17 Oct 95 03:28:53 -0700 From: Bakul Shah Sender: owner-current@FreeBSD.org Precedence: bulk > I get 64. Perhaps you have a shell bug. Possible. Or may be there is an exra fd open. zsh seems to be the culprit here. > >It is this hardwired use of FD_SETSIZE *in* the kernel I am > >bitching about. > The limit is built in to the fd_set type. The FD_SETSIZE check > just makes sure that all the bits fit in the kernel fd_set > variables. The kernel needs to use dynamically allocated > arrays to hold more bits, and different methods to access the > bits... But of course! [My fix was partial but if you decide to banish FD_SETSIZE removing all use of fd_set follows -- I should never respond when I am half asleep; but that is when I get some free time :-(] Anyway, instead of fd_set the kernel needs to use just int* (and allocate enough ints). Instead of macros FD_{SET,CLR,ISSET,ZERO} it can use #define SET_BIT(n, p) ((p)[(n)/NFDBITS] |= (1 << ((n) % NFDBITS))) #define CLR_BIT(n, p) ((p)[(n)/NFDBITS] &= ~(1 << ((n) % NFDBITS))) #define ISSET_BIT(n, p) ((p)[(n)/NFDBITS] & (1 << ((n) % NFDBITS))) #define ZERO_BITS(n, p) bzero((char*)(p), \ howmany((n), NFDBITS) * sizeof(fd_mask)) [Going off on another tangent -- I wish we can start using inline functions instead of such odious macros -- even though inline is not ISO sanctioned every compiler worth its salt provides it] From owner-freebsd-current Tue Oct 17 03:49:52 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id DAA22408 for current-outgoing; Tue, 17 Oct 1995 03:49:52 -0700 Received: from tfs.com (tfs.com [140.145.250.1]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id DAA22388 ; Tue, 17 Oct 1995 03:49:43 -0700 Received: from critter.tfs.com by tfs.com (smail3.1.28.1) with SMTP id m0t59aX-0003wxC; Tue, 17 Oct 95 03:49 PDT Received: from localhost (localhost [127.0.0.1]) by critter.tfs.com (8.6.11/8.6.9) with SMTP id LAA03166; Tue, 17 Oct 1995 11:49:39 +0100 X-Authentication-Warning: critter.tfs.com: Host localhost didn't use HELO protocol To: Bakul Shah cc: Bruce Evans , terry@lambert.org, current@freefall.freebsd.org, hackers@freefall.freebsd.org Subject: Re: getdtablesize() broken? In-reply-to: Your message of "Tue, 17 Oct 1995 03:28:53 MST." <199510171028.DAA04795@netcom5.netcom.com> Date: Tue, 17 Oct 1995 11:49:39 +0100 Message-ID: <3164.813926979@critter.tfs.com> From: Poul-Henning Kamp Sender: owner-current@FreeBSD.org Precedence: bulk > [Going off on another tangent -- I wish we can start using > inline functions instead of such odious macros -- even though > inline is not ISO sanctioned every compiler worth its salt > provides it] Wanna have a really good time: inline the syscalls... :-) -- Poul-Henning Kamp | phk@FreeBSD.ORG FreeBSD Core-team. http://www.freebsd.org/~phk | phk@login.dknet.dk Private mailbox. whois: [PHK] | phk@ref.tfs.com TRW Financial Systems, Inc. It will be some time yet before progress goes too far... (Poul Henningsen) From owner-freebsd-current Tue Oct 17 04:17:53 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id EAA23045 for current-outgoing; Tue, 17 Oct 1995 04:17:53 -0700 Received: from time.cdrom.com (time.cdrom.com [192.216.222.226]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id EAA23040 for ; Tue, 17 Oct 1995 04:17:49 -0700 Received: from localhost (localhost [127.0.0.1]) by time.cdrom.com (8.6.12/8.6.9) with SMTP id EAA05284; Tue, 17 Oct 1995 04:16:34 -0700 To: "Serge A. Babkin" cc: current@freebsd.org, bde@zeta.org.au Subject: Re: 3c509 in -current needs patching In-reply-to: Your message of "Tue, 17 Oct 1995 10:00:04 +0500." <199510170500.KAA23451@hq.icb.chel.su> Date: Tue, 17 Oct 1995 04:16:34 -0700 Message-ID: <5282.813928594@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-current@freebsd.org Precedence: bulk > I have already sent this to Jordan but got no answer, so may be the mail > was lost. Or may be Jordan is too busy to aooly this patch and had saved > it for the future. Excuse me if so. Sorry, it's more a question of me being sort of the wrong person to have sent it to. I don't have one of these cards and I'm not really a networking guy, either. I was hoping that someone else would pick it up after testing it - I have no way of knowing whether a given change is "better" or not where the ep driver is concerned.. :-( If nobody else picks this up then I will be happy to bring this into -current, but I'll be doing it blind.. Jordan > > I have found that the 'ep' driver in -current is relatively old and > omits many new improvements (including multicasting and understanding > of cards with plug-n-play mode on). I have carefully reviewed this patch > so that it should preserve all latest improvements in -current. > > Serge From owner-freebsd-current Tue Oct 17 04:53:10 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id EAA23562 for current-outgoing; Tue, 17 Oct 1995 04:53:10 -0700 Received: from bunyip.cc.uq.oz.au (pp@bunyip.cc.uq.oz.au [130.102.2.1]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id EAA23557 for ; Tue, 17 Oct 1995 04:53:07 -0700 Received: from cc.uq.oz.au by bunyip.cc.uq.oz.au id <02456-0@bunyip.cc.uq.oz.au>; Tue, 17 Oct 1995 19:55:37 +1000 Received: from orion.devetir.qld.gov.au by pandora.devetir.qld.gov.au (8.6.10/DEVETIR-E0.3a) with ESMTP id SAA24875; Tue, 17 Oct 1995 18:55:02 +1000 Received: by orion.devetir.qld.gov.au (8.6.10/DEVETIR-0.3) id SAA18528; Tue, 17 Oct 1995 18:51:17 +1000 Date: Tue, 17 Oct 1995 18:51:17 +1000 From: Stephen McKay Message-Id: <199510170851.SAA18528@orion.devetir.qld.gov.au> To: David Greenman cc: freebsd-current@freebsd.org, syssgm@devetir.qld.gov.au Subject: Re: /kernel: biodone: buffer already done Sender: owner-current@freebsd.org Precedence: bulk On Mon, 2 Oct 1995 10:10:15 GMT, David Greenman explained: >>My memory starved test box has thrown up this: >> >>Oct 2 15:10:26 stupid /kernel: biodone: buffer already done >>Oct 2 15:10:27 stupid /kernel: biodone: buffer already done > > This is a "known" problem. It's apparantly caused by inadequate vnode >locking in the NFS code and the result is a race condition which then causes >the above. > >> UID PID PPID CPU PRI NI VSZ RSS WCHAN STAT TT TIME COMMAND >> 0 149 148 109 -18 5 300 12 objtrm DN p0 0:00.22 mv /tmp/_depend148 .depend > ^^^^^^ > >Yep, that's another symptom of the bug. We'll hopefully get this fixed soon. Just in case it throws any light on the matter, I've now got this hung process: UID PID PPID CPU PRI NI VSZ RSS WCHAN STAT TT TIME COMMAND 1056 16443 167 46 -18 0 144 24 vmopar D+ p0 0:00.43 tail /ctm/LOG and, yes, /ctm is NFS mounted. This hang came after the usual pair of "biodone: buffer already done" messages. The 'make world' is still going though, and writes to /ctm/LOG are still working. I'm running -current from 1995-10-15 21:39:29 (src-cur 1082). Stephen. From owner-freebsd-current Tue Oct 17 06:11:25 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id GAA24773 for current-outgoing; Tue, 17 Oct 1995 06:11:25 -0700 Received: from irbs.irbs.com (irbs.com [199.182.75.129]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id GAA24767 for ; Tue, 17 Oct 1995 06:11:20 -0700 Received: (from jc@localhost) by irbs.irbs.com (8.6.12/8.6.6) id JAA17136; Tue, 17 Oct 1995 09:10:37 -0400 From: John Capo Message-Id: <199510171310.JAA17136@irbs.irbs.com> Subject: Re: crash To: nathan@netrail.net (Nathan Stratton) Date: Tue, 17 Oct 1995 09:10:36 -0400 (EDT) Cc: current@FreeBSD.org, et-users@netrail.net, freebsd-isp@netrail.net In-Reply-To: from "Nathan Stratton" at Oct 16, 95 12:10:11 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 924 Sender: owner-current@FreeBSD.org Precedence: bulk Nathan Stratton writes: > > > I am using a 486 DX4 100 as a router, I have a T1 from sprint and a T1 > form mci connected to it. I also have two 10 meg ethernet cards. It is > running freebsd 2.0.5 and has about 31,000 routes in it's routing table. > Well my problem is every day or so it will crash. My T1 cards need to be > reset befoer they reboot so when the system reboots it just locks up > becaue the T1 cards were not reset. > > I changed my reboot command to reset the cards, so if I do a shutdown it > works great and resets my cards. But what it looks like when the system > crashes it does not run reboot. What does it run? How can I make my > system reset my T1 cards just after it crashes and befoer it reboots the > system? > The kernel does not run any user land programs after a panic. The T1 cards should be reset by the driver when they are attached. Dennis??? John Capo IRBS Engineering From owner-freebsd-current Tue Oct 17 06:44:25 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id GAA25374 for current-outgoing; Tue, 17 Oct 1995 06:44:25 -0700 Received: from cabri.obs-besancon.fr (cabri.obs-besancon.fr [193.52.184.3]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id GAA25368 for ; Tue, 17 Oct 1995 06:44:09 -0700 Received: by cabri.obs-besancon.fr (5.57/Ultrix3.0-C) id AA20030; Tue, 17 Oct 95 14:44:31 +0100 Date: Tue, 17 Oct 95 14:44:31 +0100 Message-Id: <9510171344.AA20030@cabri.obs-besancon.fr> From: Jean-Marc Zucconi To: current@freebsd.org Subject: pci not probed X-Mailer: Emacs Sender: owner-current@freebsd.org Precedence: bulk With a kernel from this morning: pcibus_setup(1): mode1 addr port (0xcf8) is 0x8000005c pcibus_setup(2): mode 2 enable port (0xcf8) is 0xff changing root device to sd0a panic: cannot mount root Jean-Marc _____________________________________________________________________________ Jean-Marc Zucconi Observatoire de Besancon F 25010 Besancon cedex PGP Key: finger jmz@cabri.obs-besancon.fr ============================================================================= From owner-freebsd-current Tue Oct 17 07:29:49 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id HAA26448 for current-outgoing; Tue, 17 Oct 1995 07:29:49 -0700 Received: from Sysiphos (Sysiphos.MI.Uni-Koeln.DE [134.95.212.10]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id HAA26393 for ; Tue, 17 Oct 1995 07:28:51 -0700 Received: by Sysiphos id AA24647 (5.67b/IDA-1.5 for current@freebsd.org); Tue, 17 Oct 1995 15:27:02 +0100 Message-Id: <199510171427.AA24647@Sysiphos> From: se@zpr.uni-koeln.de (Stefan Esser) Date: Tue, 17 Oct 1995 15:27:01 +0100 In-Reply-To: Jean-Marc Zucconi "pci not probed" (Oct 17, 14:44) X-Mailer: Mail User's Shell (7.2.6 alpha(2) 7/9/95) To: Jean-Marc Zucconi Subject: Re: pci not probed Cc: current@freebsd.org Sender: owner-current@freebsd.org Precedence: bulk On Oct 17, 14:44, Jean-Marc Zucconi wrote: } Subject: pci not probed } With a kernel from this morning: } } pcibus_setup(1): mode1 addr port (0xcf8) is 0x8000005c } pcibus_setup(2): mode 2 enable port (0xcf8) is 0xff } changing root device to sd0a } panic: cannot mount root Well, yes, sorry ... But what motherboard and chip set is this ? (An Intel Triton, I assume ...) Can you easily go back to the previous revision of /sys/i386/isa/pcibus.c, or do you need me to send a patch ? Regards, STefan -- Stefan Esser, Zentrum fuer Paralleles Rechnen Tel: +49 221 4706021 Universitaet zu Koeln, Weyertal 80, 50931 Koeln FAX: +49 221 4705160 ============================================================================== http://www.zpr.uni-koeln.de/staff/esser/esser.html From owner-freebsd-current Tue Oct 17 07:56:40 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id HAA27375 for current-outgoing; Tue, 17 Oct 1995 07:56:40 -0700 Received: from cabri.obs-besancon.fr (cabri.obs-besancon.fr [193.52.184.3]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id HAA27363 for ; Tue, 17 Oct 1995 07:56:20 -0700 Received: by cabri.obs-besancon.fr (5.57/Ultrix3.0-C) id AA20835; Tue, 17 Oct 95 15:54:32 +0100 Date: Tue, 17 Oct 95 15:54:32 +0100 Message-Id: <9510171454.AA20835@cabri.obs-besancon.fr> From: Jean-Marc Zucconi To: se@zpr.uni-koeln.de Cc: current@freebsd.org In-Reply-To: <199510171427.AA24647@Sysiphos> (se@zpr.uni-koeln.de) Subject: Re: pci not probed X-Mailer: Emacs Sender: owner-current@freebsd.org Precedence: bulk >>>>> Stefan Esser writes: > On Oct 17, 14:44, Jean-Marc Zucconi wrote: > } Subject: pci not probed > } With a kernel from this morning: > } > } pcibus_setup(1): mode1 addr port (0xcf8) is 0x8000005c > } pcibus_setup(2): mode 2 enable port (0xcf8) is 0xff > } changing root device to sd0a > } panic: cannot mount root > Well, yes, sorry ... > But what motherboard and chip set is this ? > (An Intel Triton, I assume ...) Yes: Asus P55TP4XE/triton > Can you easily go back to the previous revision of > /sys/i386/isa/pcibus.c, or do you need me to send > a patch ? No problem, I will check out the previous version of pcibus.c Jean-Marc > Regards, STefan > -- > Stefan Esser, Zentrum fuer Paralleles Rechnen Tel: +49 221 4706021 > Universitaet zu Koeln, Weyertal 80, 50931 Koeln FAX: +49 221 4705160 > ============================================================================== > http://www.zpr.uni-koeln.de/staff/esser/esser.html _____________________________________________________________________________ Jean-Marc Zucconi Observatoire de Besancon F 25010 Besancon cedex PGP Key: finger jmz@cabri.obs-besancon.fr ============================================================================= From owner-freebsd-current Tue Oct 17 08:39:54 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id IAA28809 for current-outgoing; Tue, 17 Oct 1995 08:39:54 -0700 Received: from Sysiphos (Sysiphos.MI.Uni-Koeln.DE [134.95.212.10]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id IAA28677 for ; Tue, 17 Oct 1995 08:37:35 -0700 Received: by Sysiphos id AA25210 (5.67b/IDA-1.5 for current@freebsd.org); Tue, 17 Oct 1995 16:29:13 +0100 Message-Id: <199510171529.AA25210@Sysiphos> From: se@zpr.uni-koeln.de (Stefan Esser) Date: Tue, 17 Oct 1995 16:29:12 +0100 In-Reply-To: Jean-Marc Zucconi "Re: pci not probed" (Oct 17, 15:54) X-Mailer: Mail User's Shell (7.2.6 alpha(2) 7/9/95) To: Jean-Marc Zucconi Subject: Re: pci not probed Cc: current@freebsd.org Sender: owner-current@freebsd.org Precedence: bulk On Oct 17, 15:54, Jean-Marc Zucconi wrote: } Subject: Re: pci not probed } >>>>> Stefan Esser writes: } } > On Oct 17, 14:44, Jean-Marc Zucconi wrote: } > } Subject: pci not probed } > } With a kernel from this morning: } > } } > } pcibus_setup(1): mode1 addr port (0xcf8) is 0x8000005c O well, the code made the assumption, that the MSB was cleared by the BIOS, since this is the quiescent state ... I've just checked in a new version of pcibus.c, which ought to support the Triton again ... You should be able to use that version (and please let me know, if it doesn't work for you!). Sorry for the inconvenience. Regards, STefan -- Stefan Esser, Zentrum fuer Paralleles Rechnen Tel: +49 221 4706021 Universitaet zu Koeln, Weyertal 80, 50931 Koeln FAX: +49 221 4705160 ============================================================================== http://www.zpr.uni-koeln.de/staff/esser/esser.html From owner-freebsd-current Tue Oct 17 08:43:46 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id IAA28956 for current-outgoing; Tue, 17 Oct 1995 08:43:46 -0700 Received: from Sysiphos (Sysiphos.MI.Uni-Koeln.DE [134.95.212.10]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id IAA28950 ; Tue, 17 Oct 1995 08:43:37 -0700 Received: by Sysiphos id AA25349 (5.67b/IDA-1.5); Tue, 17 Oct 1995 16:42:13 +0100 Message-Id: <199510171542.AA25349@Sysiphos> From: se@zpr.uni-koeln.de (Stefan Esser) Date: Tue, 17 Oct 1995 16:42:13 +0100 In-Reply-To: gillham@andrews.edu (Andrew Gillham) "Stability questions..." (Oct 17, 11:12) X-Mailer: Mail User's Shell (7.2.6 alpha(2) 7/9/95) To: gillham@andrews.edu (Andrew Gillham) Subject: Re: Stability questions... Cc: hackers@freebsd.org, current@freebsd.org Sender: owner-current@freebsd.org Precedence: bulk On Oct 17, 11:12, Andrew Gillham wrote: } Subject: Stability questions... } sure, as something else broke. After a few minutes of compiling (on the } NFS mount) the kernel says "Biodone: buffer already done" or something } and hangs my compile. (sorry for the not exact errors, but I'm at } work, and the PCs are at home) Accessing the NFS mountpoint will hang } my shell, but I can still halt the box from another console. The same problem exists for me since October 5th ... I had sent a message on this topic some 10 days ago. There are lot's of "biodone: buffer already done" messages on the console, and the system hangs after some time (and is unable to unmount the file systems, if I try to reboot in time). (I had reported, that a "tail" of some file on a NFS mounted file system hung in a kernel wait, while a "cat" of the same file did work just fine on another virtual console ...) I'm running -current on my development system, and have not tried -stable. Regards, STefan -- Stefan Esser, Zentrum fuer Paralleles Rechnen Tel: +49 221 4706021 Universitaet zu Koeln, Weyertal 80, 50931 Koeln FAX: +49 221 4705160 ============================================================================== http://www.zpr.uni-koeln.de/staff/esser/esser.html From owner-freebsd-current Tue Oct 17 11:03:10 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id LAA02033 for current-outgoing; Tue, 17 Oct 1995 11:03:10 -0700 Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id LAA02012 ; Tue, 17 Oct 1995 11:03:02 -0700 Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id KAA27890; Tue, 17 Oct 1995 10:55:49 -0700 From: Terry Lambert Message-Id: <199510171755.KAA27890@phaeton.artisoft.com> Subject: Re: getdtablesize() broken? To: bakul@netcom.com (Bakul Shah) Date: Tue, 17 Oct 1995 10:55:49 -0700 (MST) Cc: bde@zeta.org.au, terry@lambert.org, current@freefall.freebsd.org, hackers@freefall.freebsd.org In-Reply-To: <199510171028.DAA04795@netcom5.netcom.com> from "Bakul Shah" at Oct 17, 95 03:28:53 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2286 Sender: owner-current@FreeBSD.org Precedence: bulk > > > I get 64. Perhaps you have a shell bug. > > Possible. Or may be there is an exra fd open. zsh seems to be > the culprit here. > > > >It is this hardwired use of FD_SETSIZE *in* the kernel I am > > >bitching about. > > > The limit is built in to the fd_set type. The FD_SETSIZE check > > just makes sure that all the bits fit in the kernel fd_set > > variables. The kernel needs to use dynamically allocated > > arrays to hold more bits, and different methods to access the > > bits... > > But of course! [My fix was partial but if you decide to > banish FD_SETSIZE removing all use of fd_set follows -- I > should never respond when I am half asleep; but that is when > I get some free time :-(] Anyway, instead of fd_set the > kernel needs to use just int* (and allocate enough ints). > Instead of macros FD_{SET,CLR,ISSET,ZERO} it can use > > #define SET_BIT(n, p) ((p)[(n)/NFDBITS] |= (1 << ((n) % NFDBITS))) > #define CLR_BIT(n, p) ((p)[(n)/NFDBITS] &= ~(1 << ((n) % NFDBITS))) > #define ISSET_BIT(n, p) ((p)[(n)/NFDBITS] & (1 << ((n) % NFDBITS))) > #define ZERO_BITS(n, p) bzero((char*)(p), \ > howmany((n), NFDBITS) * sizeof(fd_mask)) I assume (well, you assume 8-)) the size of the bit vector array type in the declaration is sizeof(x) == NFDBITS? This leads to: #define MAX_BIT(x) (sizeof(x)/NFDBITS) I don't see where this massive amount of runtime work is really worth it. /usr/unclude/sys/types.h has the forllowing in it: #ifndef FD_SETSIZE #define FD_SETSIZE 256 #endif meaning you can option it higher in the kernel and you can #define it higher before including . > [Going off on another tangent -- I wish we can start using > inline functions instead of such odious macros -- even though > inline is not ISO sanctioned every compiler worth its salt > provides it] It should be an option. But like having C equivalents for asm library routines or compiler inlines, it needs to be allowed to be turned off. Most ports do not start out self hosting until quite some way down the road, and the reason such things are avoided (or replicated) is to ease porting requirements. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-current Tue Oct 17 12:28:25 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id MAA04399 for current-outgoing; Tue, 17 Oct 1995 12:28:25 -0700 Received: from netcom23.netcom.com (root@netcom23.netcom.com [192.100.81.137]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id MAA04379 ; Tue, 17 Oct 1995 12:28:18 -0700 Received: from localhost by netcom23.netcom.com (8.6.12/Netcom) id LAA28198; Tue, 17 Oct 1995 11:51:28 -0700 Message-Id: <199510171851.LAA28198@netcom23.netcom.com> To: Terry Lambert cc: bde@zeta.org.au, current@freefall.freebsd.org, hackers@freefall.freebsd.org Subject: Re: getdtablesize() broken? In-reply-to: Your message of "Tue, 17 Oct 95 10:55:49 PDT." <199510171755.KAA27890@phaeton.artisoft.com> Date: Tue, 17 Oct 95 11:51:24 -0700 From: Bakul Shah Sender: owner-current@FreeBSD.org Precedence: bulk > I assume (well, you assume 8-)) the size of the bit vector array type > in the declaration is sizeof(x) == NFDBITS? No. NFDBITS == sizeof (fd_mask) * 8. Type fd_mask is defined to be long. As far as the kernel is concerned, select() args that are bit vector arrays, are *large* enough to hold nfds number of descriptors, where nfds is the first arg to select(). The (uap->nd <= p->p_fd->fd_nfiles) check bounds this number to something sensible. > I don't see where this massive amount of runtime work is really worth it. It is not massive amount of runtime work. Changes are fairly straight forward. The runtime cost is small. It is worth it to me. But a more general argument is that without this fix file descriptors > FD_SETSIZE are second class citizens. You _are_ a fan of consistency, are you?:-) > /usr/unclude/sys/types.h has the forllowing in it: > #ifndef FD_SETSIZE > #define FD_SETSIZE 256 > #endif This is well and good for *user* programs. Most programs don't want to bother with changing FD_SETSIZE and kernel changes I am proposing are transparent to such programs. > meaning you can option it higher in the kernel and you can #define it > higher before including . This is not a good option for commercial software. Customers generally don't like to rebuild the kernel for such things. So I am forced to use the more complex solution. It is difficult enough to convince companies to support {Net,Free}BSD -- unfortunately a lot more difficult than Linux (which is wildly more popular inspite of its growing pains) -- and this sort of scaling problems makes it harder -- especially when Solaris, IRIX etc. already do them right. > It should be an option. But like having C equivalents for asm library > routines or compiler inlines, it needs to be allowed to be turned off. > Most ports do not start out self hosting until quite some way down the > road, and the reason such things are avoided (or replicated) is to > ease porting requirements. Fair enough. So just do #define __inline__ /*inline*/ :-) --bakul From owner-freebsd-current Tue Oct 17 12:39:49 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id MAA04670 for current-outgoing; Tue, 17 Oct 1995 12:39:49 -0700 Received: from MediaCity.com (root@easy1.mediacity.com [205.216.172.10]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id MAA04665 for ; Tue, 17 Oct 1995 12:39:46 -0700 Received: (from brian@localhost) by MediaCity.com (8.6.11/8.6.9) id MAA21694; Tue, 17 Oct 1995 12:41:44 -0700 From: Brian Litzinger Message-Id: <199510171941.MAA21694@MediaCity.com> Subject: Re: crash To: jc@irbs.com (John Capo) Date: Tue, 17 Oct 1995 12:41:44 -0700 (PDT) Cc: nathan@netrail.net, current@FreeBSD.org, et-users@netrail.net, freebsd-isp@netrail.net In-Reply-To: <199510171310.JAA17136@irbs.irbs.com> from "John Capo" at Oct 17, 95 09:10:36 am X-Mailer: ELM [version 2.4 PL24 ME8a] Content-Type: text Content-Length: 1213 Sender: owner-current@FreeBSD.org Precedence: bulk > > Nathan Stratton writes: > > > > > > I am using a 486 DX4 100 as a router, I have a T1 from sprint and a T1 > > form mci connected to it. I also have two 10 meg ethernet cards. It is > > running freebsd 2.0.5 and has about 31,000 routes in it's routing table. > > Well my problem is every day or so it will crash. My T1 cards need to be > > reset befoer they reboot so when the system reboots it just locks up > > becaue the T1 cards were not reset. > > > > I changed my reboot command to reset the cards, so if I do a shutdown it > > works great and resets my cards. But what it looks like when the system > > crashes it does not run reboot. What does it run? How can I make my > > system reset my T1 cards just after it crashes and befoer it reboots the > > system? > > > > The kernel does not run any user land programs after a panic. The > T1 cards should be reset by the driver when they are attached. > Dennis??? I believe the problem is that the system cannot successfully reboot unless the cards are reset before the reboot attempt. Which doesn't happen in a crash. On the other hand, if you run the cards in 8 bit mode the problem will go away. Brian Litzinger brian@Mediacity.com From owner-freebsd-current Tue Oct 17 15:10:06 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id PAA10799 for current-outgoing; Tue, 17 Oct 1995 15:10:06 -0700 Received: from cabri.obs-besancon.fr (cabri.obs-besancon.fr [193.52.184.3]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id PAA10784 for ; Tue, 17 Oct 1995 15:09:50 -0700 Received: by cabri.obs-besancon.fr (5.57/Ultrix3.0-C) id AA24314; Tue, 17 Oct 95 23:10:02 +0100 Date: Tue, 17 Oct 95 23:10:02 +0100 Message-Id: <9510172210.AA24314@cabri.obs-besancon.fr> From: Jean-Marc Zucconi To: se@zpr.uni-koeln.de Cc: current@freebsd.org In-Reply-To: <199510171529.AA25210@Sysiphos> (se@zpr.uni-koeln.de) Subject: Re: pci not probed X-Mailer: Emacs Sender: owner-current@freebsd.org Precedence: bulk >>>>> Stefan Esser writes: > I've just checked in a new version of pcibus.c, which ought to > support the Triton again ... > You should be able to use that version (and please let me know, > if it doesn't work for you!). I tried with the new version (1.18) and it does not work. I have no problem with version 1.16 Jean-Marc _____________________________________________________________________________ Jean-Marc Zucconi Observatoire de Besancon F 25010 Besancon cedex PGP Key: finger jmz@cabri.obs-besancon.fr ============================================================================= From owner-freebsd-current Tue Oct 17 15:18:12 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id PAA10935 for current-outgoing; Tue, 17 Oct 1995 15:18:12 -0700 Received: from GndRsh.aac.dev.com (GndRsh.aac.dev.com [198.145.92.241]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id PAA10901 for ; Tue, 17 Oct 1995 15:16:49 -0700 Received: (from rgrimes@localhost) by GndRsh.aac.dev.com (8.6.12/8.6.12) id PAA16005; Tue, 17 Oct 1995 15:15:09 -0700 From: "Rodney W. Grimes" Message-Id: <199510172215.PAA16005@GndRsh.aac.dev.com> Subject: Re: crash To: brian@MediaCity.com (Brian Litzinger) Date: Tue, 17 Oct 1995 15:15:09 -0700 (PDT) Cc: jc@irbs.com, nathan@netrail.net, current@FreeBSD.org, et-users@netrail.net, freebsd-isp@netrail.net In-Reply-To: <199510171941.MAA21694@MediaCity.com> from "Brian Litzinger" at Oct 17, 95 12:41:44 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1718 Sender: owner-current@FreeBSD.org Precedence: bulk > > > > > Nathan Stratton writes: > > > > > > > > > I am using a 486 DX4 100 as a router, I have a T1 from sprint and a T1 > > > form mci connected to it. I also have two 10 meg ethernet cards. It is > > > running freebsd 2.0.5 and has about 31,000 routes in it's routing table. > > > Well my problem is every day or so it will crash. My T1 cards need to be > > > reset befoer they reboot so when the system reboots it just locks up > > > becaue the T1 cards were not reset. > > > > > > I changed my reboot command to reset the cards, so if I do a shutdown it > > > works great and resets my cards. But what it looks like when the system > > > crashes it does not run reboot. What does it run? How can I make my > > > system reset my T1 cards just after it crashes and befoer it reboots the > > > system? > > > > > > > The kernel does not run any user land programs after a panic. The > > T1 cards should be reset by the driver when they are attached. > > Dennis??? > > I believe the problem is that the system cannot successfully reboot unless > the cards are reset before the reboot attempt. Which doesn't happen in > a crash. > > On the other hand, if you run the cards in 8 bit mode the problem will > go away. If that is the case then the problem is that you are mixing 8 bit and 16 bit cards within the same 128K of memory address space in the ISA hole. This is in violation of the spec :-(. Move your shared memory area such that the mixing no longer occurs and your problem should go away. > Brian Litzinger > brian@Mediacity.com -- Rod Grimes rgrimes@gndrsh.aac.dev.com Accurate Automation Company Reliable computers for FreeBSD From owner-freebsd-current Tue Oct 17 15:42:15 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id PAA11847 for current-outgoing; Tue, 17 Oct 1995 15:42:15 -0700 Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id PAA11832 ; Tue, 17 Oct 1995 15:42:05 -0700 Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id PAA28761; Tue, 17 Oct 1995 15:35:22 -0700 From: Terry Lambert Message-Id: <199510172235.PAA28761@phaeton.artisoft.com> Subject: Re: getdtablesize() broken? To: bakul@netcom.com (Bakul Shah) Date: Tue, 17 Oct 1995 15:35:22 -0700 (MST) Cc: terry@lambert.org, bde@zeta.org.au, current@freefall.freebsd.org, hackers@freefall.freebsd.org In-Reply-To: <199510171851.LAA28198@netcom23.netcom.com> from "Bakul Shah" at Oct 17, 95 11:51:24 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2984 Sender: owner-current@FreeBSD.org Precedence: bulk > > I don't see where this massive amount of runtime work is really worth it. > > It is not massive amount of runtime work. Changes are > fairly straight forward. The runtime cost is small. > > It is worth it to me. But a more general argument is that > without this fix file descriptors > FD_SETSIZE are second > class citizens. You _are_ a fan of consistency, are you?:-) Basically, all of the user space code that uses the standard-since-4.2 sys/types.h definitions would need to be rewritten. This is what I meant. > > /usr/unclude/sys/types.h has the forllowing in it: > > > #ifndef FD_SETSIZE > > #define FD_SETSIZE 256 > > #endif > > This is well and good for *user* programs. Most programs don't > want to bother with changing FD_SETSIZE and kernel changes > I am proposing are transparent to such programs. ??? How do I make a program which doesn't guard using FD_SETSIZE the max fd it tries to select upon suddenly have a larger statically or stack declared bitvector array? I can't. Programs that "don't bother" will get the FD_SETSIZE limit or get an error from the kernel, or more likely, corrupt whatever data lives right after where the fd_set lives and eventually mysteriously fail. Checking the limit isn't optional. Reacting to a discrepancy between the user and kernel limits (ie: handling error returns from select) is also not optional. Setting the limit: that's optionalm both in the kernel and in user space. > > meaning you can option it higher in the kernel and you can #define it > > higher before including . > > This is not a good option for commercial software. > Customers generally don't like to rebuild the kernel for > such things. So I am forced to use the more complex > solution. I don't see how you prevent the kernel from twiddling user bits that follow the fd_set declaration area in the processes address space (or getting a SEGV if it's the last item in the data segment) as a result of shoving down a number that wasn't guarded based on the user's FD_SETSIZE. This seems to be a recipe for bizarre and undetectable data corruption. > It is difficult enough to convince companies to support > {Net,Free}BSD -- unfortunately a lot more difficult than > Linux (which is wildly more popular inspite of its growing > pains) -- and this sort of scaling problems makes it harder > -- especially when Solaris, IRIX etc. already do them right. If we change the macro names, that means source changes for the people doing the porting, and that won't go over well. The problem occurs in large service sites. And the problem is related to the kernel not knowing how big the user FD_SETSIZE is at select call time. I don't see that going away without an interface change. > Fair enough. So just do > #define __inline__ /*inline*/ > :-) #define __inline__ static ? Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-current Tue Oct 17 17:34:36 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id RAA15812 for current-outgoing; Tue, 17 Oct 1995 17:34:36 -0700 Received: from eikon.e-technik.tu-muenchen.de (root@eikon.regent.e-technik.tu-muenchen.de [129.187.42.3]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id RAA15807 for ; Tue, 17 Oct 1995 17:34:32 -0700 Received: from vector.eikon.e-technik.tu-muenchen.de (vector.eikon.e-technik.tu-muenchen.de [129.187.142.36]) by eikon.e-technik.tu-muenchen.de (8.6.12/8.6.9) with ESMTP id BAA27554 for ; Wed, 18 Oct 1995 01:34:20 +0100 Received: from localhost (localhost [127.0.0.1]) by vector.eikon.e-technik.tu-muenchen.de (8.6.12/8.6.9) with SMTP id BAA15853 for ; Wed, 18 Oct 1995 01:34:26 +0100 Message-Id: <199510180034.BAA15853@vector.eikon.e-technik.tu-muenchen.de> X-Authentication-Warning: vector.eikon.e-technik.tu-muenchen.de: Host localhost didn't use HELO protocol To: current@freebsd.org Subject: http://www.freebsd.org/~jhs/freebsd_people.html Reply-To: "Julian H. Stacey" X-Organisation: Vector Systems Ltd, Holz Strasse 27d, 80469 Munich, Germany X-Occupation: Internet Unix C & Systems Engineering Consultant X-Phone: +49 89 268616 Fax: +49 89 2608126 Timezone: GMT+1 X-Web: http://www.freebsd.org/~jhs/ Date: Wed, 18 Oct 1995 01:34:25 +0100 From: "Julian H. Stacey" Sender: owner-current@freebsd.org Precedence: bulk I've improved http://www.freebsd.org/~jhs/freebsd_people.html with a suggestion from jfieber (click on icon faces to get larger faces) & have also improved a couple of other things, More faces & details are invited, for details read the page. Julian S jhs From owner-freebsd-current Tue Oct 17 22:03:40 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id WAA26714 for current-outgoing; Tue, 17 Oct 1995 22:03:40 -0700 Received: from bunyip.cc.uq.oz.au (bunyip.cc.uq.oz.au [130.102.2.1]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id WAA26709 for ; Tue, 17 Oct 1995 22:03:38 -0700 Received: from cc.uq.oz.au by bunyip.cc.uq.oz.au id <21211-0@bunyip.cc.uq.oz.au>; Wed, 18 Oct 1995 13:55:26 +1000 Received: from netfl15a.devetir.qld.gov.au by pandora.devetir.qld.gov.au (8.6.10/DEVETIR-E0.3a) with ESMTP id MAA01925 for ; Wed, 18 Oct 1995 12:35:40 +1000 Received: from localhost by netfl15a.devetir.qld.gov.au (8.6.8.1/DEVETIR-0.1) id CAA20186 for ; Wed, 18 Oct 1995 02:34:43 GMT Message-Id: <199510180234.CAA20186@netfl15a.devetir.qld.gov.au> X-Mailer: exmh version 1.6.4 10/10/95 To: current@freebsd.org Subject: Errors building some LKMs in -current Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 18 Oct 1995 12:34:42 +1000 From: Stephen Hocking Sender: owner-current@freebsd.org Precedence: bulk I get (in ibcs2 & linux, to mention a couple) errors when doing the final stage in the creation of the module ld -r -o tmp.o ibcs2.o ibcs2_errno.o ibcs2_ipc.o ibcs2_stat.o ibcs2_misc.o ibcs 2_fcntl.o ibcs2_signal.o ibcs2_sysent.o ibcs2_ioctl.o ibcs2_socksys.o ibcs2_util .o ibcs2_xenix.o ibcs2_xenix_sysent.o ibcs2_isc.o ibcs2_isc_sysent.o ibcs2_msg.o ibcs2_other.o ibcs2_sysi86.o ibcs2_sysvec.o symorder -c symb.tmp tmp.o symorder: 1 symbol not found: _ibcs2_mod I've tried clean and doing make depends beforehand, but it persists. Any clues (It doesn't seem to happen for most of the FS LKMs)? Stephen -- I do not speak for the Worker's Compensation Board of Queensland - They don't pay me enough for that! From owner-freebsd-current Wed Oct 18 00:08:31 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id AAA02118 for current-outgoing; Wed, 18 Oct 1995 00:08:31 -0700 Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id AAA02101 ; Wed, 18 Oct 1995 00:08:22 -0700 Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id RAA16305; Wed, 18 Oct 1995 17:04:23 +1000 Date: Wed, 18 Oct 1995 17:04:23 +1000 From: Bruce Evans Message-Id: <199510180704.RAA16305@godzilla.zeta.org.au> To: bakul@netcom.com, terry@lambert.org Subject: Re: getdtablesize() broken? Cc: bde@zeta.org.au, current@freefall.freebsd.org, hackers@freefall.freebsd.org Sender: owner-current@FreeBSD.org Precedence: bulk >> > I don't see where this massive amount of runtime work is really worth it. >> >> It is not massive amount of runtime work. Changes are >> fairly straight forward. The runtime cost is small. >> ... >Basically, all of the user space code that uses the standard-since-4.2 >sys/types.h definitions would need to be rewritten. This is what I >meant. The select() interface has pointers to fd_set's, so it doesn't rule out using arrays of fd_set's. I think only the FD_ macros and the documentation would need to be rewritten. >> This is well and good for *user* programs. Most programs don't >> want to bother with changing FD_SETSIZE and kernel changes >> I am proposing are transparent to such programs. >??? >How do I make a program which doesn't guard using FD_SETSIZE the max fd >it tries to select upon suddenly have a larger statically or stack >declared bitvector array? Don't use the standard FD_ macros. Anyway, the kernel needs to handle an arbitrary FD_SETSIZE for compatibility. There is no reason why the Linux FD_SETSIZE should be as limited as the FD_SETSIZE that the kernel happened to be compiled with. Fixed limits defeat binary compatibility. This is particularly annoying for fixed limits like OPEN_MAX that aren't actually fixed even on the host OS. See for a long list of bogus limits. Bruce From owner-freebsd-current Wed Oct 18 01:01:51 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id BAA03414 for current-outgoing; Wed, 18 Oct 1995 01:01:51 -0700 Received: from ibp.ibp.fr (ibp.ibp.fr [132.227.60.30]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id BAA03405 for ; Wed, 18 Oct 1995 01:01:46 -0700 Received: from blaise.ibp.fr (blaise.ibp.fr [132.227.60.1]) by ibp.ibp.fr (8.6.12/jtpda-5.0) with ESMTP id JAA01013 ; Wed, 18 Oct 1995 09:01:38 +0100 Received: from (uucp@localhost) by blaise.ibp.fr (8.6.12/jtpda-5.0) with UUCP id JAA04089 ; Wed, 18 Oct 1995 09:01:28 +0100 Received: (from roberto@localhost) by keltia.freenix.fr (8.7.1/keltia-uucp-2.6) id IAA06580; Wed, 18 Oct 1995 08:33:58 +0100 (MET) From: Ollivier Robert Message-Id: <199510180733.IAA06580@keltia.freenix.fr> Subject: Re: Errors building some LKMs in -current To: sysseh@devetir.qld.gov.au (Stephen Hocking) Date: Wed, 18 Oct 1995 08:33:57 +0100 (MET) Cc: current@freebsd.org In-Reply-To: <199510180234.CAA20186@netfl15a.devetir.qld.gov.au> from "Stephen Hocking" at Oct 18, 95 12:34:42 pm X-Operating-System: FreeBSD 2.2-CURRENT ctm#1215 X-Mailer: ELM [version 2.4 PL24 ME8b] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@freebsd.org Precedence: bulk It seems that Stephen Hocking said: > I've tried clean and doing make depends beforehand, but it persists. Any > clues (It doesn't seem to happen for most of the FS LKMs)? It also happens with the new one (wcd and atapi). -- Ollivier ROBERT -=- The daemon is FREE! -=- roberto@keltia.frmug.fr.net FreeBSD keltia.freenix.fr 2.2-CURRENT #0: Sat Oct 14 19:05:10 MET 1995 From owner-freebsd-current Wed Oct 18 01:11:39 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id BAA03749 for current-outgoing; Wed, 18 Oct 1995 01:11:39 -0700 Received: from silvia.HIP.Berkeley.EDU (silvia.HIP.Berkeley.EDU [136.152.64.181]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id BAA03738 for ; Wed, 18 Oct 1995 01:11:33 -0700 Received: (from asami@localhost) by silvia.HIP.Berkeley.EDU (8.6.12/8.6.9) id BAA00674; Wed, 18 Oct 1995 01:11:18 -0700 Date: Wed, 18 Oct 1995 01:11:18 -0700 Message-Id: <199510180811.BAA00674@silvia.HIP.Berkeley.EDU> To: jmz@cabri.obs-besancon.fr CC: se@ZPR.Uni-Koeln.DE, current@freebsd.org In-reply-to: <9510172210.AA24314@cabri.obs-besancon.fr> (message from Jean-Marc Zucconi on Tue, 17 Oct 95 23:10:02 +0100) Subject: Re: pci not probed From: asami@cs.berkeley.edu (Satoshi Asami) Sender: owner-current@freebsd.org Precedence: bulk * > You should be able to use that version (and please let me know, * > if it doesn't work for you!). * * I tried with the new version (1.18) and it does not work. I have no * problem with version 1.16 Just FYI, I had the exact same problem (that I sent a report to -current...wonder why you (Stefan) didn't seem to recognize it) and it went away with revision 1.19 (the next one).... SiS chipset, Award Modular BIOS, BTW.... Satoshi From owner-freebsd-current Wed Oct 18 01:32:42 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id BAA05326 for current-outgoing; Wed, 18 Oct 1995 01:32:42 -0700 Received: from netcom22.netcom.com (bakul@netcom22.netcom.com [192.100.81.136]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id BAA05311 ; Wed, 18 Oct 1995 01:32:36 -0700 Received: from localhost by netcom22.netcom.com (8.6.12/Netcom) id BAA18615; Wed, 18 Oct 1995 01:30:42 -0700 Message-Id: <199510180830.BAA18615@netcom22.netcom.com> To: Bruce Evans , terry@lambert.org Cc: current@freefall.freebsd.org, hackers@freefall.freebsd.org Subject: Re: getdtablesize() broken? In-reply-to: Your message of "Wed, 18 Oct 95 17:04:23 +1000." <199510180704.RAA16305@godzilla.zeta.org.au> Date: Wed, 18 Oct 95 01:30:40 -0700 From: Bakul Shah Sender: owner-current@FreeBSD.org Precedence: bulk Bruce: > The select() interface has pointers to fd_set's, so it doesn't rule out > using arrays of fd_set's. I think only the FD_ macros and the > documentation would need to be rewritten. fd_set is a struct containing just an array of longs. You don't need to make an array of fd_set -- just use a bigger array (big enough to hold the highest valid fd). Me in an earlier message: >> This is well and good for *user* programs. Most programs don't >> want to bother with changing FD_SETSIZE and kernel changes >> I am proposing are transparent to such programs. What I meant is this: If the _kernel_ treats select()'s readfds, writefds, exceptfds as ptrs to int-arrays (and *not* fd_set ptrs), and allocates kernel copies of the same dynamically, this change removes the fixed limit and is transparent to user programs. All old programs using select continue working (for whatever value of FD_SETSIZE provided descriptors limit is high enough). You can even do this and it will work: cc -DFD_SETSIZE=33 foo.c cc -DFD_SETSIZE=333 foo.c You can also use dynamically or statically allocated long- int-arrays instead of fd_set and things will keep working (though lint will complain). Terry responded: >How do I make a program which doesn't guard using FD_SETSIZE the max fd >it tries to select upon suddenly have a larger statically or stack >declared bitvector array? Your program should either use fd_set (and implicitly FD_SETSIZE) or just do dynamic allocation of long-int-arrays to hold the bitvectors. (BTW, gcc will allow you to do dynamic alloc. on the stack). Basically if your program uses fixed size sets, fd_set is fine -- just redefine FD_SETSIZE to what you want. If your program wants to adjust the array size dynamically you are better off using long-int-arrays. But in the latter case you can't use the FD_ macros. What I do in C++ is define a class with methods like add, remove, ismember, members (to return a list of ints corresponding to set bits) etc. You can do something similar in C (but to avoid the overhead you'd've to use macros or inline functions). Bruce again: > Anyway, the kernel needs to handle an arbitrary FD_SETSIZE for > compatibility. There is no reason why the Linux FD_SETSIZE should be as > limited as the FD_SETSIZE that the kernel happened to be compiled with. That is exactly the point I have been trying to make. Thanks! I should've just made the change - would've been quicker!! --bakul From owner-freebsd-current Wed Oct 18 02:38:58 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id CAA01615 for current-outgoing; Wed, 18 Oct 1995 02:38:58 -0700 Received: from tfs.com (tfs.com [140.145.250.1]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id CAA01610 for ; Wed, 18 Oct 1995 02:38:56 -0700 Received: from critter.tfs.com by tfs.com (smail3.1.28.1) with SMTP id m0t5UxM-0003vnC; Wed, 18 Oct 95 02:38 PDT Received: from localhost (localhost [127.0.0.1]) by critter.tfs.com (8.6.11/8.6.9) with SMTP id KAA00278; Wed, 18 Oct 1995 10:38:41 +0100 X-Authentication-Warning: critter.tfs.com: Host localhost didn't use HELO protocol To: Stephen Hocking cc: current@freebsd.org Subject: Re: Errors building some LKMs in -current In-reply-to: Your message of "Wed, 18 Oct 1995 12:34:42 +1000." <199510180234.CAA20186@netfl15a.devetir.qld.gov.au> Date: Wed, 18 Oct 1995 10:38:39 +0100 Message-ID: <276.814009119@critter.tfs.com> From: Poul-Henning Kamp Sender: owner-current@freebsd.org Precedence: bulk > I get (in ibcs2 & linux, to mention a couple) errors when doing the final > stage in the creation of the module > symorder: 1 symbol not found: > _ibcs2_mod > > I've tried clean and doing make depends beforehand, but it persists. Any clue Yes, somebody (TM) need to figure out exactly what symbols those LKMs should export. Ideally the "-e FOO" symbol should be ibcs2_mod for instance... -- Poul-Henning Kamp | phk@FreeBSD.ORG FreeBSD Core-team. http://www.freebsd.org/~phk | phk@login.dknet.dk Private mailbox. whois: [PHK] | phk@ref.tfs.com TRW Financial Systems, Inc. Future will arrive by its own means, progress not so. From owner-freebsd-current Wed Oct 18 04:43:12 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id EAA07407 for current-outgoing; Wed, 18 Oct 1995 04:43:12 -0700 Received: from hq.icb.chel.su (icb-rich-gw.icb.chel.su [193.125.10.34]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id EAA07385 ; Wed, 18 Oct 1995 04:41:37 -0700 Received: from localhost (babkin@localhost) by hq.icb.chel.su (8.6.5/8.6.5) id PAA15264; Wed, 18 Oct 1995 15:12:12 +0500 From: "Serge A. Babkin" Message-Id: <199510181012.PAA15264@hq.icb.chel.su> Subject: Re: 3c509 in -current needs patching To: gena@NetVision.net.il Date: Wed, 18 Oct 1995 15:12:12 +0500 (GMT+0500) Cc: wollman@freebsd.org, jkh@time.cdrom.com, current@freebsd.org In-Reply-To: from "Gennady Sorokopud" at Oct 17, 95 12:15:38 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 14910 Sender: owner-current@freebsd.org Precedence: bulk > >> > >> When we are on the subject..can you make if_ep.c support IPX? > >> (latest ipx patches adds IPX support only to if_ed.c) > > This patch is combined from the previos one (that contained a bug, the word SIOCGIFADDR was written as SIOCSGIFADDR) and the IPX support. The $Id$ string says that the last patch applied was made by Garrett Wollman, so may be he can review and commit this patch, huh ? Thank you! Serge Babkin ! (babkin@hq.icb.chel.su) ! Headquarter of Joint Stock Commercial Bank "Chelindbank" ! Chelyabinsk, Russia ------------------------- cut here -------------------------------------- *** /usr/src-cur/sys/i386/isa/if_ep.c Mon Oct 16 17:40:39 1995 --- if_ep.c Wed Oct 18 12:30:37 1995 *************** *** 38,45 **** */ /* - * $Id: if_ep.c,v 1.31 1995/10/13 19:47:44 wollman Exp $ - * * Promiscuous mode added and interrupt logic slightly changed * to reduce the number of adapter failures. Transceiver select * logic changed to use value from EEPROM. Autoconfiguration --- 38,43 ---- *************** *** 87,92 **** --- 85,95 ---- #include #endif + #ifdef IPX + #include + #include + #endif + #if NBPFILTER > 0 #include #include *************** *** 100,105 **** --- 103,109 ---- #include #include #include + #include static int epprobe __P((struct isa_device *)); static int epattach __P((struct isa_device *)); *************** *** 117,122 **** --- 121,127 ---- static int send_ID_sequence __P((int)); static int get_eeprom_data __P((int, int)); + static struct ep_board *ep_look_for_board_at(struct isa_device *); struct ep_softc ep_softc[NEP]; *************** *** 132,145 **** }; static struct kern_devconf kdc_ep[NEP] = { { ! 0, 0, 0, /* filled in by dev_attach */ "ep", 0, { MDDT_ISA, 0, "net" }, isa_generic_externalize, 0, 0, ISA_EXTERNALLEN, ! &kdc_isa0, /* parent */ ! 0, /* parentdata */ ! DC_UNCONFIGURED, /* state */ "3Com 3C509 Ethernet adapter", ! DC_CLS_NETIF /* class */ } }; static inline void --- 137,150 ---- }; static struct kern_devconf kdc_ep[NEP] = { { ! 0, 0, 0, /* filled in by dev_attach */ "ep", 0, { MDDT_ISA, 0, "net" }, isa_generic_externalize, 0, 0, ISA_EXTERNALLEN, ! &kdc_isa0, /* parent */ ! 0, /* parentdata */ ! DC_UNCONFIGURED, /* state */ "3Com 3C509 Ethernet adapter", ! DC_CLS_NETIF /* class */ } }; static inline void *************** *** 154,164 **** int ep_current_tag = EP_LAST_TAG + 1; ! struct { ! int epb_addr; /* address of this board */ ! char epb_used; /* was this entry already used for configuring ? */ ! } ! ep_board[EP_MAX_BOARDS + 1]; static int eeprom_rdy(is) --- 159,165 ---- int ep_current_tag = EP_LAST_TAG + 1; ! struct ep_board ep_board[EP_MAX_BOARDS + 1]; static int eeprom_rdy(is) *************** *** 174,184 **** return (1); } ! static int ep_look_for_board_at(is) struct isa_device *is; { ! int data, i, j, io_base, id_port = EP_ID_PORT; int nisa = 0, neisa = 0; if (ep_current_tag == (EP_LAST_TAG + 1)) { --- 175,185 ---- return (1); } ! static struct ep_board * ep_look_for_board_at(is) struct isa_device *is; { ! int data, i, j, io_base, id_port = ELINK_ID_PORT; int nisa = 0, neisa = 0; if (ep_current_tag == (EP_LAST_TAG + 1)) { *************** *** 203,232 **** * Once activated, all the registers are mapped in the range * x000 - x00F, where x is the slot number. */ ep_board[neisa].epb_used = 0; ep_board[neisa++].epb_addr = j * EP_EISA_START; } ep_current_tag--; /* Look for the ISA boards. Init and leave them actived */ outb(id_port, 0xc0); /* Global reset */ DELAY(10000); for (i = 0; i < EP_MAX_BOARDS; i++) { outb(id_port, 0); outb(id_port, 0); send_ID_sequence(id_port); data = get_eeprom_data(id_port, EEPROM_MFG_ID); if (data != MFG_ID) break; /* resolve contention using the Ethernet address */ for (j = 0; j < 3; j++) ! data = get_eeprom_data(id_port, j); ep_board[neisa+nisa].epb_used = 0; ep_board[neisa+nisa++].epb_addr = ! (get_eeprom_data(id_port, EEPROM_ADDR_CFG) & 0x1f) * 0x10 + 0x200; outb(id_port, ep_current_tag); /* tags board */ outb(id_port, ACTIVATE_ADAPTER_TO_CONFIG); ep_current_tag--; --- 204,265 ---- * Once activated, all the registers are mapped in the range * x000 - x00F, where x is the slot number. */ + ep_board[neisa].epb_isa = 0; ep_board[neisa].epb_used = 0; ep_board[neisa++].epb_addr = j * EP_EISA_START; } ep_current_tag--; /* Look for the ISA boards. Init and leave them actived */ + outb(id_port, 0); + outb(id_port, 0); + + #if 0 + send_ID_sequence(id_port); + #else + elink_idseq(0xCF); + #endif + + #if 0 outb(id_port, 0xc0); /* Global reset */ + #else + elink_reset(); + #endif DELAY(10000); for (i = 0; i < EP_MAX_BOARDS; i++) { outb(id_port, 0); outb(id_port, 0); + #if 0 send_ID_sequence(id_port); + #else + elink_idseq(0xCF); + #endif data = get_eeprom_data(id_port, EEPROM_MFG_ID); if (data != MFG_ID) break; /* resolve contention using the Ethernet address */ + + for (j = 0; j < 3; j++) + get_eeprom_data(id_port, j); + + /* and save this address for later use */ + for (j = 0; j < 3; j++) ! ep_board[neisa+nisa].eth_addr[j] = get_eeprom_data(id_port, j); + ep_board[neisa+nisa].res_cfg = + get_eeprom_data(id_port, EEPROM_RESOURCE_CFG); + + ep_board[neisa+nisa].prod_id = + get_eeprom_data(id_port, EEPROM_PROD_ID); + + ep_board[neisa].epb_isa = 1; ep_board[neisa+nisa].epb_used = 0; ep_board[neisa+nisa++].epb_addr = ! (get_eeprom_data(id_port, EEPROM_ADDR_CFG) & 0x1f) * 0x10 + 0x200; ! outb(id_port, ep_current_tag); /* tags board */ outb(id_port, ACTIVATE_ADAPTER_TO_CONFIG); ep_current_tag--; *************** *** 266,283 **** IS_BASE=ep_board[i].epb_addr; ep_board[i].epb_used=1; ! return 1; } else { for (i=0; ep_board[i].epb_addr && ep_board[i].epb_addr != IS_BASE; i++); ! if( ep_board[i].epb_used || ep_board[i].epb_addr != IS_BASE) return 0; if (inw(IS_BASE + EP_W0_EEPROM_COMMAND) & EEPROM_TST_MODE) printf("ep%d: 3c5x9 at 0x%x in test mode. Erase pencil mark!\n", is->id_unit, IS_BASE); ep_board[i].epb_used=1; ! return 1; } } --- 299,318 ---- IS_BASE=ep_board[i].epb_addr; ep_board[i].epb_used=1; ! ! return &ep_board[i]; } else { for (i=0; ep_board[i].epb_addr && ep_board[i].epb_addr != IS_BASE; i++); ! if( ep_board[i].epb_used || ep_board[i].epb_addr != IS_BASE) return 0; if (inw(IS_BASE + EP_W0_EEPROM_COMMAND) & EEPROM_TST_MODE) printf("ep%d: 3c5x9 at 0x%x in test mode. Erase pencil mark!\n", is->id_unit, IS_BASE); ep_board[i].epb_used=1; ! ! return &ep_board[i]; } } *************** *** 308,327 **** ep_registerdev(is); ! if (!ep_look_for_board_at(is)) return (0); /* * The iobase was found and MFG_ID was 0x6d50. PROD_ID should be * 0x9[0-f]50 */ GO_WINDOW(0); ! k = get_e(is, EEPROM_PROD_ID); if ((k & 0xf0ff) != (PROD_ID & 0xf0ff)) { printf("epprobe: ignoring model %04x\n", k); return (0); } ! k = get_e(is, EEPROM_RESOURCE_CFG); k >>= 12; /* Now we have two cases again: --- 343,363 ---- ep_registerdev(is); ! if(( sc->epb=ep_look_for_board_at(is) )==0) return (0); /* * The iobase was found and MFG_ID was 0x6d50. PROD_ID should be * 0x9[0-f]50 */ GO_WINDOW(0); ! k = sc->epb->epb_isa ? sc->epb->prod_id : get_e(is, EEPROM_PROD_ID); if ((k & 0xf0ff) != (PROD_ID & 0xf0ff)) { printf("epprobe: ignoring model %04x\n", k); return (0); } ! k = sc->epb->epb_isa ? sc->epb->res_cfg : get_e(is, EEPROM_RESOURCE_CFG); ! k >>= 12; /* Now we have two cases again: *************** *** 396,402 **** p = (u_short *) & sc->arpcom.ac_enaddr; for (i = 0; i < 3; i++) { GO_WINDOW(0); ! p[i] = htons(get_e(is, i)); GO_WINDOW(2); outw(BASE + EP_W2_ADDR_0 + (i * 2), ntohs(p[i])); } --- 432,438 ---- p = (u_short *) & sc->arpcom.ac_enaddr; for (i = 0; i < 3; i++) { GO_WINDOW(0); ! p[i] = htons( sc->epb->epb_isa ? sc->epb->eth_addr[i] : get_e(is, i) ); GO_WINDOW(2); outw(BASE + EP_W2_ADDR_0 + (i * 2), ntohs(p[i])); } *************** *** 423,429 **** ifp->if_unit = is->id_unit; ifp->if_name = "ep"; ifp->if_mtu = ETHERMTU; ! ifp->if_flags = IFF_BROADCAST | IFF_SIMPLEX; ifp->if_init = epinit; ifp->if_output = ether_output; ifp->if_start = epstart; --- 459,466 ---- ifp->if_unit = is->id_unit; ifp->if_name = "ep"; ifp->if_mtu = ETHERMTU; ! ifp->if_flags = IFF_BROADCAST | IFF_MULTICAST | ! IFF_SIMPLEX | IFF_NOTRAILERS; ifp->if_init = epinit; ifp->if_output = ether_output; ifp->if_start = epstart; *************** *** 432,438 **** ifp->if_timer=1; if_attach(ifp); ! kdc_ep[is->id_unit].kdc_state = DC_BUSY; /* * Fill the hardware address into ifa_addr if we find an AF_LINK entry. --- 469,477 ---- ifp->if_timer=1; if_attach(ifp); ! ! /* device attach does transition from UNCONFIGURED to IDLE state */ ! kdc_ep[is->id_unit].kdc_state=DC_IDLE; /* * Fill the hardware address into ifa_addr if we find an AF_LINK entry. *************** *** 475,481 **** #endif ep_fset(F_RX_FIRST); sc->top = sc->mcur = 0; ! #if NBPFILTER > 0 bpfattach(&sc->bpf, ifp, DLT_EN10MB, sizeof(struct ether_header)); #endif --- 514,520 ---- #endif ep_fset(F_RX_FIRST); sc->top = sc->mcur = 0; ! #if NBPFILTER > 0 bpfattach(&sc->bpf, ifp, DLT_EN10MB, sizeof(struct ether_header)); #endif *************** *** 536,547 **** outw(BASE + EP_COMMAND, SET_INTR_MASK | S_5_INTS); ! if(ifp->if_flags & IFF_PROMISC) ! outw(BASE + EP_COMMAND, SET_RX_FILTER | FIL_INDIVIDUAL | ! FIL_GROUP | FIL_BRDCST | FIL_ALL); ! else ! outw(BASE + EP_COMMAND, SET_RX_FILTER | FIL_INDIVIDUAL | ! FIL_GROUP | FIL_BRDCST); /* * S.B. --- 575,586 ---- outw(BASE + EP_COMMAND, SET_INTR_MASK | S_5_INTS); ! if(ifp->if_flags & IFF_PROMISC) ! outw(BASE + EP_COMMAND, SET_RX_FILTER | FIL_INDIVIDUAL | ! FIL_GROUP | FIL_BRDCST | FIL_ALL); ! else ! outw(BASE + EP_COMMAND, SET_RX_FILTER | FIL_INDIVIDUAL | ! FIL_GROUP | FIL_BRDCST); /* * S.B. *************** *** 814,820 **** sc->rx_no_first, sc->rx_no_mbuf, sc->rx_bpf_disc, sc->rx_overrunf, sc->rx_overrunl, sc->tx_underrun); #else ! printf("ep%d: Status: %x\n", unit, status); #endif epinit(unit); splx(x); --- 853,865 ---- sc->rx_no_first, sc->rx_no_mbuf, sc->rx_bpf_disc, sc->rx_overrunf, sc->rx_overrunl, sc->tx_underrun); #else ! ! #ifdef nightmaremessages ! printf("ep%d: Status: %x (input buffer overflow)\n", unit, status); ! #else ! ++sc->arpcom.ac_if.if_ierrors; ! #endif ! #endif epinit(unit); splx(x); *************** *** 1129,1139 **** struct ifreq *ifr = (struct ifreq *) data; int s, error = 0; ! s = splimp(); switch (cmd) { case SIOCSIFADDR: ifp->if_flags |= IFF_UP; switch (ifa->ifa_addr->sa_family) { #ifdef INET case AF_INET: --- 1174,1188 ---- struct ifreq *ifr = (struct ifreq *) data; int s, error = 0; ! s=splimp(); switch (cmd) { case SIOCSIFADDR: ifp->if_flags |= IFF_UP; + + /* netifs are BUSY when UP */ + kdc_ep[ifp->if_unit].kdc_state=DC_BUSY; + switch (ifa->ifa_addr->sa_family) { #ifdef INET case AF_INET: *************** *** 1159,1179 **** break; } #endif default: epinit(ifp->if_unit); break; } break; case SIOCGIFADDR: ! { ! struct sockaddr *sa; ! ! sa = (struct sockaddr *) & ifr->ifr_data; ! bcopy((caddr_t) sc->arpcom.ac_enaddr, (caddr_t) sa->sa_data, ETHER_ADDR_LEN); } break; case SIOCSIFFLAGS: if ((ifp->if_flags & IFF_UP) == 0 && ifp->if_flags & IFF_RUNNING) { ifp->if_flags &= ~IFF_RUNNING; epstop(ifp->if_unit); --- 1208,1251 ---- break; } #endif + #ifdef IPX + case AF_IPX: + { + register struct ipx_addr *ina = &(IA_SIPX(ifa)->sipx_addr); + + if (ipx_nullhost(*ina)) + ina->x_host = + *(union ipx_host *) (sc->arpcom.ac_enaddr); + else { + ifp->if_flags &= ~IFF_RUNNING; + bcopy((caddr_t) ina->x_host.c_host, + (caddr_t) sc->arpcom.ac_enaddr, + sizeof(sc->arpcom.ac_enaddr)); + } + epinit(ifp->if_unit); + break; + } + #endif default: epinit(ifp->if_unit); break; } break; case SIOCGIFADDR: ! { ! struct sockaddr *sa; ! ! sa = (struct sockaddr *) & ifr->ifr_data; ! bcopy((caddr_t) sc->arpcom.ac_enaddr, (caddr_t) sa->sa_data, ETHER_ADDR_LEN); } break; case SIOCSIFFLAGS: + /* UP controls BUSY/IDLE */ + kdc_ep[ifp->if_unit].kdc_state= ( (ifp->if_flags & IFF_UP) + ? DC_BUSY + : DC_IDLE ); + if ((ifp->if_flags & IFF_UP) == 0 && ifp->if_flags & IFF_RUNNING) { ifp->if_flags &= ~IFF_RUNNING; epstop(ifp->if_unit); *************** *** 1186,1191 **** --- 1258,1264 ---- } /* NOTREACHED */ + #if 0 if (ifp->if_flags & IFF_UP && (ifp->if_flags & IFF_RUNNING) == 0) epinit(ifp->if_unit); *************** *** 1198,1203 **** --- 1271,1277 ---- ep_frst(F_PROMISC); epinit(ifp->if_unit); } + #endif break; #ifdef notdef *************** *** 1216,1223 **** } else { ifp->if_mtu = ifr->ifr_mtu; } ! break; ! default: error = EINVAL; } --- 1290,1304 ---- } else { ifp->if_mtu = ifr->ifr_mtu; } ! break; ! case SIOCADDMULTI: ! case SIOCDELMULTI: ! /* Now this driver has no support for programmable ! * multicast filters. If some day it will gain this ! * support this part of code must be extended. ! */ ! error=0; ! break; default: error = EINVAL; } ------------------------- cut here -------------------------------------- From owner-freebsd-current Wed Oct 18 06:51:30 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id GAA01938 for current-outgoing; Wed, 18 Oct 1995 06:51:30 -0700 Received: from halloran-eldar.lcs.mit.edu (halloran-eldar.lcs.mit.edu [18.26.0.159]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id GAA01933 for ; Wed, 18 Oct 1995 06:51:28 -0700 Received: by halloran-eldar.lcs.mit.edu; (5.65/1.1.8.2/19Aug95-0530PM) id AA05154; Wed, 18 Oct 1995 09:50:36 -0400 Date: Wed, 18 Oct 1995 09:50:36 -0400 From: "Garrett A. Wollman" Message-Id: <9510181350.AA05154@halloran-eldar.lcs.mit.edu> To: "Serge A. Babkin" Cc: current@freebsd.org Subject: Re: 3c509 in -current needs patching In-Reply-To: <199510181012.PAA15264@hq.icb.chel.su> References: <199510181012.PAA15264@hq.icb.chel.su> Sender: owner-current@freebsd.org Precedence: bulk < said: > This patch is combined from the previos one (that contained a bug, the word > SIOCGIFADDR was written as SIOCSGIFADDR) and the IPX support. The $Id$ > string says that the last patch applied was made by Garrett Wollman, so > may be he can review and commit this patch, huh ? Thank you! I have not done so, and will continue to not do so, because I don't have one of these adapters to test it with. If three people send me /private/ E-mail indicating that they have tested the patched driver and it works to their satisfaction, then I will commit it, assuming nobody who has one to test does so and disposes of it sooner. -GAWollman -- Garrett A. Wollman | Shashish is simple, it's discreet, it's brief. ... wollman@lcs.mit.edu | Shashish is the bonding of hearts in spite of distance. Opinions not those of| It is a bond more powerful than absence. We like people MIT, LCS, ANA, or NSA| who like Shashish. - Claude McKenzie + Florent Vollant From owner-freebsd-current Wed Oct 18 06:57:05 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id GAA02061 for current-outgoing; Wed, 18 Oct 1995 06:57:05 -0700 Received: from halloran-eldar.lcs.mit.edu (halloran-eldar.lcs.mit.edu [18.26.0.159]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id GAA02056 ; Wed, 18 Oct 1995 06:57:03 -0700 Received: by halloran-eldar.lcs.mit.edu; (5.65/1.1.8.2/19Aug95-0530PM) id AA05148; Wed, 18 Oct 1995 09:56:40 -0400 Date: Wed, 18 Oct 1995 09:56:40 -0400 From: "Garrett A. Wollman" Message-Id: <9510181356.AA05148@halloran-eldar.lcs.mit.edu> To: "Serge A. Babkin" Cc: gena@NetVision.net.il, wollman@freebsd.org, jkh@time.cdrom.com, current@freebsd.org Subject: Re: 3c509 in -current needs patching In-Reply-To: <199510181012.PAA15264@hq.icb.chel.su> References: <199510181012.PAA15264@hq.icb.chel.su> Sender: owner-current@freebsd.org Precedence: bulk < said: I found a bug by visual inspection... > ! ifp->if_flags = IFF_BROADCAST | IFF_MULTICAST | > ! IFF_SIMPLEX | IFF_NOTRAILERS; > ! case SIOCADDMULTI: > ! case SIOCDELMULTI: > ! /* Now this driver has no support for programmable > ! * multicast filters. If some day it will gain this > ! * support this part of code must be extended. > ! */ > ! error=0; > ! break; If multicast is not supported, the driver should not claim to support it. -GAWollman -- Garrett A. Wollman | Shashish is simple, it's discreet, it's brief. ... wollman@lcs.mit.edu | Shashish is the bonding of hearts in spite of distance. Opinions not those of| It is a bond more powerful than absence. We like people MIT, LCS, ANA, or NSA| who like Shashish. - Claude McKenzie + Florent Vollant From owner-freebsd-current Wed Oct 18 08:57:16 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id IAA09988 for current-outgoing; Wed, 18 Oct 1995 08:57:16 -0700 Received: from haven.uniserve.com (haven.uniserve.com [198.53.215.121]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id IAA09983 for ; Wed, 18 Oct 1995 08:57:14 -0700 Received: by haven.uniserve.com id <30729>; Wed, 18 Oct 1995 08:59:22 +0100 From: Tom Samplonius To: freebsd-current@freebsd.org Subject: NMBCLUSTERS on -stable Message-Id: <95Oct18.085922+0100_pdt.30729+1294@haven.uniserve.com> Date: Wed, 18 Oct 1995 08:59:08 +0100 Sender: owner-current@freebsd.org Precedence: bulk I understand -stable now allocates mbuf clusters based on maxusers. However, I've been trying to build a kernel with more mbuf's than GENERIC, however, no matter what I do, I can't get any more. While idle, the system reports over 80% in use. Tom From owner-freebsd-current Wed Oct 18 08:58:13 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id IAA10050 for current-outgoing; Wed, 18 Oct 1995 08:58:13 -0700 Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id IAA10044 for ; Wed, 18 Oct 1995 08:58:06 -0700 Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id BAA03462; Thu, 19 Oct 1995 01:53:18 +1000 Date: Thu, 19 Oct 1995 01:53:18 +1000 From: Bruce Evans Message-Id: <199510181553.BAA03462@godzilla.zeta.org.au> To: phk@critter.tfs.com, sysseh@devetir.qld.gov.au Subject: Re: Errors building some LKMs in -current Cc: current@freebsd.org Sender: owner-current@freebsd.org Precedence: bulk >> I get (in ibcs2 & linux, to mention a couple) errors when doing the final >> stage in the creation of the module >> symorder: 1 symbol not found: >> _ibcs2_mod >> >> I've tried clean and doing make depends beforehand, but it persists. Any clue >Yes, somebody (TM) need to figure out exactly what symbols those LKMs >should export. >Ideally the "-e FOO" symbol should be ibcs2_mod for instance... They just have inconsistently named entry points. Most use the name `foo_init', which seems better than foo_mod, but atapi and wcd use simply `atapi' and `wcd'. Bruce From owner-freebsd-current Wed Oct 18 09:41:41 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id JAA11775 for current-outgoing; Wed, 18 Oct 1995 09:41:41 -0700 Received: from halloran-eldar.lcs.mit.edu (halloran-eldar.lcs.mit.edu [18.26.0.159]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id JAA11766 for ; Wed, 18 Oct 1995 09:41:38 -0700 Received: by halloran-eldar.lcs.mit.edu; (5.65/1.1.8.2/19Aug95-0530PM) id AA05486; Wed, 18 Oct 1995 12:41:18 -0400 Date: Wed, 18 Oct 1995 12:41:18 -0400 From: "Garrett A. Wollman" Message-Id: <9510181641.AA05486@halloran-eldar.lcs.mit.edu> To: Bruce Evans Cc: current@freebsd.org Subject: Re: Errors building some LKMs in -current In-Reply-To: <199510181553.BAA03462@godzilla.zeta.org.au> References: <199510181553.BAA03462@godzilla.zeta.org.au> Sender: owner-current@freebsd.org Precedence: bulk < said: > They just have inconsistently named entry points. Most use the name > `foo_init', which seems better than foo_mod, but atapi and wcd use > simply `atapi' and `wcd'. I chose `foo_mod' because it was unlikely to conflict with anything that already existed in the code. `foo_init' is simply the wrong name, because these are /not/ ``initialization'' functions; they are initialization-status-teardown functions. -GAWollman -- Garrett A. Wollman | Shashish is simple, it's discreet, it's brief. ... wollman@lcs.mit.edu | Shashish is the bonding of hearts in spite of distance. Opinions not those of| It is a bond more powerful than absence. We like people MIT, LCS, ANA, or NSA| who like Shashish. - Claude McKenzie + Florent Vollant From owner-freebsd-current Wed Oct 18 10:08:09 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id KAA12477 for current-outgoing; Wed, 18 Oct 1995 10:08:09 -0700 Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id KAA12463 for ; Wed, 18 Oct 1995 10:08:04 -0700 Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id DAA05231; Thu, 19 Oct 1995 03:03:59 +1000 Date: Thu, 19 Oct 1995 03:03:59 +1000 From: Bruce Evans Message-Id: <199510181703.DAA05231@godzilla.zeta.org.au> To: bde@zeta.org.au, wollman@lcs.mit.edu Subject: Re: Errors building some LKMs in -current Cc: current@freebsd.org Sender: owner-current@freebsd.org Precedence: bulk >I chose `foo_mod' because it was unlikely to conflict with anything >that already existed in the code. `foo_init' is simply the wrong >name, because these are /not/ ``initialization'' functions; they are >initialization-status-teardown functions. How about `foo_dispatch'. The examples in /usr/src/lkm/*.c are all named `foo_init' but they just invoke the DISPATCH() macro. Bruce From owner-freebsd-current Wed Oct 18 10:54:19 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id KAA13238 for current-outgoing; Wed, 18 Oct 1995 10:54:19 -0700 Received: from meter.eng.uci.edu (root@meter.eng.uci.edu [128.200.85.3]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id KAA13233 for ; Wed, 18 Oct 1995 10:54:16 -0700 Received: from newport.ece.uci.edu by meter.eng.uci.edu (8.7) id KAA04325; Wed, 18 Oct 1995 10:54:08 -0700 (PDT) Received: from localhost by newport.ece.uci.edu (8.7) id KAA19488; Wed, 18 Oct 1995 10:54:07 -0700 (PDT) Message-Id: <199510181754.KAA19488@newport.ece.uci.edu> To: se@zpr.uni-koeln.de (Stefan Esser) cc: current@freebsd.org Subject: Re: PCI probe code In-reply-to: Your message of "Mon, 16 Oct 1995 23:59:18 BST." <199510162259.AA17189@Sysiphos> Date: Wed, 18 Oct 1995 10:54:05 -0700 From: Steven Wallace Sender: owner-current@freebsd.org Precedence: bulk pcibus_setup(1): mode1 addr port (0xcf8) is 0x80000050 pcibus_setup(2): mode 2 enable port (0xcf8) is 0xff ASUS PCI/I-P54TP4 Intel Triton From owner-freebsd-current Wed Oct 18 12:07:11 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id MAA17276 for current-outgoing; Wed, 18 Oct 1995 12:07:11 -0700 Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id MAA17270 for ; Wed, 18 Oct 1995 12:07:04 -0700 Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id MAA00623; Wed, 18 Oct 1995 12:01:05 -0700 From: Terry Lambert Message-Id: <199510181901.MAA00623@phaeton.artisoft.com> Subject: Re: Errors building some LKMs in -current To: phk@critter.tfs.com (Poul-Henning Kamp) Date: Wed, 18 Oct 1995 12:01:05 -0700 (MST) Cc: sysseh@devetir.qld.gov.au, current@freebsd.org In-Reply-To: <276.814009119@critter.tfs.com> from "Poul-Henning Kamp" at Oct 18, 95 10:38:39 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 285 Sender: owner-current@freebsd.org Precedence: bulk > Yes, somebody (TM) need to figure out exactly what symbols those LKMs > should export. Thank God! The first time through I read this as (TL)! Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-current Wed Oct 18 12:50:19 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id MAA18860 for current-outgoing; Wed, 18 Oct 1995 12:50:19 -0700 Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id MAA18842 ; Wed, 18 Oct 1995 12:50:10 -0700 Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id MAA00690; Wed, 18 Oct 1995 12:39:49 -0700 From: Terry Lambert Message-Id: <199510181939.MAA00690@phaeton.artisoft.com> Subject: Re: getdtablesize() broken? To: bde@zeta.org.au (Bruce Evans) Date: Wed, 18 Oct 1995 12:39:49 -0700 (MST) Cc: bakul@netcom.com, terry@lambert.org, bde@zeta.org.au, current@freefall.freebsd.org, hackers@freefall.freebsd.org In-Reply-To: <199510180704.RAA16305@godzilla.zeta.org.au> from "Bruce Evans" at Oct 18, 95 05:04:23 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 6382 Sender: owner-current@FreeBSD.org Precedence: bulk > >Basically, all of the user space code that uses the standard-since-4.2 > >sys/types.h definitions would need to be rewritten. This is what I > >meant. > > The select() interface has pointers to fd_set's, so it doesn't rule out > using arrays of fd_set's. I think only the FD_ macros and the > documentation would need to be rewritten. OK, I might buy this, though it seems a non-standard way of dealing with the issue. I think the current bit macros would require modification to take address operands, or cast them to long arracys and linearly traverse them in any case. Still, a passed "maxfd" in excess of the array max could have the kernel twiddling the the contents of non-select bit data areas. I think there is no way short of an interface change to cause the user to not have to supply a maxfd <= the actual array length limits, even if you make the kernel not care by breaking the FD_SETSIZE "agreement" between the kernel and the user programs. > >How do I make a program which doesn't guard using FD_SETSIZE the max fd > >it tries to select upon suddenly have a larger statically or stack > >declared bitvector array? > > Don't use the standard FD_ macros. Can't do it without mandating code modifications. If we start down this road, I demand we get rid of tty interfaces other than POSIX termios and just mandate that everyone change their code. Welcome to Plan 9. > Anyway, the kernel needs to handle an arbitrary FD_SETSIZE for > compatibility. There is no reason why the Linux FD_SETSIZE should be as > limited as the FD_SETSIZE that the kernel happened to be compiled with. > Fixed limits defeat binary compatibility. This is particularly annoying > for fixed limits like OPEN_MAX that aren't actually fixed even on the > host OS. See for a long list of bogus limits. ??? Let's see: ] #define ARG_MAX 65536 /* max bytes for an exec function */ Type: Bogus. Required by: The process environment being in the user's address space instead of attached to the proc structure and accessed through system calls. Reason: Support of legacy code that directly manipulates the enviroment in violation of the documented interface, preventing those interfaces from moving from section 3 (library) to section 2 (system calls). ] #define CHILD_MAX 40 /* max simultaneous processes */ Type: Administrative (compile time override) Required by: The ability for a user program to fork(2) the system to death. Reason: There exist intentionally and unintentionally disruptive users. ] #define LINK_MAX 32767 /* max file link count */ Type: Pragmatic Required by: There are limitations on the largest number that can be stored in the "link count" field of an on disk inode. Reason: You can't overcome all design limitations and still have reasonable usability. This is one such limit, which is orders of magnitude larger than the highest "reasonable" value. ] #define MAX_CANON 255 /* max bytes in term canon input line */ Type: Bogus Required by: Seperate cannonization buffer. Reason: No one has double-staged tty input for cannonization to cause it to use a queue based buffering mechanism. ] #define MAX_INPUT 255 /* max bytes in terminal input */ Type: Bogus Required by: Seperate cannonization buffer. Reason: No one has double-staged tty input to cause it to use a queue based buffering mechanism. ] #define NAME_MAX 255 /* max bytes in a file name */ Type: Standard Required by: POSIX compliance Reason: The file component name length limit is mandated to be set to 255 characters. ] #define NGROUPS_MAX 16 /* max supplemental group id's */ Type: Standard (Interoperability, Legacy) Required by: NFS, YP Reason: Excess groups are truncated by the NFS external ID representation mechanism. In point of fact, this limit should be 8 to ensure interoperability with older SVR3/SVR4 systems. ] #define OPEN_MAX 64 /* max open files per process */ Type: Bogus Required by: Bash, tcsh Reason: Stupid programmers of shells attempt to split the open file descriptor numeric name space into two components, and to use the upper component to ensure that a collision with the fd for the currently executing script is not stepped on by the script itself. The correct procedure for systems with memory limited open file limits (AIX, BSD, etc.) is to write the programs to use collision detection and move the script fd, using indirect instead of direct reference to the script fd to allow this. The limit also works around a bug in BSD, which is that the open file limit should be bound by a free memory threshold (as should all allocations initiated as a result of a user request) instead of causing a system panic. ] #define PATH_MAX 1024 /* max bytes in pathname */ Type: Standard Required by: POSIX compliance Reason: The path length limit is mandated to be set to 1024 characters. There is in fact a bug in non-terminal symbolic link expansion in vfs_lookup.c that reduces this limit below the mandated 1024 by using coroutine based mutual recursion to avoid increasing stack depth. This is a programatic error, and is thus only tangentially related to this limit. ] #define PIPE_BUF 512 /* max bytes for atomic pipe writes */ Type: Bogus Required by: Implementation Reason: Buffer atomicity is related to the underlying POSIX domain socket based implementation of pipes. This is in fact a limit which must be traded against pipe depth, and is a conceptual limitation on the idea of pipes. ] #define BC_BASE_MAX 99 /* max ibase/obase values in bc(1) */ ] #define BC_DIM_MAX 2048 /* max array elements in bc(1) */ ] #define BC_SCALE_MAX 99 /* max scale value in bc(1) */ ] #define BC_STRING_MAX 1000 /* max const string length in bc(1) */ ] #define COLL_WEIGHTS_MAX 0 /* max weights for order keyword */ ] #define EXPR_NEST_MAX 32 /* max expressions nested in expr(1) */ ] #define LINE_MAX 2048 /* max bytes in an input line */ ] #define RE_DUP_MAX 255 /* max RE's in interval notation */ Type: Bogus Required by: A user space program Reason: The programmer didn't know he could use "" to delimit include files instead of <>? Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-current Wed Oct 18 13:24:52 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id NAA20279 for current-outgoing; Wed, 18 Oct 1995 13:24:52 -0700 Received: from plains.nodak.edu (89@plains.NoDak.edu [134.129.111.64]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id NAA20269 ; Wed, 18 Oct 1995 13:24:41 -0700 Received: (from tinguely@localhost) by plains.nodak.edu (8.6.11/8.6.10) id PAA11848; Wed, 18 Oct 1995 15:24:01 -0500 Date: Wed, 18 Oct 1995 15:24:01 -0500 From: Mark Tinguely Message-Id: <199510182024.PAA11848@plains.nodak.edu> To: babkin@hq.icb.chel.su, wollman@lcs.mit.edu Subject: Re: 3c509 in -current needs patching Cc: current@freebsd.org, gena@NetVision.net.il, jkh@time.cdrom.com, wollman@freebsd.org Content-Length: 601 Sender: owner-current@freebsd.org Precedence: bulk > If multicast is not supported, the driver should not claim to support > it. I am assuming the talk is about the sys/i386/isa/if_ep.c, it is obvious the patch for the "IPX" and what was said to include the multicast patches is wrong as mentioned above. Since these are not "my" machines, I can install/test the other parts of the "IPX" patch, but I can make a testimonal for the -hacker posted July 10, 1995 if_ep.c "multicast" patches. I placed them on two machines at Moorhead State University about two weeks ago, one is a MBONE router and the other is an multi-cast enduser machine. --mark. From owner-freebsd-current Wed Oct 18 13:52:29 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id NAA21489 for current-outgoing; Wed, 18 Oct 1995 13:52:29 -0700 Received: from chrome.jdl.com (chrome.onramp.net [199.1.166.202]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id NAA21468 ; Wed, 18 Oct 1995 13:52:22 -0700 Received: from localhost.jdl.com (localhost.jdl.com [127.0.0.1]) by chrome.jdl.com (8.6.11/8.6.9) with SMTP id PAA11470; Wed, 18 Oct 1995 15:51:02 -0500 Message-Id: <199510182051.PAA11470@chrome.jdl.com> X-Authentication-Warning: chrome.jdl.com: Host localhost.jdl.com didn't use HELO protocol To: Terry Lambert cc: bde@zeta.org.au (Bruce Evans), bakul@netcom.com, current@freefall.freebsd.org, hackers@freefall.freebsd.org Subject: Re: getdtablesize() broken? In-reply-to: Your message of "Wed, 18 Oct 1995 12:39:49 PDT." <199510181939.MAA00690@phaeton.artisoft.com> Reply-To: jdl@chromatic.com Clarity-Index: null Threat-Level: none Software-Engineering-Dead-Seriousness: There's no excuse for unreadable code. Net-thought: If you meet the Buddha on the net, put him in your Kill file. Date: Wed, 18 Oct 1995 15:51:02 -0500 From: Jon Loeliger Sender: owner-current@FreeBSD.org Precedence: bulk Apparently, Terry Lambert scribbled: > > The select() interface has pointers to fd_set's, so it doesn't rule out > > using arrays of fd_set's. I think only the FD_ macros and the > > documentation would need to be rewritten. > > OK, I might buy this, though it seems a non-standard way of dealing with > the issue. I think the current bit macros would require modification to > take address operands, or cast them to long arracys and linearly traverse > them in any case. > > Still, a passed "maxfd" in excess of the array max could have the kernel > twiddling the the contents of non-select bit data areas. > > I think there is no way short of an interface change to cause the user > to not have to supply a maxfd <= the actual array length limits, even > if you make the kernel not care by breaking the FD_SETSIZE "agreement" > between the kernel and the user programs. Yea, and one further silly data point, that may or may not be even vaguely interesting: In AIX land, there were message queues too and they needed the ability to be select()-able as well. You couldn't reliably have a second interface that only looked at msgques, as you could only have one point of "hang" and it had to check for all the possible select() conditions. This led to the fd sets really having a message queue portion just after the set of FD bits. Naturally, in order to find where the first msg que bits were, the length of the fd sets had to be known. When msg queues were needed in the application, this had the further interesting silly effect of not really being able to tell the select() the honest number of "bits that are interesting" while doing the select(). One had to lie and claim the maximum, even though the user could be tracking the largest open fd and know full well that it was much less than the maximum FD. Icky and slow. jdl From owner-freebsd-current Wed Oct 18 14:02:51 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id OAA21963 for current-outgoing; Wed, 18 Oct 1995 14:02:51 -0700 Received: from halloran-eldar.lcs.mit.edu (halloran-eldar.lcs.mit.edu [18.26.0.159]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id OAA21956 ; Wed, 18 Oct 1995 14:02:48 -0700 Received: by halloran-eldar.lcs.mit.edu; (5.65/1.1.8.2/19Aug95-0530PM) id AA05903; Wed, 18 Oct 1995 17:02:03 -0400 Date: Wed, 18 Oct 1995 17:02:03 -0400 From: "Garrett A. Wollman" Message-Id: <9510182102.AA05903@halloran-eldar.lcs.mit.edu> To: Terry Lambert Cc: bde@zeta.org.au (Bruce Evans), bakul@netcom.com, current@freefall.freebsd.org, hackers@freefall.freebsd.org Subject: Re: getdtablesize() broken? In-Reply-To: <199510181939.MAA00690@phaeton.artisoft.com> References: <199510180704.RAA16305@godzilla.zeta.org.au> <199510181939.MAA00690@phaeton.artisoft.com> Sender: owner-current@FreeBSD.org Precedence: bulk < said: > ] #define ARG_MAX 65536 /* max bytes for an exec function */ > Type: Bogus. Type: POSIX. > Required by: The process environment being in the user's address > space instead of attached to the proc structure and > accessed through system calls. BZZZZT! Wrong, but thanks for playing. You can ask David or John about the memory-fragmentation issues which mandate the use of a separate VM submap to hold this data while it is being staged between the old process and the new process. > ] #define CHILD_MAX 40 /* max simultaneous processes */ > Type: Administrative (compile time override) Type: Bogus but POSIX. > Required by: The ability for a user program to fork(2) the system to > death. BZZZZT! This value should be modifiable at run time. (It isn't yet.) > ] #define LINK_MAX 32767 /* max file link count */ > Type: Pragmatic Type: POSIX. > ] #define MAX_CANON 255 /* max bytes in term canon input line */ > Type: Bogus Type: POSIX. > ] #define NGROUPS_MAX 16 /* max supplemental group id's */ > Type: Standard (Interoperability, Legacy) > Required by: NFS, YP > Reason: Excess groups are truncated by the NFS external ID > representation mechanism. In point of fact, this > limit should be 8 to ensure interoperability with > older SVR3/SVR4 systems. No, the NFS and RPC code have their own kluges to deal with broken systems. > ] #define OPEN_MAX 64 /* max open files per process */ > Type: Bogus Type: POSIX. > ] #define PIPE_BUF 512 /* max bytes for atomic pipe writes */ > Type: Bogus Type: POSIX. > ] #define BC_BASE_MAX 99 /* max ibase/obase values in bc(1) */ > ] #define BC_DIM_MAX 2048 /* max array elements in bc(1) */ > ] #define BC_SCALE_MAX 99 /* max scale value in bc(1) */ > ] #define BC_STRING_MAX 1000 /* max const string length in bc(1) */ > ] #define COLL_WEIGHTS_MAX 0 /* max weights for order keyword */ > ] #define EXPR_NEST_MAX 32 /* max expressions nested in expr(1) */ > ] #define LINE_MAX 2048 /* max bytes in an input line */ > ] #define RE_DUP_MAX 255 /* max RE's in interval notation */ > Type: Bogus Type: POSIX. > Required by: A user space program Required by: IEEE-CS technical committee P1003.1. Any user-space program that executes `bc' to do arithmetic, or uses the LC_COLLATE localization support, or executes `expr' to do arithmetic. -GAWollman -- Garrett A. Wollman | Shashish is simple, it's discreet, it's brief. ... wollman@lcs.mit.edu | Shashish is the bonding of hearts in spite of distance. Opinions not those of| It is a bond more powerful than absence. We like people MIT, LCS, ANA, or NSA| who like Shashish. - Claude McKenzie + Florent Vollant From owner-freebsd-current Wed Oct 18 14:52:31 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id OAA24217 for current-outgoing; Wed, 18 Oct 1995 14:52:31 -0700 Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id OAA24198 ; Wed, 18 Oct 1995 14:52:16 -0700 Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id OAA01079; Wed, 18 Oct 1995 14:45:44 -0700 From: Terry Lambert Message-Id: <199510182145.OAA01079@phaeton.artisoft.com> Subject: Re: getdtablesize() broken? To: wollman@lcs.mit.edu (Garrett A. Wollman) Date: Wed, 18 Oct 1995 14:45:44 -0700 (MST) Cc: terry@lambert.org, bde@zeta.org.au, bakul@netcom.com, current@freefall.freebsd.org, hackers@freefall.freebsd.org In-Reply-To: <9510182102.AA05903@halloran-eldar.lcs.mit.edu> from "Garrett A. Wollman" at Oct 18, 95 05:02:03 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2693 Sender: owner-current@FreeBSD.org Precedence: bulk > > ] #define ARG_MAX 65536 /* max bytes for an exec function */ > > > Type: Bogus. > > Type: POSIX. > > > Required by: The process environment being in the user's address > > space instead of attached to the proc structure and > > accessed through system calls. > > BZZZZT! Wrong, but thanks for playing. You can ask David or John > about the memory-fragmentation issues which mandate the use of a > separate VM submap to hold this data while it is being staged between > the old process and the new process. BZZZZT! Replace the enviornment with logical names and hang the logical name table off the proc struct instead of copying it like this and it won't *need* to be staged. Bye bye, staging area. Mark the environment as a shared copy-on-modification structure. > > ] #define CHILD_MAX 40 /* max simultaneous processes */ > > > Type: Administrative (compile time override) > > Type: Bogus but POSIX. > > > Required by: The ability for a user program to fork(2) the system to > > death. > > BZZZZT! This value should be modifiable at run time. (It isn't yet.) Posix? You mean by way of the limits code retrieving it? I never said that it shouldn't be modifiable at runtime, but "unlimited" is a valid value in POSIX. > > ] #define LINK_MAX 32767 /* max file link count */ > > Type: Pragmatic > Type: POSIX. Uh... where? Limits retrieval? > > ] #define MAX_CANON 255 /* max bytes in term canon input line */ > > Type: Bogus > Type: POSIX. Uh... where? POSIX doesn't mandate implementation. > > ] #define NGROUPS_MAX 16 /* max supplemental group id's */ > > Type: Standard (Interoperability, Legacy) > > Required by: NFS, YP > > Reason: Excess groups are truncated by the NFS external ID > > representation mechanism. In point of fact, this > > limit should be 8 to ensure interoperability with > > older SVR3/SVR4 systems. > > No, the NFS and RPC code have their own kluges to deal with broken > systems. You mean that they should. Try mounting an SVR4.0.2 NFS volume from a BSD system, and then accessing it from a credential with > 8 groups. > > ] #define OPEN_MAX 64 /* max open files per process */ > > Type: Bogus > Type: POSIX. Uh... where? Limits retrieval? > > ] #define PIPE_BUF 512 /* max bytes for atomic pipe writes */ > > Type: Bogus > Type: POSIX. ??? [ ... BC_ * ... ] > > Type: Bogus > > Type: POSIX. > > > Required by: A user space program > > Required by: IEEE-CS technical committee P1003.1. > > Any user-space program that executes `bc' to do arithmetic, or uses > the LC_COLLATE localization support, or executes `expr' to do > arithmetic. Yetch. Revised-Type: Gross, but POSIX From owner-freebsd-current Wed Oct 18 14:53:37 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id OAA24324 for current-outgoing; Wed, 18 Oct 1995 14:53:37 -0700 Received: from ess.harris.com (su15a.ess.harris.com [130.41.1.251]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id OAA24317 for ; Wed, 18 Oct 1995 14:53:33 -0700 Received: from borg.ess.harris.com (suw2k.ess.harris.com) by ess.harris.com (5.x/SMI-SVR4) id AA14583; Wed, 18 Oct 1995 17:53:12 -0400 Received: by borg.ess.harris.com (4.1/SMI-4.1) id AA04313; Wed, 18 Oct 95 17:50:26 EDT Date: Wed, 18 Oct 95 17:50:26 EDT From: jleppek@suw2k.ess.harris.com (James Leppek) Message-Id: <9510182150.AA04313@borg.ess.harris.com> To: freebsd-current@freefall.FreeBSD.org Subject: ranlib broken Sender: owner-current@FreeBSD.org Precedence: bulk I had some trouble with the current and stable version of ranlib using object names greater than 16 chars. It seems that it fails and complains of an invalid file format. Removing RPAD is the fix I think so the following patch fixes the problem for me. Jim Leppek *** build.c Wed Oct 18 16:57:43 1995 --- build.c.original Wed Oct 18 16:57:15 1995 *************** *** 103,109 **** /* Copy the saved objects into the archive. */ size = lseek(tfd, (off_t)0, SEEK_CUR); (void)lseek(tfd, (off_t)0, SEEK_SET); ! SETCF(tfd, tname, afd, archive, WPAD); copy_ar(&cf, size); (void)ftruncate(afd, lseek(afd, (off_t)0, SEEK_CUR)); (void)close(tfd); --- 103,109 ---- /* Copy the saved objects into the archive. */ size = lseek(tfd, (off_t)0, SEEK_CUR); (void)lseek(tfd, (off_t)0, SEEK_SET); ! SETCF(tfd, tname, afd, archive, RPAD|WPAD); copy_ar(&cf, size); (void)ftruncate(afd, lseek(afd, (off_t)0, SEEK_CUR)); (void)close(tfd); From owner-freebsd-current Wed Oct 18 15:33:49 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id PAA25829 for current-outgoing; Wed, 18 Oct 1995 15:33:49 -0700 Received: from Root.COM (implode.Root.COM [198.145.90.17]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id PAA25824 ; Wed, 18 Oct 1995 15:33:44 -0700 Received: from corbin.Root.COM (corbin [198.145.90.50]) by Root.COM (8.6.12/8.6.5) with ESMTP id PAA27155; Wed, 18 Oct 1995 15:33:41 -0700 Received: from localhost (localhost [127.0.0.1]) by corbin.Root.COM (8.6.12/8.6.5) with SMTP id PAA29572; Wed, 18 Oct 1995 15:30:13 -0700 Message-Id: <199510182230.PAA29572@corbin.Root.COM> To: Terry Lambert cc: wollman@lcs.mit.edu (Garrett A. Wollman), bde@zeta.org.au, bakul@netcom.com, current@freefall.freebsd.org, hackers@freefall.freebsd.org Subject: Re: getdtablesize() broken? In-reply-to: Your message of "Wed, 18 Oct 95 14:45:44 PDT." <199510182145.OAA01079@phaeton.artisoft.com> From: David Greenman Reply-To: davidg@Root.COM Date: Wed, 18 Oct 1995 15:30:06 -0700 Sender: owner-current@FreeBSD.org Precedence: bulk >> > ] #define ARG_MAX 65536 /* max bytes for an exec function */ >> >> > Type: Bogus. >> >> Type: POSIX. >> >> > Required by: The process environment being in the user's address >> > space instead of attached to the proc structure and >> > accessed through system calls. >> >> BZZZZT! Wrong, but thanks for playing. You can ask David or John >> about the memory-fragmentation issues which mandate the use of a >> separate VM submap to hold this data while it is being staged between >> the old process and the new process. > >BZZZZT! Replace the enviornment with logical names and hang the logical >name table off the proc struct instead of copying it like this and it >won't *need* to be staged. Bye bye, staging area. Mark the environment >as a shared copy-on-modification structure. BZZZZT! Not if you want argv[] to work. We're not talking about just the environment variables. -DG From owner-freebsd-current Wed Oct 18 17:00:01 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id RAA02639 for current-outgoing; Wed, 18 Oct 1995 17:00:01 -0700 Received: from rocky.sri.MT.net (sri.MT.net [204.94.231.129]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id QAA02626 for ; Wed, 18 Oct 1995 16:59:57 -0700 Received: (from nate@localhost) by rocky.sri.MT.net (8.6.12/8.6.12) id RAA11591; Wed, 18 Oct 1995 17:59:03 -0600 Date: Wed, 18 Oct 1995 17:59:03 -0600 From: Nate Williams Message-Id: <199510182359.RAA11591@rocky.sri.MT.net> To: Michael Smith Cc: nate@rocky.sri.MT.net (Nate Williams), handy@umbra.space.lockheed.com, current@FreeBSD.org Subject: Re: Linux emulator working? In-Reply-To: <199510190019.JAA13601@genesis.atrad.adelaide.edu.au> References: <199510182217.QAA11314@rocky.sri.MT.net> <199510190019.JAA13601@genesis.atrad.adelaide.edu.au> Sender: owner-current@FreeBSD.org Precedence: bulk > > What am I doing wrong? What can I do to fix this? I'm going to try to > > get Linux-IDL running under FreeBSD to see how the performance compares > > to the SPARC version we have. > > Please let me know how you go with IDL - we use it very heavily here on > Sparc and Alpha hardware, but being able to run it on the same platform that > does our data acquisition would be marvellous! Well, to be completely honest I was blown away. I am currently running Linux-IDL on FreeBSD as we speak. However, I can't tell how fast it is compared to our SPARC since the demo version installed by default doesn't do PRINTF. :( Some things to watch. 0) Create a 'uname' program which returns Linux instead of FreeBSD or else you'll have a bear of a time. I created a shell script and stuck it into /bin/uname. 1) The resolver libraries are different, so to get X working I had to specify the inet-address instead of the hostname. 2) I haven't been able to find libc.so.6, so everything complains about the C library. 3) The install complained about failures which I ignored and kept going, but after everything the install program went ballistic and starting sucking 98% CPU and needed to be blown away w/kill -9. All in all, I'm very impressed. IDL is a fairly large app. and it seems to work fine. Kudos!!! Nate From owner-freebsd-current Wed Oct 18 17:14:22 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id RAA03424 for current-outgoing; Wed, 18 Oct 1995 17:14:22 -0700 Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id RAA03402 ; Wed, 18 Oct 1995 17:14:16 -0700 Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id RAA01335; Wed, 18 Oct 1995 17:06:17 -0700 From: Terry Lambert Message-Id: <199510190006.RAA01335@phaeton.artisoft.com> Subject: Re: getdtablesize() broken? To: davidg@root.com Date: Wed, 18 Oct 1995 17:06:17 -0700 (MST) Cc: terry@lambert.org, wollman@lcs.mit.edu, bde@zeta.org.au, bakul@netcom.com, current@freefall.freebsd.org, hackers@freefall.freebsd.org In-Reply-To: <199510182230.PAA29572@corbin.Root.COM> from "David Greenman" at Oct 18, 95 03:30:06 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 779 Sender: owner-current@FreeBSD.org Precedence: bulk > >> about the memory-fragmentation issues which mandate the use of a > >> separate VM submap to hold this data while it is being staged between > >> the old process and the new process. > > > >BZZZZT! Replace the enviornment with logical names and hang the logical > >name table off the proc struct instead of copying it like this and it > >won't *need* to be staged. Bye bye, staging area. Mark the environment > >as a shared copy-on-modification structure. > > BZZZZT! Not if you want argv[] to work. We're not talking about just the > environment variables. Damn. I thought this was for envp. 8-(. Never mind on that one, then. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-current Wed Oct 18 21:16:21 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id VAA20579 for current-outgoing; Wed, 18 Oct 1995 21:16:21 -0700 Received: from alpha.xerox.com (alpha.Xerox.COM [13.1.64.93]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id VAA20551 ; Wed, 18 Oct 1995 21:16:14 -0700 Received: from crevenia.parc.xerox.com ([13.2.116.11]) by alpha.xerox.com with SMTP id <17317(4)>; Wed, 18 Oct 1995 16:52:46 PDT Received: from localhost by crevenia.parc.xerox.com with SMTP id <177478>; Wed, 18 Oct 1995 16:52:28 -0700 X-Mailer: exmh version 1.6.1 5/23/95 To: "Garrett A. Wollman" cc: "Serge A. Babkin" , gena@netvision.net.il, wollman@freebsd.org, jkh@time.cdrom.com, current@freebsd.org Subject: Re: 3c509 in -current needs patching In-reply-to: Your message of "Wed, 18 Oct 95 06:56:40 PDT." <9510181356.AA05148@halloran-eldar.lcs.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 18 Oct 1995 16:52:20 PDT From: Bill Fenner Message-Id: <95Oct18.165228pdt.177478@crevenia.parc.xerox.com> Sender: owner-current@freebsd.org Precedence: bulk In message <9510181356.AA05148@halloran-eldar.lcs.mit.edu> you write: >If multicast is not supported, the driver should not claim to support >it. There is a 1-bit filter: all multicast, or no multicast. All versions of the driver that I have seen set this bit, but don't set IFF_MULTICAST and return EINVAL for SIOC{ADD,DEL}MULTI. Setting IFF_MULTICAST and making SIOC{ADD,DEL}MULTI no-op's makes multicast work, although the kernel is doing all of the filtering instead of the card. Bill From owner-freebsd-current Wed Oct 18 21:46:03 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id VAA25066 for current-outgoing; Wed, 18 Oct 1995 21:46:03 -0700 Received: from rocky.sri.MT.net (sri.MT.net [204.94.231.129]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id VAA25047 for ; Wed, 18 Oct 1995 21:45:59 -0700 Received: (from nate@localhost) by rocky.sri.MT.net (8.6.12/8.6.12) id WAA12096; Wed, 18 Oct 1995 22:48:17 -0600 Date: Wed, 18 Oct 1995 22:48:17 -0600 From: Nate Williams Message-Id: <199510190448.WAA12096@rocky.sri.MT.net> To: current@FreeBSD.org Subject: IDL and FreeBSD Sender: owner-current@FreeBSD.org Precedence: bulk I can now say with assurance that FreeBSD can indeed run the Linux version of IDL. I installed it this afternoon, and finally tonight tracked down a bug where the IDL libraries routines weren't being found and was able to run all of the demos and run a little program of my own. For those who want a quick overview on what IDL is, I make the following, and apologize to RSI Inc. for any mis-representation, and encourage users of IDL to speak up and help me out here. IDL is a high-level language that allows one to write programs very quickly and easily, including GUI's and the works. It also lets one integrate in C, Fortran, and other languages code. It some ways it's a lot like TCL/TK, except that it's at a much higher level. Building a GUI in IDL is very easy once you get past the initial learning curve. However, IDL requires run-time royalties, and it's quite expensive. But, it's used by quite a few folks, and SRI is using it now so I thought I'd give it a shot under the Linux emulator. The pentium box running Linux-emulation under FreeBSD runs IDL about 2-3x faster than the SPARC 5 I would normally use, so you can understand my interest. If folks are interested, I could write-up a HOW-TO sheet to explain how to get it running, but I'm not going to take the time if no one is interested. It took a bit of time to track down a couple bugs, and one was quite strange to say the least but is easily fixed once one understands the problem. In any case, congratulations to S'ren for a great emulation package. The only NO-OP is get is from syslog, and although I'd like to fix it I don't know where to begin. Thanks! Nate From owner-freebsd-current Wed Oct 18 22:24:29 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id WAA01560 for current-outgoing; Wed, 18 Oct 1995 22:24:29 -0700 Received: from hq.icb.chel.su (icb-rich-gw.icb.chel.su [193.125.10.34]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id WAA01529 ; Wed, 18 Oct 1995 22:24:14 -0700 Received: from localhost (babkin@localhost) by hq.icb.chel.su (8.6.5/8.6.5) id KAA29910; Thu, 19 Oct 1995 10:25:29 +0500 From: "Serge A. Babkin" Message-Id: <199510190525.KAA29910@hq.icb.chel.su> Subject: Re: 3c509 in -current needs patching To: wollman@lcs.mit.edu (Garrett A. Wollman) Date: Thu, 19 Oct 1995 10:25:28 +0500 (GMT+0500) Cc: gena@NetVision.net.il, wollman@freebsd.org, jkh@time.cdrom.com, current@freebsd.org In-Reply-To: <9510181356.AA05148@halloran-eldar.lcs.mit.edu> from "Garrett A. Wollman" at Oct 18, 95 09:56:40 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 904 Sender: owner-current@freebsd.org Precedence: bulk > > < said: > > I found a bug by visual inspection... > > > ! ifp->if_flags = IFF_BROADCAST | IFF_MULTICAST | > > ! IFF_SIMPLEX | IFF_NOTRAILERS; > > > ! case SIOCADDMULTI: > > ! case SIOCDELMULTI: > > ! /* Now this driver has no support for programmable > > ! * multicast filters. If some day it will gain this > > ! * support this part of code must be extended. > > ! */ > > ! error=0; > > ! break; > > If multicast is not supported, the driver should not claim to support > it. Multicast is supported but the card has no multicast filter, it simply receives all multicast packets when the FIL_GROUP bit is set in the SET_RX_FILTER command. Serge Babkin ! (babkin@hq.icb.chel.su) ! Headquarter of Joint Stock Commercial Bank "Chelindbank" ! Chelyabinsk, Russia From owner-freebsd-current Wed Oct 18 23:56:14 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id XAA12282 for current-outgoing; Wed, 18 Oct 1995 23:56:14 -0700 Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id XAA12259 ; Wed, 18 Oct 1995 23:56:03 -0700 Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id QAA01589; Thu, 19 Oct 1995 16:48:10 +1000 Date: Thu, 19 Oct 1995 16:48:10 +1000 From: Bruce Evans Message-Id: <199510190648.QAA01589@godzilla.zeta.org.au> To: terry@lambert.org, wollman@lcs.mit.edu Subject: Re: getdtablesize() broken? Cc: bakul@netcom.com, bde@zeta.org.au, current@freefall.freebsd.org, hackers@freefall.freebsd.org Sender: owner-current@FreeBSD.org Precedence: bulk >> > ] #define ARG_MAX 65536 /* max bytes for an exec function */ >> >> > Type: Bogus. >> >> Type: POSIX. Type: Bogus. >> BZZZZT! Wrong, but thanks for playing. You can ask David or John >> about the memory-fragmentation issues which mandate the use of a Defining it makes it part of the ABI and inhibits future changes such as changing it to another fixed value or solving the memory fragmentation problems and making the limit indeterminate (POSIX 2.8.4 says it shall not be defined if it is indeterminate). Few programs use ARG_MAX, but those that do may break unnecessarily if it is changed. The limit should also be OS-dependent to support emulation of bogus definitions of it in other OS's. E.g., in Linux it is 128K, so Linux programs that rely on it may break. Both Linux and FreeBSD should leave it undefined so that applications are forced to use sysconf() if they want to know about it. The emulation support for Linux would then be trivial (just return the FreeBSD limit is sysconf()). >> > ] #define CHILD_MAX 40 /* max simultaneous processes */ >> >> > Type: Administrative (compile time override) >> >> Type: Bogus but POSIX. Type: Bogus (fails POSIX standards tests). This is another POSIX limit that shall be left undefined if its value is indeterminate. Its value is indeterminate because it may be changed by setrlimit(). This limit is sometimes bogusly redefined in kernel config files without changing its value in the . Then the advertised value is wrong even in the default case. (the kernel just uses the redefined value for the default rlimit, so the effect is the same as if all programs started with a setrlimit()). >> >> > Required by: The ability for a user program to fork(2) the system to >> > death. >> >> BZZZZT! This value should be modifiable at run time. (It isn't yet.) BZZZZT! :-) The maximum number of child processes is modifiable at runtime (using setrlimit()) and sysconf() correctly returns the modified value. >> > ] #define LINK_MAX 32767 /* max file link count */ >> > Type: Pragmatic >> Type: POSIX. Type: Bogus. This is another POSIX limit that shall be left undefined if its value is indeterminate. Its value is indeterminate because it depends on the file system. File systems and sysconf() handle it more or less correctly. >> > ] #define MAX_CANON 255 /* max bytes in term canon input line */ >> > Type: Bogus >> Type: POSIX. Type: Bogus. There is a related limit TTYHOG whose value (1024) is nowhere near the advertised limit. Defining the limit correctly would make it part of the ABI and interfere with future improvements, as above. Fortunarely, this limit is even less useful than ARG_MAX, so perhaps nothing depends on it. >> > ] #define NGROUPS_MAX 16 /* max supplemental group id's */ >> > Type: Standard (Interoperability, Legacy) >> > Required by: NFS, YP >> > Reason: Excess groups are truncated by the NFS external ID >> > representation mechanism. In point of fact, this >> > limit should be 8 to ensure interoperability with >> > older SVR3/SVR4 systems. >> >> No, the NFS and RPC code have their own kluges to deal with broken >> systems. >You mean that they should. Try mounting an SVR4.0.2 NFS volume from a >BSD system, and then accessing it from a credential with > 8 groups. Unfortunately fixing limits in FreeBSD (by making them indeterminate) won't affect compatibility. >> > ] #define OPEN_MAX 64 /* max open files per process */ >> > Type: Bogus >> Type: POSIX. Type: Bogus. S Same as for CHILD_MAX. >> > ] #define PIPE_BUF 512 /* max bytes for atomic pipe writes */ >> > Type: Bogus >> Type: POSIX. Type: Bogus. A pain in the ABI, as above. Under Linux, PIPE_BUF is 4095. If the limit is actually 512 under FreeBSD, then Linux programs that expect to write 4095 atomically to pipes can't be emulated properly. >[ ... BC_ * ... ] >> > Type: Bogus >> >> Type: POSIX. >> >> > Required by: A user space program >> >> Required by: IEEE-CS technical committee P1003.1. >> >> Any user-space program that executes `bc' to do arithmetic, or uses >> the LC_COLLATE localization support, or executes `expr' to do >> arithmetic. >Yetch. >Revised-Type: Gross, but POSIX [a-zA-Z]etch. Interferes with ABI compatibility at the library level. Fewer problems with emulation because other OS's have their own libraries. Summary: 1,$s/^Type:.*/Type: Bogus/ Bruce From owner-freebsd-current Thu Oct 19 00:00:18 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id AAA12445 for current-outgoing; Thu, 19 Oct 1995 00:00:18 -0700 Received: from meter.eng.uci.edu (root@meter.eng.uci.edu [128.200.85.3]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id AAA12440 for ; Thu, 19 Oct 1995 00:00:15 -0700 Received: from newport.ece.uci.edu by meter.eng.uci.edu (8.7) id AAA06887; Thu, 19 Oct 1995 00:00:12 -0700 (PDT) Received: from localhost by newport.ece.uci.edu (8.7) id AAA14236; Thu, 19 Oct 1995 00:00:10 -0700 (PDT) Message-Id: <199510190700.AAA14236@newport.ece.uci.edu> To: freebsd-current@freebsd.org Subject: kernel with -O2 Date: Thu, 19 Oct 1995 00:00:08 -0700 From: Steven Wallace Sender: owner-current@freebsd.org Precedence: bulk does not work for your info. If I ktrace something with a -O2 kernel I do not get the same results as running the program w/o ktrace. -O works fine. Trying -O2 -fno-strength-reduce now From owner-freebsd-current Thu Oct 19 00:59:41 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id AAA13721 for current-outgoing; Thu, 19 Oct 1995 00:59:41 -0700 Received: from time.cdrom.com (time.cdrom.com [192.216.222.226]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id AAA13701 ; Thu, 19 Oct 1995 00:59:35 -0700 Received: from time.cdrom.com (localhost [127.0.0.1]) by time.cdrom.com (8.6.12/8.6.9) with SMTP id AAA19100; Thu, 19 Oct 1995 00:58:50 -0700 Message-ID: <3086053A.2577A1CC@FreeBSD.org> Date: Thu, 19 Oct 1995 00:58:50 -0700 From: "Jordan K. Hubbard" X-Mailer: Mozilla 2.0b1 (X11; I; FreeBSD 2.1-STABLE i386) MIME-Version: 1.0 To: davidg@Root.COM CC: Terry Lambert , "Garrett A. Wollman" , bde@zeta.org.au, bakul@netcom.com, current@freefall.freebsd.org, hackers@freefall.freebsd.org Subject: Re: getdtablesize() broken? References: <199510182230.PAA29572@corbin.Root.COM> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.org Precedence: bulk > >> BZZZZT! Wrong, but thanks for playing. You can ask David or John > >BZZZZT! Replace the enviornment with logical names and hang the > BZZZZT! Not if you want argv[] to work. We're not talking about just Why am I reminded of angry bees, arguing inside the hive? :-) -- Jordan From owner-freebsd-current Thu Oct 19 04:21:04 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id EAA18524 for current-outgoing; Thu, 19 Oct 1995 04:21:04 -0700 Received: from zibbi.mikom.csir.co.za (zibbi.mikom.csir.co.za [146.64.24.58]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id EAA18460 for ; Thu, 19 Oct 1995 04:15:33 -0700 Received: (from jhay@localhost) by zibbi.mikom.csir.co.za (8.6.11/8.6.9) id NAA27005 for freebsd-current@FreeBSD.ORG; Thu, 19 Oct 1995 13:09:36 +0200 From: John Hay Message-Id: <199510191109.NAA27005@zibbi.mikom.csir.co.za> Subject: clock running faster? To: freebsd-current@FreeBSD.ORG (FreeBSD-current) Date: Thu, 19 Oct 1995 13:09:36 +0200 (SAT) X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 414 Sender: owner-current@FreeBSD.ORG Precedence: bulk Hi, Yesterday I rebooted my current machine (90M Pentium) with a new kernel. The previous kernel was build on the 13th. Now suddenly the clock gains almost 30 second in an hour. Previously the clock was very stable. I have even rebooted and it still does it. Has anybody seen something like this? I see there were changes made to i386/isa/clock.c and kern/kern_clock.c. John -- John Hay -- John.Hay@csir.co.za From owner-freebsd-current Thu Oct 19 05:53:23 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id FAA19911 for current-outgoing; Thu, 19 Oct 1995 05:53:23 -0700 Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id FAA19906 for ; Thu, 19 Oct 1995 05:53:18 -0700 Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id WAA16201; Thu, 19 Oct 1995 22:51:40 +1000 Date: Thu, 19 Oct 1995 22:51:40 +1000 From: Bruce Evans Message-Id: <199510191251.WAA16201@godzilla.zeta.org.au> To: freebsd-current@FreeBSD.ORG, jhay@mikom.csir.co.za Subject: Re: clock running faster? Sender: owner-current@FreeBSD.ORG Precedence: bulk >Yesterday I rebooted my current machine (90M Pentium) with a new kernel. The >previous kernel was build on the 13th. Now suddenly the clock gains almost >30 second in an hour. Previously the clock was very stable. I have even >rebooted and it still does it. >Has anybody seen something like this? I see there were changes made to >i386/isa/clock.c and kern/kern_clock.c. The changes have the effect of making the Pentium clock the reference. Apparently your 8254 clock's frequency is closer to its nominal value (1193182 Hz) than your Pentium clock's frequency is to its measured value (pentium_mhz = N MHz where N is as reported at boot time). The measurement and use of N depends on N being an integer for accuracy. Apparently the measured value is too small by a factor of 90/90.75. Bruce From owner-freebsd-current Thu Oct 19 06:22:27 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id GAA20499 for current-outgoing; Thu, 19 Oct 1995 06:22:27 -0700 Received: from zibbi.mikom.csir.co.za (zibbi.mikom.csir.co.za [146.64.24.58]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id GAA20436 for ; Thu, 19 Oct 1995 06:20:34 -0700 Received: (from jhay@localhost) by zibbi.mikom.csir.co.za (8.6.11/8.6.9) id PAA27646; Thu, 19 Oct 1995 15:19:06 +0200 From: John Hay Message-Id: <199510191319.PAA27646@zibbi.mikom.csir.co.za> Subject: Re: clock running faster? To: bde@zeta.org.au (Bruce Evans) Date: Thu, 19 Oct 1995 15:19:05 +0200 (SAT) Cc: freebsd-current@FreeBSD.ORG (FreeBSD-current) In-Reply-To: <199510191251.WAA16201@godzilla.zeta.org.au> from "Bruce Evans" at Oct 19, 95 10:51:40 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1436 Sender: owner-current@FreeBSD.ORG Precedence: bulk > > >Yesterday I rebooted my current machine (90M Pentium) with a new kernel. The > >previous kernel was build on the 13th. Now suddenly the clock gains almost > >30 second in an hour. Previously the clock was very stable. I have even > >rebooted and it still does it. > > >Has anybody seen something like this? I see there were changes made to > >i386/isa/clock.c and kern/kern_clock.c. > > The changes have the effect of making the Pentium clock the reference. > Apparently your 8254 clock's frequency is closer to its nominal value > (1193182 Hz) than your Pentium clock's frequency is to its measured > value (pentium_mhz = N MHz where N is as reported at boot time). The > measurement and use of N depends on N being an integer for accuracy. > Apparently the measured value is too small by a factor of 90/90.75. > Those measurements made on kernel startup does not seem stable. Here is a grep in my /var/log/messages file. Oct 18 18:39:57 angel /kernel: CPU: 86-MHz Pentium 735\90 or 815\100 (Pentium-class CPU) Oct 18 18:42:11 angel /kernel: CPU: 87-MHz Pentium 735\90 or 815\100 (Pentium-class CPU) Oct 19 11:53:40 angel /kernel: CPU: 83-MHz Pentium 735\90 or 815\100 (Pentium-class CPU) Oct 19 11:57:18 angel /kernel: CPU: 85-MHz Pentium 735\90 or 815\100 (Pentium-class CPU) Oct 19 11:59:33 angel /kernel: CPU: 89-MHz Pentium 735\90 or 815\100 (Pentium-class CPU) John -- John Hay -- John.Hay@csir.co.za From owner-freebsd-current Thu Oct 19 06:52:41 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id GAA20929 for current-outgoing; Thu, 19 Oct 1995 06:52:41 -0700 Received: from tfs.com (tfs.com [140.145.250.1]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id GAA20923 for ; Thu, 19 Oct 1995 06:52:39 -0700 Received: from critter.tfs.com by tfs.com (smail3.1.28.1) with SMTP id m0t5vOe-0003wpC; Thu, 19 Oct 95 06:52 PDT Received: from localhost (localhost [127.0.0.1]) by critter.tfs.com (8.6.11/8.6.9) with SMTP id OAA01981; Thu, 19 Oct 1995 14:52:36 +0100 X-Authentication-Warning: critter.tfs.com: Host localhost didn't use HELO protocol To: John Hay cc: bde@zeta.org.au (Bruce Evans), freebsd-current@FreeBSD.ORG (FreeBSD-current) Subject: Re: clock running faster? In-reply-to: Your message of "Sat, 19 Oct 1995 15:19:05 +0200." <199510191319.PAA27646@zibbi.mikom.csir.co.za> Date: Thu, 19 Oct 1995 14:52:35 +0100 Message-ID: <1979.814110755@critter.tfs.com> From: Poul-Henning Kamp Sender: owner-current@FreeBSD.ORG Precedence: bulk > Those measurements made on kernel startup does not seem stable. Here is a > grep in my /var/log/messages file. > > Oct 18 18:39:57 angel /kernel: CPU: 86-MHz Pentium 735\90 or 815\100 > (Pentium-class CPU) > Oct 18 18:42:11 angel /kernel: CPU: 87-MHz Pentium 735\90 or 815\100 > (Pentium-class CPU) > Oct 19 11:53:40 angel /kernel: CPU: 83-MHz Pentium 735\90 or 815\100 > (Pentium-class CPU) > Oct 19 11:57:18 angel /kernel: CPU: 85-MHz Pentium 735\90 or 815\100 > (Pentium-class CPU) > Oct 19 11:59:33 angel /kernel: CPU: 89-MHz Pentium 735\90 or 815\100 > (Pentium-class CPU) I've seen this too. Do you have any APM or other Power-mgt stuff enabled in the bios ? -- Poul-Henning Kamp | phk@FreeBSD.ORG FreeBSD Core-team. http://www.freebsd.org/~phk | phk@login.dknet.dk Private mailbox. whois: [PHK] | phk@ref.tfs.com TRW Financial Systems, Inc. Future will arrive by its own means, progress not so. From owner-freebsd-current Thu Oct 19 07:03:21 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id HAA21085 for current-outgoing; Thu, 19 Oct 1995 07:03:21 -0700 Received: from halloran-eldar.lcs.mit.edu (halloran-eldar.lcs.mit.edu [18.26.0.159]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id HAA21076 for ; Thu, 19 Oct 1995 07:03:13 -0700 Received: by halloran-eldar.lcs.mit.edu; (5.65/1.1.8.2/19Aug95-0530PM) id AA06899; Thu, 19 Oct 1995 09:58:37 -0400 Date: Thu, 19 Oct 1995 09:58:37 -0400 From: "Garrett A. Wollman" Message-Id: <9510191358.AA06899@halloran-eldar.lcs.mit.edu> To: John Hay Cc: freebsd-current@FreeBSD.ORG (FreeBSD-current) Subject: clock running faster? In-Reply-To: <199510191109.NAA27005@zibbi.mikom.csir.co.za> References: <199510191109.NAA27005@zibbi.mikom.csir.co.za> Sender: owner-current@FreeBSD.ORG Precedence: bulk < said: > 30 second in an hour. Previously the clock was very stable. I have even > rebooted and it still does it. > Has anybody seen something like this? I see there were changes made to > i386/isa/clock.c and kern/kern_clock.c. Does the startup code correctly diagnose your CPU as a 90-MHz model? If not, then you can #ifdef out the code in clock.c that looks like this: unsigned long long count; __asm __volatile(".byte 0x0f, 0x30" : : "A"(0LL), "c" (0x10)); DELAY(1000000); __asm __volatile(".byte 0xf,0x31" : "=A" (count)); /* * XX lose if the clock rate is not nearly a multiple of 1000000. */ pentium_mhz = (count + 500000) / 1000000; And you might check to see why the DELAY macro isn't delaying for the correct length of time (should be one second). -GAWollman -- Garrett A. Wollman | Shashish is simple, it's discreet, it's brief. ... wollman@lcs.mit.edu | Shashish is the bonding of hearts in spite of distance. Opinions not those of| It is a bond more powerful than absence. We like people MIT, LCS, ANA, or NSA| who like Shashish. - Claude McKenzie + Florent Vollant From owner-freebsd-current Thu Oct 19 07:14:44 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id HAA21234 for current-outgoing; Thu, 19 Oct 1995 07:14:44 -0700 Received: from zibbi.mikom.csir.co.za (zibbi.mikom.csir.co.za [146.64.24.58]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id HAA21223 for ; Thu, 19 Oct 1995 07:14:35 -0700 Received: (from jhay@localhost) by zibbi.mikom.csir.co.za (8.6.11/8.6.9) id QAA28496; Thu, 19 Oct 1995 16:09:38 +0200 From: John Hay Message-Id: <199510191409.QAA28496@zibbi.mikom.csir.co.za> Subject: Re: clock running faster? To: phk@critter.tfs.com (Poul-Henning Kamp) Date: Thu, 19 Oct 1995 16:09:38 +0200 (SAT) Cc: bde@zeta.org.au, freebsd-current@FreeBSD.org In-Reply-To: <1979.814110755@critter.tfs.com> from "Poul-Henning Kamp" at Oct 19, 95 02:52:35 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2613 Sender: owner-current@FreeBSD.org Precedence: bulk > > > Those measurements made on kernel startup does not seem stable. Here is a > > grep in my /var/log/messages file. > > > > Oct 18 18:39:57 angel /kernel: CPU: 86-MHz Pentium 735\90 or 815\100 > > (Pentium-class CPU) > > Oct 18 18:42:11 angel /kernel: CPU: 87-MHz Pentium 735\90 or 815\100 > > (Pentium-class CPU) > > Oct 19 11:53:40 angel /kernel: CPU: 83-MHz Pentium 735\90 or 815\100 > > (Pentium-class CPU) > > Oct 19 11:57:18 angel /kernel: CPU: 85-MHz Pentium 735\90 or 815\100 > > (Pentium-class CPU) > > Oct 19 11:59:33 angel /kernel: CPU: 89-MHz Pentium 735\90 or 815\100 > > (Pentium-class CPU) > > I've seen this too. > Do you have any APM or other Power-mgt stuff enabled in the bios ? > No, this is a dual pentium PCI/EISA motherboard. Its number is GA-586ID. It doesn't have any power management stuff. Just incase it help, I will attach the output from dmesg. John -- John Hay -- John.Hay@csir.co.za FreeBSD 2.2-CURRENT #0: Thu Oct 19 11:53:53 SAT 1995 jhay@angel.cids.org.za:/usr/src/sys/compile/ANGEL CPU: 89-MHz Pentium 735\\90 or 815\\100 (Pentium-class CPU) Origin = "GenuineIntel" Id = 0x525 Stepping=5 Features=0x3bf real memory = 33554432 (32768K bytes) avail memory = 31498240 (30760K bytes) Probing for devices on the ISA bus: sc0 at 0x60-0x6f irq 1 on motherboard sc0: VGA color <16 virtual consoles, flags=0x0> ed0 at 0x280-0x29f irq 5 maddr 0xd8000 msize 16384 on isa ed0: address 00:00:c0:70:bf:94, type SMC8416C/SMC8416BT (16 bit) sio0 at 0x3f8-0x3ff irq 4 on isa sio0: type 16450 sio1 at 0x2f8-0x2ff irq 3 on isa sio1: type 16450 sio2 not found at 0x3e8 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: NEC 765 fd0: 1.44MB 3.5in npx0 on motherboard npx0: INT 16 interface gus0 at 0x220 irq 15 drq 1 flags 0x3 on isa gus0: gus0: Probing for devices on the PCI bus: chip0 rev 17 on pci0:0 chip1 rev 4 on pci0:2 vga0 rev 0 int a irq 11 on pci0:3 ncr0 rev 1 int a irq 12 on pci0:4 (ncr0:0:0): "CONNER CFP1060S 1.05GB 203C" type 0 fixed SCSI 2 sd0(ncr0:0:0): Direct-Access sd0(ncr0:0:0): FAST SCSI-2 100ns (10 Mb/sec) offset 8. 1013MB (2074880 512 byte sectors) (ncr0:4:0): "TANDBERG TDC 3800 =04:" type 1 removable SCSI 2 st0(ncr0:4:0): Sequential-Access st0(ncr0:4:0): asynchronous. st0(ncr0:4:0): asynchronous. density code 0x0, drive empty From owner-freebsd-current Thu Oct 19 08:10:43 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id IAA22419 for current-outgoing; Thu, 19 Oct 1995 08:10:43 -0700 Received: from kitten.mcs.com (Kitten.mcs.com [192.160.127.90]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id IAA22413 for ; Thu, 19 Oct 1995 08:10:40 -0700 Received: from mailbox.mcs.com (Mailbox.mcs.com [192.160.127.87]) by kitten.mcs.com (8.6.10/8.6.9) with SMTP id KAA14860 for ; Thu, 19 Oct 1995 10:10:34 -0500 Received: by mailbox.mcs.com (/\==/\ Smail3.1.28.1 #28.5) id ; Thu, 19 Oct 95 10:10 CDT Received: by mercury.mcs.com (/\==/\ Smail3.1.28.1 #28.5) id ; Thu, 19 Oct 95 10:10 CDT Message-Id: Subject: New Kerberos stuff missing dependencies? To: current@freebsd.org Date: Thu, 19 Oct 1995 10:10:32 -0500 (CDT) From: "Lars Fredriksen" X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 905 Sender: owner-current@freebsd.org Precedence: bulk Hi, I just started a partiall world build yesterday, the last one was done Aug. 9. Here secure/lib/libtelnet failed to compile due to include/Kerberos not being there or up to date. Once that was fiexed, secure/lib/libtelnet(or something around there) failed to find libdes. So either I screwed up big time, or there are some depenencies missing. Here are the steps I did: cd /usr/src/include make install cd /usr/src/lib make After secure/lib/libtelnet failed to build I did: cd /usr/src/secure/include make install cd /usr/src/lib make Now fails saying that it cannot find libdes. Now, I expect that it would look in /usr/src/obj/lib or something similar for libdes and not in /usr/lib. Lars -- ------------------------------------------------------------------- Lars Fredriksen fredriks@mcs.com (home) lars@fredriks.pr.mcs.net (home-home) fredriks@asiago.cs.wisc.edu From owner-freebsd-current Thu Oct 19 14:00:49 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id OAA01602 for current-outgoing; Thu, 19 Oct 1995 14:00:49 -0700 Received: from halloran-eldar.lcs.mit.edu (halloran-eldar.lcs.mit.edu [18.26.0.159]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id OAA01590 for ; Thu, 19 Oct 1995 14:00:43 -0700 Received: by halloran-eldar.lcs.mit.edu; (5.65/1.1.8.2/19Aug95-0530PM) id AA07932; Thu, 19 Oct 1995 17:00:42 -0400 Date: Thu, 19 Oct 1995 17:00:42 -0400 From: "Garrett A. Wollman" Message-Id: <9510192100.AA07932@halloran-eldar.lcs.mit.edu> To: FreeBSD-Current Mailing List Subject: [David Borman: New BSD telnet code] Sender: owner-current@FreeBSD.ORG Precedence: bulk ------- start of forwarded message (RFC 934 encapsulation) ------- Message-Id: <9510191927.AA10371@poplar029> From: David Borman Sender: ietf-request@IETF.CNRI.Reston.VA.US To: TN3270E@list.nih.gov, ietf@CNRI.Reston.VA.US, tcp-ip@nisc.sri.com, telnet-ietf@cray.com Subject: New BSD telnet code Date: Thu, 19 Oct 1995 14:27:57 -0500 There is a new version of the BSD telnet code now available for anonymous FTP. This new version contains bug fixes to the 95.05.31 distribution (which is what is on 4.4BSD-Lite Release 2). It can be gotten from: ftp://ftp.cray.com/src/telnet/telnet.95.10.19.NE.tar.Z This version does not contain encryption. An archive with the encryption code has been sent off to MIT, and hopefully it will show up on net-dist.mit.edu:/pub/telnet in the near future. See: ftp://ftp.cray.com/src/telnet/README.encryption for more information on how to get it. Until then, you can also get the file: ftp://ftp.cray.com/src/telnet/telnet.95.10.19.diff.Z which contains the diffs to apply to the telnet.95.05.31.tar.Z to get to the new version. If you are using telnetd from the 95.05.31 distribution, I would recommend that you upgrade to this new release. (One major problem that people have run into that is fixed in the release is that the /etc/utmp file could get mucked up on SunOS/Solaris.) -David Borman, dab@cray.com ------- end ------- From owner-freebsd-current Thu Oct 19 14:19:19 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id OAA02430 for current-outgoing; Thu, 19 Oct 1995 14:19:19 -0700 Received: from silvia.HIP.Berkeley.EDU (silvia.HIP.Berkeley.EDU [136.152.64.181]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id OAA02425 for ; Thu, 19 Oct 1995 14:19:14 -0700 Received: (from asami@localhost) by silvia.HIP.Berkeley.EDU (8.6.12/8.6.9) id OAA02041; Thu, 19 Oct 1995 14:19:06 -0700 Date: Thu, 19 Oct 1995 14:19:06 -0700 Message-Id: <199510192119.OAA02041@silvia.HIP.Berkeley.EDU> To: current@freebsd.org Subject: make world failure in /usr/src/share/doc/ From: asami@cs.berkeley.edu (Satoshi Asami) Sender: owner-current@freebsd.org Precedence: bulk I've seen this in yesterday's -current.... Satoshi ------- (cd /b/src/share/doc/usd/12.vi/../../../../usr.bin/vi/USD.doc/vitut; groff -Tlj -t -ms -o1- vi.summary) | gzip -c > summary.lj.gz groff: can't find `DESC' file groff:fatal error: invalid device `lj' (cd /b/src/share/doc/usd/12.vi/../../../../usr.bin/vi/USD.doc/vitut; groff -Tlj -t -ms -o1- vi.apwh.ms) | gzip -c > viapwh.lj.gz groff: can't find `DESC' file groff:fatal error: invalid device `lj' ===> share/doc/usd/13.viref # Build index.so, side-effect of building the paper. (cd /b/src/share/doc/usd/13.viref/../../../../usr.bin/vi/USD.doc/vi.ref; soelim vi.ref) | tbl | groff -Tlj -t -s -me -o1- > /dev/null groff: can't find `DESC' file groff:fatal error: invalid device `lj' *** Error code 3 Stop. *** Error code 1 Stop. *** Error code 1 Stop. *** Error code 1 Stop. *** Error code 1 Stop. *** Error code 1 Stop. From owner-freebsd-current Thu Oct 19 16:39:54 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id QAA05841 for current-outgoing; Thu, 19 Oct 1995 16:39:54 -0700 Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id QAA05836 for ; Thu, 19 Oct 1995 16:39:50 -0700 Received: from sax.sax.de by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id AAA11715 for ; Fri, 20 Oct 1995 00:39:41 +0100 Received: by sax.sax.de (8.6.11/8.6.12-s1) with UUCP id AAA28534 for freebsd-current@FreeBSD.org; Fri, 20 Oct 1995 00:39:40 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.6.12/8.6.9) id XAA05193 for freebsd-current@FreeBSD.org; Thu, 19 Oct 1995 23:57:17 +0100 From: J Wunsch Message-Id: <199510192257.XAA05193@uriah.heep.sax.de> Subject: Re: clock running faster? To: freebsd-current@FreeBSD.org Date: Thu, 19 Oct 1995 23:57:17 +0100 (MET) Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199510191251.WAA16201@godzilla.zeta.org.au> from "Bruce Evans" at Oct 19, 95 10:51:40 pm X-Phone: +49-351-2012 669 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 302 Sender: owner-current@FreeBSD.org Precedence: bulk As Bruce Evans wrote: > > The changes have the effect of making the Pentium clock the reference. I don't think this has been a good idea. -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-current Thu Oct 19 23:30:05 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id XAA17665 for current-outgoing; Thu, 19 Oct 1995 23:30:05 -0700 Received: from aslan.cdrom.com (aslan.cdrom.com [192.216.223.142]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id XAA17653 for ; Thu, 19 Oct 1995 23:29:55 -0700 Received: from localhost.cdrom.com (localhost.cdrom.com [127.0.0.1]) by aslan.cdrom.com (8.6.12/8.6.9) with SMTP id XAA08349; Thu, 19 Oct 1995 23:29:39 -0700 Message-Id: <199510200629.XAA08349@aslan.cdrom.com> X-Authentication-Warning: aslan.cdrom.com: Host localhost.cdrom.com didn't use HELO protocol To: "Lars Fredriksen" cc: current@freebsd.org Subject: Re: New Kerberos stuff missing dependencies? In-reply-to: Your message of "Thu, 19 Oct 1995 10:10:32 CDT." Date: Thu, 19 Oct 1995 23:29:39 -0700 From: "Justin T. Gibbs" Sender: owner-current@freebsd.org Precedence: bulk >Hi, > I just started a partiall world build yesterday, the last >one was done Aug. 9. Here secure/lib/libtelnet failed to compile >due to include/Kerberos not being there or up to date. Once that was >fiexed, secure/lib/libtelnet(or something around there) failed to >find libdes. > > So either I screwed up big time, or there are some depenencies >missing. > >Here are the steps I did: > > cd /usr/src/include > make install Should be (cd /usr/src;make includes) > cd /usr/src/lib > make Should be (cd /usr/src; make libraries) > After secure/lib/libtelnet failed to build I did: > cd /usr/src/secure/include > make install Would have happened from a "make includes". > cd /usr/src/lib > make > Now fails saying that it cannot find libdes. Now, I > expect that it would look in /usr/src/obj/lib or something > similar for libdes and not in /usr/lib. Hmmm. It looks like secure/libtelnet bogusly adds "-lkrb -ldes" to LDADD. This is probably what you are seeing. It also looks that secure/libtelnet is not guaranteed to be secure with a call to "make libraries" since it bases its decision about adding kerberos functionality on the existence of /usr/lib/libkrb.a. Anyone have any comments on how we should fix the second problem? >Lars >-- >------------------------------------------------------------------- >Lars Fredriksen fredriks@mcs.com (home) > lars@fredriks.pr.mcs.net (home-home) > fredriks@asiago.cs.wisc.edu -- Justin T. Gibbs =========================================== Software Developer - Walnut Creek CDROM FreeBSD: Turning PCs into workstations =========================================== From owner-freebsd-current Fri Oct 20 07:28:20 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id HAA05847 for current-outgoing; Fri, 20 Oct 1995 07:28:20 -0700 Received: from halloran-eldar.lcs.mit.edu (halloran-eldar.lcs.mit.edu [18.26.0.159]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id HAA05842 for ; Fri, 20 Oct 1995 07:28:16 -0700 Received: by halloran-eldar.lcs.mit.edu; (5.65/1.1.8.2/19Aug95-0530PM) id AA09055; Fri, 20 Oct 1995 10:26:22 -0400 Date: Fri, 20 Oct 1995 10:26:22 -0400 From: "Garrett A. Wollman" Message-Id: <9510201426.AA09055@halloran-eldar.lcs.mit.edu> To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) Cc: freebsd-current@freebsd.org Subject: Re: clock running faster? In-Reply-To: <199510192257.XAA05193@uriah.heep.sax.de> References: <199510191251.WAA16201@godzilla.zeta.org.au> <199510192257.XAA05193@uriah.heep.sax.de> Sender: owner-current@freebsd.org Precedence: bulk < said: > As Bruce Evans wrote: >> >> The changes have the effect of making the Pentium clock the reference. > I don't think this has been a good idea. Please explain your reason for believing this, keeping in mind that a similar technique was used on MicroVAXen in 4.3 (except using microtime() rather than a purpose-built function). -GAWollman -- Garrett A. Wollman | Shashish is simple, it's discreet, it's brief. ... wollman@lcs.mit.edu | Shashish is the bonding of hearts in spite of distance. Opinions not those of| It is a bond more powerful than absence. We like people MIT, LCS, ANA, or NSA| who like Shashish. - Claude McKenzie + Florent Vollant From owner-freebsd-current Fri Oct 20 17:41:28 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id RAA26721 for current-outgoing; Fri, 20 Oct 1995 17:41:28 -0700 Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id RAA26703 for ; Fri, 20 Oct 1995 17:41:18 -0700 Received: from sax.sax.de by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id BAA12363 for ; Sat, 21 Oct 1995 01:39:53 +0100 Received: by sax.sax.de (8.6.11/8.6.12-s1) with UUCP id BAA10820 for freebsd-current@freebsd.org; Sat, 21 Oct 1995 01:39:53 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.6.12/8.6.9) id XAA12519 for freebsd-current@freebsd.org; Fri, 20 Oct 1995 23:17:59 +0100 From: J Wunsch Message-Id: <199510202217.XAA12519@uriah.heep.sax.de> Subject: Re: clock running faster? To: freebsd-current@freebsd.org Date: Fri, 20 Oct 1995 23:17:59 +0100 (MET) Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <9510201426.AA09055@halloran-eldar.lcs.mit.edu> from "Garrett A. Wollman" at Oct 20, 95 10:26:22 am X-Phone: +49-351-2012 669 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 845 Sender: owner-current@freebsd.org Precedence: bulk As Garrett A. Wollman wrote: > > >> The changes have the effect of making the Pentium clock the reference. > > > I don't think this has been a good idea. > > Please explain your reason for believing this, keeping in mind that a > similar technique was used on MicroVAXen in 4.3 (except using > microtime() rather than a purpose-built function). I simply don't trust the PeeCee industry to even bother making the CPU clock an exact frequency. OTOH, they seem to be somewhat eager to keep in spec with the 14.318... MHz clock bas where the timer input is derived from (since otherwise the MSDOG clock would also be wrong). Remember that not all people around do live in NTPland. -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-current Fri Oct 20 18:28:45 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id SAA27800 for current-outgoing; Fri, 20 Oct 1995 18:28:45 -0700 Received: from pelican.com (pelican.com [134.24.4.62]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id SAA27794 for ; Fri, 20 Oct 1995 18:28:41 -0700 Received: from puffin.pelican.com by pelican.com with smtp (Smail3.1.28.1 #5) id m0t6Sjj-000K2qC; Fri, 20 Oct 95 18:28 WET DST Received: by puffin.pelican.com (Smail3.1.29.1 #9) id m0t6Sjh-0000ReC; Fri, 20 Oct 95 18:28 PDT Message-Id: From: pete@puffin.pelican.com (Pete Carah) Subject: syslog curiosity To: current@freebsd.org Date: Fri, 20 Oct 1995 18:28:33 -0700 (PDT) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 874 Sender: owner-current@freebsd.org Precedence: bulk Wondered about our syslog(3); at a first glance (in 'stable') it looks OK but wondered... ----------------------------------------------------------- ============================================================================= CA-95:13 CERT Advisory October 19, 1995 Syslog Vulnerability - A Workaround for Sendmail ----------------------------------------------------------------------------- The CERT Coordination Center has received reports of problems with the syslog(3) subroutine. To the best of our current knowledge, the problem is present in virtually all versions of the UNIX Operating System except the following: Sony's NEWS-OS 6.X SunOS 5.5 (Solaris 2.5) Linux with libc version 4.7.2, released May 1995 ----...... (rest omitted) -- Pete From owner-freebsd-current Fri Oct 20 19:28:11 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id TAA29073 for current-outgoing; Fri, 20 Oct 1995 19:28:11 -0700 Received: from maui.com (langfod@waena.mrtc.maui.com [199.4.33.17]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id TAA29068 for ; Fri, 20 Oct 1995 19:28:08 -0700 Received: (from langfod@localhost) by maui.com (8.6.10/8.6.6) id QAA29982 for current@freebsd.org; Fri, 20 Oct 1995 16:31:57 -1000 From: David Langford Message-Id: <199510210231.QAA29982@ maui.com> Subject: Need to run BSDI2.0 stuff To: current@freebsd.org Date: Fri, 20 Oct 1995 16:31:56 -1000 (HST) X-blank-line: This space intentionaly left blank. X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 552 Sender: owner-current@freebsd.org Precedence: bulk Is there a way to get the BSDI to run 2.0 applications, even at the expense of 1.x applications. This is becoming very very important to some of my customers as more and more companies only ship BSDI binaries in compiled for 2.0. Thanks muchly. -- /--------------------------------------------------------------------\ | David Langford - Kihei, Maui, Hawaii - langfod@maui.com | | Maui Research and Technology Center -- Network Administrator | \--------------------------------------------------------------------/ From owner-freebsd-current Fri Oct 20 22:16:52 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id WAA03853 for current-outgoing; Fri, 20 Oct 1995 22:16:52 -0700 Received: from relay1.UU.NET (relay1.UU.NET [192.48.96.5]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id WAA03845 for ; Fri, 20 Oct 1995 22:16:45 -0700 Received: from ast.com by relay1.UU.NET with SMTP id QQzmjd01551; Sat, 21 Oct 1995 01:16:07 -0400 (EDT) Received: from trsvax.fw.ast.com (fw.ast.com) by ast.com with SMTP id AA01038 (5.67b/IDA-1.5); Fri, 20 Oct 1995 22:17:34 -0700 Received: by trsvax.fw.ast.com (/\=-/\ Smail3.1.18.1 #18.1) id ; Sat, 21 Oct 95 00:10 CDT Received: by nemesis.lonestar.org (Smail3.1.27.1 #19) id m0t6W9B-000IxkC; Sat, 21 Oct 95 00:07 WET DST Message-Id: Date: Sat, 21 Oct 95 00:07 WET DST To: wollman@lcs.mit.edu, joerg_wunsch@uriah.heep.sax.de, freebsd-current@FreeBSD.org From: uhclem%nemesis@fw.ast.com (Frank Durda IV) Sent: Sat Oct 21 1995, 00:07:05 CDT Subject: Re: clock running faster? Sender: owner-current@FreeBSD.org Precedence: bulk [0]As Bruce Evans wrote: [0]The changes have the effect of making the Pentium clock the reference. [1]On Thu, 19 Oct 1995 23:57:17 +0100 (MET), J Wunsch [1]said: [1]I don't think this has been a good idea. [2]"Garrett A. Wollman" then wrote: [2]Please explain your reason for believing this, keeping in mind that a [2]similar technique was used on MicroVAXen in 4.3 (except using [2]microtime() rather than a purpose-built function). Yes, and the VAX 11/780 did this too. But all you had to do was walk up to the console, halt the KL (or whatever the main processor designation was), and type SET CLOCK FAST, and then let the processor continue. Now the 780 is executing instructions about 20% faster than normal, but guess what? Despite having that nice TOD hardware down there, the BSD 4.x system wall time clocks is now running fast, gaining a lot per hour. (VMS used the TOD hardware so this didn't happen when running VMS.) We used to use this extra burst of speed when we really needed some big system build to get done faster. Just halt, change speeds and resume, no need to reboot BSD! Just a slight pause. Of course, everybody would complain about the uptime and TOD clocks not agreeing with wall clocks or with each other so we didn't do it very often. Granted the SET CLOCK FAST command mechanism on the VAX was meant to be used by CEs to detect flaky components that were on the edge of failing, but guess what? Modern PC makers "cheat" on the processor clock too, and don't always advertise the fact. In fact, in this day of one-main-logic-board-fits-all, the processor clock is probably generated by a clock synth chip, that may be allowed to be as much as 5% fast or slow on a given machine AND on a given boot cycle, as the synth speed always starts up at a very slow speed (8 to 20MHz). Crystals are usually a lot tighter on deviation from the marked frequencu, and they hold the same value from one boot to the next, but crystals are becoming far less common on motherboards. Further, I can name several major PC vendors who deliberately program "high" settings into the synth chips so that their machines will perform better in benchmarks, and the systems are sold with these faster values. These values are loaded by the BIOS after POST is complete. Since Intel (and other processor makers) have tested their components clocked at up to 10% faster than the listed value, this 5% increase isn't a problem, particularly if the cooling of the processor is under control. The chip makers don't like it when computer makers do this, and the chip makers will use it an excuse if the computer manufacturer runs into reliability trouble, but this rarely happens. I can even name a couple of Triton-based Intel-built boards out there in the market right now where this trick is done so that Vendor A can say their system is faster than Vendor P, even though they both have the exact same Intel motherboard inside. But this "bit of extra speed" can really mess up time-keeping that is based on processor speed, particularly if events skew the routine or routines that estimate processor speed. This gets worse if the timing routine tries to rationalize its results to "known" processor speeds, such as 33, 50, 66, 75, 90, 100, 120, 133, etc. If the number comes up as 92, the code might simply report 90, and do all the clock math based on 90, which will be wrong. But there are other things that can mess up the estimate. Note that like VMS, DOS and Windows don't do this - they use the system timers and the CMOS clock for TOD duties. Now I will be the first to admit that the 14.31818MHz (4 x NTSC color burst frequency - what a choice) clock that the traditional PC system clock is based from (although a multiple of this is used frequently in newer machines) isn't that easy to work with, at least it is consistent on all PCs, and even a 200ppm error in a given crystal will still be a pretty small drift in the system clock, once you get down to ~18.2/sec or ~100/sec or whatever you have it programmed to. (This clock has to be reasonably accurate or else RS-232 operations will suffer from bit errors.) If a processor "tight loop" with interrupts disabled is used to determine the processor clock speed (I suspect this is the case), such a routine can be fooled by the methods some chipsets use for performing refresh, which instead of being spaced at nice even intervals like was done years ago, now the refresh cycles may come in groups, or are eliminated based on recent Read/Write accesses. These so-called "Smart" refresh managers will completely fool a timing routine, producing one set of values on one motherboard brand machine and a different set of values on a different motherboard model. The results can also vary depending on what memory locations the loop resides in. Keep in mind that nearly 100% of the DRAM out there simply requires that each of the 256 rows be refreshed once every 16msec. There is nothing that says the processor must take that 16msec and divide it by 256, and then refresh one row at even intervals. All 256 rows can be done at once, or at irregular intervals. Since a refresh cycle is simply an incomplete memory read cycle (RAS but no CAS), the act of fetching instructions, reading and writing memory all effectively perform refreshes, but not in a uniform fashion. Old systems made no attempt to take advantage of the fact the processor had accessed given memory rows recently, but many bus control chipsets made since 1990 do, keeping "decay" counters that alert it to when a row needs refreshing, and these counter are reset by the processor accessing that row as part of one of its memory operations, a DMA cycle, or a genuine refresh cycle. This somewhat unpredictable refresh activity could probably explain systems that people boot ten times get ten different processor speed ratings for code that should be running "uninterruptable". This type of computation error could be reduced by greatly increasing the duration of the timing test, but that may not be desirable. Even if you argue that the complete timing test should end up being executed from the processor cache and pipeline, since the full internal workings of the Pentium (or its Pro buddy) are not public, we can't be sure that residual memory writes from earlier operations aren't performed during the actual timing test, or that memory reads for pipeline and cache fills aren't occurring during the test. There isn't any good way to control this without a full internal knowledge of how and when the processor tries to access memory, and what impact DMA and refresh bus grants have on the processor when it is running code already in the processor. And of course, not everybody has Pentiums, and no one except knows if all versions of the Pentium behave the same in this area. Then you have the situation where the CPU clock is not symmetrical and/or a multiple of the ISA bus clock, or of the clock that is used within the ISA chipset for things like timers, interrupt controllers, etc. This difference in timing can cause variable length of wait states to appear when attempting to access hardware registers that are not actually running at the full 66, 90 or whatever MHz speed the CPU is running at. These speed differences can also induce variable latencies in reporting interrupts to the CPU, particularly in systems that serialize IRQs to save on pins on the package. Bottom line, I also agree that estimating CPU speed and using that as the TOD clock is a bad idea. There are just too many variables to make this work well on all of the systems out there. (Ask before SGMLing) Frank Durda IV |"The Knights who say "LETNi" or uhclem%nemesis@fw.ast.com (Fastest Route)| demand... A SEGMENT REGISTER!!!" ...letni!rwsys!nemesis!uhclem |"A what?" ...decvax!fw.ast.com!nemesis!uhclem |"LETNi! LETNi! LETNi!" - 1983 Microsoft, you can add this to your Developer Network CD in exchange for a three-year Level 2 license. From owner-freebsd-current Fri Oct 20 22:43:53 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id WAA04227 for current-outgoing; Fri, 20 Oct 1995 22:43:53 -0700 Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id WAA04222 for ; Fri, 20 Oct 1995 22:43:43 -0700 Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id PAA05176; Sat, 21 Oct 1995 15:42:21 +1000 Date: Sat, 21 Oct 1995 15:42:21 +1000 From: Bruce Evans Message-Id: <199510210542.PAA05176@godzilla.zeta.org.au> To: joerg_wunsch@uriah.heep.sax.de, wollman@lcs.mit.edu Subject: Re: clock running faster? Cc: freebsd-current@FreeBSD.org Sender: owner-current@FreeBSD.org Precedence: bulk >>> The changes have the effect of making the Pentium clock the reference. >> I don't think this has been a good idea. >Please explain your reason for believing this, keeping in mind that a >similar technique was used on MicroVAXen in 4.3 (except using >microtime() rather than a purpose-built function). The 8254 clock, being intended for timekeeping, is perhaps more accurate and/or stable than the system clock. The system clock should be slowed down to save power when the system is not in use... Perhaps apm compensates for this. See apm_default_suspend() and apm_default_resume() in apm.c. Hmm. These routines seem to be buggy. inittodr() has a resolution of 1 second and is called twice for each suspend/resume. There is more jitter for residuals in the counters. The 8254 residual is limited to the (small) maximum count, but if the Pentium clock continues to run while clock interrupts are masked, then its residual is bounded only by the 64 bits in the counter register. This is a problem for settimeofday() too, but then the residuals are limited to what has accumulated since the last clock interrupt. The splsoftclock() in apm_default_suspend() is a bug. splsoftclock() doesn't nest. It sets the pl to the softclock pl, blowing away the previous pl. Masking softclock() is neither necessary for calling microtime() or inittodr() nor sufficient for atomicicity. Bruce From owner-freebsd-current Fri Oct 20 23:31:03 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id XAA04984 for current-outgoing; Fri, 20 Oct 1995 23:31:03 -0700 Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id XAA04979 for ; Fri, 20 Oct 1995 23:30:54 -0700 Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id QAA07072; Sat, 21 Oct 1995 16:23:57 +1000 Date: Sat, 21 Oct 1995 16:23:57 +1000 From: Bruce Evans Message-Id: <199510210623.QAA07072@godzilla.zeta.org.au> To: freebsd-current@FreeBSD.org, joerg_wunsch@uriah.heep.sax.de, uhclem%nemesis@fw.ast.com, wollman@lcs.mit.edu Subject: Re: clock running faster? Sender: owner-current@FreeBSD.org Precedence: bulk >Now I will be the first to admit that the 14.31818MHz (4 x NTSC color burst >frequency - what a choice) clock that the traditional PC system clock is >based from (although a multiple of this is used frequently in newer machines) >isn't that easy to work with, at least it is consistent on all PCs, and >even a 200ppm error in a given crystal will still be a pretty small drift >in the system clock, once you get down to ~18.2/sec or ~100/sec or whatever >you have it programmed to. (This clock has to be reasonably accurate or >else RS-232 operations will suffer from bit errors.) The problem is that the 8254 clock takes about 5 usec to read (at least on 8MHz ISA buses) while the Pentium clock takes only about 7 cycles to read. The 8254 clock could be used as a reference to recalibrate the Pentium clock fairly often, but this would take more programming and be slower. >If a processor "tight loop" with interrupts disabled is used to determine >the processor clock speed (I suspect this is the case), such a routine can >be fooled by the methods some chipsets use for performing refresh, which Nope, it reads the Pentium cycle counter, delays for 1 second, then reads the cycle counter again, then takes the difference in the number of cycles. The possible error causes are: cycle counts: 0 resolution of DELAY(): 20 usec accuracy of DELAY(): same as that of the 8254 clock (worst I've seen is 7 parts in 10000) >Since a refresh cycle is simply an incomplete memory read cycle >(RAS but no CAS), the act of fetching instructions, reading and >writing memory all effectively perform refreshes, but not in a uniform >fashion. Old systems made no attempt to take advantage of the fact >the processor had accessed given memory rows recently, but many bus control >chipsets made since 1990 do, keeping "decay" counters that alert it to >when a row needs refreshing, and these counter are reset by the processor >accessing that row as part of one of its memory operations, a DMA cycle, >or a genuine refresh cycle. Er, Pentiums count their own cycles. The count is perfectly accurate and unaffected by bus activity. Perhaps the clock source is affected by bus activity. >This somewhat unpredictable refresh activity could probably explain >systems that people boot ten times get ten different processor speed >ratings for code that should be running "uninterruptable". The one second delay should be enough to compensate for bus activity. I think the variance is because the power on states are different. >Even if you argue that the complete timing test should end up being >executed from the processor cache and pipeline, since the full internal >workings of the Pentium (or its Pro buddy) are not public, we can't be >sure that residual memory writes from earlier operations aren't performed >during the actual timing test, or that memory reads for pipeline and >cache fills aren't occurring during the test. There isn't any good DELAY(1) executes the same instructions at least 200000 times. I hope the Pentium's pipelines are that long :-). > (Ask before SGMLing) >Frank Durda IV |"The Knights who say "LETNi" >or uhclem%nemesis@fw.ast.com (Fastest Route)| demand... A SEGMENT REGISTER!!!" >...letni!rwsys!nemesis!uhclem |"A what?" >...decvax!fw.ast.com!nemesis!uhclem |"LETNi! LETNi! LETNi!" - 1983 OK, who are the Knights who say "LETNi"? I know what a ******* REGISTER is :-). Bruce From owner-freebsd-current Sat Oct 21 00:10:21 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id AAA05656 for current-outgoing; Sat, 21 Oct 1995 00:10:21 -0700 Received: from time.cdrom.com (time.cdrom.com [192.216.222.226]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id AAA05651 for ; Sat, 21 Oct 1995 00:10:19 -0700 Received: from time.cdrom.com (localhost [127.0.0.1]) by time.cdrom.com (8.6.12/8.6.9) with SMTP id AAA26716; Sat, 21 Oct 1995 00:10:04 -0700 Message-ID: <30889CCC.794BDF32@FreeBSD.org> Date: Sat, 21 Oct 1995 00:10:04 -0700 From: "Jordan K. Hubbard" X-Mailer: Mozilla 2.0b1 (X11; I; FreeBSD 2.1-STABLE i386) MIME-Version: 1.0 To: David Langford CC: current@FreeBSD.org Subject: Re: Need to run BSDI2.0 stuff References: <199510210231.QAA29982@ maui.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.org Precedence: bulk Not that I know of, no. That said, most accounts list it as something that wouldn't be too hard to add support for. Do I hear the sound of a man interested enough to perhaps be willing to work with a group of people in making such support happen? :-) -- Jordan From owner-freebsd-current Sat Oct 21 01:50:15 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id BAA19660 for current-outgoing; Sat, 21 Oct 1995 01:50:15 -0700 Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id BAA19626 for ; Sat, 21 Oct 1995 01:50:08 -0700 Received: from sax.sax.de by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id JAA20023 for ; Sat, 21 Oct 1995 09:50:04 +0100 Received: by sax.sax.de (8.6.11/8.6.12-s1) with UUCP id JAA14264 for freebsd-current@FreeBSD.org; Sat, 21 Oct 1995 09:50:04 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.6.12/8.6.9) id IAA15349 for freebsd-current@FreeBSD.org; Sat, 21 Oct 1995 08:49:47 +0100 From: J Wunsch Message-Id: <199510210749.IAA15349@uriah.heep.sax.de> Subject: Re: clock running faster? To: freebsd-current@FreeBSD.org (FreeBSD-current users) Date: Sat, 21 Oct 1995 08:49:47 +0100 (MET) Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: from "Frank Durda IV" at Oct 21, 95 00:07:00 am X-Phone: +49-351-2012 669 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 548 Sender: owner-current@FreeBSD.org Precedence: bulk As Frank Durda IV wrote: > > In fact, in this day of one-main-logic-board-fits-all, the processor clock > is probably generated by a clock synth chip, ... It is. I've been installing one of these 66/90/100/133/.../180 MHz boards last week. There are three jumpers encoding the CPU clock, next to a 14-pin chip (i forgot the numbers on it), next to the 14.318 MHz crystal generator. -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-current Sat Oct 21 01:50:23 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id BAA19704 for current-outgoing; Sat, 21 Oct 1995 01:50:23 -0700 Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id BAA19659 for ; Sat, 21 Oct 1995 01:50:15 -0700 Received: from sax.sax.de by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id JAA20033 for ; Sat, 21 Oct 1995 09:50:10 +0100 Received: by sax.sax.de (8.6.11/8.6.12-s1) with UUCP id JAA14270 for current@FreeBSD.ORG; Sat, 21 Oct 1995 09:50:09 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.6.12/8.6.9) id JAA15527 for current@FreeBSD.ORG; Sat, 21 Oct 1995 09:34:09 +0100 From: J Wunsch Message-Id: <199510210834.JAA15527@uriah.heep.sax.de> Subject: Re: syslog curiosity To: current@FreeBSD.ORG Date: Sat, 21 Oct 1995 09:34:09 +0100 (MET) Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: from "Pete Carah" at Oct 20, 95 06:28:33 pm X-Phone: +49-351-2012 669 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 484 Sender: owner-current@FreeBSD.ORG Precedence: bulk As Pete Carah wrote: > > Wondered about our syslog(3); at a first glance (in 'stable') it looks OK > but wondered... > To the best of our current knowledge, the problem is > present in virtually all versions of the UNIX Operating System except the > following: We didn't release an official version with the fix yet. -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-current Sat Oct 21 01:50:20 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id BAA19680 for current-outgoing; Sat, 21 Oct 1995 01:50:20 -0700 Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id BAA19653 for ; Sat, 21 Oct 1995 01:50:12 -0700 Received: from sax.sax.de by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id JAA20005 for ; Sat, 21 Oct 1995 09:50:02 +0100 Received: by sax.sax.de (8.6.11/8.6.12-s1) with UUCP id JAA14263 for freebsd-current@FreeBSD.org; Sat, 21 Oct 1995 09:50:02 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.6.12/8.6.9) id IAA15335 for freebsd-current@FreeBSD.org; Sat, 21 Oct 1995 08:47:28 +0100 From: J Wunsch Message-Id: <199510210747.IAA15335@uriah.heep.sax.de> Subject: Re: clock running faster? To: freebsd-current@FreeBSD.org Date: Sat, 21 Oct 1995 08:47:28 +0100 (MET) Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199510210623.QAA07072@godzilla.zeta.org.au> from "Bruce Evans" at Oct 21, 95 04:23:57 pm X-Phone: +49-351-2012 669 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 551 Sender: owner-current@FreeBSD.org Precedence: bulk As Bruce Evans wrote: > > The problem is that the 8254 clock takes about 5 usec to read (at least on > 8MHz ISA buses) while the Pentium clock takes only about 7 cycles to read. > The 8254 clock could be used as a reference to recalibrate the Pentium > clock fairly often, but this would take more programming and be slower. What about people who are playing with their "Turbo" key? :-] -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-current Sat Oct 21 05:46:10 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id FAA01015 for current-outgoing; Sat, 21 Oct 1995 05:46:10 -0700 Received: from cyclops (xtwa15.ess.harris.com [130.41.26.174]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id FAA01010 for ; Sat, 21 Oct 1995 05:46:06 -0700 Received: (from jleppek@localhost) by cyclops (8.6.12/8.6.9) id IAA04827; Sat, 21 Oct 1995 08:52:08 -0400 Date: Sat, 21 Oct 1995 08:52:08 -0400 From: Jim Leppek Message-Id: <199510211252.IAA04827@cyclops> To: freebsd-current@freefall.FreeBSD.org Subject: patch to fix ranlib Sender: owner-current@FreeBSD.org Precedence: bulk ranlib does not work for odd length extended names. I sent in some mail with the patch a while ago but I have not heard anything. could someone else check this and commit this patch. You can test this by creating any odd length named object over 16chars ie. obj_with_a_long_nam.o ar cr test.a obj_with_a_long_nam.o ranlib test.a will fail with inappropriate file type apply this patch and things will work: *** build.c.orig Sat Oct 21 08:46:14 1995 --- build.c Sat Oct 21 08:47:44 1995 *************** *** 103,109 **** /* Copy the saved objects into the archive. */ size = lseek(tfd, (off_t)0, SEEK_CUR); (void)lseek(tfd, (off_t)0, SEEK_SET); ! SETCF(tfd, tname, afd, archive, RPAD|WPAD); copy_ar(&cf, size); (void)ftruncate(afd, lseek(afd, (off_t)0, SEEK_CUR)); (void)close(tfd); --- 103,109 ---- /* Copy the saved objects into the archive. */ size = lseek(tfd, (off_t)0, SEEK_CUR); (void)lseek(tfd, (off_t)0, SEEK_SET); ! SETCF(tfd, tname, afd, archive, WPAD); copy_ar(&cf, size); (void)ftruncate(afd, lseek(afd, (off_t)0, SEEK_CUR)); (void)close(tfd); From owner-freebsd-current Sat Oct 21 15:49:37 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id PAA15687 for current-outgoing; Sat, 21 Oct 1995 15:49:37 -0700 Received: from localhost.cdrom.com (localhost.cdrom.com [127.0.0.1]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id PAA15682 ; Sat, 21 Oct 1995 15:49:34 -0700 X-Authentication-Warning: freefall.freebsd.org: Host localhost.cdrom.com didn't use HELO protocol To: terry@lambert.org cc: current@freebsd.org Subject: fs layering pathces doesn't work. MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <15679.814315773.1@freefall.freebsd.org> Date: Sat, 21 Oct 1995 15:49:34 -0700 Message-ID: <15680.814315774@freefall.freebsd.org> From: Poul-Henning Kamp Sender: owner-current@freebsd.org Precedence: bulk Hi Terry, I have tried your fs_layering stuff again, and they still doesn't work for me. Here's what I did: I checked out a -current /sys. applied the two files from freefall:~terry config -g'ed this file: (Notice: No NFS (and not as a LKM either :-), No DIAGNOSTICS, as I have already told you several times, though you don't seem to want to listen :-) machine "i386" cpu "I386_CPU" cpu "I486_CPU" cpu "I586_CPU" ident FEMMER maxusers 10 options DDB options INET #InterNETworking options FFS #Berkeley Fast Filesystem options PROCFS #Process filesystem options "COMPAT_43" #Compatible with BSD 4.3 options UCONSOLE #Allow users to grab the console config kernel root on wd0 controller isa0 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 controller ahc0 controller scbus0 device sd0 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 irq 4 vector siointr device sio1 at isa? port "IO_COM2" tty irq 3 vector siointr options "COM_MULTIPORT" device sio4 at isa? port 0x2a0 tty flags 0x705 device sio5 at isa? port 0x2a8 tty flags 0x705 device sio6 at isa? port 0x2b0 tty flags 0x705 device sio7 at isa? port 0x2b8 tty flags 0x705 irq 15 vector siointr device lpt0 at isa? port? tty irq 7 vector lptintr device de0 pseudo-device loop pseudo-device ether pseudo-device log pseudo-device vn pseudo-device pty 16 pseudo-device gzip # Exec gzipped a.out's and rebooted. The mount problem seems gone... I logged in as root cd /usr/src cvs update -P -d -q (4 lines of output or so) panic: free: multiple frees db> trace _Debugger(bla bla bla) _panic(bla bla bla) _free(bla bla bla) _nameifree(bla bla bla) mkdir(bla bla bla) at _mkdir_0x19c _syscall(bla bla bla) cd /a/fs_layer/sys find . -name '*.[ch]' -type f -print | xargs grep -i 'free.*cn_pnbuf' ./kern/vfs_lookup.c: free(cnp->cn_pnbuf, M_NAMEI); ./kern/vfs_lookup.c: FREE(cnp->cn_pnbuf, M_NAMEI); ./kern/vfs_lookup.c: FREE(cnp->cn_pnbuf, M_NAMEI); ./kern/vfs_lookup.c: FREE(cnp->cn_pnbuf, M_NAMEI); ./kern/vfs_lookup.c: FREE(cnp->cn_pnbuf, M_NAMEI); ./kern/vfs_lookup.c: FREE(cnp->cn_pnbuf, M_NAMEI); ./miscfs/devfs/devfs_vnops.c: FREE(ap->a_cnp->cn_pnbuf, M_NAMEI); ./miscfs/union/union_subr.c: free(cn.cn_pnbuf, M_NAMEI); ./miscfs/union/union_subr.c: free(cn.cn_pnbuf, M_NAMEI); ./nfs/nfs_subs.c: FREE(cnp->cn_pnbuf, M_NAMEI); ./nfs/nfs_subs.c: FREE(cnp->cn_pnbuf, M_NAMEI); ./ufs/ufs/ufs_vnops.c: FREE(cnp->cn_pnbuf, M_NAMEI); ./ufs/ufs/ufs_vnops.c: free(cnp->cn_pnbuf, M_NAMEI); ./ufs/ufs/ufs_vnops.c: FREE(cnp->cn_pnbuf, M_NAMEI); Hope you can find it from this. I don't give you too high ratings for the regression testing you claim to have done though... :-) Poul-Henning From owner-freebsd-current Sat Oct 21 20:11:03 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id UAA22809 for current-outgoing; Sat, 21 Oct 1995 20:11:03 -0700 Received: from relay3.UU.NET (relay3.UU.NET [192.48.96.8]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id UAA22799 for ; Sat, 21 Oct 1995 20:10:59 -0700 Received: from ast.com by relay3.UU.NET with SMTP id QQzmmm20256; Sat, 21 Oct 1995 23:10:56 -0400 (EDT) Received: from trsvax.fw.ast.com (fw.ast.com) by ast.com with SMTP id AA05417 (5.67b/IDA-1.5); Sat, 21 Oct 1995 20:12:31 -0700 Received: by trsvax.fw.ast.com (/\=-/\ Smail3.1.18.1 #18.1) id ; Sat, 21 Oct 95 22:07 CDT Received: by nemesis.lonestar.org (Smail3.1.27.1 #19) id m0t6qiL-000IscC; Sat, 21 Oct 95 22:04 WET DST Message-Id: Date: Sat, 21 Oct 95 22:04 WET DST To: j@uriah.heep.sax.de, freebsd-current@FreeBSD.org From: uhclem@nemesis.lonestar.org (Frank Durda IV) Sent: Sat Oct 21 1995, 22:04:44 CDT Subject: Re: clock running faster? Cc: uhclem@nemesis.lonestar.org Sender: owner-current@FreeBSD.org Precedence: bulk [3]As Frank Durda IV wrote: [3] [3]In fact, in this day of one-main-logic-board-fits-all, the processor clock [3]is probably generated by a clock synth chip, ... [4]joerg_wunsch@uriah.heep.sax.de spake: [4]It is. I've been installing one of these 66/90/100/133/.../180 MHz [4]boards last week. There are three jumpers encoding the CPU clock, [4]next to a 14-pin chip (i forgot the numbers on it), next to the 14.318 [4]MHz crystal generator. I rest my case. That 14.31818MHz crystal is used to drive the 8254, or whatever lies buried in the modern integrated system chip set that pretends to be a 8254 (as far as command set and function goes, but not necessarily in the timing department). In addition to not being consistent in produced clock or accurate, the synth clock may also be slowed-down deliberately as part of the EPA power management stuff when the system is idle, thus slowing but not stopping the CPU. Some of this is done by the chipset and not the BIOS, particularly in laptops, so FreeBSD would be affected. However the 8254 continues running on its rock-solid 14.31818MHz clock. Frank Durda IV |"While we stand around arguing or uhclem%nemesis@fw.ast.com (Fastest Route)| over what color the wheel should ...letni!rwsys!nemesis!uhclem | be, Bill is getting richer." ...decvax!fw.ast.com!nemesis!uhclem | From owner-freebsd-current Sat Oct 21 20:26:03 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id UAA23128 for current-outgoing; Sat, 21 Oct 1995 20:26:03 -0700 Received: from relay3.UU.NET (relay3.UU.NET [192.48.96.8]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id UAA23123 for ; Sat, 21 Oct 1995 20:25:58 -0700 Received: from ast.com by relay3.UU.NET with SMTP id QQzmmn21537; Sat, 21 Oct 1995 23:25:53 -0400 (EDT) Received: from trsvax.fw.ast.com (fw.ast.com) by ast.com with SMTP id AA05470 (5.67b/IDA-1.5 for ); Sat, 21 Oct 1995 20:27:28 -0700 Received: by trsvax.fw.ast.com (/\=-/\ Smail3.1.18.1 #18.1) id ; Sat, 21 Oct 95 22:23 CDT Received: by nemesis.lonestar.org (Smail3.1.27.1 #19) id m0t6qmU-000IscC; Sat, 21 Oct 95 22:09 WET DST Message-Id: Date: Sat, 21 Oct 95 22:09 WET DST To: current@freebsd.org From: uhclem@nemesis.lonestar.org (Frank Durda IV) Sent: Sat Oct 21 1995, 22:09:02 CDT Subject: Re: clock running faster? Sender: owner-current@freebsd.org Precedence: bulk [3]If a processor "tight loop" with interrupts disabled is used to determine [3]the processor clock speed (I suspect this is the case), such a routine can [3]be fooled by the methods some chipsets use for performing refresh, which [4]Nope, it reads the Pentium cycle counter, delays for 1 second, then reads [4]the cycle counter again, then takes the difference in the number of cycles. [4]The possible error causes are: [4] [4] cycle counts: 0 [4] resolution of DELAY(): 20 usec [4] accuracy of DELAY(): same as that of the 8254 clock [4] (worst I've seen is 7 parts in 10000) Understood, but you still can't guarantee what the processor is doing. The cycle counter may count "execution cycles" instead of "total cycles", thus not counting cycles spent on housekeeping operations, such as bus grants and bus recoveries. Now I know the answers to a few of these questions, having been allowed to gaze at the infamous Appendix a few years ago, but I can't say exactly what is going on here, nor can I be sure that Intel bothered with such minor details in that document. So just because they didn't mention it there doesn't mean they aren't doing it. We used to discover things all the time and go to Intel and they would say "yeah, it does that" or "yeah, but the next stepping fixes that". Let's just say that I am hinting that this isn't an accurate method across all of the Pentium line... Only an external logic analyzer can give mortals a truthful answer to this question, but then the answer would be correct for only a single stepping of the Pentium, as I know they have changed timing around, particularly in the laptop versions of the chip. Also, don't forget that you really don't have a 8254 anymore. The ISA chipset makers have long abandoned attempting to exactly mimic the timing oddities of a real 8254. There isn't a 8254 megacell in there, so all the timing charts in the 8254 databook are useless on modern designs. Unless you see a discrete part on the board that says 8254, and you are using an 80486 or higher design, you don't have a real 8254. The last chipset with a "real" licensed 8254 megacell was the Chips and Technology '206 chip (also licensed by Siemens), which was meant for 286 systems, but also got pasted into some low-end 386 systems. The same thing is true of the 8237. The megacells don't run the DMA at a speed under 5MHz, which is what a real 8237-5 (fastest speed ever produced) would do. These megacell DMAs run at 8.33MHz or sometimes 10MHz, plus they frequently don't have set-up and tear-down cycles between CPU and DMA bus acquisition. Each chipset is different in this area. The newer DMA systems even cover the deadly embrace that could be generated between a real 8237 and a 80x86 processor. It could not happen between a 8237 and a 8085 (these two parts were designed for each other), but that is what you get when IBM used 8-bit parts for their 16-bit system. So, the only timing for these subsystems that you can believe comes from the chipset makers databook for that one chipset. [4]DELAY(1) executes the same instructions at least 200000 times. I hope [4]the Pentium's pipelines are that long :-). It depends on how much of the cache the Pentium decide to load in for instructions that follow the delay loop while the loop is being timed. Pentium does look-thru (it looks through absolute and conditional jumps) pipeline loading, plus matching and spectulative cache loading, plus delayed memory writes. You might find that having two separate loops near one another will yield more accurate results. The first loop can be very small, on the order of (let me see) 1176 loops. This will guarantee any delayed writes (memory or I/O) have completed before your primary loop begins. Jump to the second loop using a CONDITIONAL opcode that can never fail, eg jz xyz when Z is always true when you arrive. Then your second loop should be followed by a branch into a small amount of code located between the first loop and second loop. This will guarantee that the clean-up code is already in cache (make it small) and then you can jump out of the twisty passages to the main stream of code. It looks nasty but will reduce the artifacts. Based on what I know, even the above tricks won't eliminate the issue. Perhaps a kernel -c parameter should allow the user to override clock timing selection, so they can choose the more accurate method for their system. On the Tandy XENIX systems, the TOD clock was based on video vertical sync timing, and wasn't very accurate, almost always fast. Subsequently the kernel had a routine added that the user could configure that could bump the clock forward a bit and back a bit at regular intervals to make things come out OK. All you had to do is set the system clock exactly right and at least two hours later run a utility and tell it what the wall clock was at that instant. The routine would spit out a pair of values for the kernel to use to compensate for drift (big jog and little jog, they could point in alternate directions and be applied at different points in time). The system TOD would be set to what you just told it, then you would go away for at least two hours (overnight was fine) and repeat the process. By now the clock value was pretty close, and the drift would be a second or two a week, instead of two minutes in a day. [3]Frank Durda IV |"The Knights who say "LETNi" [3]or uhclem%nemesis@fw.ast.com t Route)| demand... A SEGMENT REGISTER!!!" [3]...letni!rwsys!nemesis!uhclem |"A what?" [3]...decvax!fw.ast.com!nemesis! |"LETNi! LETNi! LETNi!" - 1983 [4]OK, who are the Knights who say "LETNi"? I know what a [4]******* REGISTER is :-). Ok, back in 1983 when I and others got suckered into bringing out the first computer based on the Intels latest and greatest 80186 processor, I wrote a script that was a take-off on "The Knights who say Ni" from Monty Python and the Holy Grail. What is "LETNi"? What is "LETNi" backwards? That used to be their logo. I thought of it after coming from sane and rational processor designs, suddenly having to deal with everything being backwards (indian among other things), plus these stupid segments. What a kludge. The script was published far and wide on the net (as it was back then) and several computers around the world adopted the name "letni" as their system name based on that script. See "letni.UUCP" or "letni.lonestar.org" as an example. I even got letters from engineers at Intel who enjoyed the joke, saying it went right over the heads of their management, so it could remain posted on walls for weeks without being distrubed. There was even a system somewhere at Intel called "letni", but I don't know if it is still there. The script closely follows the Monty Python sketch, right up to the point where some 80186-equivalent impossible task is demanded as in the original "You must cut down a the mightiest tree in the forest with.... a herring!". I think it had something to with doing a rep move string with a segment override and interrupts enabled, which is possible but unbelievably dangerous. Frank Durda IV |"The Knights who say "LETNi" or uhclem%nemesis@fw.ast.com (Fastest Route)| demand... A SEGMENT REGISTER!!!" ...letni!rwsys!nemesis!uhclem |"A what?" ...decvax!fw.ast.com!nemesis!uhclem |"LETNi! LETNi! LETNi!" - 1983 From owner-freebsd-current Sat Oct 21 23:12:17 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id XAA26297 for current-outgoing; Sat, 21 Oct 1995 23:12:17 -0700 Received: from kitten.mcs.com (Kitten.mcs.com [192.160.127.90]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id XAA26292 for ; Sat, 21 Oct 1995 23:12:15 -0700 Received: from mailbox.mcs.com (Mailbox.mcs.com [192.160.127.87]) by kitten.mcs.com (8.6.10/8.6.9) with SMTP id BAA24938 for ; Sun, 22 Oct 1995 01:12:13 -0500 Received: by mailbox.mcs.com (/\==/\ Smail3.1.28.1 #28.5) id ; Sun, 22 Oct 95 01:12 CDT Received: by mercury.mcs.com (/\==/\ Smail3.1.28.1 #28.5) id ; Sun, 22 Oct 95 01:12 CDT Message-Id: Subject: ordering of isa_devtab_tty important? To: current@freebsd.org Date: Sun, 22 Oct 1995 01:12:12 -0500 (CDT) From: "Lars Fredriksen" X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 1693 Sender: owner-current@freebsd.org Precedence: bulk Hi, Just upgraded my current kernel on Friday(Oct 20), and found that the kernel I produced would no longer boot. I have been using the same config file for about a year now, so I didn't figure that had something to do with it(suspected a bad source tree on my end). However, when I managed to boot a GENERIC kernel build from the same source tree I figured that there had to be something with my config file that caused the problem. What I found was that I had configured the mse device on the line above the sc device which in turn made the mse device the first entry in the isa_devtab_tty[] table. When I switched the two lines, the kernel came up just fine. So the question is what is the NEW assumption made about the first isa_devtab_tty[] entry. I figure it might have something to do with the serial console stuff(I don't have it enabled). I'll keep looking to see if I can't pinpoint the problem further. Also in light of what I experienced it would seem wise (if this has something to do with the console selection stuff, that the lpt and mse devices no longer be tty types. Just for your information. The symptom of my non-booting kernel was that as soon as the cart-wheel stopped spinning, my modem lights would indicate TX/RX, my floppy would start to twirl and the hard drives would be accessed a couple of times. Some time the screen would go black and the come back as it normally does, however you never saw the version[] getting printed nor any of the device probe messages. Lars -- ------------------------------------------------------------------- Lars Fredriksen fredriks@mcs.com (home) lars@fredriks.pr.mcs.net (home-home) fredriks@asiago.cs.wisc.edu