From owner-freebsd-current Sun Jun 15 01:03:14 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id BAA01798 for current-outgoing; Sun, 15 Jun 1997 01:03:14 -0700 (PDT) Received: from peeper.my.domain ([208.128.8.126]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id BAA01793 for ; Sun, 15 Jun 1997 01:03:10 -0700 (PDT) Received: (from tom@localhost) by peeper.my.domain (8.8.5/8.7.3) id AAA00937; Sun, 15 Jun 1997 00:52:48 -0500 (CDT) Message-ID: <19970615005248.35678@peeper.my.domain> Date: Sun, 15 Jun 1997 00:52:48 -0500 From: Tom Jackson To: Richard Wackerbarth Cc: freebsd-current@freebsd.org Subject: Re: CTM src-cur.2896 is missing References: <199706150014.GAA20974@hq.icb.chel.su> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.76e In-Reply-To: ; from Richard Wackerbarth on Sat, Jun 14, 1997 at 07:42:56PM -0500 Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk hey there Richard Thanks for all the hard work your putting into ctm. I may have a wire crossed, but ports-current.1888.gz seems to not work. It mentions a INDEX file at /usr/ports, which I don't have and then dies. Looking at the file with zmore, shows a lot of `|'s that I haven't seen in other ctm's. Correct me if I'm wrong, in any case, do you have any suggestions? Tom From owner-freebsd-current Sun Jun 15 08:15:43 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id IAA13318 for current-outgoing; Sun, 15 Jun 1997 08:15:43 -0700 (PDT) Received: from mail0.iij.ad.jp (mail0.iij.ad.jp [202.232.2.113]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id IAA13309 for ; Sun, 15 Jun 1997 08:15:40 -0700 (PDT) Received: from uucp2.iij.ad.jp (uucp2.iij.ad.jp [202.232.2.202]) by mail0.iij.ad.jp (8.8.5+2.7Wbeta5/3.5Wpl4-MAIL) with SMTP id AAA25447 for ; Mon, 16 Jun 1997 00:15:32 +0900 (JST) Received: (from uucp@localhost) by uucp2.iij.ad.jp (8.6.12+2.4W/3.3W9-UUCP) with UUCP id AAA24746 for current@freebsd.org; Mon, 16 Jun 1997 00:15:32 +0900 Received: from tyd1.tydfam.iijnet.or.jp (tyd1.tydfam.iijnet.or.jp [192.168.1.2]) by tydfam.iijnet.or.jp (8.8.5/3.4W2-uucp) with ESMTP id XAA10167 for ; Sun, 15 Jun 1997 23:26:40 +0900 (JST) Received: from localhost.tydfam.iijnet.or.jp (localhost.tydfam.iijnet.or.jp [127.0.0.1]) by tyd1.tydfam.iijnet.or.jp (8.8.5/3.4Wnomx) with SMTP id XAA09376 for ; Sun, 15 Jun 1997 23:26:39 +0900 (JST) Message-Id: <199706151426.XAA09376@tyd1.tydfam.iijnet.or.jp> X-Authentication-Warning: tyd1.tydfam.iijnet.or.jp: localhost.tydfam.iijnet.or.jp [127.0.0.1] didn't use HELO protocol To: current@freebsd.org Subject: Q) Hylafax v4.0pl1 Reply-To: ken@tydfam.iijnet.or.jp X-Mailer: Mew version 1.70 on Emacs 19.34.2 / Mule 2.3 Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-2022-jp Content-Transfer-Encoding: 7bit Date: Sun, 15 Jun 1997 23:26:39 +0900 From: Takeshi Yamada Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I recently installed hylafax v4.0pl1 successfully to my FreeBSD- current (ca. 06/10/97). However, "faxmail" which is supposed to convert my MIME e-mail into fax does not work. With the MIME message, 'faxmail' went into infinit loop. Is it because of MIME format, or because of 'faxmail'? A part of MIME e-mail and faxmail -v stderr message were as below. ======== MIME Mail sent to 'faxmail' =============== >From ken@tyd1.tydfam.iijnet.or.jp Sun Jun 15 12:06:44 1997 Message-Id: <199706150306.MAA24910@tyd1.tydfam.iijnet.or.jp> To: 0354346187@fax Subject: Forward: Test =?ISO-2022-JP?B?GyRCJEYkOSRIISIbKEI=?= Test Test Reply-To: ken@tydfam.iijnet.or.jp X-Mailer: Mew version 1.70 on Emacs 19.34.2 / Mule 2.3 Mime-Version: 1.0 Content-Type: Multipart/Mixed; boundary="--Next_Part(Sun_Jun_15_12:06:40_1997)--" Content-Transfer-Encoding: 7bit Date: Sun, 15 Jun 1997 12:06:42 +0900 From: Takeshi Yamada ----Next_Part(Sun_Jun_15_12:06:40_1997)-- Content-Type: Message/Rfc822 Content-Transfer-Encoding: 7bit To: 0354346187@fax Subject: Test =?ISO-2022-JP?B?GyRCJEYkOSRIISIbKEI=?= Test Test Reply-To: ken@tydfam.iijnet.or.jp X-Mailer: Mew version 1.70 on Emacs 19.34.2 / Mule 2.3 Mime-Version: 1.0 Content-Type: Multipart/Mixed; boundary="--Next_Part(Sun_Jun_15_11:46:35_1997)--" Content-Transfer-Encoding: 7bit Date: Sun, 15 Jun 1997 11:46:42 +0900 From: Takeshi Yamada ----Next_Part(Sun_Jun_15_11:46:35_1997)-- Content-Type: Text/Plain; charset=iso-2022-jp Content-Transfer-Encoding: 7bit This is a test message. This is a test message. $B$3$l$O;n83%a%C%;!<%8$G$9!#(B $B$3$l$O;n83%a%C%;!<%8$G$9!#(B $B$3$l$O;n83%a%C%;!<%8$G$9!#(B ----Next_Part(Sun_Jun_15_11:46:35_1997)-- Content-Type: Application/Postscript Content-Transfer-Encoding: quoted-printable %!PS-Adobe-2.0 EPSF-1.2 %%Creator: Adobe Illustrator(TM) 1.2d4 %%For: OpenWindows Version 2 %%Title: tiger.eps %%CreationDate: 4/12/90 3:20 AM %%DocumentProcSets: Adobe_Illustrator_1.2d1 0 0 %%DocumentSuppliedProcSets: Adobe_Illustrator_1.2d1 0 0 %%BoundingBox: 22 171 567 738 %%EndComments %%BeginProcSet:Adobe_Illustrator_1.2d1 0 0 /Adobe_Illustrator_1.2d1 dup 100 dict def load begin : : : : : : : : : : showpage %%Trailer ----Next_Part(Sun_Jun_15_11:46:35_1997)---- ----Next_Part(Sun_Jun_15_12:06:40_1997)---- ========= "cat mail | faxmail -v" =============== HEADER From ken@tyd1.tydfam.iijnet.or.jp Sun Jun 15 12: 06:44 1997 HEADER Message-Id: <199706150306.MAA24910@tyd1.tydfam.iijnet.or.jp> HEADER To: 0354346187@fax HEADER Subject: Forward: Test =?ISO-2022-JP?B?GyRCJEYkOSRIISIbKEI=?= Test Test HEADER Reply-To: ken@tydfam.iijnet.or.jp HEADER X-Mailer: Mew version 1.70 on Emacs 19.34.2 / Mule 2.3 HEADER Mime-Version: 1.0 HEADER Content-Type: Multipart/Mixed; +HEADER Content-Type: boundary="--Next_Part(Sun_Jun_15_12:06:40_1997)--" HEADER Content-Transfer-Encoding: 7bit HEADER Date: Sun, 15 Jun 1997 12:06:42 +0900 HEADER From: Takeshi Yamada Font Courier: /usr/local/lib/afm/Courier: Can not open font metrics file; using fixed widths. Font Helvetica-Bold: /usr/local/lib/afm/Helvetica-Bold: Can not open font metrics file; using fixed widths. Font Helvetica-Oblique: /usr/local/lib/afm/Helvetica-Oblique: Can not open font metrics file; using fixed widths. MIME part (line 17): multipart/mixed charset=us-ascii encoding=7bit HEADER Content-Type: Message/Rfc822 HEADER Content-Transfer-Encoding: 7bit MIME part (line 21): message/rfc822 charset=us-ascii encoding=7bit HEADER To: 0354346187@fax HEADER Subject: Test =?ISO-2022-JP?B?GyRCJEYkOSRIISIbKEI=?= Test Test HEADER Reply-To: ken@tydfam.iijnet.or.jp HEADER X-Mailer: Mew version 1.70 on Emacs 19.34.2 / Mule 2.3 HEADER Mime-Version: 1.0 HEADER Content-Type: Multipart/Mixed; +HEADER Content-Type: boundary="--Next_Part(Sun_Jun_15_11:46:35_1997)--" HEADER Content-Transfer-Encoding: 7bit HEADER Date: Sun, 15 Jun 1997 11:46:42 +0900 HEADER From: Takeshi Yamada MIME part (line 32): message/rfc822 charset=us-ascii encoding=7bit HEADER ----Next_Part(Sun_Jun_15_11: 46:35_1997)-- HEADER Content-Type: Text/Plain; charset=iso-2022-jp HEADER Content-Transfer-Encoding: 7bit MIME part (line 36): message/rfc822 charset=us-ascii encoding=7bit MIME part (line 42): message/rfc822 charset=us-ascii encoding=7bit HEADER ----Next_Part(Sun_Jun_15_11: 46:35_1997)-- HEADER Content-Type: Application/Postscript HEADER Content-Transfer-Encoding: quoted-printable MIME part (line 46): message/rfc822 charset=us-ascii encoding=7bit HEADER %%Creator: Adobe Illustrator(TM) 1.2d4 HEADER %%For: OpenWindows Version 2 HEADER %%Title: tiger.eps HEADER %%CreationDate: 4/12/90 3:20 AM HEADER %%DocumentProcSets: Adobe_Illustrator_1.2d1 0 0 HEADER %%DocumentSuppliedProcSets: Adobe_Illustrator_1.2d1 0 0 HEADER %%BoundingBox: 22 171 567 738 MIME part (line 56): message/rfc822 charset=us-ascii encoding=7bit HEADER %%BeginProcSet: Adobe_Illustrator_1.2d1 0 0 MIME part (line 58): message/rfc822 charset=us-ascii encoding=7bit +HEADER /_k /setcmybcolor where {: /setcmybcolor get +HEADER } {: { 1 sub 4 1 roll _K _K _K setrgbcolor pop } bind MIME part (line 106): message/rfc822 charset=us-ascii encoding=7bit HEADER %%Page: 1 1 MIME part (line 108): message/rfc822 charset=us-ascii encoding=7bit MIME part (line 110): message/rfc822 charset=us-ascii encoding=7bit MIME part (line 115): message/rfc822 charset=us-ascii encoding=7bit MIME part (line 125): message/rfc822 charset=us-ascii encoding=7bit MIME part (line 2776): message/rfc822 charset=us-ascii encoding=7bit MIME part (line 2778): message/rfc822 charset=us-ascii encoding=7bit MIME part (line 2780): message/rfc822 charset=us-ascii encoding=7bit HEADER ----Next_Part(Sun_Jun_15_11: 46:35_1997)---- MIME part (line 2782): message/rfc822 charset=us-ascii encoding=7bit HEADER ----Next_Part(Sun_Jun_15_12: 06:40_1997)---- MIME part (line 2783): message/rfc822 charset=us-ascii encoding=7bit : : : : : MIME part (line 2783): message/rfc822 charset=us-ascii encoding=7bit : : : : : MIME part (line 2783): message/rfc822 charset=us-ascii encoding=7bit From owner-freebsd-current Sun Jun 15 14:03:43 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id OAA25812 for current-outgoing; Sun, 15 Jun 1997 14:03:43 -0700 (PDT) Received: from peeper.my.domain ([208.128.8.154]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id OAA25797 for ; Sun, 15 Jun 1997 14:03:31 -0700 (PDT) Received: (from tom@localhost) by peeper.my.domain (8.8.5/8.7.3) id IAA03981; Sun, 15 Jun 1997 08:33:38 -0500 (CDT) Message-ID: <19970615083337.39245@peeper.my.domain> Date: Sun, 15 Jun 1997 08:33:37 -0500 From: Tom Jackson To: Richard Wackerbarth Cc: freebsd-current@FreeBSD.ORG Subject: Re: CTM src-cur.2896 is missing References: <199706150014.GAA20974@hq.icb.chel.su> <19970615005248.35678@peeper.my.domain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.76e In-Reply-To: <19970615005248.35678@peeper.my.domain>; from Tom Jackson on Sun, Jun 15, 1997 at 12:52:48AM -0500 Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Sun, Jun 15, 1997 at 12:52:48AM -0500, Tom Jackson wrote: > hey there Richard > > Thanks for all the hard work your putting into ctm. > > I may have a wire crossed, but ports-current.1888.gz seems to not work. It > mentions a INDEX file at /usr/ports, which I don't have and then dies. > Looking at the file with zmore, shows a lot of `|'s that I haven't seen in > other ctm's. > > Correct me if I'm wrong, in any case, do you have any suggestions? > > Tom Ahh ... as plenty have said Oops Moving some file systems around, trying shoehorn everything into my three scsi's and somehow (hmm) deleted the above mentioned file. Found it everything is at peace again Sorry for the noise Tom From owner-freebsd-current Sun Jun 15 17:49:25 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id RAA03695 for current-outgoing; Sun, 15 Jun 1997 17:49:25 -0700 (PDT) Received: from dyson.iquest.net (dyson.iquest.net [198.70.144.127]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id RAA03690 for ; Sun, 15 Jun 1997 17:49:22 -0700 (PDT) Received: (from root@localhost) by dyson.iquest.net (8.8.5/8.8.5) id TAA00160 for current@freebsd.org; Sun, 15 Jun 1997 19:49:05 -0500 (EST) From: "John S. Dyson" Message-Id: <199706160049.TAA00160@dyson.iquest.net> Subject: Need to rebuild libkvm,ps,w To: current@freebsd.org Date: Sun, 15 Jun 1997 19:49:05 -0500 (EST) Reply-To: dyson@freebsd.org X-Mailer: ELM [version 2.4ME+ PL31 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk The proc data structure has changed, so you'll need to rebuild the various utilities that normally break when it changes. John From owner-freebsd-current Sun Jun 15 18:20:29 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id SAA06682 for current-outgoing; Sun, 15 Jun 1997 18:20:29 -0700 (PDT) Received: from rah.star-gate.com (rah.star-gate.com [204.188.121.18]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id SAA06676; Sun, 15 Jun 1997 18:20:22 -0700 (PDT) Received: from rah.star-gate.com (localhost.star-gate.com [127.0.0.1]) by rah.star-gate.com (8.8.5/8.8.5) with ESMTP id SAA07208; Sun, 15 Jun 1997 18:20:21 -0700 (PDT) Message-Id: <199706160120.SAA07208@rah.star-gate.com> X-Mailer: exmh version 1.6.9 8/22/96 To: dyson@FreeBSD.ORG cc: current@FreeBSD.ORG Subject: Re: Need to rebuild libkvm,ps,w In-reply-to: Your message of "Sun, 15 Jun 1997 19:49:05 CDT." <199706160049.TAA00160@dyson.iquest.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 15 Jun 1997 18:20:21 -0700 From: Amancio Hasty Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Dumb question, why can't we isolate the apps from the proc data structures? Amancio >From The Desk Of "John S. Dyson" : > The proc data structure has changed, so you'll need to rebuild > the various utilities that normally break when it changes. > > John From owner-freebsd-current Sun Jun 15 18:47:30 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id SAA08254 for current-outgoing; Sun, 15 Jun 1997 18:47:30 -0700 (PDT) Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id SAA08234; Sun, 15 Jun 1997 18:47:18 -0700 (PDT) Received: (from msmith@localhost) by genesis.atrad.adelaide.edu.au (8.8.5/8.7.3) id LAA08666; Mon, 16 Jun 1997 11:17:11 +0930 (CST) From: Michael Smith Message-Id: <199706160147.LAA08666@genesis.atrad.adelaide.edu.au> Subject: Re: Need to rebuild libkvm,ps,w In-Reply-To: <199706160120.SAA07208@rah.star-gate.com> from Amancio Hasty at "Jun 15, 97 06:20:21 pm" To: hasty@rah.star-gate.com (Amancio Hasty) Date: Mon, 16 Jun 1997 11:17:10 +0930 (CST) Cc: dyson@FreeBSD.ORG, current@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL28 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Amancio Hasty stands accused of saying: > > Dumb question, why can't we isolate the apps from the proc data structures? Because the in-kernel infrastructure for arb. data retrieval isn't there yet. Sysctl is an OK start, but it's effectively fairly static. Part of the "big bad nasty config model" I keep talking about includes an attempt to deal with this - I'm not sure if it'll go down well with the masses though. Is there serious interest in this? I'd be happy to discuss further... > Amancio -- ]] Mike Smith, Software Engineer msmith@gsoft.com.au [[ ]] Genesis Software genesis@gsoft.com.au [[ ]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[ ]] realtime instrument control. (ph) +61-8-8267-3493 [[ ]] Unix hardware collector. "Where are your PEZ?" The Tick [[ From owner-freebsd-current Sun Jun 15 18:50:39 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id SAA08551 for current-outgoing; Sun, 15 Jun 1997 18:50:39 -0700 (PDT) Received: from dyson.iquest.net (dyson.iquest.net [198.70.144.127]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id SAA08526; Sun, 15 Jun 1997 18:50:27 -0700 (PDT) Received: (from root@localhost) by dyson.iquest.net (8.8.5/8.8.5) id UAA00381; Sun, 15 Jun 1997 20:50:20 -0500 (EST) From: "John S. Dyson" Message-Id: <199706160150.UAA00381@dyson.iquest.net> Subject: Re: Need to rebuild libkvm,ps,w In-Reply-To: <199706160120.SAA07208@rah.star-gate.com> from Amancio Hasty at "Jun 15, 97 06:20:21 pm" To: hasty@rah.star-gate.com (Amancio Hasty) Date: Sun, 15 Jun 1997 20:50:20 -0500 (EST) Cc: dyson@FreeBSD.ORG, current@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL31 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > Dumb question, why can't we isolate the apps from the proc data structures? > > Amancio > We certainly can. It is an issue of person-power. I think that we need to set a priority for it? I would like to see it also. John From owner-freebsd-current Sun Jun 15 18:53:28 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id SAA08765 for current-outgoing; Sun, 15 Jun 1997 18:53:28 -0700 (PDT) Received: from rah.star-gate.com (rah.star-gate.com [204.188.121.18]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id SAA08756; Sun, 15 Jun 1997 18:53:25 -0700 (PDT) Received: from rah.star-gate.com (localhost.star-gate.com [127.0.0.1]) by rah.star-gate.com (8.8.5/8.8.5) with ESMTP id SAA07474; Sun, 15 Jun 1997 18:53:19 -0700 (PDT) Message-Id: <199706160153.SAA07474@rah.star-gate.com> X-Mailer: exmh version 1.6.9 8/22/96 To: "John S. Dyson" cc: dyson@FreeBSD.ORG, current@FreeBSD.ORG Subject: Re: Need to rebuild libkvm,ps,w In-reply-to: Your message of "Sun, 15 Jun 1997 20:50:20 CDT." <199706160150.UAA00381@dyson.iquest.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 15 Jun 1997 18:53:19 -0700 From: Amancio Hasty Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Just spec it out with "sufficient" detail and I bet that a few hackers will be happy to work with the Great Dyson 8) Cheers, Amancio >From The Desk Of "John S. Dyson" : > > > > Dumb question, why can't we isolate the apps from the proc data structures? > > > > Amancio > > > We certainly can. It is an issue of person-power. I think that we need > to set a priority for it? I would like to see it also. > > John From owner-freebsd-current Mon Jun 16 10:18:42 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id KAA16905 for current-outgoing; Mon, 16 Jun 1997 10:18:42 -0700 (PDT) Received: from garbo.lodgenet.com (garbo.lodgenet.com [204.124.122.252]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id KAA16864; Mon, 16 Jun 1997 10:16:31 -0700 (PDT) Received: from jake.lodgenet.com (jake.lodgenet.com [10.0.11.30]) by garbo.lodgenet.com (8.6.12/8.6.9) with ESMTP id MAA24208; Mon, 16 Jun 1997 12:14:57 -0500 Received: from jake.lodgenet.com (localhost.lodgenet.com [127.0.0.1]) by jake.lodgenet.com (8.8.5/8.6.12) with ESMTP id MAA12318; Mon, 16 Jun 1997 12:15:30 -0500 (CDT) Message-Id: <199706161715.MAA12318@jake.lodgenet.com> X-Mailer: exmh version 2.0gamma 1/27/96 To: current@freebsd.org cc: erich@freebsd.org Subject: natd and Emerging Tech Sync cards. Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 16 Jun 1997 12:15:30 -0500 From: "Eric L. Hernes" Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Howdy, I've got a customer here who's using ET's sync cards, and would like to use ipfw/natd to filter traffic to and fro. The ET interface names come up as etha16, etha17, ... etha21. Corresponding to the various connections into a FR cloud. Any attempts to configure natd with the `ipfw ... divert ... via etha21', result in somthing like: # ipfw add divert 9999 ip from any to any via etha21 Warning: interface does not exist 00000 divert 9999 ip from any to any via etha2 and digging a bit further, netinet/ip_fw.h shows: ... #define FW_IFNLEN 6 /* To keep structure on 2^x boundary */ char fu_via_name[FW_IFNLEN]; short fu_via_unit; } fu_via_if; ... which I believe is where the `1' is getting lost (with the terminating 0). Is there any harm in expanding this by a few bytes, or does the structure have to be on a 2^x boundary? Can I safely bump this and `make world'? and have things work? thanks, eric -- erich@rrnet.com http://rrnet.com/~erich erich@freebsd.org http://www.freebsd.org/~erich erich@lodgenet.com From owner-freebsd-current Mon Jun 16 13:24:42 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id NAA28377 for current-outgoing; Mon, 16 Jun 1997 13:24:42 -0700 (PDT) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.50]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id NAA28350; Mon, 16 Jun 1997 13:24:32 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id NAA18052; Mon, 16 Jun 1997 13:15:22 -0700 From: Terry Lambert Message-Id: <199706162015.NAA18052@phaeton.artisoft.com> Subject: Re: Need to rebuild libkvm,ps,w To: msmith@atrad.adelaide.edu.au (Michael Smith) Date: Mon, 16 Jun 1997 13:15:22 -0700 (MST) Cc: hasty@rah.star-gate.com, dyson@FreeBSD.ORG, current@FreeBSD.ORG In-Reply-To: <199706160147.LAA08666@genesis.atrad.adelaide.edu.au> from "Michael Smith" at Jun 16, 97 11:17:10 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > Dumb question, why can't we isolate the apps from the proc data structures? > > Because the in-kernel infrastructure for arb. data retrieval isn't > there yet. Actually, isn't it really the memory image arguments to ps/w/et. al. that cause the problem? We could go to /proc tomorrow if /proc were mandatory and we didn't care about ps'ing crash dumps (doing that sems to me to be the job of the kernel debugger, anyway). 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 Jun 16 13:35:34 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id NAA29249 for current-outgoing; Mon, 16 Jun 1997 13:35:34 -0700 (PDT) Received: from monet.artisan.calpoly.edu (root@monet.artisan.calpoly.edu [129.65.60.33]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id NAA29244 for ; Mon, 16 Jun 1997 13:35:31 -0700 (PDT) Received: from 129.65.40.20 (porkie.its.calpoly.edu [129.65.40.20]) by monet.artisan.calpoly.edu with SMTP (8.7.6/8.7.1) id NAA16694 for ; Mon, 16 Jun 1997 13:35:07 -0700 (PDT) Message-ID: <33A5B190.7078@galaxy.calpoly.edu> Date: Mon, 16 Jun 1997 13:35:13 -0800 From: roy scaife Organization: cal poly san luis obispo, ca X-Mailer: Mozilla 3.0 (Macintosh; U; PPC) MIME-Version: 1.0 To: freebsd-current@FreeBSD.ORG Subject: freebsd Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Please add me to your mailing address. Thanks, Roy K Scaife From owner-freebsd-current Mon Jun 16 17:18:12 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id RAA10541 for current-outgoing; Mon, 16 Jun 1997 17:18:12 -0700 (PDT) Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id RAA10531; Mon, 16 Jun 1997 17:18:02 -0700 (PDT) Received: (from msmith@localhost) by genesis.atrad.adelaide.edu.au (8.8.5/8.7.3) id JAA13345; Tue, 17 Jun 1997 09:47:00 +0930 (CST) From: Michael Smith Message-Id: <199706170017.JAA13345@genesis.atrad.adelaide.edu.au> Subject: Re: Need to rebuild libkvm,ps,w In-Reply-To: <199706162015.NAA18052@phaeton.artisoft.com> from Terry Lambert at "Jun 16, 97 01:15:22 pm" To: terry@lambert.org (Terry Lambert) Date: Tue, 17 Jun 1997 09:47:00 +0930 (CST) Cc: msmith@atrad.adelaide.edu.au, hasty@rah.star-gate.com, dyson@FreeBSD.ORG, current@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL28 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Terry Lambert stands accused of saying: > > > Dumb question, why can't we isolate the apps from the proc data structures? > > > > Because the in-kernel infrastructure for arb. data retrieval isn't > > there yet. > > Actually, isn't it really the memory image arguments to ps/w/et. al. > that cause the problem? We could go to /proc tomorrow if /proc > were mandatory and we didn't care about ps'ing crash dumps (doing > that sems to me to be the job of the kernel debugger, anyway). Argh. I keep forgetting that case 8(. Who does still use ps on crash dumps? Is it useful in that form? > Terry Lambert -- ]] Mike Smith, Software Engineer msmith@gsoft.com.au [[ ]] Genesis Software genesis@gsoft.com.au [[ ]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[ ]] realtime instrument control. (ph) +61-8-8267-3493 [[ ]] Unix hardware collector. "Where are your PEZ?" The Tick [[ From owner-freebsd-current Mon Jun 16 17:39:40 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id RAA11447 for current-outgoing; Mon, 16 Jun 1997 17:39:40 -0700 (PDT) Received: from alpha.xerox.com (alpha.Xerox.COM [13.1.64.93]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id RAA11442 for ; Mon, 16 Jun 1997 17:39:38 -0700 (PDT) Received: from crevenia.parc.xerox.com ([13.2.116.11]) by alpha.xerox.com with SMTP id <15645(4)>; Mon, 16 Jun 1997 17:39:02 PDT Received: by crevenia.parc.xerox.com id <177512>; Mon, 16 Jun 1997 17:38:57 -0700 From: Bill Fenner To: current@freebsd.org Subject: Re: loopback i/f bug (?) [ was Re: Some trouble with SCSI HD] Message-Id: <97Jun16.173857pdt.177512@crevenia.parc.xerox.com> Date: Mon, 16 Jun 1997 17:38:50 PDT Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I use the "ssh -L 5999:localhost:5999 -R 9898:localhost:9898" trick along with "cvsup -h localhost -P 9898" and haven't experienced any problems with a -current vintage 5/20/97. Bill From owner-freebsd-current Mon Jun 16 17:49:13 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id RAA11864 for current-outgoing; Mon, 16 Jun 1997 17:49:13 -0700 (PDT) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.50]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id RAA11853; Mon, 16 Jun 1997 17:49:07 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id RAA18347; Mon, 16 Jun 1997 17:39:49 -0700 From: Terry Lambert Message-Id: <199706170039.RAA18347@phaeton.artisoft.com> Subject: Re: Need to rebuild libkvm,ps,w To: msmith@atrad.adelaide.edu.au (Michael Smith) Date: Mon, 16 Jun 1997 17:39:49 -0700 (MST) Cc: terry@lambert.org, msmith@atrad.adelaide.edu.au, hasty@rah.star-gate.com, dyson@FreeBSD.ORG, current@FreeBSD.ORG In-Reply-To: <199706170017.JAA13345@genesis.atrad.adelaide.edu.au> from "Michael Smith" at Jun 17, 97 09:47:00 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > Actually, isn't it really the memory image arguments to ps/w/et. al. > > that cause the problem? We could go to /proc tomorrow if /proc > > were mandatory and we didn't care about ps'ing crash dumps (doing > > that sems to me to be the job of the kernel debugger, anyway). > > Argh. I keep forgetting that case 8(. Who does still use ps on crash > dumps? Is it useful in that form? I found it useful; I'm sure many people would say that it was. Mostly because there is no good "crash" program with an intrinsic "ps" command to replace it. As an alternative to "/proc", it should be possible to put a "shared library" in a seperate object section in a kernel, and have *it* know about the kernel data format. This would be transported with the kernel, and so available to the users trying to debug a crash-dump. Be default, the kernel section would not be loaded by the kernel loader (section name "ABI"?), and used by the tools with no direct knowledge of the kernel data internal itself. Functionally, this identical to a procesural interface instead of a data interface, which is the main issue that needs addressing. Of course, it requires going to ELF, since a.out can't do sections, a requirement of the design, but that's probably less eventual work than crafting a good "crash" program and a full-on "/proc" interface (which, unless adulterated, isn't much good for anything but processes). Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-current Mon Jun 16 17:53:35 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id RAA12116 for current-outgoing; Mon, 16 Jun 1997 17:53:35 -0700 (PDT) Received: from freebsd.scds.com (scds.ziplink.net [206.15.128.34]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id RAA12111 for ; Mon, 16 Jun 1997 17:53:30 -0700 (PDT) Received: (from jseger@localhost) by freebsd.scds.com (8.8.5/8.7.3) id UAA05695 for current@freebsd.org; Mon, 16 Jun 1997 20:02:04 -0400 (EDT) Date: Mon, 16 Jun 1997 20:02:04 -0400 (EDT) From: "Justin M. Seger" Message-Id: <199706170002.UAA05695@freebsd.scds.com> To: current@freebsd.org Subject: problem with sys/dirent.h Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I'm running the latest version of current (on June 16) and get this error. Can anyone explain? Thanks in advance, -Justin Seger- # cat sys-dirent.c #include main() {} ; # cc sys-dirent.c In file included from sys-dirent.c:1: /usr/include/sys/dirent.h:52: parse error before `u_int32_t' /usr/include/sys/dirent.h:52: warning: no semicolon at end of struct or union /usr/include/sys/dirent.h:53: warning: data definition has no type or storage class /usr/include/sys/dirent.h:54: parse error before `d_type' /usr/include/sys/dirent.h:54: warning: data definition has no type or storage class /usr/include/sys/dirent.h:55: parse error before `d_namlen' /usr/include/sys/dirent.h:55: warning: data definition has no type or storage class /usr/include/sys/dirent.h:62: parse error before `}' That's it. From owner-freebsd-current Mon Jun 16 18:35:06 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id SAA14757 for current-outgoing; Mon, 16 Jun 1997 18:35:06 -0700 (PDT) Received: from friley01.res.iastate.edu (friley01.res.iastate.edu [129.186.189.1]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id SAA14702; Mon, 16 Jun 1997 18:34:02 -0700 (PDT) Received: from friley01.res.iastate.edu (loopback [127.0.0.1]) by friley01.res.iastate.edu (8.8.5/8.8.5) with ESMTP id UAA03997; Mon, 16 Jun 1997 20:33:00 -0500 (CDT) Message-Id: <199706170133.UAA03997@friley01.res.iastate.edu> X-Mailer: exmh version 2.0gamma 1/27/96 To: Michael Smith cc: terry@lambert.org (Terry Lambert), hasty@rah.star-gate.com, dyson@FreeBSD.ORG, current@FreeBSD.ORG Subject: Re: Need to rebuild libkvm,ps,w In-reply-to: Your message of Tue, 17 Jun 1997 09:47:00 +0930. <199706170017.JAA13345@genesis.atrad.adelaide.edu.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 16 Jun 1997 20:32:59 -0500 From: Chris Csanady Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >Terry Lambert stands accused of saying: >> > > Dumb question, why can't we isolate the apps from the proc data structur es? >> > >> > Because the in-kernel infrastructure for arb. data retrieval isn't >> > there yet. >> >> Actually, isn't it really the memory image arguments to ps/w/et. al. >> that cause the problem? We could go to /proc tomorrow if /proc >> were mandatory and we didn't care about ps'ing crash dumps (doing >> that sems to me to be the job of the kernel debugger, anyway). > >Argh. I keep forgetting that case 8(. Who does still use ps on crash >dumps? Is it useful in that form? Well, how about we "forget" that case for now, and leave it as incentive for someone to fill in? If it's ever to get done, it may as well be done now. It will drag on forever otherwise.. I'm sure a _lot_ more people care that the data structures be coherent.. Chris Csanady From owner-freebsd-current Mon Jun 16 19:08:17 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id TAA16378 for current-outgoing; Mon, 16 Jun 1997 19:08:17 -0700 (PDT) Received: from time.cdrom.com (root@time.cdrom.com [204.216.27.226]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id TAA16372 for ; Mon, 16 Jun 1997 19:08:15 -0700 (PDT) Received: from time.cdrom.com (jkh@localhost.cdrom.com [127.0.0.1]) by time.cdrom.com (8.8.5/8.6.9) with ESMTP id TAA22106; Mon, 16 Jun 1997 19:08:18 -0700 (PDT) To: roy scaife cc: freebsd-current@FreeBSD.ORG Subject: Re: freebsd In-reply-to: Your message of "Mon, 16 Jun 1997 13:35:13 -0800." <33A5B190.7078@galaxy.calpoly.edu> Date: Mon, 16 Jun 1997 19:08:17 -0700 Message-ID: <22103.866513297@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > Please add me to your mailing address. This is not how you do this - please visit http://www.freebsd.org/register.html if you want to register. Jordan From owner-freebsd-current Mon Jun 16 19:22:04 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id TAA17336 for current-outgoing; Mon, 16 Jun 1997 19:22:04 -0700 (PDT) Received: from silvia.HIP.Berkeley.EDU (ala-ca16-03.ix.netcom.com [204.32.168.131]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id TAA17328 for ; Mon, 16 Jun 1997 19:22:00 -0700 (PDT) Received: (from asami@localhost) by silvia.HIP.Berkeley.EDU (8.8.5/8.6.9) id TAA04720; Mon, 16 Jun 1997 19:21:37 -0700 (PDT) Date: Mon, 16 Jun 1997 19:21:37 -0700 (PDT) Message-Id: <199706170221.TAA04720@silvia.HIP.Berkeley.EDU> To: jseger@freebsd.scds.com CC: current@freebsd.org In-reply-to: <199706170002.UAA05695@freebsd.scds.com> (jseger@freebsd.scds.com) Subject: Re: problem with sys/dirent.h From: asami@cs.berkeley.edu (Satoshi Asami) Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk * /usr/include/sys/dirent.h:52: parse error before `u_int32_t' Say, how about doing a grep of this in /usr/include? (You need to include first.) Satoshi From owner-freebsd-current Mon Jun 16 20:12:54 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id UAA19616 for current-outgoing; Mon, 16 Jun 1997 20:12:54 -0700 (PDT) Received: from freebsd.scds.com (scds.ziplink.net [206.15.128.34]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id UAA19610 for ; Mon, 16 Jun 1997 20:12:50 -0700 (PDT) Received: (from jseger@localhost) by freebsd.scds.com (8.8.5/8.7.3) id WAA09651; Mon, 16 Jun 1997 22:21:13 -0400 (EDT) Date: Mon, 16 Jun 1997 22:21:13 -0400 (EDT) From: "Justin M. Seger" Message-Id: <199706170221.WAA09651@freebsd.scds.com> To: asami@cs.berkeley.edu, jseger@freebsd.scds.com Subject: Re: problem with sys/dirent.h Cc: current@freebsd.org Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Thanks, sorry. Didn't understand the error message. -Justin Seger- From owner-freebsd-current Tue Jun 17 00:17:56 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id AAA28894 for current-outgoing; Tue, 17 Jun 1997 00:17:56 -0700 (PDT) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id AAA28886 for ; Tue, 17 Jun 1997 00:17:52 -0700 (PDT) Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id JAA00356; Tue, 17 Jun 1997 09:17:44 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.8.5/8.8.5) id JAA06765; Sun, 15 Jun 1997 09:29:09 +0200 (MET DST) Message-ID: <19970615092909.IU50309@uriah.heep.sax.de> Date: Sun, 15 Jun 1997 09:29:09 +0200 From: j@uriah.heep.sax.de (J Wunsch) To: freebsd-current@FreeBSD.ORG Cc: staylor@mrynet.com (Scott G. Akmentins-Taylor) Subject: Re: Easier diskpart? (a la sysinstall) References: <199706082336.QAA00381@mrynet.com> X-Mailer: Mutt 0.60_p2-3,5,8-9 Mime-Version: 1.0 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199706082336.QAA00381@mrynet.com>; from Scott G. Akmentins-Taylor on Jun 8, 1997 16:36:08 +0000 Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk As Scott G. Akmentins-Taylor wrote: > I REALLY would like to be able to do disk partitioning (diskpart(8)) > in the same way sysinstall handles it (i.e. specifying the partition's > sizes or cylinders). > > Is such a program hiding, or has anyone written this yet? /stand/sysinstall? :) Hellmuth Michaelis once wrote a menu program, and dropped it somewhere on freefall (now hub), but i eventually forgot the name, and i think he's currently not online. -- 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 Jun 17 00:18:57 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id AAA28950 for current-outgoing; Tue, 17 Jun 1997 00:18:57 -0700 (PDT) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id AAA28940 for ; Tue, 17 Jun 1997 00:18:51 -0700 (PDT) Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id JAA00358 for freebsd-current@freefall.FreeBSD.org; Tue, 17 Jun 1997 09:18:40 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.8.5/8.8.5) id JAA06795; Sun, 15 Jun 1997 09:38:25 +0200 (MET DST) Message-ID: <19970615093825.GU64964@uriah.heep.sax.de> Date: Sun, 15 Jun 1997 09:38:25 +0200 From: j@uriah.heep.sax.de (J Wunsch) To: freebsd-current@freefall.FreeBSD.org Subject: Re: lpr problems References: <199706101017.MAA02207@gil.physik.rwth-aachen.de> X-Mailer: Mutt 0.60_p2-3,5,8-9 Mime-Version: 1.0 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199706101017.MAA02207@gil.physik.rwth-aachen.de>; from Christoph Kukulies on Jun 10, 1997 12:17:17 +0200 Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk As Christoph Kukulies wrote: > first the duplicate spool directories error. Is it a warning > or does it prevent lpr/lpd from printing at all? It's a strong warning. lpd will totally mix up the jobs that have a single spool directory, and handle them as they were for a single print queue. > lpr: connect: no such file or directory /var/run/printer is missing. It's supposed to be created by lpd. Perhaps it has been cleaned out by some /var/run cleaning in /etc/rc? -- 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 Jun 17 00:19:08 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id AAA28975 for current-outgoing; Tue, 17 Jun 1997 00:19:08 -0700 (PDT) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id AAA28965 for ; Tue, 17 Jun 1997 00:19:04 -0700 (PDT) Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id JAA00359 for current@FreeBSD.ORG; Tue, 17 Jun 1997 09:18:57 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.8.5/8.8.5) id JAA06841; Sun, 15 Jun 1997 09:50:34 +0200 (MET DST) Message-ID: <19970615095033.DD29226@uriah.heep.sax.de> Date: Sun, 15 Jun 1997 09:50:33 +0200 From: j@uriah.heep.sax.de (J Wunsch) To: current@FreeBSD.ORG Subject: Re: ccd etc. [was: overclocking] References: <199706100458.VAA14947@MindBender.serv.net> <10342.865923203@time.cdrom.com> X-Mailer: Mutt 0.60_p2-3,5,8-9 Mime-Version: 1.0 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <10342.865923203@time.cdrom.com>; from Jordan K. Hubbard on Jun 9, 1997 23:13:23 -0700 Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Sorry, jumping late into the game, i've been away... As Jordan K. Hubbard wrote: > ..., and it sure would > be nice indeed to be able to: a) tell ccd to stop using a drive, > b) tell ccd to migrate from a drive, if enough free space on > other drives exists, and c) adopt a new drive. Well, i've been holding a Digital UNIX training course last week, and the one thing that really makes me jealous is what they call Logical Storage Manager (others call it LVM -- but they did have an inferior product called LVM previously, which is now abandoned). Sure, their filesystem is not as good as e.g. AIX's JFS, but they've got their volume management completely transparent and completely optional. You are free to also use the classic BSD partitions, and with their AdvFS, you can increase it by adding new volumes (you can even decrease it). Sure, UFS certainly doesn't allow us to increase a filesystem while being mounted, but adding a new volume in unmounted state, and using is as something like a different cylinder group range (or requiring the UFS to reside on a logical volume, and extend it) shouldn't be too hard. Too bad, i'm missing the time and the FS experience. -- 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 Jun 17 01:17:59 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id BAA02206 for current-outgoing; Tue, 17 Jun 1997 01:17:59 -0700 (PDT) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id BAA02201 for ; Tue, 17 Jun 1997 01:17:56 -0700 (PDT) Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id KAA00811 for current@FreeBSD.ORG; Tue, 17 Jun 1997 10:17:48 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.8.5/8.8.5) id IAA17359; Tue, 17 Jun 1997 08:03:02 +0200 (MET DST) Message-ID: <19970617080302.DA29718@uriah.heep.sax.de> Date: Tue, 17 Jun 1997 08:03:02 +0200 From: j@uriah.heep.sax.de (J Wunsch) To: current@FreeBSD.ORG Subject: Re: Need to rebuild libkvm,ps,w References: <199706160147.LAA08666@genesis.atrad.adelaide.edu.au> <199706162015.NAA18052@phaeton.artisoft.com> X-Mailer: Mutt 0.60_p2-3,5,8-9 Mime-Version: 1.0 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Reply-To: joerg_wunsch@uriah.heep.sax.de-noreply (Joerg Wunsch) In-Reply-To: <199706162015.NAA18052@phaeton.artisoft.com>; from Terry Lambert on Jun 16, 1997 13:15:22 -0700 Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk As Terry Lambert wrote: > > Because the in-kernel infrastructure for arb. data retrieval isn't > > there yet. > > Actually, isn't it really the memory image arguments to ps/w/et. al. > that cause the problem? We could go to /proc tomorrow if /proc > were mandatory ... /proc _is_ mandatory. ps(1) only displays half the information without it. -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-current Tue Jun 17 01:24:24 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id BAA02622 for current-outgoing; Tue, 17 Jun 1997 01:24:24 -0700 (PDT) Received: from fgate.flevel.co.uk (root@fgate.flevel.co.uk [194.6.101.2]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id BAA02617 for ; Tue, 17 Jun 1997 01:24:21 -0700 (PDT) Received: from localhost (trefor@localhost) by fgate.flevel.co.uk (8.8.3/8.6.9) with SMTP id JAA26041; Tue, 17 Jun 1997 09:24:39 +0100 (BST) Date: Tue, 17 Jun 1997 09:24:39 +0100 (BST) From: "Trefor S." To: Michael Smith cc: freebsd-current@FreeBSD.ORG Subject: Re: Plug and Play? In-Reply-To: <199706130156.LAA23265@genesis.atrad.adelaide.edu.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Fri, 13 Jun 1997, Michael Smith wrote: > Not as yet, no. Post-exams, I have a Plan which involves stealing > more of the nice NetBSD peoples' code, as they have ISA PnP working > (apparently) quite nicely indeed. > > There are also some issues relating to integration with Doug R's new > driver framework that aren't entirely clear. Only one verdammte exam > to go. Some good to me -- how the exam goes well. Cheers. Tref. From owner-freebsd-current Tue Jun 17 03:26:47 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id DAA07366 for current-outgoing; Tue, 17 Jun 1997 03:26:47 -0700 (PDT) Received: from ganko.eps.nagoya-u.ac.jp (gneiss.eps.nagoya-u.ac.jp [133.6.57.99]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id DAA07325 for ; Tue, 17 Jun 1997 03:25:20 -0700 (PDT) Received: from marble.eps.nagoya-u.ac.jp (localhost [127.0.0.1]) by ganko.eps.nagoya-u.ac.jp (8.8.5/3.4W4) with ESMTP id TAA07709 for ; Tue, 17 Jun 1997 19:24:48 +0900 (JST) Message-Id: <199706171024.TAA07709@ganko.eps.nagoya-u.ac.jp> To: current@freebsd.org Subject: vm_bounce_alloc: Unmapped page From: KATO Takenori X-Mailer: Mew version 1.70 on Emacs 19.28.1 / Mule 2.3 X-PGP-Fingerprint: 03 72 85 36 62 46 23 03 52 B1 10 22 44 10 0D 9E Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Tue, 17 Jun 1997 19:24:47 +0900 Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I got `vm_bounce_alloc: Unmapped page' panic when I compiled in union mounted /usr/src/usr.sbin directory. I did: mount -t union /usr/src-pc98/sbin /usr/src/sbin mount -t union /usr/src-pc98/usr.sbin /usr/src/usr.sbin make sbin usr.sbin where /usr/src-pc98/sbin contains i386/fdisk and /usr/src-pc98/usr.sbin contains config and vidcontrol and they exist in other disk than /usr/src. Panic mainly occurs in usr.sbin/amd/doc directory. What sould I do to solve the proble? The output of kgbd is as follows: Script started on Tue Jun 17 19:12:10 1997 marble [101]# gdb -k GDB is free software and you are welcome to distribute copies of it under certain conditions; type "show copying" to see the conditions. There is absolutely no warranty for GDB; type "show warranty" for details. GDB 4.16 (i386-unknown-freebsd), Copyright 1996 Free Software Foundation, Inc. (kgdb) symbol-file kernel.debug Reading symbols from kernel.debug...done. (kgdb) exec-file /var/crash/kernel.0 (kgdb) core-file /var/crash/vmcore.0 IdlePTD 212000 current pcb at 1cfdf0 panic: vm_bounce_alloc: Unmapped page #0 boot (howto=256) at ../../kern/kern_shutdown.c:266 266 dumppcb.pcb_cr3 = rcr3(); (kgdb) where #0 boot (howto=256) at ../../kern/kern_shutdown.c:266 #1 0xf0117993 in panic (fmt=0xf01a5a42 "vm_bounce_alloc: Unmapped page") at ../../kern/kern_shutdown.c:393 #2 0xf01a5b3f in vm_bounce_alloc (bp=0xf25ebd64) at ../../i386/i386/vm_machdep.c:364 #3 0xf017a618 in sd_strategy (bp=0xf25ebd64, sc_link=0xf043bb80) at ../../scsi/sd.c:479 #4 0xf0177574 in scsi_strategy (bp=0xf25ebd64, device=0xf01c8d28) at ../../scsi/scsi_driver.c:231 #5 0xf017a00c in sdstrategy (bp=0xf25ebd64) at ../../scsi/sd.c:129 #6 0xf01406c2 in spec_strategy (ap=0xf4500d60) at ../../miscfs/specfs/spec_vnops.c:536 #7 0xf0187646 in ufs_strategy (ap=0xf4500d60) at ../../ufs/ufs/ufs_vnops.c:1833 #8 0xf012ff82 in bwrite (bp=0xf25ebd64) at vnode_if.h:1212 #9 0xf0130022 in vn_bwrite (ap=0xf4500d80) at ../../kern/vfs_bio.c:436 #10 0xf01301a0 in bawrite (bp=0xf25ebd64) at vnode_if.h:1229 #11 0xf0133baf in cluster_wbuild (vp=0xf070d780, size=8192, start_lbn=4, len=8) at ../../kern/vfs_cluster.c:747 #12 0xf0133829 in cluster_write (bp=0xf25f2038, filesize=90112) at ../../kern/vfs_cluster.c:596 #13 0xf0181621 in ffs_write (ap=0xf4500eb8) at ../../ufs/ufs/ufs_readwrite.c:286 #14 0xf0143a31 in union_write (ap=0xf4500efc) at vnode_if.h:307 #15 0xf013b1f9 in vn_write (fp=0xf07083c0, uio=0xf4500f38, cred=0xf0672480) at vnode_if.h:307 #16 0xf011ea34 in write (p=0xf0614800, uap=0xf4500f94, retval=0xf4500f84) at ../../kern/sys_generic.c:268 #17 0xf01a43c3 in syscall (frame={tf_es = 39, tf_ds = 39, tf_edi = 352256, tf_esi = 134892508, tf_ebp = -272641472, tf_isp = -196079644, tf_ebx = 134824032, tf_edx = 134892508, tf_ecx = 134892508, tf_eax = 4, tf_trapno = 0, tf_err = 7, tf_eip = 134769665, tf_cs = 31, tf_eflags = 518, tf_esp = -272641496, tf_ss = 39}) at ../../pc98/i386/trap.c:976 #18 0x8086c01 in ?? () #19 0x8084a21 in ?? () #20 0x80849b6 in ?? () #21 0x80817e2 in ?? () #22 0x80398c3 in ?? () #23 0x4c15 in ?? () #24 0x4d5d in ?? () #25 0x6370 in ?? () #26 0x67ee in ?? () #27 0x6885 in ?? () #28 0x43dc in ?? () #29 0x4231 in ?? () #30 0x3f69 in ?? () #31 0x3be4 in ?? () #32 0x24bf in ?? () #33 0x1095 in ?? () (kgdb) up #1 0xf0117993 in panic (fmt=0xf01a5a42 "vm_bounce_alloc: Unmapped page") at ../../kern/kern_shutdown.c:393 393 boot(bootopt); (kgdb) up #2 0xf01a5b3f in vm_bounce_alloc (bp=0xf25ebd64) at ../../i386/i386/vm_machdep.c:364 364 panic("vm_bounce_alloc: Unmapped page"); (kgdb) print countvmpg $1 = 2 (kgdb) print vastart No symbol "vastart" in current context. (kgdb) print vaend $2 = 0 (kgdb) print vapstart $3 = 4089024512 (kgdb) print vapend $4 = 0 (kgdb) print va $5 = 4089024512 (kgdb) print kva $6 = 0 (kgdb) print pa $7 = 0 (kgdb) print dobounceflag $8 = 0 (kgdb) print i $9 = 0 (kgdb) print bp $10 = (struct buf *) 0xf25ebd64 (kgdb) print *bp $11 = {b_hash = {le_next = 0x0, le_prev = 0x0}, b_vnbufs = { le_next = 0x87654321, le_prev = 0x0}, b_freelist = {tqe_next = 0x0, tqe_prev = 0x0}, b_act = {tqe_next = 0x0, tqe_prev = 0x0}, b_proc = 0x0, b_flags = 1090519124, b_qindex = 0, b_usecount = 0 '\000', b_error = 0, b_bufsize = 8192, b_bcount = 8192, b_resid = 0, b_dev = 197636, b_un = { b_addr = 0xf3b99000
}, b_kvabase = 0xf3b99000
, b_kvasize = 8192, b_lblkno = 3, b_blkno = 87136, b_iodone = 0xf0133604 , b_iodone_chain = 0x0, b_vp = 0xf070d780, b_dirtyoff = 0, b_dirtyend = 8192, b_rcred = 0x0, b_wcred = 0x0, b_validoff = 0, b_validend = 0, b_pblkno = 1627232, b_saveaddr = 0x0, b_savekva = 0x0, b_driver1 = 0x0, b_driver2 = 0x0, b_spc = 0x0, b_cluster = {cluster_head = { tqh_first = 0xf25f1e80, tqh_last = 0xf25f1f10}, cluster_entry = { tqe_next = 0xf25f1e80, tqe_prev = 0xf25f1f10}}, b_pages = { 0x0 }, b_npages = 0} (kgdb) up #3 0xf017a618 in sd_strategy (bp=0xf25ebd64, sc_link=0xf043bb80) at ../../scsi/sd.c:479 479 vm_bounce_alloc(bp); (kgdb) print bp $12 = (struct buf *) 0xf25ebd64 (kgdb) up #4 0xf0177574 in scsi_strategy (bp=0xf25ebd64, device=0xf01c8d28) at ../../scsi/scsi_driver.c:231 231 (*device->dev_strategy)(bp, sc_link); (kgdb) up #5 0xf017a00c in sdstrategy (bp=0xf25ebd64) at ../../scsi/sd.c:129 129 SCSI_DEVICE_ENTRIES(sd) (kgdb) up #6 0xf01406c2 in spec_strategy (ap=0xf4500d60) at ../../miscfs/specfs/spec_vnops.c:536 536 (*bdevsw[major(ap->a_bp->b_dev)]->d_strategy)(ap->a_bp); (kgdb) quit ---- KATO Takenori Dept. Earth Planet. Sci., Nagoya Univ., Nagoya, 464-01, Japan PGP public key: finger kato@eclogite.eps.nagoya-u.ac.jp ------------------- Powered by FreeBSD(98) ------------------- From owner-freebsd-current Tue Jun 17 09:08:39 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id JAA20688 for current-outgoing; Tue, 17 Jun 1997 09:08:39 -0700 (PDT) Received: from rayearth.rim.or.jp (uucp@rayearth.rim.or.jp [202.247.130.242]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id JAA20588 for ; Tue, 17 Jun 1997 09:07:15 -0700 (PDT) Received: (from uucp@localhost) by rayearth.rim.or.jp (8.8.5/3.5Wpl2-uucp1/RIMNET) with UUCP id BAA17512; Wed, 18 Jun 1997 01:07:08 +0900 (JST) Received: from tky007.tth.expo96.ad.jp (localhost [127.0.0.1]) by mail.aslm.rim.or.jp (8.8.5/3.4W4-SMTP) with ESMTP id BAA02070; Wed, 18 Jun 1997 01:06:44 +0900 (JST) Message-Id: <199706171606.BAA02070@mail.aslm.rim.or.jp> To: freebsd-current@freebsd.org Cc: max@wide.ad.jp Subject: PPP on current From: Masafumi NAKANE/=?ISO-2022-JP?B?GyRCQ2Y6LDJtSjgbKEI=?= X-Mailer: Mew version 1.54 on Emacs 19.28.1, Mule 2.3 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Wed, 18 Jun 1997 01:06:43 +0900 Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I'm running -current as of about 10 hours ago. As I updated my system, PPP stop wroking properly. It connects to the provider, get address from them without problem. But, it looks like it has some problem with (or I have some problem in my configuration regarding) the manipulation of routing table. I've changed .ppp.conf and .ppp.linkup in many different ways, but couldn't find out what I'm doing wrong. I can't even generalize the problem, though, PPP succeeds in connecting to the ISP and establish the link, so that I can telnet, ftp or whatever to outside world if it's the first time after the reboot or after doing ``route flush''. The relevant part of my ~/.ppp.conf is: set ifaddr 192.168.1.1/0 192.168.1.2/0 255.255.255.0 delete ALL add 0 0 192.168.1.2 And .ppp.linkup is: MYADDR: delete ALL add 0 0 HISADDR Could anyone suggest what I'm doing wrong? These settings have been working until I updated PPP today, BTW. Thanks, Max From owner-freebsd-current Tue Jun 17 09:44:52 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id JAA22338 for current-outgoing; Tue, 17 Jun 1997 09:44:52 -0700 (PDT) Received: from austin.polstra.com (austin.polstra.com [206.213.73.10]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id JAA22233 for ; Tue, 17 Jun 1997 09:41:19 -0700 (PDT) Received: from austin.polstra.com (jdp@localhost) by austin.polstra.com (8.8.5/8.8.5) with ESMTP id JAA02737; Tue, 17 Jun 1997 09:41:00 -0700 (PDT) Message-Id: <199706171641.JAA02737@austin.polstra.com> To: fenner@parc.xerox.com Subject: Re: loopback i/f bug (?) [ was Re: Some trouble with SCSI HD] Newsgroups: polstra.freebsd.current In-Reply-To: <97Jun16.173857pdt.177512@crevenia.parc.xerox.com> References: <97Jun16.173857pdt.177512@crevenia.parc.xerox.com> Organization: Polstra & Co., Seattle, WA Cc: current@freebsd.org Date: Tue, 17 Jun 1997 09:40:59 -0700 From: John Polstra Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In article <97Jun16.173857pdt.177512@crevenia.parc.xerox.com>, Bill Fenner wrote: > I use the "ssh -L 5999:localhost:5999 -R 9898:localhost:9898" trick > along with "cvsup -h localhost -P 9898" and haven't experienced any > problems with a -current vintage 5/20/97. Yes, it doesn't happen when you tunnel through ssh. It turns out that you have to set up quite an uncommon state of affairs in order to make it fail. I spent a couple days on it with tcpdump and the kernel debugger, and was able to track it down to a bug in the TCP stack. The bug is exposed by (but not caused by) the large MTU and buffer sizes chosen when localhost is used. (Compare "route get localhost" with "route get yourhost.domain.com".) I have a small test program that reliably makes it fail even when localhost isn't used. I also have a simple fix which is being reviewed. It's not likely to be related to the NFS hangs, since this bug is in the TCP stack and not in the UDP code. -- John Polstra jdp@polstra.com John D. Polstra & Co., Inc. Seattle, Washington USA "Self-knowledge is always bad news." -- John Barth From owner-freebsd-current Tue Jun 17 10:31:21 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id KAA24749 for current-outgoing; Tue, 17 Jun 1997 10:31:21 -0700 (PDT) Received: from mhub1.tc.umn.edu (0@mhub1.tc.umn.edu [128.101.131.51]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id KAA24737 for ; Tue, 17 Jun 1997 10:31:10 -0700 (PDT) Received: from gold.tc.umn.edu by mhub1.tc.umn.edu; Tue, 17 Jun 97 12:30:50 -0500 Received: from pub-23-c-219.dialup.umn.edu by gold.tc.umn.edu; Tue, 17 Jun 97 12:30:47 -0500 Date: Tue, 17 Jun 1997 12:28:10 -0500 (CDT) From: dave adkins To: Masafumi NAKANE/=?ISO-2022-JP?B?GyRCQ2Y6LDJtSjgbKEI=?= cc: freebsd-current@FreeBSD.ORG Subject: Re: PPP on current In-Reply-To: <199706171606.BAA02070@mail.aslm.rim.or.jp> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Wed, 18 Jun 1997, Masafumi NAKANE/[ISO-2022-JP] $BCf:,2mJ8(B wrote: > I'm running -current as of about 10 hours ago. > > As I updated my system, PPP stop wroking properly. It connects to the > provider, get address from them without problem. But, it looks like > it has some problem with (or I have some problem in my configuration > regarding) the manipulation of routing table. > > I've changed .ppp.conf and .ppp.linkup in many different ways, but > couldn't find out what I'm doing wrong. I can't even generalize the > problem, though, PPP succeeds in connecting to the ISP and establish > the link, so that I can telnet, ftp or whatever to outside world if > it's the first time after the reboot or after doing ``route flush''. > > The relevant part of my ~/.ppp.conf is: > > set ifaddr 192.168.1.1/0 192.168.1.2/0 255.255.255.0 > delete ALL > add 0 0 192.168.1.2 > > And .ppp.linkup is: > MYADDR: > delete ALL > add 0 0 HISADDR > > Could anyone suggest what I'm doing wrong? These settings have been > working until I updated PPP today, BTW. > > Thanks, > Max > > I have the same problem. As of about 1997-06-10 ppp doesn't seem to remove the default route. With log tcp/ip enabled the write in OsSetRoute fails on the delete command. Have there been any changes to ppp that would require changes to ppp.conf to delete the default route? A change to route.c that seems to fix the problem for me is: --- route.c.orig Tue Jun 17 07:45:47 1997 +++ route.c Tue Jun 17 07:28:36 1997 @@ -74,6 +74,7 @@ rtmes.m_rtm.rtm_version = RTM_VERSION; rtmes.m_rtm.rtm_type = cmd; rtmes.m_rtm.rtm_addrs = RTA_DST | RTA_NETMASK | RTA_GATEWAY; + if (cmd == RTM_DELETE) rtmes.m_rtm.rtm_addrs &= ~RTA_GATEWAY; rtmes.m_rtm.rtm_seq = ++seqno; rtmes.m_rtm.rtm_pid = getpid(); rtmes.m_rtm.rtm_flags = RTF_UP | RTF_GATEWAY | RTF_STATIC; This is from route.c v1.13. It seems that RTM_DELETE doesn't work for default if the addrs is declared as a gateway. dave adkins From owner-freebsd-current Tue Jun 17 11:35:04 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id LAA28724 for current-outgoing; Tue, 17 Jun 1997 11:35:04 -0700 (PDT) Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id LAA28675 for ; Tue, 17 Jun 1997 11:34:57 -0700 (PDT) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.8.5/8.8.5) id OAA26765; Tue, 17 Jun 1997 14:34:53 -0400 (EDT) Date: Tue, 17 Jun 1997 14:34:53 -0400 (EDT) From: Garrett Wollman Message-Id: <199706171834.OAA26765@khavrinen.lcs.mit.edu> To: John Polstra Cc: fenner@parc.xerox.com, current@FreeBSD.ORG Subject: Re: loopback i/f bug (?) [ was Re: Some trouble with SCSI HD] Newsgroups: polstra.freebsd.current In-Reply-To: <199706171641.JAA02737@austin.polstra.com> References: <97Jun16.173857pdt.177512@crevenia.parc.xerox.com> <199706171641.JAA02737@austin.polstra.com> Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk < said: > "route get yourhost.domain.com".) I have a small test program that > reliably makes it fail even when localhost isn't used. I also have > a simple fix which is being reviewed. That's news to me... -GAWollman -- Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same wollman@lcs.mit.edu | O Siem / The fires of freedom Opinions not those of| Dance in the burning flame MIT, LCS, CRS, or NSA| - Susan Aglukark and Chad Irschick From owner-freebsd-current Tue Jun 17 13:16:43 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id NAA04542 for current-outgoing; Tue, 17 Jun 1997 13:16:43 -0700 (PDT) Received: from austin.polstra.com (austin.polstra.com [206.213.73.10]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id NAA04536 for ; Tue, 17 Jun 1997 13:16:41 -0700 (PDT) Received: from austin.polstra.com (jdp@localhost) by austin.polstra.com (8.8.5/8.8.5) with ESMTP id NAA03584; Tue, 17 Jun 1997 13:16:23 -0700 (PDT) Message-Id: <199706172016.NAA03584@austin.polstra.com> To: Garrett Wollman cc: fenner@parc.xerox.com, current@FreeBSD.ORG Subject: Re: loopback i/f bug (?) [ was Re: Some trouble with SCSI HD] In-reply-to: Your message of "Tue, 17 Jun 1997 14:34:53 EDT." <199706171834.OAA26765@khavrinen.lcs.mit.edu> References: <97Jun16.173857pdt.177512@crevenia.parc.xerox.com> <199706171641.JAA02737@austin.polstra.com> <199706171834.OAA26765@khavrinen.lcs.mit.edu> Date: Tue, 17 Jun 1997 13:16:22 -0700 From: John Polstra Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > "route get yourhost.domain.com".) I have a small test program that > > reliably makes it fail even when localhost isn't used. I also have > > a simple fix which is being reviewed. > > That's news to me... I sent you a carefully excerpted and annotated tcpdump listing on June 5 that showed the bug in action, but you didn't reply. That plus what I perceived as a brusque/impatient tone in your earlier e-mails led me to conclude that you didn't have time or weren't interested. So I looked for a different reviewer. E-mail is touchy and if I misinterpreted yours then I'd welcome your involvement again. John -- John Polstra jdp@polstra.com John D. Polstra & Co., Inc. Seattle, Washington USA "Self-knowledge is always bad news." -- John Barth From owner-freebsd-current Tue Jun 17 14:41:01 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id OAA10078 for current-outgoing; Tue, 17 Jun 1997 14:41:01 -0700 (PDT) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.50]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id OAA10073 for ; Tue, 17 Jun 1997 14:40:58 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id OAA19726; Tue, 17 Jun 1997 14:32:29 -0700 From: Terry Lambert Message-Id: <199706172132.OAA19726@phaeton.artisoft.com> Subject: Re: Need to rebuild libkvm,ps,w To: joerg_wunsch@uriah.heep.sax.de-noreply Date: Tue, 17 Jun 1997 14:32:29 -0700 (MST) Cc: current@FreeBSD.ORG In-Reply-To: <19970617080302.DA29718@uriah.heep.sax.de> from "J Wunsch" at Jun 17, 97 08:03:02 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > Actually, isn't it really the memory image arguments to ps/w/et. al. > > that cause the problem? We could go to /proc tomorrow if /proc > > were mandatory ... > > /proc _is_ mandatory. ps(1) only displays half the information > without it. This was a "hidden" jab at the utility of the commands in a crash situation (/proc for the crashed system is a procedural interface, and therefore unavailable). I should probably have ben more forthright, but people seem to get upset when I call something crap. 8-) Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-current Tue Jun 17 19:13:20 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id TAA22328 for current-outgoing; Tue, 17 Jun 1997 19:13:20 -0700 (PDT) Received: from peeper.my.domain ([208.128.8.126]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id TAA22319 for ; Tue, 17 Jun 1997 19:13:07 -0700 (PDT) Received: (from tom@localhost) by peeper.my.domain (8.8.5/8.7.3) id VAA00389; Tue, 17 Jun 1997 21:10:47 -0500 (CDT) Message-ID: <19970617211047.55183@peeper.my.domain> Date: Tue, 17 Jun 1997 21:10:47 -0500 From: Tom Jackson To: FreeBSD Current Subject: boot.help not work Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.76e Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I moved the file to / fs and even remade the biosboot directory but when booting, I don't get this boot screen. Any help? Tom From owner-freebsd-current Tue Jun 17 19:18:39 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id TAA22512 for current-outgoing; Tue, 17 Jun 1997 19:18:39 -0700 (PDT) Received: from peeper.my.domain ([208.128.8.126]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id TAA22429 for ; Tue, 17 Jun 1997 19:16:04 -0700 (PDT) Received: (from tom@localhost) by peeper.my.domain (8.8.5/8.7.3) id VAA00406; Tue, 17 Jun 1997 21:15:45 -0500 (CDT) Message-ID: <19970617211545.46581@peeper.my.domain> Date: Tue, 17 Jun 1997 21:15:45 -0500 From: Tom Jackson To: freebsd-current@FreeBSD.ORG Subject: Re: PPP on current References: <199706171606.BAA02070@mail.aslm.rim.or.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.76e In-Reply-To: ; from dave adkins on Tue, Jun 17, 1997 at 12:28:10PM -0500 Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk I have a standalone, no network, nada. Not running routed, and I've been cussing my isp for a week about this (his problem/no). The route flush command does eliminate the reboot requirement, thank goodness. Hope this can cleared up soon, wish I could. Tom From owner-freebsd-current Tue Jun 17 22:06:43 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id WAA28286 for current-outgoing; Tue, 17 Jun 1997 22:06:43 -0700 (PDT) Received: from shell.uniserve.com (tom@shell.uniserve.com [204.244.210.252]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id WAA28280 for ; Tue, 17 Jun 1997 22:06:31 -0700 (PDT) Received: from localhost (tom@localhost) by shell.uniserve.com (8.8.5/8.8.5) with SMTP id WAA16328; Tue, 17 Jun 1997 22:04:56 -0700 (PDT) X-Authentication-Warning: shell.uniserve.com: tom owned process doing -bs Date: Tue, 17 Jun 1997 22:04:51 -0700 (PDT) From: Tom To: Tom Jackson cc: FreeBSD Current Subject: Re: boot.help not work In-Reply-To: <19970617211047.55183@peeper.my.domain> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Tue, 17 Jun 1997, Tom Jackson wrote: > I moved the file to / fs and even remade the biosboot directory > but when booting, I don't get this boot screen. > > Any help? > > Tom > You need to use disklabel to write the new boot blocks to your disk. This is never done automatically, and is normally only done by sysinstall as part of the initial install. Tom From owner-freebsd-current Wed Jun 18 01:44:28 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id BAA06131 for current-outgoing; Wed, 18 Jun 1997 01:44:28 -0700 (PDT) Received: from peeper.my.domain ([208.128.8.121]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id BAA06123 for ; Wed, 18 Jun 1997 01:44:19 -0700 (PDT) Received: (from tom@localhost) by peeper.my.domain (8.8.5/8.7.3) id DAA00338; Wed, 18 Jun 1997 03:39:55 -0500 (CDT) Message-ID: <19970618033924.27079@peeper.my.domain> Date: Wed, 18 Jun 1997 03:39:24 -0500 From: Tom Jackson To: FreeBSD Current Subject: Re: boot.help not work References: <19970617211047.55183@peeper.my.domain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.76e In-Reply-To: ; from Tom on Tue, Jun 17, 1997 at 10:04:51PM -0700 Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Tue, Jun 17, 1997 at 10:04:51PM -0700, Tom wrote: > > On Tue, 17 Jun 1997, Tom Jackson wrote: > > > I moved the file to / fs and even remade the biosboot directory > > but when booting, I don't get this boot screen. > > > > Any help? > > > > Tom > > > > You need to use disklabel to write the new boot blocks to your disk. > This is never done automatically, and is normally only done by sysinstall > as part of the initial install. > > Tom > That's it alright. Used disklabel -w -B /dev/rsd0c diskname. Worked fine and thank you. Little hesitant to use sysinstall, not always sure what's going to happen. Tom From owner-freebsd-current Wed Jun 18 05:42:45 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id FAA14516 for current-outgoing; Wed, 18 Jun 1997 05:42:45 -0700 (PDT) Received: from fgate.flevel.co.uk (root@fgate.flevel.co.uk [194.6.101.2]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id FAA14511 for ; Wed, 18 Jun 1997 05:42:42 -0700 (PDT) Received: from localhost (dev@localhost) by fgate.flevel.co.uk (8.8.3/8.6.9) with SMTP id NAA12637 for ; Wed, 18 Jun 1997 13:43:13 +0100 (BST) Date: Wed, 18 Jun 1997 13:43:13 +0100 (BST) From: Developer To: freebsd-current@freebsd.org Subject: ELO Touch Screen Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk We compiled the new X-Windows and installed it, when X boots it recognises the ELO touch screen that is installed and says it is adding support for it, but when I touch on the screen nothing happens? Any ideas if there is something else that needs to be done? Thanks in Advance. Trefor S. From owner-freebsd-current Wed Jun 18 06:29:42 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id GAA16277 for current-outgoing; Wed, 18 Jun 1997 06:29:42 -0700 (PDT) Received: from obiwan.psinet.net.au (adrian@for.a.good.time.call.adrian.austnet.org [203.19.28.59]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id GAA16272 for ; Wed, 18 Jun 1997 06:29:35 -0700 (PDT) Received: from localhost (adrian@localhost) by obiwan.psinet.net.au (8.8.5/8.8.5) with SMTP id VAA14270; Wed, 18 Jun 1997 21:09:29 +0800 (WST) Date: Wed, 18 Jun 1997 21:09:29 +0800 (WST) From: Adrian Chadd To: Developer cc: freebsd-current@FreeBSD.ORG Subject: Re: ELO Touch Screen In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Wed, 18 Jun 1997, Developer wrote: > > We compiled the new X-Windows and installed it, when X boots it recognises > the ELO touch screen that is installed and says it is adding support for > it, but when I touch on the screen nothing happens? > > Any ideas if there is something else that needs to be done? Wanna tell me more about these touch screens? Ie : Size, cost, avaliability.. :-) Adrian "who always wanted a touch screen running in UNIX just to say "nyeah! at people who think UNIX sucks" Thanks, -- Adrian Chadd | "Unix doesn't stop you from doing | stupid things because that would | stop you from doing clever things" From owner-freebsd-current Thu Jun 19 16:31:51 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id QAA26848 for current-outgoing; Thu, 19 Jun 1997 16:31:51 -0700 (PDT) Received: from veda.is (ubiq.veda.is [193.4.230.60]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id QAA26627 for ; Thu, 19 Jun 1997 16:27:07 -0700 (PDT) Received: (from adam@localhost) by veda.is (8.8.5/8.7.3) id XAA12656 for freebsd-current@freebsd.org; Thu, 19 Jun 1997 23:54:16 GMT From: Adam David Message-Id: <199706192354.XAA12656@veda.is> Subject: getty modem control To: freebsd-current@freebsd.org Date: Thu, 19 Jun 1997 23:54:15 +0000 (GMT) X-Mailer: ELM [version 2.4ME+ PL31 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk 1. Would anyone be terribly upset if I added modem string grabbing support to getty? This would be useful for logging caller ID and connect speed. 2. I've been trying to use the modem init stuff on FreeBSD 2.2.2 getty. DTR lights up but there is no flicker on TXD. After this attempt I can no longer access /dev/ttyd0 or /dev/cua00, 'cu' refuses to open the port (no light on DTR) because "Line in use". However, there is nothing using the line. getty will light DTR on further attempts, but no dice. Obviously, nothing is getting sent to the hardware port and therefore no reply is received. # dwimgrep /etc/ttys ttyd0 "/usr/libexec/getty dialppp" unknown on # dwimgrep /etc/gettytab dialppp:\ :pp=/usr/local/sbin/pplogin:hw:dc#15:\ :ic="" at&fe0&t5&w0z0 OK\r:ac="RING\r ATA\r CONNECT:\ :tc=std.115200: # dwimgrep /var/log/authlog Jun 19 22:55:49 x getty[15727]: getty_chat script='"" at&fe0&t5&w0z0^M OK^M' Jun 19 22:55:49 x getty[15727]: chat_expect '' Jun 19 22:55:49 x getty[15727]: chat_expect OK Jun 19 22:55:49 x getty[15727]: chat_send 'at&fe0&t5&w0z0^M' Jun 19 22:55:59 x getty[15727]: chat_send TIMEOUT Jun 19 22:55:59 x getty[15727]: getty_chat TIMEOUT Jun 19 22:55:59 x getty[15727]: modem init problem on /dev/ttyd0 -- Adam David From owner-freebsd-current Thu Jun 19 16:34:30 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id QAA27037 for current-outgoing; Thu, 19 Jun 1997 16:34:30 -0700 (PDT) Received: from veda.is (ubiq.veda.is [193.4.230.60]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id QAA27028 for ; Thu, 19 Jun 1997 16:34:24 -0700 (PDT) Received: (from adam@localhost) by veda.is (8.8.5/8.7.3) id AAA12736 for freebsd-current@freebsd.org; Fri, 20 Jun 1997 00:01:48 GMT From: Adam David Message-Id: <199706200001.AAA12736@veda.is> Subject: getty modem stuff (typo) To: freebsd-current@freebsd.org Date: Fri, 20 Jun 1997 00:01:47 +0000 (GMT) X-Mailer: ELM [version 2.4ME+ PL31 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk oops, typo in my previous email. # dwimgrep /etc/gettytab :ic="" at&fe0&t5&w0z0\r OK\r:\ This is what I was using and it doesn't work. -- Adam David From owner-freebsd-current Thu Jun 19 17:40:12 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id RAA29943 for current-outgoing; Thu, 19 Jun 1997 17:40:12 -0700 (PDT) Received: from veda.is (ubiq.veda.is [193.4.230.60]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id RAA29937 for ; Thu, 19 Jun 1997 17:40:07 -0700 (PDT) Received: (from adam@localhost) by veda.is (8.8.5/8.7.3) id BAA12886; Fri, 20 Jun 1997 01:07:20 GMT Date: Fri, 20 Jun 1997 01:07:20 GMT From: Adam David Message-Id: <199706200107.BAA12886@veda.is> To: freebsd-current@freebsd.org Subject: Re: Need to rebuild libkvm,ps,w Newsgroups: list.freebsd.current References: <199706160147.LAA08666@genesis.atrad.adelaide.edu.au> <19970617080302.DA29718@uriah.heep.sax.de> X-Newsreader: NN version 6.5.0 #2 (NOV) Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk ^^^^^^^^^^;) >/proc _is_ mandatory. ps(1) only displays half the information >without it. ps(1) does not even display that half of it when the struct changes, which seems to be the main push of this thread. Have you ever sat at a half-hosed system and been forced to reboot simply because there was no PID info available about that one process that needed to be killed? This can happen when /usr/src/sys diverges from /usr/src (or perhaps it was a shared symlink includes thing). It would be nice for ps(1) to become decoupled from the kernel so this can no longer happen. -- Adam David From owner-freebsd-current Thu Jun 19 19:48:36 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id TAA05268 for current-outgoing; Thu, 19 Jun 1997 19:48:36 -0700 (PDT) Received: from sumatra.americantv.com (sumatra.americantv.com [207.170.17.37]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id TAA05261 for ; Thu, 19 Jun 1997 19:48:30 -0700 (PDT) Received: from right.PCS (right.PCS [148.105.10.31]) by sumatra.americantv.com (8.8.5/8.8.5) with ESMTP id WAA06272; Thu, 19 Jun 1997 22:32:59 -0500 (CDT) Received: (jlemon@localhost) by right.PCS (8.6.13/8.6.4) id VAA08134; Thu, 19 Jun 1997 21:50:03 -0500 Message-ID: <19970619215003.46235@right.PCS> Date: Thu, 19 Jun 1997 21:50:03 -0500 From: Jonathan Lemon To: Adam David Cc: freebsd-current@FreeBSD.ORG Subject: Re: Need to rebuild libkvm,ps,w References: <199706160147.LAA08666@genesis.atrad.adelaide.edu.au> <19970617080302.DA29718@uriah.heep.sax.de> <199706200107.BAA12886@veda.is> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.61.1 In-Reply-To: <199706200107.BAA12886@veda.is>; from Adam David on Jun 06, 1997 at 01:07:20AM +0000 Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Jun 06, 1997 at 01:07:20AM +0000, Adam David wrote: > seems to be the main push of this thread. Have you ever sat at a half-hosed > system and been forced to reboot simply because there was no PID info > available about that one process that needed to be killed? This can Ctrl-Alt-F1 to get vty0, Ctrl-PrtSc to get ddb, then ps from the debugger. :-) I don't think my desktop machine has had a working ps for the last 2 months, mainly because I've been too (busy|lazy) to install one. -- Jonathan From owner-freebsd-current Thu Jun 19 20:13:29 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id UAA06397 for current-outgoing; Thu, 19 Jun 1997 20:13:29 -0700 (PDT) Received: from veda.is (ubiq.veda.is [193.4.230.60]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id UAA06392 for ; Thu, 19 Jun 1997 20:13:26 -0700 (PDT) Received: (from adam@localhost) by veda.is (8.8.5/8.7.3) id DAA13240; Fri, 20 Jun 1997 03:40:45 GMT From: Adam David Message-Id: <199706200340.DAA13240@veda.is> Subject: Re: Need to rebuild libkvm,ps,w In-Reply-To: <19970619215003.46235@right.PCS> from Jonathan Lemon at "Jun 19, 97 09:50:03 pm" To: jlemon@americantv.com (Jonathan Lemon) Date: Fri, 20 Jun 1997 03:40:44 +0000 (GMT) Cc: freebsd-current@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL31 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > On Jun 06, 1997 at 01:07:20AM +0000, Adam David wrote: > > seems to be the main push of this thread. Have you ever sat at a half-hosed > > system and been forced to reboot simply because there was no PID info > > available about that one process that needed to be killed? This can > > Ctrl-Alt-F1 to get vty0, Ctrl-PrtSc to get ddb, then ps from the debugger. > > :-) ddb_mod.o ? ;-) -- Adam David From owner-freebsd-current Thu Jun 19 22:51:01 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id WAA13102 for current-outgoing; Thu, 19 Jun 1997 22:51:01 -0700 (PDT) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id WAA13096 for ; Thu, 19 Jun 1997 22:50:39 -0700 (PDT) Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id HAA24629; Fri, 20 Jun 1997 07:50:34 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.8.5/8.8.5) id HAA04997; Fri, 20 Jun 1997 07:35:06 +0200 (MET DST) Message-ID: <19970620073506.MK21253@uriah.heep.sax.de> Date: Fri, 20 Jun 1997 07:35:06 +0200 From: j@uriah.heep.sax.de (J Wunsch) To: freebsd-current@FreeBSD.ORG Cc: adam@veda.is (Adam David) Subject: Re: getty modem control References: <199706192354.XAA12656@veda.is> X-Mailer: Mutt 0.60_p2-3,5,8-9 Mime-Version: 1.0 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199706192354.XAA12656@veda.is>; from Adam David on Jun 19, 1997 23:54:15 +0000 Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk As Adam David wrote: > 1. Would anyone be terribly upset if I added modem string grabbing support > to getty? This would be useful for logging caller ID and connect speed. Yep, i'm very reluctant to such things in the regular getty. The reason for this reluctance is that you gotta abuse the inbound port. Normally, the inbound port is supposed to block inside open(2) until carrier arrives. I understand that your intended changes would break this (as well as David Nugent's changes broke this, see below). If you need mgetty, better use mgetty. There's no use to invent a second all-singing all-dancing getty, i'd be more happy to keep the standard getty reasonably small, more targeted towards regular needs and non-broken modems. > 2. I've been trying to use the modem init stuff on FreeBSD 2.2.2 getty. > DTR lights up but there is no flicker on TXD. After this attempt I can > no longer access /dev/ttyd0 or /dev/cua00, 'cu' refuses to open the port > (no light on DTR) because "Line in use". That's already one of the problems i've been afraid when i've been objecting against _any_ modem initialization handling back when David Nugent added it. Fixing all the related programs to chatting with a modem will become an endless mess. I really don't think this should go into a regular getty, or after some time, we'll end up with yet another mgetty. This is silly, will bloat the regular getty, and is nothing but a duplication of (Gert Doering's in this case) efforts. Non-broken modems do work with a lightweight getty. Broken modems (and i figure the entire class of modems that is allowed in Australia belongs into this class) requires special hacks which should IMHO be left to special programs. If you don't agree on this, please agree on forking off the old (pre-David N) getty as ``getty-light'', so i could continue to use this version then. I refuse to use broken modems anyway, and i don't need the creeping featurism. (Not meant as a personal offense, but as a general statement.) -- 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 Jun 20 00:10:31 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id AAA17008 for current-outgoing; Fri, 20 Jun 1997 00:10:31 -0700 (PDT) Received: from trifork.gu.net (trifork.gu.net [194.93.190.194]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id AAA16993 for ; Fri, 20 Jun 1997 00:10:14 -0700 (PDT) Received: from localhost (localhost.gu.kiev.ua [127.0.0.1]) by trifork.gu.net (8.8.5/8.8.5) with SMTP id NAA01126; Fri, 20 Jun 1997 13:11:19 +0300 (EEST) Date: Fri, 20 Jun 1997 13:11:19 +0300 (EEST) From: Andrew Stesin Reply-To: stesin@gu.net To: Joerg Wunsch cc: freebsd-current@FreeBSD.ORG, Adam David Subject: Re: getty modem control In-Reply-To: <19970620073506.MK21253@uriah.heep.sax.de> Message-ID: X-NCC-RegID: ua.gu MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hi, On Fri, 20 Jun 1997, J Wunsch wrote: > > 1. Would anyone be terribly upset if I added modem string grabbing support > > to getty? This would be useful for logging caller ID and connect speed. I will. > If you need mgetty, better use mgetty. There's no use to invent a > second all-singing all-dancing getty, i'd be more happy to keep the ^^^^^^ I think there are about several dozens "smart" getty's around already and have been for years. uugetty comes to mind, for example. > standard getty reasonably small, more targeted towards regular needs > and non-broken modems. > Fixing all the related programs to chatting with a > modem will become an endless mess. Sure. > If you don't agree on this, please agree on forking off the old > (pre-David N) getty as ``getty-light'', so i could continue to use > this version then. I refuse to use broken modems anyway, and i don't > need the creeping featurism. (Not meant as a personal offense, but as > a general statement.) A second this wholeheartly. Also the "lightweight" setup is much easier to administer when you have at least 16 modems per box. > -- > 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. ;-) > Best regards, Andrew Stesin nic-hdl: ST73-RIPE From owner-freebsd-current Fri Jun 20 00:47:58 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id AAA18778 for current-outgoing; Fri, 20 Jun 1997 00:47:58 -0700 (PDT) Received: from veda.is (ubiq.veda.is [193.4.230.60]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id AAA18770 for ; Fri, 20 Jun 1997 00:47:53 -0700 (PDT) Received: (from adam@localhost) by veda.is (8.8.5/8.7.3) id IAA15687; Fri, 20 Jun 1997 08:15:09 GMT From: Adam David Message-Id: <199706200815.IAA15687@veda.is> Subject: Re: getty modem control In-Reply-To: <19970620073506.MK21253@uriah.heep.sax.de> from J Wunsch at "Jun 20, 97 07:35:06 am" To: joerg_wunsch@uriah.heep.sax.de Date: Fri, 20 Jun 1997 08:15:07 +0000 (GMT) Cc: freebsd-current@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL31 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk [Adam] > > 1. Would anyone be terribly upset if I added modem string grabbing support > > to getty? This would be useful for logging caller ID and connect speed. [Jörg] > Yep, i'm very reluctant to such things in the regular getty. The > reason for this reluctance is that you gotta abuse the inbound port. > Normally, the inbound port is supposed to block inside open(2) until > carrier arrives. I understand that your intended changes would break > this (as well as David Nugent's changes broke this, see below). > > If you need mgetty, better use mgetty. There's no use to invent a > second all-singing all-dancing getty, i'd be more happy to keep the > standard getty reasonably small, more targeted towards regular needs > and non-broken modems. It's a pity modems don't allow for retrieving the caller-ID afterwards, instead of spitting it out in realtime. The connect speed can be read back on request, probably even between active sessions. Further to the discussion on the subject of (m)getty back in February, would it work to use DSR as RI for those ports without RI? AT&S1 DSR will become active after answer tone has been detected and inactive after the carrier has been lost, i.e. becomes active after RI and before CD (probably too late to catch caller-ID though?). > > 2. I've been trying to use the modem init stuff on FreeBSD 2.2.2 getty. > > DTR lights up but there is no flicker on TXD. After this attempt I can > > no longer access /dev/ttyd0 or /dev/cua00, 'cu' refuses to open the port > > (no light on DTR) because "Line in use". Trying to let getty open cuaa0 resulted in permissions root.wheel 600 and normal inoperativeness was restored by changing back to uucp.dialer 660 I'm not making any progress with using the modem init string capability. (DTR lights up but there is no flicker on TXD) > That's already one of the problems i've been afraid when i've been > objecting against _any_ modem initialization handling back when David > Nugent added it. Fixing all the related programs to chatting with a > modem will become an endless mess. I really don't think this should > go into a regular getty, or after some time, we'll end up with yet > another mgetty. This is silly, will bloat the regular getty, and is > nothing but a duplication of (Gert Doering's in this case) efforts. How could this be farmed out to a separate process? > Non-broken modems do work with a lightweight getty. Broken modems > (and i figure the entire class of modems that is allowed in Australia > belongs into this class) requires special hacks which should IMHO be > left to special programs. > > > If you don't agree on this, please agree on forking off the old > (pre-David N) getty as ``getty-light'', so i could continue to use > this version then. I refuse to use broken modems anyway, and i don't > need the creeping featurism. (Not meant as a personal offense, but as > a general statement.) The whole point was that the user only gets the features requested via specific gettytab entries. Unless requested, they stay out of the way. -- Adam David From owner-freebsd-current Fri Jun 20 01:23:22 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id BAA20291 for current-outgoing; Fri, 20 Jun 1997 01:23:22 -0700 (PDT) Received: from veda.is (ubiq.veda.is [193.4.230.60]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id BAA20286 for ; Fri, 20 Jun 1997 01:23:16 -0700 (PDT) Received: (from adam@localhost) by veda.is (8.8.5/8.7.3) id IAA15732; Fri, 20 Jun 1997 08:50:33 GMT From: Adam David Message-Id: <199706200850.IAA15732@veda.is> Subject: Re: getty modem control In-Reply-To: <19970620073506.MK21253@uriah.heep.sax.de> from J Wunsch at "Jun 20, 97 07:35:06 am" To: joerg_wunsch@uriah.heep.sax.de Date: Fri, 20 Jun 1997 08:50:31 +0000 (GMT) Cc: freebsd-current@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL31 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk [Adam] > > 1. Would anyone be terribly upset if I added modem string grabbing support > > to getty? This would be useful for logging caller ID and connect speed. In case it wasn't clear, this would be a fleshing out of :ac=...: and only affects the answer chat script. [Jörg] > Yep, i'm very reluctant to such things in the regular getty. The > reason for this reluctance is that you gotta abuse the inbound port. > Normally, the inbound port is supposed to block inside open(2) until > carrier arrives. I understand that your intended changes would break > this (as well as David Nugent's changes broke this, see below). Actually, I much prefer the blocking approach for most purposes, and am considering a reshuffle of the code to allow :ac=...: in that case also, requiring a new capability to describe whether to block on open or wait in select. How about :nb: for non-blocking, and default to blocking? -- Adam David From owner-freebsd-current Fri Jun 20 03:10:01 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id DAA25325 for current-outgoing; Fri, 20 Jun 1997 03:10:01 -0700 (PDT) Received: from fgate.flevel.co.uk (root@fgate.flevel.co.uk [194.6.101.2]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id DAA25290 for ; Fri, 20 Jun 1997 03:09:56 -0700 (PDT) Received: from localhost (dev@localhost) by fgate.flevel.co.uk (8.8.3/8.6.9) with SMTP id LAA00719; Fri, 20 Jun 1997 11:10:01 +0100 (BST) Date: Fri, 20 Jun 1997 11:10:01 +0100 (BST) From: Developer To: Francis Yeung cc: freebsd-current@freebsd.org Subject: Re: ELO Touch Screen In-Reply-To: <9706191659.AA20877@fyeung8.netific.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Thu, 19 Jun 1997, Francis Yeung wrote: > Have you received any reply for your post ? Yes, a couple. > I have not used the ELO touch screen before but I used other > touch screen technology. for most of them, I have to write a special control > program to enable them. I am surprised that X supports it without > any special interface. Have you talked to ELO about this ? Ive managed to solve the problem and get it working in the end. It seems that the serial IO code was not working correctly and I have to patch the driver so it sets all the baud rates and also does a 200ms wait before trying to read from the serial. I also commented out the inital check about the baud rate as it didn't seem to be supported by this model, it now works fine:)) If anyone needs the patched code I'll email it. Regards, Trefor S. From owner-freebsd-current Fri Jun 20 08:35:20 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id IAA08153 for current-outgoing; Fri, 20 Jun 1997 08:35:20 -0700 (PDT) Received: from rayearth.rim.or.jp (uucp@rayearth.rim.or.jp [202.247.130.242]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id IAA08116 for ; Fri, 20 Jun 1997 08:34:43 -0700 (PDT) Received: (from uucp@localhost) by rayearth.rim.or.jp (8.8.5/3.5Wpl2-uucp1/RIMNET) with UUCP id AAA20033; Sat, 21 Jun 1997 00:34:23 +0900 (JST) Received: from tky007.tth.expo96.ad.jp (localhost [127.0.0.1]) by mail.aslm.rim.or.jp (8.8.5/3.4W4-SMTP) with ESMTP id AAA26895; Sat, 21 Jun 1997 00:22:24 +0900 (JST) Message-Id: <199706201522.AAA26895@mail.aslm.rim.or.jp> To: freebsd-current@freebsd.org Cc: max@wide.ad.jp Subject: international eBones broken? From: Masafumi NAKANE/=?ISO-2022-JP?B?GyRCQ2Y6LDJtSjgbKEI=?= X-Mailer: Mew version 1.54 on Emacs 19.28.1, Mule 2.3 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Sat, 21 Jun 1997 00:22:22 +0900 Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi, I got the following as I compiled eBones/ (which I got from the international crypto repository). ===> include ===> lib ===> lib/libacl ===> lib/libkdb ===> lib/libkrb cc -O -DKERBEROS -DCRYPT -DDEBUG -DBSD42 -I/usr/src/eBones/lib/libkrb/../../../secure/lib/libdes -I/usr/src/eBones/lib/libkrb/../../include -Wall -I/usr/src/eBones/lib/libkrb/../../../secure/lib/libdes -I/usr/src/eBones/lib/libkrb/../../include -Wall -c /usr/src/eBones/lib/libkrb/des_rw.c -o des_rw.o /usr/src/eBones/lib/libkrb/des_rw.c: In function `des_write': /usr/src/eBones/lib/libkrb/des_rw.c:233: void value not ignored as it ought to be *** Error code 1 Stop. *** Error code 1 Stop. *** Error code 1 Stop. Am I doing something wrong? Or is it something with the source? Thanks, Max From owner-freebsd-current Fri Jun 20 15:04:09 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id PAA27675 for current-outgoing; Fri, 20 Jun 1997 15:04:09 -0700 (PDT) Received: from nagual.pp.ru (ache.relcom.ru [194.58.229.133]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id PAA27645; Fri, 20 Jun 1997 15:03:44 -0700 (PDT) Received: (from ache@localhost) by nagual.pp.ru (8.8.5/8.8.5) id CAA00515; Sat, 21 Jun 1997 02:03:41 +0400 (MSD) Date: Sat, 21 Jun 1997 02:03:38 +0400 (MSD) From: =?KOI8-R?B?4c7E0sXKIP7F0s7P1w==?= To: Masafumi NAKANE/=?ISO-2022-JP?B?GyRCQ2Y6LDJtSjgbKEI=?= cc: freebsd-current@freebsd.org, markm@freebsd.org Subject: Re: international eBones broken? In-Reply-To: <199706201522.AAA26895@mail.aslm.rim.or.jp> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=KOI8-R Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Sat, 21 Jun 1997, Masafumi NAKANE/[ISO-2022-JP] $BCf:,2mJ8(B wrote: > Am I doing something wrong? Or is it something with the source? > International repository must be upgraded to -current national, I already send needed patch to markm, but still nothing happens. -- Andrey A. Chernov http://www.nagual.pp.ru/~ache/ From owner-freebsd-current Fri Jun 20 15:41:10 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id PAA29258 for current-outgoing; Fri, 20 Jun 1997 15:41:10 -0700 (PDT) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.50]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id PAA29253 for ; Fri, 20 Jun 1997 15:41:06 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id PAA24698; Fri, 20 Jun 1997 15:27:38 -0700 From: Terry Lambert Message-Id: <199706202227.PAA24698@phaeton.artisoft.com> Subject: Re: getty modem control To: adam@veda.is (Adam David) Date: Fri, 20 Jun 1997 15:27:38 -0700 (MST) Cc: joerg_wunsch@uriah.heep.sax.de, freebsd-current@FreeBSD.ORG In-Reply-To: <199706200815.IAA15687@veda.is> from "Adam David" at Jun 20, 97 08:15:07 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > It's a pity modems don't allow for retrieving the caller-ID afterwards, > instead of spitting it out in realtime. The connect speed can be read > back on request, probably even between active sessions. Connect speed is evil. The data rate should be driven with the RS232C external clock for modems (described in the RS232C, Bell 103C, and Bell 212 standards). The negotiation for speed should be done at the carrier recognition, and not between the UART on the modem and the UART in the computer. This is an evil perpetrated on honest, God-fearing people by Intel and National Semiconductor. > Further to the discussion on the subject of (m)getty back in > February, would it work to use DSR as RI for those ports > without RI? 9 pins: chassis ground (evil waste of a pin) TXD RXD RTS CTS DSR signal ground DCD DTR I think the problem is that off-to-on DSR events are not interrupted by the UART. > AT&S1 DSR will become active after answer tone has been detected > and inactive after the carrier has been lost, i.e. becomes active > after RI and before CD (probably too late to catch caller-ID though?). Caller ID data is sent down the line between ring 1 and 2 when using POTS lines in the US. For ISDN, caller ID data is sent seperately. I still have the first Caller-ID to RS232 circuit I built (look for the circuit in an old Radio Electronics or Popular Electronics, I forget which). > I'm not making any progress with using the modem init string capability. > (DTR lights up but there is no flicker on TXD) Look at the CTS/RTS settings, and how they effect the modem and UART in the DCD-not-present state, in particular. > How could this be farmed out to a separate process? You make a "modem driver" and seperate "inbound" vs. "outbound" tty device operations. The main problem is that most of these damn "do everything" getty programs like to initialize the modems to a state which is optimal for them. This is the same reason you can't share amodem between an intermittent ISP connection and a FAX server on most Microsoft platforms. > The whole point was that the user only gets the features requested via > specific gettytab entries. Unless requested, they stay out of the way. Getty is the wrong place to do this. The corect thing for getty to do is to listen to the inbound tty pseudo device (no, not pseudo tty), and for a program to fan out the connection on the basis of DCD and DTR state transitions. The RI stuff is a hack I suggested to use as an inbound call marker; as you've discovered with 9 pin ports, it's not a very good hack. 8-(. Better to support inbound call fanning to voice/data/fax devices as seperate entities. There is actually one modem that creates two serial pseudo devices under Windows95/NT: that's the Intel modem for telephony (I can't tell you the model without going to the usability lab down the hall, sorry). I *really* liked the modem, but obviously, it required a per-modem driver to do its thing. It supported Caller-ID as well, as a device ioctl (and supported providing your own calling-ID, too). Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-current Fri Jun 20 16:47:37 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id QAA02856 for current-outgoing; Fri, 20 Jun 1997 16:47:37 -0700 (PDT) Received: from austin.polstra.com (austin.polstra.com [206.213.73.10]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id QAA02843 for ; Fri, 20 Jun 1997 16:47:30 -0700 (PDT) Received: from austin.polstra.com (jdp@localhost) by austin.polstra.com (8.8.5/8.8.5) with ESMTP id QAA00447; Fri, 20 Jun 1997 16:47:25 -0700 (PDT) Message-Id: <199706202347.QAA00447@austin.polstra.com> To: ache@nagual.pp.ru Subject: Re: international eBones broken? Newsgroups: polstra.freebsd.current In-Reply-To: References: Organization: Polstra & Co., Seattle, WA Cc: current@freebsd.org Date: Fri, 20 Jun 1997 16:47:25 -0700 From: John Polstra Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > International repository must be upgraded to -current national, I already > send needed patch to markm, but still nothing happens. Not too long ago, he announced (in -hackers, I think) that his home had been burlarized and much of his equipment stolen. I suspect he's still out of commission. -- John Polstra jdp@polstra.com John D. Polstra & Co., Inc. Seattle, Washington USA "Self-knowledge is always bad news." -- John Barth From owner-freebsd-current Fri Jun 20 17:18:29 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id RAA04129 for current-outgoing; Fri, 20 Jun 1997 17:18:29 -0700 (PDT) Received: from agora.rdrop.com (root@agora.rdrop.com [199.2.210.241]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id RAA04122 for ; Fri, 20 Jun 1997 17:18:26 -0700 (PDT) Received: from veda.is (ubiq.veda.is [193.4.230.60]) by agora.rdrop.com (8.8.5/8.8.5) with ESMTP id RAA17825 for ; Fri, 20 Jun 1997 17:18:20 -0700 (PDT) Received: (from adam@localhost) by veda.is (8.8.5/8.7.3) id AAA17361; Sat, 21 Jun 1997 00:43:55 GMT From: Adam David Message-Id: <199706210043.AAA17361@veda.is> Subject: Re: getty modem control In-Reply-To: <199706202227.PAA24698@phaeton.artisoft.com> from Terry Lambert at "Jun 20, 97 03:27:38 pm" To: terry@lambert.org (Terry Lambert) Date: Sat, 21 Jun 1997 00:43:55 +0000 (GMT) Cc: freebsd-current@freebsd.org X-Mailer: ELM [version 2.4ME+ PL31 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > It's a pity modems don't allow for retrieving the caller-ID afterwards, > > instead of spitting it out in realtime. The connect speed can be read > > back on request, probably even between active sessions. > > Connect speed is evil. The data rate should be driven with the > RS232C external clock for modems (described in the RS232C, Bell 103C, > and Bell 212 standards). The negotiation for speed should be done > at the carrier recognition, and not between the UART on the modem > and the UART in the computer. Terry, I think we are not describing the same thing here. I meant simply to record the line speed (modem to modem) established on connection (and retrain). This is not data rate, which on asynchronous modem DTE is regulated by handshaking. The incoming DTE link speed is constant. Oh, you are referring to the UART handshake? In that case I do not understand your comment about speed negotiation, unless you are referring to synchronous transfer. Concerning caller-ID storage by modem for later retrieval, I see that serious modems do this, but why Rockwell didn't include it is a total mystery to me. > This is an evil perpetrated on honest, God-fearing people by Intel > and National Semiconductor. Oh, it's a far bigger conspiracy than that. ;) > > Further to the discussion on the subject of (m)getty back in > > February, would it work to use DSR as RI for those ports > > without RI? > > 9 pins: > > chassis ground (evil waste of a pin) > TXD > RXD > RTS > CTS > DSR > signal ground > DCD > DTR Serious 9-pin ports put RI on pin 1. Chassis ground is available at the shielding. > I think the problem is that off-to-on DSR events are not interrupted > by the UART. Yeah, it would have been a hack anyway. > > AT&S1 DSR will become active after answer tone has been detected > > and inactive after the carrier has been lost, i.e. becomes active > > after RI and before CD (probably too late to catch caller-ID though?). > > Caller ID data is sent down the line between ring 1 and 2 when > using POTS lines in the US. For ISDN, caller ID data is sent > seperately. I still have the first Caller-ID to RS232 circuit I > built (look for the circuit in an old Radio Electronics or Popular > Electronics, I forget which). I could build or buy a circuit for each incoming line, but it makes better sense to have it builtin to the modem, especially when it already is. > > I'm not making any progress with using the modem init string capability. > > (DTR lights up but there is no flicker on TXD) > > Look at the CTS/RTS settings, and how they effect the modem and > UART in the DCD-not-present state, in particular. Are you saying I need a special cable because the software is a hack, or am I misconfiguring the software? > > How could this be farmed out to a separate process? > > You make a "modem driver" and seperate "inbound" vs. "outbound" > tty device operations. The main problem is that most of these > damn "do everything" getty programs like to initialize the modems > to a state which is optimal for them. This is the same reason > you can't share amodem between an intermittent ISP connection and > a FAX server on most Microsoft platforms. If there is a modem driver, getty does not have to meddle with the modem at all, correct? > > The whole point was that the user only gets the features requested via > > specific gettytab entries. Unless requested, they stay out of the way. > > Getty is the wrong place to do this. The corect thing for getty > to do is to listen to the inbound tty pseudo device (no, not pseudo > tty), and for a program to fan out the connection on the basis of > DCD and DTR state transitions. The RI stuff is a hack I suggested > to use as an inbound call marker; as you've discovered with 9 pin > ports, it's not a very good hack. 8-(. Better to support inbound > call fanning to voice/data/fax devices as seperate entities. There is no other marker of calls inbound. CD signals an established call. RI is much simpler to implement as an external circuit than CID, but if the serial port is broken by design then you take your chances. > There is actually one modem that creates two serial pseudo devices > under Windows95/NT: that's the Intel modem for telephony (I can't > tell you the model without going to the usability lab down the > hall, sorry). I *really* liked the modem, but obviously, it required > a per-modem driver to do its thing. It supported Caller-ID as well, > as a device ioctl (and supported providing your own calling-ID, too). Does this or any other readily available/affordable modem handle full duplex (simultaneous realtime) voice to data conversion that would be usable for an internet phone gateway? -- Adam David From owner-freebsd-current Sat Jun 21 00:23:23 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id AAA17465 for current-outgoing; Sat, 21 Jun 1997 00:23:23 -0700 (PDT) Received: from innocence.interface-business.de (innocence.interface-business.de [193.101.57.202]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id AAA17460 for ; Sat, 21 Jun 1997 00:23:17 -0700 (PDT) Received: (from root@localhost) by innocence.interface-business.de (8.6.11/8.6.9) with UUCP id JAA01783 for freebsd-current@FreeBSD.ORG; Sat, 21 Jun 1997 09:21:18 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.8.5/8.8.5) id JAA10058; Sat, 21 Jun 1997 09:09:24 +0200 (MET DST) Message-ID: <19970621090924.HW47363@uriah.heep.sax.de> Date: Sat, 21 Jun 1997 09:09:24 +0200 From: j@uriah.heep.sax.de (J Wunsch) To: freebsd-current@FreeBSD.ORG Subject: Re: getty modem control References: <19970620073506.MK21253@uriah.heep.sax.de> <199706200815.IAA15687@veda.is> X-Mailer: Mutt 0.60_p2-3,5,8-9 Mime-Version: 1.0 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199706200815.IAA15687@veda.is>; from Adam David on Jun 20, 1997 08:15:07 +0000 Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk As Adam David wrote: > Further to the discussion > on the subject of (m)getty back in February, would it work to use DSR as RI > for those ports without RI? I'm afraid not. > AT&S1 DSR will become active after answer tone has been detected and > inactive after the carrier has been lost, i.e. becomes active after > RI and before CD (probably too late to catch caller-ID though?). I have no ideas about caller-ID (it's not supported by the Deutsche Telekom on analog lines). Well, perhaps give it a try? > The whole point was that the user only gets the features requested via > specific gettytab entries. Unless requested, they stay out of the way. I realized this. But still, you make getty far more complex by adding this, and in particular, you're pulling an entire new class of problems into getty in the end: handling the various idiosyncrasies of various modems. As long as the regular getty demands an un-broken modem, one that can remember its speed for an incoming call, and that properly resets on each DTR drop, things are simple. Once you start to talk to modems, look at mgetty for the result. mgetty wasn't always that fat, but much of the code has been added to handle any oddball modem that can be found on this planet. -- 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 Jun 21 00:23:35 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id AAA17489 for current-outgoing; Sat, 21 Jun 1997 00:23:35 -0700 (PDT) Received: from innocence.interface-business.de (innocence.interface-business.de [193.101.57.202]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id AAA17479 for ; Sat, 21 Jun 1997 00:23:31 -0700 (PDT) Received: (from root@localhost) by innocence.interface-business.de (8.6.11/8.6.9) with UUCP id JAA01785 for freebsd-current@FreeBSD.ORG; Sat, 21 Jun 1997 09:21:25 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.8.5/8.8.5) id JAA10073; Sat, 21 Jun 1997 09:13:06 +0200 (MET DST) Message-ID: <19970621091306.KP10523@uriah.heep.sax.de> Date: Sat, 21 Jun 1997 09:13:06 +0200 From: j@uriah.heep.sax.de (J Wunsch) To: freebsd-current@FreeBSD.ORG Subject: Re: getty modem control References: <199706200815.IAA15687@veda.is> <199706202227.PAA24698@phaeton.artisoft.com> X-Mailer: Mutt 0.60_p2-3,5,8-9 Mime-Version: 1.0 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Reply-To: freebsd-current@FreeBSD.ORG In-Reply-To: <199706202227.PAA24698@phaeton.artisoft.com>; from Terry Lambert on Jun 20, 1997 15:27:38 -0700 Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk As Terry Lambert wrote: > > Further to the discussion on the subject of (m)getty back in > > February, would it work to use DSR as RI for those ports > > without RI? > > 9 pins: > > chassis ground (evil waste of a pin) > TXD > RXD > RTS > CTS > DSR > signal ground > DCD > DTR Wrong. Try again. The DB-9 connector doesn't have a protection ground pin. But it does have a ring indicator pin (pin 9). What they've been dropping was things like the external clock lines. So while it's not that evil that UART-equipped PC cards have only a DB-9, it's evil if modem manufacturers start to produce DB-9 equipped modems, since you cannot run them in (externally clocked) sync mode anymore. -- 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 Jun 21 06:10:43 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id GAA28562 for current-outgoing; Sat, 21 Jun 1997 06:10:43 -0700 (PDT) Received: from grunt.grondar.za (grunt.grondar.za [196.7.18.129]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id GAA28552; Sat, 21 Jun 1997 06:10:15 -0700 (PDT) Received: from greenpeace.grondar.za (greenpeace.grondar.za [196.7.18.132]) by grunt.grondar.za (8.8.5/8.8.5) with ESMTP id PAA17427; Sat, 21 Jun 1997 15:08:24 +0200 (SAT) Received: from greenpeace.grondar.za (localhost [127.0.0.1]) by greenpeace.grondar.za (8.8.5/8.8.5) with ESMTP id PAA09777; Sat, 21 Jun 1997 15:08:22 +0200 (SAT) Message-Id: <199706211308.PAA09777@greenpeace.grondar.za> X-Mailer: exmh version 2.0gamma 1/27/96 To: =?KOI8-R?B?4c7E0sXKIP7F0s7P1w==?= cc: Masafumi NAKANE/=?ISO-2022-JP?B?GyRCQ2Y6LDJtSjgbKEI=?= , freebsd-current@freebsd.org, markm@freebsd.org Subject: Re: international eBones broken? Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 21 Jun 1997 15:08:22 +0200 From: Mark Murray Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk =?KOI8-R?B?4c7E0sXKIP7F0s7P1w==?= wrote: > On Sat, 21 Jun 1997, Masafumi NAKANE/[ISO-2022-JP] $BCf:,2mJ8(B wrote: > > > Am I doing something wrong? Or is it something with the source? > > > > International repository must be upgraded to -current national, I already > send needed patch to markm, but still nothing happens. Many apologies for the delay. It has taken me quite a while to recover from being burgled, and one of the things that was still badly broken was my mail sorting stuff. I had you submission, but it got misfiled under "see later - not important" :-(. I have just committed it now. M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org From owner-freebsd-current Sat Jun 21 07:02:41 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id HAA29815 for current-outgoing; Sat, 21 Jun 1997 07:02:41 -0700 (PDT) Received: from smtp.enteract.com (qmailr@char-star.rdist.org [206.54.252.22]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id HAA29802 for ; Sat, 21 Jun 1997 07:02:36 -0700 (PDT) Received: (qmail 7171 invoked from network); 21 Jun 1997 14:02:35 -0000 Received: from enteract.com (mrfoine@206.54.252.1) by char-star.rdist.org with SMTP; 21 Jun 1997 14:02:35 -0000 Date: Sat, 21 Jun 1997 09:02:35 -0500 (CDT) From: Wayne Baety To: questions@freebsd.org, current@freebsd.org Subject: DCC protocol doesnt work in irc Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-437162281-866901755=:4542" Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --0-437162281-866901755=:4542 Content-Type: TEXT/PLAIN; charset=US-ASCII whenever i try to dcc a file...even to myself (in a new client window su'ed to another user) sending a file via DCC doesnt work but rather floods my consoles with : /kernel: ipx_ctlinput: cmd 15. what's going on?? Im using ipfw and pppd on ppp0 to make the inet connection. I attached some possibly relevant files. alaska /root % ipfw -a list 01200 3359 365608 divert 6136 ip from any to any via ppp0 01300 3428 378764 allow ip from any to any 65535 11 1557 deny ip from any to any now 6136 is natd attached to a divert socket... but this doesnt matter the same problem happens when I dont have rule 1200 and natd running. --0-437162281-866901755=:4542 Content-Type: TEXT/PLAIN; charset=US-ASCII; name=ALASKA-ISDN Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Kernel config Iw0KIyBHRU5FUklDIC0tIEdlbmVyaWMgbWFjaGluZSB3aXRoIFdEL0FIeC9O Q1IvQlR4IGZhbWlseSBkaXNrcw0KIw0KIyBGb3IgbW9yZSBpbmZvcm1hdGlv biByZWFkIHRoZSBoYW5kYm9vayBwYXJ0IFN5c3RlbSBBZG1pbmlzdHJhdGlv biAtPiANCiMgQ29uZmlndXJpbmcgdGhlIEZyZWVCU0QgS2VybmVsIC0+IFRo ZSBDb25maWd1cmF0aW9uIEZpbGUuIA0KIyBUaGUgaGFuZGJvb2sgaXMgYXZh aWxhYmxlIGluIC91c3Ivc2hhcmUvZG9jL2hhbmRib29rIG9yIG9ubGluZSBh cw0KIyBsYXRlc3QgdmVyc2lvbiBmcm9tIHRoZSBGcmVlQlNEIFdvcmxkIFdp ZGUgV2ViIHNlcnZlciANCiMgPFVSTDpodHRwOi8vd3d3LkZyZWVCU0QuT1JH Lz4NCiMNCiMgQW4gZXhoYXVzdGl2ZSBsaXN0IG9mIG9wdGlvbnMgYW5kIG1v cmUgZGV0YWlsZWQgZXhwbGFuYXRpb25zIG9mIHRoZSANCiMgZGV2aWNlIGxp bmVzIGlzIHByZXNlbnQgaW4gdGhlIC4vTElOVCBjb25maWd1cmF0aW9uIGZp bGUuIElmIHlvdSBhcmUgDQojIGluIGRvdWJ0IGFzIHRvIHRoZSBwdXJwb3Nl IG9yIG5lY2Vzc2l0eSBvZiBhIGxpbmUsIGNoZWNrIGZpcnN0IGluIExJTlQu DQojDQojCSRGcmVlQlNEJA0KDQptYWNoaW5lCQkiaTM4NiINCiNjcHUJCSJJ Mzg2X0NQVSINCmNwdQkJIkk0ODZfQ1BVIg0KY3B1CQkiSTU4Nl9DUFUiDQoj Y3B1CQkiSTY4Nl9DUFUiDQppZGVudAkJQUxBU0tBLUlTRE4NCm1heHVzZXJz CTYwDQoNCm9wdGlvbnMJCUlORVQJCQkjSW50ZXJORVR3b3JraW5nDQoNCg0K IyMjIEZpbGUgU3lzdGVtcw0Kb3B0aW9ucwkJRkZTCQkJI0JlcmtlbGV5IEZh c3QgRmlsZXN5c3RlbQ0Kb3B0aW9ucwkJTkZTCQkJI05ldHdvcmsgRmlsZXN5 c3RlbQ0Kb3B0aW9ucwkJTVNET1NGUwkJCSNNU0RPUyBGaWxlc3lzdGVtDQpv cHRpb25zCQkiQ0Q5NjYwIgkJI0lTTyA5NjYwIEZpbGVzeXN0ZW0NCm9wdGlv bnMJCSJDRDk2NjBfUk9PVERFTEFZPTIwIgkjSVNPIDk2NjAgZGVsYXkgdGlt ZSBpbiBzZWNvbmRzDQpvcHRpb25zCQlQUk9DRlMJCQkjUHJvY2VzcyBmaWxl c3lzdGVtDQpvcHRpb25zICAgICAgICAgREVWRlMgICAgICAgICAgICAgICAg ICAgI2RldmljZXMgZmlsZXN5c3RlbQ0KDQpvcHRpb25zICAgICAgICAgUVVP VEENCiMjIyMNCg0KDQpvcHRpb25zCQkiQ09NUEFUXzQzIgkJI0NvbXBhdGli bGUgd2l0aCBCU0QgNC4zIFtLRUVQIFRISVMhXQ0Kb3B0aW9ucwkJU0NTSV9E RUxBWT0xNQkJI0JlIHBlc3NpbWlzdGljIGFib3V0IEpvZSBTQ1NJIGRldmlj ZQ0Kb3B0aW9ucwkJQk9VTkNFX0JVRkZFUlMJCSNpbmNsdWRlIHN1cHBvcnQg Zm9yIERNQSBib3VuY2UgYnVmZmVycw0Kb3B0aW9ucwkJVUNPTlNPTEUJCSNB bGxvdyB1c2VycyB0byBncmFiIHRoZSBjb25zb2xlDQpvcHRpb25zCQlGQUlM U0FGRQkJI0JlIGNvbnNlcnZhdGl2ZQ0Kb3B0aW9ucwkJVVNFUkNPTkZJRwkJ I2Jvb3QgLWMgZWRpdG9yDQpvcHRpb25zCQlWSVNVQUxfVVNFUkNPTkZJRwkj dmlzdWFsIGJvb3QgLWMgZWRpdG9yDQpvcHRpb25zICAgICAgICAgVVNFUl9M RFQNCm9wdGlvbnMgICAgICAgICBTWVNWU0hNDQpvcHRpb25zICAgICAgICAg U1lTVlNFTQ0Kb3B0aW9ucyAgICAgICAgIFNZU1ZNU0cNCm9wdGlvbnMgICAg ICAgICAiTUQ1Ig0Kb3B0aW9ucyAgICAgICAgIFBFUkZNT04NCm9wdGlvbnMg ICAgICAgICBJUFgNCm9wdGlvbnMgICAgICAgICBJUFhJUA0Kb3B0aW9ucyAg ICAgICAgIElQVFVOTkVMDQpvcHRpb25zICAgICAgICAgSVBYUFJJTlRGUz0w DQpvcHRpb25zICAgICAgICAgSVBYX0VSUlBSSU5URlM9MA0Kb3B0aW9ucyAg ICAgICAgIE5FVEFUQUxLDQpvcHRpb25zCQlLVFJBQ0UJCSNrZXJuZWwgdHJh Y2luZw0Kb3B0aW9ucwkJQVRBUEkJCSNFbmFibGUgQVRBUEkgc3VwcG9ydCBm b3IgSURFIGJ1cw0Kb3B0aW9ucwkJQVRBUElfU1RBVElDCSNEb24ndCBkbyBp dCBhcyBhbiBMS00NCm9wdGlvbnMJCVhTRVJWRVIJCSMgaW5jbHVkZSBjb2Rl IGZvciBYRnJlZTg2DQpvcHRpb25zICAgICAgICAgSVBGSVJFV0FMTA0Kb3B0 aW9ucyAgICAgICAgIElQRklSRVdBTExfVkVSQk9TRQ0Kb3B0aW9ucyAgICAg ICAgIElQRklSRVdBTExfVkVSQk9TRV9MSU1JVD01MA0Kb3B0aW9ucwkJSVBB Q0NUDQpvcHRpb25zCQlNUk9VVElORw0Kb3B0aW9ucwkJVENQREVCVUcNCm9w dGlvbnMJCUlQRElWRVJUDQpvcHRpb25zCQlERUJVR19JUEZJUkVXQUxMDQpv cHRpb25zICAgICAgICAgSVBGT1JXQVJESU5HPTENCiNvcHRpb25zCQlJUEZJ TFRFUl9MS00JI21vZHVsZSB2ZXJzaW9uDQojb3B0aW9ucwkJSVBGSUxURVJf TE9HCSNzdXBwb3J0IGxvZ2dpbmcgKGluLWtlcm5lbCkNCg0KY29uZmlnCQlr ZXJuZWwJcm9vdCBvbiB3ZDANCg0KY29udHJvbGxlcglpc2EwDQojY29udHJv bGxlcgllaXNhMA0KY29udHJvbGxlcglwY2kwDQoNCmNvbnRyb2xsZXIJZmRj MAlhdCBpc2E/IHBvcnQgIklPX0ZEMSIgYmlvIGlycSA2IGRycSAyIHZlY3Rv ciBmZGludHINCmRpc2sJCWZkMAlhdCBmZGMwIGRyaXZlIDANCg0KI2Rpc2sJ CWZkMQlhdCBmZGMwIGRyaXZlIDENCiN0YXBlCQlmdDAJYXQgZmRjMCBkcml2 ZSAyDQoNCmNvbnRyb2xsZXIJd2RjMAlhdCBpc2E/IHBvcnQgIklPX1dEMSIg YmlvIGlycSAxNCB2ZWN0b3Igd2RpbnRyDQpkaXNrCQl3ZDAJYXQgd2RjMCBk cml2ZSAwDQpkaXNrCQl3ZDEJYXQgd2RjMCBkcml2ZSAxDQoNCmNvbnRyb2xs ZXIJd2RjMQlhdCBpc2E/IHBvcnQgIklPX1dEMiIgYmlvIGlycSAxNSB2ZWN0 b3Igd2RpbnRyDQpkaXNrCQl3ZDIJYXQgd2RjMSBkcml2ZSAwDQpkaXNrCQl3 ZDMJYXQgd2RjMSBkcml2ZSAxDQoNCmRldmljZQkJd2NkMAkjSURFIENELVJP TQ0KDQojIHN5c2NvbnMgaXMgdGhlIGRlZmF1bHQgY29uc29sZSBkcml2ZXIs IHJlc2VtYmxpbmcgYW4gU0NPIGNvbnNvbGUNCmRldmljZQkJc2MwCWF0IGlz YT8gcG9ydCAiSU9fS0JEIiB0dHkgaXJxIDEgdmVjdG9yIHNjaW50cg0Kb3B0 aW9ucwkJTUFYQ09OUz0xNg0KDQojIE1hbmRhdG9yeSwgZG9uJ3QgcmVtb3Zl DQpkZXZpY2UJCW5weDAJYXQgaXNhPyBwb3J0ICJJT19OUFgiIGlycSAxMyB2 ZWN0b3IgbnB4aW50cg0KDQojDQojIExhcHRvcCBzdXBwb3J0IChzZWUgTElO VCBmb3IgbW9yZSBvcHRpb25zKQ0KIw0KZGV2aWNlCQlhcG0wICAgIGF0IGlz YT8JICAgICAgICAjIEFkdmFuY2VkIFBvd2VyIE1hbmFnZW1lbnQNCm9wdGlv bnMJCUFQTV9CUk9LRU5fU1RBVENMT0NLCSMgV29ya2Fyb3VuZCBzb21lIGJ1 Z2d5IEFQTSBCSU9TDQoNCmRldmljZQkJc2lvMAlhdCBpc2E/IHBvcnQgIklP X0NPTTEiIHR0eSBpcnEgNCB2ZWN0b3Igc2lvaW50cg0KZGV2aWNlCQlzaW8x CWF0IGlzYT8gcG9ydCAiSU9fQ09NMiIgdHR5IGlycSAzIHZlY3RvciBzaW9p bnRyDQpkZXZpY2UJCXNpbzIJYXQgaXNhPyBkaXNhYmxlIHBvcnQgIklPX0NP TTMiIHR0eSBpcnEgNSB2ZWN0b3Igc2lvaW50cg0KZGV2aWNlCQlzaW8zCWF0 IGlzYT8gZGlzYWJsZSBwb3J0ICJJT19DT000IiB0dHkgaXJxIDkgdmVjdG9y IHNpb2ludHINCg0KZGV2aWNlCQlscHQwCWF0IGlzYT8gcG9ydD8gdHR5IGly cSA3IHZlY3RvciBscHRpbnRyDQpkZXZpY2UJCWxwdDEJYXQgaXNhPyBwb3J0 PyB0dHkNCg0KDQpkZXZpY2UgZWQwIGF0IGlzYT8gZGlzYWJsZSBwb3J0IDB4 MjgwIG5ldCBpcnEgIDUgaW9tZW0gMHhkODAwMCB2ZWN0b3IgZWRpbnRyDQpk ZXZpY2UgZWQxIGF0IGlzYT8gcG9ydCAweDMwMCBuZXQgaXJxICAxMSBpb21l bSAweGQ4MDAwIHZlY3RvciBlZGludHINCg0KcHNldWRvLWRldmljZSAgIHNu cCAgICAgMyAgIA0KcHNldWRvLWRldmljZQlsb29wDQpwc2V1ZG8tZGV2aWNl CWV0aGVyDQpwc2V1ZG8tZGV2aWNlCWxvZw0KcHNldWRvLWRldmljZQlzbAky DQpwc2V1ZG8tZGV2aWNlICAgZmRkaQ0KcHNldWRvLWRldmljZSAgIHNwcHAN CnBzZXVkby1kZXZpY2UgICBicGZpbHRlciAgICA0DQpwc2V1ZG8tZGV2aWNl ICAgZGlzYw0KIyBpanBwcCB1c2VzIHR1biBpbnN0ZWFkIG9mIHBwcCBkZXZp Y2UNCnBzZXVkby1kZXZpY2UJcHBwCTINCnBzZXVkby1kZXZpY2UJdHVuCTEN CnBzZXVkby1kZXZpY2UJcHR5CTE2DQpwc2V1ZG8tZGV2aWNlCWd6aXAJCSMg RXhlYyBnemlwcGVkIGEub3V0J3MNCnBzZXVkby1kZXZpY2UJdm4NCg0KDQoj LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQojDQojCUJJU0ROIC0g cGFydHMgb2YgYW4gZXhhbXBsZSBjb25maWcgZmlsZSBmb3IgYmlzZG4NCiMJ LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLQ0KIw0KIwlsYXN0IGVkaXQtZGF0ZTogW01vbiBKdW4gIDMgMTM6MjY6 NTEgMTk5Nl0NCiMNCiMtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0N Cg0Kb3B0aW9ucwlJUElfVkoJCQkjIFZhbiBKYWNvYnNlbiBoZWFkZXIgY29t cHJlc3Npb24gc3VwcG9ydA0Kb3B0aW9ucwkiSVBJX0RJUEE9MyIJCSMgc2Vu ZCBpcCBhY2NvdW50aW5nIHBhY2tldHMgZXZlcnkgMyBzZWNvbmRzDQpvcHRp b25zCVRFTEVTX0hBU19NRU1DUFlCCSMgc3VwcG9ydCBvZiBpc2RuICANCg0K IyBUZWxlcyBTMC84CSMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyBJUlEgIDkgIyMNCiNjb250cm9sbGVy CXRlbDAgYXQgaXNhPyBpb21lbSAweGRjMDAwIG5ldCBpcnEgOSB2ZWN0b3Ig dGVsaW50cg0KIyBUZWxlcyBTMC8xNgkjIyMjIyMjIyMjIyMjIyMjIyMjIyMj IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMgSVJRICA5ICMjDQoj Y29udHJvbGxlcgl0ZWwwIGF0IGlzYT8gcG9ydCAweGQ4MCBpb21lbSAweGRj MDAwIG5ldCBpcnEgOSB2ZWN0b3IgdGVsaW50cg0KIyBUZWxlcyBTMC8xNi4z CSMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj IyMjIyMjIyMjIyBJUlEgIDkgIyMNCmNvbnRyb2xsZXIJdGVsMCBhdCBpc2E/ IHBvcnQgMHhkODAgbmV0IGlycSA1IHZlY3RvciB0ZWxpbnRyDQpwc2V1ZG8t ZGV2aWNlCWRpc2RuDQpwc2V1ZG8tZGV2aWNlCWlzZG4NCnBzZXVkby1kZXZp Y2UJaXBpCTINCnBzZXVkby1kZXZpY2UJaXBwCTINCnBzZXVkby1kZXZpY2UJ aXRlbAkxDQpwc2V1ZG8tZGV2aWNlCWlzcHkJMQ0K --0-437162281-866901755=:4542 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="rc.conf" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: System Config file IyEvYmluL3NoDQojDQoNCiMgVGhpcyBpcyByYy5jb25mIC0gYSBmaWxlIGZ1 bGwgb2YgdXNlZnVsIHZhcmlhYmxlcyB0aGF0IHlvdSBjYW4gc2V0IA0KIyB0 byBjaGFuZ2UgdGhlIGRlZmF1bHQgc3RhcnR1cCBiZWhhdmlvciBvZiB5b3Vy IHN5c3RlbS4NCiMNCiMgQWxsIGFyZ3VtZW50cyBtdXN0IGJlIGluIGRvdWJs ZSBvciBzaW5nbGUgcXVvdGVzLg0KIw0KIwkkSWQ6IHJjLmNvbmYsdiAxLjE4 IDE5OTcvMDYvMTggMTY6MDE6MTkgcHN0IEV4cCAkDQoNCiMjIyMjIyMjIyMj IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj IyMjIyMjDQojIyMgSW1wb3J0YW50IGluaXRpYWwgQm9vdC10aW1lIG9wdGlv bnMgICMjIyMjIyMjIyMjIyMjIyMjIyMjIw0KIyMjIyMjIyMjIyMjIyMjIyMj IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMN Cg0Kc3dhcGZpbGU9Ik5PIgkJIyBTZXQgdG8gbmFtZSBvZiBzd2FwZmlsZSBp ZiBhdXggc3dhcGZpbGUgZGVzaXJlZC4NCmFwbV9lbmFibGU9IllFUyIJIyBT ZXQgdG8gWUVTIGlmIHlvdSB3YW50IEFQTSBlbmFibGVkLg0KcGNjYXJkX2Vu YWJsZT0iTk8iCSMgU2V0IHRvIFlFUyBpZiB5b3Ugd2FudCB0byBjb25maWd1 cmUgUENDQVJEIGRldmljZXMuDQpwY2NhcmRfbWVtPSJERUZBVUxUIgkjIElm IHBjY2FyZF9lbmFibGU9WUVTLCB0aGlzIGlzIGNhcmQgbWVtb3J5IGFkZHJl c3MuDQpwY2NhcmRfaWZjb25maWc9Ik5PIgkjIFNwZWNpYWxpemVkIHBjY2Fy ZCBldGhlcm5ldCBjb25maWd1cmF0aW9uIChvciBOTykuDQpsb2NhbF9zdGFy dHVwPSIvdXNyL2xvY2FsL2V0Yy9yYy5kIC91c3IvWDExUjYvZXRjL3JjLmQi CSMgc3RhcnR1cCBzY3JpcHQgZGlycy4NCg0KDQojIyMjIyMjIyMjIyMjIyMj IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj Iw0KIyMjICBOZXR3b3JrIGNvbmZpZ3VyYXRpb24gc3ViLXNlY3Rpb24gICMj IyMjIyMjIyMjIyMjIyMjIyMjIyMNCiMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjDQoNCiMj IyBCYXNpYyBuZXR3b3JrIG9wdGlvbnM6ICMjIw0KaG9zdG5hbWU9ImFsYXNr YS5vcmlnaW5hbHN0b3Jlcy5jb20iCSMgU2V0IHRoaXMhDQpuaXNkb21haW5u YW1lPSJuaXMubGFuLWV0aDEiCQkjIFNldCB0byBOSVMgZG9tYWluIGlmIHVz aW5nIE5JUyAob3IgTk8pLg0KZmlyZXdhbGw9Im9wZW4iCQkJIyBmaXJld2Fs bCB0eXBlIChzZWUgL2V0Yy9yYy5maXJld2FsbCkgb3IgTk8uDQp0Y3BfZXh0 ZW5zaW9ucz0iWUVTIgkJIyBBbGxvdyBSRkMxMzIzICYgUkZDMTU0NCBleHRl bnNpb25zIChvciBOTykuDQpuZXR3b3JrX2ludGVyZmFjZXM9ImxvMCBlZDIg cHBwMCIgIyBMaXN0IG9mIG5ldHdvcmsgaW50ZXJmYWNlcyAobG8wIGlzIGxv b3BiYWNrKS4NCmlmY29uZmlnX2xvMD0iaW5ldCAxMjcuMC4wLjEiCSMgZGVm YXVsdCBsb29wYmFjayBkZXZpY2UgY29uZmlndXJhdGlvbi4NCmlmY29uZmln X2VkMj0iaW5ldCAxOTIuMTY4LjEuMSBuZXRtYXNrIDI1NS4yNTUuMjU1LjAg YXJwIHBoYXNlIDIiDQppZmNvbmZpZ19wcHAwPSJpbmV0IDEwLjAuMC4xIDE5 NC42NC40LjcgbmV0bWFzayAyNTUuMjU1LjI1NS4wIg0KI2lmY29uZmlnX2xv MF9hbGlhczA9ImluZXQgMTI3LjAuMC4yNTQgbmV0bWFzayAweGZmZmZmZmZm IiAjIFNhbXBsZSBhbGlhcyBlbnRyeS4NCg0KIyMjIE5ldHdvcmsgZGFlbW9u IChtaXNjZWxsYW5lb3VzKSAmIE5GUyBvcHRpb25zOiAjIyMNCnN5c2xvZ2Rf ZW5hYmxlPSJZRVMiCQkjIFJ1biBzeXNsb2cgZGFlbW9uIChvciBOTykuDQpz eXNsb2dkX2ZsYWdzPSIiCQkjIEZsYWdzIHRvIHN5c2xvZ2QgKGlmIGVuYWJs ZWQpLg0KaW5ldGRfZW5hYmxlPSJZRVMiCQkjIFJ1biB0aGUgbmV0d29yayBk YWVtb24gZGlzcGxhdGNoZXIgKG9yIE5PKS4NCmluZXRkX2ZsYWdzPSIiCQkJ IyBPcHRpb25hbCBmbGFncyB0byBpbmV0ZA0KbmFtZWRfZW5hYmxlPSJZRVMi CQkjIFJ1biBuYW1lZCwgdGhlIEROUyBzZXJ2ZXIgKG9yIE5PKS4NCm5hbWVk X2ZsYWdzPSItYiAvZXRjL25hbWVkYi9uYW1lZC5ib290IiAjIEZsYWdzIHRv IG5hbWVkIChpZiBlbmFibGVkKS4NCmtlcmJlcm9zX3NlcnZlcl9lbmFibGU9 IllFUyIJIyBSdW4gYSBrZXJiZXJvcyBtYXN0ZXIgc2VydmVyIChvciBOTyku DQpyd2hvZF9lbmFibGU9IllFUyIJCSMgUnVuIHRoZSByd2hvIGRhZW1vbiAo b3IgTk8pLg0KYW1kX2VuYWJsZT0iTk8iCQkJIyBSdW4gYW1kIHNlcnZpY2Ug d2l0aCAkYW1kX2ZsYWdzIChvciBOTykuDQphbWRfZmxhZ3M9Ii1hIC9uZXQg LWMgMTgwMCAtayBpMzg2IC1kIG15LmRvbWFpbiAtbCBzeXNsb2cgL2hvc3Qg L2V0Yy9hbWQubWFwIg0KbmZzX2NsaWVudF9lbmFibGU9Ik5PIgkJIyBUaGlz IGhvc3QgaXMgYW4gTkZTIGNsaWVudCAob3IgTk8pLg0KbmZzX2NsaWVudF9m bGFncz0iLW4gNCIJCSMgRmxhZ3MgdG8gbmZzaW9kIChpZiBlbmFibGVkKS4N Cm5mc19zZXJ2ZXJfZW5hYmxlPSJOTyIJCSMgVGhpcyBob3N0IGlzIGFuIE5G UyBzZXJ2ZXIgKG9yIE5PKS4NCm5mc19zZXJ2ZXJfZmxhZ3M9Ii11IC10IDQi CSMgRmxhZ3MgdG8gbmZzZCAoaWYgZW5hYmxlZCkuDQp3ZWFrX21vdW50ZF9h dXRoZW50aWNhdGlvbj0iTk8iCSMgUnVubmluZyBQQ05GU0QgLyBvdGhlciBu b24tcm9vdCBuZnNkIChvciBOTykuDQpuZnNfcmVzZXJ2ZWRfcG9ydF9vbmx5 PSJOTyIJIyBQcm92aWRlIE5GUyBvbmx5IG9uIHNlY3VyZSBwb3J0IChvciBO TykuDQpycGNfbG9ja2RfZW5hYmxlPSJOTyIJCSMgUnVuIE5GUyBycGMubG9j a2QgKCpicm9rZW4hKikgaWYgbmZzX3NlcnZlci4NCnJwY19zdGF0ZF9lbmFi bGU9IllFUyIJCSMgUnVuIE5GUyBycGMuc3RhdGQgaWYgbmZzX3NlcnZlciAo b3IgTk8pLg0KcG9ydG1hcF9lbmFibGU9IllFUyIJCSMgUnVuIHRoZSBwb3J0 bWFwcGVyIHNlcnZpY2UgKG9yIE5PKS4NCnBvcnRtYXBfZmxhZ3M9IiIJCSMg RmxhZ3MgdG8gcG9ydG1hcCAoaWYgZW5hYmxlZCkuDQp4dGVuZF9lbmFibGU9 Ik5PIgkJIyBSdW4gdGhlIFgtMTAgcG93ZXIgY29udHJvbGxlciBkYWVtb24u DQp4dGVuZF9mbGFncz0iIgkJCSMgRmxhZ3MgdG8geHRlbmQgKGlmIGVuYWJs ZWQpLg0KDQojIyMgTmV0d29yayBUaW1lIFNlcnZpY2VzIG9wdGlvbnM6ICMj Iw0KdGltZWRfZW5hYmxlPSJOTyIJCSMgUnVuIHRoZSB0aW1lIGRhZW1vbiAo b3IgTk8pLg0KdGltZWRfZmxhZ3M9IiIJCQkjIEZsYWdzIHRvIHRpbWVkIChp ZiBlbmFibGVkKS4NCm50cGRhdGVfZW5hYmxlPSJOTyIJCSMgUnVuIHRoZSBu dHBkYXRlIHRvIHN5bmMgdGltZSAob3IgTk8pLg0KbnRwZGF0ZV9mbGFncz0i IgkJIyBGbGFncyB0byBudHBkYXRlIChpZiBlbmFibGVkKS4NCnhudHBkX2Vu YWJsZT0iTk8iCQkjIFJ1biB4bnRwZCBOZXR3b3JrIFRpbWUgUHJvdG9jb2wg KG9yIE5PKS4NCnhudHBkX2ZsYWdzPSIiCQkJIyBGbGFncyB0byB4bnRwZCAo aWYgZW5hYmxlZCkuDQp0aWNrYWRqX2VuYWJsZT0iTk8iCQkjIFJ1biB0aWNr YWRqIChvciBOTykuDQp0aWNrYWRqX2ZsYWdzPSItQXEiCQkjIEZsYWdzIHRv IHRpY2thZGogKGlmIGVuYWJsZWQpLg0KDQojIE5ldHdvcmsgSW5mb3JtYXRp b24gU2VydmljZXMgKE5JUykgb3B0aW9uczogIyMjDQpuaXNfY2xpZW50X2Vu YWJsZT0iTk8iCQkjIFdlJ3JlIGFuIE5JUyBjbGllbnQgKG9yIE5PKQ0Kbmlz X2NsaWVudF9mbGFncz0iIgkJIyBGbGFncyB0byB5cGJpbmQgKGlmIGVuYWJs ZWQpLg0KbmlzX3lwc2V0X2VuYWJsZT0iTk8iCQkjIFJ1biB5cHNldCBhdCBi b290IHRpbWUgKG9yIE5PKS4NCm5pc195cHNldF9mbGFncz0iIgkJIyBGbGFn cyB0byB5cHNldCAoaWYgZW5hYmxlZCkuDQpuaXNfc2VydmVyX2VuYWJsZT0i Tk8iCQkjIFdlJ3JlIGFuIE5JUyBzZXJ2ZXIgKG9yIE5PKQ0KbmlzX3NlcnZl cl9mbGFncz0iIgkJIyBGbGFncyB0byB5cHNlcnYgKGlmIGVuYWJsZWQpLg0K bmlzX3lweGZyZF9lbmFibGU9Ik5PIgkJIyBSdW4gcnBjLnlweGZyZCBhdCBi b290IHRpbWUgKG9yIE5PKS4NCm5pc195cHhmcmRfZmxhZ3M9IiIJCSMgRmxh Z3MgdG8gcnBjLnlweGZyZCAoaWYgZW5hYmxlZCkuDQpuaXNfeXBwYXNzd2Rk X2VuYWJsZT0iTk8iCSMgUnVuIHJwYy55cHBhc3N3ZGQgYXQgYm9vdCB0aW1l IChvciBOTykuDQpuaXNfeXBwYXNzd2RkX2ZsYWdzPSIiCQkjIEZsYWdzIHRv IHJwYy55cHBhc3N3ZGQgKGlmIGVuYWJsZWQpLg0KDQojIyMgTmV0d29yayBy b3V0aW5nIG9wdGlvbnM6ICMjIw0KZGVmYXVsdHJvdXRlcj0iMTk0LjY0LjQu NyIJIyBTZXQgdG8gZGVmYXVsdCBnYXRld2F5IChvciBOTykuDQpzdGF0aWNf cm91dGVzPSJsb29wYmFjayIJIyBTZXQgdG8gc3RhdGljIHJvdXRlIGxpc3Qg KG9yIGxlYXZlIGVtcHR5KS4NCnJvdXRlX2xvb3BiYWNrPSIke2hvc3RuYW1l fSBsb2NhbGhvc3QiDQpnYXRld2F5X2VuYWJsZT0iWUVTIgkJIyBTZXQgdG8g WUVTIGlmIHRoaXMgaG9zdCB3aWxsIGJlIGEgZ2F0ZXdheS4NCnJvdXRlcl9l bmFibGU9Ik5PIgkJIyBTZXQgdG8gWUVTIHRvIGVuYWJsZSBhIHJvdXRpbmcg ZGFlbW9uLg0Kcm91dGVyPSJyb3V0ZWQiCQkJIyBOYW1lIG9mIHJvdXRpbmcg ZGFlbW9uIHRvIHVzZSBpZiBlbmFibGVkLg0Kcm91dGVyX2ZsYWdzPSItcSIJ CSMgRmxhZ3MgZm9yIHJvdXRpbmcgZGFlbW9uLg0KbXJvdXRlZF9lbmFibGU9 Ik5PIgkJIyBEbyBtdWx0aWNhc3Qgcm91dGluZyAoc2VlIC9ldGMvbXJvdXRl ZC5jb25mKQ0KaXB4Z2F0ZXdheV9lbmFibGU9Ik5PIgkJIyBTZXQgdG8gWUVT IHRvIGVuYWJsZSBJUFggcm91dGluZy4NCmlweHJvdXRlZF9lbmFibGU9Ik5P IgkJIyBTZXQgdG8gWUVTIHRvIHJ1biB0aGUgSVBYIHJvdXRpbmcgZGFlbW9u Lg0KaXB4cm91dGVkX2ZsYWdzPSIiCQkjIEZsYWdzIGZvciBJUFggcm91dGlu ZyBkYWVtb24uDQphcnBwcm94eV9hbGw9IiIJCQkjIHJlcGxhY2VzIG9ic29s ZXRlIGtlcm5lbCBvcHRpb24gQVJQX1BST1hZX0FMTA0KDQoNCiMjIyMjIyMj IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj IyMjIyMjIyMjDQojIyMgIFN5c3RlbSBjb25zb2xlIG9wdGlvbnMgICMjIyMj IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIw0KIyMjIyMjIyMjIyMjIyMj IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj IyMNCg0Ka2V5bWFwPSJnZXJtYW4uY3A4NTAiCSMga2V5bWFwIGluIC91c3Iv c2hhcmUvc3lzY29ucy9rZXltYXBzLyogKG9yIE5PKS4NCmtleXJhdGU9ImZh c3QiCQkjIGtleWJvYXJkIHJhdGUgdG86IHNsb3csIG5vcm1hbCwgZmFzdCAo b3IgTk8pLg0Ka2V5YmVsbD0ibm9ybWFsIgkjIGJlbGwgdG8gZHVyYXRpb24u cGl0Y2ggb3Igbm9ybWFsIG9yIHZpc3VhbCAob3IgTk8pLg0Ka2V5Y2hhbmdl PSJOTyIJCSMgZnVuY3Rpb24ga2V5cyBkZWZhdWx0IHZhbHVlcyAob3IgTk8p Lg0KY3Vyc29yPSJub3JtYWwiCQkjIGN1cnNvciB0eXBlIHtub3JtYWx8Ymxp bmt8ZGVzdHJ1Y3RpdmV9IChvciBOTykuDQpzY3JubWFwPSJOTyIJCSMgc2Ny ZWVuIG1hcCBpbiAvdXNyL3NoYXJlL3N5c2NvbnMvc2Nybm1hcHMvKiAob3Ig Tk8pLg0KZm9udDh4MTY9Imlzby04eDE2IgkjIGZvbnQgOHgxNiBmcm9tIC91 c3Ivc2hhcmUvc3lzY29ucy9mb250cy8qIChvciBOTykuDQpmb250OHgxND0i aXNvLTh4MTQiCSMgZm9udCA4eDE0IGZyb20gL3Vzci9zaGFyZS9zeXNjb25z L2ZvbnRzLyogKG9yIE5PKS4NCmZvbnQ4eDg9Imlzby04eDgiCSMgZm9udCA4 eDggZnJvbSAvdXNyL3NoYXJlL3N5c2NvbnMvZm9udHMvKiAob3IgTk8pLg0K Ymxhbmt0aW1lPSIzMDAiCQkjIGJsYW5rIHRpbWUgKGluIHNlY29uZHMpIG9y ICJOTyIgdG8gdHVybiBpdCBvZmYuDQpzYXZlcj0iZ3JlZW4iICAgICAgICAg ICAjIHNjcmVlbiBzYXZlcjogYmxhbmsvZGFlbW9uL2dyZWVuL3NuYWtlL3N0 YXIvTk8uDQptb3VzZWRfdHlwZT0ibWljcm9zb2Z0IgkjIFNlZSBtYW4gcGFn ZSBmb3IgcmMuY29uZig4KSBmb3IgYXZhaWxhYmxlIHNldHRpbmdzLg0KbW91 c2VkX3BvcnQ9Ii9kZXYvY3VhYTAiICMgU2V0IHRvIHlvdXIgbW91c2UgcG9y dCAocmVxdWlyZWQgaWYgbW91c2V0eXBlIHNldCkNCm1vdXNlZF9mbGFncz0i IgkJIyBBbnkgYWRkaXRpb25hbCBmbGFncyB0byBtb3VzZWQuDQoNCg0KIyMj IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj IyMjIyMjIyMjIyMjIyMNCiMjIyAgTWlzY2VsbGFuZW91cyBhZG1pbmlzdHJh dGl2ZSBvcHRpb25zICAjIyMjIyMjIyMjIyMjIyMjIyMjDQojIyMjIyMjIyMj IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj IyMjIyMjIw0KDQpjcm9uX2VuYWJsZT0iWUVTIgkjIFJ1biB0aGUgcGVyaW9k aWMgam9iIGRhZW1vbg0KbHBkX2VuYWJsZT0iWUVTIgkjIFJ1biB0aGUgbGlu ZSBwcmludGVyIGRhZW1vbg0KbHBkX2ZsYWdzPSIiCQkjIEZsYWdzIHRvIGxw ZCAoaWYgZW5hYmxlZCkuDQpzZW5kbWFpbF9lbmFibGU9IllFUyIJIyBSdW4g dGhlIHNlbmRtYWlsIGRhZW1vbiAob3IgTk8pLg0Kc2VuZG1haWxfZmxhZ3M9 Ii1iZCAtcTMwbSIgIyAtYmQgaXMgcHJldHR5IG1hbmRhdG9yeQ0Kc2F2ZWNv cmVfZW5hYmxlPSJOTyIJIyBTYXZlIGtlcm5lbCBjcmFzaGR1bXBzIGZvciBk ZWJ1Z2dpbmcgKG9yIE5PKS4NCmR1bXBkZXY9Ik5PIgkJIyBEZXZpY2UgbmFt ZSB0byBjcmFzaGR1bXAgdG8gKGlmIGVuYWJsZWQpLg0KY2hlY2tfcXVvdGFz PSJZRVMiCSMgQ2hlY2sgcXVvdGFzIChvciBOTykuDQphY2NvdW50aW5nX2Vu YWJsZT0iWUVTIgkjIFR1cm4gb24gcHJvY2VzcyBhY2NvdW50aW5nIChvciBO TykuDQppYmNzMl9lbmFibGU9IllFUyIJIyBJYmNzMiAoU0NPKSBlbXVsYXRp b24gbG9hZGVkIGF0IHN0YXJ0dXAgKG9yIE5PKS4NCmxpbnV4X2VuYWJsZT0i WUVTIgkjIExpbnV4IGVtdWxhdGlvbiBsb2FkZWQgYXQgc3RhcnR1cCAob3Ig Tk8pLg0KcmFuZF9pcnFzPSJOTyIJCSMgU3RpciB0aGUgZW50cm9weSBwb29s IChsaWtlIC1zNSAtczExIG9yIE5PKS4NCg0KIyMjIyMjIyMjIyMjIyMjIyMj IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMN CiMjIyBBbGxvdyBsb2NhbCBjb25maWd1cmF0aW9uIG92ZXJyaWRlIGF0IHRo ZSB2ZXJ5IGVuZCBoZXJlICMjDQojIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIw0KaWYgWyAt ZiAvZXRjL3JjLmNvbmYubG9jYWwgXTsgdGhlbg0KCS4gL2V0Yy9yYy5jb25m LmxvY2FsDQpmaQ0K --0-437162281-866901755=:4542-- From owner-freebsd-current Sat Jun 21 11:31:56 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id LAA12932 for current-outgoing; Sat, 21 Jun 1997 11:31:56 -0700 (PDT) Received: from whizzo.TransSys.COM (whizzo.TransSys.COM [144.202.42.10]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id LAA12927 for ; Sat, 21 Jun 1997 11:31:54 -0700 (PDT) Received: from localhost.transsys.com (localhost.transsys.com [127.0.0.1]) by whizzo.TransSys.COM (8.8.5/8.7.3) with SMTP id OAA22108; Sat, 21 Jun 1997 14:30:55 -0400 (EDT) Message-Id: <199706211830.OAA22108@whizzo.TransSys.COM> X-Mailer: exmh version 2.0delta 6/3/97 To: Terry Lambert cc: adam@veda.is (Adam David), joerg_wunsch@uriah.heep.sax.de, freebsd-current@FreeBSD.ORG From: "Louis A. Mamakos" Subject: Re: getty modem control References: <199706202227.PAA24698@phaeton.artisoft.com> In-reply-to: Your message of "Fri, 20 Jun 1997 15:27:38 PDT." <199706202227.PAA24698@phaeton.artisoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 21 Jun 1997 14:30:55 -0400 Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > Connect speed is evil. The data rate should be driven with the > RS232C external clock for modems (described in the RS232C, Bell 103C, > and Bell 212 standards). The negotiation for speed should be done > at the carrier recognition, and not between the UART on the modem > and the UART in the computer. Yes connect speed is evil. The data rate should be fixed at some higher rate, and you should use CTS/RTS "hardware" flow control. It's unclean and non-EIA standard, but the only thing which actually works for contemporary modems which use RS232, and link-level compression and reliability. You can't use an external clock for async data; the UART needs to sample at (usually) 3 or more times the data rate to discover the center of each bit by finding the leading edge of the start bit. Of course for DTE synchronous data transfers and modems, things are all different. Of course, for non-RS232 connected modems (like inside terminal servers which take a ISDN PRI in one and and ethernet out the other), things are all different. > This is an evil perpetrated on honest, God-fearing people by Intel > and National Semiconductor. You can't blame Intel for *this* particular evil. The folks that got this stuff right was Telebit. Their original modems had two serial interfaces on the connector, so you could chat with the modem out-of-band to configure and query it. These days, you'd use an SNMP MIB... louie From owner-freebsd-current Sat Jun 21 12:21:12 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id MAA15072 for current-outgoing; Sat, 21 Jun 1997 12:21:12 -0700 (PDT) Received: from time.cdrom.com (root@time.cdrom.com [204.216.27.226]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id MAA15067 for ; Sat, 21 Jun 1997 12:21:09 -0700 (PDT) Received: from time.cdrom.com (jkh@localhost.cdrom.com [127.0.0.1]) by time.cdrom.com (8.8.5/8.6.9) with ESMTP id MAA21997 for ; Sat, 21 Jun 1997 12:21:17 -0700 (PDT) To: current@freebsd.org Subject: Hmmmm, this is new.. Date: Sat, 21 Jun 1997 12:21:17 -0700 Message-ID: <21993.866920877@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk While compiling today's 3.0 SNAP release over at current.freebsd.org, I noticed: building shared tcl library (version 75.1) ld: /usr/lib/libm.a(i387_s_tan.o): RRS text relocation at 0x2e9d3 for "___generic_tan" ld: /usr/lib/libm.a(i387_s_tan.o): RRS text relocation at 0x2e9c5 for "___get_hw_float" ld: /usr/lib/libm.a(i387_s_ceil.o): RRS text relocation at 0x2ea53 for "___generic_ceil" ld: /usr/lib/libm.a(i387_s_ceil.o): RRS text relocation at 0x2ea45 for "___get_hw_float" ld: /usr/lib/libm.a(w_sinh.o): RRS text relocation at 0x2ea9c for "___ieee754_si It seems to build OK, but I don't recall seeing these in libm before? Jordan From owner-freebsd-current Sat Jun 21 14:16:28 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id OAA19866 for current-outgoing; Sat, 21 Jun 1997 14:16:28 -0700 (PDT) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.50]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id OAA19861 for ; Sat, 21 Jun 1997 14:16:25 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id OAA27805; Sat, 21 Jun 1997 14:05:10 -0700 From: Terry Lambert Message-Id: <199706212105.OAA27805@phaeton.artisoft.com> Subject: Re: getty modem control To: louie@TransSys.COM (Louis A. Mamakos) Date: Sat, 21 Jun 1997 14:05:10 -0700 (MST) Cc: terry@lambert.org, adam@veda.is, joerg_wunsch@uriah.heep.sax.de, freebsd-current@FreeBSD.ORG In-Reply-To: <199706211830.OAA22108@whizzo.TransSys.COM> from "Louis A. Mamakos" at Jun 21, 97 02:30:55 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > Connect speed is evil. The data rate should be driven with the > > RS232C external clock for modems (described in the RS232C, Bell 103C, > > and Bell 212 standards). The negotiation for speed should be done > > at the carrier recognition, and not between the UART on the modem > > and the UART in the computer. > > Yes connect speed is evil. The data rate should be fixed at some > higher rate, and you should use CTS/RTS "hardware" flow control. It's > unclean and non-EIA standard, but the only thing which actually works for > contemporary modems which use RS232, and link-level compression and > reliability. You can't reliably run the computer-modem rate at a higher rate that the modem-modem rate. Conversely, you can't reliably run the modem-modem rate at a higher rate than the computer-modem rate. This is because of issues of bufferring, and when common UART chips trigger interrupts relative to their FIFO size. The last modem you could reliably run at differential speeds was the original MNP Microcom modems; they had huge buffers. Link-level compression is evil anyway; compression belongs on the host side of the host UART so that the datarate is not limited by the serial port rate. > > This is an evil perpetrated on honest, God-fearing people by Intel > > and National Semiconductor. > > You can't blame Intel for *this* particular evil. Sure I can! If they had ripped off the Zilog design, there wouldn't be a problem. 8-). > The folks that got this stuff right was Telebit. Their original modems > had two serial interfaces on the connector, so you could chat with the > modem out-of-band to configure and query it. The original Hayes modems had external clocking. It's not necessary to go sync to utilize an external clock. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-current Sat Jun 21 14:37:59 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id OAA20683 for current-outgoing; Sat, 21 Jun 1997 14:37:59 -0700 (PDT) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.50]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id OAA20678 for ; Sat, 21 Jun 1997 14:37:56 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id OAA27870; Sat, 21 Jun 1997 14:27:21 -0700 From: Terry Lambert Message-Id: <199706212127.OAA27870@phaeton.artisoft.com> Subject: Re: getty modem control To: adam@veda.is (Adam David) Date: Sat, 21 Jun 1997 14:27:21 -0700 (MST) Cc: terry@lambert.org, freebsd-current@FreeBSD.ORG In-Reply-To: <199706210043.AAA17361@veda.is> from "Adam David" at Jun 21, 97 00:43:55 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > > I'm not making any progress with using the modem init string capability. > > > (DTR lights up but there is no flicker on TXD) > > > > Look at the CTS/RTS settings, and how they effect the modem and > > UART in the DCD-not-present state, in particular. > > Are you saying I need a special cable because the software is a hack, > or am I misconfiguring the software? No. I'm saying that CTS/RTS may be active, even in the absence of DCD. If so, this modem is either broken, or misconfigured. Typically, command interchange with a modem does not involve data exchanges larger than the buffer size. The CTS/RTS should not be required until DCD is high, and thus the modem is doing data, not command, interchange. Typically, the symptoms are "no data back from modem until DCD is present". If you can't change the modem settings, then you will be limited to blind-dialing in all cases. > > You make a "modem driver" and seperate "inbound" vs. "outbound" > > tty device operations. The main problem is that most of these > > damn "do everything" getty programs like to initialize the modems > > to a state which is optimal for them. This is the same reason > > you can't share amodem between an intermittent ISP connection and > > a FAX server on most Microsoft platforms. > > If there is a modem driver, getty does not have to meddle with the modem > at all, correct? If there is a modem driver, getty is *PROHIBITED* from meddling with the modem at all. If it talks to the modem, it is committing a crime. > > The RI stuff is a hack I suggested > > to use as an inbound call marker; as you've discovered with 9 pin > > ports, it's not a very good hack. 8-(. Better to support inbound > > call fanning to voice/data/fax devices as seperate entities. > > There is no other marker of calls inbound. CD signals an established call. > RI is much simpler to implement as an external circuit than CID, but if > the serial port is broken by design then you take your chances. Actually, if you have a driver, then you are permitted to receive data befree DCD is asserted. The tty is not permitted to open until DCD is asserted in the data-call-answer case. The driver would "fan out" inbound calls to a voice device, a fax device, and an inbound tty. There may be a sperate DTMF device, but more likely it will be piggybacked on the voice device. A driver-based soloution could use data from the modem with DCD low as marker data, and interpret it as "cachable caller ID" or "soft ring notification", etc.. > > There is actually one modem that creates two serial pseudo devices > > under Windows95/NT: that's the Intel modem for telephony (I can't > > tell you the model without going to the usability lab down the > > hall, sorry). I *really* liked the modem, but obviously, it required > > a per-modem driver to do its thing. It supported Caller-ID as well, > > as a device ioctl (and supported providing your own calling-ID, too). > > Does this or any other readily available/affordable modem handle > full duplex (simultaneous realtime) voice to data conversion that > would be usable for an internet phone gateway? I believe the Intel modem uses a full duplex, ADAC, yes. I'm not real sure about the software controls embedded on the board as far as data directing, etc.. It's a PCI card, if that will help you narrow it down. I've used it for "voice response" -- rather nice, you tell it the name of the person you are calling, and it switches the call to that extension -- more hardware was present for the switching, before you rush out to buy the modem thinking it can do this by itself. The modem, one per inbound line, combined with a dialogic card, is enough to make a machine into a little PBX. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-current Sat Jun 21 15:06:04 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id PAA21783 for current-outgoing; Sat, 21 Jun 1997 15:06:04 -0700 (PDT) Received: from veda.is (ubiq.veda.is [193.4.230.60]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id PAA21775 for ; Sat, 21 Jun 1997 15:05:55 -0700 (PDT) Received: (from adam@localhost) by veda.is (8.8.5/8.7.3) id WAA19957; Sat, 21 Jun 1997 22:33:04 GMT From: Adam David Message-Id: <199706212233.WAA19957@veda.is> Subject: Re: getty modem control In-Reply-To: <199706212127.OAA27870@phaeton.artisoft.com> from Terry Lambert at "Jun 21, 97 02:27:21 pm" To: terry@lambert.org (Terry Lambert) Date: Sat, 21 Jun 1997 22:33:03 +0000 (GMT) Cc: terry@lambert.org, freebsd-current@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL31 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > > > I'm not making any progress with using the modem init string capability. > > > > (DTR lights up but there is no flicker on TXD) > > > > > > Look at the CTS/RTS settings, and how they effect the modem and > > > UART in the DCD-not-present state, in particular. > > > > Are you saying I need a special cable because the software is a hack, > > or am I misconfiguring the software? > > No. I'm saying that CTS/RTS may be active, even in the absence of > DCD. If so, this modem is either broken, or misconfigured. > > Typically, command interchange with a modem does not involve data > exchanges larger than the buffer size. The CTS/RTS should not be > required until DCD is high, and thus the modem is doing data, not > command, interchange. > > Typically, the symptoms are "no data back from modem until DCD > is present". If you can't change the modem settings, then you > will be limited to blind-dialing in all cases. I can cu the device and get a normal response without carrier present. However, getty times out trying to send the data, with no flicker on the modem TXD. -- Adam David From owner-freebsd-current Sat Jun 21 15:15:50 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id PAA22265 for current-outgoing; Sat, 21 Jun 1997 15:15:50 -0700 (PDT) Received: from austin.polstra.com (austin.polstra.com [206.213.73.10]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id PAA22259 for ; Sat, 21 Jun 1997 15:15:45 -0700 (PDT) Received: from austin.polstra.com (jdp@localhost) by austin.polstra.com (8.8.5/8.8.5) with ESMTP id PAA08801; Sat, 21 Jun 1997 15:15:41 -0700 (PDT) Message-Id: <199706212215.PAA08801@austin.polstra.com> To: jkh@time.cdrom.com Subject: Re: Hmmmm, this is new.. Newsgroups: polstra.freebsd.current In-Reply-To: <21993.866920877@time.cdrom.com> References: <21993.866920877@time.cdrom.com> Organization: Polstra & Co., Seattle, WA Cc: current@freebsd.org Date: Sat, 21 Jun 1997 15:15:41 -0700 From: John Polstra Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > While compiling today's 3.0 SNAP release over at current.freebsd.org, > I noticed: > > building shared tcl library (version 75.1) > ld: /usr/lib/libm.a(i387_s_tan.o): RRS text relocation at 0x2e9d3 for "___generic_tan" > ld: /usr/lib/libm.a(i387_s_tan.o): RRS text relocation at 0x2e9c5 for "___get_hw_float" > ld: /usr/lib/libm.a(i387_s_ceil.o): RRS text relocation at 0x2ea53 for "___generic_ceil" > ld: /usr/lib/libm.a(i387_s_ceil.o): RRS text relocation at 0x2ea45 for "___get_hw_float" > ld: /usr/lib/libm.a(w_sinh.o): RRS text relocation at 0x2ea9c for "___ieee754_si > > It seems to build OK, but I don't recall seeing these in libm before? They should not be happening. It looks a lot like your system has lost its /usr/lib/libm.so.3.0. The Makefile for libtcl adds "-lm" to the command that builds the shared library. That's fine -- it just makes sure that libm is pulled in whenever the shared libtcl is used. But if your shared version of libm is missing or cannot be found, it will statically link in /usr/lib/libm.a instead. (Maybe it should refuse.) Since libm.a is not built PIC, you get the linker warnings. They probably won't prevent programs from working, but they're bad from an efficiency standpoint. John -- John Polstra jdp@polstra.com John D. Polstra & Co., Inc. Seattle, Washington USA "Self-knowledge is always bad news." -- John Barth From owner-freebsd-current Sat Jun 21 17:45:00 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id RAA28799 for current-outgoing; Sat, 21 Jun 1997 17:45:00 -0700 (PDT) Received: from whizzo.TransSys.COM (whizzo.TransSys.COM [144.202.42.10]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id RAA28794 for ; Sat, 21 Jun 1997 17:44:56 -0700 (PDT) Received: from localhost.transsys.com (localhost.transsys.com [127.0.0.1]) by whizzo.TransSys.COM (8.8.5/8.7.3) with SMTP id UAA25091; Sat, 21 Jun 1997 20:41:18 -0400 (EDT) Message-Id: <199706220041.UAA25091@whizzo.TransSys.COM> X-Mailer: exmh version 2.0delta 6/3/97 To: Terry Lambert cc: adam@veda.is, joerg_wunsch@uriah.heep.sax.de, freebsd-current@FreeBSD.ORG From: "Louis A. Mamakos" Subject: Re: getty modem control References: <199706212105.OAA27805@phaeton.artisoft.com> In-reply-to: Your message of "Sat, 21 Jun 1997 14:05:10 PDT." <199706212105.OAA27805@phaeton.artisoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 21 Jun 1997 20:41:17 -0400 Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > You can't reliably run the computer-modem rate at a higher rate > that the modem-modem rate. Conversely, you can't reliably run > the modem-modem rate at a higher rate than the computer-modem > rate. That's news to me; I routinely ran a serial port at 38.4 kb/s with CTS/RTS hardware flow control with a V.32 (14.4kb/s) modem, and it worked just fine. As I was using it for SLIP, I knew there were no overruns because there were no IP, TCP or UDP checksum errors. > This is because of issues of bufferring, and when common UART > chips trigger interrupts relative to their FIFO size. I do not dispute broken hardware, but it's not all universally busted. > The last modem you could reliably run at differential speeds was > the original MNP Microcom modems; they had huge buffers. This was on a ZyXEL 1496 modem. > Link-level compression is evil anyway; compression belongs on > the host side of the host UART so that the datarate is not > limited by the serial port rate. I disagree. Given that the modem is already doing V.42 link-level reliablity, it fits in very nicely with it's segmentation. louie From owner-freebsd-current Sat Jun 21 19:03:20 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id TAA01260 for current-outgoing; Sat, 21 Jun 1997 19:03:20 -0700 (PDT) Received: from atlantis.nconnect.net (root@atlantis.nconnect.net [207.227.50.2]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id TAA01252 for ; Sat, 21 Jun 1997 19:03:16 -0700 (PDT) Received: from arabian.astrolab.org (dial208.nconnect.net [207.227.50.208]) by atlantis.nconnect.net (8.8.4/8.7.3) with ESMTP id UAA16457 for ; Sat, 21 Jun 1997 20:54:02 -0500 (CDT) Message-ID: <33AC879F.550E37FA@nconnect.net> Date: Sat, 21 Jun 1997 21:02:07 -0500 From: Randall D DuCharme Reply-To: randyd@nconnect.net X-Mailer: Mozilla 4.0b5C (X11; I; FreeBSD 3.0-CURRENT i386) MIME-Version: 1.0 To: current@freebsd.org Subject: Problem building mysql-3.20.22 on -Current machine X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Greetings, I'm running a very current -current SMP machine. I just tried to build and install the mysql port and got this.... gmake[2]: Leaving directory `/usr/ports/pub/FreeBSD/FreeBSD-current/ports/databases/mysql/work/mysql-3.20.22/client' making all in mit-pthreads cd: can't cd to /dr1/my/masters/mysql-old/mit-pthreads gmake[2]: Entering directory `/usr/ports/pub/FreeBSD/FreeBSD-current/ports/databases/mysql/work/mysql-3.20.22/mit-pthreads' GNUmakefile:53: /pthreads/GNUmakefile.inc: No such file or directory GNUmakefile:54: /stdlib/GNUmakefile.inc: No such file or directory GNUmakefile:55: /stdio/GNUmakefile.inc: No such file or directory GNUmakefile:56: /string/GNUmakefile.inc: No such file or directory GNUmakefile:57: /gen/GNUmakefile.inc: No such file or directory GNUmakefile:58: /net/GNUmakefile.inc: No such file or directory GNUmakefile:59: /scripts/GNUmakefile.inc: No such file or directory gmake[2]: *** No rule to make target `/scripts/GNUmakefile.inc'. Stop. gmake[2]: Leaving directory `/usr/ports/pub/FreeBSD/FreeBSD-current/ports/databases/mysql/work/mysql-3.20.22/mit-pthreads' gmake[1]: *** [all-recursive] Error 1 gmake[1]: Leaving directory `/usr/ports/pub/FreeBSD/FreeBSD-current/ports/databases/mysql/work/mysql-3.20.22' gmake: *** [all-recursive-hack] Error 2 *** Error code 2 Stop. *** Error code 1 Stop. *** Error code 1 Stop. Can't quite figure this one out!! Any ideas??? Thanks From owner-freebsd-current Sat Jun 21 19:37:56 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id TAA02478 for current-outgoing; Sat, 21 Jun 1997 19:37:56 -0700 (PDT) Received: from elvis.mu.org (paul@[206.156.231.253]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id TAA02473 for ; Sat, 21 Jun 1997 19:37:52 -0700 (PDT) Received: (from paul@localhost) by elvis.mu.org (8.8.5/8.8.5) id VAA01560; Sat, 21 Jun 1997 21:37:19 -0500 (CDT) From: Paul Saab Message-Id: <199706220237.VAA01560@elvis.mu.org> Subject: Re: Problem building mysql-3.20.22 on -Current machine In-Reply-To: <33AC879F.550E37FA@nconnect.net> from Randall D DuCharme at "Jun 21, 97 09:02:07 pm" To: randyd@nconnect.net Date: Sat, 21 Jun 1997 21:37:19 -0500 (CDT) Cc: current@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL31H (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk I ran into the same problem. do this... find the line in /usr/ports/databases/mysql/work/mysql-3.20.22/mit-pthreads/config/configure that contains.. i386-*-freebsd2.*) and change it to i386-*-freebsd2.* | i386-*-freebsd3.*) Paul Randall D DuCharme wrote: > Greetings, > > I'm running a very current -current SMP machine. I just tried to build > and > install the mysql port and got this.... > > gmake[2]: Leaving directory > `/usr/ports/pub/FreeBSD/FreeBSD-current/ports/databases/mysql/work/mysql-3.20.22/client' > making all in mit-pthreads > cd: can't cd to /dr1/my/masters/mysql-old/mit-pthreads > gmake[2]: Entering directory > `/usr/ports/pub/FreeBSD/FreeBSD-current/ports/databases/mysql/work/mysql-3.20.22/mit-pthreads' > GNUmakefile:53: /pthreads/GNUmakefile.inc: No such file or directory > GNUmakefile:54: /stdlib/GNUmakefile.inc: No such file or directory > GNUmakefile:55: /stdio/GNUmakefile.inc: No such file or directory > GNUmakefile:56: /string/GNUmakefile.inc: No such file or directory > GNUmakefile:57: /gen/GNUmakefile.inc: No such file or directory > GNUmakefile:58: /net/GNUmakefile.inc: No such file or directory > GNUmakefile:59: /scripts/GNUmakefile.inc: No such file or directory > gmake[2]: *** No rule to make target `/scripts/GNUmakefile.inc'. Stop. > gmake[2]: Leaving directory > `/usr/ports/pub/FreeBSD/FreeBSD-current/ports/databases/mysql/work/mysql-3.20.22/mit-pthreads' > gmake[1]: *** [all-recursive] Error 1 > gmake[1]: Leaving directory > `/usr/ports/pub/FreeBSD/FreeBSD-current/ports/databases/mysql/work/mysql-3.20.22' > gmake: *** [all-recursive-hack] Error 2 > *** Error code 2 > > Stop. > *** Error code 1 > > Stop. > *** Error code 1 > > Stop. > > Can't quite figure this one out!! > > Any ideas??? > > Thanks > From owner-freebsd-current Sat Jun 21 21:26:37 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id VAA07257 for current-outgoing; Sat, 21 Jun 1997 21:26:37 -0700 (PDT) Received: from atlantis.nconnect.net (root@atlantis.nconnect.net [207.227.50.2]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id VAA07252 for ; Sat, 21 Jun 1997 21:26:35 -0700 (PDT) Received: from arabian.astrolab.org (dial183.nconnect.net [207.227.50.183]) by atlantis.nconnect.net (8.8.4/8.7.3) with ESMTP id XAA20458 for ; Sat, 21 Jun 1997 23:17:39 -0500 (CDT) Message-ID: <33ACA959.5205B0C1@nconnect.net> Date: Sat, 21 Jun 1997 23:26:01 -0500 From: Randall D DuCharme Reply-To: randyd@nconnect.net X-Mailer: Mozilla 4.0b5C (X11; I; FreeBSD 3.0-CURRENT i386) MIME-Version: 1.0 To: current@FreeBSD.ORG Subject: Warnings on mysql build X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Greetings, I just (successfully) built and installed mysql-3.20.22 on a -current machine. I got the following messages at the end of the install and wonder what it might mean. perl: warning: Setting locale failed. perl: warning: Please check that your locale settings: LC_ALL = (unset), LANG = "us" are supported and installed on your system. perl: warning: Falling back to the standard locale ("C"). perl: warning: Setting locale failed. perl: warning: Please check that your locale settings: LC_ALL = (unset), LANG = "us" are supported and installed on your system. Thanks From owner-freebsd-current Sat Jun 21 22:47:42 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id WAA10199 for current-outgoing; Sat, 21 Jun 1997 22:47:42 -0700 (PDT) Received: from time.cdrom.com (root@time.cdrom.com [204.216.27.226]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id WAA10190 for ; Sat, 21 Jun 1997 22:47:38 -0700 (PDT) Received: from time.cdrom.com (jkh@localhost.cdrom.com [127.0.0.1]) by time.cdrom.com (8.8.5/8.6.9) with ESMTP id WAA23875; Sat, 21 Jun 1997 22:47:44 -0700 (PDT) To: John Polstra cc: current@freebsd.org Subject: Re: Hmmmm, this is new.. In-reply-to: Your message of "Sat, 21 Jun 1997 15:15:41 PDT." <199706212215.PAA08801@austin.polstra.com> Date: Sat, 21 Jun 1997 22:47:44 -0700 Message-ID: <23872.866958464@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > They should not be happening. It looks a lot like your system has > lost its /usr/lib/libm.so.3.0. The Makefile for libtcl adds "-lm" Hmmm. There may be something in the release building process which actually causes this - let me investigate further, and sorry for the false alarm if it turns out to be one. Thanks. Jordan From owner-freebsd-current Sat Jun 21 23:50:14 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id XAA13218 for current-outgoing; Sat, 21 Jun 1997 23:50:14 -0700 (PDT) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id XAA13150 for ; Sat, 21 Jun 1997 23:49:53 -0700 (PDT) Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.5/8.6.9) id QAA23309; Sun, 22 Jun 1997 16:38:58 +1000 Date: Sun, 22 Jun 1997 16:38:58 +1000 From: Bruce Evans Message-Id: <199706220638.QAA23309@godzilla.zeta.org.au> To: jdp@polstra.com, jkh@time.cdrom.com Subject: Re: Hmmmm, this is new.. Cc: current@FreeBSD.ORG Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >> They should not be happening. It looks a lot like your system has >> lost its /usr/lib/libm.so.3.0. The Makefile for libtcl adds "-lm" > >Hmmm. There may be something in the release building process which >actually causes this - let me investigate further, and sorry for >the false alarm if it turns out to be one. It's probably a bug for it not to happen for every `make world'. -nostdlib should be used to prevent old libraries being linked to. Since libtcl is built before msun and there is no special bootstrapping for msun, a new version of msun is guaranteed to not exist when libtcl is linked. The release attempts to avoid problems like this by building in a chrooted tree. Apparently it is not careful enough. I think linking to a 2.2 libm.so would work but linking to a 2.1 libm.so would fail. Bruce From owner-freebsd-current Sat Jun 21 23:52:53 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id XAA13429 for current-outgoing; Sat, 21 Jun 1997 23:52:53 -0700 (PDT) Received: from veda.is (ubiq.veda.is [193.4.230.60]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id XAA13412 for ; Sat, 21 Jun 1997 23:52:46 -0700 (PDT) Received: (from adam@localhost) by veda.is (8.8.5/8.7.3) id HAA21918; Sun, 22 Jun 1997 07:20:42 GMT From: Adam David Message-Id: <199706220720.HAA21918@veda.is> Subject: Re: getty modem control In-Reply-To: <199706220523.PAA00550@labs.usn.blaze.net.au> from David Nugent at "Jun 22, 97 03:23:07 pm" To: davidn@labs.usn.blaze.net.au (David Nugent) Date: Sun, 22 Jun 1997 07:20:41 +0000 (GMT) Cc: freebsd-current@freebsd.org X-Mailer: ELM [version 2.4ME+ PL31 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk [David Nugent] > Actually, CID should be trivial to add. The support functionality > is already there. Instead of flushing the modem input with wait/flush > after the connect, use the functions in chat.c to grab each line > output from the modem and log the data. I have reordered the flow of the chat support in main() and added :nb: to enable non-blocking use. If no-one among the non-blocking crowd objects, I will commit the changes so that blocking use of the answer chat facilities is available by default. Yes, it would definitely be nice to log the report strings. Is there a chance that CID will be available on broken implementations (such as Rockwell) when blocking on open() is used? To generify the question, if the serial input is not flushed on successful open, is that input available for reading if it originally occured after open() was first invoked but before the open() completed? > I *hate* mgetty with a vengence - it is far too bloated and > difficult to configure. ... and still assumes primitive modem technology. It's fine to support older equipment, but too limiting when this is assumed. > getty works for me, and very well, using a wide range of modems. > Its only problem is having to use cua* devices rather than tty* > devices, which I am fairly certain has to do with termios settings, > and in particular CLOCAL handling. It is in my todo list to fix. Ah, this is where I took a wrong turn. I was trying to use it with ttyd? devices. CLOCAL looks a likely culprit under the circumstances. However, when trying cuaa0 I found something had set /dev/cuaa0 to root.wheel 600 and I don't remember any other program than getty getting near it, so I went back to being stuck at getty chat on ttyd0 not working. Since people are using it with some success, I sat back to hear how this was done. -- Adam David