From owner-freebsd-hackers Sun Nov 9 00:04:58 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id AAA22408 for hackers-outgoing; Sun, 9 Nov 1997 00:04:58 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from smtp04.primenet.com (smtp04.primenet.com [206.165.5.85]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id AAA22402 for ; Sun, 9 Nov 1997 00:04:54 -0800 (PST) (envelope-from tlambert@usr06.primenet.com) Received: (from daemon@localhost) by smtp04.primenet.com (8.8.7/8.8.7) id BAA08577; Sun, 9 Nov 1997 01:04:53 -0700 (MST) Received: from usr06.primenet.com(206.165.6.206) via SMTP by smtp04.primenet.com, id smtpd008570; Sun Nov 9 01:04:50 1997 Received: (from tlambert@localhost) by usr06.primenet.com (8.8.5/8.8.5) id BAA17700; Sun, 9 Nov 1997 01:04:47 -0700 (MST) From: Terry Lambert Message-Id: <199711090804.BAA17700@usr06.primenet.com> Subject: Re: x86 gods; advice? Suggestions? To: mike@smith.net.au (Mike Smith) Date: Sun, 9 Nov 1997 08:04:47 +0000 (GMT) Cc: wghhicks@ix.netcom.com, mini@d198-232.uoregon.edu, mike@smith.net.au, hackers@FreeBSD.ORG In-Reply-To: <199711081106.VAA01053@word.smith.net.au> from "Mike Smith" at Nov 8, 97 09:36:46 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > Well, in the bad old days, I would probably have reached for Forth. > > There is some precedent for this approach over at Sun... > > OpenBoot is big and expensive. And it doesn't lock you into x86 to run the BIOS on video cards... where's the fun in that? If you go that route, pretty soon, you have people switching to other processors every time a bug is revealed, and people start writing ActiveX components and viruses and network program stack overflow using programs and using guest accounts on ISP's with machines using Pentium processors to mount denial of service attacks. People are not supposed to switch to other processors... they are supposed to live with the bugs because they have no alternatives. And if that argment doesn't sway you, what about software availability? Do you realize that a DEC Alpha or Motorola PowerPC simply *can't* run *any* of the most popular viruses you can get for DOS machines? Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Sun Nov 9 00:10:22 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id AAA22641 for hackers-outgoing; Sun, 9 Nov 1997 00:10:22 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from word.smith.net.au (word.smith.net.au [202.0.75.3]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id AAA22619 for ; Sun, 9 Nov 1997 00:10:10 -0800 (PST) (envelope-from mike@word.smith.net.au) Received: from word.smith.net.au (localhost.smith.net.au [127.0.0.1]) by word.smith.net.au (8.8.7/8.8.5) with ESMTP id SAA00646; Sun, 9 Nov 1997 18:36:01 +1030 (CST) Message-Id: <199711090806.SAA00646@word.smith.net.au> X-Mailer: exmh version 2.0zeta 7/24/97 To: Terry Lambert cc: mike@smith.net.au (Mike Smith), wghhicks@ix.netcom.com, mini@d198-232.uoregon.edu, hackers@FreeBSD.ORG Subject: Re: x86 gods; advice? Suggestions? In-reply-to: Your message of "Sun, 09 Nov 1997 08:04:47 -0000." <199711090804.BAA17700@usr06.primenet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 09 Nov 1997 18:36:00 +1030 From: Mike Smith Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > > Well, in the bad old days, I would probably have reached for Forth. > > > There is some precedent for this approach over at Sun... > > > > OpenBoot is big and expensive. > > And it doesn't lock you into x86 to run the BIOS on video cards... > where's the fun in that? I don't give a shit what it doesn't do, Terry. What *I* care about is that OpenBoot is big, it is expensive and proprietary, and it is a complete crock from the POV of usability. Sorry, that's just the way it is. 8( mike From owner-freebsd-hackers Sun Nov 9 00:23:38 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id AAA23200 for hackers-outgoing; Sun, 9 Nov 1997 00:23:38 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from smtp03.primenet.com (smtp03.primenet.com [206.165.5.84]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id AAA23195 for ; Sun, 9 Nov 1997 00:23:34 -0800 (PST) (envelope-from tlambert@usr06.primenet.com) Received: (from daemon@localhost) by smtp03.primenet.com (8.8.7/8.8.7) id BAA02244; Sun, 9 Nov 1997 01:23:33 -0700 (MST) Received: from usr06.primenet.com(206.165.6.206) via SMTP by smtp03.primenet.com, id smtpd002238; Sun Nov 9 01:23:25 1997 Received: (from tlambert@localhost) by usr06.primenet.com (8.8.5/8.8.5) id BAA18550; Sun, 9 Nov 1997 01:23:22 -0700 (MST) From: Terry Lambert Message-Id: <199711090823.BAA18550@usr06.primenet.com> Subject: Re: Newest Pentium bug (fatal) To: digital@www2.shoppersnet.com (Howard Lew) Date: Sun, 9 Nov 1997 08:23:22 +0000 (GMT) Cc: alk@subtle.east.sun.com, hackers@FreeBSD.ORG In-Reply-To: from "Howard Lew" at Nov 8, 97 07:42:51 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > For Windows users this bug should not be much of a problem unless viruses > start popping up taking advantage of the bug. For FreeBSD it is not very > comforting to know that any misbehaving user can lock up your shell > machine, but in a controlled environment this should not be a problem. A virus isn't the only way it could be done. A Windows user's ISP could be denial of service attacked using the bug, so it could affect them. Active X, anyone? Microsoft made their JAVA capable of calling x86 code (makes it possible to write java wrappers for ActiveX code that isn't security checked for a VeriSign key, right?). Apparent;y Sun was right about it being a mistake for Microsoft to do this. 8-) 8-). Word Macros? Excel Macros? Help files? Email attachments? Screen savers? Desktop Themes? The default for the system directory on Windows NT is world writeable; it seems to me many NT file servers are at risk (not that they weren't at risk without tuning anyway). I'd say "all", but of course NT runs on non-Intel machines... ;-). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Sun Nov 9 00:27:28 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id AAA23367 for hackers-outgoing; Sun, 9 Nov 1997 00:27:28 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from smtp04.primenet.com (smtp04.primenet.com [206.165.5.85]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id AAA23361; Sun, 9 Nov 1997 00:27:23 -0800 (PST) (envelope-from tlambert@usr06.primenet.com) Received: (from daemon@localhost) by smtp04.primenet.com (8.8.7/8.8.7) id BAA08774; Sun, 9 Nov 1997 01:27:22 -0700 (MST) Received: from usr06.primenet.com(206.165.6.206) via SMTP by smtp04.primenet.com, id smtpd008767; Sun Nov 9 01:27:18 1997 Received: (from tlambert@localhost) by usr06.primenet.com (8.8.5/8.8.5) id BAA18715; Sun, 9 Nov 1997 01:27:15 -0700 (MST) From: Terry Lambert Message-Id: <199711090827.BAA18715@usr06.primenet.com> Subject: Re: VIEWING / PERMS-OWNER To: randyk@ccsales.com (Randy Katz) Date: Sun, 9 Nov 1997 08:27:15 +0000 (GMT) Cc: hackers@FreeBSD.ORG, questions@FreeBSD.ORG In-Reply-To: from "Randy Katz" at Nov 8, 97 09:17:06 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > Is there any way to view the permissions on the "/" directory? And to > view the ownership/group on it? BTW, in case you were asking for the reason I think you were asking (since there really isn't another reason to ask 8-)), there is no underlying mount point for the "/" directory, so there are no permissions on the mount point that can screw you up. If you are seeing odd behaviour, it's some other problem.. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Sun Nov 9 00:32:05 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id AAA23753 for hackers-outgoing; Sun, 9 Nov 1997 00:32:05 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from smtp04.primenet.com (smtp04.primenet.com [206.165.5.85]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id AAA23748 for ; Sun, 9 Nov 1997 00:32:03 -0800 (PST) (envelope-from tlambert@usr06.primenet.com) Received: (from daemon@localhost) by smtp04.primenet.com (8.8.7/8.8.7) id BAA08828; Sun, 9 Nov 1997 01:32:02 -0700 (MST) Received: from usr06.primenet.com(206.165.6.206) via SMTP by smtp04.primenet.com, id smtpd008814; Sun Nov 9 01:31:54 1997 Received: (from tlambert@localhost) by usr06.primenet.com (8.8.5/8.8.5) id BAA18899; Sun, 9 Nov 1997 01:31:51 -0700 (MST) From: Terry Lambert Message-Id: <199711090831.BAA18899@usr06.primenet.com> Subject: Re: IDT processors? To: freebsd@atipa.com (Atipa) Date: Sun, 9 Nov 1997 08:31:51 +0000 (GMT) Cc: cmott@srv.net, hackers@FreeBSD.ORG In-Reply-To: from "Atipa" at Nov 8, 97 11:04:18 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > I really doubt the contingent that is affected by this bug would be > likely to trust a no-name chip. The whole point is reliability... I think any "no name" chip vendor could reasonably claim "as reliable as a Pentium(tm)" on a potato chip bag right about now... [ ... ] > Good call... especially if any member of the contingent in question is an ISP offering shell accounts and execute access for customer applications... like, oh, say WWW page CGI's, etc.? Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Sun Nov 9 00:46:01 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id AAA24333 for hackers-outgoing; Sun, 9 Nov 1997 00:46:01 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from monk.via.net (monk.via.net [140.174.204.10]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id AAA24328 for ; Sun, 9 Nov 1997 00:45:59 -0800 (PST) (envelope-from joe@via.net) Received: (from joe@localhost) by monk.via.net (8.6.11/8.6.12) id AAA14711 for hackers@freebsd.org; Sun, 9 Nov 1997 00:35:42 -0800 Date: Sun, 9 Nov 1997 00:35:42 -0800 From: Joe McGuckin Message-Id: <199711090835.AAA14711@monk.via.net> To: hackers@freebsd.org Subject: TCP questions X-Sun-Charset: US-ASCII Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I was using Solaris' snoop command to debug a telnet proxy. When I issue a setsockopts() call to set the segment size, does that result in an immediate send of a packet? 0: 0000 0c92 fff0 0060 083b e82e 0800 4500 .......`.;....E. 16: 002c c500 4000 2006 cc9c d151 093a cda2 .,..@. ....Q.:.. 32: 2101 0412 0017 012a 8c98 0000 0000 6002 !......*......`. 48: 2000 1d0c 0000 0204 05b4 05b4 ........... Here we have one side setting the max segment size to 1460 (0x05b4). What the heck is that other 0x05b4 in the data stream ? I never see in on the receiving end... Can ACK or SYN packets carry application level data as well ? ETHER: ----- Ether Header ----- ETHER: ETHER: Packet 5 arrived at 1:06:54.95 ETHER: Packet size = 60 bytes ETHER: Destination = 0:0:c:92:ff:f0, Cisco ETHER: Source = 0:60:8:3b:e8:2e, ETHER: Ethertype = 0800 (IP) ETHER: IP: ----- IP Header ----- IP: IP: Version = 4 IP: Header length = 20 bytes IP: Type of service = 0x00 IP: xxx. .... = 0 (precedence) IP: ...0 .... = normal delay IP: .... 0... = normal throughput IP: .... .0.. = normal reliability IP: Total length = 40 bytes IP: Identification = 50688 IP: Flags = 0x4 IP: .1.. .... = do not fragment IP: ..0. .... = last fragment IP: Fragment offset = 0 bytes IP: Time to live = 32 seconds/hops IP: Protocol = 6 (TCP) IP: Header checksum = cba0 IP: Source address = 209.81.9.58, 209.81.9.58 IP: Destination address = 205.162.33.1, trn01.newark.wpac.com IP: No options IP: TCP: ----- TCP Header ----- TCP: TCP: Source port = 1042 TCP: Destination port = 23 (TELNET) TCP: Sequence number = 19565721 TCP: Acknowledgement number = 1683231818 TCP: Data offset = 20 bytes TCP: Flags = 0x10 TCP: ..0. .... = No urgent pointer TCP: ...1 .... = Acknowledgement TCP: .... 0... = No push TCP: .... .0.. = No reset TCP: .... ..0. = No Syn TCP: .... ...0 = No Fin TCP: Window = 8576 TCP: Checksum = 0xba9a TCP: Urgent pointer = 0 TCP: No options TCP: TELNET: ----- TELNET: ----- TELNET: TELNET: "" TELNET: 0: 0000 0c92 fff0 0060 083b e82e 0800 4500 .......`.;....E. 16: 0028 c600 4000 2006 cba0 d151 093a cda2 .(..@. ....Q.:.. 32: 2101 0412 0017 012a 8c99 6454 144a 5010 !......*..dT.JP. 48: 2180 ba9a 0000 0000 0000 0000 !........... Is this sending a bunch of nulls to the other telnet client ? How does the push flag work? If the packet is less than the segment size and the push flag is zero, does that mean that there's no payload ? (Just as in the above packet) From owner-freebsd-hackers Sun Nov 9 00:59:52 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id AAA24902 for hackers-outgoing; Sun, 9 Nov 1997 00:59:52 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from dfw-ix6.ix.netcom.com (dfw-ix6.ix.netcom.com [206.214.98.6]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id AAA24896 for ; Sun, 9 Nov 1997 00:59:48 -0800 (PST) (envelope-from wghhicks@ix.netcom.com) Received: (from smap@localhost) by dfw-ix6.ix.netcom.com (8.8.4/8.8.4) id CAA12618; Sun, 9 Nov 1997 02:57:25 -0600 (CST) Received: from atl-ga7-24.ix.netcom.com(199.183.210.56) by dfw-ix6.ix.netcom.com via smap (V1.3) id rma012615; Sun Nov 9 02:57:22 1997 Message-ID: <34657AE0.1AFD9984@ix.netcom.com> Date: Sun, 09 Nov 1997 03:57:04 -0500 From: Jerry Hicks Reply-To: wghhicks@ix.netcom.com Organization: TerraEarth X-Mailer: Mozilla 4.03b8 [en] (X11; I; FreeBSD 2.2.5-STABLE i386) MIME-Version: 1.0 To: Mike Smith CC: Terry Lambert , mini@d198-232.uoregon.edu, hackers@FreeBSD.ORG Subject: Re: x86 gods; advice? Suggestions? References: <199711090806.SAA00646@word.smith.net.au> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Mike Smith wrote: > > > > > Well, in the bad old days, I would probably have reached for Forth. > > > > There is some precedent for this approach over at Sun... > > > > > > OpenBoot is big and expensive. > > > > And it doesn't lock you into x86 to run the BIOS on video cards... > > where's the fun in that? > > I don't give a shit what it doesn't do, Terry. What *I* care about is > that OpenBoot is big, it is expensive and proprietary, and it is a > complete crock from the POV of usability. > > Sorry, that's just the way it is. 8( > > mike Yeah, ain't it a shame tho... (back to basement, red-eyed, cursing forth...) J. Hicks From owner-freebsd-hackers Sun Nov 9 01:08:51 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id BAA25513 for hackers-outgoing; Sun, 9 Nov 1997 01:08:51 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from unix.tfs.net (root@unix.tfs.net [199.79.146.60]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id BAA25501 for ; Sun, 9 Nov 1997 01:08:44 -0800 (PST) (envelope-from jbryant@argus.tfs.net) Received: from argus.tfs.net (pm3-p2.tfs.net [206.154.183.194]) by unix.tfs.net (8.8.5/8.8.5) with ESMTP id DAA13934; Sun, 9 Nov 1997 03:07:15 -0600 Received: (from jbryant@localhost) by argus.tfs.net (8.8.7/8.8.5) id DAA05745; Sun, 9 Nov 1997 03:08:16 -0600 (CST) From: Jim Bryant Message-Id: <199711090908.DAA05745@argus.tfs.net> Subject: Re: Newest Pentium bug (fatal) In-Reply-To: from Charles Mott at "Nov 8, 97 10:06:59 pm" To: cmott@srv.net (Charles Mott) Date: Sun, 9 Nov 1997 03:08:14 -0600 (CST) Cc: freebsd-hackers@freebsd.org Reply-to: jbryant@tfs.net X-Windows: R00LZ!@# MS-Winbl0wz DR00LZ!@# X-Operating-System: FreeBSD 2.2.2-RELEASE #0: Wed Jul 9 01:01:24 CDT 1997 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-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In reply: > On Sat, 8 Nov 1997, Howard Lew wrote: > > > > For Windows users this bug should not be much of a problem unless viruses > > start popping up taking advantage of the bug. For FreeBSD it is not very > > comforting to know that any misbehaving user can lock up your shell > > machine, but in a controlled environment this should not be a problem. > > > > Possibly also systems where users are allowed to put executable > CGI-invoked code on their web pages (although usually such users > also have shell accounts). > > This could be bad for Intel. I think that there is a limited > subset of Pentium owners which now have a *very* strong incentive > to obtain replacement chips or go to alternate vendors (AMD or > IDT). this is going to be a real nightmare for intel... how many pentiums are out there, and i'm begionning to notice a lot of pentium-specific stuff out there now. the instruction seqquence in question seems to me to be a type that will be in widespread use in the very near future. to compare and exchange a 64 bit number is pretty fundamental, but still pentium specific. with the forward push for pentium specific programs, this will become more and more of a problem... hmmmm.... 100+ million pissed off customers... just imagine the logistics of a recall.... jim -- All opinions expressed are mine, if you | "I will not be pushed, stamped, think otherwise, then go jump into turbid | briefed, debriefed, indexed, or radioactive waters and yell WAHOO !!! | numbered!" - #1, "The Prisoner" ------------------------------------------------------------------------------ Inet: jbryant@tfs.net AX.25: kc5vdj@wv0t.#neks.ks.usa.noam grid: EM28pw voice: KC5VDJ - 6 & 2 Meters AM/FM/SSB, 70cm FM. http://www.tfs.net/~jbryant ------------------------------------------------------------------------------ HF/6M/2M: IC-706-MkII, 2M: HTX-212, 2M: HTX-202, 70cm: HTX-404, Packet: KPC-3+ From owner-freebsd-hackers Sun Nov 9 01:47:17 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id BAA27291 for hackers-outgoing; Sun, 9 Nov 1997 01:47:17 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from unix.tfs.net (root@unix.tfs.net [199.79.146.60]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id BAA27285 for ; Sun, 9 Nov 1997 01:47:06 -0800 (PST) (envelope-from jbryant@argus.tfs.net) Received: from argus.tfs.net (pm3-p2.tfs.net [206.154.183.194]) by unix.tfs.net (8.8.5/8.8.5) with ESMTP id DAA16226; Sun, 9 Nov 1997 03:45:27 -0600 Received: (from jbryant@localhost) by argus.tfs.net (8.8.7/8.8.5) id DAA05798; Sun, 9 Nov 1997 03:46:38 -0600 (CST) From: Jim Bryant Message-Id: <199711090946.DAA05798@argus.tfs.net> Subject: Re: Newest Pentium bug (fatal) In-Reply-To: <199711090823.BAA18550@usr06.primenet.com> from Terry Lambert at "Nov 9, 97 08:23:22 am" To: tlambert@primenet.com (Terry Lambert) Date: Sun, 9 Nov 1997 03:46:31 -0600 (CST) Cc: freebsd-hackers@freebsd.org, jamesbryant@sprintmail.com Reply-to: jbryant@tfs.net X-Windows: R00LZ!@# MS-Winbl0wz DR00LZ!@# X-Operating-System: FreeBSD 2.2.2-RELEASE #0: Wed Jul 9 01:01:24 CDT 1997 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-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In reply: > > For Windows users this bug should not be much of a problem unless viruses > > start popping up taking advantage of the bug. For FreeBSD it is not very > > comforting to know that any misbehaving user can lock up your shell > > machine, but in a controlled environment this should not be a problem. > > A virus isn't the only way it could be done. the list of ways this could be used is too long to enumerate... > A Windows user's ISP could be denial of service attacked using the bug, > so it could affect them. > > Active X, anyone? > > Microsoft made their JAVA capable of calling x86 code (makes it possible > to write java wrappers for ActiveX code that isn't security checked for > a VeriSign key, right?). Apparent;y Sun was right about it being a > mistake for Microsoft to do this. 8-) 8-). bill gets bit on the butt again... every security expert in the industry tells bill he's stupid, but does he listen... we are talking about a man who wants to bypass the standards process rather than be a part of it... > Word Macros? Excel Macros? Help files? Email attachments? Screen > savers? Desktop Themes? > > > The default for the system directory on Windows NT is world writeable; > it seems to me many NT file servers are at risk (not that they weren't > at risk without tuning anyway). I'd say "all", but of course NT runs > on non-Intel machines... ;-). ^^^^^^^^^^^^^^^^^^^^^ heheh, barely, AXP, MIPS, cases in point.... scary stuff, eh... RECALL RECALL RECALL [as in TOTAL RECALL] i don't know why i didn't mention this in my earlier post with the disassembly info: could it be possible that intel is lying about finding out about this on friday... a pentium specific instuction, compatable with the LOCK prefix, but not tested... a pentium specific instruction to compare and exchange a set of quadword values IN 10 CLOCKS, but not tested... of all of the instructions specific to pentium and above classes of processors, this is one i would consider highly desirable to use, and thus should be one of the most extensively tested. once 486 backward compatability is tossed out the door, this will be an extensively used instruction. for a full description of the instruction, please see pp. 25-72 and 25-73 of intel's "Pentium Processor Family Developer's Manual, Volume 3: Archetecture and Programming Manual". this reeks. can you say coverup? do i recall reading on this list that ppro or p-ii cpus generate an exception on this? this would indicate quite probably that they found out about this LONG before friday. if my hunch is correct, i hope this bites them on the butt. i don't know about you, but i bought a cpu that would "RUN TOMORROW'S SOFTWARE TODAY". i don't buy intel's ass-covering story that they just learned about this... RECALL RECALL RECALL RECALL RECALL RECALL RECALL RECALL RECALL RECALL RECALL RECALL RECALL RECALL RECALL RECALL RECALL RECALL RECALL RECALL RECALL RECALL RECALL RECALL RECALL RECALL RECALL RECALL RECALL RECALL RECALL RECALL RECALL RECALL RECALL RECALL RECALL RECALL RECALL RECALL RECALL RECALL RECALL RECALL RECALL RECALL RECALL RECALL RECALL RECALL RECALL RECALL RECALL RECALL RECALL RECALL RECALL RECALL RECALL RECALL RECALL RECALL RECALL RECALL RECALL RECALL RECALL RECALL RECALL RECALL RECALL RECALL RECALL RECALL RECALL RECALL RECALL RECALL RECALL RECALL RECALL RECALL RECALL RECALL RECALL RECALL RECALL RECALL RECALL RECALL RECALL RECALL RECALL RECALL RECALL RECALL jim -- All opinions expressed are mine, if you | "I will not be pushed, stamped, think otherwise, then go jump into turbid | briefed, debriefed, indexed, or radioactive waters and yell WAHOO !!! | numbered!" - #1, "The Prisoner" ------------------------------------------------------------------------------ Inet: jbryant@tfs.net AX.25: kc5vdj@wv0t.#neks.ks.usa.noam grid: EM28pw voice: KC5VDJ - 6 & 2 Meters AM/FM/SSB, 70cm FM. http://www.tfs.net/~jbryant ------------------------------------------------------------------------------ HF/6M/2M: IC-706-MkII, 2M: HTX-212, 2M: HTX-202, 70cm: HTX-404, Packet: KPC-3+ From owner-freebsd-hackers Sun Nov 9 02:22:02 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id CAA29245 for hackers-outgoing; Sun, 9 Nov 1997 02:22:02 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from smtp04.primenet.com (smtp04.primenet.com [206.165.5.85]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id CAA29237 for ; Sun, 9 Nov 1997 02:21:58 -0800 (PST) (envelope-from tlambert@usr06.primenet.com) Received: (from daemon@localhost) by smtp04.primenet.com (8.8.7/8.8.7) id DAA11946; Sun, 9 Nov 1997 03:21:57 -0700 (MST) Received: from usr06.primenet.com(206.165.6.206) via SMTP by smtp04.primenet.com, id smtpd011941; Sun Nov 9 03:21:56 1997 Received: (from tlambert@localhost) by usr06.primenet.com (8.8.5/8.8.5) id DAA24289; Sun, 9 Nov 1997 03:21:54 -0700 (MST) From: Terry Lambert Message-Id: <199711091021.DAA24289@usr06.primenet.com> Subject: Re: x86 gods; advice? Suggestions? To: mike@smith.net.au (Mike Smith) Date: Sun, 9 Nov 1997 10:21:54 +0000 (GMT) Cc: mini@d198-232.uoregon.edu, hackers@FreeBSD.ORG In-Reply-To: <199711080954.UAA00629@word.smith.net.au> from "Mike Smith" at Nov 8, 97 08:24:16 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > > This was suggested by another respondent. I'd be very interested in > > > knowing how I could arrange such a thing, either overloading the > > > existing syscall callgate or making another for temporary use (I have > > > another free descriptor that I can hijack for the purpose). > > > > I don't know, I've never done it myself, personally. :) > > Ah. A handwave response. 8) I'll look at it tomorrow; it was > suggested that I buy a book - obviously a suggestion from someone that > doesn't live in this book-desert. I was the one who suggested a book: Protected Mode Software Architecture - PC System Architecture Series Tom Shanley MindShare, Inc. ISBN: 0-201-55447-X Lest I be accused of handwaving-by-association yet gain, here's the process (people who are too lazy to wrap their brains around complicated things should delete this message now instead of bitching at me like they do when I talk about other complicated things they are too lazy to wrap their brains around, like file systems, etc.): o Load all or part of the task into memory (minimally, startup code). o Create a TSS for the task. A TSS is an execution context for the processor at the point it first begins or resumes the exection of the task. A special TSS segment desriptor is placed in the GDT defining the base address, length, and Descriptor Priviledge Level for the TSS it points to. A TSS starts at the TR specified TSS base address and extends to the TSS limit, also from the TR. It looks like: 0 31 00 Link (old TSS selector) 0000000000000000 04 ESP0 08 SS0 0000000000000000 0C ESP1 10 SS1 0000000000000000 14 ESP2 18 SS2 0000000000000000 1C CR3 20 EIP 24 EFLAGS 28 EAX 2C ECX 30 EDX 34 EBX <-- this ordering explains a bit, eh? 38 ESP 3C EBP 40 ESI 44 EDI 48 ES 0000000000000000 4C CS 0000000000000000 50 SS 0000000000000000 54 DS 0000000000000000 58 FS 0000000000000000 5C GS 0000000000000000 60 Task's LDT selector 0000000000000000 64 X000000000000000 Base address of I/O Map (*) Optional additonal information: You can follow this starting at 68 with OS specific data of arbitrary length (I wouldn't make it too large... the whole thing shouldn't exceed 64k, and should be longword aligned -- the I/O Map Base address is a 16 bit offset). If you are using the Appendix H disclosures to set the virtual 8086 mode interrupt handling by setting bit 0 (Later 486 and Pentium processors or better only), then a CLI, STI, INT, PUSHF, POPF, or IRET is not handled the same was as on the 386 (and 486's before a rev or two after the Pentium was introduced). Instead, the IF register is shadowed in a register called VIF (V=virtual), and modifying EFLAGS IF modifies this instead. A bitmap that must be exactly 8 longwords long (256 bits) then lets you let the interrupt be handled in "real mode" instead of trapping to your Virtual Machine Monitor if the bit is set. The "Base address of I/O Map" field points to the first longword immediately following the above two areas (ie: the processor uses this value and a negative offset of 32 bytes to access the virtual interrupt processing bitmap). The I/O Map must be present if your VM86 task is going to access I/O ports. If you virtualize all accesses, you do not need a bitmap. In theory, the bitmap needs to be 8k. In practice, you can do it in longword chunks up to the TSS limit from the TR if you don't want to permit accesses to ports above some arbitrary limit. (*) If X = 1, a debug exception occurs when switching to the task The TSS descriptor looks like: 0 7 0 LSB of Segment Size 1 2nd byte of Segment size 2 LSB of Base Address 3 2nd byte of Base Address 4 3rd byte of Base Address 5 1 B 0 X S D1 D2 L 6 [ nibble ] U 0 0 G 7 4th byte of Base Address B 1 = task is busy X 0 = 16 bit TSS, 1 = 32 bit TSS S 0 = system segment (must be zero in TSS descriptor) D1&D2 Descriptor Priviledge Level (0 for OS, 3 for user/VM86) P 1 = Segment present nibble upper nibble of Segment Size (20 bits total) U user bit (can be used by FreeBSD, etc.) G Granularity of Segment Size (0 = bytes, 1 = pages) o Set up a hardware timer to force you back. PCAUDIO is a definite drag at this point because of interrupts. o Switch to the task using a far call or jump that selects the TSS descriptor in the GDT. This implies you have a TSS for the OS, since the processor is going to copy the registers out to the OS's TSS. o The processor loads the new task's TSS an uses the CS:EIP from the new TSS to start fetching (and executing) code from the new task. This sort of answers Tony Overfield's "3. Something else..." question: you can get a Task Gate Descriptor in the LDT or GDT or IDT. This means "Something else..." can be triggered by: o A far call o A jump o A hardware interrupt o A software exception o An INT instruction (hello, thunking...) You use a VMM to field the event (in the INT case) in a memory extender; basically you need a VMM to do VM86 mode anyway. It works by being the general purpose exception handler code. A VM86 task pushes the EFLAGS register on the stack, but then clears the VM bit disabling VM86 mode. The exception handler looks at the EFLAGS on the stack to see if the VM bit is set; if it isn't, it does the normal protected mode stuff. If it is, however, the VMM must determine the action requested by the DOS task, and figure out how to do it itself. For example, an INT 21 against 0x80 could be handled as a request to a virtual "C:" actually implemented as a subhierarchy of an FFS mounted volume (Yet Another Reason To Allow Terry's Layering Fixes: now there are *4* VFS consumers: system calls, the NFS server, the kld code, and the newly defined VMM fielding INT 21 calls on behalf of a DOS process. Now we *really* can't keep our eyes tighly closed and pretend it's only system calls...). > > - a 32-bit 'we are the kernel now' context, > > - a 16-bit protected-mode 'let's play with the BIOS' context, and > > - a 16-bit vm86 'let's pretend we are a Microsoft OS' context. > > Too complicated, and inadequate. There is a separate 32-bit context > needed for the APM BIOS as well, and we are out of descriptors already. > The vm86 support handles this differently by creating a kernel process > at a later stage. Because we want to *not* virtualize INT 21 (or more likely INT 13) in the case where we are are running a fallback driver, and *not* virtualize INT 10 in the case where we are calling it (against my better judgement: many VGA cards disable interrupts in BIOS to get rid of "sparklies" any time you call INT 10 -- can you say "sucks"? I knew you could...) to set video modes via BIOS, etc.... Then we want to have at least three TSS's: one for the OS, one for the OS to make BIOS calls with, and one for the OS to run a VM86 for DOS under UNIX (and depending on the complexity of the VMM, maybe even emulate the functions of the 386 to the point of running Windows 95, like some other x86 protected mode OS's can). The APM mention above would be handled in the second context, above. Technically, you could do this using only two GDT's: one for the OS (in this case FreeBSD), and one that you switched off between as many others as you wanted, so long as they never trapped back to something other than the OS exception handler (acting as the VMM) to do their thing. Practically, there are far to many things that rely on the "DOS not busy" interrupt at INT 27 for this to work well... for example, if you wanted to unset the bit for an INT for a network card in the OS TSS and make the VMM switch to a VM86 and run a DOS network card driver to field the interrupt and use real mode IPX or ODI or whatever stacks, and then pass the data to FreeBSD via thunk. This would leave you with two TSS's, which, together, implemented the actual OS (instead of one). Any card driver that ran in DOS but not in FreeBSD could, in principle, be handled the same way. > > - hop into protected mode, create a vm86 task which handle > > loading the kernel. (map the vm86 1M+ range to where you want the > > kernel to go, or do a 1:1 map of all physical memory, and then set > > the vm86's descriptor limit to 4G or so. Do all the loading from > > vm86 mode. much easier code to look at) > > Unfortunately, we have no tools for writing realmode code. I was > perhaps somewhat misleading regarding running the bootstrap in real > mode; please look at the code for an understanding of the issues. I agree. We want to enter protected mode as early as we can, build a VM86, and *stay* in protected mode ever after. > This isn't making a lot of sense to me. Are you implying that one > could be in 32-bit PM and vm86 mode at the same time? No. You can swap them, but one has 16 bit segments, the other 32, so at least two additional TSS's are needed ...but they could be virtual, as stated above, so you'd have only two total real GDT entries, if you felt you were running low... Buy the book; it goes into much more detail than I did, including VM86 mode, task creation, the "magic registers" from Appendix H, including how to do a virtualized INT 10 for a VM86 task to think it has video hardware (it doesn't cover screen writes, but you can do that fairly simply by marking the "screen memory" read-only and taking an exception when it's written; use two timers, the first for latency so that inactivity causes the "real" screen, probably an X window or virtual console, to be updated, and the second, longer one for interval so that even if the display is highly active, you mirror the changes to that point. This lets you do things like graphics fairly quickly, at the cost of keeping a "diff" copy around to note deltas at any given timer firing. Yet Another Reason To Listen To Terry And Put DDX In The Kernel: console graphics for programs running under VM86...). This is entirely more than I had intended to type using only 9 fingers (one of my fingers is currently on strike for the next 6 weeks or so...). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Sun Nov 9 02:32:39 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id CAA29846 for hackers-outgoing; Sun, 9 Nov 1997 02:32:39 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from smtp04.primenet.com (smtp04.primenet.com [206.165.5.85]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id CAA29841 for ; Sun, 9 Nov 1997 02:32:37 -0800 (PST) (envelope-from tlambert@usr06.primenet.com) Received: (from daemon@localhost) by smtp04.primenet.com (8.8.7/8.8.7) id DAA12130; Sun, 9 Nov 1997 03:32:37 -0700 (MST) Received: from usr06.primenet.com(206.165.6.206) via SMTP by smtp04.primenet.com, id smtpd012123; Sun Nov 9 03:32:28 1997 Received: (from tlambert@localhost) by usr06.primenet.com (8.8.5/8.8.5) id DAA24687; Sun, 9 Nov 1997 03:32:24 -0700 (MST) From: Terry Lambert Message-Id: <199711091032.DAA24687@usr06.primenet.com> Subject: Re: x86 gods; advice? Suggestions? To: mike@smith.net.au (Mike Smith) Date: Sun, 9 Nov 1997 10:32:24 +0000 (GMT) Cc: tlambert@primenet.com, mike@smith.net.au, wghhicks@ix.netcom.com, mini@d198-232.uoregon.edu, hackers@FreeBSD.ORG In-Reply-To: <199711090806.SAA00646@word.smith.net.au> from "Mike Smith" at Nov 9, 97 06:36:00 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > And it doesn't lock you into x86 to run the BIOS on video cards... > > where's the fun in that? > > I don't give a shit what it doesn't do, Terry. Boy, no sense of humor. What it *does* do, then is make cards not depend on particular processors. > What *I* care about is that OpenBoot is big, it is expensive and > proprietary, That last arrow struck home (the others missed, though, if expensive is meant in terms of overhead instead of as a subset of proprietary, which would make your statement redundant. Besides, you don't care how long it takes for things you do once, so long as it isn't "too long". I could, for example, bitch about the "waiting for SCSI devices to settle" on that count, since my controller already does that for me... the time it takes doing that -- until I dike it out of my local kernel -- is more than enough time to run OpenBoot several times over). It's true that if Sun was *really* interested in making their "standard" a _standard_, they'd provide source code for the thing. I think it's because they don't sell any machines with PCI slots yet. The people who were pushing it were Motorola, and the PowerComputing and Apple people, who wanted to use commodity cards in their boxes without a per card driver to set video modes, etc.. > and it is a complete crock from the POV of usability. Again, you only need to use it once. The code for the OS is similar to what I've been pushing in terms of VM86 fallback drivers. You don't use it except for the boot, so usability isn't an issue. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Sun Nov 9 02:51:30 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id CAA00863 for hackers-outgoing; Sun, 9 Nov 1997 02:51:30 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id CAA00841 for ; Sun, 9 Nov 1997 02:51:22 -0800 (PST) (envelope-from j@uriah.heep.sax.de) Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id LAA01876 for freebsd-hackers@FreeBSD.ORG; Sun, 9 Nov 1997 11:51:21 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.8.7/8.8.5) id LAA00614; Sun, 9 Nov 1997 11:50:07 +0100 (MET) Message-ID: <19971109115007.JB56482@uriah.heep.sax.de> Date: Sun, 9 Nov 1997 11:50:07 +0100 From: j@uriah.heep.sax.de (J Wunsch) To: freebsd-hackers@FreeBSD.ORG Subject: Re: Why doesn't /bin/echo use getopt? References: <25358.879002601@axl.iafrica.com> <19971108175832.31362@jraynard.demon.co.uk> 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: <19971108175832.31362@jraynard.demon.co.uk>; from James Raynard on Nov 8, 1997 17:58:32 +0000 Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk As James Raynard wrote: > Because it's supposed to repeat its arguments instead of parse them? > (with the exception of -n, of course). Tough question: how do you echo a "-n\n" then (without using printf(1), of course)? -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-hackers Sun Nov 9 03:17:40 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id DAA02088 for hackers-outgoing; Sun, 9 Nov 1997 03:17:40 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from shrimp.dataplex.net (shrimp.dataplex.net [208.2.87.3]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id DAA02079 for ; Sun, 9 Nov 1997 03:17:34 -0800 (PST) (envelope-from rkw@dataplex.net) Received: from [208.2.87.4] (user4.dataplex.net [208.2.87.4]) by shrimp.dataplex.net (8.8.5/8.8.5) with ESMTP id FAA21867; Sun, 9 Nov 1997 05:17:25 -0600 (CST) X-Sender: rkw@mail.dataplex.net Message-Id: In-Reply-To: <19971109115007.JB56482@uriah.heep.sax.de> References: <19971108175832.31362@jraynard.demon.co.uk>; from James Raynard on Nov 8, 1997 17:58:32 +0000 <25358.879002601@axl.iafrica.com> <19971108175832.31362@jraynard.demon.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sun, 9 Nov 1997 05:17:39 -0600 To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) From: Richard Wackerbarth Subject: Re: Why doesn't /bin/echo use getopt? Cc: freebsd-hackers@FreeBSD.ORG Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk At 4:50 AM -0600 11/9/97, J Wunsch wrote: >As James Raynard wrote: > >> Because it's supposed to repeat its arguments instead of parse them? >> (with the exception of -n, of course). > >Tough question: how do you echo a "-n\n" then (without using >printf(1), of course)? echo -n "-n\ " Richard Wackerbarth From owner-freebsd-hackers Sun Nov 9 03:46:02 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id DAA03979 for hackers-outgoing; Sun, 9 Nov 1997 03:46:02 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from hydrogen.nike.efn.org (resnet.uoregon.edu [128.223.170.28]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id DAA03972 for ; Sun, 9 Nov 1997 03:45:58 -0800 (PST) (envelope-from gurney_j@efn.org) Received: (from jmg@localhost) by hydrogen.nike.efn.org (8.8.7/8.8.7) id DAA28173; Sun, 9 Nov 1997 03:45:31 -0800 (PST) Message-ID: <19971109034531.63922@hydrogen.nike.efn.org> Date: Sun, 9 Nov 1997 03:45:31 -0800 From: John-Mark Gurney To: Joerg Wunsch Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Why doesn't /bin/echo use getopt? References: <25358.879002601@axl.iafrica.com> <19971108175832.31362@jraynard.demon.co.uk> <19971109115007.JB56482@uriah.heep.sax.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.69 In-Reply-To: <19971109115007.JB56482@uriah.heep.sax.de>; from J Wunsch on Sun, Nov 09, 1997 at 11:50:07AM +0100 Reply-To: John-Mark Gurney Organization: Cu Networking X-Operating-System: FreeBSD 2.2.1-RELEASE i386 X-PGP-Fingerprint: B7 EC EF F8 AE ED A7 31 96 7A 22 B3 D8 56 36 F4 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk J Wunsch scribbled this message on Nov 9: > As James Raynard wrote: > > > Because it's supposed to repeat its arguments instead of parse them? > > (with the exception of -n, of course). > > Tough question: how do you echo a "-n\n" then (without using > printf(1), of course)? why not: echo -n "-n " hexdump: 0000000 6e2d 000a 0000003 :) -- John-Mark Gurney Modem/FAX: +1 541 683 6954 Cu Networking Live in Peace, destroy Micro$oft, support free software, run FreeBSD From owner-freebsd-hackers Sun Nov 9 04:31:53 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id EAA06242 for hackers-outgoing; Sun, 9 Nov 1997 04:31:53 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from klokan.sh.cvut.cz (root@klokan.sh.cvut.cz [193.84.105.141]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id EAA06237 for ; Sun, 9 Nov 1997 04:31:49 -0800 (PST) (envelope-from J.Klaus@sh.cvut.cz) Received: from skunk.sh.cvut.cz (skunk.sh.cvut.cz [194.108.141.34]) by klokan.sh.cvut.cz (8.6.12/8.6.9) with ESMTP id NAA23704; Sun, 9 Nov 1997 13:31:22 +0100 Received: from SKUNK/SpoolDir by skunk.sh.cvut.cz (Mercury 1.31); 9 Nov 97 13:31:22 +0200 Received: from SpoolDir by SKUNK (Mercury 1.31); 9 Nov 97 13:30:58 +0100 Received: from hell.sh.cvut.cz by skunk.sh.cvut.cz (Mercury 1.31); 9 Nov 97 13:30:50 +0200 Message-ID: X-Mailer: XFMail 1.1 [p0] on FreeBSD Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit MIME-Version: 1.0 In-Reply-To: <3463605C.41C67EA6@whistle.com> Date: Sun, 09 Nov 1997 13:26:42 +0100 (CET) Organization: CTU Prague From: Jaroslav Klaus To: Julian Elischer Subject: RE: Newest Pentium bug (fatal) Cc: hackers@FreeBSD.ORG Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On 07-Nov-97 Julian Elischer wrote: > On a "genuine Intel" pentium (not pentium pro) > execution of the following sequence, 0xf0 0x0f 0xc7 0xc8 > > will stop the processor. This is doable from user mode and in > 16bitmode, or in fact any mode. > > try the following c program. > > > > > unsigned char x[] = { 0xfo, 0x0f, 0xc7, 0xc8 }; > > > main () > { > void (*f)(void) = x; > f(); > } > > > > > We've checked: > K5... OK > P6... OK > P5... *SPLAT* > > no idea about the pentium II or other pentium copies. > K6? > > other pentium variants? > versions? > > this one DEFINITLY dies: > CPU: Pentium (99.38-MHz 586-class CPU) > Origin = "GenuineIntel" Id = 0x525 Stepping=5 > Features=0x1bf > > > share and enjoy.. > > julian ---------------------------------- E-Mail: Jaroslav Klaus Date: 09-Nov-97 Time: 13:26:43 This message was sent by XFMail ---------------------------------- From owner-freebsd-hackers Sun Nov 9 05:57:26 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id FAA12010 for hackers-outgoing; Sun, 9 Nov 1997 05:57:26 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from labinfo.iet.unipi.it (labinfo.iet.unipi.it [131.114.9.5]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id FAA12005 for ; Sun, 9 Nov 1997 05:57:22 -0800 (PST) (envelope-from luigi@labinfo.iet.unipi.it) Received: from localhost (luigi@localhost) by labinfo.iet.unipi.it (8.6.5/8.6.5) id NAA00156; Sun, 9 Nov 1997 13:47:39 +0100 From: Luigi Rizzo Message-Id: <199711091247.NAA00156@labinfo.iet.unipi.it> Subject: atapi cd problems reading last audio track To: hackers@freebsd.org Date: Sun, 9 Nov 1997 13:47:39 +0100 (MET) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I am not sure if others are having this problem... with IDE CD driver, I have always had problems playing the last track of an audio CD. I use cdcontrol, and when I specify "Play" without parameters (or specify a range which includes the last track on a disk) it complains sayin cdcontrol: Input/output error Quickly looking at the cdcontrol source, it seems that the arguments are directly passed to the driver, so the problem might be in the kernel, not in cdcontrol. BTW I can manage to play parts of the last track if I specify times instead of track numbers, and do not request for the complete track (e.g. leaving the last block or second out). Sounds like a bug in the kernel, where the boundary check is off by one... this is on 2.2.1 at least, I cannot check if it has been fixed. Cheers Luigi -----------------------------+-------------------------------------- Luigi Rizzo | Dip. di Ingegneria dell'Informazione email: luigi@iet.unipi.it | Universita' di Pisa tel: +39-50-568533 | via Diotisalvi 2, 56126 PISA (Italy) fax: +39-50-568522 | http://www.iet.unipi.it/~luigi/ _____________________________|______________________________________ From owner-freebsd-hackers Sun Nov 9 06:06:30 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id GAA12312 for hackers-outgoing; Sun, 9 Nov 1997 06:06:30 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from altos.rnd.runnet.ru (altos.rnd.runnet.ru [195.208.248.40]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id GAA12295 for ; Sun, 9 Nov 1997 06:06:18 -0800 (PST) (envelope-from max@rnd.runnet.ru) Received: from altos.rnd.runnet.ru (altos.rnd.runnet.ru [195.208.248.40]) by altos.rnd.runnet.ru (8.8.7/8.8.6) with SMTP id RAA23182 for ; Sun, 9 Nov 1997 17:06:10 +0300 (MSK) Date: Sun, 9 Nov 1997 17:06:10 +0300 (MSK) From: Maxim Bolotin To: hackers@FreeBSD.ORG Subject: RE: Newest Pentium bug (fatal) -- exception handling problem? In-Reply-To: <81EA05D65B95CF11822500A0243D54040103CA@host66.creativedesign.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Fri, 7 Nov 1997, Jonathan Ng wrote: > I've used the same 133MHz Pentium chip to run the experiment. > > Under both FreeBSD and Linux, the system halted immediately. My Solaris 2.5.1 with 2 Intel P133 halted immediately too. (IBM PC Server 320, 2 x Intel Pentium 133). It's realy big problem, it's publicly avalible UNIX for students. RECALL!!!! Max. - Rostov State University Computer Center Rostov-on-Don, +7 (8632) 285794 or 357476 Russia, RUNNet, MAB1-RIPE max@run.net From owner-freebsd-hackers Sun Nov 9 06:07:01 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id GAA12351 for hackers-outgoing; Sun, 9 Nov 1997 06:07:01 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from gargoyle.bazzle.com (gargoyle.bazzle.com [206.103.246.189]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id GAA12343 for ; Sun, 9 Nov 1997 06:06:57 -0800 (PST) (envelope-from ejc@bazzle.com) Received: from gargoyle.bazzle.com (gargoyle.bazzle.com [206.103.246.189]) by gargoyle.bazzle.com (8.8.7/8.8.5) with SMTP id JAA14563; Sun, 9 Nov 1997 09:06:43 -0500 (EST) Date: Sun, 9 Nov 1997 09:06:43 -0500 (EST) From: "Eric J. Chet" To: Terry Lambert cc: "David E. Cross" , julian@whistle.com, hackers@FreeBSD.ORG Subject: Re: Newest Pentium bug (fatal) In-Reply-To: <199711072222.PAA17815@usr06.primenet.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Fri, 7 Nov 1997, Terry Lambert wrote: > > CPU: Pentium (132.96-MHz 586-class CPU) > > Origin = "GenuineIntel" Id = 0x52c Stepping=12 > > Features=0x1bf > > > > Just tested OK for me (no crash) > > An "Id = 0x52b Stepping=12" was reported as crashing. This looks like > the break-point. Not so quickly, CPU: Pentium (133.64-MHz 586-class CPU) Origin = "GenuineIntel" Id = 0x52c Stepping=12 Features=0x3bf STONE DEAD.... Notice the feature difference APIC. Later, Eric Chet -- ejchet@lucent.com || ejc@bazzle.com Systems Analysts - Specializing in OOA, OOD and CORBA Bazzle Systems Consulting, Inc. Software Engineering Services Empowering Your Business for Internet Commerce From owner-freebsd-hackers Sun Nov 9 06:25:49 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id GAA13195 for hackers-outgoing; Sun, 9 Nov 1997 06:25:49 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from heron.doc.ic.ac.uk (0s3QtN1EFLn3v1zC1+NQey8g8/AJhMwO@heron.doc.ic.ac.uk [146.169.2.31]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id GAA13187 for ; Sun, 9 Nov 1997 06:25:45 -0800 (PST) (envelope-from njs3@doc.ic.ac.uk) Received: from oak68.doc.ic.ac.uk [146.169.33.68] ([s0n/XDyqUuM5wa1vpTzrs2mnUzl3KRqp]) by heron.doc.ic.ac.uk with smtp (Exim 1.62 #3) id 0xUYJl-0007gc-00; Sun, 9 Nov 1997 14:26:25 +0000 Received: from njs3 by oak68.doc.ic.ac.uk with local (Exim 1.62 #3) id 0xUYIo-0000rQ-00; Sun, 9 Nov 1997 14:25:26 +0000 From: njs3@doc.ic.ac.uk (Niall Smart) Date: Sun, 9 Nov 1997 14:25:26 +0000 In-Reply-To: Warner Losh "Re: a.out format" (Nov 8, 6:07pm) X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: Warner Losh , njs3@doc.ic.ac.uk (Niall Smart) Subject: Re: a.out format Cc: hackers@freebsd.org Message-Id: Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Nov 8, 6:07pm, Warner Losh wrote: } Subject: Re: a.out format > In message Niall Smart writes: > : Don't suppose anyone knows how the "a.out" format got its name? > > "ld foo.o" used to produce (and still does) a file called a.out by > default. It used to be the only format. Now, that there are others, > you gotta call it something :-). > > Where the name a.out came from is generally believed to be short for > "assembler output" but there has been some other rumors I've heard > over the years. Kinda like .bss (which is supposedly from an old IBM > op code for Blank Storage Section, which was all zeros, but I'm > digressing). Ah, I've also heard Block Started by Symbol, but I prefer Blank Storage Section. Niall From owner-freebsd-hackers Sun Nov 9 06:29:06 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id GAA13397 for hackers-outgoing; Sun, 9 Nov 1997 06:29:06 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from heron.doc.ic.ac.uk (bKVpvXBO1vkG/6RFnyUtUzsDC1KZiCQX@heron.doc.ic.ac.uk [146.169.2.31]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id GAA13390 for ; Sun, 9 Nov 1997 06:29:02 -0800 (PST) (envelope-from njs3@doc.ic.ac.uk) Received: from oak68.doc.ic.ac.uk [146.169.33.68] ([+PUE52t1XYdmu8k2t0rf7dDvu8gv58RA]) by heron.doc.ic.ac.uk with smtp (Exim 1.62 #3) id 0xUYMd-0007gv-00; Sun, 9 Nov 1997 14:29:23 +0000 Received: from njs3 by oak68.doc.ic.ac.uk with local (Exim 1.62 #3) id 0xUYLh-0000ri-00; Sun, 9 Nov 1997 14:28:25 +0000 From: njs3@doc.ic.ac.uk (Niall Smart) Date: Sun, 9 Nov 1997 14:28:25 +0000 In-Reply-To: "Jordan K. Hubbard" "FreeBSD 2.2.5 CDs are now shipping from Walnut Creek CDROM" (Nov 9, 2:17am) X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: "Jordan K. Hubbard" Subject: Re: FreeBSD 2.2.5 CDs are now shipping from Walnut Creek CDROM Cc: hackers@freebsd.org Message-Id: Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Nov 9, 2:17am, "Jordan K. Hubbard" wrote: [snip] > somewhere between $15 - $18. Just for something totally new, we will > also soon have some rather nice FreeBSD polo shirts sporting an > embroidered daemon on the pocket with the word "FreeBSD" below it. > These shirts are of very high quality and with a price tag to match - > $45.00. Not cheap, but still a great gift item for that special > FreeBSD someone in your life this Christmas. :) Ahh yes, someone like me. Niall From owner-freebsd-hackers Sun Nov 9 07:19:23 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id HAA15679 for hackers-outgoing; Sun, 9 Nov 1997 07:19:23 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from rvc1.informatik.ba-stuttgart.de (rvc1.informatik.ba-stuttgart.de [141.31.112.22]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id HAA15674 for ; Sun, 9 Nov 1997 07:19:18 -0800 (PST) (envelope-from helbig@Informatik.BA-Stuttgart.DE) Received: (from helbig@localhost) by rvc1.informatik.ba-stuttgart.de (8.8.7/8.8.5) id QAA04460; Sun, 9 Nov 1997 16:19:09 +0100 (MET) From: Wolfgang Helbig Message-Id: <199711091519.QAA04460@rvc1.informatik.ba-stuttgart.de> Subject: Re: Why doesn't /bin/echo use getopt? In-Reply-To: from Richard Wackerbarth at "Nov 9, 97 05:17:39 am" To: rkw@dataplex.net (Richard Wackerbarth) Date: Sun, 9 Nov 1997 16:19:08 +0100 (MET) Cc: joerg_wunsch@uriah.heep.sax.de, freebsd-hackers@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL30 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > At 4:50 AM -0600 11/9/97, J Wunsch wrote: > >As James Raynard wrote: > > > >> Because it's supposed to repeat its arguments instead of parse them? > >> (with the exception of -n, of course). > > > >Tough question: how do you echo a "-n\n" then (without using > >printf(1), of course)? > > echo -n "-n\ > " Wrong for sh(1). The newline is swallowed by the shell. >From the manual page: "A backslash preceding a \n is treated as a line continuation" $ echo -n "-n > " seems to be an answer to this week's question. Wolfgang From owner-freebsd-hackers Sun Nov 9 07:31:50 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id HAA16124 for hackers-outgoing; Sun, 9 Nov 1997 07:31:50 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from picnic.mat.net (picnic.mat.net [206.246.122.117]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id HAA16118 for ; Sun, 9 Nov 1997 07:31:46 -0800 (PST) (envelope-from chuckr@glue.umd.edu) Received: from localhost (chuckr@localhost) by picnic.mat.net (8.8.7/8.8.5) with SMTP id JAA26813; Sun, 9 Nov 1997 09:27:51 -0500 (EST) X-Authentication-Warning: picnic.mat.net: chuckr owned process doing -bs Date: Sun, 9 Nov 1997 09:27:50 -0500 (EST) From: Chuck Robey X-Sender: chuckr@localhost To: Terry Lambert cc: Tony Overfield , mike@smith.net.au, hackers@FreeBSD.ORG Subject: Re: >64MB In-Reply-To: <199711090753.AAA17086@usr06.primenet.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Sun, 9 Nov 1997, Terry Lambert wrote: > > I can't tell, but I think you're talking about one of these: > > > > 1. ... switching to protected mode, setting larger segment limits > > and then switching back to real mode. > > > > It's very unlikely that you have anything in your config.sys > > that uses this trick. There's no benefit to using it, and > > there are serious compatibility problems with it. > > > > 2. ... the real mode trick of using FFFF:xxxx addressing. > > > > This lets you address up to 64K-16 bytes of memory above 1M in > > real mode. Protected mode is not needed to enable or use this > > trick. It is completely inadequate for loading a kernel. In > > DOS, this is called the HMA "high memory area". It is used > > when use have DOS=HIGH in your config.sys, as one example. > > > > 3. Something else. > > If so, please state it more clearly. > > 3. Something else. > > A) Switch to protected mode. > B) Set up a TSS and call gate. > C) Set up a memory map for real mode, excluding the last 64k in > the 640k->1M window. For it, you leave it unmapped. > D) Set up a data area below the 64k that the code stores what area > of high memory you want to access. > E) "Return" to real mode by calling through the gate. > F) When you need to access a 64k chunk abouve 1M, set which one you > want in the data area, and then access it as if it were in the > 64k region. > G) Take the fault in protected mode. Examine the data region. Map Terry, I don't think that will happen this way. Are you sure you didn't mean VM86 mode, not real mode? The exception won't move you to protected mode automatically (except in VM86 mode). > the desired region in the Real mode last 64k. Return. > > This is not quite trivial, but it's not quite impossible, either. Many > memory managers (even DOS ones) do it every day. > > There are several other you can do using suspend/resume instructions and > similar tricks (documented in the Van Gilluwe book -- I assume that's > what you were referring to in #1? > > > Terry Lambert > terry@lambert.org > --- > Any opinions in this posting are my own and not those of my present > or previous employers. > > ----------------------------+----------------------------------------------- Chuck Robey | Interests include any kind of voice or data chuckr@glue.umd.edu | communications topic, C programming, and Unix. 213 Lakeside Drive Apt T-1 | Greenbelt, MD 20770 | I run Journey2 and picnic, both FreeBSD (301) 220-2114 | version 3.0 current -- and great FUN! ----------------------------+----------------------------------------------- From owner-freebsd-hackers Sun Nov 9 07:50:41 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id HAA17038 for hackers-outgoing; Sun, 9 Nov 1997 07:50:41 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id HAA17028 for ; Sun, 9 Nov 1997 07:50:38 -0800 (PST) (envelope-from j@uriah.heep.sax.de) Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id QAA04956 for hackers@FreeBSD.ORG; Sun, 9 Nov 1997 16:50:31 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.8.7/8.8.5) id QAA01568; Sun, 9 Nov 1997 16:24:21 +0100 (MET) Message-ID: <19971109162421.IH64390@uriah.heep.sax.de> Date: Sun, 9 Nov 1997 16:24:21 +0100 From: j@uriah.heep.sax.de (J Wunsch) To: hackers@FreeBSD.ORG Subject: Re: How useful is this patch? References: <199711090436.UAA26951@freefall.freebsd.org> 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: <199711090436.UAA26951@freefall.freebsd.org>; from Julian Elischer on Nov 8, 1997 20:36:20 -0800 Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk As Julian Elischer wrote: > if a mount option is specified, then setting the SUID bit > on a directory specifies similar inheritance with UIDS as we > presently have with GIDs. As long as it's a mount option (defaulting to off), i think i could live with it. > The SUID bits are hereditary to child directories, and > a file 'given away' in this manner > 1/ cannot be give n to root (would defeat quotas) > 2/ has the execute bits stripped off (and suid) Problem: you can cause someone else a DoS attack by maliciously filling his home directory. (I didn't review the patch itself, so i explicitly don't comment on stylistic etc. bugs. Make sure the style adhers to the requirements of style(9).) -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-hackers Sun Nov 9 07:51:09 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id HAA17075 for hackers-outgoing; Sun, 9 Nov 1997 07:51:09 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id HAA17065 for ; Sun, 9 Nov 1997 07:51:04 -0800 (PST) (envelope-from j@uriah.heep.sax.de) Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id QAA04970 for freebsd-hackers@FreeBSD.ORG; Sun, 9 Nov 1997 16:50:56 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.8.7/8.8.5) id QAA01783; Sun, 9 Nov 1997 16:46:10 +0100 (MET) Message-ID: <19971109164610.QQ32715@uriah.heep.sax.de> Date: Sun, 9 Nov 1997 16:46:10 +0100 From: j@uriah.heep.sax.de (J Wunsch) To: freebsd-hackers@FreeBSD.ORG Subject: Re: Why doesn't /bin/echo use getopt? References: <199711091519.QAA04460@rvc1.informatik.ba-stuttgart.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: <199711091519.QAA04460@rvc1.informatik.ba-stuttgart.de>; from Wolfgang Helbig on Nov 9, 1997 16:19:08 +0100 Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk As Wolfgang Helbig wrote: > $ echo -n "-n > > " > > seems to be an answer to this week's question. I think the less ugly looking answer is echo -n "$randomtext"; echo "" This one has the advantage that it'll also work for the csh unmodified, and seems to be the way out if you don't know whether some user's input ($randomtext) might start with -n. -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-hackers Sun Nov 9 07:51:17 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id HAA17094 for hackers-outgoing; Sun, 9 Nov 1997 07:51:17 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from phoenix.its.rpi.edu (phoenix.its.rpi.edu [128.113.161.45]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id HAA17089 for ; Sun, 9 Nov 1997 07:51:13 -0800 (PST) (envelope-from dec@phoenix.its.rpi.edu) Received: from localhost (dec@localhost) by phoenix.its.rpi.edu (8.8.7/8.8.7) with SMTP id KAA06510; Sun, 9 Nov 1997 10:51:18 -0500 (EST) (envelope-from dec@phoenix.its.rpi.edu) Date: Sun, 9 Nov 1997 10:51:17 -0500 (EST) From: "David E. Cross" To: Joerg Wunsch cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Why doesn't /bin/echo use getopt? In-Reply-To: <19971109115007.JB56482@uriah.heep.sax.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Sun, 9 Nov 1997, J Wunsch wrote: > As James Raynard wrote: > > > Because it's supposed to repeat its arguments instead of parse them? > > (with the exception of -n, of course). > > Tough question: how do you echo a "-n\n" then (without using > printf(1), of course)? The same way you rm(1) a file named -rf/? rm -- -rf/ for echo: echo -- -n\n That would work with getopt(3). -- David Cross ACS Consultant From owner-freebsd-hackers Sun Nov 9 08:00:09 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id IAA17785 for hackers-outgoing; Sun, 9 Nov 1997 08:00:09 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from zeus.xtalwind.net (serial.xtalwind.net [205.160.242.5]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id IAA17762 for ; Sun, 9 Nov 1997 08:00:03 -0800 (PST) (envelope-from jack@diamond.xtalwind.net) Received: from localhost (zeus.xtalwind.net [127.0.0.1]) by zeus.xtalwind.net (8.8.7/8.8.5) with SMTP id LAA21626 for ; Sun, 9 Nov 1997 11:00:01 -0500 (EST) Date: Sun, 9 Nov 1997 11:00:01 -0500 (EST) From: jack X-Sender: jack@zeus.xtalwind.net To: hackers@FreeBSD.ORG Subject: Re: Newest Pentium bug (fatal) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Sun, 9 Nov 1997, Eric J. Chet wrote: > On Fri, 7 Nov 1997, Terry Lambert wrote: > > > > CPU: Pentium (132.96-MHz 586-class CPU) > > > Origin = "GenuineIntel" Id = 0x52c Stepping=12 > > > Features=0x1bf > > > > > > Just tested OK for me (no crash) > > > > An "Id = 0x52b Stepping=12" was reported as crashing. This looks like > > the break-point. > > Not so quickly, > > CPU: Pentium (133.64-MHz 586-class CPU) > Origin = "GenuineIntel" Id = 0x52c Stepping=12 > Features=0x3bf > > STONE DEAD.... > > Notice the feature difference APIC. CPU: Pentium (195.60-MHz 586-class CPU) Origin = "GenuineIntel" Id = 0x52c Stepping=12 Features=0x1bf No APIC, just as dead :( -------------------------------------------------------------------------- Jack O'Neill Finger jacko@diamond.xtalwind.net or jack@xtalwind.net http://www.xtalwind.net/~jacko/pubpgp.html #include for my PGP key. PGP Key fingerprint = F6 C4 E6 D4 2F 15 A7 67 FD 09 E9 3C 5F CC EB CD -------------------------------------------------------------------------- From owner-freebsd-hackers Sun Nov 9 08:06:20 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id IAA18958 for hackers-outgoing; Sun, 9 Nov 1997 08:06:20 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from post.mail.demon.net (post-20.mail.demon.net [194.217.242.27]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id IAA18875 for ; Sun, 9 Nov 1997 08:06:15 -0800 (PST) (envelope-from fhackers@jraynard.demon.co.uk) Received: from jraynard.demon.co.uk ([158.152.42.77]) by post.mail.demon.net id aa2004303; 9 Nov 97 16:00 GMT Received: (from fhackers@localhost) by jraynard.demon.co.uk (8.8.7/8.8.7) id OAA10894; Sun, 9 Nov 1997 14:37:49 GMT (envelope-from fhackers) Message-ID: <19971109143748.29900@jraynard.demon.co.uk> Date: Sun, 9 Nov 1997 14:37:48 +0000 From: James Raynard To: Joerg Wunsch Cc: freebsd-hackers@freebsd.org Subject: Re: Why doesn't /bin/echo use getopt? References: <25358.879002601@axl.iafrica.com> <19971108175832.31362@jraynard.demon.co.uk> <19971109115007.JB56482@uriah.heep.sax.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.81e In-Reply-To: <19971109115007.JB56482@uriah.heep.sax.de>; from J Wunsch on Sun, Nov 09, 1997 at 11:50:07AM +0100 Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Sun, Nov 09, 1997 at 11:50:07AM +0100, J Wunsch wrote: > As James Raynard wrote: > > Tough question: how do you echo a "-n\n" then (without using > printf(1), of course)? The only tricky case is echoing -n followed by a newline: $ echo -n '-n > ' -n $ It's ugly, but it works, and this is a rare situation anyway. [The Unix Programming Environment, Kernighan and Pike] -- In theory, theory is better than practice. In practice, it isn't. James Raynard, Edinburgh, Scotland. http://www.freebsd.org/~jraynard/ From owner-freebsd-hackers Sun Nov 9 08:27:19 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id IAA20664 for hackers-outgoing; Sun, 9 Nov 1997 08:27:19 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from word.smith.net.au (ppp13.portal.net.au [202.12.71.113]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id IAA20653 for ; Sun, 9 Nov 1997 08:27:14 -0800 (PST) (envelope-from mike@word.smith.net.au) Received: from word.smith.net.au (localhost [127.0.0.1]) by word.smith.net.au (8.8.7/8.8.5) with ESMTP id CAA00609 for ; Mon, 10 Nov 1997 02:53:20 +1030 (CST) Message-Id: <199711091623.CAA00609@word.smith.net.au> X-Mailer: exmh version 2.0zeta 7/24/97 To: hackers@freebsd.org Subject: vm86, brief status rundown Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 10 Nov 1997 02:53:19 +1030 From: Mike Smith Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Well, I was hoping to get the vm86 'thunk' stuff nailed down today, but no luck. If I start the vm86daemon kernel process from userland, it works OK, but starting it as a kernel process appears to have a subtle effect that stops it from working. I will be out of town from Tuesday morning until about the 25th or so, and mail connectivity is likely to be patchy (anyone know a good ISP in the London, Ont. area?) during that time. I hope to have some luck chasing the problem, but no guarantees. If someone wants to pursue the matter, I would be more than happy to provide diffs and sample code/functions to demonstrate the current problem, as well as being very grateful. If so, please mail me direct & let me know. mike From owner-freebsd-hackers Sun Nov 9 08:31:07 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id IAA20916 for hackers-outgoing; Sun, 9 Nov 1997 08:31:07 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from server.local.sunyit.edu (A-T34.rh.sunyit.edu [150.156.210.241]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id IAA20908 for ; Sun, 9 Nov 1997 08:31:00 -0800 (PST) (envelope-from perlsta@cs.sunyit.edu) Received: from localhost (perlsta@localhost) by server.local.sunyit.edu (8.8.7/8.8.5) with SMTP id MAA18761; Sun, 9 Nov 1997 12:35:42 -0500 (EST) X-Authentication-Warning: server.local.sunyit.edu: perlsta owned process doing -bs Date: Sun, 9 Nov 1997 12:35:42 -0500 (EST) From: Alfred Perlstein X-Sender: perlsta@server.local.sunyit.edu To: Atipa cc: Charles Mott , hackers@FreeBSD.ORG Subject: Re: IDT processors? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk intel stinks, period. First the Pentium FPU bug, then the PII and PPro FPU bug (anyone besides me know about this?) and now any server out there running shell is vulnerable to DOS from some dumbass with gcc and the ability to paste from a webpage into thier telnet terminal? AMD has a bug with systems with greater than 64 megs of ram With Cyrix chips you're lucky if the damn thing doesn't smolder through your motherboard. plus with the baby wintels they just dfon't have enough testing behind them to see if they have any esoteric bugs like the pentium or worse. sorry for the rant, anyone know where can get a bug free chip? someone has to be making them... :) -Alfred > > What/Who is IDT? I heard about some So. CA startup company using the > SGS/Thompson Fab. Is that them? > > I really doubt the contingent that is affected by this bug would be > likely to trust a no-name chip. The whole point is reliability... > > I would not put mission critial servers on AMD K6 or any Cyrix. There is > no vestal virgin in the X86 market. Intel is still the best of the bunch > for reliability. > > Kevin > From owner-freebsd-hackers Sun Nov 9 08:33:31 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id IAA21001 for hackers-outgoing; Sun, 9 Nov 1997 08:33:31 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from server.local.sunyit.edu (A-T34.rh.sunyit.edu [150.156.210.241]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id IAA20990 for ; Sun, 9 Nov 1997 08:33:28 -0800 (PST) (envelope-from perlsta@cs.sunyit.edu) Received: from localhost (perlsta@localhost) by server.local.sunyit.edu (8.8.7/8.8.5) with SMTP id MAA18765 for ; Sun, 9 Nov 1997 12:38:10 -0500 (EST) X-Authentication-Warning: server.local.sunyit.edu: perlsta owned process doing -bs Date: Sun, 9 Nov 1997 12:38:10 -0500 (EST) From: Alfred Perlstein X-Sender: perlsta@server.local.sunyit.edu To: hackers@FreeBSD.org Subject: Re: IDT processors? In-Reply-To: <34655D0A.F0DCFF37@ix.netcom.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk from what i've heard the IDT chip's FPU is garbage, and it's integer performance is terrible. definetly not high octane stuff, mostly for desktop applications and such, buying one of these for a server system is not a great idea. -Alfred On Sun, 9 Nov 1997, Jerry Hicks wrote: > Atipa wrote: > > > > > also have shell accounts). > > > > > > This could be bad for Intel. I think that there is a limited > > > subset of Pentium owners which now have a *very* strong incentive > > > to obtain replacement chips or go to alternate vendors (AMD or > > > IDT). > > > > > > P.S. Have any FreeBSD users tried out the new IDT chip? > > > > What/Who is IDT? I heard about some So. CA startup company using the > > SGS/Thompson Fab. Is that them? > > > > I really doubt the contingent that is affected by this bug would be > > likely to trust a no-name chip. The whole point is reliability... > > > > I would not put mission critial servers on AMD K6 or any Cyrix. There is > > no vestal virgin in the X86 market. Intel is still the best of the bunch > > for reliability. > > > > Kevin > > Naw, IDT has been around for some time. They've been doing MIPS > processors for a while. They are a premier company well known among > developers of bit-slice systems too, having some hard to find FIFO parts > and such. > > I wouldn't mind using their components if IDT sez they work. They've > always been a pretty credible bunch for us. > > Cheers! > > Jerry Hicks > jerry_hicks@bigfoot.com > ( back to the basement, mumbling something unintelligible :) > From owner-freebsd-hackers Sun Nov 9 08:45:39 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id IAA21754 for hackers-outgoing; Sun, 9 Nov 1997 08:45:39 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from server.local.sunyit.edu (A-T34.rh.sunyit.edu [150.156.210.241]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id IAA21745 for ; Sun, 9 Nov 1997 08:45:35 -0800 (PST) (envelope-from perlsta@cs.sunyit.edu) Received: from localhost (perlsta@localhost) by server.local.sunyit.edu (8.8.7/8.8.5) with SMTP id MAA18782 for ; Sun, 9 Nov 1997 12:50:23 -0500 (EST) X-Authentication-Warning: server.local.sunyit.edu: perlsta owned process doing -bs Date: Sun, 9 Nov 1997 12:50:23 -0500 (EST) From: Alfred Perlstein X-Sender: perlsta@server.local.sunyit.edu To: hackers@FreeBSD.org Subject: Exploring Windows - November 10, 1997 (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk hahahahahah... suffer you fools :) (how did i get on thier mailing list?) if you're interested read all the K-rad things you can do with your mouse in windows... to bad you can't rebind like in X huh? :) ---------- Forwarded message ---------- Date: Sun, 9 Nov 1997 07:18:15 -0800 From: Exploring Windows Editor To: "'perlsta@sunyit.edu'" Subject: Exploring Windows - November 10, 1997 Exploring Windows(R) News - November 10, 1997 ---------------------------------------------------------------------- For additional information, visit: Windows Home Page http://www.microsoft.com/windows/ Microsoft Daily News http://www.microsoft.com/windows/dailynews!/ ---------------------------------------------------------------------- MICROSOFT ANNOUNCES WINDOWS CE 2.0 FOR THE HANDHELD PC http://www.microsoft.com/windowsce/default.asp Microsoft has introduced Windows CE 2.0 for the Handheld PC. The latest version of the Windows CE operating system for the H/PC contains new and improved versions of pocket applications such as Pocket PowerPoint, Pocket Outlook and frames-capable Pocket Internet Explorer. ---------------------------------------------------------------------- BILL GATES AT COMDEX FALL 97 http://www.microsoft.com/events/comdex Kick off your visit to Comdex Fall 97 with Bill Gates' keynote address: 7pm, November 16th, at the Aladdin Hotel. Microsoft's Web site features information about the Microsoft booth, partners, conference sessions and event registration. ---------------------------------------------------------------------- TIPWORLD'S TIP OF THE DAY http://www.tipworld.com This tip originally appeared on the TipWorld web site. KEYBOARD JAMMIN' Here are three keyboard shortcuts you shouldn't be without: Alt-Shift-Tab While Alt-Tab cycles you through open programs and windows, Alt-Shift-Tab cycles you backward through the same list. It's useful when lots of applications are open. Shift-Right-click If you'd like to open a file in a particular application other than the one it's associated with, hold down Shift as you right-mouse-click on the already selected file icon. Select Open With, choose the application in which you'd like to open the files, and click on OK. Shift-Delete Typically, selecting an item and pressing the Delete key sends it to the Recycle Bin (after you click on Yes to confirm that you actually want to send the item there). To bypass the Recycle Bin altogether, hold down Shift as you press Delete. ---------------------------------------------------------------------- INSIDE MICROSOFT WINDOWS 95 TIP OF THE WEEK The following tip is presented by INSIDE MICROSOFT WINDOWS 95, a monthly publication of The Cobb Group. For a FREE issue, go to http://www.cobb.com/w95/cuvyeu.htm CHECKING THE STATUS OF YOUR WINDOWS 95 OPERATIONS Status bars, which you'll find at the bottom of many Windows 95 applications' windows, are useful tools for providing information about the command or operation you're currently performing. For example, if you open a folder in My Computer and select several files, the status bar will tell you how many files you've selected and the combined size of the selected files. When you pull down a menu in a Windows 95 application and position the pointer over a command, the status bar describes the purpose of the command. For example, if you pull down the Insert menu in WordPad and hold the pointer over the Object... command, a description of that command appears in the status bar. In applications that have toolbars, the status bar works with tool tips that display the command name associated with the button in question. For example, if you position your cursor over the undo button on WordPad's toolbar, a tool tip will tell you the button performs an Undo operation. When Windows 95 displays the tool tip, more detailed information about the Undo command appears in the status bar. ---------------------------------------------------------------------- WUGNET SHAREWARE OF THE WEEK http://www.microsoft.com/ntworkstation/shareware/ http://www.microsoft.com/windows/software/shareware/ Each week WUGNET and Microsoft feature a shareware pick demonstrating the highest standards available today in shareware for Windows 95. Try one, try them all! BLACKWIDOW BY SOFTBYTE LABS http://www.softbytelabs.com/files/BlackWidow.exe This week's pick is BlackWidow by SoftByte Labs. This Internet application will scan Web sites and get an Internet Explorer-like view of the site's directory structure and all files within the site. You can then choose which files to download or download the entire site for offline viewing. You can run multiple instances of BlackWidow to work with different Web sites at the same time, as well as perform downloads from one site while profiling another. Black Widow allows you to suspend an operation and resume it at a later time and assign logins and passwords for secure sites. The application also includes functions that enable you to provide proxies and ports, select/deselect files and select any extensions. ---------------------------------------------------------------------- For information on local events and promotions in your area http://microsoft.com/usa/ ---------------------------------------------------------------------- HOW TO JOIN THE MAILING LIST: You received this e-mail newsletter as a result of your registration on the Microsoft Personal Information Center. You may unsubscribe from this newsletter, or subscribe to a variety of other informative newsletters, by returning to the Personal Information Center, http://register.microsoft.com/regwiz/personalinfo.asp and changing your subscription preferences. Alternatively, please send a reply to this e-mail with the word "unsubscribe" as the first line in the body of the message. ---------------------------------------------------------------------- THIS DOCUMENT IS PROVIDED FOR INFORMATIONAL PURPOSES ONLY. The information contained in this document represents the current view of Microsoft Corporation on the issues discussed as of the date of publication. Because Microsoft must respond to change in market conditions, it should not be interpreted to be a commitment on the part of Microsoft and Microsoft cannot guarantee the accuracy of any information presented after the date of publication. INFORMATION PROVIDED IN THIS DOCUMENT IS PROVIDED 'AS IS' WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND FREEDOM FROM INFRINGEMENT. The user assumes the entire risk as to the accuracy and the use of this document. This document may be copied and distributed subject to the following conditions: 1. All text must be copied without modification and all pages must be included 2. All copies must contain Microsoft's copyright notice and any other notices provided therein 3. This document may not be distributed for profit. From owner-freebsd-hackers Sun Nov 9 08:48:48 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id IAA21940 for hackers-outgoing; Sun, 9 Nov 1997 08:48:48 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from server.local.sunyit.edu (A-T34.rh.sunyit.edu [150.156.210.241]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id IAA21935 for ; Sun, 9 Nov 1997 08:48:44 -0800 (PST) (envelope-from perlsta@cs.sunyit.edu) Received: from localhost (perlsta@localhost) by server.local.sunyit.edu (8.8.7/8.8.5) with SMTP id MAA18786 for ; Sun, 9 Nov 1997 12:53:30 -0500 (EST) X-Authentication-Warning: server.local.sunyit.edu: perlsta owned process doing -bs Date: Sun, 9 Nov 1997 12:53:30 -0500 (EST) From: Alfred Perlstein X-Sender: perlsta@server.local.sunyit.edu To: hackers@FreeBSD.org Subject: Lanmanger Hole! In-Reply-To: <19971109162421.IH64390@uriah.heep.sax.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk I think in the latest Dr Dobbs magazine there is an article on how to crack lanmanger passwords, it's not diffucult to do, most people running samba shouold upgrade it to the more secure one that uses NTs security model. (although we don't know how secure that is right? :) ) -Alfred From owner-freebsd-hackers Sun Nov 9 09:38:51 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id JAA24203 for hackers-outgoing; Sun, 9 Nov 1997 09:38:51 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from bagpuss.visint.co.uk (bagpuss.visint.co.uk [194.207.134.1]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id JAA24194; Sun, 9 Nov 1997 09:38:38 -0800 (PST) (envelope-from steve@visint.co.uk) Received: from dylan.visint.co.uk (dylan.visint.co.uk [194.207.134.180]) by bagpuss.visint.co.uk (8.7.5/8.7.3) with SMTP id RAA24091; Sun, 9 Nov 1997 17:38:36 GMT Date: Sun, 9 Nov 1997 17:38:34 +0000 (GMT) From: Stephen Roome To: Julian Elischer cc: hackers@FreeBSD.ORG Subject: Re: How useful is this patch? In-Reply-To: <199711090436.UAA26951@freefall.freebsd.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Sat, 8 Nov 1997, Julian Elischer wrote: > The problem is that there are cases where one unpriveliged user needs > to put files in the 'home directories' of other users. This is OK as long > as the owner of the directory can delete them. This sounds really familiar... what you're suggesting sounds good in practice, and as a mount options thats normally off it's not too much of a problem. > Here is the hack idea. > if a mount option is specified, then setting the SUID bit > on a directory specifies similar inheritance with UIDS as we > presently have with GIDs. In other words, if the USER's home directory > is SUID, then when user B places a hierarchy of files into USER A's > directory, they become owned by user A. This corresponds exactly > with how naive PC users expect things to work. > "It's in my folder so it's mine" > The SUID bits are hereditary to child directories, and > a file 'given away' in this manner > 1/ cannot be give n to root (would defeat quotas) > 2/ has the execute bits stripped off (and suid) Okay, sounds good, what if I am in group wheel and I want to have this option set, and I have a ~/bin directory in my path. Someone could place an executable in my bin directory called "su", this could be a nice password grabber util... My ~/bin dir is last in my path so this isn't too much of a problem except with people figuring that I'm prone to typoing things like "su-" (without a space) which would be a great trojan horse. Okay, I'm quibbling, guess this only means that this system would need to ensure that files placed in other peoples directories like this can't be made executable, and certainly can't overwrite other files that are there. [I didn't get time to read the patch that carefully, so knowing my luck you've thought of this.. struck me as dangerous though.. like chown, any way of getting around ownership permissions usually ends up being root only..] > The advantage to this is that SAMBA and NETATALK, FTP and any other utilities > one may think of, suddenly all start exhibiting 'DOS-USER friendly' > behaviour, without needing to change and maintain those packages. > It can also be turned on and off > so that it would not be turned on in parts of the filesystem used by > 'real' users. You still have netatalk's problem of .Apple* files needed to just browse properly, unless all directories that should be browseable are setuid. Other than that, I get round this by exporting under samba ~ and /home/filestore/transfer/USERNAME which is chmod 777.. that's nasty and ends up with tons of "transfer directories" full of junk that no-one ever deletes.. This is the best alternative I have, so I'll probably be using your patch anyway.. Steve (quibbling) -- Steve Roome - Vision Interactive Ltd. Tel:+44(0)117 9730597 Home:+44(0)976 241342 WWW: http://dylan.visint.co.uk/ From owner-freebsd-hackers Sun Nov 9 09:41:13 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id JAA24310 for hackers-outgoing; Sun, 9 Nov 1997 09:41:13 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from out2.ibm.net (out2.ibm.net [165.87.194.229]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id JAA24302 for ; Sun, 9 Nov 1997 09:41:08 -0800 (PST) (envelope-from mouth@ibm.net) Received: from slip129-37-53-124.ca.us.ibm.net (slip129-37-53-124.ca.us.ibm.net [129.37.53.124]) by out2.ibm.net (8.8.5/8.6.9) with SMTP id RAA92434 for ; Sun, 9 Nov 1997 17:41:05 GMT From: mouth@ibm.net (John Kelly) To: hackers@FreeBSD.ORG Subject: Re: Newest Pentium bug (fatal) Date: Sun, 09 Nov 1997 18:42:20 GMT Message-ID: <3466035d.2461408@smtp-gw01.ny.us.ibm.net> References: <199711090908.DAA05745@argus.tfs.net> In-Reply-To: <199711090908.DAA05745@argus.tfs.net> X-Mailer: Forte Agent 1.01/16.397 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by hub.freebsd.org id JAA24304 Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Sun, 9 Nov 1997 03:08:14 -0600 (CST), Jim Bryant wrote: >this is going to be a real nightmare for intel... how many pentiums >are out there, and i'm begionning to notice a lot of pentium-specific >stuff out there now. the instruction seqquence in question seems to >me to be a type that will be in widespread use in the very near >future. Now I'm really glad I bought a bunch of 486 processors and VLB motherboards on closeout. :-) John From owner-freebsd-hackers Sun Nov 9 09:50:18 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id JAA24726 for hackers-outgoing; Sun, 9 Nov 1997 09:50:18 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from plaut.de (ns.plaut.de [194.39.177.166]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id JAA24721 for ; Sun, 9 Nov 1997 09:50:14 -0800 (PST) (envelope-from afuchs@totum.plaut.de) Received: from totum.plaut.de (totum.plaut.de [194.39.177.9]) by plaut.de (8.6.12/8.6.12) with ESMTP id SAA05426; Sun, 9 Nov 1997 18:50:10 +0100 Received: from localhost (afuchs@localhost) by totum.plaut.de (8.8.7/8.7.3) with SMTP id SAA14576; Sun, 9 Nov 1997 18:50:10 +0100 (MET) Date: Sun, 9 Nov 1997 18:50:10 +0100 (MET) From: alex fuchsstadt To: Luigi Rizzo cc: hackers@FreeBSD.ORG Subject: Re: atapi cd problems reading last audio track In-Reply-To: <199711091247.NAA00156@labinfo.iet.unipi.it> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Sun, 9 Nov 1997, Luigi Rizzo wrote: > I am not sure if others are having this problem... with IDE CD driver, > I have always had problems playing the last track of an audio CD. I use > cdcontrol, and when I specify "Play" without parameters (or specify a > range which includes the last track on a disk) it complains sayin > > cdcontrol: Input/output error > Check how long is the playtime of this CD. Some audioCDs exceed the defined maximum playtime by a few minutes. It depends on the tracking area of the LaserPickUP's mechanic whether it can reach the outer tracks correctly. Also the up <--> down movement of the CD is larger at the outer tracks, so maybe the PickUP is not further able to focus the laserbeam on the surface. These effects depend on the the particular hardware. Some players or drives do it, some not. > Quickly looking at the cdcontrol source, it seems that the arguments > are directly passed to the driver, so the problem might be in the > kernel, not in cdcontrol. > > BTW I can manage to play parts of the last track if I specify times > instead of track numbers, and do not request for the complete track > (e.g. leaving the last block or second out). > > Sounds like a bug in the kernel, where the boundary check is off by > one... this is on 2.2.1 at least, I cannot check if it has been fixed. > > Cheers > Luigi > -----------------------------+-------------------------------------- > Luigi Rizzo | Dip. di Ingegneria dell'Informazione > email: luigi@iet.unipi.it | Universita' di Pisa > tel: +39-50-568533 | via Diotisalvi 2, 56126 PISA (Italy) > fax: +39-50-568522 | http://www.iet.unipi.it/~luigi/ > _____________________________|______________________________________ > Alexander Fuchsstadt -------------------- R/3-Basis Plaut Software GmbH From owner-freebsd-hackers Sun Nov 9 10:50:36 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id KAA27611 for hackers-outgoing; Sun, 9 Nov 1997 10:50:36 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id KAA27599 for ; Sun, 9 Nov 1997 10:50:30 -0800 (PST) (envelope-from j@uriah.heep.sax.de) Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id TAA09498 for freebsd-hackers@FreeBSD.ORG; Sun, 9 Nov 1997 19:50:29 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.8.7/8.8.5) id TAA00491; Sun, 9 Nov 1997 19:39:36 +0100 (MET) Message-ID: <19971109193935.QU33958@uriah.heep.sax.de> Date: Sun, 9 Nov 1997 19:39:35 +0100 From: j@uriah.heep.sax.de (J Wunsch) To: freebsd-hackers@FreeBSD.ORG Subject: Re: Why doesn't /bin/echo use getopt? References: <19971109115007.JB56482@uriah.heep.sax.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: ; from David E. Cross on Nov 9, 1997 10:51:17 -0500 Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk As David E. Cross wrote: > for echo: > echo -- -n\n > > That would work with getopt(3). ...but not with /bin/echo, that's why i was asking. j@uriah 54% /bin/echo -- '-n\n' -- -n\n OTOH, if you were asking for getopt, consider: j@uriah 55% /bin/echo "- today's a great day -" - today's a great day - vs. the getopt(3)ified version: j@uriah 56% /tmp/echo/echo "- today's a great day -" echo: illegal option -- echo: illegal option -- t echo: illegal option -- o echo: illegal option -- d echo: illegal option -- a echo: illegal option -- y echo: illegal option -- ' echo: illegal option -- s echo: illegal option -- echo: illegal option -- a echo: illegal option -- echo: illegal option -- g echo: illegal option -- r echo: illegal option -- e echo: illegal option -- a echo: illegal option -- t echo: illegal option -- echo: illegal option -- d echo: illegal option -- a echo: illegal option -- y echo: illegal option -- -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-hackers Sun Nov 9 10:50:50 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id KAA27636 for hackers-outgoing; Sun, 9 Nov 1997 10:50:50 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id KAA27624 for ; Sun, 9 Nov 1997 10:50:43 -0800 (PST) (envelope-from j@uriah.heep.sax.de) Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id TAA09501 for freebsd-hackers@freebsd.org; Sun, 9 Nov 1997 19:50:35 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.8.7/8.8.5) id TAA00506; Sun, 9 Nov 1997 19:43:18 +0100 (MET) Message-ID: <19971109194318.GE14919@uriah.heep.sax.de> Date: Sun, 9 Nov 1997 19:43:18 +0100 From: j@uriah.heep.sax.de (J Wunsch) To: freebsd-hackers@freebsd.org Subject: Re: Why doesn't /bin/echo use getopt? References: <25358.879002601@axl.iafrica.com> <19971108175832.31362@jraynard.demon.co.uk> <19971109115007.JB56482@uriah.heep.sax.de> <19971109143748.29900@jraynard.demon.co.uk> 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: <19971109143748.29900@jraynard.demon.co.uk>; from James Raynard on Nov 9, 1997 14:37:48 +0000 Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk As James Raynard wrote: > It's ugly, but it works, and this is a rare situation anyway. Well, rare situation or not, the question is if you wanna truly echo something the user has entered into a shell script variable, it seems your only option is to always do it this way. Nobody does, of course, which means all these scripts are probably vulnerable against input starting with -n. SysV is worse, since they were `smart' with their backslashomania (as opposed to BSD inventing printf(1) for this purpose). It seems to be nearly impossible to echo a string verbatim in SysV if you don't know what the string is. > [The Unix Programming Environment, Kernighan and Pike] Oh, that's cheating. :-) -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-hackers Sun Nov 9 11:00:38 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id LAA28259 for hackers-outgoing; Sun, 9 Nov 1997 11:00:38 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from thought.calbbs.com (thought.calbbs.com [207.71.213.16]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id LAA28251 for ; Sun, 9 Nov 1997 11:00:34 -0800 (PST) (envelope-from brian@wasteland.calbbs.com) Received: from localhost (localhost [127.0.0.1]) by thought.calbbs.com (8.8.7/8.6.12) with SMTP id TAA05806 for ; Sun, 9 Nov 1997 19:00:38 GMT Date: Sun, 9 Nov 1997 11:00:38 -0800 (PST) From: "Brian W. Buchanan" X-Sender: brian@thought.calbbs.com To: hackers@FreeBSD.ORG Subject: GNU Assembler - new version? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Is it possible we could see a new version of the GNU assembler for -STABLE anytime soon? The version currently present in the tree seems to date back to 1992 or 1993, and lacks some features of more recent versions. I've tried grabbing a newer version of gas from the GNU binutils-2.8, but the configure script doesn't recognize FreeBSD, and I'm not knowledgeable (or patient) enough to hack it into working. -- Brian Buchanan brian@wasteland.calbbs.com "So now I'm an undemocratic, elitist `privacy extremist,' eh? Just like Thomas Jefferson? What's next? I'm presumed a terrorist until I turn over my encryption keys?" If privacy is outlawed, only outlaws will have privacy. Million Microbe March: Small is Beautiful. From owner-freebsd-hackers Sun Nov 9 11:12:35 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id LAA28965 for hackers-outgoing; Sun, 9 Nov 1997 11:12:35 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from labinfo.iet.unipi.it (labinfo.iet.unipi.it [131.114.9.5]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id LAA28958 for ; Sun, 9 Nov 1997 11:12:29 -0800 (PST) (envelope-from luigi@labinfo.iet.unipi.it) Received: from localhost (luigi@localhost) by labinfo.iet.unipi.it (8.6.5/8.6.5) id TAA00407; Sun, 9 Nov 1997 19:01:19 +0100 From: Luigi Rizzo Message-Id: <199711091801.TAA00407@labinfo.iet.unipi.it> Subject: Re: atapi cd problems reading last audio track To: afuchs@totum.plaut.de (alex fuchsstadt) Date: Sun, 9 Nov 1997 19:01:18 +0100 (MET) Cc: hackers@FreeBSD.ORG In-Reply-To: from "alex fuchsstadt" at Nov 9, 97 06:49:51 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > On Sun, 9 Nov 1997, Luigi Rizzo wrote: > > > I am not sure if others are having this problem... with IDE CD driver, > > I have always had problems playing the last track of an audio CD. I use > > cdcontrol, and when I specify "Play" without parameters (or specify a > > range which includes the last track on a disk) it complains sayin > > > > cdcontrol: Input/output error > > Check how long is the playtime of this CD. Some audioCDs exceed the nope, it's the atapi cmd that returns the error immediately. and in fact as I already wrote: > > BTW I can manage to play parts of the last track if I specify times > > instead of track numbers, and do not request for the complete track > > (e.g. leaving the last block or second out). so i can play almost everything but the very last bits of the last track. Luigi From owner-freebsd-hackers Sun Nov 9 11:21:23 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id LAA29429 for hackers-outgoing; Sun, 9 Nov 1997 11:21:23 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from isbalham.ist.co.uk (isbalham.ist.co.uk [192.31.26.1]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id LAA29408 for ; Sun, 9 Nov 1997 11:21:17 -0800 (PST) (envelope-from rb@gid.co.uk) Received: from gid.co.uk (uucp@localhost) by isbalham.ist.co.uk (8.8.4/8.8.4) with UUCP id TAA18765; Sun, 9 Nov 1997 19:04:56 GMT Received: from [194.32.164.2] by seagoon.gid.co.uk; Sun, 9 Nov 1997 18:58:13 GMT X-Sender: rb@194.32.164.1 Message-Id: In-Reply-To: References: Warner Losh "Re: a.out format" (Nov 8, 6:07pm) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sun, 9 Nov 1997 18:57:36 +0000 To: njs3@doc.ic.ac.uk (Niall Smart) From: Bob Bishop Subject: Re: a.out format Cc: hackers@FreeBSD.ORG, Warner Losh Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk At 2:25 pm +0000 9/11/97, Niall Smart wrote: >On Nov 8, 6:07pm, Warner Losh wrote: >} Subject: Re: a.out format >> In message Niall Smart writes: >> [...] Kinda like .bss (which is supposedly from an old IBM >> op code for Blank Storage Section, which was all zeros, but I'm >> digressing). > >Ah, I've also heard Block Started by Symbol, but I prefer Blank Storage >Section. Block Started by Symbol was strictly correct, an *uninitialised* hole in the allocation with a label at the front. -- Bob Bishop (0118) 977 4017 international code +44 118 rb@gid.co.uk fax (0118) 989 4254 between 0800 and 1800 UK From owner-freebsd-hackers Sun Nov 9 11:42:42 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id LAA00667 for hackers-outgoing; Sun, 9 Nov 1997 11:42:42 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from phoenix.its.rpi.edu (phoenix.its.rpi.edu [128.113.161.45]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id LAA00658 for ; Sun, 9 Nov 1997 11:42:35 -0800 (PST) (envelope-from dec@phoenix.its.rpi.edu) Received: from localhost (dec@localhost) by phoenix.its.rpi.edu (8.8.7/8.8.7) with SMTP id OAA24593; Sun, 9 Nov 1997 14:42:38 -0500 (EST) (envelope-from dec@phoenix.its.rpi.edu) Date: Sun, 9 Nov 1997 14:42:37 -0500 (EST) From: "David E. Cross" To: Howard Lew cc: Tony Kimball , hackers@FreeBSD.ORG Subject: Re: Newest Pentium bug (fatal) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Sat, 8 Nov 1997, Howard Lew wrote: > On Sat, 8 Nov 1997, Tony Kimball wrote: > > > ! Compared with the aforementioned > > ! floating-point bug, this seems like a much bigger deal. > > > > No, the FP bug was infinitely worse, because it would silently give > > wrong answers. You could crash the Thai Bhat by accident with an old > > Pentium chip. In this case, the machine is locked -- no one is going The floating point bug could be corrected in software by the OS fairly easily (in fact it has on windows, not sure about FreeBSD), this can't to my knowledge, unless you are going to have your OS's check each opcode before it is executed (for CS people out there that is O(really-nasty) ;). my $0.02. -- David Cross From owner-freebsd-hackers Sun Nov 9 11:43:49 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id LAA00729 for hackers-outgoing; Sun, 9 Nov 1997 11:43:49 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from trojanhorse.ml.org (mdean.vip.best.com [206.86.94.101]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id LAA00723 for ; Sun, 9 Nov 1997 11:43:39 -0800 (PST) (envelope-from jamil@trojanhorse.ml.org) Received: from localhost (jamil@localhost) by trojanhorse.ml.org (8.8.7/8.8.5) with SMTP id LAA01434; Sun, 9 Nov 1997 11:43:04 -0800 (PST) Date: Sun, 9 Nov 1997 11:43:04 -0800 (PST) From: "Jamil J. Weatherbee" To: Alfred Perlstein cc: Atipa , Charles Mott , hackers@FreeBSD.ORG Subject: Re: IDT processors? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk ALPHA, get that freebsd port done! On Sun, 9 Nov 1997, Alfred Perlstein wrote: > intel stinks, period. > First the Pentium FPU bug, then the PII and PPro FPU bug (anyone besides > me know about this?) and now any server out there running shell is > vulnerable to DOS from some dumbass with gcc and the ability to paste from > a webpage into thier telnet terminal? > > AMD has a bug with systems with greater than 64 megs of ram > With Cyrix chips you're lucky if the damn thing doesn't smolder through > your motherboard. > > plus with the baby wintels they just dfon't have enough testing behind > them to see if they have any esoteric bugs like the pentium or worse. > > sorry for the rant, anyone know where can get a bug free chip? someone > has to be making them... :) > > -Alfred > > > > > What/Who is IDT? I heard about some So. CA startup company using the > > SGS/Thompson Fab. Is that them? > > > > I really doubt the contingent that is affected by this bug would be > > likely to trust a no-name chip. The whole point is reliability... > > > > I would not put mission critial servers on AMD K6 or any Cyrix. There is > > no vestal virgin in the X86 market. Intel is still the best of the bunch > > for reliability. > > > > Kevin > > > > From owner-freebsd-hackers Sun Nov 9 11:45:05 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id LAA00849 for hackers-outgoing; Sun, 9 Nov 1997 11:45:05 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from horst.bfd.com (horst.bfd.com [204.160.242.10]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id LAA00833 for ; Sun, 9 Nov 1997 11:45:00 -0800 (PST) (envelope-from ejs@bfd.com) Received: from harlie.bfd.com (bastion.bfd.com [204.160.242.14]) by horst.bfd.com (8.8.5/8.7.3) with SMTP id LAA17947; Sun, 9 Nov 1997 11:44:51 -0800 (PST) Date: Sun, 9 Nov 1997 11:44:51 -0800 (PST) From: "Eric J. Schwertfeger" To: Alfred Perlstein cc: Atipa , Charles Mott , hackers@FreeBSD.ORG Subject: Re: IDT processors? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Sun, 9 Nov 1997, Alfred Perlstein wrote: > AMD has a bug with systems with greater than 64 megs of ram Fixed in newer revisions of the chip, but I don't have all the data. Last I checked (about a month ago), the only supplier that understood the difference had the fixed chips for the K6 200mhz and less, but not the K6 233. From owner-freebsd-hackers Sun Nov 9 11:47:12 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id LAA00995 for hackers-outgoing; Sun, 9 Nov 1997 11:47:12 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from trojanhorse.ml.org (mdean.vip.best.com [206.86.94.101]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id LAA00981 for ; Sun, 9 Nov 1997 11:47:08 -0800 (PST) (envelope-from jamil@trojanhorse.ml.org) Received: from localhost (jamil@localhost) by trojanhorse.ml.org (8.8.7/8.8.5) with SMTP id LAA01446; Sun, 9 Nov 1997 11:46:33 -0800 (PST) Date: Sun, 9 Nov 1997 11:46:33 -0800 (PST) From: "Jamil J. Weatherbee" To: John Kelly cc: hackers@FreeBSD.ORG Subject: Re: Newest Pentium bug (fatal) In-Reply-To: <3466035d.2461408@smtp-gw01.ny.us.ibm.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk This is the same reason I trust the CYRIX 6x86, it is a damn hyperactive 486. In fact I held onto my 486-120 for quite some time, if they had only increased the cache and memory bandwidth on those things, keep the damn thing simple you intel bastards. On Sun, 9 Nov 1997, John Kelly wrote: > On Sun, 9 Nov 1997 03:08:14 -0600 (CST), Jim Bryant > wrote: > > >this is going to be a real nightmare for intel... how many pentiums > >are out there, and i'm begionning to notice a lot of pentium-specific > >stuff out there now. the instruction seqquence in question seems to > >me to be a type that will be in widespread use in the very near > >future. > > Now I'm really glad I bought a bunch of 486 processors and VLB > motherboards on closeout. :-) > > John > > > From owner-freebsd-hackers Sun Nov 9 11:55:13 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id LAA01453 for hackers-outgoing; Sun, 9 Nov 1997 11:55:13 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from alpha.xerox.com (alpha.Xerox.COM [13.1.64.93]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id LAA01448 for ; Sun, 9 Nov 1997 11:55:10 -0800 (PST) (envelope-from fenner@parc.xerox.com) Received: from crevenia.parc.xerox.com ([13.2.116.11]) by alpha.xerox.com with SMTP id <52892(5)>; Sun, 9 Nov 1997 11:54:35 PST Received: from localhost by crevenia.parc.xerox.com with SMTP id <177476>; Sun, 9 Nov 1997 11:54:26 -0800 To: Joe McGuckin cc: hackers@freebsd.org Subject: Re: TCP questions In-reply-to: Your message of "Sun, 09 Nov 97 00:35:42 PST." <199711090835.AAA14711@monk.via.net> Date: Sun, 9 Nov 1997 11:54:20 PST From: Bill Fenner Message-Id: <97Nov9.115426pst.177476@crevenia.parc.xerox.com> Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Joe McGuckin wrote: > 48: 2000 1d0c 0000 0204 05b4 05b4 ........... > >What the heck is that other 0x05b4 in the data stream ? I never see >in on the receiving end... It's padding. Look at the IP length. >Can ACK or SYN packets carry application level data as well ? Yes. Almost every packet after the establishment of a TCP connection is an ACK packet. >Is this sending a bunch of nulls to the other telnet client ? No. Look at the IP length. The first "0000" is the TCP urgent pointer (the end of the TCP header), and the IP packet ends there; the futher "0000"'s are padding. >How does the push flag work? If the packet is less than the segment >size and the push flag is zero, does that mean that there's no >payload ? If the push flag is off, it means "you may delay 'pushing' this data up to the receiving user"; if it's on it means to deliver the data to the receiver as soon as possible. Use the IP length to determine how much payload there is. Bill From owner-freebsd-hackers Sun Nov 9 12:10:19 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id MAA02161 for hackers-outgoing; Sun, 9 Nov 1997 12:10:19 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from plaut.de (ns.plaut.de [194.39.177.166]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id MAA02153 for ; Sun, 9 Nov 1997 12:10:15 -0800 (PST) (envelope-from afuchs@totum.plaut.de) Received: from totum.plaut.de (totum.plaut.de [194.39.177.9]) by plaut.de (8.6.12/8.6.12) with ESMTP id VAA05571; Sun, 9 Nov 1997 21:10:12 +0100 Received: from localhost (afuchs@localhost) by totum.plaut.de (8.8.7/8.7.3) with SMTP id VAA14795; Sun, 9 Nov 1997 21:10:12 +0100 (MET) Date: Sun, 9 Nov 1997 21:10:12 +0100 (MET) From: alex fuchsstadt To: Luigi Rizzo cc: hackers@freebsd.org Subject: Re: atapi cd problems reading last audio track In-Reply-To: <199711091801.TAA00407@labinfo.iet.unipi.it> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Sun, 9 Nov 1997, Luigi Rizzo wrote: > > On Sun, 9 Nov 1997, Luigi Rizzo wrote: > > > > > I am not sure if others are having this problem... with IDE CD driver, > > > I have always had problems playing the last track of an audio CD. I use > > > cdcontrol, and when I specify "Play" without parameters (or specify a > > > range which includes the last track on a disk) it complains sayin > > > > > > cdcontrol: Input/output error > > > > Check how long is the playtime of this CD. Some audioCDs exceed the > > nope, it's the atapi cmd that returns the error immediately. and in > fact as I already wrote: > > > > BTW I can manage to play parts of the last track if I specify times > > > instead of track numbers, and do not request for the complete track > > > (e.g. leaving the last block or second out). > > so i can play almost everything but the very last bits of the last > track. That also complies the reasons I mentioned. Oh, pardon I talked about tracks, maybe in your opinion a track is the whole title. Acording to mine, a track is only one "line" of information during 360 degrees of disk spin. > > Luigi > Alexander Fuchsstadt -------------------- R/3-Basis Plaut Software GmbH From owner-freebsd-hackers Sun Nov 9 12:55:47 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id MAA04163 for hackers-outgoing; Sun, 9 Nov 1997 12:55:47 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from gvr.gvr.org (root@gvr.gvr.org [194.151.74.97]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id MAA04158 for ; Sun, 9 Nov 1997 12:55:44 -0800 (PST) (envelope-from guido@gvr.org) Received: (from guido@localhost) by gvr.gvr.org (8.8.6/8.8.5) id VAA22935; Sun, 9 Nov 1997 21:55:37 +0100 (MET) From: Guido van Rooij Message-Id: <199711092055.VAA22935@gvr.gvr.org> Subject: Re: Newest Pentium bug (fatal) In-Reply-To: from Finn Arne Gangstad at "Nov 7, 97 10:03:48 pm" To: finnag@guardian.no (Finn Arne Gangstad) Date: Sun, 9 Nov 1997 21:55:37 +0100 (MET) Cc: hackers@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL32 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Finn Arne Gangstad wrote: > > EEk - don't try this on a compaq armada 1510 - no hard reset button (that > i can find) and power button is also soft power - so now I have to wait > for the battery to go empty on me.. Are you sure it has no hard reset? Try ctrl-alt-suspend. -Guido From owner-freebsd-hackers Sun Nov 9 13:00:58 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id NAA04483 for hackers-outgoing; Sun, 9 Nov 1997 13:00:58 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from shadows.aeon.net (bsdhack@shadows.aeon.net [194.100.41.1]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id NAA04477 for ; Sun, 9 Nov 1997 13:00:50 -0800 (PST) (envelope-from bsdhack@shadows.aeon.net) Received: (from bsdhack@localhost) by shadows.aeon.net (8.8.7/8.8.3) id WAA17476; Sun, 9 Nov 1997 22:54:43 +0200 (EET) From: mika ruohotie Message-Id: <199711092054.WAA17476@shadows.aeon.net> Subject: Re: IDT processors? In-Reply-To: from "Jamil J. Weatherbee" at "Nov 9, 97 11:43:04 am" To: jamil@trojanhorse.ml.org (Jamil J. Weatherbee) Date: Sun, 9 Nov 1997 22:54:43 +0200 (EET) Cc: perlsta@cs.sunyit.edu, freebsd@atipa.com, cmott@srv.net, hackers@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-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > ALPHA, get that freebsd port done! why would anyone want to use anything else than r10000? now, _that_ would be a port i'd like to see, freebsd on SGI platform. how likely is it? mickey From owner-freebsd-hackers Sun Nov 9 13:11:14 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id NAA04928 for hackers-outgoing; Sun, 9 Nov 1997 13:11:14 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from lestat.nas.nasa.gov (lestat.nas.nasa.gov [129.99.50.29]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id NAA04923 for ; Sun, 9 Nov 1997 13:11:12 -0800 (PST) (envelope-from thorpej@lestat.nas.nasa.gov) Received: from localhost (localhost [127.0.0.1]) by lestat.nas.nasa.gov (8.8.7/8.6.12) with SMTP id NAA17325; Sun, 9 Nov 1997 13:12:00 -0800 (PST) Message-Id: <199711092112.NAA17325@lestat.nas.nasa.gov> X-Authentication-Warning: lestat.nas.nasa.gov: localhost [127.0.0.1] didn't use HELO protocol To: njs3@doc.ic.ac.uk (Niall Smart) Cc: hackers@freebsd.org Subject: Re: a.out format Reply-To: Jason Thorpe From: Jason Thorpe Date: Sun, 09 Nov 1997 13:11:59 -0800 Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Sat, 8 Nov 1997 22:55:27 +0000 njs3@doc.ic.ac.uk (Niall Smart) wrote: > Don't suppose anyone knows how the "a.out" format got its name? "assembler output" as I recall... Jason R. Thorpe thorpej@nas.nasa.gov NASA Ames Research Center Home: +1 408 866 1912 NAS: M/S 258-6 Work: +1 650 604 0935 Moffett Field, CA 94035 Pager: +1 415 428 6939 From owner-freebsd-hackers Sun Nov 9 13:35:54 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id NAA06348 for hackers-outgoing; Sun, 9 Nov 1997 13:35:54 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from zippy.dyn.ml.org (haiti-67.ppp.hooked.net [206.169.228.67]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id NAA06340 for ; Sun, 9 Nov 1997 13:35:50 -0800 (PST) (envelope-from garbanzo@hooked.net) Received: from localhost (garbanzo@localhost) by zippy.dyn.ml.org (8.8.7/8.8.7) with SMTP id NAA18216; Sun, 9 Nov 1997 13:36:30 -0800 (PST) X-Authentication-Warning: zippy.dyn.ml.org: garbanzo owned process doing -bs Date: Sun, 9 Nov 1997 13:36:29 -0800 (PST) From: Alex X-Sender: garbanzo@zippy.dyn.ml.org To: "Brian W. Buchanan" cc: hackers@FreeBSD.ORG Subject: Re: GNU Assembler - new version? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Sun, 9 Nov 1997, Brian W. Buchanan wrote: > Is it possible we could see a new version of the GNU assembler for -STABLE > anytime soon? The version currently present in the tree seems to date > back to 1992 or 1993, and lacks some features of more recent versions. > I've tried grabbing a newer version of gas from the GNU binutils-2.8, but > the configure script doesn't recognize FreeBSD, and I'm not knowledgeable > (or patient) enough to hack it into working. I think the newer GNU binutils have dropped support for the a.out format, which FreeBSD uses, so until -current switches over to ELF, you're out of luck (I think). - alex From owner-freebsd-hackers Sun Nov 9 13:44:05 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id NAA06908 for hackers-outgoing; Sun, 9 Nov 1997 13:44:05 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from blackhole.iceworld.org (griffin@blackhole.iceworld.org [204.246.64.101]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id NAA06894 for ; Sun, 9 Nov 1997 13:44:01 -0800 (PST) (envelope-from griffin@blackhole.iceworld.org) Received: from localhost (griffin@localhost) by blackhole.iceworld.org (8.8.7/8.8.7) with SMTP id PAA03635; Sun, 9 Nov 1997 15:43:48 -0600 Date: Sun, 9 Nov 1997 15:43:44 -0600 (CST) From: Jimbo Bahooli To: Alfred Perlstein cc: Atipa , Charles Mott , hackers@FreeBSD.ORG Subject: Re: IDT processors? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Sun, 9 Nov 1997, Alfred Perlstein wrote: > intel stinks, period. > First the Pentium FPU bug, then the PII and PPro FPU bug (anyone besides > me know about this?) and now any server out there running shell is > vulnerable to DOS from some dumbass with gcc and the ability to paste from > a webpage into thier telnet terminal? > > AMD has a bug with systems with greater than 64 megs of ram This bug has been fixed with AMD chips. It was fixed around september 15th and if you have a broken AMD chip, AMD will be more then happy to fix the situation. > With Cyrix chips you're lucky if the damn thing doesn't smolder through > your motherboard. > > -Alfred > From owner-freebsd-hackers Sun Nov 9 13:51:37 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id NAA07371 for hackers-outgoing; Sun, 9 Nov 1997 13:51:37 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from trojanhorse.ml.org (mdean.vip.best.com [206.86.94.101]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id NAA07364 for ; Sun, 9 Nov 1997 13:51:33 -0800 (PST) (envelope-from jamil@trojanhorse.ml.org) Received: from localhost (jamil@localhost) by trojanhorse.ml.org (8.8.7/8.8.5) with SMTP id NAA13949; Sun, 9 Nov 1997 13:50:34 -0800 (PST) Date: Sun, 9 Nov 1997 13:50:34 -0800 (PST) From: "Jamil J. Weatherbee" To: mika ruohotie cc: perlsta@cs.sunyit.edu, freebsd@atipa.com, cmott@srv.net, hackers@FreeBSD.ORG Subject: Re: IDT processors? In-Reply-To: <199711092054.WAA17476@shadows.aeon.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Did anyone ever notice that 80386 backwards in 68308, does that mean that intel crap is just ass backwards motorola 68000's? What is the highest 68000 at this time 68400? How fast? In my opinion, gaining performance by making a hotter more complicated cpu is no kind of solution. We should of gone multiprocessing back on the 386's. It is still not a solution either because I dont believe in any computer that has moving parts when it comes to reliablity. The machine should be completly sealed from the environment (no dust) and fully submersible (more or less). On Sun, 9 Nov 1997, mika ruohotie wrote: > > ALPHA, get that freebsd port done! > > why would anyone want to use anything else than r10000? > > now, _that_ would be a port i'd like to see, freebsd on SGI platform. > > how likely is it? > > > mickey > From owner-freebsd-hackers Sun Nov 9 13:55:54 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id NAA07675 for hackers-outgoing; Sun, 9 Nov 1997 13:55:54 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from DNS.Lamb.net (root@DNS.Lamb.net [207.90.181.1]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id NAA07664 for ; Sun, 9 Nov 1997 13:55:52 -0800 (PST) (envelope-from ulf@Gatekeeper.Alameda.net) Received: (from uucp@localhost) by DNS.Lamb.net (8.8.6/8.8.6) id NAA03970; Sun, 9 Nov 1997 13:56:01 -0800 (PST) Received: from gatekeeper.Alameda.net(207.90.181.2) via SMTP by DNS.Lamb.net, id smtpd003968; Sun Nov 9 13:55:52 1997 Received: (from ulf@localhost) by Gatekeeper.Alameda.net (8.8.6/8.7.6) id NAA15695; Sun, 9 Nov 1997 13:55:39 -0800 (PST) From: Ulf Zimmermann Message-Id: <199711092155.NAA15695@Gatekeeper.Alameda.net> Subject: Re: IDT processors? In-Reply-To: <199711092054.WAA17476@shadows.aeon.net> from mika ruohotie at "Nov 9, 97 10:54:43 pm" To: bsdhack@shadows.aeon.net (mika ruohotie) Date: Sun, 9 Nov 1997 13:55:39 -0800 (PST) Cc: jamil@trojanhorse.ml.org, perlsta@cs.sunyit.edu, freebsd@atipa.com, cmott@srv.net, hackers@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-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > ALPHA, get that freebsd port done! > > why would anyone want to use anything else than r10000? > > now, _that_ would be a port i'd like to see, freebsd on SGI platform. > > how likely is it? > > > mickey Then let's start a port. I have an O2 R10K at home. I might be able to get some insider information. Considering that people internal have done a Linux port (or part of it) as also they have done a NT kernel for a Challenge L. On the other side I am looking at a project involving a Mips R4300i, a SCSI controller and several EIDE controller ;-) Ulf. --------------------------------------------------------------------- Ulf Zimmermann, 1525 Pacific Ave., Alameda, CA-94501, #: 510-769-2936 Alameda Networks, Inc. | http://www.Alameda.net | Fax#: 510-521-5073 From owner-freebsd-hackers Sun Nov 9 14:03:19 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id OAA08207 for hackers-outgoing; Sun, 9 Nov 1997 14:03:19 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from whistle.com (s205m131.whistle.com [207.76.205.131]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id OAA08200 for ; Sun, 9 Nov 1997 14:03:15 -0800 (PST) (envelope-from archie@whistle.com) Received: (from smap@localhost) by whistle.com (8.7.5/8.6.12) id OAA11903; Sun, 9 Nov 1997 14:02:43 -0800 (PST) Received: from bubba.whistle.com(207.76.205.7) by whistle.com via smap (V1.3) id sma011901; Sun Nov 9 14:02:20 1997 Received: (from archie@localhost) by bubba.whistle.com (8.8.5/8.6.12) id OAA00530; Sun, 9 Nov 1997 14:02:20 -0800 (PST) From: Archie Cobbs Message-Id: <199711092202.OAA00530@bubba.whistle.com> Subject: Re: How useful is this patch? In-Reply-To: <19971109162421.IH64390@uriah.heep.sax.de> from J Wunsch at "Nov 9, 97 04:24:21 pm" To: joerg_wunsch@uriah.heep.sax.de Date: Sun, 9 Nov 1997 14:02:20 -0800 (PST) Cc: hackers@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-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk J Wunsch writes: > As Julian Elischer wrote: > > > if a mount option is specified, then setting the SUID bit > > on a directory specifies similar inheritance with UIDS as we > > presently have with GIDs. > > As long as it's a mount option (defaulting to off), i think i could > live with it. > > > The SUID bits are hereditary to child directories, and > > a file 'given away' in this manner > > 1/ cannot be give n to root (would defeat quotas) > > 2/ has the execute bits stripped off (and suid) > > Problem: you can cause someone else a DoS attack by maliciously > filling his home directory. This attack would require that you have given the other user write permission to your home directory, at least. -Archie ___________________________________________________________________________ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com From owner-freebsd-hackers Sun Nov 9 14:15:27 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id OAA09086 for hackers-outgoing; Sun, 9 Nov 1997 14:15:27 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from rah.star-gate.com (rah.star-gate.com [204.188.121.18]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id OAA09073; Sun, 9 Nov 1997 14:15:22 -0800 (PST) (envelope-from hasty@rah.star-gate.com) Received: from rah.star-gate.com (localhost.v-site.net [127.0.0.1]) by rah.star-gate.com (8.8.7/8.8.5) with ESMTP id OAA00317; Sun, 9 Nov 1997 14:15:21 -0800 (PST) Message-Id: <199711092215.OAA00317@rah.star-gate.com> X-Mailer: exmh version 2.0zeta 7/24/97 To: multimedia@freebsd.org cc: hackers@freebsd.org Subject: http://www.mpegtv.com/ Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 09 Nov 1997 14:15:21 -0800 From: Amancio Hasty Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Please try the BSD/OS version of mpegtv . Tristan the author of mpegtv needs feedback . Tristan claims that about 100 linux users / day are downloading his mpeg player. mpegtv uses the linux sound driver 3.5 ioctl interface which is available from -current and the latest version for -current of the sound driver is available from: ftp://rah.star-gate.com/pub/guspnp23.tar.gz There was minor bug for sound cards which have ad1848/cs4231 in setting the left or right channel volume which affects mpegtv ;however, the volume setting is not affected . This is not a fatal bug. At any rate the latest version of guspnp has this problem fix . Amancio From owner-freebsd-hackers Sun Nov 9 14:31:08 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id OAA10088 for hackers-outgoing; Sun, 9 Nov 1997 14:31:08 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from hydrogen.nike.efn.org (resnet.uoregon.edu [128.223.170.28]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id OAA10082 for ; Sun, 9 Nov 1997 14:31:05 -0800 (PST) (envelope-from gurney_j@efn.org) Received: (from jmg@localhost) by hydrogen.nike.efn.org (8.8.7/8.8.7) id OAA03349; Sun, 9 Nov 1997 14:29:44 -0800 (PST) Message-ID: <19971109142944.41819@hydrogen.nike.efn.org> Date: Sun, 9 Nov 1997 14:29:44 -0800 From: John-Mark Gurney To: "Jamil J. Weatherbee" Cc: hackers@FreeBSD.ORG Subject: Re: IDT processors? References: <199711092054.WAA17476@shadows.aeon.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.69 In-Reply-To: ; from Jamil J. Weatherbee on Sun, Nov 09, 1997 at 01:50:34PM -0800 Reply-To: John-Mark Gurney Organization: Cu Networking X-Operating-System: FreeBSD 2.2.1-RELEASE i386 X-PGP-Fingerprint: B7 EC EF F8 AE ED A7 31 96 7A 22 B3 D8 56 36 F4 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Jamil J. Weatherbee scribbled this message on Nov 9: > Did anyone ever notice that 80386 backwards in 68308, does that mean that > intel crap is just ass backwards motorola 68000's? > What is the highest 68000 at this time 68400? How fast? the 68k line had numbers of 680[0-4]0... and the fastest clock for the 68040 was 33mhz... the only similarities would be the 86 and 68.. a neighbor of mine (who was responsible for the 486SX/DX split so that he would save his job for another couple years :) ) had this car shade that said: "680x0, Just Say NO." :) -- John-Mark Gurney Modem/FAX: +1 541 683 6954 Cu Networking Live in Peace, destroy Micro$oft, support free software, run FreeBSD From owner-freebsd-hackers Sun Nov 9 14:40:27 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id OAA10715 for hackers-outgoing; Sun, 9 Nov 1997 14:40:27 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id OAA10707 for ; Sun, 9 Nov 1997 14:40:23 -0800 (PST) (envelope-from julian@whistle.com) Received: (from daemon@localhost) by alpo.whistle.com (8.8.5/8.8.5) id OAA25158; Sun, 9 Nov 1997 14:38:56 -0800 (PST) Received: from UNKNOWN(), claiming to be "current1.whistle.com" via SMTP by alpo.whistle.com, id smtpd025154; Sun Nov 9 14:38:50 1997 Date: Sun, 9 Nov 1997 14:36:59 -0800 (PST) From: Julian Elischer To: perlsta@cs.sunyit.edu, hackers@freebsd.org Subject: Re: Lanmanger Hole! (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Here is the response from one of the prime autors of SAMBA.. (he's in the next cube) ---------- Forwarded message ---------- Date: Sun, 9 Nov 1997 12:46:20 -0800 From: Jeremy Allison To: julian@whistle.com Subject: Re: Lanmanger Hole! (fwd) > Could you send me a little 2 prargraph status report > re: this sort of thing,that I can forward to the FreeBSD Lists Julian, please forward this : Jeremy. ---------------------------------------------------------------- Lanman passwords are insecure. There's no getting around this. When designing the Lanman password hash Microsoft made some very poor decisions. They uppercase the password (which drasticly reduces the search time for a brute force search), used DES in ecb mode, and finally didn't use salt. This means that it is very easy to brute force lanman passwords. A further problem is that in the CIFS/SMB protocols password hashes are plaintext equivalent. This means that just knowing the hash is enough for me to make a network drive connection - there is no need to know the plaintext password (this is true for NT passwords also). When used in encrypted password mode Samba treats the lanman and NT passwords like a shadow password file and keeps the file owned by root and with no read access to any other user. Changing to NT security model doesn't buy you anything as NT keeps the Lanman passwords around and by default will accept either the Lanman or NT password, and also using NT passwords only prohibits Windows 95 machines from being used on your network. Samba could easily be changed to only accept NT passwords, but as mentioned above this means *no* DOS, Win3.1, or Win95. Also the NT password hash, although better than the Lanman one, has no salt and is vulnerable to brute force - although much better than the Lanman hash (it is plain MD4 on the unicode password). There is a freeware Lanman/NT password cracker at the L0ft site (can't remember the URL - do a search). Hope this helps, Jeremy Allison Samba Team. From owner-freebsd-hackers Sun Nov 9 14:49:35 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id OAA11299 for hackers-outgoing; Sun, 9 Nov 1997 14:49:35 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from pds-gateway.pdspc.com ([207.170.17.234]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id OAA11288 for ; Sun, 9 Nov 1997 14:49:31 -0800 (PST) (envelope-from khanson@pdspc.com) Received: by pds-gateway.pdspc.com with Internet Mail Service (5.0.1457.3) id ; Sun, 9 Nov 1997 16:49:56 -0600 Message-ID: <91DD7FDA88E4D011BED00000C0DD87E7124C7B@pds-gateway.pdspc.com> From: Kenny Hanson To: "FreeBSD Hackers (E-mail)" Subject: Compiling Apache 1.3b2 Date: Sun, 9 Nov 1997 16:49:54 -0600 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1457.3) Content-Type: text/plain Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk I am having troubles compiling the Apache 1.3b web server. The error is: ld: -lsocks: no match I'm assuming this means that I don't have the socks lib installed (to tell the truth I don't have a clue!) yet I find nothing in the /stand/sysinstall options for it. Could somebody please point me in the right direction? Thanx in advance... Kenny Hanson khanson@pdspc.com From owner-freebsd-hackers Sun Nov 9 15:01:32 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id PAA12255 for hackers-outgoing; Sun, 9 Nov 1997 15:01:32 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from picnic.mat.net (picnic.mat.net [206.246.122.117]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id PAA12233 for ; Sun, 9 Nov 1997 15:01:19 -0800 (PST) (envelope-from chuckr@glue.umd.edu) Received: from localhost (chuckr@localhost) by picnic.mat.net (8.8.7/8.8.5) with SMTP id QAA28697; Sun, 9 Nov 1997 16:56:31 -0500 (EST) X-Authentication-Warning: picnic.mat.net: chuckr owned process doing -bs Date: Sun, 9 Nov 1997 16:56:30 -0500 (EST) From: Chuck Robey X-Sender: chuckr@picnic.mat.net To: "Jamil J. Weatherbee" cc: mika ruohotie , perlsta@cs.sunyit.edu, freebsd@atipa.com, cmott@srv.net, hackers@FreeBSD.ORG Subject: Re: IDT processors? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Sun, 9 Nov 1997, Jamil J. Weatherbee wrote: > > > Did anyone ever notice that 80386 backwards in 68308, does that mean that > intel crap is just ass backwards motorola 68000's? > What is the highest 68000 at this time 68400? How fast? > > In my opinion, gaining performance by making a hotter more complicated cpu > is no kind of solution. We should of gone multiprocessing back on the > 386's. It is still not a solution either because I dont believe in any > computer that has moving parts when it comes to reliablity. The machine > should be completly sealed from the environment (no dust) and fully > submersible (more or less). In the case of drives that nearly _glow_ with heat, and are inside the case, just how are you going to do that? And, what kind of general purpose computer do you have that doesn't have a disk (your moving parts comment)? Much of the performance improvement that's gone into _all_ modern CPUs is dealing with pipelining, branch prediction, superscaling, all of which are great places for subtle bugs. The inter-instruction dependencies can drive you to drink. Seeing as we never noticed the bug at all, until a few days ago, I can't see it's too much of a killer. I don't like it much, but painting Intel as a big villain because of that is nonsensical. Clearly, if it was that much of a major thing, you'd have noticed it before now. There are better reasons to dump on Intel, that make much more sense than this one. Hell, has anyone realized that the coming Merced processor is going to mean rewriting a _whole lot_ of FreeBSD? I've heard it has a compatibility mode, but (to get the performance out of it) much will change. > > > > On Sun, 9 Nov 1997, mika ruohotie wrote: > > > > ALPHA, get that freebsd port done! > > > > why would anyone want to use anything else than r10000? > > > > now, _that_ would be a port i'd like to see, freebsd on SGI platform. > > > > how likely is it? > > > > > > mickey > > > > > ----------------------------+----------------------------------------------- Chuck Robey | Interests include any kind of voice or data chuckr@glue.umd.edu | communications topic, C programming, and Unix. 213 Lakeside Drive Apt T-1 | Greenbelt, MD 20770 | I run Journey2 and picnic, both FreeBSD (301) 220-2114 | version 3.0 current -- and great FUN! ----------------------------+----------------------------------------------- From owner-freebsd-hackers Sun Nov 9 15:13:15 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id PAA13129 for hackers-outgoing; Sun, 9 Nov 1997 15:13:15 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from implode.root.com (implode.root.com [198.145.90.17]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id PAA13118 for ; Sun, 9 Nov 1997 15:13:09 -0800 (PST) (envelope-from root@implode.root.com) Received: from implode.root.com (localhost [127.0.0.1]) by implode.root.com (8.8.5/8.8.5) with ESMTP id PAA27471; Sun, 9 Nov 1997 15:15:10 -0800 (PST) Message-Id: <199711092315.PAA27471@implode.root.com> To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) cc: hackers@FreeBSD.ORG Subject: Re: How useful is this patch? In-reply-to: Your message of "Sun, 09 Nov 1997 16:24:21 +0100." <19971109162421.IH64390@uriah.heep.sax.de> From: David Greenman Reply-To: dg@root.com Date: Sun, 09 Nov 1997 15:15:10 -0800 Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >As Julian Elischer wrote: > >> if a mount option is specified, then setting the SUID bit >> on a directory specifies similar inheritance with UIDS as we >> presently have with GIDs. > >As long as it's a mount option (defaulting to off), i think i could >live with it. > >> The SUID bits are hereditary to child directories, and >> a file 'given away' in this manner >> 1/ cannot be give n to root (would defeat quotas) >> 2/ has the execute bits stripped off (and suid) > >Problem: you can cause someone else a DoS attack by maliciously >filling his home directory. > >(I didn't review the patch itself, so i explicitly don't comment on >stylistic etc. bugs. Make sure the style adhers to the requirements >of style(9).) You could also create a .rhosts file, allowing anyone to log in as the user. You could also create a variety of other files like .tcshrc if it didn't already exist and the user's shell was tcsh (and similar other login scripts with other shells), or various X resource files if the user might start X apps. The list goes on and on. I think it sounds like a major security hole for just about anyone who enables it. -DG David Greenman Core-team/Principal Architect, The FreeBSD Project From owner-freebsd-hackers Sun Nov 9 15:39:32 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id PAA14794 for hackers-outgoing; Sun, 9 Nov 1997 15:39:32 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from time.cdrom.com (root@time.cdrom.com [204.216.27.226]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id PAA14786 for ; Sun, 9 Nov 1997 15:39:29 -0800 (PST) (envelope-from jkh@time.cdrom.com) Received: from time.cdrom.com (jkh@localhost.cdrom.com [127.0.0.1]) by time.cdrom.com (8.8.7/8.6.9) with ESMTP id PAA11098; Sun, 9 Nov 1997 15:36:43 -0800 (PST) To: mika ruohotie cc: jamil@trojanhorse.ml.org (Jamil J. Weatherbee), perlsta@cs.sunyit.edu, freebsd@atipa.com, cmott@srv.net, hackers@FreeBSD.ORG Subject: Re: IDT processors? In-reply-to: Your message of "Sun, 09 Nov 1997 22:54:43 +0200." <199711092054.WAA17476@shadows.aeon.net> Date: Sun, 09 Nov 1997 15:36:43 -0800 Message-ID: <11094.879118603@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > why would anyone want to use anything else than r10000? > > now, _that_ would be a port i'd like to see, freebsd on SGI platform. > > how likely is it? Depends on how fast you're able to do the port, I guess! :) Seriously, simply calling for a port to a new platform is a waste of time since we've been asked, at one point or another, to port FreeBSD to just about every architecture on the market today and we've even been offered money to port to architectures like the UltraSPARC. Finding the people who have both the ability and the time to do this, however, is a lot harder and I wish that people would simply leave us alone on this topic unless they're also willing to do the work of porting FreeBSD to a new architecture *and* be willing maintain it in the tree for some reasonable number of years afterwards. Otherwise, don't waste our time in a frivolous discussion of something which can't and won't happen without such volunteer labor being available. Jordan From owner-freebsd-hackers Sun Nov 9 15:53:12 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id PAA15659 for hackers-outgoing; Sun, 9 Nov 1997 15:53:12 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from DNS.Lamb.net (root@DNS.Lamb.net [207.90.181.1]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id PAA15645 for ; Sun, 9 Nov 1997 15:53:07 -0800 (PST) (envelope-from ulf@Gatekeeper.Alameda.net) Received: (from uucp@localhost) by DNS.Lamb.net (8.8.6/8.8.6) id PAA04345; Sun, 9 Nov 1997 15:53:08 -0800 (PST) Received: from gatekeeper.Alameda.net(207.90.181.2) via SMTP by DNS.Lamb.net, id smtpd004343; Sun Nov 9 15:53:07 1997 Received: (from ulf@localhost) by Gatekeeper.Alameda.net (8.8.6/8.7.6) id PAA18024; Sun, 9 Nov 1997 15:53:05 -0800 (PST) From: Ulf Zimmermann Message-Id: <199711092353.PAA18024@Gatekeeper.Alameda.net> Subject: Re: IDT processors? In-Reply-To: <11198.879119463@time.cdrom.com> from "Jordan K. Hubbard" at "Nov 9, 97 03:51:03 pm" To: jkh@time.cdrom.com (Jordan K. Hubbard) Date: Sun, 9 Nov 1997 15:53:04 -0800 (PST) Cc: ulf@Alameda.net, bsdhack@shadows.aeon.net, jamil@trojanhorse.ml.org, perlsta@cs.sunyit.edu, freebsd@atipa.com, cmott@srv.net, hackers@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-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > Then let's start a port. I have an O2 R10K at home. I might be able to > > get some insider information. Considering that people internal have > > done a Linux port (or part of it) as also they have done a NT kernel > > for a Challenge L. > > Now that looks more promising. How much support inside of SGI do you > think you could create for this, Ulf? > > Jordan I will see what I can do. There many changes going on inside of SGI. Have to find the people Warren(?) talked to, etc. Ulf. --------------------------------------------------------------------- Ulf Zimmermann, 1525 Pacific Ave., Alameda, CA-94501, #: 510-769-2936 Alameda Networks, Inc. | http://www.Alameda.net | Fax#: 510-521-5073 From owner-freebsd-hackers Sun Nov 9 15:53:14 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id PAA15667 for hackers-outgoing; Sun, 9 Nov 1997 15:53:14 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from time.cdrom.com (root@time.cdrom.com [204.216.27.226]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id PAA15654 for ; Sun, 9 Nov 1997 15:53:08 -0800 (PST) (envelope-from jkh@time.cdrom.com) Received: from time.cdrom.com (jkh@localhost.cdrom.com [127.0.0.1]) by time.cdrom.com (8.8.7/8.6.9) with ESMTP id PAA11202; Sun, 9 Nov 1997 15:51:03 -0800 (PST) To: Ulf Zimmermann cc: bsdhack@shadows.aeon.net (mika ruohotie), jamil@trojanhorse.ml.org, perlsta@cs.sunyit.edu, freebsd@atipa.com, cmott@srv.net, hackers@FreeBSD.ORG Subject: Re: IDT processors? In-reply-to: Your message of "Sun, 09 Nov 1997 13:55:39 PST." <199711092155.NAA15695@Gatekeeper.Alameda.net> Date: Sun, 09 Nov 1997 15:51:03 -0800 Message-ID: <11198.879119463@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > Then let's start a port. I have an O2 R10K at home. I might be able to > get some insider information. Considering that people internal have > done a Linux port (or part of it) as also they have done a NT kernel > for a Challenge L. Now that looks more promising. How much support inside of SGI do you think you could create for this, Ulf? Jordan From owner-freebsd-hackers Sun Nov 9 15:56:12 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id PAA15897 for hackers-outgoing; Sun, 9 Nov 1997 15:56:12 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from srv.net (snake.srv.net [199.104.81.3]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id PAA15888 for ; Sun, 9 Nov 1997 15:56:08 -0800 (PST) (envelope-from cmott@srv.net) Received: from darkstar.home (tc-if2-33.ida.net [208.141.171.90]) by srv.net (8.8.7/8.8.5) with SMTP id QAA16103; Sun, 9 Nov 1997 16:33:00 -0700 (MST) Date: Sun, 9 Nov 1997 16:32:27 -0700 (MST) From: Charles Mott X-Sender: cmott@darkstar.home To: Chuck Robey cc: "Jamil J. Weatherbee" , mika ruohotie , perlsta@cs.sunyit.edu, freebsd@atipa.com, hackers@FreeBSD.ORG Subject: Re: IDT processors? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Sun, 9 Nov 1997, Chuck Robey wrote: > Much of the performance improvement that's gone into _all_ modern CPUs is > dealing with pipelining, branch prediction, superscaling, all of which are > great places for subtle bugs. The inter-instruction dependencies can > drive you to drink. Seeing as we never noticed the bug at all, until a > few days ago, I can't see it's too much of a killer. I don't like it > much, but painting Intel as a big villain because of that is nonsensical. > Clearly, if it was that much of a major thing, you'd have noticed it > before now. There are better reasons to dump on Intel, that make much > more sense than this one. I think that crackers with shell accounts probably have been able to crash machines without benefit of the Pentium bug for some time now, although this latest exploit is simple and has the danger of becoming a fad. I think this could be bad for Intel, although I agree with you that it is wrong to paint them as the villain here. One can hope that rational thought will prevail. Generally speaking, if one allows users to execute arbitrary object code, there is always a crash risk. I think crackers are much more interested in exploits that either directly or indirectly lead to root access (packet eavesdropping, tcp hijacking, symlink attacks, stack overflow, race conditions, etc.) than simple denial-of-service attacks. Charles Mott From owner-freebsd-hackers Sun Nov 9 16:36:57 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id QAA18375 for hackers-outgoing; Sun, 9 Nov 1997 16:36:57 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from dog.farm.org (gw-hssi-2.farm.org [209.66.103.33]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id QAA18370 for ; Sun, 9 Nov 1997 16:36:50 -0800 (PST) (envelope-from dog.farm.org!dk) Received: (from dk@localhost) by dog.farm.org (8.7.5/dk#3) id QAA27994; Sun, 9 Nov 1997 16:34:00 -0800 (PST) Date: Sun, 9 Nov 1997 16:34:00 -0800 (PST) From: Dmitry Kohmanyuk Message-Id: <199711100034.QAA27994@dog.farm.org> To: tlambert@primenet.com (Terry Lambert) Cc: freebsd-hackers@freebsd.org Subject: Re: x86 gods; advice? Suggestions? Newsgroups: cs-monolit.gated.lists.freebsd.hackers Organization: FARM Computing Association Reply-To: dk+@ua.net X-Newsreader: TIN [version 1.2 PL2] Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In article <199711091032.DAA24687@usr06.primenet.com> you wrote: > It's true that if Sun was *really* interested in making their "standard" > a _standard_, they'd provide source code for the thing. I think it's > because they don't sell any machines with PCI slots yet. The people > who were pushing it were Motorola, and the PowerComputing and Apple > people, who wanted to use commodity cards in their boxes without a > per card driver to set video modes, etc.. NetApp file servers use OpenBoot, and they use PCI hardware with Intel CPU (they now have alpha boxes also, but I haven't got one so I don't know does it use OpenBoot or not.) -- You Know You've Been Hacking Too Long When... ...you are about to feed your cat and you find yourself thinking half-consciously, "is this an AT&T cat or a Berkeley cat?" -- acbul1@penfold.cc.monash.edu.au (Andrew Bulhak) From owner-freebsd-hackers Sun Nov 9 16:39:28 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id QAA18523 for hackers-outgoing; Sun, 9 Nov 1997 16:39:28 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from post.mail.demon.net (post-20.mail.demon.net [194.217.242.27]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id QAA18514 for ; Sun, 9 Nov 1997 16:39:22 -0800 (PST) (envelope-from fhackers@jraynard.demon.co.uk) Received: from jraynard.demon.co.uk ([158.152.42.77]) by post.mail.demon.net id aa2028344; 10 Nov 97 0:08 GMT Received: (from fhackers@localhost) by jraynard.demon.co.uk (8.8.7/8.8.7) id AAA07815; Mon, 10 Nov 1997 00:03:20 GMT (envelope-from fhackers) Message-ID: <19971110000319.31789@jraynard.demon.co.uk> Date: Mon, 10 Nov 1997 00:03:19 +0000 From: James Raynard To: "Brian W. Buchanan" Cc: freebsd-hackers@freebsd.org Subject: Re: GNU Assembler - new version? References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.81e In-Reply-To: ; from Brian W. Buchanan on Sun, Nov 09, 1997 at 11:00:38AM -0800 Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Sun, Nov 09, 1997 at 11:00:38AM -0800, Brian W. Buchanan wrote: > Is it possible we could see a new version of the GNU assembler for -STABLE > anytime soon? Not unless someone finds the time to port it. :-( > The version currently present in the tree seems to date > back to 1992 or 1993, Well, it's version 1.93, released in 1992: jraynard% head -1 /usr/src/gnu/usr.bin/as/ChangeLog Sun Mar 1 17:02:06 1992 K. Richard Pixley (rich@cygnus.com) and committed in 1993: date: 1993/11/03 00:50:46; author: paul; state: Exp; lines: +273 -761 Brought over NetBSD's gas ready for pk's shared libs. (Perhaps NetBSD have a more recent version we could "borrow"?) > and lacks some features of more recent versions. If you're after a different assembler, try nasm (recently added to the ports). It has an aout option, which produces output than can be linked with gcc and run under FreeBSD. It can also produce output for most other i386 OS's, which could be useful. > I've tried grabbing a newer version of gas from the GNU binutils-2.8, but > the configure script doesn't recognize FreeBSD, and I'm not knowledgeable > (or patient) enough to hack it into working. Me neither :-( -- In theory, theory is better than practice. In practice, it isn't. James Raynard, Edinburgh, Scotland. http://www.freebsd.org/~jraynard/ From owner-freebsd-hackers Sun Nov 9 17:25:13 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id RAA20984 for hackers-outgoing; Sun, 9 Nov 1997 17:25:13 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from phoenix.volant.org (phoenix.volant.org [205.179.79.193]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id RAA20975 for ; Sun, 9 Nov 1997 17:25:09 -0800 (PST) (envelope-from patl@phoenix.volant.org) From: patl@phoenix.volant.org Received: from asimov.phoenix.volant.org [205.179.79.65] by phoenix.volant.org with smtp (Exim 1.62 #1) id 0xUibE-0000to-00; Sun, 9 Nov 1997 17:25:08 -0800 Received: from localhost by asimov.phoenix.volant.org (SMI-8.6/SMI-SVR4) id RAA15862; Sun, 9 Nov 1997 17:25:03 -0800 Date: Sun, 9 Nov 1997 17:25:03 -0800 (PST) Reply-To: patl@phoenix.volant.org Subject: Re: IDT processors? To: John-Mark Gurney cc: "Jamil J. Weatherbee" , hackers@freebsd.org In-Reply-To: <19971109142944.41819@hydrogen.nike.efn.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > Jamil J. Weatherbee scribbled this message on Nov 9: > > Did anyone ever notice that 80386 backwards in 68308, does that mean that > > intel crap is just ass backwards motorola 68000's? > > What is the highest 68000 at this time 68400? How fast? > > the 68k line had numbers of 680[0-4]0... and the fastest clock for the > 68040 was 33mhz... the only similarities would be the 86 and 68.. Bzzzttt. Actually, that's 680[0-6]0. The '060 is a superscalar CISC/RISC hybred available in clock speeds up to 50MHz. A 68060/50 is 20..30% faster than a Pentium 90. In tests comparing a P90 running Windows95 against a 68060/50 Amiga, the Amiga often more than doubled the performance of the PC. Much of this is due to the superior design of AmigaDOS/Intuition over Windows95... ` Boot time: Win95 (3 small user-specific programs) 00:53 Amiga (32 user-specific, 57 tasks total) 00:22 Non-stop scrolling through 520Kb of text: Win95 2:18 Amiga 1:48 Similar ratios for various text editing functions (CygnusEditor vs UltraEdit-32 v4.10) Since CygnusEditor doesn't support sort-block, it was necessary to use an AREXX script to cut/save-to-file/sort-temp- file/re-insert. It still beat the PC by 50%. But this is all -way- off topic for a FreeBSD mailing list... -Pat From owner-freebsd-hackers Sun Nov 9 17:28:20 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id RAA21141 for hackers-outgoing; Sun, 9 Nov 1997 17:28:20 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from arg1.demon.co.uk (arg1.demon.co.uk [194.222.34.166]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id RAA21131 for ; Sun, 9 Nov 1997 17:28:16 -0800 (PST) (envelope-from arg@arg1.demon.co.uk) Received: (from arg@localhost) by arg1.demon.co.uk (8.8.5/8.8.5) id BAA22791; Mon, 10 Nov 1997 01:38:10 GMT Date: Mon, 10 Nov 1997 01:38:09 +0000 (GMT) From: Andrew Gordon X-Sender: arg@server.arg.sj.co.uk To: hackers@freebsd.org Subject: Major device allocation, please Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I am currently writing a device driver for the Unitext teletext card (see http://www.pelican.com.au/ ). When finished, the driver will be freely available. The driver (currently called "ttxt") uses one (character) device, with minor device numbers selecting between (up to 4) installed cards. Can I have a major device number allocated, please. From owner-freebsd-hackers Sun Nov 9 17:50:31 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id RAA22695 for hackers-outgoing; Sun, 9 Nov 1997 17:50:31 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id RAA22690 for ; Sun, 9 Nov 1997 17:50:28 -0800 (PST) (envelope-from julian@whistle.com) Received: (from daemon@localhost) by alpo.whistle.com (8.8.5/8.8.5) id RAA28029; Sun, 9 Nov 1997 17:25:07 -0800 (PST) Received: from UNKNOWN(), claiming to be "current1.whistle.com" via SMTP by alpo.whistle.com, id smtpd028027; Sun Nov 9 17:25:01 1997 Date: Sun, 9 Nov 1997 17:23:10 -0800 (PST) From: Julian Elischer To: David Greenman cc: Joerg Wunsch , hackers@FreeBSD.ORG Subject: Re: How useful is this patch? In-Reply-To: <199711092315.PAA27471@implode.root.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk of course, but who said that you have to enable it in you HOME directory? We want to do this in users 'dropbox' directories which is not the same as their ho,e directories. without it there is a never-ending set of complaints about permissions, and the admin spends a lot of time removing files for users. As is indicated.. this is implemented as a mount option (default off) and the directory in question must have the bit set.. it isn't likely to happen by accident. We can keep it as a WHISTLE-ONLY mod here, but I thought I'd see if anyone else wants it.. I'd rather have it in the general sources than proprietary, but That's a decision that's beyond me to make.. (i.e. yours). On Sun, 9 Nov 1997, David Greenman wrote: > >As Julian Elischer wrote: > > > >> if a mount option is specified, then setting the SUID bit > >> on a directory specifies similar inheritance with UIDS as we > >> presently have with GIDs. > > > >As long as it's a mount option (defaulting to off), i think i could > >live with it. > > > >> The SUID bits are hereditary to child directories, and > >> a file 'given away' in this manner > >> 1/ cannot be give n to root (would defeat quotas) > >> 2/ has the execute bits stripped off (and suid) > > > >Problem: you can cause someone else a DoS attack by maliciously > >filling his home directory. It doesn't make any differnce about who can write to the directory. it just changes who OWNS it. the previous behaviour is more of a DOS attack because the user may not be able to DELETE things that are owned by others. The user can now just delete it. > > > >(I didn't review the patch itself, so i explicitly don't comment on > >stylistic etc. bugs. Make sure the style adhers to the requirements > >of style(9).) > > You could also create a .rhosts file, allowing anyone to log in as the > user. You could also create a variety of other files like .tcshrc if it > didn't already exist and the user's shell was tcsh (and similar other login > scripts with other shells), or various X resource files if the user might > start X apps. The list goes on and on. I think it sounds like a major > security hole for just about anyone who enables it. How many of these check the owner now? .rhosts is a security hole anyhow, and in any case I think that doing this on a home directory would be foolish. it doesn't change who CAN write, just who ends up owning the file.. I certainly don't think it should be default anywhere. We want it for the thousands of 'unwitting' FreeBSD users we have, using it through SAMBA and Netatalk. julian > > -DG > > David Greenman > Core-team/Principal Architect, The FreeBSD Project > From owner-freebsd-hackers Sun Nov 9 17:55:41 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id RAA23061 for hackers-outgoing; Sun, 9 Nov 1997 17:55:41 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from nighthawk.iti.gov.sg (nighthawk.iti.gov.sg [192.122.131.51]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id RAA23056 for ; Sun, 9 Nov 1997 17:55:36 -0800 (PST) (envelope-from joerg@iti.gov.sg) Received: (from mailer@localhost) by nighthawk.iti.gov.sg (8.6.11/8.6.11) id KAA07205; Mon, 10 Nov 1997 10:04:00 +0800 Received: from mailhub.iti.gov.sg(192.122.132.132) by nighthawk.iti.gov.sg via smap (V1.3) id sma007199; Mon Nov 10 10:03:39 1997 Received: (from joerg@localhost) by iti.gov.sg (8.8.5/8.8.5) id JAA03020; Mon, 10 Nov 1997 09:46:09 +0800 (SGT) Date: Mon, 10 Nov 1997 09:46:09 +0800 (SGT) From: Joerg Micheel Message-Id: <199711100146.JAA03020@iti.gov.sg> To: njs3@doc.ic.ac.uk Cc: hackers@FreeBSD.ORG Subject: Re: a.out format Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Niall, # Don't suppose anyone knows how the "a.out" format got its name? It means "assembler output file". Usually, linking object files involves multiple input files, so the linker doesn't know which name to assign to the executable. Per default, it's a.out. The a.out format got it's name afterwards to distinguish it from others. It used to be just "the object file format". Anyone else? Joerg From owner-freebsd-hackers Sun Nov 9 18:17:30 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id SAA24240 for hackers-outgoing; Sun, 9 Nov 1997 18:17:30 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from fly.HiWAAY.net (root@fly.HiWAAY.net [208.147.154.56]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id SAA24233 for ; Sun, 9 Nov 1997 18:17:24 -0800 (PST) (envelope-from dkelly@nospam.hiwaay.net) Received: from nospam.hiwaay.net (tnt1-161.HiWAAY.net [208.147.147.161]) by fly.HiWAAY.net (8.8.7/8.8.6) with ESMTP id UAA12619 for ; Sun, 9 Nov 1997 20:17:14 -0600 (CST) Received: from localhost (localhost [127.0.0.1]) by nospam.hiwaay.net (8.8.7/8.8.4) with ESMTP id UAA08730 for ; Sun, 9 Nov 1997 20:07:22 -0600 (CST) Message-Id: <199711100207.UAA08730@nospam.hiwaay.net> X-Mailer: exmh version 2.0zeta 7/24/97 To: hackers@FreeBSD.ORG From: David Kelly Subject: Re: IDT processors? Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 09 Nov 1997 20:07:22 -0600 Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > Jamil J. Weatherbee scribbled this message on Nov 9: > > Did anyone ever notice that 80386 backwards in 68308, does that mean that > > intel crap is just ass backwards motorola 68000's? > > What is the highest 68000 at this time 68400? How fast? > > the 68k line had numbers of 680[0-4]0... and the fastest clock for the > 68040 was 33mhz... the only similarities would be the 86 and 68.. There was/is a 68060. No one remembers it because Apple never shipped one. There were 50 MHz accelerator boards available for Macs, might have only been 68030's. And wasn't the IIfx a 68030 at 40 MHz? And the Quadra 950 was an '040 at 40 MHz? (The Quadra 900 was '040 at 33). In the embedded arena there is the 68302, probably used in most ISDN boxes as its (3) RISC-based communications ports makes it a natural. Also Motorola *said* it was targeted for ISDN use. The 68306 is a super cheap embedded 68k. Another similar part (possibly a 68308 like IDT's number) was a 68k with 8051-like bus interface. Moving up, there is the 68340 with CPU-32 core (think 68020). Another part with most of the interesting stuff rolled onto one chip for embedded use. One of the most interesting features is the BDM port, 10 pin interface for a low cost Background Debugging Mode. At about the top, the 68360 has a CPU-32+ core and (4) communications ports similar to the 68302 but better. A mask pinout option turns one port into an ethernet port. Motorola has been mirroring this product line with their ColdFire series using PowerPC cores. I think the ColdFire CPU's emulate 68k instructions, or there is a 68k binary-to-ColdFire translator. Motorola was recently offering a very interesting ColdFire prototyping kit, a ColdFire MB with 512k DRAM, ethernet, an ISA ethernet card, and software tools for something like $150 or $99.95. I wanted one, but accepted the fact that I don't have time to play with one. -- David Kelly N4HHE, dkelly@hiwaay.net ===================================================================== The human mind ordinarily operates at only ten percent of its capacity -- the rest is overhead for the operating system. From owner-freebsd-hackers Sun Nov 9 19:14:41 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id TAA27360 for hackers-outgoing; Sun, 9 Nov 1997 19:14:41 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from dcarmich.pr.mcs.net (dcarmich.pr.mcs.net [204.95.63.202]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id TAA27353 for ; Sun, 9 Nov 1997 19:14:38 -0800 (PST) (envelope-from dcarmich@dcarmich.pr.mcs.net) Received: (from dcarmich@localhost) by dcarmich.pr.mcs.net (8.8.7/8.8.7) id RAA02551; Sun, 9 Nov 1997 17:54:14 -0600 (CST) (envelope-from dcarmich) From: Douglas Carmichael Message-Id: <199711092354.RAA02551@dcarmich.pr.mcs.net> Subject: Could FreeBSD be a viable platform for large SQL/SAP/etc enterprise applications? To: dg@root.com Date: Sun, 9 Nov 1997 17:54:14 -0600 (CST) Cc: freebsd-hackers@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-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Could FreeBSD be a viable platform to run business applications (e.g. Oracle or other SQL servers, SAP R/3, BAAN, etc.)? From owner-freebsd-hackers Sun Nov 9 19:22:50 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id TAA27867 for hackers-outgoing; Sun, 9 Nov 1997 19:22:50 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from DNS.Lamb.net (root@DNS.Lamb.net [207.90.181.1]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id TAA27862 for ; Sun, 9 Nov 1997 19:22:46 -0800 (PST) (envelope-from ulf@Gatekeeper.Alameda.net) Received: (from uucp@localhost) by DNS.Lamb.net (8.8.6/8.8.6) id TAA04858; Sun, 9 Nov 1997 19:22:50 -0800 (PST) Received: from gatekeeper.Alameda.net(207.90.181.2) via SMTP by DNS.Lamb.net, id smtpd004856; Sun Nov 9 19:22:41 1997 Received: (from ulf@localhost) by Gatekeeper.Alameda.net (8.8.6/8.7.6) id TAA21822; Sun, 9 Nov 1997 19:22:36 -0800 (PST) From: Ulf Zimmermann Message-Id: <199711100322.TAA21822@Gatekeeper.Alameda.net> Subject: Re: IDT processors? In-Reply-To: <199711100207.UAA08730@nospam.hiwaay.net> from David Kelly at "Nov 9, 97 08:07:22 pm" To: dkelly@hiwaay.net (David Kelly) Date: Sun, 9 Nov 1997 19:22:36 -0800 (PST) Cc: hackers@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-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > Motorola has been mirroring this product line with their ColdFire > series using PowerPC cores. I think the ColdFire CPU's emulate 68k > instructions, or there is a 68k binary-to-ColdFire translator. Motorola > was recently offering a very interesting ColdFire prototyping kit, a > ColdFire MB with 512k DRAM, ethernet, an ISA ethernet card, and > software tools for something like $150 or $99.95. I wanted one, but > accepted the fact that I don't have time to play with one. Do you have a pointer where to find more informations ? Part number ? Thanks, Ulf. --------------------------------------------------------------------- Ulf Zimmermann, 1525 Pacific Ave., Alameda, CA-94501, #: 510-769-2936 Alameda Networks, Inc. | http://www.Alameda.net | Fax#: 510-521-5073 From owner-freebsd-hackers Sun Nov 9 19:24:02 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id TAA27977 for hackers-outgoing; Sun, 9 Nov 1997 19:24:02 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from vinyl.quickweb.com (vinyl.quickweb.com [209.112.4.14]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id TAA27963 for ; Sun, 9 Nov 1997 19:23:55 -0800 (PST) (envelope-from mark@quickweb.com) Received: (from mark@localhost) by vinyl.quickweb.com (8.8.7/8.6.12) id WAA11880; Sun, 9 Nov 1997 22:24:40 -0500 (EST) Message-ID: <19971109222439.12758@vmunix.com> Date: Sun, 9 Nov 1997 22:24:39 -0500 From: Mark Mayo To: Ulf Zimmermann Cc: hackers@freebsd.org Subject: Re: IDT processors? References: <199711092054.WAA17476@shadows.aeon.net> <199711092155.NAA15695@Gatekeeper.Alameda.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.85e In-Reply-To: <199711092155.NAA15695@Gatekeeper.Alameda.net>; from Ulf Zimmermann on Sun, Nov 09, 1997 at 01:55:39PM -0800 X-Operating-System: FreeBSD 2.2.5-STABLE i386 Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Sun, Nov 09, 1997 at 01:55:39PM -0800, Ulf Zimmermann wrote: > > > ALPHA, get that freebsd port done! > > > > why would anyone want to use anything else than r10000? > > > > now, _that_ would be a port i'd like to see, freebsd on SGI platform. > > > > how likely is it? > > > > > > mickey > > Then let's start a port. I have an O2 R10K at home. I might be able to > get some insider information. Considering that people internal have > done a Linux port (or part of it) as also they have done a NT kernel > for a Challenge L. > > On the other side I am looking at a project involving a Mips R4300i, > a SCSI controller and several EIDE controller ;-) Isn't the R4300i the processor used in the Nintendo N64? Now that would be something! Personally, I'd love to help with a port like this -- the problem of course would be getting information from Nintendo.. I suspect the rest of the R4300 would be well documented, at least superficially the entire MIPS lineup seems to be fairly "open" and documented. -Mark > > Ulf. > > --------------------------------------------------------------------- > Ulf Zimmermann, 1525 Pacific Ave., Alameda, CA-94501, #: 510-769-2936 > Alameda Networks, Inc. | http://www.Alameda.net | Fax#: 510-521-5073 -- ------------------------------------------------------------------------ Mark Mayo mark@vmunix.com RingZero Comp. http://www.vmunix.com/mark finger mark@vmunix.com for my PGP key and GCS code ------------------------------------------------------------------------ Win95/NT - 32 bit extensions and a graphical shell for a 16 bit patch to an an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition. -UGU From owner-freebsd-hackers Sun Nov 9 19:27:33 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id TAA28182 for hackers-outgoing; Sun, 9 Nov 1997 19:27:33 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from DNS.Lamb.net (root@DNS.Lamb.net [207.90.181.1]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id TAA28170 for ; Sun, 9 Nov 1997 19:27:27 -0800 (PST) (envelope-from ulf@Gatekeeper.Alameda.net) Received: (from uucp@localhost) by DNS.Lamb.net (8.8.6/8.8.6) id TAA04881; Sun, 9 Nov 1997 19:27:31 -0800 (PST) Received: from gatekeeper.Alameda.net(207.90.181.2) via SMTP by DNS.Lamb.net, id smtpd004877; Sun Nov 9 19:27:20 1997 Received: (from ulf@localhost) by Gatekeeper.Alameda.net (8.8.6/8.7.6) id TAA21900; Sun, 9 Nov 1997 19:27:14 -0800 (PST) From: Ulf Zimmermann Message-Id: <199711100327.TAA21900@Gatekeeper.Alameda.net> Subject: Re: IDT processors? In-Reply-To: <19971109222439.12758@vmunix.com> from Mark Mayo at "Nov 9, 97 10:24:39 pm" To: mark@vmunix.com (Mark Mayo) Date: Sun, 9 Nov 1997 19:27:14 -0800 (PST) Cc: hackers@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-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > On Sun, Nov 09, 1997 at 01:55:39PM -0800, Ulf Zimmermann wrote: > > > > ALPHA, get that freebsd port done! > > > > > > why would anyone want to use anything else than r10000? > > > > > > now, _that_ would be a port i'd like to see, freebsd on SGI platform. > > > > > > how likely is it? > > > > > > > > > mickey > > > > Then let's start a port. I have an O2 R10K at home. I might be able to > > get some insider information. Considering that people internal have > > done a Linux port (or part of it) as also they have done a NT kernel > > for a Challenge L. > > > > On the other side I am looking at a project involving a Mips R4300i, > > a SCSI controller and several EIDE controller ;-) > > Isn't the R4300i the processor used in the Nintendo N64? Now that > would be something! Yes, it is. At 93 Mhz. > > Personally, I'd love to help with a port like this -- the problem > of course would be getting information from Nintendo.. There is some dev kit, but supposely you need a high powered SGI machine, probably because of the GFX. > > I suspect the rest of the R4300 would be well documented, at least > superficially the entire MIPS lineup seems to be fairly "open" > and documented. The R4300 itself is very well documented. 1k quantity pricing is around $35 or less. > > -Mark > > > > > Ulf. > > > > --------------------------------------------------------------------- > > Ulf Zimmermann, 1525 Pacific Ave., Alameda, CA-94501, #: 510-769-2936 > > Alameda Networks, Inc. | http://www.Alameda.net | Fax#: 510-521-5073 > > -- > ------------------------------------------------------------------------ > Mark Mayo mark@vmunix.com > RingZero Comp. http://www.vmunix.com/mark > > finger mark@vmunix.com for my PGP key and GCS code > ------------------------------------------------------------------------ > Win95/NT - 32 bit extensions and a graphical shell for a 16 bit patch to > an an 8 bit operating system originally coded for a 4 bit microprocessor, > written by a 2 bit company that can't stand 1 bit of competition. -UGU > Ulf. --------------------------------------------------------------------- Ulf Zimmermann, 1525 Pacific Ave., Alameda, CA-94501, #: 510-769-2936 Alameda Networks, Inc. | http://www.Alameda.net | Fax#: 510-521-5073 From owner-freebsd-hackers Sun Nov 9 19:35:09 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id TAA28648 for hackers-outgoing; Sun, 9 Nov 1997 19:35:09 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from vinyl.quickweb.com (vinyl.quickweb.com [209.112.4.14]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id TAA28637 for ; Sun, 9 Nov 1997 19:35:01 -0800 (PST) (envelope-from mark@quickweb.com) Received: (from mark@localhost) by vinyl.quickweb.com (8.8.7/8.6.12) id WAA11963; Sun, 9 Nov 1997 22:35:55 -0500 (EST) Message-ID: <19971109223555.49470@vmunix.com> Date: Sun, 9 Nov 1997 22:35:55 -0500 From: Mark Mayo To: Julian Elischer Cc: hackers@freebsd.org Subject: Re: How useful is this patch? References: <199711092315.PAA27471@implode.root.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.85e In-Reply-To: ; from Julian Elischer on Sun, Nov 09, 1997 at 05:23:10PM -0800 X-Operating-System: FreeBSD 2.2.5-STABLE i386 Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Sun, Nov 09, 1997 at 05:23:10PM -0800, Julian Elischer wrote: > of course, > but who said that you have to enable it in you HOME directory? > We want to do this in users 'dropbox' directories > which is not the same as their ho,e directories. > without it there is a never-ending set of complaints about > permissions, and the admin spends a lot of time removing files for users. > As is indicated.. this is implemented as a mount option (default off) > and the directory in question must have the bit set.. > it isn't likely to happen by accident. > We can keep it as a WHISTLE-ONLY mod here, but I thought > I'd see if anyone else wants it.. > I'd rather have it in the general sources than proprietary, > but That's a decision that's beyond me to make.. > (i.e. yours). Personally, I think it would be very useful. It's a situation typical in SMB/Appletalk environments... As long as it's off by default, I don't see a problem. These servers tend to be non-typical Unix boxes anyhow, where users generally don't log in -- they're just using it as a file server. Hell, prevent logins all together - that's what NT basically does (no executable content on the server, just files and printers..). Of course, what we're really looking for here are ACLs.. -Mark > > > On Sun, 9 Nov 1997, David Greenman wrote: > > > >As Julian Elischer wrote: > > > > > >> if a mount option is specified, then setting the SUID bit > > >> on a directory specifies similar inheritance with UIDS as we > > >> presently have with GIDs. > > > > > >As long as it's a mount option (defaulting to off), i think i could > > >live with it. > > > > > >> The SUID bits are hereditary to child directories, and > > >> a file 'given away' in this manner > > >> 1/ cannot be give n to root (would defeat quotas) > > >> 2/ has the execute bits stripped off (and suid) > > > > > >Problem: you can cause someone else a DoS attack by maliciously > > >filling his home directory. > > It doesn't make any differnce about who can write to the directory. > it just changes who OWNS it. > the previous behaviour is more of a DOS attack because > the user may not be able to DELETE things that are owned by others. > > The user can now just delete it. > > > > > > >(I didn't review the patch itself, so i explicitly don't comment on > > >stylistic etc. bugs. Make sure the style adhers to the requirements > > >of style(9).) > > > > You could also create a .rhosts file, allowing anyone to log in as the > > user. You could also create a variety of other files like .tcshrc if it > > didn't already exist and the user's shell was tcsh (and similar other login > > scripts with other shells), or various X resource files if the user might > > start X apps. The list goes on and on. I think it sounds like a major > > security hole for just about anyone who enables it. > How many of these check the owner now? > .rhosts is a security hole anyhow, > and in any case I think that doing this on a home directory would be > foolish. > > it doesn't change who CAN write, just who ends up owning the file.. > I certainly don't think it should be default anywhere. We want it for the > thousands of > 'unwitting' FreeBSD users we have, using it through SAMBA and Netatalk. > > julian > > > > -DG > > > > David Greenman > > Core-team/Principal Architect, The FreeBSD Project > > -- ------------------------------------------------------------------------ Mark Mayo mark@vmunix.com RingZero Comp. http://www.vmunix.com/mark finger mark@vmunix.com for my PGP key and GCS code ------------------------------------------------------------------------ Win95/NT - 32 bit extensions and a graphical shell for a 16 bit patch to an an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition. -UGU From owner-freebsd-hackers Sun Nov 9 19:40:23 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id TAA28999 for hackers-outgoing; Sun, 9 Nov 1997 19:40:23 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from word.smith.net.au (vh1.gsoft.com.au [203.38.152.122]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id TAA28994 for ; Sun, 9 Nov 1997 19:40:17 -0800 (PST) (envelope-from mike@word.smith.net.au) Received: from word.smith.net.au (localhost.gsoft.com.au [127.0.0.1]) by word.smith.net.au (8.8.7/8.8.5) with ESMTP id OAA00719; Mon, 10 Nov 1997 14:06:13 +1030 (CST) Message-Id: <199711100336.OAA00719@word.smith.net.au> X-Mailer: exmh version 2.0zeta 7/24/97 To: Douglas Carmichael cc: freebsd-hackers@freebsd.org Subject: Re: Could FreeBSD be a viable platform for large SQL/SAP/etc enterprise applications? In-reply-to: Your message of "Sun, 09 Nov 1997 17:54:14 MDT." <199711092354.RAA02551@dcarmich.pr.mcs.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 10 Nov 1997 14:06:12 +1030 From: Mike Smith Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > Could FreeBSD be a viable platform to run business applications (e.g. Oracle > or other SQL servers, SAP R/3, BAAN, etc.)? Naturally. The biggest hurdle is getting versions of said applications that will run; there are certainly people running Oracle on FreeBSD, as well as other large SQL servers. If SAP is available for SCO, then there's a reasonable chance it would run OK; dBase 4 was running last time I looked as well. mike From owner-freebsd-hackers Sun Nov 9 19:48:14 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id TAA29390 for hackers-outgoing; Sun, 9 Nov 1997 19:48:14 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from vinyl.quickweb.com (vinyl.quickweb.com [209.112.4.14]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id TAA29382 for ; Sun, 9 Nov 1997 19:48:08 -0800 (PST) (envelope-from mark@quickweb.com) Received: (from mark@localhost) by vinyl.quickweb.com (8.8.7/8.6.12) id WAA12042; Sun, 9 Nov 1997 22:49:00 -0500 (EST) Message-ID: <19971109224900.14074@vmunix.com> Date: Sun, 9 Nov 1997 22:49:00 -0500 From: Mark Mayo To: Ulf Zimmermann Cc: hackers@freebsd.org Subject: Re: IDT processors? References: <19971109222439.12758@vmunix.com> <199711100327.TAA21900@Gatekeeper.Alameda.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.85e In-Reply-To: <199711100327.TAA21900@Gatekeeper.Alameda.net>; from Ulf Zimmermann on Sun, Nov 09, 1997 at 07:27:14PM -0800 X-Operating-System: FreeBSD 2.2.5-STABLE i386 Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Sun, Nov 09, 1997 at 07:27:14PM -0800, Ulf Zimmermann wrote: > > On Sun, Nov 09, 1997 at 01:55:39PM -0800, Ulf Zimmermann wrote: > > > > > ALPHA, get that freebsd port done! > > > > > > > > why would anyone want to use anything else than r10000? > > > > > > > > now, _that_ would be a port i'd like to see, freebsd on SGI platform. > > > > > > > > how likely is it? > > > > > > > > mickey > > > > > > Then let's start a port. I have an O2 R10K at home. I might be able to > > > get some insider information. Considering that people internal have > > > done a Linux port (or part of it) as also they have done a NT kernel > > > for a Challenge L. > > > > > > On the other side I am looking at a project involving a Mips R4300i, > > > a SCSI controller and several EIDE controller ;-) > > > > Isn't the R4300i the processor used in the Nintendo N64? Now that > > would be something! > > Yes, it is. At 93 Mhz. > > There is some dev kit, but supposely you need a high powered SGI machine, > probably because of the GFX. Getting the SGI machine isn't the problem - getting the Kit is.. I've seen the development kit in action at EA Canada, it's just a card that plugs into an O2 or Octane - quite neat. Considering you can get an O2 with the R10000 and Alias/Wavefront bundled for $15k, it's not a bad deal. I tried to get a kit for a project, but it was impossible to convince Nintendo that I should have a kit... It seems that unless you're a multi-million dollar game house, they don't want to hear from you. To be expected, but disapointing non-the-less... It's too bad, since you get OpenGL, sound, 100MHz CPU, 4MB of Rambus RAM (500MB/s IO throughput - drooool), and video hardware for $150. String a couple together and the government will be coming after you requiring a supercomputer license.. :-) -Mark > > Ulf. > > --------------------------------------------------------------------- > Ulf Zimmermann, 1525 Pacific Ave., Alameda, CA-94501, #: 510-769-2936 > Alameda Networks, Inc. | http://www.Alameda.net | Fax#: 510-521-5073 -- ------------------------------------------------------------------------ Mark Mayo mark@vmunix.com RingZero Comp. http://www.vmunix.com/mark finger mark@vmunix.com for my PGP key and GCS code ------------------------------------------------------------------------ Win95/NT - 32 bit extensions and a graphical shell for a 16 bit patch to an an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition. -UGU From owner-freebsd-hackers Sun Nov 9 20:35:31 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id UAA01812 for hackers-outgoing; Sun, 9 Nov 1997 20:35:31 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from time.cdrom.com (root@time.cdrom.com [204.216.27.226]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id UAA01806 for ; Sun, 9 Nov 1997 20:35:29 -0800 (PST) (envelope-from jkh@time.cdrom.com) Received: from time.cdrom.com (jkh@localhost.cdrom.com [127.0.0.1]) by time.cdrom.com (8.8.7/8.6.9) with ESMTP id UAA12633; Sun, 9 Nov 1997 20:35:06 -0800 (PST) To: Andrew Gordon cc: hackers@FreeBSD.ORG Subject: Re: Major device allocation, please In-reply-to: Your message of "Mon, 10 Nov 1997 01:38:09 GMT." Date: Sun, 09 Nov 1997 20:35:06 -0800 Message-ID: <12630.879136506@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Please just use 14 (reserved for local use) until you're ready to commit the driver, at which point we can assign you a more permanant one. Thanks! Jordan > I am currently writing a device driver for the Unitext teletext card > (see http://www.pelican.com.au/ ). When finished, the driver will be > freely available. > > The driver (currently called "ttxt") uses one (character) device, > with minor device numbers selecting between (up to 4) installed cards. > > Can I have a major device number allocated, please. From owner-freebsd-hackers Sun Nov 9 20:39:37 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id UAA02009 for hackers-outgoing; Sun, 9 Nov 1997 20:39:37 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from cam.grad.kiev.ua ([195.5.25.54]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id UAA01980 for ; Sun, 9 Nov 1997 20:39:24 -0800 (PST) (envelope-from Ruslan@Shevchenko.kiev.ua) Received: from Shevchenko.kiev.ua (localhost [127.0.0.1]) by cam.grad.kiev.ua (8.8.7/8.8.5) with ESMTP id HAA10303; Mon, 10 Nov 1997 07:33:41 GMT Message-ID: <3466B8D3.3FC2B89C@Shevchenko.kiev.ua> Date: Mon, 10 Nov 1997 07:33:40 +0000 From: Ruslan Shevchenko X-Mailer: Mozilla 4.03b8 [en] (X11; I; FreeBSD 2.2.5-STABLE i386) MIME-Version: 1.0 To: Douglas Carmichael , freebsd-hackers@freebsd.org Subject: Re: Could FreeBSD be a viable platform for large SQL/SAP/etc enterprise applications? References: <199711092354.RAA02551@dcarmich.pr.mcs.net> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Douglas Carmichael wrote: > Could FreeBSD be a viable platform to run business applications (e.g. Oracle > or other SQL servers, SAP R/3, BAAN, etc.)? Somebody say, that he run Oracle under SCO emulator. but in general, i think, answer is no: --- no support of vendors of Business Application. (so, it bad server for business applications) --- FreeBSD can't run pure Java APPS (so, it'a bad client) I reccomended for Server Sun-Solaris/Alpha-OSF/RS-AIX or SCO, if you have only PC. for clients -- if you love Unix -- then Linux. From owner-freebsd-hackers Sun Nov 9 21:18:07 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id VAA03636 for hackers-outgoing; Sun, 9 Nov 1997 21:18:07 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from dfw-ix14.ix.netcom.com (dfw-ix14.ix.netcom.com [206.214.98.14]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id VAA03631 for ; Sun, 9 Nov 1997 21:18:04 -0800 (PST) (envelope-from wghhicks@ix.netcom.com) Received: (from smap@localhost) by dfw-ix14.ix.netcom.com (8.8.4/8.8.4) id XAA24979; Sun, 9 Nov 1997 23:16:23 -0600 (CST) Received: from atl-ga15-03.ix.netcom.com(204.32.174.99) by dfw-ix14.ix.netcom.com via smap (V1.3) id rma024927; Sun Nov 9 23:15:57 1997 Message-ID: <3466987D.4C14CA3E@ix.netcom.com> Date: Mon, 10 Nov 1997 00:15:41 -0500 From: Jerry Hicks Reply-To: wghhicks@ix.netcom.com Organization: TerraEarth X-Mailer: Mozilla 4.03b8 [en] (X11; I; FreeBSD 2.2.5-STABLE i386) MIME-Version: 1.0 To: Ruslan Shevchenko CC: Douglas Carmichael , freebsd-hackers@FreeBSD.ORG Subject: Re: Could FreeBSD be a viable platform for large SQL/SAP/etc enterprise applications? References: <199711092354.RAA02551@dcarmich.pr.mcs.net> <3466B8D3.3FC2B89C@Shevchenko.kiev.ua> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Ruslan Shevchenko wrote: > --- FreeBSD can't run pure Java APPS > (so, it'a bad client) This simply is not true. Although many do consider Java to be a bad *language*. FreeBSD has been *much* better for us in commercial settings that Linux or SCO. Jerry Hicks jerry_hicks@bigfoot.com From owner-freebsd-hackers Sun Nov 9 21:41:34 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id VAA04737 for hackers-outgoing; Sun, 9 Nov 1997 21:41:34 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from smtp2.xs4all.nl (smtp2.xs4all.nl [194.109.6.52]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id VAA04732 for ; Sun, 9 Nov 1997 21:41:29 -0800 (PST) (envelope-from plm@muon.xs4all.nl) Received: from asterix.xs4all.nl (root@asterix.xs4all.nl [194.109.6.11]) by smtp2.xs4all.nl (8.8.6/XS4ALL) with ESMTP id GAA28616 for ; Mon, 10 Nov 1997 06:41:27 +0100 (CET) Received: from muon.xs4all.nl (uucp@localhost) by asterix.xs4all.nl (8.8.6/8.8.6) with UUCP id GAA12029 for freebsd-hackers@freebsd.org; Mon, 10 Nov 1997 06:30:19 +0100 (MET) Received: (from plm@localhost) by muon.xs4all.nl (8.8.7/8.7.3) id XAA04664; Sun, 9 Nov 1997 23:06:59 +0100 (MET) To: freebsd-hackers@freebsd.org Subject: Re: Newest Pentium bug (fatal) References: <87k9eiyi5d.fsf@totally-fudged-out-message-id> From: Peter Mutsaers Date: 09 Nov 1997 23:06:59 +0100 In-Reply-To: Doug Lo's message of Sat, 08 Nov 1997 11:51:03 +0800 Message-ID: <87k9ehzpq4.fsf@muon.xs4all.nl> Lines: 12 X-Mailer: Gnus v5.5/Emacs 20.2 Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk CPU: Pentium (200.46-MHz 586-class CPU) Origin = "GenuineIntel" Id = 0x544 Stepping=4 Features=0x8001bf Also crashes. How do I get a replacement from Intel? -- /\_/\ ( o.o ) Peter Mutsaers | Abcoude (Utrecht), | Trust me, I know ) ^ ( plm@xs4all.nl | the Netherlands | what I'm doing. From owner-freebsd-hackers Sun Nov 9 21:47:23 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id VAA05021 for hackers-outgoing; Sun, 9 Nov 1997 21:47:23 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from cam.grad.kiev.ua ([195.5.25.54]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id VAA04992; Sun, 9 Nov 1997 21:47:12 -0800 (PST) (envelope-from Ruslan@Shevchenko.kiev.ua) Received: from Shevchenko.kiev.ua (localhost [127.0.0.1]) by cam.grad.kiev.ua (8.8.7/8.8.5) with ESMTP id IAA14077; Mon, 10 Nov 1997 08:41:53 GMT Message-ID: <3466C8CF.DB597F9D@Shevchenko.kiev.ua> Date: Mon, 10 Nov 1997 08:41:51 +0000 From: Ruslan Shevchenko X-Mailer: Mozilla 4.03b8 [en] (X11; I; FreeBSD 2.2.5-STABLE i386) MIME-Version: 1.0 To: wghhicks@ix.netcom.com CC: freebsd-hackers@freebsd.org, freebsd-chat@freebsd.org Subject: Re: Could FreeBSD be a viable platform for large SQL/SAP/etc enterprise applications? References: <199711092354.RAA02551@dcarmich.pr.mcs.net> <3466B8D3.3FC2B89C@Shevchenko.kiev.ua> <3466987D.4C14CA3E@ix.netcom.com> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Jerry Hicks wrote: > Ruslan Shevchenko wrote: > > ? --- FreeBSD can't run pure Java APPS > ? (so, it'a bad client) > > This simply is not true. Although many do consider Java to be a bad > (Hmm --- I must mail you "100% Java compability application", or propose you to run appletviewer or jdb ? ) > *language*. > May be Java is a bad language. (Windows, for example --- bad OS, but I spend most of my time sitting on WindowsNT, becouse Windows have support from commercical vendors, becouse exists rapid development tools, and users sitting on Windows, not becouse it fools, but becouse they wont *to use applications*.) Java iniciative allows all U*IXEX to run application. May be it is bad applications, but they exists. If seriosly, I can spend some my time to java-on-FreeBSD work, if anybody interested, write to me. > FreeBSD has been *much* better for us in commercial settings that Linux > or SCO. > Termins. What mean "commercial settings" In my opinion, FreeBSD is good for: 1. ISP 2. Home use. > Jerry Hicks > jerry_hicks@bigfoot.com P.S. (let's move this topic for freebsd-chat) From owner-freebsd-hackers Sun Nov 9 22:16:22 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id WAA06609 for hackers-outgoing; Sun, 9 Nov 1997 22:16:22 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id WAA06598 for ; Sun, 9 Nov 1997 22:16:18 -0800 (PST) (envelope-from imp@village.org) Received: from pencil-box.village.org [10.0.0.22] by rover.village.org with esmtp (Exim 1.71 #1) id 0xUn8y-000466-00; Sun, 9 Nov 1997 23:16:16 -0700 Received: from pencil-box.village.org (localhost [127.0.0.1]) by pencil-box.village.org (8.8.7/8.8.3) with ESMTP id FAA00969; Mon, 10 Nov 1997 05:19:38 GMT Message-Id: <199711100519.FAA00969@pencil-box.village.org> To: mika ruohotie Subject: Re: IDT processors? Cc: hackers@freebsd.org In-reply-to: Your message of "Sun, 09 Nov 1997 22:54:43 +0200." <199711092054.WAA17476@shadows.aeon.net> References: <199711092054.WAA17476@shadows.aeon.net> Date: Sun, 09 Nov 1997 22:19:36 -0700 From: "M. Warner Losh" Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In message <199711092054.WAA17476@shadows.aeon.net> mika ruohotie writes: : now, _that_ would be a port i'd like to see, freebsd on SGI platform. : how likely is it? I once started a FreeBSD port to R4400 that it is in the arc machine I have. I punted on it due to lack of time. There were also perlininary offers to have someone pay for this port. Finally, the OpenBSD folks are working on an sgi port. I don't think that it is in the tree yet. Warner From owner-freebsd-hackers Sun Nov 9 22:16:24 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id WAA06620 for hackers-outgoing; Sun, 9 Nov 1997 22:16:24 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id WAA06604 for ; Sun, 9 Nov 1997 22:16:20 -0800 (PST) (envelope-from imp@village.org) Received: from pencil-box.village.org [10.0.0.22] by rover.village.org with esmtp (Exim 1.71 #1) id 0xUn8z-000466-00; Sun, 9 Nov 1997 23:16:17 -0700 Received: from pencil-box.village.org (localhost [127.0.0.1]) by pencil-box.village.org (8.8.7/8.8.3) with ESMTP id FAA00981; Mon, 10 Nov 1997 05:23:09 GMT Message-Id: <199711100523.FAA00981@pencil-box.village.org> To: Ulf Zimmermann Subject: Re: IDT processors? Cc: jkh@time.cdrom.com (Jordan K. Hubbard), bsdhack@shadows.aeon.net, jamil@trojanhorse.ml.org, perlsta@cs.sunyit.edu, freebsd@atipa.com, cmott@srv.net, hackers@freebsd.org In-reply-to: Your message of "Sun, 09 Nov 1997 15:53:04 PST." <199711092353.PAA18024@Gatekeeper.Alameda.net> References: <199711092353.PAA18024@Gatekeeper.Alameda.net> Date: Sun, 09 Nov 1997 22:23:08 -0700 From: "M. Warner Losh" Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In message <199711092353.PAA18024@Gatekeeper.Alameda.net> Ulf Zimmermann writes: : I will see what I can do. There many changes going on inside of SGI. : Have to find the people Warren(?) talked to, etc. Hmmm, I tried to find the person I talked to before, and can't seem to find it in my records. Warner From owner-freebsd-hackers Sun Nov 9 22:51:10 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id WAA08127 for hackers-outgoing; Sun, 9 Nov 1997 22:51:10 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from unix.tfs.net (root@unix.tfs.net [199.79.146.60]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id WAA08122 for ; Sun, 9 Nov 1997 22:51:02 -0800 (PST) (envelope-from jbryant@argus.tfs.net) Received: from argus.tfs.net (tc1-p12.tfs.net [139.146.197.12]) by unix.tfs.net (8.8.5/8.8.5) with ESMTP id AAA25608; Mon, 10 Nov 1997 00:49:26 -0600 Received: (from jbryant@localhost) by argus.tfs.net (8.8.7/8.8.5) id AAA07487; Mon, 10 Nov 1997 00:50:42 -0600 (CST) From: Jim Bryant Message-Id: <199711100650.AAA07487@argus.tfs.net> Subject: Re: Newest Pentium bug (fatal) In-Reply-To: <87k9ehzpq4.fsf@muon.xs4all.nl> from Peter Mutsaers at "Nov 9, 97 11:06:59 pm" To: plm@xs4all.nl (Peter Mutsaers) Date: Mon, 10 Nov 1997 00:50:40 -0600 (CST) Cc: freebsd-hackers@freebsd.org Reply-to: jbryant@tfs.net X-Windows: R00LZ!@# MS-Winbl0wz DR00LZ!@# X-Operating-System: FreeBSD 2.2.2-RELEASE #0: Wed Jul 9 01:01:24 CDT 1997 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-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In reply: > CPU: Pentium (200.46-MHz 586-class CPU) > Origin = "GenuineIntel" Id = 0x544 Stepping=4 > Features=0x8001bf > > Also crashes. > > How do I get a replacement from Intel? access to the press... we have to counter the paid ass-covering robert collins is giving for intel in the press... he is claiming to have another instruction sequence that he calls an "invalid opcode" that can crash a pentium in a similar way, and is apparently holding back and telling people not to "stir up the pot" in another recent usenet posting... research proves that the currently discussed bug is NOT an invalid opcode as he claims but in fact is an infinitely useful documented instruction. LOCK CMPXCHG8B EDX:EAX, ECX:EBX ; crash... pp 25-72 to ; 25-73 of intel's arch & prog ; manual for the pentium jim -- All opinions expressed are mine, if you | "I will not be pushed, stamped, think otherwise, then go jump into turbid | briefed, debriefed, indexed, or radioactive waters and yell WAHOO !!! | numbered!" - #1, "The Prisoner" ------------------------------------------------------------------------------ Inet: jbryant@tfs.net AX.25: kc5vdj@wv0t.#neks.ks.usa.noam grid: EM28pw voice: KC5VDJ - 6 & 2 Meters AM/FM/SSB, 70cm FM. http://www.tfs.net/~jbryant ------------------------------------------------------------------------------ HF/6M/2M: IC-706-MkII, 2M: HTX-212, 2M: HTX-202, 70cm: HTX-404, Packet: KPC-3+ From owner-freebsd-hackers Sun Nov 9 22:51:19 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id WAA08147 for hackers-outgoing; Sun, 9 Nov 1997 22:51:19 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from time.cdrom.com (root@time.cdrom.com [204.216.27.226]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id WAA08142 for ; Sun, 9 Nov 1997 22:51:16 -0800 (PST) (envelope-from jkh@time.cdrom.com) Received: from time.cdrom.com (jkh@localhost.cdrom.com [127.0.0.1]) by time.cdrom.com (8.8.7/8.6.9) with ESMTP id WAA13226; Sun, 9 Nov 1997 22:50:53 -0800 (PST) To: Peter Mutsaers cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Newest Pentium bug (fatal) In-reply-to: Your message of "09 Nov 1997 23:06:59 +0100." <87k9ehzpq4.fsf@muon.xs4all.nl> Date: Sun, 09 Nov 1997 22:50:53 -0800 Message-ID: <13222.879144653@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk I don't know, but I'd say it's also time for this thread to die in -hackers. I've read about 30 mails on the topic and I think we're all more than clear now on the fact that Pentiums have a bug, Intel is making some dubious claims about it and nobody knows what their return policy is going to be (ask your Intel salesman or your local computer dealer - they're likely to know as little about such things as we are :-). In any case, this is a generic x86 problem and no longer of *specific* interest to FreeBSD - I'm sure that the comp.arch.x86 newsgroup will have more information. Thanks. Jordan > CPU: Pentium (200.46-MHz 586-class CPU) > Origin = "GenuineIntel" Id = 0x544 Stepping=4 > Features=0x8001bf > > Also crashes. > > How do I get a replacement from Intel? > > -- > /\_/\ > ( o.o ) Peter Mutsaers | Abcoude (Utrecht), | Trust me, I know > ) ^ ( plm@xs4all.nl | the Netherlands | what I'm doing. From owner-freebsd-hackers Sun Nov 9 22:59:30 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id WAA08513 for hackers-outgoing; Sun, 9 Nov 1997 22:59:30 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from labinfo.iet.unipi.it (labinfo.iet.unipi.it [131.114.9.5]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id WAA08504 for ; Sun, 9 Nov 1997 22:59:23 -0800 (PST) (envelope-from luigi@labinfo.iet.unipi.it) Received: from localhost (luigi@localhost) by labinfo.iet.unipi.it (8.6.5/8.6.5) id GAA01204; Mon, 10 Nov 1997 06:49:48 +0100 From: Luigi Rizzo Message-Id: <199711100549.GAA01204@labinfo.iet.unipi.it> Subject: Re: atapi cd problems reading last audio track To: afuchs@totum.plaut.de (alex fuchsstadt) Date: Mon, 10 Nov 1997 06:49:48 +0100 (MET) Cc: hackers@freebsd.org In-Reply-To: from "alex fuchsstadt" at Nov 9, 97 09:09:53 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > Oh, pardon I talked about tracks, maybe in your opinion a track is the > whole title. exactly. I don't have a culture on this so I am merely reusing the names that I see in the documentation or in the "Table of contents" listing produced by cdcontrol... > Acording to mine, a track is only one "line" of information during 360 > degrees of disk spin. well i thought on the CD the significant unit of informatio was the "block" containing roughly 2300 bytes of audio data... Luigi From owner-freebsd-hackers Sun Nov 9 23:21:48 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id XAA09527 for hackers-outgoing; Sun, 9 Nov 1997 23:21:48 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id XAA09517 for ; Sun, 9 Nov 1997 23:21:44 -0800 (PST) (envelope-from j@uriah.heep.sax.de) Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id IAA07671 for hackers@FreeBSD.ORG; Mon, 10 Nov 1997 08:20:55 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.8.7/8.8.5) id IAA03511; Mon, 10 Nov 1997 08:13:53 +0100 (MET) Message-ID: <19971110081352.JL61976@uriah.heep.sax.de> Date: Mon, 10 Nov 1997 08:13:52 +0100 From: j@uriah.heep.sax.de (J Wunsch) To: hackers@FreeBSD.ORG Subject: Re: How useful is this patch? References: <19971109162421.IH64390@uriah.heep.sax.de> <199711092315.PAA27471@implode.root.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: <199711092315.PAA27471@implode.root.com>; from David Greenman on Nov 9, 1997 15:15:10 -0800 Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk As David Greenman wrote: > >Problem: you can cause someone else a DoS attack by maliciously > >filling his home directory. > You could also create a .rhosts file, allowing anyone to log in > as the user. Anybody enabling it on his $HOME must be insane. But i can see some value for it e.g. for a $HOME/kitchensink directory (which should, of course, not be in his $PATH either :). iruserok(3) should check the permissions of $HOME, and ignore an .rhosts iff $HOME is writable by anyone else than the owner. -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-hackers Sun Nov 9 23:22:02 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id XAA09554 for hackers-outgoing; Sun, 9 Nov 1997 23:22:02 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from smtp04.primenet.com (smtp04.primenet.com [206.165.5.85]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id XAA09547 for ; Sun, 9 Nov 1997 23:21:58 -0800 (PST) (envelope-from tlambert@usr06.primenet.com) Received: (from daemon@localhost) by smtp04.primenet.com (8.8.7/8.8.7) id AAA18516; Mon, 10 Nov 1997 00:21:58 -0700 (MST) Received: from usr06.primenet.com(206.165.6.206) via SMTP by smtp04.primenet.com, id smtpd018508; Mon Nov 10 00:21:57 1997 Received: (from tlambert@localhost) by usr06.primenet.com (8.8.5/8.8.5) id AAA09666; Mon, 10 Nov 1997 00:21:56 -0700 (MST) From: Terry Lambert Message-Id: <199711100721.AAA09666@usr06.primenet.com> Subject: Re: Why doesn't /bin/echo use getopt? To: joerg_wunsch@uriah.heep.sax.de Date: Mon, 10 Nov 1997 07:21:56 +0000 (GMT) Cc: freebsd-hackers@FreeBSD.ORG In-Reply-To: <19971109194318.GE14919@uriah.heep.sax.de> from "J Wunsch" at Nov 9, 97 07:43:18 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > It's ugly, but it works, and this is a rare situation anyway. > > Well, rare situation or not, the question is if you wanna truly echo > something the user has entered into a shell script variable, it seems > your only option is to always do it this way. Nobody does, of course, > which means all these scripts are probably vulnerable against input > starting with -n. SysV is worse, since they were `smart' with their > backslashomania (as opposed to BSD inventing printf(1) for this > purpose). It seems to be nearly impossible to echo a string verbatim > in SysV if you don't know what the string is. So don't use "echo"... cat < Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id XAA09606 for hackers-outgoing; Sun, 9 Nov 1997 23:22:23 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id XAA09589 for ; Sun, 9 Nov 1997 23:22:17 -0800 (PST) (envelope-from j@uriah.heep.sax.de) Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id IAA07677 for hackers@FreeBSD.ORG; Mon, 10 Nov 1997 08:21:46 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.8.7/8.8.5) id IAA03520; Mon, 10 Nov 1997 08:14:46 +0100 (MET) Message-ID: <19971110081446.UX03181@uriah.heep.sax.de> Date: Mon, 10 Nov 1997 08:14:46 +0100 From: j@uriah.heep.sax.de (J Wunsch) To: hackers@FreeBSD.ORG Subject: Re: How useful is this patch? References: <19971109162421.IH64390@uriah.heep.sax.de> <199711092202.OAA00530@bubba.whistle.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: <199711092202.OAA00530@bubba.whistle.com>; from Archie Cobbs on Nov 9, 1997 14:02:20 -0800 Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk As Archie Cobbs wrote: > > Problem: you can cause someone else a DoS attack by maliciously > > filling his home directory. > > This attack would require that you have given the other user write > permission to your home directory, at least. ...or somewhere below your home directory. But well, if you don't want this, what's the sense behind it at all? :-) -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-hackers Sun Nov 9 23:23:24 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id XAA09660 for hackers-outgoing; Sun, 9 Nov 1997 23:23:24 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id XAA09653; Sun, 9 Nov 1997 23:23:07 -0800 (PST) (envelope-from bde@zeta.org.au) Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.7/8.6.9) id SAA04061; Mon, 10 Nov 1997 18:19:48 +1100 Date: Mon, 10 Nov 1997 18:19:48 +1100 From: Bruce Evans Message-Id: <199711100719.SAA04061@godzilla.zeta.org.au> To: dg@root.com, itojun@itojun.org Subject: Re: 2.2.5 installation bug on 1gig machines Cc: bugs@FreeBSD.ORG, elh@svic.com, hackers@FreeBSD.ORG, toor@dyson.iquest.net Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >> The problem with this is that the memory is already sized before >>'userconfig' is called (it needs to be that way for various reasons). This >>... > Current userconfig menu in the kernel is very nice (I was surprised > when I saw this for the first time), but I believe it is > good to have some device configuration menu/option/whatever in /boot. > > (on bsdi we can disable devices that way. Also, /boot will look > for the default settings in /etc/boot.default. In this way > the settings can be kept the same over kernel reconfiguration) FreeBSD with `options USERCONFIG_BOOT' can now keep settings in the text file /kernel.config. The file is left in boot loader memory by the boot loader, copied to kernel memory in locore.s and sourced by the UserConfig CLI at UserConfig time. Unfortunately, this has the same problem with memory sizing as interactive UserConfig. It should be easy enough to run at least the CLI part of UserConfig earlier (as early as ddb would be more than sufficient). It mainly needs to avoid using malloc(). It uses malloc() mainly to store changes (dset can't use the active changed values since some changes may be unrelated to configuration). Bruce From owner-freebsd-hackers Sun Nov 9 23:24:29 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id XAA09788 for hackers-outgoing; Sun, 9 Nov 1997 23:24:29 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from smtp03.primenet.com (smtp03.primenet.com [206.165.5.84]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id XAA09775 for ; Sun, 9 Nov 1997 23:24:24 -0800 (PST) (envelope-from tlambert@usr06.primenet.com) Received: (from daemon@localhost) by smtp03.primenet.com (8.8.7/8.8.7) id AAA10657; Mon, 10 Nov 1997 00:24:21 -0700 (MST) Received: from usr06.primenet.com(206.165.6.206) via SMTP by smtp03.primenet.com, id smtpd010654; Mon Nov 10 00:24:17 1997 Received: (from tlambert@localhost) by usr06.primenet.com (8.8.5/8.8.5) id AAA09776; Mon, 10 Nov 1997 00:24:13 -0700 (MST) From: Terry Lambert Message-Id: <199711100724.AAA09776@usr06.primenet.com> Subject: Re: Newest Pentium bug (fatal) To: dec@phoenix.its.rpi.edu (David E. Cross) Date: Mon, 10 Nov 1997 07:24:13 +0000 (GMT) Cc: digital@www2.shoppersnet.com, alk@subtle.east.sun.com, hackers@FreeBSD.ORG In-Reply-To: from "David E. Cross" at Nov 9, 97 02:42:37 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > can't to my knowledge, unless you are going to have your OS's check each > opcode before it is executed (for CS people out there that is > O(really-nasty) ;). You could always use a two processor box and burn one processor to watchdog the other. 8-). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Sun Nov 9 23:37:31 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id XAA10572 for hackers-outgoing; Sun, 9 Nov 1997 23:37:31 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from smtp04.primenet.com (smtp04.primenet.com [206.165.5.85]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id XAA10566 for ; Sun, 9 Nov 1997 23:37:28 -0800 (PST) (envelope-from tlambert@usr06.primenet.com) Received: (from daemon@localhost) by smtp04.primenet.com (8.8.7/8.8.7) id AAA18769; Mon, 10 Nov 1997 00:37:27 -0700 (MST) Received: from usr06.primenet.com(206.165.6.206) via SMTP by smtp04.primenet.com, id smtpd018762; Mon Nov 10 00:37:20 1997 Received: (from tlambert@localhost) by usr06.primenet.com (8.8.5/8.8.5) id AAA10415; Mon, 10 Nov 1997 00:37:17 -0700 (MST) From: Terry Lambert Message-Id: <199711100737.AAA10415@usr06.primenet.com> Subject: Re: Newest Pentium bug (fatal) To: jbryant@tfs.net Date: Mon, 10 Nov 1997 07:37:17 +0000 (GMT) Cc: plm@xs4all.nl, freebsd-hackers@FreeBSD.ORG In-Reply-To: <199711100650.AAA07487@argus.tfs.net> from "Jim Bryant" at Nov 10, 97 00:50:40 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > LOCK CMPXCHG8B EDX:EAX, ECX:EBX ; crash... pp 25-72 to > ; 25-73 of intel's arch & prog > ; manual for the pentium The same manual states that the CMPXCHG8B asserts a "#LOCK" signal, as does the "#LOCK" command. Also some paging situations, and "XCHG". It looks to me like they took the 486 macrocell, and extended it (easiest way to get binary compatability), and "forgot" the new registers when implementing the "#LOCK" assert test. I can verify that using non-extended registers doesn't crash. As someone else noticed, ther emay also be a cache fetch interaction (page fault was another thing referenced by #LOCK). Clearly, it's self-deadlocking trying to assert #LOCK. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Sun Nov 9 23:47:02 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id XAA11080 for hackers-outgoing; Sun, 9 Nov 1997 23:47:02 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from smtp03.primenet.com (smtp03.primenet.com [206.165.5.84]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id XAA11073 for ; Sun, 9 Nov 1997 23:47:00 -0800 (PST) (envelope-from tlambert@usr06.primenet.com) Received: (from daemon@localhost) by smtp03.primenet.com (8.8.7/8.8.7) id AAA11749; Mon, 10 Nov 1997 00:47:00 -0700 (MST) Received: from usr06.primenet.com(206.165.6.206) via SMTP by smtp03.primenet.com, id smtpd011736; Mon Nov 10 00:46:50 1997 Received: (from tlambert@localhost) by usr06.primenet.com (8.8.5/8.8.5) id AAA10744; Mon, 10 Nov 1997 00:46:48 -0700 (MST) From: Terry Lambert Message-Id: <199711100746.AAA10744@usr06.primenet.com> Subject: Re: Could FreeBSD be a viable platform for large SQL/SAP/etc enterprise applications? To: Ruslan@Shevchenko.kiev.ua (Ruslan Shevchenko) Date: Mon, 10 Nov 1997 07:46:48 +0000 (GMT) Cc: dcarmich@mcs.com, freebsd-hackers@FreeBSD.ORG In-Reply-To: <3466B8D3.3FC2B89C@Shevchenko.kiev.ua> from "Ruslan Shevchenko" at Nov 10, 97 07:33:40 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > Could FreeBSD be a viable platform to run business applications (e.g. Oracle > > or other SQL servers, SAP R/3, BAAN, etc.)? > > Somebody say, that he run Oracle under SCO emulator. Back in the 1.5.1 days when the IBCS2 was Sean and Soren's baby instead of an import, with some minor mods to the VM86() call gate (only to support FPU reporting and so on), I was able to run the SVR3 IBCS2 statically linked Lotus 1-2-3 and Sybase. The Sybase ran a copy of the Human Genome database for a genetecist friend who was tracking the relationship between marker genes and physiological morphology (ie: is your left earlobe attached or detached? | | | | \ \ \ \ /| \_ \_/ | | | If the latter, then you have a gene associated with the marker gene associated with a 30% increased risk of coronary heart disease, etc.. In other words, the gene for the physiological morphology is usually close enough to the other that you hinherit both or you inherit neither. Not something you'd want an insurance company noting about you -- seen "Gattaca" yet?). Anyway, Sybase ran well enough that FreeBSD was usable in place of the aging AT&T Starserver it used to run on. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Mon Nov 10 00:10:43 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id AAA12261 for hackers-outgoing; Mon, 10 Nov 1997 00:10:43 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from piggy.mdstud.chalmers.se (root@piggy.mdstud.chalmers.se [129.16.234.10]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id AAA12256 for ; Mon, 10 Nov 1997 00:10:40 -0800 (PST) (envelope-from md6tommy@mdstud.chalmers.se) Received: from link.mdstud.chalmers.se (md6tommy@link.mdstud.chalmers.se [129.16.235.140]) by piggy.mdstud.chalmers.se (8.8.5/8.8.5) with ESMTP id JAA17959; Mon, 10 Nov 1997 09:10:33 +0100 (MET) Received: from localhost (md6tommy@localhost) by link.mdstud.chalmers.se (8.8.5/8.8.5) with SMTP id JAA24787; Mon, 10 Nov 1997 09:10:09 +0100 (MET) X-Authentication-Warning: link.mdstud.chalmers.se: md6tommy owned process doing -bs Date: Mon, 10 Nov 1997 09:10:09 +0100 (MET) From: Tommy Hallgren To: mika ruohotie cc: "Jamil J. Weatherbee" , perlsta@cs.sunyit.edu, freebsd@atipa.com, cmott@srv.net, hackers@FreeBSD.ORG Subject: Re: IDT processors? In-Reply-To: <199711092054.WAA17476@shadows.aeon.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Sun, 9 Nov 1997, mika ruohotie wrote: > > ALPHA, get that freebsd port done! > > why would anyone want to use anything else than r10000? > > now, _that_ would be a port i'd like to see, freebsd on SGI platform. > > how likely is it? It is very likely, especially if you start right now. (What! Did you expect Mr. Someone Else to do the port?) Mvh: Tommy From owner-freebsd-hackers Mon Nov 10 00:11:45 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id AAA12332 for hackers-outgoing; Mon, 10 Nov 1997 00:11:45 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from cynic.portal.ca (root@cynic.portal.ca [204.174.36.7]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id AAA12327 for ; Mon, 10 Nov 1997 00:11:42 -0800 (PST) (envelope-from cjs@portal.ca) Received: from localhost ([[UNIX: localhost]]) by cynic.portal.ca (8.8.5/8.8.5) with SMTP id AAA26367; Mon, 10 Nov 1997 00:11:31 -0800 (PST) X-Authentication-Warning: cynic.portal.ca: cjs owned process doing -bs Date: Mon, 10 Nov 1997 00:11:31 -0800 (PST) From: Curt Sampson To: James Raynard cc: "Brian W. Buchanan" , freebsd-hackers@FreeBSD.ORG Subject: Re: GNU Assembler - new version? In-Reply-To: <19971110000319.31789@jraynard.demon.co.uk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Mon, 10 Nov 1997, James Raynard wrote: > > Is it possible we could see a new version of the GNU assembler for -STABLE > > anytime soon? > > Not unless someone finds the time to port it. :-( > ... > (Perhaps NetBSD have a more recent version we could "borrow"?) Right. The current gas doesn't support i386 BSD a.out shared libs. We've been bemoaning this in the NetBSD world for some time now (having a somewhat greater need for cross-compiling than the FreeBSD folks), and there's a distinct possibility that something's going to be done about it between NetBSD 1.3 and NetBSD 1.4. If any FreeBSD folks want to pitch in, drop me a note any time after December 1st. (I'm far to busy trying to make a 1.3 release for the Alpha until then.) cjs Curt Sampson cjs@portal.ca Info at http://www.portal.ca/ Internet Portal Services, Inc. Through infinite myst, software reverberates Vancouver, BC (604) 257-9400 In code possess'd of invisible folly. From owner-freebsd-hackers Mon Nov 10 00:32:49 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id AAA13548 for hackers-outgoing; Mon, 10 Nov 1997 00:32:49 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from iq.org (proff@profane.iq.org [203.4.184.222]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id AAA13537 for ; Mon, 10 Nov 1997 00:32:44 -0800 (PST) (envelope-from proff@iq.org) Received: (qmail 13510 invoked by uid 110); 10 Nov 1997 08:25:06 -0000 Date: 10 Nov 1997 08:25:06 -0000 Message-ID: <19971110082506.13509.qmail@iq.org> From: Julian Assange To: freebsd-hackers@freebsd.org Subject: real audio Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Does anyone have a Real Audio player for FreeBSD-2.2 that works? The currently distributed RealPlayer from Progressive (both the static and dynamic versions) makes .ram's sound like the Star Spangled Banner at 90 fathoms through a kazoo. -- Prof. Julian Assange |If you want to build a ship, don't drum up people |together to collect wood and don't assign them tasks proff@iq.org |and work, but rather teach them to long for the endless proff@gnu.ai.mit.edu |immensity of the sea. -- Antoine de Saint Exupery From owner-freebsd-hackers Mon Nov 10 00:49:32 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id AAA14264 for hackers-outgoing; Mon, 10 Nov 1997 00:49:32 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from rvc1.informatik.ba-stuttgart.de (rvc1.informatik.ba-stuttgart.de [141.31.112.22]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id AAA14255 for ; Mon, 10 Nov 1997 00:49:21 -0800 (PST) (envelope-from helbig@Informatik.BA-Stuttgart.DE) Received: (from helbig@localhost) by rvc1.informatik.ba-stuttgart.de (8.8.7/8.8.5) id JAA06913; Mon, 10 Nov 1997 09:48:43 +0100 (MET) From: Wolfgang Helbig Message-Id: <199711100848.JAA06913@rvc1.informatik.ba-stuttgart.de> Subject: Re: Newest Pentium bug (fatal) In-Reply-To: <13222.879144653@time.cdrom.com> from "Jordan K. Hubbard" at "Nov 9, 97 10:50:53 pm" To: jkh@time.cdrom.com (Jordan K. Hubbard) Date: Mon, 10 Nov 1997 09:48:42 +0100 (MET) Cc: freebsd-hackers@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL30 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > In any case, this is a generic x86 problem and no longer of *specific* > interest to FreeBSD - I'm sure that the comp.arch.x86 newsgroup will > have more information. > > Thanks. Sorry, but there is one question left bothering me: What is the state of FreeBSD's ALPHA port? Wolfgang From owner-freebsd-hackers Mon Nov 10 01:05:55 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id BAA15173 for hackers-outgoing; Mon, 10 Nov 1997 01:05:55 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from time.cdrom.com (root@time.cdrom.com [204.216.27.226]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id BAA15167 for ; Mon, 10 Nov 1997 01:05:48 -0800 (PST) (envelope-from jkh@time.cdrom.com) Received: from time.cdrom.com (jkh@localhost.cdrom.com [127.0.0.1]) by time.cdrom.com (8.8.7/8.6.9) with ESMTP id BAA13900; Mon, 10 Nov 1997 01:05:04 -0800 (PST) To: Wolfgang Helbig cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Newest Pentium bug (fatal) In-reply-to: Your message of "Mon, 10 Nov 1997 09:48:42 +0100." <199711100848.JAA06913@rvc1.informatik.ba-stuttgart.de> Date: Mon, 10 Nov 1997 01:05:04 -0800 Message-ID: <13897.879152704@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > In any case, this is a generic x86 problem and no longer of *specific* > > interest to FreeBSD - I'm sure that the comp.arch.x86 newsgroup will > > have more information. > > > > Thanks. > > Sorry, but there is one question left bothering me: > What is the state of FreeBSD's ALPHA port? Going nowhere fast. Jordan From owner-freebsd-hackers Mon Nov 10 01:09:01 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id BAA15365 for hackers-outgoing; Mon, 10 Nov 1997 01:09:01 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from time.cdrom.com (root@time.cdrom.com [204.216.27.226]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id BAA15360 for ; Mon, 10 Nov 1997 01:08:55 -0800 (PST) (envelope-from jkh@time.cdrom.com) Received: from time.cdrom.com (jkh@localhost.cdrom.com [127.0.0.1]) by time.cdrom.com (8.8.7/8.6.9) with ESMTP id BAA13920; Mon, 10 Nov 1997 01:07:55 -0800 (PST) To: Julian Assange cc: freebsd-hackers@FreeBSD.ORG Subject: Re: real audio In-reply-to: Your message of "10 Nov 1997 08:25:06 GMT." <19971110082506.13509.qmail@iq.org> Date: Mon, 10 Nov 1997 01:07:55 -0800 Message-ID: <13916.879152875@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk That's odd - I suspect your sound card and/or the audio driver. My AWE32 works just great with RealPlayer 3.0 and I use it all the time (how else would I listen to KMUD, a local "alternative" radio station broadcasting at all of 20 watts in its area and unreachable from here, so we put it on the net using a FreeBSD box and RealServer 5.0 BETA). Jordan P.S. Obligatory plug: http://www.kmud.org > > Does anyone have a Real Audio player for FreeBSD-2.2 that works? The > currently distributed RealPlayer from Progressive (both the static and > dynamic versions) makes .ram's sound like the Star Spangled Banner at > 90 fathoms through a kazoo. > > -- > Prof. Julian Assange |If you want to build a ship, don't drum up people > |together to collect wood and don't assign them tasks > proff@iq.org |and work, but rather teach them to long for the endles s > proff@gnu.ai.mit.edu |immensity of the sea. -- Antoine de Saint Exupery > > > From owner-freebsd-hackers Mon Nov 10 01:11:58 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id BAA15641 for hackers-outgoing; Mon, 10 Nov 1997 01:11:58 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from unix.tfs.net (root@unix.tfs.net [199.79.146.60]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id BAA15617 for ; Mon, 10 Nov 1997 01:11:49 -0800 (PST) (envelope-from jbryant@argus.tfs.net) Received: from argus.tfs.net (node6.tfs.net [207.2.220.6]) by unix.tfs.net (8.8.5/8.8.5) with ESMTP id DAA06602; Mon, 10 Nov 1997 03:10:25 -0600 Received: (from jbryant@localhost) by argus.tfs.net (8.8.7/8.8.5) id DAA07810; Mon, 10 Nov 1997 03:11:41 -0600 (CST) From: Jim Bryant Message-Id: <199711100911.DAA07810@argus.tfs.net> Subject: Re: Newest Pentium bug (fatal) In-Reply-To: <199711100737.AAA10415@usr06.primenet.com> from Terry Lambert at "Nov 10, 97 07:37:17 am" To: tlambert@primenet.com (Terry Lambert) Date: Mon, 10 Nov 1997 03:11:40 -0600 (CST) Cc: freebsd-hackers@freebsd.org Reply-to: jbryant@tfs.net X-Windows: R00LZ!@# MS-Winbl0wz DR00LZ!@# X-Operating-System: FreeBSD 2.2.2-RELEASE #0: Wed Jul 9 01:01:24 CDT 1997 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-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In reply: > > LOCK CMPXCHG8B EDX:EAX, ECX:EBX ; crash... pp 25-72 to > > ; 25-73 of intel's arch & prog > > ; manual for the pentium > > The same manual states that the CMPXCHG8B asserts a "#LOCK" signal, as > does the "#LOCK" command. Also some paging situations, and "XCHG". where do you see this? what page? defintely not in the "Instruction Set" chapter [chapter 25]... p 25-72: "Operation if edx:eax = dest zf <- 1 dest <- ecx:ebx else zf <- 0 edx:eax <- dest" p 25-73: "Notes This instruction can be used with the LOCK prefix. In order to simplify interface to the processor's bus, the destination operand receives a write cycle without regard to the result of the comparison. DEST is written back if the comparison fails, and SRC is written into the destination otherwise. (The processor never produces a locked read without also producing a locked write.)" > It looks to me like they took the 486 macrocell, and extended it (easiest > way to get binary compatability), and "forgot" the new registers when > implementing the "#LOCK" assert test. the 0C8h r/m byte specifies the proper extended regs... > I can verify that using non-extended registers doesn't crash. if the backwards compatable 32-bit instruction CMPXCHG was buggy we would have found out about this a long time ago... intel was obviously betting that things would remain 486 backwards compatable for the market lifetime of the pentium. they had to have tested this very early in the production cycle or late in the tooling process. if i'm right about a coverup, it must have been a good one, so good that they put it into the MMX. > As someone else noticed, ther emay also be a cache fetch interaction > (page fault was another thing referenced by #LOCK). > > Clearly, it's self-deadlocking trying to assert #LOCK. hmmmmmm.... just so we are talking apples <-> apples, i am referencing intel's "Pentium(R) Processor Family Developer's Manual, Volume 3: Archetecture and Programming Manual", ISBN 1-55512-247-7, (c) 1995, order number 241430-004. covering the 1110/133, 1000/120, 815/100, 735/90, and 615/75 cpus. jim -- All opinions expressed are mine, if you | "I will not be pushed, stamped, think otherwise, then go jump into turbid | briefed, debriefed, indexed, or radioactive waters and yell WAHOO !!! | numbered!" - #1, "The Prisoner" ------------------------------------------------------------------------------ Inet: jbryant@tfs.net AX.25: kc5vdj@wv0t.#neks.ks.usa.noam grid: EM28pw voice: KC5VDJ - 6 & 2 Meters AM/FM/SSB, 70cm FM. http://www.tfs.net/~jbryant ------------------------------------------------------------------------------ HF/6M/2M: IC-706-MkII, 2M: HTX-212, 2M: HTX-202, 70cm: HTX-404, Packet: KPC-3+ From owner-freebsd-hackers Mon Nov 10 01:28:18 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id BAA16718 for hackers-outgoing; Mon, 10 Nov 1997 01:28:18 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from unix.tfs.net (root@unix.tfs.net [199.79.146.60]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id BAA16713 for ; Mon, 10 Nov 1997 01:28:14 -0800 (PST) (envelope-from jbryant@argus.tfs.net) Received: from argus.tfs.net (node6.tfs.net [207.2.220.6]) by unix.tfs.net (8.8.5/8.8.5) with ESMTP id DAA07706; Mon, 10 Nov 1997 03:26:51 -0600 Received: (from jbryant@localhost) by argus.tfs.net (8.8.7/8.8.5) id DAA07836; Mon, 10 Nov 1997 03:28:08 -0600 (CST) From: Jim Bryant Message-Id: <199711100928.DAA07836@argus.tfs.net> Subject: Re: Newest Pentium bug (fatal) In-Reply-To: <199711100741.XAA26352@kithrup.com> from Sean Eric Fagan at "Nov 9, 97 11:41:16 pm" To: sef@kithrup.com (Sean Eric Fagan) Date: Mon, 10 Nov 1997 03:28:07 -0600 (CST) Cc: freebsd-hackers@freebsd.org Reply-to: jbryant@tfs.net X-Windows: R00LZ!@# MS-Winbl0wz DR00LZ!@# X-Operating-System: FreeBSD 2.2.2-RELEASE #0: Wed Jul 9 01:01:24 CDT 1997 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-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In reply: > In article <199711100650.AAA07487.kithrup.freebsd.hackers@argus.tfs.net> you write: > >research proves that the currently discussed bug is NOT an invalid > >opcode as he claims but in fact is an infinitely useful documented > >instruction. > > > >LOCK CMPXCHG8B EDX:EAX, ECX:EBX ; crash... pp 25-72 to > > ; 25-73 of intel's arch & prog > > ; manual for the pentium > > LOCK is not a valid prefix for CMPXCHG8. ^^^^^^^^ CMPXCHG8B is the intel designation. RTFM. p 25-73. under the heading "notes", and beginning with the sentance "This instruction can be used with a LOCK prefix." > %eax (and, in fact, any 32-bit register) is not a valid operand for CMPXCHG8. p 25-72: "Description The CMPXCHG8B instruction compares the 64-bit value in EDX:EAX with DEST. EDX contains the high-order 32 bits, and EAX contains the low-order 32 bits of the 64-bit value. If they are equal, the 64-bit value in ECX:EBX is stored into DEST. ECX contains the high-order 32 bits and EBX contains the low-order 32 bits. Otherwise, DEST is loaded into EDX:EAX." the only thing i question here is if i am interpreting the r/m64 byte correctly [0x0C8]. jim -- All opinions expressed are mine, if you | "I will not be pushed, stamped, think otherwise, then go jump into turbid | briefed, debriefed, indexed, or radioactive waters and yell WAHOO !!! | numbered!" - #1, "The Prisoner" ------------------------------------------------------------------------------ Inet: jbryant@tfs.net AX.25: kc5vdj@wv0t.#neks.ks.usa.noam grid: EM28pw voice: KC5VDJ - 6 & 2 Meters AM/FM/SSB, 70cm FM. http://www.tfs.net/~jbryant ------------------------------------------------------------------------------ HF/6M/2M: IC-706-MkII, 2M: HTX-212, 2M: HTX-202, 70cm: HTX-404, Packet: KPC-3+ From owner-freebsd-hackers Mon Nov 10 01:32:00 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id BAA16950 for hackers-outgoing; Mon, 10 Nov 1997 01:32:00 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from unix.tfs.net (root@unix.tfs.net [199.79.146.60]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id BAA16938 for ; Mon, 10 Nov 1997 01:31:56 -0800 (PST) (envelope-from jbryant@argus.tfs.net) Received: from argus.tfs.net (node6.tfs.net [207.2.220.6]) by unix.tfs.net (8.8.5/8.8.5) with ESMTP id DAA08025; Mon, 10 Nov 1997 03:30:34 -0600 Received: (from jbryant@localhost) by argus.tfs.net (8.8.7/8.8.5) id DAA07860; Mon, 10 Nov 1997 03:31:50 -0600 (CST) From: Jim Bryant Message-Id: <199711100931.DAA07860@argus.tfs.net> Subject: Re: real audio In-Reply-To: <19971110082506.13509.qmail@iq.org> from Julian Assange at "Nov 10, 97 08:25:06 am" To: proff@iq.org (Julian Assange) Date: Mon, 10 Nov 1997 03:31:49 -0600 (CST) Cc: freebsd-hackers@freebsd.org Reply-to: jbryant@tfs.net X-Windows: R00LZ!@# MS-Winbl0wz DR00LZ!@# X-Operating-System: FreeBSD 2.2.2-RELEASE #0: Wed Jul 9 01:01:24 CDT 1997 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-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In reply: > Does anyone have a Real Audio player for FreeBSD-2.2 that works? The > currently distributed RealPlayer from Progressive (both the static and > dynamic versions) makes .ram's sound like the Star Spangled Banner at > 90 fathoms through a kazoo. try luigi's new sound drivers, they fix the problem... i don't have the url handy off the top of my head... luigi? jim -- All opinions expressed are mine, if you | "I will not be pushed, stamped, think otherwise, then go jump into turbid | briefed, debriefed, indexed, or radioactive waters and yell WAHOO !!! | numbered!" - #1, "The Prisoner" ------------------------------------------------------------------------------ Inet: jbryant@tfs.net AX.25: kc5vdj@wv0t.#neks.ks.usa.noam grid: EM28pw voice: KC5VDJ - 6 & 2 Meters AM/FM/SSB, 70cm FM. http://www.tfs.net/~jbryant ------------------------------------------------------------------------------ HF/6M/2M: IC-706-MkII, 2M: HTX-212, 2M: HTX-202, 70cm: HTX-404, Packet: KPC-3+ From owner-freebsd-hackers Mon Nov 10 01:33:02 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id BAA17056 for hackers-outgoing; Mon, 10 Nov 1997 01:33:02 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from labinfo.iet.unipi.it (labinfo.iet.unipi.it [131.114.9.5]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id BAA17048 for ; Mon, 10 Nov 1997 01:32:56 -0800 (PST) (envelope-from luigi@labinfo.iet.unipi.it) Received: from localhost (luigi@localhost) by labinfo.iet.unipi.it (8.6.5/8.6.5) id JAA01525; Mon, 10 Nov 1997 09:20:37 +0100 From: Luigi Rizzo Message-Id: <199711100820.JAA01525@labinfo.iet.unipi.it> Subject: Re: real audio To: proff@iq.org (Julian Assange) Date: Mon, 10 Nov 1997 09:20:37 +0100 (MET) Cc: freebsd-hackers@FreeBSD.ORG In-Reply-To: <19971110082506.13509.qmail@iq.org> from "Julian Assange" at Nov 10, 97 08:24:47 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > Does anyone have a Real Audio player for FreeBSD-2.2 that works? The > currently distributed RealPlayer from Progressive (both the static and > dynamic versions) makes .ram's sound like the Star Spangled Banner at > 90 fathoms through a kazoo. hmmm... i am using the raplayer 3.0 (dynamic version) for Freebsd and it works pretty well with my audio driver. I suspect you are really having a sounbd driver problem (e.g. raplayer feeding an 8-bit audio device wit 16-bit samples). Luigi -----------------------------+-------------------------------------- Luigi Rizzo | Dip. di Ingegneria dell'Informazione email: luigi@iet.unipi.it | Universita' di Pisa tel: +39-50-568533 | via Diotisalvi 2, 56126 PISA (Italy) fax: +39-50-568522 | http://www.iet.unipi.it/~luigi/ _____________________________|______________________________________ From owner-freebsd-hackers Mon Nov 10 01:40:09 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id BAA17646 for hackers-outgoing; Mon, 10 Nov 1997 01:40:09 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from rah.star-gate.com (rah.star-gate.com [204.188.121.18]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id BAA17636 for ; Mon, 10 Nov 1997 01:40:05 -0800 (PST) (envelope-from hasty@rah.star-gate.com) Received: from rah.star-gate.com (localhost.v-site.net [127.0.0.1]) by rah.star-gate.com (8.8.7/8.8.5) with ESMTP id BAA14030; Mon, 10 Nov 1997 01:28:03 -0800 (PST) Message-Id: <199711100928.BAA14030@rah.star-gate.com> X-Mailer: exmh version 2.0zeta 7/24/97 To: Julian Assange cc: freebsd-hackers@FreeBSD.ORG Subject: Re: real audio In-reply-to: Your message of "10 Nov 1997 08:25:06 GMT." <19971110082506.13509.qmail@iq.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 10 Nov 1997 01:28:02 -0800 From: Amancio Hasty Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Try using the OSS driver . http://www.4front-tech.com/ossfree/ Or upgrade to 3.0 -current . Regards, Amancio From owner-freebsd-hackers Mon Nov 10 02:00:39 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id CAA18692 for hackers-outgoing; Mon, 10 Nov 1997 02:00:39 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from webfarm1.whistle.com (webfarm1.whistle.com [207.76.204.6]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id CAA18675 for ; Mon, 10 Nov 1997 02:00:34 -0800 (PST) (envelope-from julian@whistle.com) Received: (from smap@localhost) by webfarm1.whistle.com (8.8.5/8.8.5) id CAA18976 for ; Mon, 10 Nov 1997 02:00:33 -0800 (PST) X-Authentication-Warning: webfarm1.whistle.com: smap set sender to using -f Received: from alpo.whistle.com(alpo.isp.whistle.com 207.76.204.38) by webfarm1.whistle.com via smap (V2.0) id xmaa18971; Mon, 10 Nov 97 02:00:14 -0800 Received: (from daemon@localhost) by alpo.whistle.com (8.8.5/8.8.5) id BAA06864; Mon, 10 Nov 1997 01:44:11 -0800 (PST) Received: from UNKNOWN(), claiming to be "current1.whistle.com" via SMTP by alpo.whistle.com, id smtpd006861; Mon Nov 10 01:44:03 1997 Date: Mon, 10 Nov 1997 01:42:12 -0800 (PST) From: Julian Elischer To: Joerg Wunsch cc: hackers@FreeBSD.ORG Subject: Re: How useful is this patch? In-Reply-To: <19971110081446.UX03181@uriah.heep.sax.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Mon, 10 Nov 1997, J Wunsch wrote: > As Archie Cobbs wrote: > > > > Problem: you can cause someone else a DoS attack by maliciously > > > filling his home directory. > > > > This attack would require that you have given the other user write > > permission to your home directory, at least. > > ...or somewhere below your home directory. But well, if you don't > want this, what's the sense behind it at all? :-) > We set up our servers with the home directory elsewhere.. the users can't get to it :) and user never get to execute ANYTHONG (including a shell) in fact I hope to mount that drive -noexec soon. From owner-freebsd-hackers Mon Nov 10 02:00:40 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id CAA18704 for hackers-outgoing; Mon, 10 Nov 1997 02:00:40 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from webfarm1.whistle.com (webfarm1.whistle.com [207.76.204.6]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id CAA18674 for ; Mon, 10 Nov 1997 02:00:34 -0800 (PST) (envelope-from julian@whistle.com) Received: (from smap@localhost) by webfarm1.whistle.com (8.8.5/8.8.5) id CAA18975 for ; Mon, 10 Nov 1997 02:00:33 -0800 (PST) X-Authentication-Warning: webfarm1.whistle.com: smap set sender to using -f Received: from alpo.whistle.com(alpo.isp.whistle.com 207.76.204.38) by webfarm1.whistle.com via smap (V2.0) id xma018971; Mon, 10 Nov 97 02:00:13 -0800 Received: (from daemon@localhost) by alpo.whistle.com (8.8.5/8.8.5) id BAA06816; Mon, 10 Nov 1997 01:41:31 -0800 (PST) Received: from UNKNOWN(), claiming to be "current1.whistle.com" via SMTP by alpo.whistle.com, id smtpd006814; Mon Nov 10 01:41:29 1997 Date: Mon, 10 Nov 1997 01:39:38 -0800 (PST) From: Julian Elischer To: Mark Mayo cc: hackers@freebsd.org Subject: Re: How useful is this patch? In-Reply-To: <19971109223555.49470@vmunix.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > SMB/Appletalk environments... As long as it's off by default, I don't > see a problem. These servers tend to be non-typical Unix boxes anyhow, > where users generally don't log in -- they're just using it as a file > server. Hell, prevent logins all together - that's what NT basically > does (no executable content on the server, just files and printers..). > > Of course, what we're really looking for here are ACLs.. I'm working on that one.. ;-) julian From owner-freebsd-hackers Mon Nov 10 02:05:59 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id CAA19257 for hackers-outgoing; Mon, 10 Nov 1997 02:05:59 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from bugs.us.dell.com (bugs.us.dell.com [143.166.169.147]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id CAA19251 for ; Mon, 10 Nov 1997 02:05:52 -0800 (PST) (envelope-from tony@dell.com) Received: from ant.us.dell.com (ant.us.dell.com [143.166.12.34]) by bugs.us.dell.com (8.6.12/8.6.12) with SMTP id EAA18323; Mon, 10 Nov 1997 04:00:37 -0600 Message-Id: <3.0.3.32.19971110034509.0069e370@bugs.us.dell.com> X-Sender: tony@bugs.us.dell.com X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.3 (32) Date: Mon, 10 Nov 1997 03:45:09 -0600 To: Mike Smith From: Tony Overfield Subject: Re: >64MB Cc: John-Mark Gurney , Chuck Robey , Terry Lambert , jamil@trojanhorse.ml.org, hackers@freebsd.org, Jonathan Mini In-Reply-To: <199711070205.MAA00455@word.smith.net.au> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk At 12:34 PM 11/7/97 +1030, Mike Smith wrote: >The kernel is loaded above 1M, so you would have to be careful to make >sure that your BIOS calls came out of the lowest 64K. That could be >done with a dispatcher in locore.s though. I assume you mean the lowest 640K. But yes, a dispatcher would have to exist down there, with a buffer large enough for your INT 13h calls and etc. >The other reason is that I don't know how to make the change. 8) If I >did, I'd certainly consider it, although vm86 has a few other uses that >argue for using it just out of commonality. Have you seen this? /pub/NetBSD-current/src/sys/arch/i386/bioscall/biostramp.S I don't know if it works, but it looks simple enough. I do realize it offends the sensibilities of some real-mode fearing folks. If you can't trust the BIOS after the kernel is in memory, how can you trust it to load the kernel into memory? While the kernel is still "booting...", the BIOS should be safe enough to call in real-mode. - Tony From owner-freebsd-hackers Mon Nov 10 02:06:51 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id CAA19306 for hackers-outgoing; Mon, 10 Nov 1997 02:06:51 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from bugs.us.dell.com (bugs.us.dell.com [143.166.169.147]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id CAA19298 for ; Mon, 10 Nov 1997 02:06:47 -0800 (PST) (envelope-from tony@dell.com) Received: from ant.us.dell.com (ant.us.dell.com [143.166.12.34]) by bugs.us.dell.com (8.6.12/8.6.12) with SMTP id EAA18346; Mon, 10 Nov 1997 04:01:02 -0600 Message-Id: <3.0.3.32.19971110035812.00701028@bugs.us.dell.com> X-Sender: tony@bugs.us.dell.com X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.3 (32) Date: Mon, 10 Nov 1997 03:58:12 -0600 To: Terry Lambert , mike@smith.net.au (Mike Smith) From: Tony Overfield Subject: Re: x86 gods; advice? Suggestions? Cc: mini@d198-232.uoregon.edu, hackers@FreeBSD.ORG In-Reply-To: <199711091021.DAA24289@usr06.primenet.com> References: <199711080954.UAA00629@word.smith.net.au> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk At 10:21 AM 11/9/97 +0000, Terry Lambert wrote: [Tremendous amounts of nine-fingered vm86 task creation and operational ideas deleted] >This sort of answers Tony Overfield's "3. Something else..." question: >you can get a Task Gate Descriptor in the LDT or GDT or IDT. This means >"Something else..." can be triggered by: Uh no. Let's see if we can follow the thread.... [Here, it's clear that Terry and Tony aren't on the same page. :-( ] In reference to bootloader ideas, and referring to calling the real-mode BIOS calls from the kernel initialization code, Tony asked: > Speaking of vm86(), why not just use real-mode? It's easier and much > better for compatibility while booting. In response, Mike asked (rhetorically, I think) how one could load the kernel into memory without using protected mode at all: >How do you copy the kernel into memory > 1M in real mode? If you could >elaborate on this (and how to *stay* in real mode while running over >1M, ie. so that the kzip pass and subsequent real-mode startup >requirements could be met), I'd be *very*happy* [Here, it's clear that Mike and Tony weren't on the same page. :-( ] Terry's suggestion to load the kernel into memory without using protected mode at all is this: >There are several ways to do this. The main one uses a call that drops >into protected mode, changes a 64k mapping at the top of the 1M >you can get at, and goes back to protected mode. [Here, it's clear that Terry and Mike weren't on the same page. :-( ] Wondered which of the possible "real-mode" only approaches Terry was thinking about, I said: >I can't tell, but I think you're talking about one of these: > >1. ... switching to protected mode, setting larger segment limits > and then switching back to real mode. > >2. ... the real mode trick of using FFFF:xxxx addressing. > >3. Something else. [Here, it's clear that Tony and Terry weren't on the same page. :-( ] So there we are. Terry misunderstood the question asked by Mike who misunderstood the question asked by Tony, who probably asked an ambiguous question to begin with. Sorry. I *never* have this problem with people I already know. Dang this "language" stuff we're forced to use to communicate. ;-/ - Tony From owner-freebsd-hackers Mon Nov 10 02:06:24 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id CAA19281 for hackers-outgoing; Mon, 10 Nov 1997 02:06:24 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from bugs.us.dell.com (bugs.us.dell.com [143.166.169.147]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id CAA19274 for ; Mon, 10 Nov 1997 02:06:15 -0800 (PST) (envelope-from tony@dell.com) Received: from ant.us.dell.com (ant.us.dell.com [143.166.12.34]) by bugs.us.dell.com (8.6.12/8.6.12) with SMTP id EAA18337; Mon, 10 Nov 1997 04:00:59 -0600 Message-Id: <3.0.3.32.19971110035717.00704df0@bugs.us.dell.com> X-Sender: tony@bugs.us.dell.com X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.3 (32) Date: Mon, 10 Nov 1997 03:57:17 -0600 To: Jonathan Mini From: Tony Overfield Subject: Re: >64MB Cc: John-Mark Gurney , Chuck Robey , Mike Smith , Terry Lambert , jamil@trojanhorse.ml.org, hackers@FreeBSD.ORG In-Reply-To: <19971106195834.34457@micron.mini.net> References: <3.0.3.32.19971106150448.006d5438@bugs.us.dell.com> <199711061242.XAA00382@word.smith.net.au> <19971106094616.51849@hydrogen.nike.efn.org> <3.0.3.32.19971106150448.006d5438@bugs.us.dell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk At 07:58 PM 11/6/97 -0800, Jonathan Mini wrote: >Tony Overfield stands accused of saying: >> >yep... I've heard of this (they called it Un-real mode :) )... but >> >basicly you set your registers to a 4gig limit instead of the 64k limit >> >that they have normally... I've bounced your message, Mike, to a friend >> >of mine (Jonathan Mini) who will be able to help with this... Sorry, I didn't say that, but I don't disagree with it. ;-) > Oh. My queue : > > There's nothing Magical about 'Unreal mode' at all. All you do is pop >yourself into protected mode real quick, and then do one of two things : > > 1) set the descriptor limits for all of your registers to the > maximum value (2^32, or apx 4G) and then return to real mode. > > 2) create a vm86 TSS which contains a descriptor with a limit > of > 1M, and a 1:1 page map against the real memory. > > Once you are back into real/vm86 mode (the difference doesn't matter), >you simply address the data in the 'out of bounds' area by using the 32bit >offset and index registers. > There's nothing magical about it, I don't know why everyone acts like it's >black voodoo magic. (This all reminds me of the magic around DOS TSRs in the >really old days and then 'Mode X' (non chain-4 256c VGA modes) Uh, no kidding, me too. ;-) I did say this, however: >> Sorry for this useless diversion. It seems my question was ambiguous and >> that Mike took it the other way. I recommend against using this "unreal" >> mode trick. > > Why? This was a response to a question about the FreeBSD bootloader, and it isn't what I was wanting to talk about, but you did ask, so... First, it's entirely wrong for the application. The bootloader is a use32 protected mode program. It makes transitions to real mode for BIOS calls only. There's simply no need to address extended memory from real mode. Second, to me it seems a little bit silly to pop into protected mode then back to real mode just so you can avoid protected mode. I realize that there still exists some real-mode code that needs quick access to video frame buffers and such, but that's another topic. Third, it doesn't always work. Any time you give up the CPU to another piece of code (ostensibly BIOS code), especially in real mode, there's a chance that that code might take a brief trip into protected mode and when it exits it might reload your descriptors with bonafide real-mode compatible ones. Of course, you can fix them up when necessary, if you know when they are clobbered. Of course, I'm not aware of any BIOS that does this, but other BIOS "hookers" could be there, particularly in the case of the DOS version of the bootloader. I have seen instances where a timer or an asynchronous disk interrupt (yes, in DOS) has occurred that resulted in a "real-mode" task-switch and an interrupt-time reentry into INT 13h. If the INT 13h function were to reload the descriptors before returning, you would lose your big limits at an essentially unpredictable time. (NCACHE.EXE for you die-hard types.) >> >he was quite surprised that we kept flipping between real and protected >> >mode when he first saw the boot blocks... >> >> I wonder why. I don't see anything wrong with flipping into and out of >> protected and real modes. After all, it needs to be done. > > No, it doesn't need to be done, and the boot blocks eat a serious >performance loss doing it. Well, I'll have to strongly disagree here. Last time I measured this, I was able to switch from protected mode to real mode and back well over 100000 times per second (236000 times/sec in my last test). That's without A20 gate toggling, of course. If you include A20 gate toggling, any imagined disadvantage of mode switching disappears entirely into the noise. Sure, it's a lot slower than "mov reallybigpointer, %ebx" but it's not slow enough to make any difference. I simply don't believe 1) that the booloader does enough of these to matter, and 2) that anyone really cares about the performance of code that runs for less than one second per boot (on my systems, at least). On every system I've seen, the bootloader spends most of that second either waiting for I/O, or doing I/O. >> My ambiguous question reworded would say... >> >> Once you are in the kernel startup code and running in protected mode, >> why not simply switch back to real mode for BIOS calls and etc. instead >> of trying to set up a VM86() facility? I think it's easier and much >> better for compatibility while booting. > > There are four reasons : [Four good, irrelevant, and deleted reasons...] Well, I'm fairly familiar with each of these bad things you've mentioned, but it seems that I cannot keep the discussion centered around the original topic. I have never suggested that real-mode be entered for BIOS calls after the kernel has actually take over the VM, the IRQs, or the control of devices. Specifically, I was talking about what happens or could happen during the bootstrap process; the time before, during, and very slightly after the kernel is loaded into memory. In the context of bootloaders, it was suggested that because the bootloader is completely out of space, that some (or even most) of the things that one might like to locate in the bootloader should instead be dragged into the kernel to be performed there. The assumption I made (am I the only one who made this assumption?) is that the code moved to the kernel is run almost immediately after the bootloader jumps to the kernel. This is at least logically similar to it being an extension of the bootloader. After the bootloader loads the kernel into memory, it jumps into it. The part that bothers me is that people want that instant in time to be a magical instant where you cannot call the BIOS in real mode anymore after having done so several thousands of times up to that point. Just because it's now running the "kernel" doesn't mean anything other than a jump (lret, in this case) has actually occurred. I was arguing that there is no reason for things to work differently (i.e. no real need for vm86()), until after the booting process has been completed and the kernel "proper" begins execution. - Tony From owner-freebsd-hackers Mon Nov 10 02:07:18 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id CAA19355 for hackers-outgoing; Mon, 10 Nov 1997 02:07:18 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from bugs.us.dell.com (bugs.us.dell.com [143.166.169.147]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id CAA19342 for ; Mon, 10 Nov 1997 02:07:13 -0800 (PST) (envelope-from tony@dell.com) Received: from ant.us.dell.com (ant.us.dell.com [143.166.12.34]) by bugs.us.dell.com (8.6.12/8.6.12) with SMTP id EAA18343; Mon, 10 Nov 1997 04:01:01 -0600 Message-Id: <3.0.3.32.19971110035805.006cab94@bugs.us.dell.com> X-Sender: tony@bugs.us.dell.com X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.3 (32) Date: Mon, 10 Nov 1997 03:58:05 -0600 To: Terry Lambert From: Tony Overfield Subject: Re: >64MB Cc: mike@smith.net.au, hackers@FreeBSD.ORG In-Reply-To: <199711090753.AAA17086@usr06.primenet.com> References: <3.0.3.32.19971106141214.006d5438@bugs.us.dell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk At 07:53 AM 11/9/97 +0000, Terry Lambert wrote: >3. Something else. > >A) Switch to protected mode. >B) Set up a TSS and call gate. >C) Set up a memory map for real mode, excluding the last 64k in > the 640k->1M window. For it, you leave it unmapped. >D) Set up a data area below the 64k that the code stores what area > of high memory you want to access. >E) "Return" to real mode by calling through the gate. >F) When you need to access a 64k chunk abouve 1M, set which one you > want in the data area, and then access it as if it were in the > 64k region. >G) Take the fault in protected mode. Examine the data region. Map > the desired region in the Real mode last 64k. Return. > >This is not quite trivial, but it's not quite impossible, either. No, it's not impossible to do, it's just useless to do, IMHO, for the job at hand. I don't see any reason to turn the bootloader into a vm86() program that plays games like this just to copy to memory above 1 MB, since it's far easier to just switch modes and copy it directly. >There are several other you can do using suspend/resume instructions and >similar tricks Suspend instruction? I could have sworn I knew them all by heart. If you're referring to SMI mode, that's not an option that's available to you, the BIOS owns that. If your book was discussing that as a way to copy memory around, it must have been an educational example. >(documented in the Van Gilluwe book -- I assume that's >what you were referring to in #1? #1 was the well-known method of setting maximal limits on the descriptors before returning to real mode. No, I don't have that book. - Tony From owner-freebsd-hackers Mon Nov 10 02:07:07 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id CAA19327 for hackers-outgoing; Mon, 10 Nov 1997 02:07:07 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from bugs.us.dell.com (bugs.us.dell.com [143.166.169.147]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id CAA19317 for ; Mon, 10 Nov 1997 02:07:03 -0800 (PST) (envelope-from tony@dell.com) Received: from ant.us.dell.com (ant.us.dell.com [143.166.12.34]) by bugs.us.dell.com (8.6.12/8.6.12) with SMTP id EAA18326; Mon, 10 Nov 1997 04:00:56 -0600 Message-Id: <3.0.3.32.19971110034659.0069e370@bugs.us.dell.com> X-Sender: tony@bugs.us.dell.com X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.3 (32) Date: Mon, 10 Nov 1997 03:46:59 -0600 To: Terry Lambert From: Tony Overfield Subject: Re: >64MB Cc: hackers@FreeBSD.ORG In-Reply-To: <199711070052.RAA19368@usr01.primenet.com> References: <3.0.3.32.19971106150448.006d5438@bugs.us.dell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk At 12:52 AM 11/7/97 +0000, Terry Lambert wrote: >> I think [protected/real-mode instead of vm86 mode] is easier and much >> better for compatibility while booting. > >I don't understand how it's a compatability win. I said this mainly because I think simpler code usually works better. There's also a small chance that you'll run into something that doesn't like vm86() mode. If you're careful enough, this risk isn't worth worrying too much about, after all EMM386 and the others do work ok. Of course, EMM386 and etc., have endured numerous releases to fix this strange bug or that strange bug, that I'm sure nobody expected before it happened. ;-) >Plus there's still the issue of "what INT 13 disk maps to what controller >and target", that's the reason we can't know the BIOS geometry to make >up good fdisk data in the first place... Yes, I know. >Plus we need a VM86() in general in any case, since we may need to call >the BIOS mode setting code for standard PCI/EISA/ISA video cards that >are plugged into non-Intel hardware, etc., because card vendors don't >know how to write data dependencies in a seperate area of their BIOS >so a non-Intel OS could figure out how to program the card without >needing information obtained under non-disclosure. I honestly don't have the time to debate every topic you can think of, interesting though they may be. I entered this discussion by pointing to a problem related to the way in which the kernel reads certain CMOS locations, but it has wandered off into protected-mode-only bootloaders, run-time vm86() BIOS calls, vm86() device I/O port snooping, and something called VM86() that a non-Intel CPU can call that runs x86 video card firmware. To their credit, the non-Intel system designers are taking advantage of the abundance of Intel compatible devices and now you want to complain that the Intel compatible industry should have spent more energy accomodating the other .5% (wild, irresponsible guess) of the market, but they didn't do it because they "don't know how." I don't suppose you can think of any other reason besides that one. - Tony From owner-freebsd-hackers Mon Nov 10 02:10:41 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id CAA19722 for hackers-outgoing; Mon, 10 Nov 1997 02:10:41 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from webfarm1.whistle.com (webfarm1.whistle.com [207.76.204.6]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id CAA19701 for ; Mon, 10 Nov 1997 02:10:34 -0800 (PST) (envelope-from julian@whistle.com) Received: (from smap@localhost) by webfarm1.whistle.com (8.8.5/8.8.5) id CAA19050 for ; Mon, 10 Nov 1997 02:10:33 -0800 (PST) X-Authentication-Warning: webfarm1.whistle.com: smap set sender to using -f Received: from alpo.whistle.com(alpo.isp.whistle.com 207.76.204.38) by webfarm1.whistle.com via smap (V2.0) id xmac19042; Mon, 10 Nov 97 02:10:11 -0800 Received: (from daemon@localhost) by alpo.whistle.com (8.8.5/8.8.5) id BAA07056; Mon, 10 Nov 1997 01:52:21 -0800 (PST) Received: from UNKNOWN(), claiming to be "current1.whistle.com" via SMTP by alpo.whistle.com, id smtpd007051; Mon Nov 10 01:52:16 1997 Date: Mon, 10 Nov 1997 01:50:24 -0800 (PST) From: Julian Elischer To: jbryant@tfs.net cc: Peter Mutsaers , freebsd-hackers@FreeBSD.ORG Subject: Re: Newest Pentium bug (fatal) In-Reply-To: <199711100650.AAA07487@argus.tfs.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Mon, 10 Nov 1997, Jim Bryant wrote: > In reply: > > CPU: Pentium (200.46-MHz 586-class CPU) > > Origin = "GenuineIntel" Id = 0x544 Stepping=4 > > Features=0x8001bf > > > > Also crashes. > > > > How do I get a replacement from Intel? > > access to the press... we have to counter the paid ass-covering > robert collins is giving for intel in the press... > > he is claiming to have another instruction sequence that he calls an > "invalid opcode" that can crash a pentium in a similar way, and is > apparently holding back and telling people not to "stir up the pot" in > another recent usenet posting... > > research proves that the currently discussed bug is NOT an invalid > opcode as he claims but in fact is an infinitely useful documented > instruction. > > LOCK CMPXCHG8B EDX:EAX, ECX:EBX ; crash... pp 25-72 to > ; 25-73 of intel's arch & prog > ; manual for the pentium well EBX is on both sides,, is this useful? > > jim > -- > All opinions expressed are mine, if you | "I will not be pushed, stamped, > think otherwise, then go jump into turbid | briefed, debriefed, indexed, or > radioactive waters and yell WAHOO !!! | numbered!" - #1, "The Prisoner" > ------------------------------------------------------------------------------ > Inet: jbryant@tfs.net AX.25: kc5vdj@wv0t.#neks.ks.usa.noam grid: EM28pw > voice: KC5VDJ - 6 & 2 Meters AM/FM/SSB, 70cm FM. http://www.tfs.net/~jbryant > ------------------------------------------------------------------------------ > HF/6M/2M: IC-706-MkII, 2M: HTX-212, 2M: HTX-202, 70cm: HTX-404, Packet: KPC-3+ > From owner-freebsd-hackers Mon Nov 10 02:26:23 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id CAA20760 for hackers-outgoing; Mon, 10 Nov 1997 02:26:23 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from d198-232.uoregon.edu (d198-232.uoregon.edu [128.223.198.232]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id CAA20753 for ; Mon, 10 Nov 1997 02:26:20 -0800 (PST) (envelope-from mini@d198-232.uoregon.edu) Received: (from mini@localhost) by d198-232.uoregon.edu (8.8.5/8.8.5) id CAA26782; Mon, 10 Nov 1997 02:25:41 -0800 (PST) Message-ID: <19971110022540.34863@micron.mini.net> Date: Mon, 10 Nov 1997 02:25:40 -0800 From: Jonathan Mini To: Tony Overfield Cc: Mike Smith , John-Mark Gurney , Chuck Robey , Terry Lambert , jamil@trojanhorse.ml.org, hackers@freebsd.org Subject: Re: >64MB References: <199711070205.MAA00455@word.smith.net.au> <3.0.3.32.19971110034509.0069e370@bugs.us.dell.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.85e In-Reply-To: <3.0.3.32.19971110034509.0069e370@bugs.us.dell.com>; from Tony Overfield on Mon, Nov 10, 1997 at 03:45:09AM -0600 X-files: The Truth is Out There Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Tony Overfield stands accused of saying: > At 12:34 PM 11/7/97 +1030, Mike Smith wrote: > >The kernel is loaded above 1M, so you would have to be careful to make > >sure that your BIOS calls came out of the lowest 64K. That could be > >done with a dispatcher in locore.s though. > > I assume you mean the lowest 640K. But yes, a dispatcher would have > to exist down there, with a buffer large enough for your INT 13h calls > and etc. THat's not true, the call needs to come from the lower 1087K, or the lower 1024K (1M) if you want to be really nice. (calculate the linear adress for FFFF:FFFF - it's (64K - 1) above 1M) > >The other reason is that I don't know how to make the change. 8) If I > >did, I'd certainly consider it, although vm86 has a few other uses that > >argue for using it just out of commonality. > > Have you seen this? > > /pub/NetBSD-current/src/sys/arch/i386/bioscall/biostramp.S > > I don't know if it works, but it looks simple enough. I do realize it > offends the sensibilities of some real-mode fearing folks. > > If you can't trust the BIOS after the kernel is in memory, how can you > trust it to load the kernel into memory? While the kernel is still > "booting...", the BIOS should be safe enough to call in real-mode. The reason you can't trust the BIOS always is because once FreeBSD touches a device, the BIOS doesn't know it and might assume that the device is in a different state than it really is. The solution to this is to ensure that the BIOS and FreeBSD never touch the same devices. The only real way to ensure this is if FreeBSD doesn't touch devices, or the BIOS doesn't touch devices. -- Jonathan Mini Ingenious Productions Software Development P.O. Box 5693, Eugene, Or. 97405 "A child of five could understand this! Quick -- Fetch me a child of five." From owner-freebsd-hackers Mon Nov 10 02:29:46 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id CAA21066 for hackers-outgoing; Mon, 10 Nov 1997 02:29:46 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from iq.org (proff@profane.iq.org [203.4.184.222]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id CAA21052 for ; Mon, 10 Nov 1997 02:29:41 -0800 (PST) (envelope-from proff@iq.org) From: proff@iq.org Received: (qmail 331 invoked by uid 110); 10 Nov 1997 10:28:36 -0000 Message-ID: <19971110102836.330.qmail@iq.org> Subject: Re: real audio In-Reply-To: <199711100820.JAA01525@labinfo.iet.unipi.it> from Luigi Rizzo at "Nov 10, 97 09:20:37 am" To: luigi@labinfo.iet.unipi.it (Luigi Rizzo) Date: Mon, 10 Nov 1997 21:28:36 +1100 (EST) Cc: proff@iq.org, freebsd-hackers@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL28 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > Does anyone have a Real Audio player for FreeBSD-2.2 that works? The > > currently distributed RealPlayer from Progressive (both the static and > > dynamic versions) makes .ram's sound like the Star Spangled Banner at > > 90 fathoms through a kazoo. > > hmmm... i am using the raplayer 3.0 (dynamic version) for Freebsd and > it works pretty well with my audio driver. I suspect you are really > having a sounbd driver problem (e.g. raplayer feeding an 8-bit audio > device wit 16-bit samples). I am using an 8bit SB pro (which works fine with NAS etc). I would be a little suprised to find that RAP has no support for 8bit output devices. A have a few 16 bit cards, but being PnP they appear totally useless under FreeBSD. Speaking of plugs (Jordon's message) mosey on over to the chomsky audio archive: ftp://sunsite.unc.edu/pub/multimedia/radio4all/radio/chomsky -- Prof. Julian Assange |"Don't worry about people stealing your ideas. If your | Ideas are any good, you'll have to ram them down proff@iq.org | people's throats." -- Stolen quote from Howard Aiken proff@gnu.ai.mit.edu | http://underground.org/book From owner-freebsd-hackers Mon Nov 10 02:59:32 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id CAA22873 for hackers-outgoing; Mon, 10 Nov 1997 02:59:32 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from d198-232.uoregon.edu (d198-232.uoregon.edu [128.223.198.232]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id CAA22867 for ; Mon, 10 Nov 1997 02:59:28 -0800 (PST) (envelope-from mini@d198-232.uoregon.edu) Received: (from mini@localhost) by d198-232.uoregon.edu (8.8.5/8.8.5) id CAA26822; Mon, 10 Nov 1997 02:58:48 -0800 (PST) Message-ID: <19971110025848.49607@micron.mini.net> Date: Mon, 10 Nov 1997 02:58:48 -0800 From: Jonathan Mini To: Tony Overfield Cc: John-Mark Gurney , Chuck Robey , Mike Smith , Terry Lambert , jamil@trojanhorse.ml.org, hackers@FreeBSD.ORG Subject: Re: >64MB References: <3.0.3.32.19971106150448.006d5438@bugs.us.dell.com> <199711061242.XAA00382@word.smith.net.au> <19971106094616.51849@hydrogen.nike.efn.org> <3.0.3.32.19971106150448.006d5438@bugs.us.dell.com> <19971106195834.34457@micron.mini.net> <3.0.3.32.19971110035717.00704df0@bugs.us.dell.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.85e In-Reply-To: <3.0.3.32.19971110035717.00704df0@bugs.us.dell.com>; from Tony Overfield on Mon, Nov 10, 1997 at 03:57:17AM -0600 X-files: The Truth is Out There Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Tony Overfield stands accused of saying: > First, it's entirely wrong for the application. The bootloader is a use32 > protected mode program. It makes transitions to real mode for BIOS calls > only. There's simply no need to address extended memory from real mode. > > Second, to me it seems a little bit silly to pop into protected mode then > back to real mode just so you can avoid protected mode. I realize that > there still exists some real-mode code that needs quick access to video > frame buffers and such, but that's another topic. The boot blocks need to be one _one_ state, and IMO there are only two states possible, and only one of those two is really a good idea. They are : 1) The boot blocks are a part of the boot process, meaning that they should function in real mode (being part of initializing the processor) and the sole function of this code is to load the kernel into memory. (this is bogus, IMO) 2) The boot blocks are a small microkernel who's sole purpose is to load the main kernel (or possible a second micro-kernel which handles config : read three stage boot) into memory and give it control. To do this, it needs to have two contexts : a) a protected context with mappings for the kernel, and b) a vm86 context for talking to the BIOS. The boot blocks shouldn't be constantly hopping from Real Mode to Protected Mode over and over again! This is insane, and the processor (especially on a P/Pro system) will be spending more time jumping in and out of Real Mode than it will spend loading the kernel from disk. > Third, it doesn't always work. Any time you give up the CPU to another > piece of code (ostensibly BIOS code), especially in real mode, there's a > chance that that code might take a brief trip into protected mode and when > it exits it might reload your descriptors with bonafide real-mode > compatible ones. Of course, you can fix them up when necessary, if you > know when they are clobbered. Of course, I'm not aware of any BIOS that > does this, but other BIOS "hookers" could be there, particularly in the > case of the DOS version of the bootloader. The BIOS does _NOT_ get to mess with the processor state once it hands control over to the boot code. The BIOS is no guaranteed to even have a ring 0 run state, and if it did this, it would break most DPMI or EMS servers, most notably being Microsoft's EMM386 and Quarterdeck's QEMM. If the BIOS _did_ try and mess with the machine state it wuold break Windows 95 and most people running DOS. Somehow I doubt someone would break the spec in this way. > I have seen instances where a timer or an asynchronous disk interrupt > (yes, in DOS) has occurred that resulted in a "real-mode" task-switch > and an interrupt-time reentry into INT 13h. If the INT 13h function > were to reload the descriptors before returning, you would lose your > big limits at an essentially unpredictable time. (NCACHE.EXE for you > die-hard types.) Hello, we're not running DOS. We're talking about boot code from the BIOS. Not TSR's or DOS device drivers here. (just us chickens) > I simply don't believe 1) that the booloader does enough of these to > matter, and 2) that anyone really cares about the performance of code > that runs for less than one second per boot (on my systems, at least). > On every system I've seen, the bootloader spends most of that second > either waiting for I/O, or doing I/O. The point isn't really performance, but rather that we should be running in protected mode ASAP. Especially since we don't have a 16bit compiler. > >> My ambiguous question reworded would say... > >> > >> Once you are in the kernel startup code and running in protected mode, > >> why not simply switch back to real mode for BIOS calls and etc. instead > >> of trying to set up a VM86() facility? I think it's easier and much > >> better for compatibility while booting. > > > > There are four reasons : > > [Four good, irrelevant, and deleted reasons...] These reasons _AREN'T_ irrelevent, simply because they are the major reasons for having a PROTECTED mode in the first place. Which makes those reasons solely good and deleted. Yay. > Well, I'm fairly familiar with each of these bad things you've > mentioned, but it seems that I cannot keep the discussion centered > around the original topic. > > I have never suggested that real-mode be entered for BIOS calls after > the kernel has actually take over the VM, the IRQs, or the control of > devices. > > Specifically, I was talking about what happens or could happen during > the bootstrap process; the time before, during, and very slightly after > the kernel is loaded into memory. THe VM86 facility you are talking about will ONLY exist after the kernel has 'taken over' the machine's state. > In the context of bootloaders, it was suggested that because the > bootloader is completely out of space, that some (or even most) of the > things that one might like to locate in the bootloader should instead be > dragged into the kernel to be performed there. The assumption I made > (am I the only one who made this assumption?) is that the code moved to > the kernel is run almost immediately after the bootloader jumps to the > kernel. This is at least logically similar to it being an extension of > the bootloader. > > After the bootloader loads the kernel into memory, it jumps into it. > The part that bothers me is that people want that instant in time to be > a magical instant where you cannot call the BIOS in real mode anymore > after having done so several thousands of times up to that point. Just > because it's now running the "kernel" doesn't mean anything other than > a jump (lret, in this case) has actually occurred. I was arguing that > there is no reason for things to work differently (i.e. no real need > for vm86()), until after the booting process has been completed and the > kernel "proper" begins execution. Several 'magical' things HAVE happened to the machine at this point. One of the most important is that the system has 'assumed' control of the ENTIRE machine at this point in time. All IRQ's all memory mappings, and the status of all devices. (read: probe pass will come soon, if it hasn't already happened) You are saying that after having spent all of the time up to this point setting this situation up, that we should _give_ _up_ control and return it to the BIOS temporarily? This I don't understand. -- Jonathan Mini Ingenious Productions Software Development P.O. Box 5693, Eugene, Or. 97405 "A child of five could understand this! Quick -- Fetch me a child of five." From owner-freebsd-hackers Mon Nov 10 03:31:20 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id DAA24661 for hackers-outgoing; Mon, 10 Nov 1997 03:31:20 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from ns.samara.net (ns.samara.net [195.128.128.1]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id DAA24654 for ; Mon, 10 Nov 1997 03:31:15 -0800 (PST) (envelope-from pm@ns.online.samara.ru) Received: from ns.online.samara.ru ([195.128.128.206]) by ns.samara.net (8.7.5/8.7.3) with ESMTP id PAA08311 for ; Mon, 10 Nov 1997 15:49:41 +0400 (KSK) Received: by ns.online.samara.ru id PAA11674; (8.8.5/vak/1.9) Mon, 10 Nov 1997 15:18:26 GMT To: freebsd-hackers@freebsd.org Message-ID: Organization: Cronyx Ltd. From: "Postmaster" Date: Mon, 10 Nov 97 15:18:26 +0000 X-Mailer: BML [UNIX Beauty Mail v.1.39] Subject: [?] login.conf Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I want limited user access to my computer I try create /etc/login.conf whith contents user-name: times.deny 1400-1500 and nothing. User user-name can logon in this period. Why ? From owner-freebsd-hackers Mon Nov 10 03:36:02 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id DAA25052 for hackers-outgoing; Mon, 10 Nov 1997 03:36:02 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from gatekeeper.tsc.tdk.com (root@gatekeeper.tsc.tdk.com [207.113.159.21]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id DAA25035 for ; Mon, 10 Nov 1997 03:35:57 -0800 (PST) (envelope-from gdonl@tsc.tdk.com) Received: from sunrise.gv.tsc.tdk.com (root@sunrise.gv.tsc.tdk.com [192.168.241.191]) by gatekeeper.tsc.tdk.com (8.8.4/8.8.4) with ESMTP id DAA20353; Mon, 10 Nov 1997 03:35:52 -0800 (PST) Received: from salsa.gv.tsc.tdk.com (salsa.gv.tsc.tdk.com [192.168.241.194]) by sunrise.gv.tsc.tdk.com (8.8.5/8.8.5) with ESMTP id DAA14782; Mon, 10 Nov 1997 03:35:51 -0800 (PST) Received: (from gdonl@localhost) by salsa.gv.tsc.tdk.com (8.8.5/8.8.5) id DAA25891; Mon, 10 Nov 1997 03:35:50 -0800 (PST) From: Don Lewis Message-Id: <199711101135.DAA25891@salsa.gv.tsc.tdk.com> Date: Mon, 10 Nov 1997 03:35:50 -0800 In-Reply-To: Terry Lambert "Re: x86 gods; advice? Suggestions?" (Nov 9, 10:32am) X-Mailer: Mail User's Shell (7.2.6 alpha(3) 7/19/95) To: Terry Lambert Subject: Re: x86 gods; advice? Suggestions? Cc: hackers@FreeBSD.ORG Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Nov 9, 10:32am, Terry Lambert wrote: } Subject: Re: x86 gods; advice? Suggestions? } I think it's } because they [Sun] don't sell any machines with PCI slots yet. Yes they do. There's the Ultra 30 workstation and the Ultra Enterprise 150 and 450 servers. They also sell ATX format UltraSPARC motherboards. From owner-freebsd-hackers Mon Nov 10 03:39:48 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id DAA25309 for hackers-outgoing; Mon, 10 Nov 1997 03:39:48 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from labinfo.iet.unipi.it (labinfo.iet.unipi.it [131.114.9.5]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id DAA25246 for ; Mon, 10 Nov 1997 03:38:56 -0800 (PST) (envelope-from luigi@labinfo.iet.unipi.it) Received: from localhost (luigi@localhost) by labinfo.iet.unipi.it (8.6.5/8.6.5) id LAA01718; Mon, 10 Nov 1997 11:28:55 +0100 From: Luigi Rizzo Message-Id: <199711101028.LAA01718@labinfo.iet.unipi.it> Subject: Re: real audio To: proff@iq.org Date: Mon, 10 Nov 1997 11:28:54 +0100 (MET) Cc: freebsd-hackers@FreeBSD.ORG In-Reply-To: <19971110102836.330.qmail@iq.org> from "proff@iq.org" at Nov 10, 97 09:28:17 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > I am using an 8bit SB pro (which works fine with NAS etc). I would > be a little suprised to find that RAP has no support for 8bit output > devices. > > A have a few 16 bit cards, but being PnP they appear totally useless > under FreeBSD. At http://www.iet.unipi.it/~luigi/FreeBSD.html you can find PnP support and the new audio driver which works well with many new PnP 16-bit cards and many many apps. Cheers Luigi -----------------------------+-------------------------------------- Luigi Rizzo | Dip. di Ingegneria dell'Informazione email: luigi@iet.unipi.it | Universita' di Pisa tel: +39-50-568533 | via Diotisalvi 2, 56126 PISA (Italy) fax: +39-50-568522 | http://www.iet.unipi.it/~luigi/ _____________________________|______________________________________ From owner-freebsd-hackers Mon Nov 10 03:41:57 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id DAA25522 for hackers-outgoing; Mon, 10 Nov 1997 03:41:57 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from freya.circle.net (freya.circle.net [209.95.95.2] (may be forged)) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id DAA25442; Mon, 10 Nov 1997 03:41:33 -0800 (PST) (envelope-from team-freebsd@circle.net) Received: by FREYA with Internet Mail Service (5.0.1457.3) id ; Mon, 10 Nov 1997 06:42:23 -0500 Message-ID: <8188AD2EBC3CD111B7A30060082F32A401C5C7@FREYA> From: Team FreeBSD RC5-64 Effort To: "'freebsd-announce@freebsd.org'" , "'freebsd-chat@freebsd.org'" , "'freebsd-questions@freebsd.org'" , "'freebsd-hackers@freebsd.org'" Subject: Team FreeBSD RC5-64 Secret Key Challenge Date: Mon, 10 Nov 1997 06:42:21 -0500 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1457.3) Content-Type: text/plain Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Calling all FreeBSD supporters everywhere! Team FreeBSD is a distributed effort by FreeBSD supporters to crack the RC5-64 encryption (RSA Secret Key Challenge). This effort is coordinated by distributed.net using their RC5-64 "Bovine" client programs. These programs use ONLY idle time on your machine, affecting production use not at all. There are versions of the client available for FreeBSD as well as most other platforms. To find out more about Team FreeBSD, visit: http://www.circle.net/team-freebsd To find out more about the RC5-64 effort, visit: http://www.distributed.net To see the latest rankings of Team FreeBSD, visit: http://rc5stats.distributed.net/tmsummary.idc?TM=988 To flame me for crossposting this announcement, mail to: team-freebsd@circle.net - - - - - - If Team FreeBSD cracks the code, we plan on donating prize winnings to the FreeBSD development effort. So your CPU idle time could mean real cash $$ for FreeBSD. As of this posting, Team FreeBSD is now ranked #196 out of thousands and climbing fast! From owner-freebsd-hackers Mon Nov 10 05:10:38 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id FAA29929 for hackers-outgoing; Mon, 10 Nov 1997 05:10:38 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from time.cdrom.com (root@time.cdrom.com [204.216.27.226]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id FAA29920 for ; Mon, 10 Nov 1997 05:10:29 -0800 (PST) (envelope-from jkh@time.cdrom.com) Received: from time.cdrom.com (jkh@localhost.cdrom.com [127.0.0.1]) by time.cdrom.com (8.8.7/8.6.9) with ESMTP id FAA15119; Mon, 10 Nov 1997 05:09:37 -0800 (PST) To: Team FreeBSD RC5-64 Effort Cc: hackers@freebsd.org Subject: Re: Team FreeBSD RC5-64 Secret Key Challenge In-reply-to: Your message of "Mon, 10 Nov 1997 06:42:21 EST." <8188AD2EBC3CD111B7A30060082F32A401C5C7@FREYA> Date: Mon, 10 Nov 1997 05:09:37 -0800 Message-ID: <15115.879167377@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk While I appreciate your enthusiasm, posting this to every FreeBSD mailing list was a gross violation of the mailing list charters (section 25.1.3 of the handbook) and, should it be repeated, will result in the loss of your posting privileges. Do not do this again. This will be your only warning. Jordan > Calling all FreeBSD supporters everywhere! > > Team FreeBSD is a distributed effort by FreeBSD supporters > to crack the RC5-64 encryption (RSA Secret Key Challenge). > > This effort is coordinated by distributed.net using their > RC5-64 "Bovine" client programs. These programs use ONLY > idle time on your machine, affecting production use not at > all. There are versions of the client available for FreeBSD > as well as most other platforms. > > To find out more about Team FreeBSD, visit: > http://www.circle.net/team-freebsd > > To find out more about the RC5-64 effort, visit: > http://www.distributed.net > > To see the latest rankings of Team FreeBSD, visit: > http://rc5stats.distributed.net/tmsummary.idc?TM=988 > > To flame me for crossposting this announcement, mail to: > team-freebsd@circle.net > > - - - - - - > > If Team FreeBSD cracks the code, we plan on donating prize > winnings to the FreeBSD development effort. So your CPU idle time > could mean real cash $$ for FreeBSD. > > As of this posting, Team FreeBSD is now ranked #196 out of thousands > and climbing fast! From owner-freebsd-hackers Mon Nov 10 05:30:39 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id FAA00747 for hackers-outgoing; Mon, 10 Nov 1997 05:30:39 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from fallout.campusview.indiana.edu (fallout.campusview.indiana.edu [149.159.1.1]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id FAA00729 for ; Mon, 10 Nov 1997 05:30:34 -0800 (PST) (envelope-from jfieber@indiana.edu) Received: from localhost (jfieber@localhost) by fallout.campusview.indiana.edu (8.8.7/8.8.7) with SMTP id IAA02479; Mon, 10 Nov 1997 08:29:27 -0500 (EST) Date: Mon, 10 Nov 1997 08:29:26 -0500 (EST) From: John Fieber To: Postmaster cc: freebsd-hackers@FreeBSD.ORG Subject: Re: [?] login.conf In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Mon, 10 Nov 1997, Postmaster wrote: > I want limited user access to my computer > I try create /etc/login.conf whith contents > user-name: > times.deny 1400-1500 > and nothing. User user-name can logon in this period. Why ? It really needs to be CLEARLY documented, but a fair number of knobs in login.conf don't actually do anything (yet). As far as I know, only the limits and environment variables actually have any effect, and the latter don't work even in the "login.conf aware" version of xdm, or at least *I* can't get them to work. -john From owner-freebsd-hackers Mon Nov 10 05:51:00 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id FAA01734 for hackers-outgoing; Mon, 10 Nov 1997 05:51:00 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from ns1.yes.no (ns1.yes.no [195.119.24.10]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id FAA01727 for ; Mon, 10 Nov 1997 05:50:52 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [194.198.43.36]) by ns1.yes.no (8.8.7/8.8.7) with ESMTP id NAA29542; Mon, 10 Nov 1997 13:50:33 GMT Received: (from eivind@localhost) by bitbox.follo.net (8.8.6/8.8.6) id OAA18039; Mon, 10 Nov 1997 14:50:32 +0100 (MET) Date: Mon, 10 Nov 1997 14:50:32 +0100 (MET) Message-Id: <199711101350.OAA18039@bitbox.follo.net> From: Eivind Eklund To: Finn Arne Gangstad CC: hackers@FreeBSD.ORG In-reply-to: Finn Arne Gangstad's message of Fri, 7 Nov 1997 22:03:48 +0100 (MET) Subject: Re: Newest Pentium bug (fatal) References: <3463605C.41C67EA6@whistle.com> Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > EEk - don't try this on a compaq armada 1510 - no hard reset button (that > i can find) and power button is also soft power - so now I have to wait > for the battery to go empty on me.. Remove the batteries for a quick'n'hard shutdown. (Provided they can be removed, but I don't think I've ever seen a laptop where they can't). Eivind, who has had the same problem on a Mac - the DEMO PROGRAM supplied by Apple hung the box this hard; no changes from default install. From owner-freebsd-hackers Mon Nov 10 07:20:23 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id HAA05708 for hackers-outgoing; Mon, 10 Nov 1997 07:20:23 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from itsdsv1.enc.edu (fw1.enc.edu [207.95.42.127]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id HAA05698 for ; Mon, 10 Nov 1997 07:20:18 -0800 (PST) (envelope-from owensc@enc.edu) Received: from itsdsv2.enc.edu (itsdsv2.enc.edu [10.1.1.9]) by itsdsv1.enc.edu (8.7.5/8.7.3) with SMTP id KAA29230 for ; Mon, 10 Nov 1997 10:19:51 -0500 (EST) Date: Mon, 10 Nov 1997 10:19:51 -0500 (EST) From: Charles Owens To: hackers list FreeBSD Subject: NFS locking status (rpc.lockd) ? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi all, Is anyone currently working on getting NFS locking to work? I just dug through the list archive and it appears, a few months back, at least, that some folks had been thinking seriously about attempting an implementation. Where do we stand now? I'm in the design stage for a large-scale system that pretty much requires NFS-locking. In short, the basic design is a cluster of identical servers that NFS-mount user and group file areas off of one or more central, RAID-based NFS server(s). I'd _really_ like to use FreeBSD for this, but unless I can get the locking working I don't see how it can happen. (Any clever ideas for working around the lack of NFS locking?) If anyone _is_ working on this, I'd be glad to be of assistance in testing or whatever. I have access to FreeBSD, Solaris, and AIX (3.2.5 and 4.1) boxes. thanks, --- ------------------------------------------------------------------------- Charles N. Owens Email: owensc@enc.edu http://www.enc.edu/~owensc Network & Systems Administrator Information Technology Services "Outside of a dog, a book is a man's Eastern Nazarene College best friend. Inside of a dog it's too dark to read." - Groucho Marx ------------------------------------------------------------------------- From owner-freebsd-hackers Mon Nov 10 07:27:58 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id HAA06127 for hackers-outgoing; Mon, 10 Nov 1997 07:27:58 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from ns.samara.net (ns.samara.net [195.128.128.1]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id HAA06120 for ; Mon, 10 Nov 1997 07:27:47 -0800 (PST) (envelope-from pm@ns.online.samara.ru) Received: from ns.online.samara.ru ([195.128.128.206]) by ns.samara.net (8.7.5/8.7.3) with ESMTP id TAA08691 for ; Mon, 10 Nov 1997 19:46:19 +0400 (KSK) Received: by ns.online.samara.ru id TAA00219; (8.8.5/vak/1.9) Mon, 10 Nov 1997 19:21:00 GMT To: freebsd-hackers@freebsd.org Message-ID: Organization: Cronyx Ltd. From: "Postmaster" Date: Mon, 10 Nov 97 19:21:00 +0000 X-Mailer: BML [UNIX Beauty Mail v.1.39] Subject: unknown class Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In boot time I receive: inetd[160]: login_getclass: unknown class 'root' and after login I receive: login: login_getclass: unknown class 'root' Why ? my os is FreeBSD 2.2.2 From owner-freebsd-hackers Mon Nov 10 09:10:31 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id JAA11923 for hackers-outgoing; Mon, 10 Nov 1997 09:10:31 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from freya.circle.net (freya.circle.net [209.95.95.2] (may be forged)) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id JAA11918 for ; Mon, 10 Nov 1997 09:10:27 -0800 (PST) (envelope-from team-freebsd@circle.net) Received: by FREYA with Internet Mail Service (5.0.1457.3) id ; Mon, 10 Nov 1997 12:11:14 -0500 Message-ID: <8188AD2EBC3CD111B7A30060082F32A401C5DA@FREYA> From: Team FreeBSD RC5-64 Effort To: "'freebsd-hackers@freebsd.org'" Subject: Apologies Date: Mon, 10 Nov 1997 12:11:12 -0500 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1457.3) Content-Type: text/plain Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk My apologies for over-agressive crossposting of the prior email. I am sending this to -hackers only, though this apology applies to all the lists for which I violated charters. - RC5 Team FreeBSD Coordinator From owner-freebsd-hackers Mon Nov 10 09:16:57 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id JAA12359 for hackers-outgoing; Mon, 10 Nov 1997 09:16:57 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id JAA12351; Mon, 10 Nov 1997 09:16:43 -0800 (PST) (envelope-from bde@zeta.org.au) Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.7/8.6.9) id EAA23391; Tue, 11 Nov 1997 04:12:51 +1100 Date: Tue, 11 Nov 1997 04:12:51 +1100 From: Bruce Evans Message-Id: <199711101712.EAA23391@godzilla.zeta.org.au> To: dg@root.com, nnd@itfs.nsk.su Subject: Re: Cyclades :( Cc: bde@FreeBSD.ORG, hackers@FreeBSD.ORG Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > You're right - it appears the Bruce messed up the offsets when he "fixed" >the style/indentation. I don't have a -current machine here with the Cyclom-Y >in it, so I didn't notice the brokeness. Bruce? Oops. Fixed. >>> >--- cy.c.ORIG Sat Nov 1 13:33:19 1997 >>> >+++ cy.c Sat Nov 1 13:36:55 1997 >>> >@@ -410,7 +404,7 @@ >>> > #endif >>> > >>> > static int cy_chip_offset[] = { >>> >- 0x0000, 0x0200, 0x0400, 0x0600, 0x0100, 0x0300, 0x0500, 0x0700, >>> >+ 0x0000, 0x0400, 0x0800, 0x0c00, 0x0200, 0x0600, 0x0a00, 0x0e00 >>> > }; >>> > static int cy_nr_cd1400s[NCY]; >>> > static int cy_total_devices; This is correct. I haven't tested it, but it must be correct since it restores the known good table from rev.1.52. >>> > Partial "correctnes proof" for this patch can be found >>> >in (working) Linux 'cy' (or 'cz') driver which uses the same >>> >chip_offset addresses as in "patched" driver, but not as in >>> >original FreeBSD's 'cy' driver. The Linux driver is obfuscation for obfuscation compatible here :-). I fixed one of the obfuscations so I need a different table, but I shouldn't have committed the changed values. >>> If you look at the cy_inb/cy_outb functions in cyreg.h, you'll see that >>> the offset is adjusted (shifted left by one bit) for the PCI card, making >>> the appropriate adjustment. The above change (which has the left shift built >>> in to the numbers) would effectively double this shift. What I'm saying is >>> that unless I'm really missing something, the patch can't be correct. There are two independent shifts involved. For cy_inb/cy_outb, the cd1400 register numbers are shifted left by log2(bus_width_in_bytes) to get a partial offset. The shift is implemented as (log2(bus_width_in_bytes) - 1) in cy_align and 1 hard-coded in the macros, except in my version the entire shift is in cy_align. For the chip offsets, there should have been no shifts involved. However, old Cyclades boards wasted lots of address space (almost a factor of 4 even after a 2:1 wastage for mapping bytes to the bus width), so the address space had to be squeezed to make room for 32 ports, and the address space had to be stirred so that at least the first 16 of the 32 ports work with old drivers. In the PCI case, the shift to implement the squeezing is 1, and in the ISA case, the shift to implement null squeezing is 0, so the shift to implement squeezing just happens to be (log2(bus_width_in_bytes) - 1) in all cases. The driver exploits this to save a few cycles. This gives a confusing offset table in the PCI case (offsets are shifted right by 1). In my version, this gives a confusing offset table in all cases. >>[1.53 commit] >> Here you can see (unexplained in the commitlog) >>"division by 2" operation on the 'cy_chip_offset' array >>elements. I hope the above explains it in enough detail :-). I have another 30K of patches that I haven't worked on for a long time. They are mainly to save a few i/o instructions in the interrupt handler by not preserving the CAR (Channel Access Register) across interrupts. This brings the efficiency of the (default) Poll_Mode configuration closer to that of the (unavailable except on 8-port boards) svcack configuration. Bruce From owner-freebsd-hackers Mon Nov 10 09:22:01 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id JAA12785 for hackers-outgoing; Mon, 10 Nov 1997 09:22:01 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from eps.ufsc.br (root@eps.ufsc.br [150.162.1.50]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id JAA12767 for ; Mon, 10 Nov 1997 09:21:28 -0800 (PST) (envelope-from george@eps.ufsc.br) Received: from localhost ([150.162.50.32] (may be forged)) by eps.ufsc.br (8.8.6/8.7.3) with SMTP id PAA25821 for ; Mon, 10 Nov 1997 15:20:57 -0200 (EDT) Date: Mon, 10 Nov 1997 12:28:33 -0200 (EDT) From: George Tavares X-Sender: george@localhost To: hackers@freebsd.org Subject: AMD bug In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- On Sun, 9 Nov 1997, Eric J. Schwertfeger wrote: > > > Fixed in newer revisions of the chip, but I don't have all the data. Last > I checked (about a month ago), the only supplier that understood the > difference had the fixed chips for the K6 200mhz and less, but not the K6 > 233. > Is there any program to test the bug? Where I can find it? ----------------------------------------------------------------------- | George Tavares Ciencias da Computacao - UFSC | | Fone:(048)331-7020 E-mail: george@eps.ufsc.br | | http://www.eps.ufsc.br/~george PGP key disponivel por http | ----------------------------------------------------------------------- -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia Charset: noconv iQCVAwUBNGcaElMIPFxpfY6NAQGAfgQAvUih3h4I2SLm1xl5cvgSBVfhWmYCLIZR 2oEcVfTKknc/B4Obj96FzZXs80B1JOllFMo8NFgZy0mTELHt5d4HDNy+voX/McgG V7oKovfnR2U2HtHhFxxrRsgcbw6qlwmmASql7y9yWEYMGOCQN3krBX2lfXQ4AuH9 mgGKvHS2YJ8= =XT8t -----END PGP SIGNATURE----- From owner-freebsd-hackers Mon Nov 10 09:29:29 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id JAA13093 for hackers-outgoing; Mon, 10 Nov 1997 09:29:29 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from server.local.sunyit.edu (A-T34.rh.sunyit.edu [150.156.210.241]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id JAA13066 for ; Mon, 10 Nov 1997 09:29:02 -0800 (PST) (envelope-from perlsta@cs.sunyit.edu) Received: from localhost (perlsta@localhost) by server.local.sunyit.edu (8.8.7/8.8.5) with SMTP id NAA20799 for ; Mon, 10 Nov 1997 13:33:30 -0500 (EST) X-Authentication-Warning: server.local.sunyit.edu: perlsta owned process doing -bs Date: Mon, 10 Nov 1997 13:33:30 -0500 (EST) From: Alfred Perlstein X-Sender: perlsta@server.local.sunyit.edu To: hackers@FreeBSD.org Subject: Re: Newest Pentium bug (fatal) a fix? In-Reply-To: <199711100724.AAA09776@usr06.primenet.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk i don't know the logistics of doing this but what about an adapter that sits between the pentium and the socket that snoops for that code coming though the instruction line and mangles it into something different? would that work? is it feasable? -Alfred On Mon, 10 Nov 1997, Terry Lambert wrote: > > can't to my knowledge, unless you are going to have your OS's check each > > opcode before it is executed (for CS people out there that is > > O(really-nasty) ;). > > You could always use a two processor box and burn one processor to > watchdog the other. 8-). > > > Terry Lambert > terry@lambert.org > --- > Any opinions in this posting are my own and not those of my present > or previous employers. > From owner-freebsd-hackers Mon Nov 10 09:56:35 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id JAA15313 for hackers-outgoing; Mon, 10 Nov 1997 09:56:35 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from shell6.ba.best.com (root@shell6.ba.best.com [206.184.139.137]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id JAA15308 for ; Mon, 10 Nov 1997 09:56:27 -0800 (PST) (envelope-from bannai@shell6.ba.best.com) Received: (from bannai@localhost) by shell6.ba.best.com (8.8.7/8.7.3) id JAA10797; Mon, 10 Nov 1997 09:54:37 -0800 (PST) From: Vinay Bannai Message-Id: <199711101754.JAA10797@shell6.ba.best.com> Subject: Re: IDT processors? In-Reply-To: <199711100519.FAA00969@pencil-box.village.org> from "M. Warner Losh" at "Nov 9, 97 10:19:36 pm" To: imp@village.org (M. Warner Losh) Date: Mon, 10 Nov 1997 09:54:37 -0800 (PST) Cc: bsdhack@shadows.aeon.net, hackers@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL32 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk According to M. Warner Losh: > In message <199711092054.WAA17476@shadows.aeon.net> mika ruohotie writes: > : now, _that_ would be a port i'd like to see, freebsd on SGI platform. > : how likely is it? > > I once started a FreeBSD port to R4400 that it is in the arc machine I > have. I punted on it due to lack of time. There were also > perlininary offers to have someone pay for this port. > > Finally, the OpenBSD folks are working on an sgi port. I don't think > that it is in the tree yet. > > Warner > Hi Warner, I have been working on the R4k series for a while, most specifically R4650. This was mostly related to hooking up IDT NicStar 77201/77211 SAR chips. If you are stalled for some reason, let me know and I will be more than glad to give you a hand. I just got freed from a major obligation and seems like I will have some free time in the coming weeks/months. Vinay -- Vinay Bannai E-mail: bannai@best.com From owner-freebsd-hackers Mon Nov 10 10:41:11 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id KAA18597 for hackers-outgoing; Mon, 10 Nov 1997 10:41:11 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from smtp04.primenet.com (smtp04.primenet.com [206.165.5.85]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id KAA18588 for ; Mon, 10 Nov 1997 10:41:07 -0800 (PST) (envelope-from tlambert@usr05.primenet.com) Received: (from daemon@localhost) by smtp04.primenet.com (8.8.7/8.8.7) id LAA26664; Mon, 10 Nov 1997 11:40:23 -0700 (MST) Received: from usr05.primenet.com(206.165.6.205) via SMTP by smtp04.primenet.com, id smtpd026645; Mon Nov 10 11:40:17 1997 Received: (from tlambert@localhost) by usr05.primenet.com (8.8.5/8.8.5) id LAA10030; Mon, 10 Nov 1997 11:40:10 -0700 (MST) From: Terry Lambert Message-Id: <199711101840.LAA10030@usr05.primenet.com> Subject: Re: Newest Pentium bug (fatal) To: jkh@time.cdrom.com (Jordan K. Hubbard) Date: Mon, 10 Nov 1997 18:40:10 +0000 (GMT) Cc: helbig@Informatik.BA-Stuttgart.DE, freebsd-hackers@FreeBSD.ORG In-Reply-To: <13897.879152704@time.cdrom.com> from "Jordan K. Hubbard" at Nov 10, 97 01:05:04 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > Sorry, but there is one question left bothering me: > > What is the state of FreeBSD's ALPHA port? > > Going nowhere fast. Perhaps if the source tree were reorganized to be more multiple architecture friendly, progress would speed up? Converting changes to the FreeBSD source tree to an architecture friendly layout is no mean feat. It generally consumes a large part of the porter's time, for zero net gain (but without this process, you end up with code that is hopelessly out of date and thus impossible to integrate later -- like Jack Vogel's SPARC port of FreeBSD 1.5.1). As it is, I have a hard enough time keeping up with VM changes in my attempts to port FreeBSD's VM to NetBSD x86 and Alpha. 8-(. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Mon Nov 10 10:47:21 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id KAA19050 for hackers-outgoing; Mon, 10 Nov 1997 10:47:21 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from gvr.gvr.org (root@gvr.gvr.org [194.151.74.97]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id KAA18995; Mon, 10 Nov 1997 10:46:28 -0800 (PST) (envelope-from guido@gvr.org) Received: (from guido@localhost) by gvr.gvr.org (8.8.6/8.8.5) id TAA26362; Mon, 10 Nov 1997 19:45:53 +0100 (MET) From: Guido van Rooij Message-Id: <199711101845.TAA26362@gvr.gvr.org> Subject: multi sector io on IBM-DMCA-21440 To: freebsd-mobile@freebsd.org Date: Mon, 10 Nov 1997 19:45:53 +0100 (MET) Cc: FreeBSD-hackers@freebsd.org (FreeBSD-hackers) X-Mailer: ELM [version 2.4ME+ PL32 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk IS anyone using multi-sector IO successfully on his laptop? I am having problems when running a Compaq Armada 1130 with multi-sector io. The wd controller is identified as follows: wdc0 at 0x1f0-0x1f7 irq 14 flags 0x80008000 on isa wdc0: unit 0 (wd0): , 32-bit wd0: 1376MB (2818368 sectors), 2796 cyls, 16 heads, 63 S/T, 512 B/S When I would enable multi-sector io, the filesystem is severely corrupted (without the driver giving any errors at all.) I configured it with flas 0x80ff80ff. -Guido From owner-freebsd-hackers Mon Nov 10 10:57:09 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id KAA20047 for hackers-outgoing; Mon, 10 Nov 1997 10:57:09 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from smtp03.primenet.com (smtp03.primenet.com [206.165.5.84]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id KAA20040 for ; Mon, 10 Nov 1997 10:57:03 -0800 (PST) (envelope-from tlambert@usr05.primenet.com) Received: (from daemon@localhost) by smtp03.primenet.com (8.8.7/8.8.7) id LAA12504; Mon, 10 Nov 1997 11:57:03 -0700 (MST) Received: from usr05.primenet.com(206.165.6.205) via SMTP by smtp03.primenet.com, id smtpd012485; Mon Nov 10 11:56:53 1997 Received: (from tlambert@localhost) by usr05.primenet.com (8.8.5/8.8.5) id LAA10693; Mon, 10 Nov 1997 11:56:51 -0700 (MST) From: Terry Lambert Message-Id: <199711101856.LAA10693@usr05.primenet.com> Subject: Re: Newest Pentium bug (fatal) To: jbryant@tfs.net Date: Mon, 10 Nov 1997 18:56:50 +0000 (GMT) Cc: tlambert@primenet.com, freebsd-hackers@freebsd.org In-Reply-To: <199711100911.DAA07810@argus.tfs.net> from "Jim Bryant" at Nov 10, 97 03:11:40 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > In reply: > > > LOCK CMPXCHG8B EDX:EAX, ECX:EBX ; crash... pp 25-72 to > > > ; 25-73 of intel's arch & prog > > > ; manual for the pentium > > > > The same manual states that the CMPXCHG8B asserts a "#LOCK" signal, as > > does the "#LOCK" command. Also some paging situations, and "XCHG". > > where do you see this? what page? defintely not in the "Instruction > Set" chapter [chapter 25]... Look up "LOCK" instead of "CMPXCHG". > > It looks to me like they took the 486 macrocell, and extended it (easiest > > way to get binary compatability), and "forgot" the new registers when > > implementing the "#LOCK" assert test. > > the 0C8h r/m byte specifies the proper extended regs... > > > I can verify that using non-extended registers doesn't crash. > > if the backwards compatable 32-bit instruction CMPXCHG was buggy we > would have found out about this a long time ago... Why? A working compiler won't emit a "LOCK" before it... as others have pointed out, the bug is not that it doesn't work, but that it doesn't correctly signal an illegal instruction. The PPro and PII signal the illegal instruction. Try using your "backward compatability instruction" with a LOCK prefix on a PPro or PII. If my posting can't convince you, and you won't read about "LOCK", then perhaps a non-crashing machine signalling an illegal instruction can convinve you... > intel was obviously betting that things would remain 486 backwards > compatable for the market lifetime of the pentium. they had to have > tested this very early in the production cycle or late in the tooling > process. if i'm right about a coverup, it must have been a good one, > so good that they put it into the MMX. This would be a good theory, except that later 486's have portions of the Pentium macrocell embedded in them. If you read "Protected Mode Software Architecture", it's obvious that they have taken at least the CR4[VM] bit and V86 components and have retrofit them into the 486. That they were able to do this in such a way that it was cost effective (the only win they get is faster V86 mode on 486's than other 486 class chips) argues heavily for a large amount of shared silicon between the chips, and argues even more strongly for the macrocell extension theory of extended registers. Remember that Intel instructions are not mask programmed (like the 6502). Undocumented instructions are supposed to signal exceptions (unless the are in Appendix H). > > As someone else noticed, ther emay also be a cache fetch interaction > > (page fault was another thing referenced by #LOCK). > > > > Clearly, it's self-deadlocking trying to assert #LOCK. > > hmmmmmm.... > > just so we are talking apples <-> apples, i am referencing intel's > "Pentium(R) Processor Family Developer's Manual, Volume 3: > Archetecture and Programming Manual", ISBN 1-55512-247-7, (c) 1995, > order number 241430-004. covering the 1110/133, 1000/120, 815/100, > 735/90, and 615/75 cpus. I'm referencing: Pentium Processor System Architecture" MindShare, Inc. (Everyone should buy the full set of books to encourage these guys!) Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Mon Nov 10 11:08:59 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id LAA21041 for hackers-outgoing; Mon, 10 Nov 1997 11:08:59 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from smtp04.primenet.com (smtp04.primenet.com [206.165.5.85]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id LAA21036 for ; Mon, 10 Nov 1997 11:08:55 -0800 (PST) (envelope-from tlambert@usr05.primenet.com) Received: (from daemon@localhost) by smtp04.primenet.com (8.8.7/8.8.7) id MAA29859; Mon, 10 Nov 1997 12:08:43 -0700 (MST) Received: from usr05.primenet.com(206.165.6.205) via SMTP by smtp04.primenet.com, id smtpd029843; Mon Nov 10 12:08:37 1997 Received: (from tlambert@localhost) by usr05.primenet.com (8.8.5/8.8.5) id MAA11282; Mon, 10 Nov 1997 12:08:30 -0700 (MST) From: Terry Lambert Message-Id: <199711101908.MAA11282@usr05.primenet.com> Subject: Re: >64MB To: tony@dell.com (Tony Overfield) Date: Mon, 10 Nov 1997 19:08:30 +0000 (GMT) Cc: mike@smith.net.au, gurney_j@resnet.uoregon.edu, chuckr@glue.umd.edu, tlambert@primenet.com, jamil@trojanhorse.ml.org, hackers@FreeBSD.ORG, j_mini@efn.org In-Reply-To: <3.0.3.32.19971110034509.0069e370@bugs.us.dell.com> from "Tony Overfield" at Nov 10, 97 03:45:09 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > >The kernel is loaded above 1M, so you would have to be careful to make > >sure that your BIOS calls came out of the lowest 64K. That could be > >done with a dispatcher in locore.s though. > > I assume you mean the lowest 640K. But yes, a dispatcher would have > to exist down there, with a buffer large enough for your INT 13h calls > and etc. Actually, he means the 64k-16b that immediately follows the 1M boundary, since you can adulterate a segment register to access this memory (in effect you can start loading FreeBSD there, and so long as the access code and data go in that window, you can make it look like DOS memory and the BIOS can access it. > I don't know if it works, but it looks simple enough. I do realize it > offends the sensibilities of some real-mode fearing folks. > > If you can't trust the BIOS after the kernel is in memory, how can you > trust it to load the kernel into memory? While the kernel is still > "booting...", the BIOS should be safe enough to call in real-mode. Three problems: 1) You can't trust a *user process* to call the BIOS (it's not the sword that's the problem, it's what the peasent *does* with the sword that makes us make them illegal for everyone but the knights and the king). 2) The BIOS INT 13 code has a 2G limit on partition size, unless you can guarantee all the devices in your machine support LBA mode (even then the limit on LBA is lower than the limit in FreeBSD... 64bits >> 32 bits). 3) Gate A20 (now you will argue that Dell hardware doesn't use BIOS code that expects a wrap in memory). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Mon Nov 10 11:19:13 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id LAA21709 for hackers-outgoing; Mon, 10 Nov 1997 11:19:13 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from smtp03.primenet.com (smtp03.primenet.com [206.165.5.84]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id LAA21703 for ; Mon, 10 Nov 1997 11:19:06 -0800 (PST) (envelope-from tlambert@usr05.primenet.com) Received: (from daemon@localhost) by smtp03.primenet.com (8.8.7/8.8.7) id MAA14024; Mon, 10 Nov 1997 12:19:06 -0700 (MST) Received: from usr05.primenet.com(206.165.6.205) via SMTP by smtp03.primenet.com, id smtpd014004; Mon Nov 10 12:18:57 1997 Received: (from tlambert@localhost) by usr05.primenet.com (8.8.5/8.8.5) id MAA11628; Mon, 10 Nov 1997 12:18:55 -0700 (MST) From: Terry Lambert Message-Id: <199711101918.MAA11628@usr05.primenet.com> Subject: Re: >64MB To: tony@dell.com (Tony Overfield) Date: Mon, 10 Nov 1997 19:18:54 +0000 (GMT) Cc: tlambert@primenet.com, hackers@FreeBSD.ORG In-Reply-To: <3.0.3.32.19971110034659.0069e370@bugs.us.dell.com> from "Tony Overfield" at Nov 10, 97 03:46:59 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > To their credit, the non-Intel system designers are taking advantage of > the abundance of Intel compatible devices and now you want to complain > that the Intel compatible industry should have spent more energy > accomodating the other .5% (wild, irresponsible guess) of the market, > but they didn't do it because they "don't know how." No, I want to complain that Intel wields monopolistic power in the marketplace, and should have it's CPU division broken away from its support chip divisions, under the terms of the Sherman Antitrust Acts. But since doing so will fall on deaf ears, I won't do that here. ;-). > I don't suppose > you can think of any other reason besides that one. Sure I can: they've leanrned the lesson Apple keeps failing to learn: it's better to have 30% of 90% of the market than it is to have 100% of 6% of the market. To get 30% of 100% of the market would take more than a 3% cost of goods sold increase (mostly because the 10% was not form factor compatible, historically -- now they are). So it's simply that they are behind the times, and slow to react. Before you rip me a new one, note that in my previous posting, I referred to putting the mode tables where an OS could find them, as opposed to making the (much bigger) investment in "Open" Firmware. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Mon Nov 10 11:30:40 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id LAA22351 for hackers-outgoing; Mon, 10 Nov 1997 11:30:40 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from unix.tfs.net (root@unix.tfs.net [199.79.146.60]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id LAA22345 for ; Mon, 10 Nov 1997 11:30:33 -0800 (PST) (envelope-from jbryant@argus.tfs.net) Received: from argus.tfs.net (pm3-p10.tfs.net [206.154.183.202]) by unix.tfs.net (8.8.5/8.8.5) with ESMTP id NAA20005; Mon, 10 Nov 1997 13:29:03 -0600 Received: (from jbryant@localhost) by argus.tfs.net (8.8.7/8.8.5) id NAA08588; Mon, 10 Nov 1997 13:30:21 -0600 (CST) From: Jim Bryant Message-Id: <199711101930.NAA08588@argus.tfs.net> Subject: Re: Newest Pentium bug (fatal) a fix? In-Reply-To: from Alfred Perlstein at "Nov 10, 97 01:33:30 pm" To: perlsta@cs.sunyit.edu (Alfred Perlstein) Date: Mon, 10 Nov 1997 13:30:15 -0600 (CST) Cc: freebsd-hackers@freebsd.org Reply-to: jbryant@tfs.net X-Windows: R00LZ!@# MS-Winbl0wz DR00LZ!@# X-Operating-System: FreeBSD 2.2.2-RELEASE #0: Wed Jul 9 01:01:24 CDT 1997 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-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk RECALL RECALL RECALL In reply: > i don't know the logistics of doing this but what about an adapter that > sits between the pentium and the socket that snoops for that code coming > though the instruction line and mangles it into something different? > > would that work? is it feasable? > > -Alfred > > > On Mon, 10 Nov 1997, Terry Lambert wrote: > > > > can't to my knowledge, unless you are going to have your OS's check each > > > opcode before it is executed (for CS people out there that is > > > O(really-nasty) ;). > > > > You could always use a two processor box and burn one processor to > > watchdog the other. 8-). > > > > > > Terry Lambert > > terry@lambert.org > > --- > > Any opinions in this posting are my own and not those of my present > > or previous employers. > > > > -- All opinions expressed are mine, if you | "I will not be pushed, stamped, think otherwise, then go jump into turbid | briefed, debriefed, indexed, or radioactive waters and yell WAHOO !!! | numbered!" - #1, "The Prisoner" ------------------------------------------------------------------------------ Inet: jbryant@tfs.net AX.25: kc5vdj@wv0t.#neks.ks.usa.noam grid: EM28pw voice: KC5VDJ - 6 & 2 Meters AM/FM/SSB, 70cm FM. http://www.tfs.net/~jbryant ------------------------------------------------------------------------------ HF/6M/2M: IC-706-MkII, 2M: HTX-212, 2M: HTX-202, 70cm: HTX-404, Packet: KPC-3+ From owner-freebsd-hackers Mon Nov 10 11:36:25 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id LAA22880 for hackers-outgoing; Mon, 10 Nov 1997 11:36:25 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from iafnl.es.iaf.nl (uucp@iafnl.es.iaf.nl [195.108.17.20]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id LAA22875 for ; Mon, 10 Nov 1997 11:36:22 -0800 (PST) (envelope-from wilko@yedi.iaf.nl) Received: by iafnl.es.iaf.nl with UUCP id AA04203 (5.67b/IDA-1.5 for freebsd-hackers@FreeBSD.ORG); Mon, 10 Nov 1997 20:35:43 +0100 Received: (from wilko@localhost) by yedi.iaf.nl (8.8.5/8.6.12) id TAA01572; Mon, 10 Nov 1997 19:37:57 +0100 (MET) From: Wilko Bulte Message-Id: <199711101837.TAA01572@yedi.iaf.nl> Subject: Re: Newest Pentium bug (fatal) To: jkh@time.cdrom.com (Jordan K. Hubbard) Date: Mon, 10 Nov 1997 19:37:57 +0100 (MET) Cc: helbig@Informatik.BA-Stuttgart.DE, freebsd-hackers@FreeBSD.ORG In-Reply-To: <13897.879152704@time.cdrom.com> from "Jordan K. Hubbard" at Nov 10, 97 01:05:04 am X-Organisation: Private FreeBSD site - Arnhem, The Netherlands X-Pgp-Info: PGP public key at 'finger wilko@freefall.freebsd.org' X-Mailer: ELM [version 2.4 PL24 ME8a] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk As Jordan K. Hubbard wrote... > > > > In any case, this is a generic x86 problem and no longer of *specific* > > > interest to FreeBSD - I'm sure that the comp.arch.x86 newsgroup will > > > have more information. > > > > > > Thanks. > > > > Sorry, but there is one question left bothering me: > > What is the state of FreeBSD's ALPHA port? > > Going nowhere fast. > > Jordan Am I to interpret this as 'going nowhere at all' or am I then overly negative? Wilko _ ______________________________________________________________________ | / o / / _ Bulte email: wilko@yedi.iaf.nl http://www.tcja.nl/~wilko |/|/ / / /( (_) Arnhem, The Netherlands - Do, or do not. There is no 'try' ---------------- Support your local daemons: run [Free,Net]BSD Unix --Yoda From owner-freebsd-hackers Mon Nov 10 11:56:54 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id LAA24048 for hackers-outgoing; Mon, 10 Nov 1997 11:56:54 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from unix.tfs.net (root@unix.tfs.net [199.79.146.60]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id LAA24043 for ; Mon, 10 Nov 1997 11:56:49 -0800 (PST) (envelope-from jbryant@argus.tfs.net) Received: from argus.tfs.net (pm3-p10.tfs.net [206.154.183.202]) by unix.tfs.net (8.8.5/8.8.5) with ESMTP id NAA24172; Mon, 10 Nov 1997 13:55:19 -0600 Received: (from jbryant@localhost) by argus.tfs.net (8.8.7/8.8.5) id NAA08623; Mon, 10 Nov 1997 13:56:37 -0600 (CST) From: Jim Bryant Message-Id: <199711101956.NAA08623@argus.tfs.net> Subject: Re: Newest Pentium bug (fatal) In-Reply-To: <199711101856.LAA10693@usr05.primenet.com> from Terry Lambert at "Nov 10, 97 06:56:50 pm" To: tlambert@primenet.com (Terry Lambert) Date: Mon, 10 Nov 1997 13:56:36 -0600 (CST) Cc: freebsd-hackers@freebsd.org Reply-to: jbryant@tfs.net X-Windows: R00LZ!@# MS-Winbl0wz DR00LZ!@# X-Operating-System: FreeBSD 2.2.2-RELEASE #0: Wed Jul 9 01:01:24 CDT 1997 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-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In reply: > > In reply: > > > The same manual states that the CMPXCHG8B asserts a "#LOCK" signal, as > > > does the "#LOCK" command. Also some paging situations, and "XCHG". > > > > where do you see this? what page? defintely not in the "Instruction > > Set" chapter [chapter 25]... > > Look up "LOCK" instead of "CMPXCHG". [big snip] okay, i finally got some sleep, and re-read the manual... the fact that there are a limited number of r64 values and the fact that it is documented to create the exception for the register operand would indicate that it would have been tested at some point [my guess is too late to fix it]... i re-read LOCK, and found your reference, and see why i initially dismissed it... the only place you could be referring to is: "The XCHG instruction always asserts LOCK# regardless of the presence or absence of the LOCK prefix." no mention is made of CMPXCHG or CMPXCHG8B, but even running on the assumption that they share the same logic with XCHG, then the LOCK prefix is still legal, and apparently ignored. CMPXCHG and CMPXCHG8B are both explicitly documented under "notes" to be compatable with the LOCK prefix. your argument about compilers is correct. LOCK should only really be seen in OS software and device drivers. my backwards compatability argument as the reason for this only being found now still stands with or without the prefix. jim -- All opinions expressed are mine, if you | "I will not be pushed, stamped, think otherwise, then go jump into turbid | briefed, debriefed, indexed, or radioactive waters and yell WAHOO !!! | numbered!" - #1, "The Prisoner" ------------------------------------------------------------------------------ Inet: jbryant@tfs.net AX.25: kc5vdj@wv0t.#neks.ks.usa.noam grid: EM28pw voice: KC5VDJ - 6 & 2 Meters AM/FM/SSB, 70cm FM. http://www.tfs.net/~jbryant ------------------------------------------------------------------------------ HF/6M/2M: IC-706-MkII, 2M: HTX-212, 2M: HTX-202, 70cm: HTX-404, Packet: KPC-3+ From owner-freebsd-hackers Mon Nov 10 12:02:14 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id MAA24425 for hackers-outgoing; Mon, 10 Nov 1997 12:02:14 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from srv.net (snake.srv.net [199.104.81.3]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id MAA24418 for ; Mon, 10 Nov 1997 12:02:10 -0800 (PST) (envelope-from cmott@srv.net) Received: from darkstar.home (tc-if3-20.ida.net [208.141.171.125]) by srv.net (8.8.7/8.8.5) with SMTP id NAA10728 for ; Mon, 10 Nov 1997 13:02:01 -0700 (MST) Date: Mon, 10 Nov 1997 13:01:28 -0700 (MST) From: Charles Mott X-Sender: cmott@darkstar.home To: freebsd-hackers@FreeBSD.ORG Subject: Re: Newest Pentium bug (fatal) In-Reply-To: <199711101840.LAA10030@usr05.primenet.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > Perhaps if the source tree were reorganized to be more multiple > architecture friendly, progress would speed up? I'm sure other people have seen this problem, but the long data type seems to cause hell when transitioning from 32 to 64 bit architectures. There seem to be 2 strategies: (1) int = 32 bits, long = 32 bits, long long = 64 bits (2) int = 32 bits, long = 64 bits Strategy (1) helps with a lot of the networking code which assumes long is 32 bits, but then there are some functions which seem to think that the long data type should be the same size as an absolute address pointer. If int ever goes to 64 bits, I can't imagine what disasters would be waiting. But the fact that the NetBSD and OpenBSD people must have dealt with this problem indicates there must be a straightforward solution. Charles Mott From owner-freebsd-hackers Mon Nov 10 12:17:11 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id MAA25362 for hackers-outgoing; Mon, 10 Nov 1997 12:17:11 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from smtp03.primenet.com (smtp03.primenet.com [206.165.5.84]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id MAA25354 for ; Mon, 10 Nov 1997 12:17:07 -0800 (PST) (envelope-from tlambert@usr05.primenet.com) Received: (from daemon@localhost) by smtp03.primenet.com (8.8.7/8.8.7) id NAA18547; Mon, 10 Nov 1997 13:17:05 -0700 (MST) Received: from usr05.primenet.com(206.165.6.205) via SMTP by smtp03.primenet.com, id smtpd018523; Mon Nov 10 13:17:03 1997 Received: (from tlambert@localhost) by usr05.primenet.com (8.8.5/8.8.5) id NAA13623; Mon, 10 Nov 1997 13:16:59 -0700 (MST) From: Terry Lambert Message-Id: <199711102016.NAA13623@usr05.primenet.com> Subject: Re: >64MB To: tony@dell.com (Tony Overfield) Date: Mon, 10 Nov 1997 20:16:59 +0000 (GMT) Cc: tlambert@primenet.com, mike@smith.net.au, hackers@FreeBSD.ORG In-Reply-To: <3.0.3.32.19971110035805.006cab94@bugs.us.dell.com> from "Tony Overfield" at Nov 10, 97 03:58:05 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > No, it's not impossible to do, it's just useless to do, IMHO, for the > job at hand. I don't see any reason to turn the bootloader into a > vm86() program that plays games like this just to copy to memory above > 1 MB, since it's far easier to just switch modes and copy it directly. I think you are missing the point. There's no argument that the boot loader should be a vm86() program. The only argument is that it should do the minimum possible work that can possibly be done before handing the machine over to the kernel. This is because the more the boot loader does, the more you will have to rewrite for each new platform you port to, and the less it does, the less you will have to rewrite. The point of accessing system information from the kernel where possible is to make the boot-loader/kernel interconnect as architecturally abstract as it can possibly be, so that the majority of the startup code can be shared between architectures. The procedural abstraction, if not the functional. Ideally, you will have C versions of as much assembly code as you can possible arrange to have, in order to make a "base level port" as easy as possible. You leave the machine specific assembly code as an exercise in tuning (memcpy/bcopy is one example of something where a C version should be available, but an assembly version, *if* available, should be preferentially used -- clearly the FreeBSD tree is not very porting-friendly from this standpoint). This includes minimal C code to return statically set system specific data that match the machine to which you are porting -- memory size, initial day/date, and so on -- every possible piece of information that you would want to ask a BIOS (or on a PReP box, PPCBug, or on a CHRP box, OpenFirmWare, or on a Mac 6100, the system ROMs). These C versions of the static initialization data and slow support routines constitute a gross simplification on a HAL, and can hopefully evolve into a real HAL over time. But what that *does* mean for the x86 is that the information you obtain from the BIOS is to be obtained by the kernel, not by the boot loader and passed to the kernel. The best you can hope for the boot loader to pass to the kernel is a HAL access function entry point and a (void *) context. You *could* use this to statically gather BIOS data, and then access it via the function entry (which would only pretend to be a HAL), but this is not a terribly portable nor desirable reference implementation to aspire to... besides which, it makes the bootloader large, an offense in itself. > >There are several other you can do using suspend/resume instructions and > >similar tricks > > Suspend instruction? I could have sworn I knew them all by heart. There are "ICEBP" equivalents on non-Intel processors to do register and processor state saves and restores; typically, they are used by laptops for thjings like "suspend to disk" modes. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Mon Nov 10 12:22:46 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id MAA25659 for hackers-outgoing; Mon, 10 Nov 1997 12:22:46 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from smtp04.primenet.com (smtp04.primenet.com [206.165.5.85]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id MAA25654 for ; Mon, 10 Nov 1997 12:22:43 -0800 (PST) (envelope-from tlambert@usr05.primenet.com) Received: (from daemon@localhost) by smtp04.primenet.com (8.8.7/8.8.7) id NAA06188; Mon, 10 Nov 1997 13:22:33 -0700 (MST) Received: from usr05.primenet.com(206.165.6.205) via SMTP by smtp04.primenet.com, id smtpd006178; Mon Nov 10 13:22:29 1997 Received: (from tlambert@localhost) by usr05.primenet.com (8.8.5/8.8.5) id NAA13831; Mon, 10 Nov 1997 13:22:27 -0700 (MST) From: Terry Lambert Message-Id: <199711102022.NAA13831@usr05.primenet.com> Subject: Re: x86 gods; advice? Suggestions? To: Don.Lewis@tsc.tdk.com (Don Lewis) Date: Mon, 10 Nov 1997 20:22:27 +0000 (GMT) Cc: tlambert@primenet.com, hackers@FreeBSD.ORG In-Reply-To: <199711101135.DAA25891@salsa.gv.tsc.tdk.com> from "Don Lewis" at Nov 10, 97 03:35:50 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > } I think it's > } because they [Sun] don't sell any machines with PCI slots yet. > > Yes they do. There's the Ultra 30 workstation and the Ultra Enterprise > 150 and 450 servers. They also sell ATX format UltraSPARC motherboards. What do they sell for, so I can draw a distinction between "they manufacture" and "they sell"... ;-). Or alternately, I can rush out and buy one (I have been delaying in the hope I can find a used two processor SPARC cheap). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Mon Nov 10 12:31:53 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id MAA26182 for hackers-outgoing; Mon, 10 Nov 1997 12:31:53 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from srv.net (snake.srv.net [199.104.81.3]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id MAA26176 for ; Mon, 10 Nov 1997 12:31:49 -0800 (PST) (envelope-from cmott@srv.net) Received: from darkstar.home (tc-if3-20.ida.net [208.141.171.125]) by srv.net (8.8.7/8.8.5) with SMTP id NAA13490 for ; Mon, 10 Nov 1997 13:31:12 -0700 (MST) Date: Mon, 10 Nov 1997 13:30:38 -0700 (MST) From: Charles Mott X-Sender: cmott@darkstar.home To: hackers@freebsd.org Subject: Reading kernel memory Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I had earlier asked some questions about reducing the overhead in a gettimeofday() system call. One suggestion was to somehow map kernel memory into user space and read the system time variable. I have just tried doing this via the kvm_read() function, and it takes about 200 microseconds on a 386 to do this. In comparison, gettimeofday() takes only about 60 microseconds on the same machine. So if one really wants to map a kernel variable to user space, I am guessing something more sophisticated than the kvm routines are needed. [Note: originally I became interested in this as a way to speed up libalias a little bit, but this is really irrelevant now. I am more interested in understanding some of the underlying principles here. Please forgive my lack of practicality.] Wandering through the kernel source code, I have also discovered that gettimeofday() actaully invokes a microtime() call which actually tries to determine the time by reading a timer and using it to refine the kernel time variable. I was quite impressed by this, as previous experience with Linux indicates they just use a time variable updated every kernel quantum. The FreeBSD kernel treats the subject of time quite seriously. Charles Mott From owner-freebsd-hackers Mon Nov 10 12:40:33 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id MAA26785 for hackers-outgoing; Mon, 10 Nov 1997 12:40:33 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from smtp03.primenet.com (smtp03.primenet.com [206.165.5.84]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id MAA26780 for ; Mon, 10 Nov 1997 12:40:30 -0800 (PST) (envelope-from tlambert@usr05.primenet.com) Received: (from daemon@localhost) by smtp03.primenet.com (8.8.7/8.8.7) id NAA21906; Mon, 10 Nov 1997 13:39:58 -0700 (MST) Received: from usr05.primenet.com(206.165.6.205) via SMTP by smtp03.primenet.com, id smtpd021892; Mon Nov 10 13:39:52 1997 Received: (from tlambert@localhost) by usr05.primenet.com (8.8.5/8.8.5) id NAA14689; Mon, 10 Nov 1997 13:39:50 -0700 (MST) From: Terry Lambert Message-Id: <199711102039.NAA14689@usr05.primenet.com> Subject: Re: NFS locking status (rpc.lockd) ? To: owensc@enc.edu (Charles Owens) Date: Mon, 10 Nov 1997 20:39:50 +0000 (GMT) Cc: freebsd-hackers@FreeBSD.ORG In-Reply-To: from "Charles Owens" at Nov 10, 97 10:19:51 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > Is anyone currently working on getting NFS locking to work? I just dug > through the list archive and it appears, a few months back, at least, that > some folks had been thinking seriously about attempting an implementation. > Where do we stand now? Look a bit further back. I posted kernel patches for the server side to the -current list some time ago. More recently, I posted layering changes to support veto-based VOP_ADVLOCK implementation both for FS stacking, and to support client-side locking lock proxy to the server. Both of these were post-Lite2 integration. I also posted a kernel memory leak detection test environment, and a test written to use that environment to monitor namei buf usage and return across all system calls that did path lookup (Doug Rabson made some NFS changes that conflicted with my namei() layering fixes for some VFAT/VFAT32/NTFS support work I was doing, and one or both of us together introduced a path name buffer leak; I didn't have the ability to do the NFS tests locally, so I released the test environment). I haven't really been keeping this code fresh (other than the test environment which is trivial enough that it won't be impacted by anything but a massive change) since it's pretty clear it's not going to get committed until either someone who can vet the code wraps their brain around the VFS problems I'm trying to solve, or until I find the time to educate someone to the same effect (ie: wrap their brain around the code for them). > If anyone _is_ working on this, I'd be glad to be of assistance in testing > or whatever. I have access to FreeBSD, Solaris, and AIX (3.2.5 and 4.1) > boxes. I will look at what it will take to get the patches "fresh" again for you (I first did them in June 1995, more than two years ago -- about when Lite2 was released and a year and a half before it was integrated). There is still some rpc.lockd work that needs to be done. I can describe it, but the problem is the representation of the file handle; I don't know what it is, since it doesn't seem to match that of the kernel NFS. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Mon Nov 10 12:41:31 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id MAA26857 for hackers-outgoing; Mon, 10 Nov 1997 12:41:31 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from time.cdrom.com (root@time.cdrom.com [204.216.27.226]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id MAA26837 for ; Mon, 10 Nov 1997 12:41:27 -0800 (PST) (envelope-from jkh@time.cdrom.com) Received: from time.cdrom.com (jkh@localhost.cdrom.com [127.0.0.1]) by time.cdrom.com (8.8.7/8.6.9) with ESMTP id MAA16850; Mon, 10 Nov 1997 12:40:23 -0800 (PST) To: Terry Lambert cc: helbig@Informatik.BA-Stuttgart.DE, freebsd-hackers@FreeBSD.ORG Subject: Re: Newest Pentium bug (fatal) In-reply-to: Your message of "Mon, 10 Nov 1997 18:40:10 GMT." <199711101840.LAA10030@usr05.primenet.com> Date: Mon, 10 Nov 1997 12:40:22 -0800 Message-ID: <16846.879194422@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > Perhaps if the source tree were reorganized to be more multiple > architecture friendly, progress would speed up? No, if we had more people with ALPHAs and who actually understood the design of the "Miata" it would help more than anything else. Even with all the architecture friendliness in the world, we still wouldn't have this key ingredient. As usual, you're grossly oversimplifying the problem in order to grind your usual set of axes. Jordan From owner-freebsd-hackers Mon Nov 10 12:50:09 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id MAA27473 for hackers-outgoing; Mon, 10 Nov 1997 12:50:09 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from vision.connect.net (vision.connect.net [199.1.91.168]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id MAA27465 for ; Mon, 10 Nov 1997 12:50:04 -0800 (PST) (envelope-from bryan@connect.net) From: bryan@connect.net Received: from vw1p26.connect.net ([208.6.144.26]) by vision.connect.net (Post.Office MTA v3.1 release PO203a ID# 100-35121U5000L500S0) with SMTP id AAA1217 for ; Mon, 10 Nov 1997 14:49:59 -0600 Message-Id: <3.0.1.32.19971110144920.0069c3e8@connect.net> X-Sender: bryan@connect.net (Unverified) X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Mon, 10 Nov 1997 14:49:20 -0800 To: hackers@freebsd.org Subject: modem/ethernet card problem Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I recently purchased FreeBSD, version 2.2.2. I installed it on my laptop via parralel laplink cable. I have a Megahertz by USRobotics PCMCIA card. It is a pc card Ethernet Modem with XJACK connector. 28.8/14.4 bps. FreeBSD is probing the device as zp when I boot up the operating system. When I run the ppp program, I can't seem to talk to the modem. PPP says it dials and then prompts me with ok but i am getting no modem initalization. I Called walnut creek tech support and they encountered the same problem. It's probably singling out the ethernet device and not probing the modem. Thanks, Bryan Hinton From owner-freebsd-hackers Mon Nov 10 13:06:39 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id NAA28543 for hackers-outgoing; Mon, 10 Nov 1997 13:06:39 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from smtp03.primenet.com (smtp03.primenet.com [206.165.5.84]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id NAA28538 for ; Mon, 10 Nov 1997 13:06:36 -0800 (PST) (envelope-from tlambert@usr05.primenet.com) Received: (from daemon@localhost) by smtp03.primenet.com (8.8.7/8.8.7) id OAA26071; Mon, 10 Nov 1997 14:06:31 -0700 (MST) Received: from usr05.primenet.com(206.165.6.205) via SMTP by smtp03.primenet.com, id smtpd026060; Mon Nov 10 14:06:24 1997 Received: (from tlambert@localhost) by usr05.primenet.com (8.8.5/8.8.5) id OAA16644; Mon, 10 Nov 1997 14:06:22 -0700 (MST) From: Terry Lambert Message-Id: <199711102106.OAA16644@usr05.primenet.com> Subject: Re: Newest Pentium bug (fatal) To: jkh@time.cdrom.com (Jordan K. Hubbard) Date: Mon, 10 Nov 1997 21:06:21 +0000 (GMT) Cc: tlambert@primenet.com, helbig@Informatik.BA-Stuttgart.DE, freebsd-hackers@FreeBSD.ORG In-Reply-To: <16846.879194422@time.cdrom.com> from "Jordan K. Hubbard" at Nov 10, 97 12:40:22 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > Perhaps if the source tree were reorganized to be more multiple > > architecture friendly, progress would speed up? > > No, if we had more people with ALPHAs and who actually understood the > design of the "Miata" it would help more than anything else. Even > with all the architecture friendliness in the world, we still wouldn't > have this key ingredient. Well, since I own a "Multia" and not a "Miata", I don't really get how understanding the "Miata" would help me port to the "Multia", so perhaps you could explain it to me... > As usual, you're grossly oversimplifying > the problem in order to grind your usual set of axes. As SEF would say, "Pot. Kettle. Black.". There's a very simple way to keep me from grinding axes: take them away from me, leaving me nothing to grind. If you weren't always such an immovable object, then I wouldn't have to try to be an irresistable force to get you to move... I will be the first to admit that activity does not imply action ("Never substitute activity for action" -- Seneca, 4th century BC), but inactivity *does* imply inaction. If you don't agree with the action I propose, propose your own. But either way, *act*. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Mon Nov 10 13:21:25 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id NAA29453 for hackers-outgoing; Mon, 10 Nov 1997 13:21:25 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from time.cdrom.com (root@time.cdrom.com [204.216.27.226]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id NAA29448 for ; Mon, 10 Nov 1997 13:21:22 -0800 (PST) (envelope-from jkh@time.cdrom.com) Received: from time.cdrom.com (jkh@localhost.cdrom.com [127.0.0.1]) by time.cdrom.com (8.8.7/8.6.9) with ESMTP id NAA17169; Mon, 10 Nov 1997 13:20:38 -0800 (PST) To: Terry Lambert cc: helbig@Informatik.BA-Stuttgart.DE, freebsd-hackers@FreeBSD.ORG Subject: Re: Newest Pentium bug (fatal) In-reply-to: Your message of "Mon, 10 Nov 1997 21:06:21 GMT." <199711102106.OAA16644@usr05.primenet.com> Date: Mon, 10 Nov 1997 13:20:38 -0800 Message-ID: <17165.879196838@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > Well, since I own a "Multia" and not a "Miata", I don't really get > how understanding the "Miata" would help me port to the "Multia", > so perhaps you could explain it to me... The other people in the ALPHA project have Miatas. Your Multia is thus of little concern to them. > As SEF would say, "Pot. Kettle. Black.". > > There's a very simple way to keep me from grinding axes: take them > away from me, leaving me nothing to grind. If you weren't always > such an immovable object, then I wouldn't have to try to be an > irresistable force to get you to move... Terry, when will you learn? People aren't just sitting on their thumbs waiting for Terry The Great Motivator to kick them into action, there are other major stumbling blocks in the way which are drastically impeding progress, one such being the fact that Digital has been completely and totally unable to provide *any* technical documentation on these machines! NetBSD also doesn't run on them, so we can't even look "next door" for a peek at what's going on under their hood, so to speak, and the fact that they run DUX is of little use since DUX doesn't come with source code. If you really want to help then either get some documentation out of Digital using your direct pipeline to God (of course Terry talks directly to God, hasn't everyone here realized that by now? ;-) or get us a free source code license to Digital Unix so that we can crib code from them. Either way, get off your high horse and realize that not all issues can be conveniently steamrollered out of the way just because you say they should be. If you think an ALPHA port to the Miata is so simple then why don't *you* do it? Jordan From owner-freebsd-hackers Mon Nov 10 13:51:23 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id NAA02085 for hackers-outgoing; Mon, 10 Nov 1997 13:51:23 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from itsdsv1.enc.edu (fw1.enc.edu [207.95.42.127]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id NAA02063 for ; Mon, 10 Nov 1997 13:51:05 -0800 (PST) (envelope-from owensc@enc.edu) Received: from itsdsv2.enc.edu (itsdsv2.enc.edu [10.1.1.9]) by itsdsv1.enc.edu (8.7.5/8.7.3) with SMTP id QAA10716; Mon, 10 Nov 1997 16:49:41 -0500 (EST) Date: Mon, 10 Nov 1997 16:49:41 -0500 (EST) From: Charles Owens To: Terry Lambert cc: freebsd-hackers@FreeBSD.ORG Subject: Re: NFS locking status (rpc.lockd) ? In-Reply-To: <199711102039.NAA14689@usr05.primenet.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Mon, 10 Nov 1997, Terry Lambert wrote: > > Is anyone currently working on getting NFS locking to work? I just dug > > through the list archive and it appears, a few months back, at least, that > > some folks had been thinking seriously about attempting an implementation. > > Where do we stand now? > > Look a bit further back. I posted kernel patches for the server side > to the -current list some time ago. More recently, I posted layering > changes to support veto-based VOP_ADVLOCK implementation both for FS > stacking, and to support client-side locking lock proxy to the server. > > Both of these were post-Lite2 integration. > > I also posted a kernel memory leak detection test environment, and > a test written to use that environment to monitor namei buf usage > and return across all system calls that did path lookup (Doug Rabson > made some NFS changes that conflicted with my namei() layering fixes > for some VFAT/VFAT32/NTFS support work I was doing, and one or both > of us together introduced a path name buffer leak; I didn't have the > ability to do the NFS tests locally, so I released the test environment). > > I haven't really been keeping this code fresh (other than the test > environment which is trivial enough that it won't be impacted by > anything but a massive change) since it's pretty clear it's not > going to get committed until either someone who can vet the code > wraps their brain around the VFS problems I'm trying to solve, or > until I find the time to educate someone to the same effect (ie: > wrap their brain around the code for them). > > > > If anyone _is_ working on this, I'd be glad to be of assistance in testing > > or whatever. I have access to FreeBSD, Solaris, and AIX (3.2.5 and 4.1) > > boxes. > > I will look at what it will take to get the patches "fresh" again > for you (I first did them in June 1995, more than two years ago -- > about when Lite2 was released and a year and a half before it was > integrated). There is still some rpc.lockd work that needs to be > done. I can describe it, but the problem is the representation > of the file handle; I don't know what it is, since it doesn't seem > to match that of the kernel NFS. I appreciate your reply. It sounds like there is a good bit left to do... I'd love to delve into it myself, but I don't really have the skill, or the time. It doesn't seem too hopeful to me that individuals with the necessary skill, free time, and inclination are going to materialize and nail this problem within then next 4 months or so.... Which means my project either needs to be based on some other OS or utilize a completely different architecture... arrrgghhhh... :-| Again, if anyone would like to take this challenge upon themselves (oh please, oh please!) I will gladly assist with testing or whatever... Thanks, --- ------------------------------------------------------------------------- Charles N. Owens Email: owensc@enc.edu http://www.enc.edu/~owensc Network & Systems Administrator Information Technology Services "Outside of a dog, a book is a man's Eastern Nazarene College best friend. Inside of a dog it's too dark to read." - Groucho Marx ------------------------------------------------------------------------- From owner-freebsd-hackers Mon Nov 10 13:59:33 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id NAA02632 for hackers-outgoing; Mon, 10 Nov 1997 13:59:33 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from ns.mt.sri.com (SRI-56K-FR.mt.net [206.127.65.42]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id NAA02613 for ; Mon, 10 Nov 1997 13:59:24 -0800 (PST) (envelope-from nate@rocky.mt.sri.com) Received: from rocky.mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.8.7/8.8.7) with ESMTP id OAA20671; Mon, 10 Nov 1997 14:59:19 -0700 (MST) Received: (from nate@localhost) by rocky.mt.sri.com (8.7.5/8.7.3) id OAA11108; Mon, 10 Nov 1997 14:59:18 -0700 (MST) Date: Mon, 10 Nov 1997 14:59:18 -0700 (MST) Message-Id: <199711102159.OAA11108@rocky.mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: bryan@connect.net Cc: hackers@freebsd.org Subject: Re: modem/ethernet card problem In-Reply-To: <3.0.1.32.19971110144920.0069c3e8@connect.net> References: <3.0.1.32.19971110144920.0069c3e8@connect.net> X-Mailer: VM 6.29 under 19.15 XEmacs Lucid Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > I recently purchased FreeBSD, version 2.2.2. Hmm, how recently, and from whom? If possible, get a refund and get FreeBSD 2.2.5, which was released a couple of weeks ago. > I installed it on my laptop via parralel laplink cable. I have a > Megahertz by USRobotics PCMCIA card. It is a pc card Ethernet Modem > with XJACK connector. 28.8/14.4 bps. FreeBSD is probing the device as > zp when I boot up the operating system. Not quite. FreeBSD is trying to determine if your card matches the driver that the 'zp' device knows about, which is the 3COM ethernet driver. It doesn't match, so it doesn't use the driver for your card. > When I run the ppp program, I can't seem to talk to the modem. That's because there is no driver for your modem setup. Getting the driver to work with your modem is pretty easy, but it requires building a custom kernel. Having said that, this is a much easier task in 2.2.5-STABLE (post-2.2.5), where there is an example kernel config file, and suspend/resume supports works much better. > I Called walnut creek tech support and they encountered the same problem. > It's probably singling out the ethernet device and not probing the modem. They are right on the money. You need to either build a custom kernel with PCCARD support built in, setup /etc/rc.conf and /etc/pccard.conf correctly and it should be found fine. But, if you upgrade to the most recent release you'll get a bunch more bugfixes and generally better laptop support. Nate From owner-freebsd-hackers Mon Nov 10 14:45:08 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id OAA05258 for hackers-outgoing; Mon, 10 Nov 1997 14:45:08 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from whistle.com (s205m131.whistle.com [207.76.205.131]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id OAA05242 for ; Mon, 10 Nov 1997 14:44:52 -0800 (PST) (envelope-from archie@whistle.com) Received: (from smap@localhost) by whistle.com (8.7.5/8.6.12) id OAA20090; Mon, 10 Nov 1997 14:44:17 -0800 (PST) Received: from bubba.whistle.com(207.76.205.7) by whistle.com via smap (V1.3) id sma020086; Mon Nov 10 14:43:54 1997 Received: (from archie@localhost) by bubba.whistle.com (8.8.5/8.6.12) id OAA00849; Mon, 10 Nov 1997 14:43:54 -0800 (PST) From: Archie Cobbs Message-Id: <199711102243.OAA00849@bubba.whistle.com> Subject: Re: Newest Pentium bug (fatal) In-Reply-To: from Charles Mott at "Nov 10, 97 01:01:28 pm" To: cmott@srv.net (Charles Mott) Date: Mon, 10 Nov 1997 14:43:54 -0800 (PST) Cc: freebsd-hackers@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-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Charles Mott writes: > > Perhaps if the source tree were reorganized to be more multiple > > architecture friendly, progress would speed up? > > I'm sure other people have seen this problem, but the long data > type seems to cause hell when transitioning from 32 to 64 bit > architectures. There seem to be 2 strategies: > > (1) int = 32 bits, long = 32 bits, long long = 64 bits > > (2) int = 32 bits, long = 64 bits > > Strategy (1) helps with a lot of the networking code which assumes long is > 32 bits, but then there are some functions which seem to think that the > long data type should be the same size as an absolute address pointer. > > If int ever goes to 64 bits, I can't imagine what disasters would be > waiting. But the fact that the NetBSD and OpenBSD people must have dealt > with this problem indicates there must be a straightforward solution. This brings up a good point... if you're writing code and you want/expect something to be 32 bits, then its type should be either "int32_t" or "u_int32_t"!! Same goes for 8, 16, and 64! -Archie ___________________________________________________________________________ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com From owner-freebsd-hackers Mon Nov 10 15:15:34 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id PAA06791 for hackers-outgoing; Mon, 10 Nov 1997 15:15:34 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from isgate.is (isgate.is [193.4.58.51]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id PAA06785 for ; Mon, 10 Nov 1997 15:15:29 -0800 (PST) (envelope-from totii@est.is) Received: from eh.est.is (eh.est.is [194.144.208.34]) by isgate.is (8.7.5-M/) with ESMTP id XAA16327; Mon, 10 Nov 1997 23:15:24 GMT Received: from didda.est.is (totii@ppp-22.est.is [194.144.208.122]) by eh.est.is (8.8.5/8.8.5) with SMTP id XAA05623; Mon, 10 Nov 1997 23:15:33 GMT Message-ID: <3467958A.167EB0E7@est.is> Date: Mon, 10 Nov 1997 23:15:22 +0000 From: =?iso-8859-1?Q?=DEor=F0ur?= Ivarsson X-Mailer: Mozilla 3.01Gold (X11; I; FreeBSD 2.2.2-RELEASE i386) MIME-Version: 1.0 To: Postmaster CC: freebsd-hackers@FreeBSD.ORG Subject: Re: unknown class References: Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by hub.freebsd.org id PAA06787 Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Postmaster wrote: > > In boot time I receive: > inetd[160]: login_getclass: unknown class 'root' > and after login I receive: > login: login_getclass: unknown class 'root' > Why ? > my os is FreeBSD 2.2.2 This belongs to 'questions' ! Copy the file login.conf from /usr/src/etc to /etc Works if you installed the sources -- Þórður Ívarsson Thordur Ivarsson Rafeindavirki Electronic technician Norðurgötu 30 Nordurgotu 30 Box 309 Box 309 602 Akureyri 602 Akureyri Ísland Iceland --------------------------------------------- FreeBSD has good features, Some others are full of unwanted features! --------------------------------------------- From owner-freebsd-hackers Mon Nov 10 15:23:02 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id PAA07234 for hackers-outgoing; Mon, 10 Nov 1997 15:23:02 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from srv.net (snake.srv.net [199.104.81.3]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id PAA07224 for ; Mon, 10 Nov 1997 15:22:58 -0800 (PST) (envelope-from cmott@srv.net) Received: from darkstar.home (tc-if3-35.ida.net [208.141.171.140]) by srv.net (8.8.7/8.8.5) with SMTP id QAA32319; Mon, 10 Nov 1997 16:22:53 -0700 (MST) Date: Mon, 10 Nov 1997 16:22:19 -0700 (MST) From: Charles Mott X-Sender: cmott@darkstar.home To: Archie Cobbs cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Newest Pentium bug (fatal) In-Reply-To: <199711102243.OAA00849@bubba.whistle.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Mon, 10 Nov 1997, Archie Cobbs wrote: > Charles Mott writes: > > > Perhaps if the source tree were reorganized to be more multiple > > > architecture friendly, progress would speed up? > > > > I'm sure other people have seen this problem, but the long data > > type seems to cause hell when transitioning from 32 to 64 bit > > architectures. There seem to be 2 strategies: > > > > (1) int = 32 bits, long = 32 bits, long long = 64 bits > > > > (2) int = 32 bits, long = 64 bits > > > > Strategy (1) helps with a lot of the networking code which assumes long is > > 32 bits, but then there are some functions which seem to think that the > > long data type should be the same size as an absolute address pointer. > > > > If int ever goes to 64 bits, I can't imagine what disasters would be > > waiting. But the fact that the NetBSD and OpenBSD people must have dealt > > with this problem indicates there must be a straightforward solution. > > > > This brings up a good point... if you're writing code and you > want/expect something to be 32 bits, then its type should be > either "int32_t" or "u_int32_t"!! Same goes for 8, 16, and 64! > > I understand this, and I plan to weed these things out of libalias (the only thing I have any responsibility for in the FreeBSD source tree). However, if you take a cruise the the source tree and even the kernel in particular, you may discover quite frequent occurences of such problems. In particular, you might wish to try the following command. grep long /usr/include/netinet/*.h Somehow your message came accross as chastising me individually (I dunderstand these things), when you should consider the entire FreeBSD code base. What you recommend is good practice, but there is an enormous amount of existing code which does not adhere to this. Charles Mott From owner-freebsd-hackers Mon Nov 10 15:32:58 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id PAA07685 for hackers-outgoing; Mon, 10 Nov 1997 15:32:58 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from fallout.campusview.indiana.edu (fallout.campusview.indiana.edu [149.159.1.1]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id PAA07679 for ; Mon, 10 Nov 1997 15:32:51 -0800 (PST) (envelope-from jfieber@indiana.edu) Received: from localhost (jfieber@localhost) by fallout.campusview.indiana.edu (8.8.7/8.8.7) with SMTP id SAA03931; Mon, 10 Nov 1997 18:30:33 -0500 (EST) Date: Mon, 10 Nov 1997 18:30:32 -0500 (EST) From: John Fieber To: "Jordan K. Hubbard" cc: Terry Lambert , freebsd-hackers@FreeBSD.ORG Subject: Re: Newest Pentium bug (fatal) In-Reply-To: <17165.879196838@time.cdrom.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Mon, 10 Nov 1997, Jordan K. Hubbard wrote: Terry Lambert wrote: > > There's a very simple way to keep me from grinding axes: take them > > away from me, leaving me nothing to grind. If you weren't always > > such an immovable object, then I wouldn't have to try to be an > > irresistable force to get you to move... > > Terry, when will you learn? People aren't just sitting on their > thumbs waiting for Terry The Great Motivator to kick them into action, Yawn. I hate re-runs. Could you guys develop some new episodes? ]:-> -john From owner-freebsd-hackers Mon Nov 10 15:47:53 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id PAA08465 for hackers-outgoing; Mon, 10 Nov 1997 15:47:53 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from kinclaith.pdl.cs.cmu.edu (KINCLAITH.PDL.CS.CMU.EDU [128.2.189.18]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id PAA08446 for ; Mon, 10 Nov 1997 15:47:37 -0800 (PST) (envelope-from dpetrou@kinclaith.pdl.cs.cmu.edu) Message-Id: <199711102347.PAA08446@hub.freebsd.org> Subject: microtime() time travel? To: freebsd-hackers@freebsd.org Date: Mon, 10 Nov 1997 18:46:45 -0500 (EST) From: David Petrou X-Mailer: ELM [version 2.4 PL25-40] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi. I'm seeing something quite bizarre with microtime() under certain circumstances. I've made a little hack so that whenever a process is going to be desceduled (in mi_switch()) i print to the console how many microseconds the process used since it was scheduled. Normally, this works just fine. I see the output of the printf() in my xconsole. Now, I also have a serial console attached to my machine. If I kill my xconsole, kernel printf()'s go to my serial console at a much slower rate of 9600 baud. When I do this, my printf()'s start reporting that the process is using _negative_ amounts of time. Any potential explanations? Thanks, David From owner-freebsd-hackers Mon Nov 10 16:38:22 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id QAA11661 for hackers-outgoing; Mon, 10 Nov 1997 16:38:22 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from white.lambton.on.ca (white.lambton.on.ca [192.139.190.2]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id QAA11655 for ; Mon, 10 Nov 1997 16:38:16 -0800 (PST) (envelope-from david@lambton.on.ca) Received: from localhost (david@localhost) by white.lambton.on.ca (8.8.7/8.8.7) with SMTP id TAA05038 for ; Mon, 10 Nov 1997 19:38:00 -0500 (EST) Date: Mon, 10 Nov 1997 19:37:58 -0500 (EST) From: David Grant To: hackers@FreeBSD.ORG Subject: Anyone started an LM78 driver? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk I've got my hands on a new ASUS TX97 motherboard with the LM78 hardware monitor chip. The one line in the docs says its mapped to the ISA bus at 0x290. Anyone started a driver yet? It would be cool to know how hot the cpu is. :) (really bad pun intended :) Dave ----- David Grant VE3DGR +1 519 542-7751 x348 Lambton College, Sarnia, ON, CANADA +1 519 542-6667 FAX From owner-freebsd-hackers Mon Nov 10 18:02:30 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id SAA16481 for hackers-outgoing; Mon, 10 Nov 1997 18:02:30 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from whistle.com (s205m131.whistle.com [207.76.205.131]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id SAA16472 for ; Mon, 10 Nov 1997 18:02:24 -0800 (PST) (envelope-from archie@whistle.com) Received: (from smap@localhost) by whistle.com (8.7.5/8.6.12) id SAA21669; Mon, 10 Nov 1997 18:01:51 -0800 (PST) Received: from bubba.whistle.com(207.76.205.7) by whistle.com via smap (V1.3) id sma021665; Mon Nov 10 18:01:31 1997 Received: (from archie@localhost) by bubba.whistle.com (8.8.5/8.6.12) id SAA01528; Mon, 10 Nov 1997 18:01:31 -0800 (PST) From: Archie Cobbs Message-Id: <199711110201.SAA01528@bubba.whistle.com> Subject: Re: Newest Pentium bug (fatal) In-Reply-To: from Charles Mott at "Nov 10, 97 04:22:19 pm" To: cmott@srv.net (Charles Mott) Date: Mon, 10 Nov 1997 18:01:31 -0800 (PST) Cc: freebsd-hackers@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-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Charles Mott writes: > On Mon, 10 Nov 1997, Archie Cobbs wrote: > > Charles Mott writes: > > > > Perhaps if the source tree were reorganized to be more multiple > > > > architecture friendly, progress would speed up? > > > > > > I'm sure other people have seen this problem, but the long data > > > type seems to cause hell when transitioning from 32 to 64 bit > > > architectures. There seem to be 2 strategies: > > > > > > (1) int = 32 bits, long = 32 bits, long long = 64 bits > > > > > > (2) int = 32 bits, long = 64 bits > > > > > > Strategy (1) helps with a lot of the networking code which assumes long is > > > 32 bits, but then there are some functions which seem to think that the > > > long data type should be the same size as an absolute address pointer. > > > > > > If int ever goes to 64 bits, I can't imagine what disasters would be > > > waiting. But the fact that the NetBSD and OpenBSD people must have dealt > > > with this problem indicates there must be a straightforward solution. > > > > > > > > This brings up a good point... if you're writing code and you > > want/expect something to be 32 bits, then its type should be > > either "int32_t" or "u_int32_t"!! Same goes for 8, 16, and 64! > > > > > > I understand this, and I plan to weed these things out of libalias (the > only thing I have any responsibility for in the FreeBSD source tree). > > However, if you take a cruise the the source tree and even the kernel in > particular, you may discover quite frequent occurences of such problems. > In particular, you might wish to try the following command. > > grep long /usr/include/netinet/*.h > > Somehow your message came accross as chastising me individually (I > dunderstand these things), when you should consider the entire FreeBSD > code base. What you recommend is good practice, but there is an enormous > amount of existing code which does not adhere to this. Sorry about that, the "you" was intended to refer to ALL developers, including myself! :-) Of course, these type definitions are relatively new compared to BSD itself. It would be a good project for someone who's interested to identify and correct all of these in the code. This would go a long way towards making the source more portable. -Archie ___________________________________________________________________________ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com From owner-freebsd-hackers Mon Nov 10 20:02:55 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id UAA22995 for hackers-outgoing; Mon, 10 Nov 1997 20:02:55 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from trojanhorse.ml.org (mdean.vip.best.com [206.86.94.101]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id UAA22988 for ; Mon, 10 Nov 1997 20:02:47 -0800 (PST) (envelope-from jamil@trojanhorse.ml.org) Received: from localhost (jamil@localhost) by trojanhorse.ml.org (8.8.7/8.8.5) with SMTP id UAA01268 for ; Mon, 10 Nov 1997 20:02:40 -0800 (PST) Date: Mon, 10 Nov 1997 20:02:39 -0800 (PST) From: "Jamil J. Weatherbee" To: hackers@freebsd.org Subject: Possible Kernel Bug? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I may be dead wrong about this but it is worth a try: void *data; void *data_end; lets say you are passed a struct buf with a data buffer bp->b_data and bp->b_bcount = 1000; if you say data = bp->b_data /* this is fine */ what about data_end = bp->b_data + bp->b_bcount /* this pointer could point to something nonexistent??? */ so dereferencing it is definetly a no no (and that is not being done) but I see places where data compared to data_end , now since caddr_t is defined as , such as while (data < data_end) typedef char *caddr_t; which i assume is represented as a 32 bit unsigned integer are you guaranteed that the byte 0xffffffff is never allocated? this should be true in addition to 0x00000000 never being allocated. From owner-freebsd-hackers Mon Nov 10 21:07:32 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id VAA25988 for hackers-outgoing; Mon, 10 Nov 1997 21:07:32 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from picnic.mat.net (picnic.mat.net [206.246.122.117]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id VAA25982 for ; Mon, 10 Nov 1997 21:07:24 -0800 (PST) (envelope-from chuckr@glue.umd.edu) Received: from localhost (chuckr@localhost) by picnic.mat.net (8.8.7/8.8.5) with SMTP id XAA12093; Mon, 10 Nov 1997 23:04:03 -0500 (EST) X-Authentication-Warning: picnic.mat.net: chuckr owned process doing -bs Date: Mon, 10 Nov 1997 23:04:01 -0500 (EST) From: Chuck Robey X-Sender: chuckr@picnic.mat.net To: "Jamil J. Weatherbee" cc: hackers@FreeBSD.ORG Subject: Re: Possible Kernel Bug? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Mon, 10 Nov 1997, Jamil J. Weatherbee wrote: > > > I may be dead wrong about this but it is worth a try: > > void *data; > void *data_end; > > lets say you are passed a struct buf with a data buffer bp->b_data > and bp->b_bcount = 1000; > > if you say data = bp->b_data /* this is fine */ > what about data_end = bp->b_data + bp->b_bcount /* this pointer could > point to something nonexistent??? */ Dereferencing a void pointer won't work, because a void * is an example of a invalid pointer (unless casted to another type). "An attempt to dereference an invalid pointer may cause a run-time error" is from Harbison & Steele, section 5.3.2, page 110. Also illegal to do math on a void * (page 188). > > so dereferencing it is definetly a no no (and that is not being done) but > I see places where data compared to data_end , now since caddr_t is > defined as , such as while (data < data_end) > > typedef char *caddr_t; > which i assume is represented as a 32 bit unsigned integer > > are you guaranteed that the byte 0xffffffff is never allocated? > this should be true in addition to 0x00000000 never being allocated. > > > > > ----------------------------+----------------------------------------------- Chuck Robey | Interests include any kind of voice or data chuckr@glue.umd.edu | communications topic, C programming, and Unix. 213 Lakeside Drive Apt T-1 | Greenbelt, MD 20770 | I run Journey2 and picnic, both FreeBSD (301) 220-2114 | version 3.0 current -- and great FUN! ----------------------------+----------------------------------------------- From owner-freebsd-hackers Mon Nov 10 21:27:27 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id VAA26777 for hackers-outgoing; Mon, 10 Nov 1997 21:27:27 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from usr02.primenet.com (tlambert@usr02.primenet.com [206.165.6.202]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id VAA26772 for ; Mon, 10 Nov 1997 21:27:22 -0800 (PST) (envelope-from tlambert@usr02.primenet.com) Received: (from tlambert@localhost) by usr02.primenet.com (8.8.5/8.8.5) id WAA21873; Mon, 10 Nov 1997 22:26:50 -0700 (MST) From: Terry Lambert Message-Id: <199711110526.WAA21873@usr02.primenet.com> Subject: Re: Newest Pentium bug (fatal) To: jkh@time.cdrom.com (Jordan K. Hubbard) Date: Tue, 11 Nov 1997 05:26:49 +0000 (GMT) Cc: tlambert@primenet.com, helbig@Informatik.BA-Stuttgart.DE, freebsd-hackers@FreeBSD.ORG In-Reply-To: <17165.879196838@time.cdrom.com> from "Jordan K. Hubbard" at Nov 10, 97 01:20:38 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > Terry, when will you learn? People aren't just sitting on their > thumbs waiting for Terry The Great Motivator to kick them into action, > there are other major stumbling blocks in the way which are > drastically impeding progress, one such being the fact that Digital > has been completely and totally unable to provide *any* technical > documentation on these machines! NetBSD also doesn't run on them, so > we can't even look "next door" for a peek at what's going on under > their hood, so to speak, and the fact that they run DUX is of little > use since DUX doesn't come with source code. Gee, sounds like you picked the perfoect porting platform... and me sitting here with this Multia with full system documentation, NetBSD source that runs on the thing, Linux source that runs on the thing, and a partial port of the FreeBSD VM code to the thing! Boy, is my face red! > If you really want to help then either get some documentation out of > Digital using your direct pipeline to God (of course Terry talks > directly to God, hasn't everyone here realized that by now? ;-) or > get us a free source code license to Digital Unix so that we can > crib code from them. Oh, yeah, THAT'LL happen. BTW: it's not the people who talk to God you have to worry about, it's the people who claim God talks to them, and that somehow ennobles their position in any discussion. > Either way, get off your high horse and realize that not all issues > can be conveniently steamrollered out of the way just because you say > they should be. If you think an ALPHA port to the Miata is so simple > then why don't *you* do it? Sorry, I only had $400 to sepnd on hardware. If you can't afford hardware and had to have DEC donate it, you probably shoould have gotten them to donate documentation at the same time... PS: Have you checked to see if Linux runs on the thing? Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Mon Nov 10 21:30:12 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id VAA26907 for hackers-outgoing; Mon, 10 Nov 1997 21:30:12 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from usr02.primenet.com (tlambert@usr02.primenet.com [206.165.6.202]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id VAA26900 for ; Mon, 10 Nov 1997 21:30:07 -0800 (PST) (envelope-from tlambert@usr02.primenet.com) Received: (from tlambert@localhost) by usr02.primenet.com (8.8.5/8.8.5) id WAA22034; Mon, 10 Nov 1997 22:30:05 -0700 (MST) From: Terry Lambert Message-Id: <199711110530.WAA22034@usr02.primenet.com> Subject: Re: Newest Pentium bug (fatal) To: archie@whistle.com (Archie Cobbs) Date: Tue, 11 Nov 1997 05:30:03 +0000 (GMT) Cc: cmott@srv.net, freebsd-hackers@FreeBSD.ORG In-Reply-To: <199711102243.OAA00849@bubba.whistle.com> from "Archie Cobbs" at Nov 10, 97 02:43:54 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > > This brings up a good point... if you're writing code and you > want/expect something to be 32 bits, then its type should be > either "int32_t" or "u_int32_t"!! Same goes for 8, 16, and 64! > > You're going to kill me on this... ;-). I suppose: 8 char 16 short 32 int 64 long ? ...I thought "int" was supposed to be the single-cycle-fetch type... so isn't int 64 like long? If so, how do I get an int32_t? Anyway, damn ANSI for not implementing sized types... or adopting "quad" and loosening the restriction on sizeof(long)>=sizeof(int). 8-(. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Mon Nov 10 21:34:44 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id VAA27173 for hackers-outgoing; Mon, 10 Nov 1997 21:34:44 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from time.cdrom.com (root@time.cdrom.com [204.216.27.226]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id VAA27165 for ; Mon, 10 Nov 1997 21:34:35 -0800 (PST) (envelope-from jkh@time.cdrom.com) Received: from time.cdrom.com (jkh@localhost.cdrom.com [127.0.0.1]) by time.cdrom.com (8.8.7/8.6.9) with ESMTP id VAA24583; Mon, 10 Nov 1997 21:32:09 -0800 (PST) To: Terry Lambert cc: helbig@Informatik.BA-Stuttgart.DE, freebsd-hackers@FreeBSD.ORG Subject: Re: Newest Pentium bug (fatal) In-reply-to: Your message of "Tue, 11 Nov 1997 05:26:49 GMT." <199711110526.WAA21873@usr02.primenet.com> Date: Mon, 10 Nov 1997 21:32:09 -0800 Message-ID: <24579.879226329@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > Gee, sounds like you picked the perfoect porting platform... and me > sitting here with this Multia with full system documentation, NetBSD > source that runs on the thing, Linux source that runs on the thing, > and a partial port of the FreeBSD VM code to the thing! Boy, is my > face red! You act as if this was my choice. Digital donated the stuff and since beggers can't be choosers, we took whatever they had to give. It wasn't until afterwards, when they proved unable to supply any docs, that we knew it would even be a problem. > Sorry, I only had $400 to sepnd on hardware. If you can't afford > hardware and had to have DEC donate it, you probably shoould have > gotten them to donate documentation at the same time... You think we haven't tried? Terry, I've had it with you. Consider yourself procmailed. I really don't feel the need to read anything you write anymore - it accomplishes nothing and leaves me only with a feeling of frustration. Jordan From owner-freebsd-hackers Mon Nov 10 21:55:48 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id VAA28245 for hackers-outgoing; Mon, 10 Nov 1997 21:55:48 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from usr02.primenet.com (tlambert@usr02.primenet.com [206.165.6.202]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id VAA28239 for ; Mon, 10 Nov 1997 21:55:43 -0800 (PST) (envelope-from tlambert@usr02.primenet.com) Received: (from tlambert@localhost) by usr02.primenet.com (8.8.5/8.8.5) id WAA23462; Mon, 10 Nov 1997 22:55:00 -0700 (MST) From: Terry Lambert Message-Id: <199711110555.WAA23462@usr02.primenet.com> Subject: Re: Newest Pentium bug (fatal) To: jkh@time.cdrom.com (Jordan K. Hubbard) Date: Tue, 11 Nov 1997 05:54:59 +0000 (GMT) Cc: tlambert@primenet.com, helbig@Informatik.BA-Stuttgart.DE, freebsd-hackers@FreeBSD.ORG In-Reply-To: <24579.879226329@time.cdrom.com> from "Jordan K. Hubbard" at Nov 10, 97 09:32:09 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > You think we haven't tried? Terry, I've had it with you. Consider > yourself procmailed. I really don't feel the need to read anything > you write anymore - it accomplishes nothing and leaves me only with a > feeling of frustration. Like I'm in the to be read by you. This really pisses me off. Either get behind the cart and push, or get the hell out of the way. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Mon Nov 10 22:39:29 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id WAA00982 for hackers-outgoing; Mon, 10 Nov 1997 22:39:29 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from dfw-ix2.ix.netcom.com (dfw-ix2.ix.netcom.com [206.214.98.2]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id WAA00973 for ; Mon, 10 Nov 1997 22:39:27 -0800 (PST) (envelope-from wghhicks@ix.netcom.com) Received: (from smap@localhost) by dfw-ix2.ix.netcom.com (8.8.4/8.8.4) id AAA08860; Tue, 11 Nov 1997 00:35:40 -0600 (CST) Received: from atl-ga19-02.ix.netcom.com(205.186.178.34) by dfw-ix2.ix.netcom.com via smap (V1.3) id rma008562; Tue Nov 11 00:34:11 1997 Message-ID: <3467FC52.1C6E655B@ix.netcom.com> Date: Tue, 11 Nov 1997 01:33:54 -0500 From: Jerry Hicks Reply-To: wghhicks@ix.netcom.com Organization: TerraEarth X-Mailer: Mozilla 4.03b8 [en] (X11; I; FreeBSD 2.2.5-STABLE i386) MIME-Version: 1.0 To: Terry Lambert CC: "Jordan K. Hubbard" , helbig@Informatik.BA-Stuttgart.DE, freebsd-hackers@FreeBSD.ORG Subject: Re: Newest Pentium bug (fatal) References: <199711110526.WAA21873@usr02.primenet.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > If you really want to help then either get some documentation out of > Digital using your direct pipeline to God (of course Terry talks > directly to God, hasn't everyone here realized that by now? ;-) or > get us a free source code license to Digital Unix so that we can > crib code from them. > Wonder if any lack of enthusiasm for FreeBSD from DEC has anything to do with Jon "Mad-Dog" Hall's Linux activities? I bet the Linux porters *do* have access to the aforementioned source code. And probably a goodly share of other DEC resources as well. Never heard it mentioned here... Jerry Hicks jerry_hicks@bigfoot.com From owner-freebsd-hackers Mon Nov 10 22:47:35 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id WAA01480 for hackers-outgoing; Mon, 10 Nov 1997 22:47:35 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from hokkshideh.jetcafe.org (hokkshideh.jetcafe.org [207.155.21.4]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id WAA01470 for ; Mon, 10 Nov 1997 22:47:32 -0800 (PST) (envelope-from dave@hokkshideh.jetcafe.org) Received: from hokkshideh.jetcafe.org (localhost [127.0.0.1]) by hokkshideh.jetcafe.org (8.8.5/8.8.5) with ESMTP id WAA05049 for ; Mon, 10 Nov 1997 22:47:31 -0800 (PST) Message-Id: <199711110647.WAA05049@hokkshideh.jetcafe.org> X-Mailer: exmh version 2.0zeta 7/24/97 To: hackers@FreeBSD.ORG Subject: Re: mv /usr/src/games /dev/null - any objections? Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 10 Nov 1997 22:47:31 -0800 From: Dave Hayes Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Niall Smart writes: > With all respect, studies show that only 1/100000 people install FreeBSD > to play text mode games. With all respect, I -teach- aspects of UNIX via games. As was pointed out, the VI cursor mode keys are in Rogue. Kids learn much quicker when playing games, and you will lose the Linux vs FreeBSD illusory war when you tell the kids that FreeBSD does not come with games but Linux does. ------ Dave Hayes - Altadena CA, USA - dave@jetcafe.org >>> The opinions expressed above are entirely my own <<< Freedom Knight of Usenet - http://www.jetcafe.org/~dave/usenet A suggested definition of "sin" - Trading aliveness for survival. From owner-freebsd-hackers Mon Nov 10 23:06:39 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id XAA03124 for hackers-outgoing; Mon, 10 Nov 1997 23:06:39 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from usr03.primenet.com (tlambert@usr03.primenet.com [206.165.6.203]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id XAA03098 for ; Mon, 10 Nov 1997 23:06:32 -0800 (PST) (envelope-from tlambert@usr03.primenet.com) Received: (from tlambert@localhost) by usr03.primenet.com (8.8.5/8.8.5) id AAA02943; Tue, 11 Nov 1997 00:06:11 -0700 (MST) From: Terry Lambert Message-Id: <199711110706.AAA02943@usr03.primenet.com> Subject: Re: Newest Pentium bug (fatal) To: jkh@time.cdrom.com (Jordan K. Hubbard) Date: Tue, 11 Nov 1997 07:06:10 +0000 (GMT) Cc: tlambert@primenet.com, helbig@Informatik.BA-Stuttgart.DE, freebsd-hackers@FreeBSD.ORG In-Reply-To: <24579.879226329@time.cdrom.com> from "Jordan K. Hubbard" at Nov 10, 97 09:32:09 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > Gee, sounds like you picked the perfoect porting platform... and me > > sitting here with this Multia with full system documentation, NetBSD > > source that runs on the thing, Linux source that runs on the thing, > > and a partial port of the FreeBSD VM code to the thing! Boy, is my > > face red! > > You act as if this was my choice. Digital donated the stuff and since > beggers can't be choosers, we took whatever they had to give. It > wasn't until afterwards, when they proved unable to supply any docs, > that we knew it would even be a problem. BTW, if this is truly your position, and you are not trying to "one-up" me (which is meaningless for me, I assure you; I am egoless in the Buddhist sense of the word, as well as the Jungian), then I'd have to say that "beggers are not the people who should be doing the port, since they might end up with undocumented hardware". You should start your calculation with "competed port = ?" instead of running calculations and hoping you end up with "completed port" as one of a number of brute-force soloutions. It's not like a lack of documentation is a totally unprecedented event, or even unexpected by a reasonable person for a new platform. Either you are being supported by DEC or you aren't. It's a nice, binary compare, which you should be capable of making on your own without me harrassing you into it by declaring it an Aristotilian mean. In that sense of undocumented vs. documented, it was *alway* your choice; the only variable was "who could afford to participate", and you made that decision based on your inherent biases, since it's not like all DEC hardware is undocumented. Only the hardware you felt compelled to choose because of your own bias. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Mon Nov 10 23:18:19 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id XAA03715 for hackers-outgoing; Mon, 10 Nov 1997 23:18:19 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from rah.star-gate.com (rah.star-gate.com [204.188.121.18]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id XAA03710 for ; Mon, 10 Nov 1997 23:18:16 -0800 (PST) (envelope-from hasty@rah.star-gate.com) Received: from rah.star-gate.com (localhost.v-site.net [127.0.0.1]) by rah.star-gate.com (8.8.7/8.8.5) with ESMTP id XAA03101; Mon, 10 Nov 1997 23:16:58 -0800 (PST) Message-Id: <199711110716.XAA03101@rah.star-gate.com> X-Mailer: exmh version 2.0zeta 7/24/97 To: Terry Lambert cc: jkh@time.cdrom.com (Jordan K. Hubbard), helbig@Informatik.BA-Stuttgart.DE, freebsd-hackers@FreeBSD.ORG Subject: Re: Newest Pentium bug (fatal) In-reply-to: Your message of "Tue, 11 Nov 1997 05:54:59 GMT." <199711110555.WAA23462@usr02.primenet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 10 Nov 1997 23:16:58 -0800 From: Amancio Hasty Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Okay boys, Time out for coffee and you have to retrieve to your respective hacking corners 8) Cheers, Amancio From owner-freebsd-hackers Tue Nov 11 00:20:35 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id AAA07468 for hackers-outgoing; Tue, 11 Nov 1997 00:20:35 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id AAA07461 for ; Tue, 11 Nov 1997 00:20:31 -0800 (PST) (envelope-from julian@whistle.com) Received: (from daemon@localhost) by alpo.whistle.com (8.8.5/8.8.5) id AAA14683 for ; Tue, 11 Nov 1997 00:15:16 -0800 (PST) Received: from UNKNOWN(), claiming to be "current1.whistle.com" via SMTP by alpo.whistle.com, id smtpd014680; Tue Nov 11 00:15:07 1997 Message-ID: <3468139A.167EB0E7@whistle.com> Date: Tue, 11 Nov 1997 00:13:14 -0800 From: Julian Elischer Organization: Whistle Communications X-Mailer: Mozilla 3.0Gold (X11; I; FreeBSD 2.2-CURRENT i386) MIME-Version: 1.0 To: hackers@freebsd.org Subject: Out of mount flags in mount.h Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I was porting some Whistle changes to -current, when I suddenly came up a show-stopper bug. we are out of flag bits. In other words we have run out of bits to describe how a filesystem might be mounted. (e.g. nosuid, noexec, readonly, etc.) does anyone have any suggestions about how to fix this? I notice that mount.c in src/sbin/mount has room for something called the "alt_flags". Is this an attempt to get around this? somehow I want to be able to mount a partition with my SUID-directory changes, but while it fits under 2.2.5 (what we use) I can't migrate it forward to 3.0.. suggestions gratefuly received. rewriting every function and program that uses the mount flags is going to be grim.. maybe just define it to be quad_t? Migration would be a pain.. julian From owner-freebsd-hackers Tue Nov 11 00:31:19 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id AAA07983 for hackers-outgoing; Tue, 11 Nov 1997 00:31:19 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from rah.star-gate.com (rah.star-gate.com [204.188.121.18]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id AAA07978 for ; Tue, 11 Nov 1997 00:31:15 -0800 (PST) (envelope-from hasty@rah.star-gate.com) Received: from rah.star-gate.com (localhost.v-site.net [127.0.0.1]) by rah.star-gate.com (8.8.7/8.8.5) with ESMTP id AAA03740; Tue, 11 Nov 1997 00:21:18 -0800 (PST) Message-Id: <199711110821.AAA03740@rah.star-gate.com> X-Mailer: exmh version 2.0gamma 1/27/96 To: proff@iq.org cc: freebsd-hackers@FreeBSD.ORG Subject: Re: real audio In-reply-to: Your message of "Mon, 10 Nov 1997 11:28:54 +0100." <199711101028.LAA01718@labinfo.iet.unipi.it> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 11 Nov 1997 00:21:17 -0800 From: Amancio Hasty Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk And Folks, if you have questions about multimedia stuff try to post to multimedia@freebsd.org . Cheers, Amancio > > I am using an 8bit SB pro (which works fine with NAS etc). I would > > be a little suprised to find that RAP has no support for 8bit output > > devices. > > > > A have a few 16 bit cards, but being PnP they appear totally useless > > under FreeBSD. > > At http://www.iet.unipi.it/~luigi/FreeBSD.html > you can find PnP support and the new audio driver which works well with > many new PnP 16-bit cards and many many apps. > > Cheers > Luigi > -----------------------------+-------------------------------------- > Luigi Rizzo | Dip. di Ingegneria dell'Informazione > email: luigi@iet.unipi.it | Universita' di Pisa > tel: +39-50-568533 | via Diotisalvi 2, 56126 PISA (Italy) > fax: +39-50-568522 | http://www.iet.unipi.it/~luigi/ > _____________________________|______________________________________ > From owner-freebsd-hackers Tue Nov 11 00:40:11 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id AAA08334 for hackers-outgoing; Tue, 11 Nov 1997 00:40:11 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id AAA08327 for ; Tue, 11 Nov 1997 00:40:09 -0800 (PST) (envelope-from julian@whistle.com) Received: (from daemon@localhost) by alpo.whistle.com (8.8.5/8.8.5) id AAA15119 for ; Tue, 11 Nov 1997 00:39:47 -0800 (PST) Received: from UNKNOWN(), claiming to be "current1.whistle.com" via SMTP by alpo.whistle.com, id smtpd015117; Tue Nov 11 00:39:39 1997 Message-ID: <3468195A.15FB7483@whistle.com> Date: Tue, 11 Nov 1997 00:37:46 -0800 From: Julian Elischer Organization: Whistle Communications X-Mailer: Mozilla 3.0Gold (X11; I; FreeBSD 2.2-CURRENT i386) MIME-Version: 1.0 To: hackers@freebsd.org Subject: Re: Out of flag bits in mount.h Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I just noticed that a bunch of bits have dissappeared in -current. (in the mount structure flags word) Are they really free? can I recycle these bits? (I need one) julian From owner-freebsd-hackers Tue Nov 11 01:08:15 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id BAA09826 for hackers-outgoing; Tue, 11 Nov 1997 01:08:15 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from seidata.com (seidata.com [206.160.242.33]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id BAA09821 for ; Tue, 11 Nov 1997 01:08:11 -0800 (PST) (envelope-from mike@seidata.com) Received: from seidata.com ([208.10.211.51]) by seidata.com (8.8.7/8.8.5) with ESMTP id EAA06981; Tue, 11 Nov 1997 04:07:47 -0500 (EST) Message-ID: <346768CA.5984ED28@seidata.com> Date: Mon, 10 Nov 1997 15:04:26 -0500 From: Mike Hoskins X-Mailer: Mozilla 4.03 [en] (Win95; I) MIME-Version: 1.0 To: wghhicks@ix.netcom.com, freebsd-hackers@freebsd.org Subject: Re: Newest Pentium bug (fatal) References: <199711110526.WAA21873@usr02.primenet.com> <3467FC52.1C6E655B@ix.netcom.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Jerry Hicks wrote: > I bet the Linux porters *do* have access to the aforementioned source > code. And probably a goodly share of other DEC resources as well. I use FreeBSD and Linux on a regular basis, and if this is the case, I find it very discouraging. I've always viewed Linux and FreeBSD as "alternative operating systems". That is defined, by me, to be operating systems programmed by individuals that rise above petty differences, corporate bloat, and/or monetary concerns to have one common goal... to program the best OS possible. Windows/MacOS/etc. seem to be so busy fighting against each other that progress is, in many ways, greatly hindered by their petty, greed-driven bickering. I had always hoped (and still believe) that both FreeBSD and Linux rose above such bickering and focussed on the important issues of security/performance/etc. If, however, either side were to purposefully withhold any type of information simply to "ensure their OS does better than the other", it would seem the guilty party has adopted a rather Microsoft-like attitude on development. --- Mike Hoskins SEI Data Network Services mike@seidata.com From owner-freebsd-hackers Tue Nov 11 01:33:08 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id BAA11114 for hackers-outgoing; Tue, 11 Nov 1997 01:33:08 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from dfw-ix5.ix.netcom.com (dfw-ix5.ix.netcom.com [206.214.98.5]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id BAA11106 for ; Tue, 11 Nov 1997 01:33:05 -0800 (PST) (envelope-from wghhicks@ix.netcom.com) Received: (from smap@localhost) by dfw-ix5.ix.netcom.com (8.8.4/8.8.4) id DAA15883; Tue, 11 Nov 1997 03:32:00 -0600 (CST) Received: from atl-ga19-02.ix.netcom.com(205.186.178.34) by dfw-ix5.ix.netcom.com via smap (V1.3) id rma015874; Tue Nov 11 03:31:54 1997 Message-ID: <346825F9.4924796F@ix.netcom.com> Date: Tue, 11 Nov 1997 04:31:37 -0500 From: Jerry Hicks Reply-To: wghhicks@ix.netcom.com Organization: TerraEarth X-Mailer: Mozilla 4.03b8 [en] (X11; I; FreeBSD 2.2.5-STABLE i386) MIME-Version: 1.0 To: Mike Hoskins CC: freebsd-hackers@freebsd.org Subject: Re: Newest Pentium bug (fatal) References: <199711110526.WAA21873@usr02.primenet.com> <3467FC52.1C6E655B@ix.netcom.com> <346768CA.5984ED28@seidata.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Mike Hoskins wrote: > > Jerry Hicks wrote: > > > I bet the Linux porters *do* have access to the aforementioned source > > code. And probably a goodly share of other DEC resources as well. > > I use FreeBSD and Linux on a regular basis, and if this is > the case, I find it very discouraging. I've always viewed > Linux and FreeBSD as "alternative operating systems". That > is defined, by me, to be operating systems programmed by > individuals that rise above petty differences, corporate > bloat, and/or monetary concerns to have one common goal... > to program the best OS possible. Windows/MacOS/etc. seem to > be so busy fighting against each other that progress is, in > many ways, greatly hindered by their petty, greed-driven > bickering. I had always hoped (and still believe) that both > FreeBSD and Linux rose above such bickering and focussed on > the important issues of security/performance/etc. If, > however, either side were to purposefully withhold any type > of information simply to "ensure their OS does better than > the other", it would seem the guilty party has adopted a > rather Microsoft-like attitude on development. > > --- > Mike Hoskins > SEI Data Network Services > mike@seidata.com DEC has a very vocal group of Linux developers internally. I think that Mr. Hall holds a particularly important position there WRT Unix matters. I find it very difficult to believe that they are producing Linux developments without any advantage over outside developers such as FreeBSD. This can be looked at in a more positive light too. DEC might be said to be revealing internal information through a filtered channel to the freeware markets. This simply means that, if an Alpha port were ever taken on by FreeBSD, the best information would most likely be gleaned from the Linux ports. Anything that DEC would give out directly probably wouldn't be as complete as that. We *can* give them credit for having done more than any other mainstream Unix vendor. Food for thought eh? Jerry Hicks jerry_hicks@bigfoot.com From owner-freebsd-hackers Tue Nov 11 01:47:36 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id BAA12021 for hackers-outgoing; Tue, 11 Nov 1997 01:47:36 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from seidata.com (seidata.com [206.160.242.33]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id BAA12014 for ; Tue, 11 Nov 1997 01:47:29 -0800 (PST) (envelope-from mike@seidata.com) Received: from seidata.com ([208.10.211.51]) by seidata.com (8.8.7/8.8.5) with ESMTP id EAA09167; Tue, 11 Nov 1997 04:47:56 -0500 (EST) Message-ID: <34677233.598C2FD3@seidata.com> Date: Mon, 10 Nov 1997 15:44:35 -0500 From: Mike Hoskins X-Mailer: Mozilla 4.03 [en] (Win95; I) MIME-Version: 1.0 To: "Kragen \"Skewed\" Sitaker" , freebsd-hackers@freebsd.org Subject: Re: Intel Pentium Bug References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Kragen "Skewed" Sitaker wrote: > Is this intended to keep malicious people from crashing your computer? Perhaps I mis-understood the original message the script was posted in, but I thought it was plainly stated in the original (even though not much more than the script was shown in the re-post here) that the true purpose of the code was to do (quote-un-quote) "postmortem cleanup". As if to say its real target use was locating programs containing the malicious opcodes after a lockup has occurred... so as to hopefully track down the culprit. That was, at least, my understanding... and I've been known to blunder once or twice in this life. ;) Either way, this is my last post on this issue... here, at least. --- Mike Hoskins SEI Data Network Services mike@seidata.com From owner-freebsd-hackers Tue Nov 11 02:18:30 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id CAA13434 for hackers-outgoing; Tue, 11 Nov 1997 02:18:30 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from dfw-ix9.ix.netcom.com (dfw-ix9.ix.netcom.com [206.214.98.9]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id CAA13427 for ; Tue, 11 Nov 1997 02:18:27 -0800 (PST) (envelope-from wghhicks@ix.netcom.com) Received: (from smap@localhost) by dfw-ix9.ix.netcom.com (8.8.4/8.8.4) id EAA20349; Tue, 11 Nov 1997 04:17:24 -0600 (CST) Received: from atl-ga19-02.ix.netcom.com(205.186.178.34) by dfw-ix9.ix.netcom.com via smap (V1.3) id rma020345; Tue Nov 11 04:17:02 1997 Message-ID: <3468308E.5D62F17F@ix.netcom.com> Date: Tue, 11 Nov 1997 05:16:46 -0500 From: Jerry Hicks Organization: TerraEarth X-Mailer: Mozilla 4.03b8 [en] (X11; I; FreeBSD 2.2.5-STABLE i386) MIME-Version: 1.0 To: Mike Hoskins , freebsd-hackers@FreeBSD.ORG Subject: Re: Newest Pentium bug (fatal) References: <199711110526.WAA21873@usr02.primenet.com> <3467FC52.1C6E655B@ix.netcom.com> <346768CA.5984ED28@seidata.com> <346825F9.4924796F@ix.netcom.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Jerry Hicks wrote: > We *can* give them credit for having done more than any other mainstream > Unix vendor. Uhh... That came out wrong. I meant for free OS development. From owner-freebsd-hackers Tue Nov 11 05:18:25 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id FAA21505 for hackers-outgoing; Tue, 11 Nov 1997 05:18:25 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from hda.hda.com (hda-bicnet.bicnet.net [208.220.66.37]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id FAA21500 for ; Tue, 11 Nov 1997 05:18:19 -0800 (PST) (envelope-from dufault@hda.hda.com) Received: (from dufault@localhost) by hda.hda.com (8.8.5/8.8.5) id UAA20154; Mon, 10 Nov 1997 20:09:19 -0500 (EST) From: Peter Dufault Message-Id: <199711110109.UAA20154@hda.hda.com> Subject: Re: LabPC+ Driver Specifics In-Reply-To: from "Jamil J. Weatherbee" at "Nov 8, 97 09:20:15 pm" To: jamil@trojanhorse.ml.org (Jamil J. Weatherbee) Date: Mon, 10 Nov 1997 20:09:17 -0500 (EST) Cc: hackers@freebsd.org X-Mailer: ELM [version 2.4ME+ PL25 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > I am currently in the process of writing a driver for an analog input > board and am using your labpc driver as an example (I have a labpc also). > I am kind of curious about your buffer management. It appears that you are > using the onboard fifo for buffering and depending on the user to make > bio buffers available for writing out the fifo once they open the device. > If they don't make buffers available frequently enough through read() then > you have a problem. Yes, and you'll get an error from the hardware when the FIFO overruns. > Here are some questions I have, because I think your driver is good > example and I don't feel a need to make any unnecessary mistakes in design > that conversing with you could save me. > > One thing is the AD_MICRO_PERIOD_SET, does that change the frequency for > the entire board or just one channel. Is that general enough? In my case I > have 128 channels so It is going to get pretty complex managing 128 > channels at 128 different frequencies (with one clock). There is only one clock on that board. If you have (or are implementing) independent clocks you probably have (or are implementing) independent FIFOs or other memory channels and you should handle it as separate instances of the driver, i.e., as if each is a separate board. > Secondly, I don't have a fifo, however I have interrupts driven through a > 8253 chain. I assume than the best thing is for me to pick a decent fifo > size and manage it like the labpc hardware manages its fifo. Would that be > like 512*(128/8) = 8kb? The particular board is not capable of more than > 30000 samples/s. The best solution is to implement a FIFO in software and run it at a restrictive interrupt level, as Bruce has done in the SIO driver. That is the typical and most appropriate solution for that problem. Then the FIFO size can be a config (or even ioctl) time setting. > I was thinking of implementing an AD_START and AD_STOP ioctls(), or am I > missing something? I think an AD_TRIGGER is needed and you can put it in the dataacq header. That would describe what will begin the acquisition, and the default would be AD_TRIG_IMMEDIATE (that is, as soon as read). Another would be AD_TRIG_EXTERNAL (external TTL start), and a scope-like structure for trigger level and slope. I assume this is what you mean for AD_START? I see less of a need for an AD_STOP, but maybe you can describe what it would do. I see advantages to a frame description ioctl (describe the size of a frame independent of user I/O transfer size) so you could do: open ... describe frame ... set trigger ... read a real big chunk of data in a frame with multiple reads and it stops automatically ... set trigger read frame ... etc. > > I noticed , it looks like your chaining together buffers passed to your > strategy routine. Can you breifly explain what is going on there with > tqe.next (b_actf), I realize this is part of the queue management MACROS, > but I > don't think you are actually using those. I just want a qualitative > description since I am pretty unclear on the hardware level stuff of the > labpc. I should be using the queue macros. This is a basic start chain - the I/O requests are enqueued in the chain and then the done interrupt can kick off the next transfer within the interrupt. You can now use "team" or fork a process and get double buffered transfers and soak up the overhead of resuming a user process. If you do: while (read(0, buff, N) == N) ; the system must resume your process before each read whereas if two of these processes are running the next buffer will be ready to receive the data in the done interrupt, reducing the required FIFO elasticity. > If your ad channels just start spewing when you open, then why don't you > implement readselect, why just leave it to seltrue? If your trying to > read all 8 channels this just might be useful to determine which order. Specifically, they start spewing data when you issue a read. To answer your question: the typical A-D card has a single channel list, gain list, timer, etc, and so you know the order the data will arrive in since you specified the frame. A trickier board with multiple resources or a home brew system is best handled as multiple simple boards. I've begged the question, though: If a trigger ioctl is added then there should be a read select. Then you can open multiple boards and process the one that triggers first. Any system with multiple "boards" (physical or in software as I believe you plan) with independent timers per channel will also benefit from the select. Peter -- Peter Dufault (dufault@hda.com) Realtime development, Machine control, HD Associates, Inc. Safety critical systems, Agency approval From owner-freebsd-hackers Tue Nov 11 05:38:59 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id FAA22632 for hackers-outgoing; Tue, 11 Nov 1997 05:38:59 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from vinyl.quickweb.com (vinyl.quickweb.com [209.112.4.14]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id FAA22625 for ; Tue, 11 Nov 1997 05:38:56 -0800 (PST) (envelope-from mark@quickweb.com) Received: (from mark@localhost) by vinyl.quickweb.com (8.8.7/8.6.12) id IAA27254; Tue, 11 Nov 1997 08:39:02 -0500 (EST) Message-ID: <19971111083902.30210@vmunix.com> Date: Tue, 11 Nov 1997 08:39:02 -0500 From: Mark Mayo To: wghhicks@ix.netcom.com Cc: Mike Hoskins , freebsd-hackers@FreeBSD.ORG Subject: Re: Newest Pentium bug (fatal) References: <199711110526.WAA21873@usr02.primenet.com> <3467FC52.1C6E655B@ix.netcom.com> <346768CA.5984ED28@seidata.com> <346825F9.4924796F@ix.netcom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.85e In-Reply-To: <346825F9.4924796F@ix.netcom.com>; from Jerry Hicks on Tue, Nov 11, 1997 at 04:31:37AM -0500 X-Operating-System: FreeBSD 2.2.5-STABLE i386 Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Tue, Nov 11, 1997 at 04:31:37AM -0500, Jerry Hicks wrote: > Mike Hoskins wrote: > > > > Jerry Hicks wrote: > > > > > I bet the Linux porters *do* have access to the aforementioned source > > > code. And probably a goodly share of other DEC resources as well. > > > This simply means that, if an Alpha port were ever taken on by FreeBSD, > the best information would most likely be gleaned from the Linux ports. > Anything that DEC would give out directly probably wouldn't be as > complete as that. > > We *can* give them credit for having done more than any other mainstream > Unix vendor. >From my naive eyes, it would certainly appear that if FreeBSD were going to port to the Alpha platform, Linux is the place to look for "documentation". NetBSD also seems to be running fairly well on the Alpha. NetBSD is even running on the TurboLaser products, which i don't believe Linux is (I could be wrong on that one). If Terry is able to port the VM system to the alpha architecture, that would be a huge step towards a sucessful port IMHO, since a lot of the other stuff could be "borrowed" from NetBSD and Linux. Like I said, this is my naive point of view, and there's almost certainly other major obstacles in the way... :-) At any rate, it would be nice to have FreeBSD Alpha port. The other reality, of course, is that even though Alpha's are dropping like stones in price (at least the 21164PC ones..), they probably won't ever become mainstream enough to really warrant a FreeBSD port. Afterall, if I want BSD on my Alpha, I can always get it from NetBSD! -Mark P.S. The main problems I have with the Alpha's is their seemingly wildly different hardware layouts... the whole 21164PC vs. 21164A deal is quite confusing.. This debate is a perfect example - we've got X and you've got Y - unfortunately they seem to be so different that we can't even use the same bootstrapping code.... argghh.. Frustration... > > Food for thought eh? > > Jerry Hicks > jerry_hicks@bigfoot.com -- ------------------------------------------------------------------------ Mark Mayo mark@vmunix.com RingZero Comp. http://www.vmunix.com/mark finger mark@vmunix.com for my PGP key and GCS code ------------------------------------------------------------------------ Win95/NT - 32 bit extensions and a graphical shell for a 16 bit patch to an an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition. -UGU From owner-freebsd-hackers Tue Nov 11 07:38:49 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id HAA29803 for hackers-outgoing; Tue, 11 Nov 1997 07:38:49 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from sasami.jurai.net (winter@sasami.jurai.net [207.96.1.17]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id HAA29798 for ; Tue, 11 Nov 1997 07:38:41 -0800 (PST) (envelope-from winter@jurai.net) Received: from localhost (winter@localhost) by sasami.jurai.net (8.8.7/8.8.7) with SMTP id KAA04554; Tue, 11 Nov 1997 10:37:47 -0500 (EST) Date: Tue, 11 Nov 1997 10:37:47 -0500 (EST) From: "Matthew N. Dodd" To: Don Lewis cc: Terry Lambert , hackers@FreeBSD.ORG Subject: Re: x86 gods; advice? Suggestions? In-Reply-To: <199711101135.DAA25891@salsa.gv.tsc.tdk.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Mon, 10 Nov 1997, Don Lewis wrote: > On Nov 9, 10:32am, Terry Lambert wrote: > } Subject: Re: x86 gods; advice? Suggestions? > } I think it's > } because they [Sun] don't sell any machines with PCI slots yet. > > Yes they do. There's the Ultra 30 workstation and the Ultra Enterprise > 150 and 450 servers. They also sell ATX format UltraSPARC motherboards. And the PCI I/O cards for the Ultra Enterprise [3-6]000 series. According to Sun, the fastest SCSI interface for the UE series is not their own Ultra SBUS card, but the PCI Adaptec 2940UW. /* Matthew N. Dodd | A memory retaining a love you had for life winter@jurai.net | As cruel as it seems nothing ever seems to http://www.jurai.net/~winter | go right - FLA M 3.1:53 */ From owner-freebsd-hackers Tue Nov 11 08:25:55 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id IAA03280 for hackers-outgoing; Tue, 11 Nov 1997 08:25:55 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from usr03.primenet.com (tlambert@usr03.primenet.com [206.165.6.203]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id IAA03271 for ; Tue, 11 Nov 1997 08:25:52 -0800 (PST) (envelope-from tlambert@usr03.primenet.com) Received: (from tlambert@localhost) by usr03.primenet.com (8.8.5/8.8.5) id JAA18808; Tue, 11 Nov 1997 09:25:36 -0700 (MST) From: Terry Lambert Message-Id: <199711111625.JAA18808@usr03.primenet.com> Subject: Re: Newest Pentium bug (fatal) To: mark@vmunix.com (Mark Mayo) Date: Tue, 11 Nov 1997 16:25:35 +0000 (GMT) Cc: wghhicks@ix.netcom.com, mike@seidata.com, freebsd-hackers@FreeBSD.ORG In-Reply-To: <19971111083902.30210@vmunix.com> from "Mark Mayo" at Nov 11, 97 08:39:02 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > From my naive eyes, it would certainly appear that if FreeBSD were > going to port to the Alpha platform, Linux is the place to look > for "documentation". NetBSD also seems to be running fairly well > on the Alpha. NetBSD is even running on the TurboLaser > products, which i don't believe Linux is (I could be wrong on that > one). > > If Terry is able to port the VM system to the alpha architecture, > that would be a huge step towards a sucessful port IMHO, since > a lot of the other stuff could be "borrowed" from NetBSD and Linux. It's not that hard a port; as John Dyson pointed out the last time this came up, it's fairly portable, so I don't deserve a hell of a lot of credit for it. What isn't portable is the use of the VM system by other systems in the kernel, starting with the FS. That's mostly NetBSD/FreeBSD integration, and it's an ongoing problem that gets worse and worse as they both diverge from Lite2 without consideration for the union of issues that both camps are trying to address. > At any rate, it would be nice to have FreeBSD Alpha port. The other > reality, of course, is that even though Alpha's are dropping like > stones in price (at least the 21164PC ones..), they probably won't > ever become mainstream enough to really warrant a FreeBSD port. > Afterall, if I want BSD on my Alpha, I can always get it from NetBSD! The point is not just to have BSD, but to leverage technological advance; FreeBSD's VM is more advanced, it should go in. FreeBSD's SMP work is more advanced, it should go in. NetBSD's build tree structure is cross platform, it should go in. FreeBSD's ports system is more advanced, it should go in. And so on. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Tue Nov 11 08:43:17 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id IAA04245 for hackers-outgoing; Tue, 11 Nov 1997 08:43:17 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from goof.com (goof.com [128.173.247.211]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id IAA04232 for ; Tue, 11 Nov 1997 08:43:07 -0800 (PST) (envelope-from mmead@goof.com) Received: (qmail 2810 invoked by uid 10000); 11 Nov 1997 16:42:09 -0000 Message-ID: <19971111114209.47857@goof.com> Date: Tue, 11 Nov 1997 11:42:09 -0500 From: "matthew c. mead" To: hackers@freebsd.org Subject: nfs read problems Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84 Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I'm having some severe problems with mounting an nfs filesystem and using it to store applications. From what I can tell, it works fine via TCP NFS, but unbelievably slow. When I don't specify TCP, and let it use UDP, it just breaks completely. For instance, when I'm running an application stored on the nfs server, I see this on the wire repeatedly, and the application never executes: galen.narnia.math.vt.edu -> calvin.narnia.math.vt.edu NFS C READ3 FH=DC3D at 0 for 8192 calvin.narnia.math.vt.edu -> galen.narnia.math.vt.edu NFS R READ3 OK (8192 bytes) calvin.narnia.math.vt.edu -> galen.narnia.math.vt.edu UDP continuation ID=60083 calvin.narnia.math.vt.edu -> galen.narnia.math.vt.edu UDP continuation ID=60083 calvin.narnia.math.vt.edu -> galen.narnia.math.vt.edu UDP continuation ID=60083 calvin.narnia.math.vt.edu -> galen.narnia.math.vt.edu UDP continuation ID=60083 calvin.narnia.math.vt.edu -> galen.narnia.math.vt.edu UDP continuation ID=60083 Each time this set of packets is seen, the filehandle is the same, yet it's reading 8192 bytes once every 10-15 seconds. This is a 100Mbit wire, so it should be loading almost instantly. Is there a possibility this is an ethernet card problem? Thanks for any help! -matt PS - please reply directly if possible - thanks -- Matthew C. Mead mmead@goof.com http://www.goof.com/~mmead/ From owner-freebsd-hackers Tue Nov 11 10:05:37 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id KAA09597 for hackers-outgoing; Tue, 11 Nov 1997 10:05:37 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from implode.root.com (implode.root.com [198.145.90.17]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id KAA09587 for ; Tue, 11 Nov 1997 10:05:33 -0800 (PST) (envelope-from root@implode.root.com) Received: from implode.root.com (localhost [127.0.0.1]) by implode.root.com (8.8.5/8.8.5) with ESMTP id KAA26767; Tue, 11 Nov 1997 10:07:15 -0800 (PST) Message-Id: <199711111807.KAA26767@implode.root.com> To: "matthew c. mead" cc: hackers@FreeBSD.ORG Subject: Re: nfs read problems In-reply-to: Your message of "Tue, 11 Nov 1997 11:42:09 EST." <19971111114209.47857@goof.com> From: David Greenman Reply-To: dg@root.com Date: Tue, 11 Nov 1997 10:07:14 -0800 Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > I'm having some severe problems with mounting an nfs >filesystem and using it to store applications. From what I can >tell, it works fine via TCP NFS, but unbelievably slow. When I >don't specify TCP, and let it use UDP, it just breaks completely. >For instance, when I'm running an application stored on the >nfs server, I see this on the wire repeatedly, and the >application never executes: > > >galen.narnia.math.vt.edu -> calvin.narnia.math.vt.edu NFS C READ3 FH=DC3D at 0 for 8192 >calvin.narnia.math.vt.edu -> galen.narnia.math.vt.edu NFS R READ3 OK (8192 bytes) >calvin.narnia.math.vt.edu -> galen.narnia.math.vt.edu UDP continuation ID=60083 >calvin.narnia.math.vt.edu -> galen.narnia.math.vt.edu UDP continuation ID=60083 >calvin.narnia.math.vt.edu -> galen.narnia.math.vt.edu UDP continuation ID=60083 >calvin.narnia.math.vt.edu -> galen.narnia.math.vt.edu UDP continuation ID=60083 >calvin.narnia.math.vt.edu -> galen.narnia.math.vt.edu UDP continuation ID=60083 > > Each time this set of packets is seen, the filehandle is >the same, yet it's reading 8192 bytes once every 10-15 seconds. >This is a 100Mbit wire, so it should be loading almost instantly. >Is there a possibility this is an ethernet card problem? What ethernet card are you using? -DG David Greenman Core-team/Principal Architect, The FreeBSD Project From owner-freebsd-hackers Tue Nov 11 10:15:31 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id KAA10183 for hackers-outgoing; Tue, 11 Nov 1997 10:15:31 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from iafnl.es.iaf.nl (uucp@iafnl.es.iaf.nl [195.108.17.20]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id KAA10177 for ; Tue, 11 Nov 1997 10:15:28 -0800 (PST) (envelope-from wilko@yedi.iaf.nl) Received: by iafnl.es.iaf.nl with UUCP id AA23397 (5.67b/IDA-1.5 for freebsd-hackers@FreeBSD.ORG); Tue, 11 Nov 1997 19:14:34 +0100 Received: (from wilko@localhost) by yedi.iaf.nl (8.8.5/8.6.12) id WAA03489; Mon, 10 Nov 1997 22:43:20 +0100 (MET) From: Wilko Bulte Message-Id: <199711102143.WAA03489@yedi.iaf.nl> Subject: Re: Newest Pentium bug (fatal) To: jkh@time.cdrom.com (Jordan K. Hubbard) Date: Mon, 10 Nov 1997 22:43:20 +0100 (MET) Cc: tlambert@primenet.com, helbig@Informatik.BA-Stuttgart.DE, freebsd-hackers@FreeBSD.ORG In-Reply-To: <16846.879194422@time.cdrom.com> from "Jordan K. Hubbard" at Nov 10, 97 12:40:22 pm X-Organisation: Private FreeBSD site - Arnhem, The Netherlands X-Pgp-Info: PGP public key at 'finger wilko@freefall.freebsd.org' X-Mailer: ELM [version 2.4 PL24 ME8a] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk As Jordan K. Hubbard wrote... > > > Perhaps if the source tree were reorganized to be more multiple > > architecture friendly, progress would speed up? > > No, if we had more people with ALPHAs and who actually understood the > design of the "Miata" it would help more than anything else. Even You might consider following the port-alpha list of the NetBSD effort. It has become quite clear to me that each AXP machinetype is really an individual, so there is a lot to do for each boxtype. It is not nearly as simple as people hope (myself included BTW) PCs, with all their quirks, at least have quite some commonality to offer. Wilko _ ______________________________________________________________________ | / o / / _ Bulte email: wilko@yedi.iaf.nl http://www.tcja.nl/~wilko |/|/ / / /( (_) Arnhem, The Netherlands - Do, or do not. There is no 'try' ---------------- Support your local daemons: run [Free,Net]BSD Unix --Yoda From owner-freebsd-hackers Tue Nov 11 10:16:10 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id KAA10299 for hackers-outgoing; Tue, 11 Nov 1997 10:16:10 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from iafnl.es.iaf.nl (uucp@iafnl.es.iaf.nl [195.108.17.20]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id KAA10256 for ; Tue, 11 Nov 1997 10:16:03 -0800 (PST) (envelope-from wilko@yedi.iaf.nl) Received: by iafnl.es.iaf.nl with UUCP id AA23424 (5.67b/IDA-1.5 for hackers@FreeBSD.ORG); Tue, 11 Nov 1997 19:15:49 +0100 Received: (from wilko@localhost) by yedi.iaf.nl (8.8.5/8.6.12) id WAA03499; Mon, 10 Nov 1997 22:44:44 +0100 (MET) From: Wilko Bulte Message-Id: <199711102144.WAA03499@yedi.iaf.nl> Subject: Re: x86 gods; advice? Suggestions? To: tlambert@primenet.com (Terry Lambert) Date: Mon, 10 Nov 1997 22:44:44 +0100 (MET) Cc: Don.Lewis@tsc.tdk.com, tlambert@primenet.com, hackers@FreeBSD.ORG In-Reply-To: <199711102022.NAA13831@usr05.primenet.com> from "Terry Lambert" at Nov 10, 97 08:22:27 pm X-Organisation: Private FreeBSD site - Arnhem, The Netherlands X-Pgp-Info: PGP public key at 'finger wilko@freefall.freebsd.org' X-Mailer: ELM [version 2.4 PL24 ME8a] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk As Terry Lambert wrote... > > > } I think it's > > } because they [Sun] don't sell any machines with PCI slots yet. > > > > Yes they do. There's the Ultra 30 workstation and the Ultra Enterprise > > 150 and 450 servers. They also sell ATX format UltraSPARC motherboards. > > What do they sell for, so I can draw a distinction between "they > manufacture" and "they sell"... ;-). > > Or alternately, I can rush out and buy one (I have been delaying in > the hope I can find a used two processor SPARC cheap). I think there is an overview of PCI/Sun related info on http://www.sun.com/pci (or something very similar) Wilko _ ______________________________________________________________________ | / o / / _ Bulte email: wilko@yedi.iaf.nl http://www.tcja.nl/~wilko |/|/ / / /( (_) Arnhem, The Netherlands - Do, or do not. There is no 'try' ---------------- Support your local daemons: run [Free,Net]BSD Unix --Yoda From owner-freebsd-hackers Tue Nov 11 10:17:21 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id KAA10389 for hackers-outgoing; Tue, 11 Nov 1997 10:17:21 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from goof.com (goof.com [128.173.247.211]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id KAA10372 for ; Tue, 11 Nov 1997 10:17:12 -0800 (PST) (envelope-from mmead@goof.com) Received: (qmail 3264 invoked by uid 10000); 11 Nov 1997 18:16:00 -0000 Message-ID: <19971111131600.34281@goof.com> Date: Tue, 11 Nov 1997 13:16:00 -0500 From: "matthew c. mead" To: dg@root.com Cc: hackers@FreeBSD.ORG Subject: Re: nfs read problems References: <19971111114209.47857@goof.com> <199711111807.KAA26767@implode.root.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84 In-Reply-To: <199711111807.KAA26767@implode.root.com>; from David Greenman on Tue, Nov 11, 1997 at 10:07:14AM -0800 Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Tue, Nov 11, 1997 at 10:07:14AM -0800, David Greenman wrote: > > I'm having some severe problems with mounting an nfs > >filesystem and using it to store applications. From what I can > >tell, it works fine via TCP NFS, but unbelievably slow. When I > >don't specify TCP, and let it use UDP, it just breaks completely. > >For instance, when I'm running an application stored on the > >nfs server, I see this on the wire repeatedly, and the > >application never executes: > >galen.narnia.math.vt.edu -> calvin.narnia.math.vt.edu NFS C READ3 FH=DC3D at 0 for 8192 > >calvin.narnia.math.vt.edu -> galen.narnia.math.vt.edu NFS R READ3 OK (8192 bytes) > >calvin.narnia.math.vt.edu -> galen.narnia.math.vt.edu UDP continuation ID=60083 > >calvin.narnia.math.vt.edu -> galen.narnia.math.vt.edu UDP continuation ID=60083 > >calvin.narnia.math.vt.edu -> galen.narnia.math.vt.edu UDP continuation ID=60083 > >calvin.narnia.math.vt.edu -> galen.narnia.math.vt.edu UDP continuation ID=60083 > >calvin.narnia.math.vt.edu -> galen.narnia.math.vt.edu UDP continuation ID=60083 > > Each time this set of packets is seen, the filehandle is > >the same, yet it's reading 8192 bytes once every 10-15 seconds. > >This is a 100Mbit wire, so it should be loading almost instantly. > >Is there a possibility this is an ethernet card problem? > What ethernet card are you using? Sorry - forgot to include that vital info. It's a 3c905. I've gotten mail from one person that's said that's probably my problem. -matt -- Matthew C. Mead mmead@goof.com http://www.goof.com/~mmead/ From owner-freebsd-hackers Tue Nov 11 11:04:04 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id LAA13734 for hackers-outgoing; Tue, 11 Nov 1997 11:04:04 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from iafnl.es.iaf.nl (uucp@iafnl.es.iaf.nl [195.108.17.20]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id LAA13680 for ; Tue, 11 Nov 1997 11:03:55 -0800 (PST) (envelope-from wilko@yedi.iaf.nl) Received: by iafnl.es.iaf.nl with UUCP id AA25216 (5.67b/IDA-1.5 for freebsd-hackers@FreeBSD.ORG); Tue, 11 Nov 1997 20:03:39 +0100 Received: (from wilko@localhost) by yedi.iaf.nl (8.8.5/8.6.12) id TAA01376; Tue, 11 Nov 1997 19:29:32 +0100 (MET) From: Wilko Bulte Message-Id: <199711111829.TAA01376@yedi.iaf.nl> Subject: Re: Newest Pentium bug (fatal) To: jkh@time.cdrom.com (Jordan K. Hubbard) Date: Tue, 11 Nov 1997 19:29:32 +0100 (MET) Cc: tlambert@primenet.com, helbig@Informatik.BA-Stuttgart.DE, freebsd-hackers@FreeBSD.ORG In-Reply-To: <17165.879196838@time.cdrom.com> from "Jordan K. Hubbard" at Nov 10, 97 01:20:38 pm X-Organisation: Private FreeBSD site - Arnhem, The Netherlands X-Pgp-Info: PGP public key at 'finger wilko@freefall.freebsd.org' X-Mailer: ELM [version 2.4 PL24 ME8a] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk As Jordan K. Hubbard wrote... > > > Well, since I own a "Multia" and not a "Miata", I don't really get > > how understanding the "Miata" would help me port to the "Multia", > > so perhaps you could explain it to me... > > The other people in the ALPHA project have Miatas. Your Multia is > thus of little concern to them. > > > As SEF would say, "Pot. Kettle. Black.". > > > > There's a very simple way to keep me from grinding axes: take them > > away from me, leaving me nothing to grind. If you weren't always > > such an immovable object, then I wouldn't have to try to be an > > irresistable force to get you to move... > > Terry, when will you learn? People aren't just sitting on their > thumbs waiting for Terry The Great Motivator to kick them into action, > there are other major stumbling blocks in the way which are > drastically impeding progress, one such being the fact that Digital > has been completely and totally unable to provide *any* technical > documentation on these machines! NetBSD also doesn't run on them, so Please stop bitching. What do you need for Miata docs? I can look at work (yes, at Digital) to see what publically redistributable docs I can come up with. Just tell me exactly what boards/machines you have and I'll give it my best shot. > we can't even look "next door" for a peek at what's going on under > their hood, so to speak, and the fact that they run DUX is of little > use since DUX doesn't come with source code. You have to sign with your own blood to even take a look at the source... > If you really want to help then either get some documentation out of > Digital using your direct pipeline to God (of course Terry talks > directly to God, hasn't everyone here realized that by now? ;-) or > get us a free source code license to Digital Unix so that we can > crib code from them. Thank you, no need to call me God. Wilko will do ;-) Wilko _ ______________________________________________________________________ | / o / / _ Bulte email: wilko@yedi.iaf.nl http://www.tcja.nl/~wilko |/|/ / / /( (_) Arnhem, The Netherlands - Do, or do not. There is no 'try' ---------------- Support your local daemons: run [Free,Net]BSD Unix --Yoda From owner-freebsd-hackers Tue Nov 11 11:08:28 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id LAA14047 for hackers-outgoing; Tue, 11 Nov 1997 11:08:28 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from iafnl.es.iaf.nl (uucp@iafnl.es.iaf.nl [195.108.17.20]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id LAA14040 for ; Tue, 11 Nov 1997 11:08:24 -0800 (PST) (envelope-from wilko@yedi.iaf.nl) Received: by iafnl.es.iaf.nl with UUCP id AA25222 (5.67b/IDA-1.5 for freebsd-hackers@FreeBSD.ORG); Tue, 11 Nov 1997 20:04:18 +0100 Received: (from wilko@localhost) by yedi.iaf.nl (8.8.5/8.6.12) id TAA01415; Tue, 11 Nov 1997 19:34:44 +0100 (MET) From: Wilko Bulte Message-Id: <199711111834.TAA01415@yedi.iaf.nl> Subject: Re: Newest Pentium bug (fatal) To: wghhicks@ix.netcom.com Date: Tue, 11 Nov 1997 19:34:44 +0100 (MET) Cc: tlambert@primenet.com, jkh@time.cdrom.com, helbig@Informatik.BA-Stuttgart.DE, freebsd-hackers@FreeBSD.ORG In-Reply-To: <3467FC52.1C6E655B@ix.netcom.com> from "Jerry Hicks" at Nov 11, 97 01:33:54 am X-Organisation: Private FreeBSD site - Arnhem, The Netherlands X-Pgp-Info: PGP public key at 'finger wilko@freefall.freebsd.org' X-Mailer: ELM [version 2.4 PL24 ME8a] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk As Jerry Hicks wrote... > > > > If you really want to help then either get some documentation out of > > Digital using your direct pipeline to God (of course Terry talks > > directly to God, hasn't everyone here realized that by now? ;-) or > > get us a free source code license to Digital Unix so that we can > > crib code from them. > > > > Wonder if any lack of enthusiasm for FreeBSD from DEC has anything to do > with Jon "Mad-Dog" Hall's Linux activities? > > I bet the Linux porters *do* have access to the aforementioned source > code. And probably a goodly share of other DEC resources as well. They better keep their mouths VERY shut in that case. Working from D-Unix source to include things in freely distributable Unix source code is most likely a really fast way to resign from Digital. Getting access to D-Unix source code involves signatures here and there. Wilko (who has checked this inside Digital) _ ______________________________________________________________________ | / o / / _ Bulte email: wilko@yedi.iaf.nl http://www.tcja.nl/~wilko |/|/ / / /( (_) Arnhem, The Netherlands - Do, or do not. There is no 'try' ---------------- Support your local daemons: run [Free,Net]BSD Unix --Yoda From owner-freebsd-hackers Tue Nov 11 11:46:21 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id LAA16858 for hackers-outgoing; Tue, 11 Nov 1997 11:46:21 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from guacari.udem.edu.co ([206.114.14.85]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id LAA16615 for ; Tue, 11 Nov 1997 11:43:09 -0800 (PST) (envelope-from lgomez@guacari.udem.edu.co) Received: from localhost (lgomez@localhost) by guacari.udem.edu.co (8.8.5/8.8.5) with SMTP id JAA05826 for ; Tue, 11 Nov 1997 09:38:49 -0500 (EST) Date: Tue, 11 Nov 1997 09:38:48 -0500 (EST) From: Lucas Adri n G¢mez Bland¢n To: freebsd-hackers@freebsd.org Subject: Problems with passwd utility. Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by hub.freebsd.org id LAA16850 Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi everyone, I'm install FreeBSD 2.1.7.1 (STABLE), it was a piece of cake!, but when a user call "passwd" he receive "Permision denied". What's wrong????. Thanks for all! bye Lucas Adri n G¢mez Bland¢n Panel de Control Asesorias Inform ticas. From owner-freebsd-hackers Tue Nov 11 12:31:21 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id MAA19926 for hackers-outgoing; Tue, 11 Nov 1997 12:31:21 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from ns.frihet.com (frihet.bayarea.net [205.219.92.1]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id MAA19914; Tue, 11 Nov 1997 12:31:16 -0800 (PST) (envelope-from tweten@ns.frihet.com) Received: from ns.frihet.com (localhost [127.0.0.1]) by ns.frihet.com (8.8.7/8.8.7) with ESMTP id MAA07279; Tue, 11 Nov 1997 12:30:28 -0800 (PST) (envelope-from tweten@ns.frihet.com) Message-Id: <199711112030.MAA07279@ns.frihet.com> X-Mailer: exmh version 2.0zeta 7/24/97 Reply-To: "David E. Tweten" To: Guido van Rooij cc: freebsd-mobile@FreeBSD.ORG, FreeBSD-hackers@FreeBSD.ORG (FreeBSD-hackers) Subject: Re: multi sector io on IBM-DMCA-21440 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 11 Nov 1997 12:30:28 -0800 From: "David E. Tweten" Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk guido@gvr.org said: >IS anyone using multi-sector IO successfully on his laptop? I am, on an NEC 6030X (at home), and on an NEC 6050MX (at work). >When I would enable multi-sector io, the filesystem is severely >corrupted (without the driver giving any errors at all.) I configured >it with flas 0x80ff80ff. I've had no such problem. My equivalent boot messages are: wdc0 at 0x1f0-0x1f7 irq 14 on isa wdc0: unit 0 (wd0): , 32-bit, multi-block-16 wd0: 1378MB (2822400 sectors), 2800 cyls, 16 heads, 63 S/T, 512 B/S And my appropriate kernel config lines are: controller wdc0 at isa0 port "IO_WD1" bio irq 14 vector wdintr disk wd0 at wdc0 drive 0 flags 0x80ff disk wd1 at wdc0 drive 1 flags 0x80ff device wcd0 It seems the only difference in our setups is that I put the flags on the device declaration while you put them on the controller declaration (and, of course, our laptops are made by different manufacturors). I have no idea why mine works and yours doesn't, but at least this is more data for you. -- David E. Tweten | 2047-bit PGP fingerprint: | tweten@frihet.com 12141 Atrium Drive | E9 59 E7 5C 6B 88 B8 90 | tweten@and.com Saratoga, CA 95070-3162 | 65 30 2A A4 A0 BC 49 AE | (408) 446-4131 Those who make good products sell products; those who don't, sell solutions. From owner-freebsd-hackers Tue Nov 11 12:47:39 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id MAA21401 for hackers-outgoing; Tue, 11 Nov 1997 12:47:39 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from out1.ibm.net (out1.ibm.net [165.87.194.252]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id MAA21391 for ; Tue, 11 Nov 1997 12:47:30 -0800 (PST) (envelope-from mouth@ibm.net) Received: from slip129-37-53-153.ca.us.ibm.net (slip129-37-53-153.ca.us.ibm.net [129.37.53.153]) by out1.ibm.net (8.8.5/8.6.9) with SMTP id UAA101086; Tue, 11 Nov 1997 20:45:57 GMT From: mouth@ibm.net (John Kelly) To: Bruce Evans Cc: hackers@freebsd.org Subject: Status of 650 UART support Date: Tue, 11 Nov 1997 21:47:13 GMT Message-ID: <3468ce08.353607@smtp-gw01.ny.us.ibm.net> References: <199711111110.DAA15487@hub.freebsd.org> In-Reply-To: <199711111110.DAA15487@hub.freebsd.org> X-Mailer: Forte Agent 1.01/16.397 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by hub.freebsd.org id MAA21396 Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Tue, 11 Nov 1997 03:10:02 -0800 (PST), Bruce Evans wrote: > > /kernel: sio2: 40 more interrupt-level buffer overflows (total 828) > > This message is unusual. It means that the system is overloaded with > interrupt processing. Apparently the modem can keep up without input > flow control (into it), but FreeBSD can't. I'm getting that "interrupt-level buffer overflow" message when I use the 650 UART support. As long as I run the UARTs in 550 compatibility mode, they work fine. My kernel is 3.0-971108-SNAP. I've looked at the source in sio.c and I see where the 650 auto CTS/RTS flow control is turned on, but I've made little other progress towards comprehending sio.c >static char const * const error_desc[] = {. > "silo overflow", > "interrupt-level buffer overflow", > "tty-level buffer overflow", >}; Can anyone explain the difference between these three types of overflows? John From owner-freebsd-hackers Tue Nov 11 13:27:56 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id NAA24262 for hackers-outgoing; Tue, 11 Nov 1997 13:27:56 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from dyson.iquest.net (dyson.iquest.net [198.70.144.127]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id NAA24256 for ; Tue, 11 Nov 1997 13:27:48 -0800 (PST) (envelope-from dyson@dyson.iquest.net) Received: (from root@localhost) by dyson.iquest.net (8.8.7/8.8.5) id QAA03485; Tue, 11 Nov 1997 16:26:27 -0500 (EST) From: "John S. Dyson" Message-Id: <199711112126.QAA03485@dyson.iquest.net> Subject: Re: Newest Pentium bug (fatal) In-Reply-To: <199711110526.WAA21873@usr02.primenet.com> from Terry Lambert at "Nov 11, 97 05:26:49 am" To: tlambert@primenet.com (Terry Lambert) Date: Tue, 11 Nov 1997 16:26:27 -0500 (EST) Cc: jkh@time.cdrom.com, tlambert@primenet.com, helbig@Informatik.BA-Stuttgart.DE, freebsd-hackers@FreeBSD.ORG 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-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Terry Lambert said: > > BTW: it's not the people who talk to God you have to worry about, it's > the people who claim God talks to them, and that somehow ennobles their > position in any discussion. > Well, I'll tell ya -- God consults with me before making decisions :-). -- John dyson@freebsd.org jdyson@nc.com From owner-freebsd-hackers Tue Nov 11 14:02:57 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id OAA26732 for hackers-outgoing; Tue, 11 Nov 1997 14:02:57 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from trojanhorse.ml.org (mdean.vip.best.com [206.86.94.101]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id OAA26726 for ; Tue, 11 Nov 1997 14:02:50 -0800 (PST) (envelope-from jamil@trojanhorse.ml.org) Received: from localhost (jamil@localhost) by trojanhorse.ml.org (8.8.7/8.8.5) with SMTP id OAA00372; Tue, 11 Nov 1997 14:02:32 -0800 (PST) Date: Tue, 11 Nov 1997 14:02:32 -0800 (PST) From: "Jamil J. Weatherbee" To: Peter Dufault cc: hackers@freebsd.org Subject: Re: LabPC+ Driver Specifics In-Reply-To: <199711110109.UAA20154@hda.hda.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Can you possibly take a glance at my source in a few days? > There is only one clock on that board. does that mean if you say set AD_MICRO_PERIOD = 10000 and you are reading from 4 of the 8 channels then really each channel is only getting 25 readings per second. (I can't remember of the labpc if internally multiplexed like my board) > > If you have (or are implementing) independent clocks you probably have > (or are implementing) independent FIFOs or other memory channels > and you should handle it as separate instances of the driver, i.e., > as if each is a separate board. Not possible (there is only one clock) and any drivers would have to be cooperating with each other So data acquisiton doesn't start on a labpc channel until the _first_ read, then it is continuous until closing? I was going to have my channels when open not spew any data. when you ioctl() AD_START they start to read at the MICRO_PERIOD rate. when you AD_STOP they stop spewing. Of course if each has its own virtual clock this might not be neccessary. That was my problem in a multiplexed system say you have 3 channels open. channel 1 wants 10hz signal channel 2 wants 20hz signal channel 3 wants 30hz signal then for me you have to do some pretty fancy scheduling stuff and run the 8253 at 60 hz having it go through a scheduling list on each interrupt of which channel to read. Can you explain what the concept of frame means to you in this context? I am currently chaining together each buffer as it comes in and biodone() it when i am finished filling it up (and I AM using QUEUE macros, i finally figured out you were using the structures in your own kind of hacked up way which is fine).. I fear that the labpc can get 8 readings on one interrupt wheras I really only have one port but it is double multiplexed (reading is the two step process of setting a multilplexer address, and letting that settle for 1 click then (thus the external multiplexer signal) then starting a conversion going a click (always more than the 30microsecond conversion time) and reading the result. if I want 48 channels at 10 samples/sec each my clock rate is 960hz for instance. From owner-freebsd-hackers Tue Nov 11 15:03:06 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id PAA01406 for hackers-outgoing; Tue, 11 Nov 1997 15:03:06 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from DNS.Lamb.net (root@DNS.Lamb.net [207.90.181.1]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id PAA01395 for ; Tue, 11 Nov 1997 15:03:00 -0800 (PST) (envelope-from ulf@Gatekeeper.Alameda.net) Received: (from uucp@localhost) by DNS.Lamb.net (8.8.6/8.8.6) id PAA13759 for ; Tue, 11 Nov 1997 15:03:00 -0800 (PST) Received: from gatekeeper.Alameda.net(207.90.181.2) via SMTP by DNS.Lamb.net, id smtpd013757; Tue Nov 11 15:02:57 1997 Received: (from ulf@localhost) by Gatekeeper.Alameda.net (8.8.6/8.7.6) id PAA14867 for hackers@freebsd.org; Tue, 11 Nov 1997 15:02:55 -0800 (PST) From: Ulf Zimmermann Message-Id: <199711112302.PAA14867@Gatekeeper.Alameda.net> Subject: Perl 5.004 To: hackers@freebsd.org Date: Tue, 11 Nov 1997 15:02:55 -0800 (PST) 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-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Anyone has idea why this happens with the port of perl5.00401 and 5.00404: Gatekeeper root local/mrtg # ./mrtg.test mrtg.cfg.test (null): Undefined symbol "___inet_ntoa" called from perl5.00404:/usr/local/lib/perl5/i386-freebsd/5.00404/auto/Socket/Socket.so at 0x8127110 I tried it with the port of Perl5, the package for perl5.004 and I patched the port to use the 5.00404 source. All the same results. Perl 5.003 works fine. This is on 2.2.2R Ulf. --------------------------------------------------------------------- Ulf Zimmermann, 1525 Pacific Ave., Alameda, CA-94501, #: 510-769-2936 Alameda Networks, Inc. | http://www.Alameda.net | Fax#: 510-521-5073 From owner-freebsd-hackers Tue Nov 11 15:11:09 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id PAA01994 for hackers-outgoing; Tue, 11 Nov 1997 15:11:09 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: (from jmb@localhost) by hub.freebsd.org (8.8.7/8.8.7) id PAA01942; Tue, 11 Nov 1997 15:10:06 -0800 (PST) (envelope-from jmb) From: "Jonathan M. Bresler" Message-Id: <199711112310.PAA01942@hub.freebsd.org> Subject: Re: Newest Pentium bug (fatal) To: dyson@FreeBSD.ORG Date: Tue, 11 Nov 1997 15:10:05 -0800 (PST) Cc: tlambert@primenet.com, jkh@time.cdrom.com, helbig@Informatik.BA-Stuttgart.DE, freebsd-hackers@FreeBSD.ORG In-Reply-To: <199711112126.QAA03485@dyson.iquest.net> from "John S. Dyson" at Nov 11, 97 04:26:27 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk John S. Dyson wrote: > > Terry Lambert said: > > > > BTW: it's not the people who talk to God you have to worry about, it's > > the people who claim God talks to them, and that somehow ennobles their > > position in any discussion. > > > Well, I'll tell ya -- God consults with me before making decisions :-). and i though that VM was hard..... ;) jmb From owner-freebsd-hackers Tue Nov 11 15:34:38 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id PAA03865 for hackers-outgoing; Tue, 11 Nov 1997 15:34:38 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from kinclaith.pdl.cs.cmu.edu (KINCLAITH.PDL.CS.CMU.EDU [128.2.189.18]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id PAA03845 for ; Tue, 11 Nov 1997 15:34:30 -0800 (PST) (envelope-from dpetrou@kinclaith.pdl.cs.cmu.edu) Message-Id: <199711112334.PAA03845@hub.freebsd.org> Subject: Why no priority check before need_resched() in wakeup()? To: freebsd-hackers@freebsd.org Date: Tue, 11 Nov 1997 18:34:12 -0500 (EST) From: David Petrou X-Mailer: ELM [version 2.4 PL25-40] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Inside wakeup() and wakeup_one() there's a section of code with a comment that reads: /* OPTIMIZED EXPANSION OF setrunnable(p); */. This piece of code (among other things) marks a process as runnable and calls setrunqueue(). It also unconditionally calls need_resched() so that the scheduler will be invoked when leaving the kernel. My question is this: Why does this expansion of setrunnable() NOT check to see if the process's priority is better than the priority of the currently running process before calling need_resched()? If you look at the code for setrunnable(), you'll see that the check is there. Thanks, David From owner-freebsd-hackers Tue Nov 11 16:30:44 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id QAA07721 for hackers-outgoing; Tue, 11 Nov 1997 16:30:44 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from lafcol (lafcol.lafayette.edu [139.147.8.5]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id QAA07715 for ; Tue, 11 Nov 1997 16:30:41 -0800 (PST) (envelope-from knollm@lafcol.lafayette.edu) Received: from believer by lafcol (SMI-8.6/SMI-SVR4) id TAA11796; Tue, 11 Nov 1997 19:29:23 -0500 Message-Id: <3.0.32.19971111192821.009d1730@lafcol.lafayette.edu> X-Sender: knollm@lafcol.lafayette.edu X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Tue, 11 Nov 1997 19:29:49 -0500 To: hackers@freebsd.org From: Michael Knoll Subject: Ethernet packet generation Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Is there a way to generate an ethernet packet, with an unsupported protocol through a user level program? I attempted to generate an ethernet packet by opening a socket by calling socket(AF_UNSPEC, SOCK_RAW, PF_UNSPEC), and it fails with a protocol unsupported. Is there a way using standard socket calls to write ethernet packets? If not, is there any way to do it? Any source code as examples? Thanks Michael From owner-freebsd-hackers Tue Nov 11 17:30:14 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id RAA13019 for hackers-outgoing; Tue, 11 Nov 1997 17:30:14 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from cynic.portal.ca (root@cynic.portal.ca [204.174.36.7]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id RAA13014 for ; Tue, 11 Nov 1997 17:30:11 -0800 (PST) (envelope-from cjs@portal.ca) Received: from localhost ([[UNIX: localhost]]) by cynic.portal.ca (8.8.5/8.8.5) with SMTP id RAA01462; Tue, 11 Nov 1997 17:30:00 -0800 (PST) X-Authentication-Warning: cynic.portal.ca: cjs owned process doing -bs Date: Tue, 11 Nov 1997 17:30:00 -0800 (PST) From: Curt Sampson To: Michael Knoll cc: hackers@FreeBSD.ORG Subject: Re: Ethernet packet generation In-Reply-To: <3.0.32.19971111192821.009d1730@lafcol.lafayette.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Tue, 11 Nov 1997, Michael Knoll wrote: > Is there a way to generate an ethernet packet, with an unsupported protocol > through a user level program? Yes. Use bpf. cjs Curt Sampson cjs@portal.ca Info at http://www.portal.ca/ Internet Portal Services, Inc. Through infinite myst, software reverberates Vancouver, BC (604) 257-9400 In code possess'd of invisible folly. From owner-freebsd-hackers Tue Nov 11 17:35:21 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id RAA13635 for hackers-outgoing; Tue, 11 Nov 1997 17:35:21 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from bachue.usc.unal.edu.co ([168.176.3.20]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id RAA13621 for ; Tue, 11 Nov 1997 17:35:11 -0800 (PST) (envelope-from pgiffuni@fps.biblos.unal.edu.co) Received: from giffuni.inteng.com ([168.176.3.32]) by bachue.usc.unal.edu.co (Netscape Messaging Server 3.0) with SMTP id AAA20509; Tue, 11 Nov 1997 20:37:20 +0500 Message-ID: <3468E3C5.57159787@fps.biblos.unal.edu.co> Date: Tue, 11 Nov 1997 23:01:25 +0000 From: "Pedro Giffuni S." Organization: U. Nacional de Colombia X-Mailer: Mozilla 3.01Gold (X11; I; FreeBSD 2.2.2-RELEASE i386) MIME-Version: 1.0 To: Lucas Adrin G¢mez Bland¢n CC: freebsd-hackers@freebsd.org Subject: Re: Problems with passwd utility. References: Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Don't expect an answer to this...there is insufficient background information. Perhaps you are mixing DES and MD5 or maybe root changed permissions somewhere ? BTW, your version is outdated. This is a technical list, try freebsd-questions@freebsd.org and be more especific. You can also email me privately if you have problems with your english. regards, Pedro Giffuni Universidad Nacional de Colombia Lucas Adri n G¢mez Bland¢n wrote: > > Hi everyone, I'm install FreeBSD 2.1.7.1 (STABLE), it was a piece of > cake!, but when a user call "passwd" he receive "Permision denied". > > What's wrong????. > > Thanks for all! bye > > Lucas Adri n G¢mez Bland¢n > Panel de Control > Asesorias Inform ticas. From owner-freebsd-hackers Tue Nov 11 17:45:20 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id RAA14675 for hackers-outgoing; Tue, 11 Nov 1997 17:45:20 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from absinthe.i3inc.com (Absinthe.i3inc.com [209.31.147.194]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id RAA14667 for ; Tue, 11 Nov 1997 17:45:14 -0800 (PST) (envelope-from chris@absinthe.i3inc.com) Received: (from chris@localhost) by absinthe.i3inc.com (8.7.2/8.7.2) id UAA02462; Tue, 11 Nov 1997 20:45:03 -0500 (EST) To: hackers@freebsd.org Subject: mpd -- configuration for "server" side? From: Chris Shenton Date: 11 Nov 1997 20:45:01 -0500 Message-ID: <87oh3q997m.fsf@absinthe.i3inc.com> Lines: 82 X-Mailer: Gnus v5.5/Emacs 20.2 Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I've got Archie's multi-link ppp "mpd" running on two boxes: one at my house with 2.2.5-STABLE, the other at my ISP with 2.2.1-RELEASE. I want the home box to mpd-dial the ISP-box's mpd and stripe two POTS lines. I've been able to config the home box to dial out a single channel into a couple people's terminal servers -- Ascend, Livingston. I'm only trying to use one modem initially. It acts like normal kernel mode pppd with approximately the same performance. What I can't figure out is how to get the ISP mpd to listen for connections and answer the phone. Am I being lame? The normal mpd.conf setup seems oriented for dialing out, but I've got the link set to "answer-ring" thinking that would cause the daemon to camp on the line, and have also turned off "bw-manage" thinking that this would cause it to dial-on-demand rather than camp. I've tried various permutations with no luck. Or is mpd supposed to be spawned by init from /etc/ttys? Tried that too and got the expected "respawning to fast" from init; perhaps I invoked it wrong. I've searched the archives and haven't found anything besides "where can I find it" messages. I would have posted to -questions but most the traffic on this was on -hackers and -isp. Heres my ISP-side mpd configuration info; what's wrong with this picture? Any pointers would be most welcome. Thanks. [mpd.conf] # Incoming connection from sisyphus.stonos.washington.dc.us # Have to turn off login on this port! (/etc/ttys) # If Daemon isn't sitting on the line the modem won't answer! # Maybe need to turn of "bw-manage" to make it permanent? default: load sisyphus sisyphus: load log-normal set login ConsoleLogin new sisyphus usr0 set bundle authname placebo set bundle disable multilink #set bundle enable bw-manage #set bundle idle 300 set iface addrs 209.31.147.33 209.31.147.34 set iface enable on-demand set iface route 209.31.147.193/32 set ipcp ranges 209.31.147.33/32 209.31.147.34/32 set ipcp yes vjcomp link usr0 set link yes acfcomp protocomp set link yes pap set link no chap # We're waiting for connections, not dialing out. set modem script answer-ring set modem var $Timeout 600 open [mpd.link] # Internal US Robotics 33.6 modem on cuaa0 usr0: set link type modem #set link device /dev/cuaa0 # Want daemon listening in incoming device, not outgoing call unit set link device /dev/ttyd0 set link latency 100000 set link bandwidth 23040 set modem speed 115200 set modem watch +cd set modem var $InitString "&F1S0=1" From owner-freebsd-hackers Tue Nov 11 18:43:36 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id SAA20683 for hackers-outgoing; Tue, 11 Nov 1997 18:43:36 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from whistle.com (s205m131.whistle.com [207.76.205.131]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id SAA20665 for ; Tue, 11 Nov 1997 18:43:32 -0800 (PST) (envelope-from archie@whistle.com) Received: (from smap@localhost) by whistle.com (8.7.5/8.6.12) id SAA00143; Tue, 11 Nov 1997 18:42:56 -0800 (PST) Received: from bubba.whistle.com(207.76.205.7) by whistle.com via smap (V1.3) id sma000137; Tue Nov 11 18:42:46 1997 Received: (from archie@localhost) by bubba.whistle.com (8.8.5/8.6.12) id SAA08550; Tue, 11 Nov 1997 18:42:46 -0800 (PST) From: Archie Cobbs Message-Id: <199711120242.SAA08550@bubba.whistle.com> Subject: Re: mpd -- configuration for "server" side? In-Reply-To: <87oh3q997m.fsf@absinthe.i3inc.com> from Chris Shenton at "Nov 11, 97 08:45:01 pm" To: chris@absinthe.i3inc.com (Chris Shenton) Date: Tue, 11 Nov 1997 18:42:46 -0800 (PST) Cc: hackers@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-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Chris Shenton writes: > I've got Archie's multi-link ppp "mpd" running on two boxes: one at my > house with 2.2.5-STABLE, the other at my ISP with 2.2.1-RELEASE. I > want the home box to mpd-dial the ISP-box's mpd and stripe two POTS > lines. > > [...] > > What I can't figure out is how to get the ISP mpd to listen for > connections and answer the phone. Am I being lame? The normal mpd.conf > setup seems oriented for dialing out, but I've got the link set to > "answer-ring" thinking that would cause the daemon to camp on the > line, and have also turned off "bw-manage" thinking that this would > cause it to dial-on-demand rather than camp. I've tried various > permutations with no luck. > [mpd.conf] > > set iface enable on-demand Try "set iface disable on-demand" instead of enabling it. This will make it NOT wait for an outgoing packet before trying to "connect" -- by listening for an incoming call. Check that the tunnel interface is up and has addresses after mpd is started. Admittedly, this is confusing because there are two things you have to tweak to turn dial-on-demand on or off. -Archie ___________________________________________________________________________ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com From owner-freebsd-hackers Tue Nov 11 18:53:57 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id SAA21713 for hackers-outgoing; Tue, 11 Nov 1997 18:53:57 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from milkyway.org (lta-r-1.usit.net [205.241.194.17] (may be forged)) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id SAA21701 for ; Tue, 11 Nov 1997 18:53:47 -0800 (PST) (envelope-from toby@milkyway.org) Received: (from toby@localhost) by milkyway.org (8.8.5/8.8.3) id VAA01234; Tue, 11 Nov 1997 21:52:01 -0500 (EST) Date: Tue, 11 Nov 1997 21:52:01 -0500 (EST) From: Toby Swanson To: freebsd-hackers@freebsd.org Subject: security patch for open() Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Please explain in plain American how to apply the patches for the open() security hole that was recently released by the FreeBSD security officer. Better yet, give this FreeBSD newbie the general instructions for patch application. Thanks in advance. Toby (toby@milkyway.org) From owner-freebsd-hackers Tue Nov 11 19:11:41 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id TAA23346 for hackers-outgoing; Tue, 11 Nov 1997 19:11:41 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id TAA23339 for ; Tue, 11 Nov 1997 19:11:38 -0800 (PST) (envelope-from bde@zeta.org.au) Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.7/8.6.9) id OAA00642; Wed, 12 Nov 1997 14:05:03 +1100 Date: Wed, 12 Nov 1997 14:05:03 +1100 From: Bruce Evans Message-Id: <199711120305.OAA00642@godzilla.zeta.org.au> To: bde@zeta.org.au, mouth@ibm.net Subject: Re: Status of 650 UART support Cc: hackers@freebsd.org Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >I'm getting that "interrupt-level buffer overflow" message when I use >the 650 UART support. As long as I run the UARTs in 550 compatibility >mode, they work fine. My kernel is 3.0-971108-SNAP. > >I've looked at the source in sio.c and I see where the 650 auto >CTS/RTS flow control is turned on, but I've made little other progress >towards comprehending sio.c > >>static char const * const error_desc[] =3D {. >> "silo overflow", >> "interrupt-level buffer overflow", >> "tty-level buffer overflow", >>}; > >Can anyone explain the difference between these three types of >overflows? "silo overflow", This means that too many characters arrived before the sio interrupt handler could run to transfer the characters from the hardware fifo to the sio software fifo. RTS flow control is almost useless for preventing this error, since the interrupt handler must run to invoke RTS flow control. "interrupt-level buffer overflow", This means that too many characters arrived before the sio timeout handler could run to transfer the characters from the software fifo to the tty buffer (or to the line discipline routine, e.g., the kernel ppp one). RTS flow control is good for preventing this error, but you hope that it is not invoked since it would decrease throughput. It is invoked when the the software fifo is 3/4 full (192/256 characters). The gap between the high water mark and the end of the fifo (256 - 192) needs to be larger than the hardware fifo size. I think it is for the 16550, so the 16550 bug must be elsewhere. "tty-level buffer overflow", This means that too many characters arrived before the application could run to transfer the characters from the tty buffer to the application's buffer. All buffer sizes are too small for 230400 bps. The software fifo is large enough for 22 msec worth of input at 115200 bps and the timeout handler normally runs every 10 msec to drain it. 12 msec to spare is normally plenty, but 2 msec for 230400 bps wouldn't be. The tty buffer is large enough for 88 msec worth of input at 115200 bps. This is too small, since the scheduling quantum is 100 msec and it is possible for hundreds of processes to be scheduled ahead of you. However, it works well in practice, at least if RTS flow control is used, because processes usually only run for a few (hundred?) usec before giving up control, and flow control prevents problems from transient loads. It usually isn't reasonable to make the tty buffers hundreds of times larger to handle transient loads. Bruce From owner-freebsd-hackers Tue Nov 11 19:47:43 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id TAA26039 for hackers-outgoing; Tue, 11 Nov 1997 19:47:43 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from pandora.hh.kew.com (root@kendra.ne.mediaone.net [24.128.53.73]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id TAA26033 for ; Tue, 11 Nov 1997 19:47:39 -0800 (PST) (envelope-from ahd@kew.com) Received: from sonata (sonata.hh.kew.com [192.195.203.135]) by pandora.hh.kew.com (8.8.5/8.8.5) with ESMTP id WAA10575; Tue, 11 Nov 1997 22:47:33 -0500 (EST) Message-ID: <346926D6.1E12A218@kew.com> Date: Tue, 11 Nov 1997 22:47:34 -0500 From: Drew Derbyshire Reply-To: chat@FreeBSD.ORG Organization: Kendra Electronic Wonderworks, Stoneham MA 02180 X-Mailer: Mozilla 4.01 [en]C-MOENE (WinNT; U) MIME-Version: 1.0 To: Wilko Bulte Subject: Platform Port Phlame Wars (was: Re: Newest Pentium bug (fatal)) X-Priority: 3 (Normal) References: <199711111829.TAA01376@yedi.iaf.nl> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Wilko Bulte wrote: > > > Well, since I own a "Multia" and not a "Miata", I don't really get > > > how understanding the "Miata" would help me port to the "Multia", > > > so perhaps you could explain it to me... I _DO_ own Miata, and a Pentium, and this thread is headed away from both, so would all sides find a new subject line for the porting flame war? (I am mildly interested in the original topic. Silly me.) [Replies to this tangent of a tangent will be routed to chat.] -ahd- -- Internet: ahd@kew.com Voice: 781-279-9812 "Gotta get a Gund . . ." From owner-freebsd-hackers Tue Nov 11 21:18:39 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id VAA06652 for hackers-outgoing; Tue, 11 Nov 1997 21:18:39 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from out1.ibm.net (out1.ibm.net [165.87.194.252]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id VAA06621 for ; Tue, 11 Nov 1997 21:18:26 -0800 (PST) (envelope-from mouth@ibm.net) Received: from slip129-37-53-170.ca.us.ibm.net (slip129-37-53-170.ca.us.ibm.net [129.37.53.170]) by out1.ibm.net (8.8.5/8.6.9) with SMTP id FAA121406; Wed, 12 Nov 1997 05:18:18 GMT From: mouth@ibm.net (John Kelly) To: Bruce Evans Cc: hackers@freebsd.org Subject: Re: Status of 650 UART support Date: Wed, 12 Nov 1997 06:19:34 GMT Message-ID: <34693467.2988634@smtp-gw01.ny.us.ibm.net> References: <199711120305.OAA00642@godzilla.zeta.org.au> In-Reply-To: <199711120305.OAA00642@godzilla.zeta.org.au> X-Mailer: Forte Agent 1.01/16.397 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by hub.freebsd.org id VAA06625 Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Wed, 12 Nov 1997 14:05:03 +1100, Bruce Evans wrote: > "silo overflow", > >RTS flow control is almost useless for preventing this error, since > the interrupt handler must run to invoke RTS flow control. Did you know that the 650 UART has on-chip "auto" RTS flow control which can be invoked by the chip itself when the UART FIFO trigger level is reached? That's why I want to use my 650 UARTs in 650 mode rather than 550 compatibility mode. > "interrupt-level buffer overflow", > >The gap between the high water mark and the end of the fifo (256 - 192) >needs to be larger than the hardware fifo size. I think it is for >the 16550, so the 16550 bug must be elsewhere. You mean 650? A Startech 16C650 has a 32 byte FIFO buffer while the quad 16C654, four UARTs on a chip, each have 64 bytes. I increased the software buffer size from 256 to 512, and that seemed to reduce the number of overflows, but a burst of disk activity would still trigger one even with the larger buffer. >All buffer sizes are too small for 230400 bps. I have a 3Com ISDN T/A attached to a serial port at 230400 bps. I can saturate that link with a large download, start another download on an analog modem at 57600 bps, FTP upload my XFree86 directory from another machine via 10Mbps ethernet, and copy a directory from CD to the same hard drive receiving the FTP upload, never getting any serial overflows with the UARTs running in 550 compatibility mode. And the machine is only a 486 DX4-100. >The software fifo is large enough for 22 msec worth of input at 115200 > bps and the timeout handler normally runs every 10 msec to drain it. >12 msec to spare is normally plenty, but 2 msec for 230400 bps wouldn't I've never seen my ISDN link exceed throughput of 15k bytes per second, so I suppose my average bit rate of 150,000 is safe even in 550 mode. Hmmm ... the ISDN adapter is talking to the serial port at 230400 in short bursts ... I wonder how many bytes might arrive in one burst ... but then again, why should that be a problem only in 650 mode and not in 550 mode? I can change my ISDN port back to 115200 and still get overflows in 650 mode -- even the 57600 modem will overflow in 650 mode. John From owner-freebsd-hackers Tue Nov 11 21:19:57 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id VAA06847 for hackers-outgoing; Tue, 11 Nov 1997 21:19:57 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from absinthe.i3inc.com (Absinthe.i3inc.com [209.31.147.194]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id VAA06827 for ; Tue, 11 Nov 1997 21:19:50 -0800 (PST) (envelope-from chris@absinthe.i3inc.com) Received: (from chris@localhost) by absinthe.i3inc.com (8.7.2/8.7.2) id AAA02620; Wed, 12 Nov 1997 00:19:20 -0500 (EST) To: Archie Cobbs Cc: hackers@FreeBSD.ORG Subject: Re: mpd -- configuration for "server" side? References: <199711120242.SAA08550@bubba.whistle.com> From: Chris Shenton Date: 12 Nov 1997 00:19:19 -0500 In-Reply-To: Archie Cobbs's message of Tue, 11 Nov 1997 18:42:46 -0800 (PST) Message-ID: <87n2ja8zag.fsf@absinthe.i3inc.com> Lines: 81 X-Mailer: Gnus v5.5/Emacs 20.2 Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Archie Cobbs writes: > Try "set iface disable on-demand" instead of enabling it. > This will make it NOT wait for an outgoing packet before > trying to "connect" -- by listening for an incoming call. > Check that the tunnel interface is up and has addresses > after mpd is started. > > Admittedly, this is confusing because there are two things > you have to tweak to turn dial-on-demand on or off. That seems to have done it. "set iface disable on-demand" gets the daemon to camp on the device; I had to use /dev/cuaa0 rather than /dev/ttyd0 (unlike getty). Using "set bundle disable bw-manage" didn't seem to have any effect -- seems to work with it enabled too. It looks like the tun isn't instantiated until the call is answered -- is this a problem? Thanks! Now I can try to actually use multiple links :-) Couple of behavioral comments and questions: 1. On the "server side" I see complaints in the logs which usually, after 6 repetitions or so, have caused the "server" to drop the link: Nov 12 00:16:06 Placebo mpd: [usr0] LCP: no reply to 1 echo request(s) 2. This time, the link drops due to idle time-out; "server" logs: Nov 12 00:20:48 Placebo mpd: [sisyphus] idle timeout after 300 seconds Nov 12 00:20:48 Placebo mpd: [sisyphus] closing link "usr0"... Nov 12 00:20:48 Placebo mpd: [usr0] got msg MSG_CLOSE Nov 12 00:20:48 Placebo mpd: [usr0] LCP: Close event Nov 12 00:20:48 Placebo mpd: [usr0] LCP: state change Opened --> Closing Nov 12 00:20:48 Placebo mpd: [usr0] LCP: phase shift NETWORK --> TERMINATE Nov 12 00:20:48 Placebo mpd: [sisyphus] up: 0 links, total bandwidth 0 bps Nov 12 00:20:48 Placebo mpd: [sisyphus] closing link "usr0"... Nov 12 00:20:48 Placebo mpd: [usr0] LCP: SendTerminateReq #2 Nov 12 00:20:48 Placebo mpd: [usr0] LCP: LayerDown Nov 12 00:20:48 Placebo mpd: [usr0] got msg MSG_CLOSE Nov 12 00:20:48 Placebo mpd: [usr0] LCP: Close event Nov 12 00:20:48 Placebo mpd: [usr0] LCP: rec'd Terminate Ack #2 (Closing) Nov 12 00:20:48 Placebo mpd: [usr0] LCP: state change Closing --> Closed Nov 12 00:20:48 Placebo mpd: [usr0] LCP: phase shift TERMINATE --> ESTABLISH Nov 12 00:20:48 Placebo mpd: [usr0] LCP: LayerFinish Nov 12 00:20:48 Placebo mpd: [usr0] Closing physical layer in state UP Nov 12 00:20:48 Placebo mpd: [usr0] got msg MSG_DOWN Nov 12 00:20:48 Placebo mpd: [usr0] LCP: Down event Nov 12 00:20:48 Placebo mpd: [usr0] LCP: state change Closed --> Initial Nov 12 00:20:48 Placebo mpd: [usr0] LCP: phase shift ESTABLISH --> DEAD 3. Triggering demand causes the client side to attempt to re-establish the link, but the *server* is still sitting there at LCP DEAD. It never goes back to waiting by the phone. How to I get it to reset so that it will handle repeated incoming demand dials? 4. Can I set it up so that demand is there to ensure that if the link goes down it will get re-established, but that it never times out from being idle? My POTS line is unmetered, but I have a finite amount of "free" calls I can make per month. Does idle=0 imply infinite connection? (or hangup immediately, like an Ascend? :-) 5. Something in my mpd.conf and/or mpd.links sometimes generates "Line too long, truncated" warnings. The error doesn't identify which file, line number, or the line contents. It seems usually to associated with the "load log-normal" if the "log-normal:" specifier has stuff after it like miscellaneous comments, possibly even separated with the desired blank line. It would be real nice to have file:line identifiers to track this down, or at least a dislay of the offending line. Perhaps there's some confusion parsing the file looking for the last hunk and my trailing comments may be throwing it off? Thanks for your help. From owner-freebsd-hackers Tue Nov 11 21:20:55 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id VAA07090 for hackers-outgoing; Tue, 11 Nov 1997 21:20:55 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from server.local.sunyit.edu (A-T34.rh.sunyit.edu [150.156.210.241]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id VAA07059 for ; Tue, 11 Nov 1997 21:20:47 -0800 (PST) (envelope-from perlsta@cs.sunyit.edu) Received: from localhost (perlsta@localhost) by server.local.sunyit.edu (8.8.7/8.8.5) with SMTP id BAA14487 for ; Wed, 12 Nov 1997 01:25:17 -0500 (EST) X-Authentication-Warning: server.local.sunyit.edu: perlsta owned process doing -bs Date: Wed, 12 Nov 1997 01:25:16 -0500 (EST) From: Alfred Perlstein X-Sender: perlsta@server.local.sunyit.edu To: hackers@FreeBSD.org Subject: LFS system? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk has any though been put towards a log based File system? would it be a performance gain at all? i think it could be a major improvement on heavily modified file systems for instance on a large News server were a sync might take a few seconds to complete. -Alfred From owner-freebsd-hackers Tue Nov 11 22:57:37 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id WAA19784 for hackers-outgoing; Tue, 11 Nov 1997 22:57:37 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id WAA19773 for ; Tue, 11 Nov 1997 22:57:33 -0800 (PST) (envelope-from bde@zeta.org.au) Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.7/8.6.9) id RAA10782; Wed, 12 Nov 1997 17:47:08 +1100 Date: Wed, 12 Nov 1997 17:47:08 +1100 From: Bruce Evans Message-Id: <199711120647.RAA10782@godzilla.zeta.org.au> To: bde@zeta.org.au, mouth@ibm.net Subject: Re: Status of 650 UART support Cc: hackers@freebsd.org Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >>RTS flow control is almost useless for preventing this error, since >> the interrupt handler must run to invoke RTS flow control. > >Did you know that the 650 UART has on-chip "auto" RTS flow control >which can be invoked by the chip itself when the UART FIFO trigger >level is reached? That's why I want to use my 650 UARTs in 650 mode >rather than 550 compatibility mode. Yes. I'm not sure if it actually works (I don't have any 16650s). On some (early? all?) 16650s it is said to be just a pessimization to use it, since it is invoked when the trigger level is reached, so it is invoked for almost every input interrupt. I don't know what happens when the driver sets RTS directly. Perhaps auto flow control interferes with this and causes your buffer overflows. Possible fix: turn off auto flow control at least when clearing RTS directly. >>The gap between the high water mark and the end of the fifo (256 - 192) >>needs to be larger than the hardware fifo size. I think it is for >>the 16550, so the 16550 bug must be elsewhere. > >You mean 650? 16650 :-). >A Startech 16C650 has a 32 byte FIFO buffer while the quad 16C654, >four UARTs on a chip, each have 64 bytes. A 64-byte fifo probably won't work unless the fifo trigger level is reduced (defeating the point of the larger fifo). There may be just enough margin if the default (highest) trigger level is enough below 64. I think the best available setup is to use 16550 mode with the tx fifo size set to match the flow control. The 16650 configuration is too specific - it forces 16650 flow control and a 32 byte tx fifo size. The interrupt latency is low enough for auto flow control to be unnecessary in most cases (and there is another 6 character times of slop available by reducing the 16550 trigger level from 14 to 8 to handle overloaded cases). Another problem with auto flow control is that it doesn't actually work if the sender can't stop soon enough. E.g., if the sender is a 16550, then it can't reasonably stop before sending 16 characters if it has 16 characters in its tx fifo. The receiver must have a rx fifo trigger level 16+ below the fifo size to handle this completely in hardware (+ = a few more to give the interrupt handler time to run before flow control is actually invoked). 16+ below the 16650 fifo size of 32 is too many. 16+ below the 16654 fifo size of 64 is better. >I increased the software buffer size from 256 to 512, and that seemed >to reduce the number of overflows, but a burst of disk activity would >still trigger one even with the larger buffer. That breaks the watermarks in the tty buffer unless the tty buffer size (TTYHOG) is increased too. Bruce From owner-freebsd-hackers Tue Nov 11 23:06:00 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id XAA20854 for hackers-outgoing; Tue, 11 Nov 1997 23:06:00 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from misery.sdf.com (misery.sdf.com [204.244.210.193]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id XAA20844 for ; Tue, 11 Nov 1997 23:05:56 -0800 (PST) (envelope-from tom@sdf.com) Received: from tom by misery.sdf.com with smtp (Exim 1.73 #1) id 0xVWl9-00023q-00; Tue, 11 Nov 1997 22:58:43 -0800 Date: Tue, 11 Nov 1997 22:58:42 -0800 (PST) From: Tom To: Alfred Perlstein cc: hackers@freebsd.org Subject: Re: LFS system? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Wed, 12 Nov 1997, Alfred Perlstein wrote: > has any though been put towards a log based File system? Lots. See mount_lfs code (keep in mind that it doesn't work). Do a "man -k lfs" to get the whole picture. > would it be a performance gain at all? i think it could be a major > improvement on heavily modified file systems for instance on a large News > server were a sync might take a few seconds to complete. Performance gain? I always though LFS files systems were slow, due to the extra overhead. However, that overhead buys you security, and fast filesystems checks during start up. > -Alfred Tom From owner-freebsd-hackers Wed Nov 12 01:02:16 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id BAA09677 for hackers-outgoing; Wed, 12 Nov 1997 01:02:16 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from mail1.its.rpi.edu (root@mail1.its.rpi.edu [128.113.100.7]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id BAA09634 for ; Wed, 12 Nov 1997 01:02:05 -0800 (PST) (envelope-from gad@mlor.its.rpi.edu) Received: from mlor.its.rpi.edu (mlor.its.rpi.edu [128.113.24.92]) by mail1.its.rpi.edu (8.8.5/8.8.5) with SMTP id EAA09228 for ; Wed, 12 Nov 1997 04:02:00 -0500 Received: by mlor.its.rpi.edu (NX5.67f2/NX3.0M) id AA16549; Wed, 12 Nov 97 04:09:28 -0500 Message-Id: <9711120909.AA16549@mlor.its.rpi.edu> Content-Type: text/plain Mime-Version: 1.0 (NeXT Mail 3.3 v118.2) Received: by NeXT.Mailer (1.118.2) From: Garance A Drosehn Date: Wed, 12 Nov 97 04:09:27 -0500 To: hackers@FreeBSD.ORG Subject: Virtual Intel Machines? Reply-To: gad@eclipse.its.rpi.edu Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk The following is probably the result of an over-active imagination, but I was wondering if the following could be done (or already has been done). In the land of IBM mainframes, there's an operating system (of sorts) called VM. This is an operating system which lets you run multiple operating systems on a single machine, at the same time. VM can allocate devices between the running systems, so that one running OS sees a given hard disk (for example), but no other operating systems can possibly get to that hard disk. What I was wondering is if something similar could be done with Intel-ish chips? I realize this wouldn't be a trivial thing to write, but it'd be mighty convenient to have in some circumstances (at least in an academic setting). Note that I'm not talking about compatability modes so that the user could run applications from a given operating system. I am really interested in running the entire operating system, without having to change it for some special environment. This is also similar to the idea of VirtualPC on the MacOS, except that I'd imagine it would be easier to do it on an Intel-based OS such as FreeBSD. For my purposes it'd be fine if it only worked on real, 32-bit operating systems, so maybe that makes the project a little simpler. No DOS, Win3.1 or Win95. If such a thing were possible, I think I could suggest a few additional features which would make it even more enticing to have. On the other hand, that might just ensure that everyone on this list hates me for promoting more work than anyone would have the time to do. So for now let me start with the basic idea before dreaming up exotic additions to it. --- Garance Alistair Drosehn = gad@eclipse.its.rpi.edu Senior Systems Programmer (MIME & NeXTmail capable) Rensselaer Polytechnic Institute; Troy NY USA From owner-freebsd-hackers Wed Nov 12 01:52:48 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id BAA18477 for hackers-outgoing; Wed, 12 Nov 1997 01:52:48 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from frmug.org (frmug-gw.frmug.org [193.56.58.252]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id BAA18439 for ; Wed, 12 Nov 1997 01:52:40 -0800 (PST) (envelope-from roberto@keltia.freenix.fr) Received: (from uucp@localhost) by frmug.org (8.8.8/frmug-2.1/nospam) with UUCP id IAA02712 for hackers@FreeBSD.ORG; Wed, 12 Nov 1997 08:38:29 +0100 (CET) (envelope-from roberto@keltia.freenix.fr) Received: (from roberto@localhost) by keltia.freenix.fr (8.8.7/keltia-2.12/nospam) id IAA03982; Wed, 12 Nov 1997 08:34:50 +0100 (CET) (envelope-from roberto) Message-ID: <19971112083449.00854@keltia.freenix.fr> Date: Wed, 12 Nov 1997 08:34:49 +0100 From: Ollivier Robert To: hackers@FreeBSD.ORG Subject: Re: Perl 5.004 References: <199711112302.PAA14867@Gatekeeper.Alameda.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84 In-Reply-To: <199711112302.PAA14867@Gatekeeper.Alameda.net>; from Ulf Zimmermann on Tue, Nov 11, 1997 at 03:02:55PM -0800 X-Operating-System: FreeBSD 3.0-CURRENT ctm#3797 AMD-K6 MMX @ 208 MHz Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk According to Ulf Zimmermann: > Anyone has idea why this happens with the port of perl5.00401 and 5.00404: > > Gatekeeper root local/mrtg # ./mrtg.test mrtg.cfg.test > (null): Undefined symbol "___inet_ntoa" called from perl5.00404:/usr/local/lib/perl5/i386-freebsd/5.00404/auto/Socket/Socket.so at 0x8127110 You have compiled Perl with the header files from bind 8.1. Ensure that every file in arpa/ is taken from the system files not from the directory installed by bind in /usr/local/include. I usually rename /usr/local/include/arpa into /usr/local/bind/bind/ to avoid conflicts. I think 8.1.1's header files have been fixed but I've not verified it. -- Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- roberto@keltia.freenix.fr FreeBSD keltia.freenix.fr 3.0-CURRENT #48: Sat Nov 8 18:08:59 CET 1997 From owner-freebsd-hackers Wed Nov 12 02:14:22 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id CAA21562 for hackers-outgoing; Wed, 12 Nov 1997 02:14:22 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from dfw-ix1.ix.netcom.com (dfw-ix1.ix.netcom.com [206.214.98.1]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id CAA21557 for ; Wed, 12 Nov 1997 02:14:20 -0800 (PST) (envelope-from wghhicks@ix.netcom.com) Received: (from smap@localhost) by dfw-ix1.ix.netcom.com (8.8.4/8.8.4) id EAA02991; Wed, 12 Nov 1997 04:13:00 -0600 (CST) Received: from atl-ga7-04.ix.netcom.com(199.183.210.36) by dfw-ix1.ix.netcom.com via smap (V1.3) id rma002986; Wed Nov 12 04:12:38 1997 Message-ID: <3469810A.3FC8E8DC@ix.netcom.com> Date: Wed, 12 Nov 1997 05:12:26 -0500 From: Jerry Hicks Reply-To: jerry_hicks@bigfoot.com Organization: TerraEarth X-Mailer: Mozilla 4.03b8 [en] (X11; I; FreeBSD 2.2.5-STABLE i386) MIME-Version: 1.0 To: Ulf Zimmermann CC: David Kelly , hackers@FreeBSD.ORG Subject: Re: IDT processors? References: <199711100322.TAA21822@Gatekeeper.Alameda.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Ulf Zimmermann wrote: > > > Motorola has been mirroring this product line with their ColdFire > > series using PowerPC cores. I think the ColdFire CPU's emulate 68k > > instructions, or there is a 68k binary-to-ColdFire translator. Motorola > > was recently offering a very interesting ColdFire prototyping kit, a > > ColdFire MB with 512k DRAM, ethernet, an ISA ethernet card, and > > software tools for something like $150 or $99.95. I wanted one, but > > accepted the fact that I don't have time to play with one. > > Do you have a pointer where to find more informations ? Part number ? > > Thanks, Ulf. > > --------------------------------------------------------------------- > Ulf Zimmermann, 1525 Pacific Ave., Alameda, CA-94501, #: 510-769-2936 > Alameda Networks, Inc. | http://www.Alameda.net | Fax#: 510-521-5073 Ahh... There it is. That was *hard* to find. http://www.hollinet.com/~tools/ColdFire_5206.htm Jerry Hicks jerry_hicks@bigfoot.com From owner-freebsd-hackers Wed Nov 12 02:22:14 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id CAA22222 for hackers-outgoing; Wed, 12 Nov 1997 02:22:14 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from labinfo.iet.unipi.it (labinfo.iet.unipi.it [131.114.9.5]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id CAA22205 for ; Wed, 12 Nov 1997 02:22:09 -0800 (PST) (envelope-from luigi@labinfo.iet.unipi.it) Received: from localhost (luigi@localhost) by labinfo.iet.unipi.it (8.6.5/8.6.5) id JAA06510 for hackers@freebsd.org; Wed, 12 Nov 1997 09:58:14 +0100 From: Luigi Rizzo Message-Id: <199711120858.JAA06510@labinfo.iet.unipi.it> Subject: A stylistic question... To: hackers@freebsd.org Date: Wed, 12 Nov 1997 09:58:14 +0100 (MET) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I have always wondered about this: most if not all programs, and some pieces of the kernel as well (e.g. userconfig.c) have a menu/usage function which is written like this: usage() { printf( "bla bla bla...\n" ); printf( "bla bla bla...\n" ); printf( "bla bla bla...\n" ); ... printf( "bla bla bla...\n" ); } instead of what in my opinion would be much better: usage() { printf( "%s", "bla bla bla...\n" "bla bla bla...\n" ... "bla bla bla...\n"); } yes the code savings are modest (5-10 bytes/call ? but in the kernel or boot blocks they still matter...) but at runtime the second approach is faster since the format string must be parsed only once and it is the shortest possible. Any reason not to use the second method ? Cheers Luigi -----------------------------+-------------------------------------- Luigi Rizzo | Dip. di Ingegneria dell'Informazione email: luigi@iet.unipi.it | Universita' di Pisa tel: +39-50-568533 | via Diotisalvi 2, 56126 PISA (Italy) fax: +39-50-568522 | http://www.iet.unipi.it/~luigi/ _____________________________|______________________________________ From owner-freebsd-hackers Wed Nov 12 03:11:50 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id DAA26103 for hackers-outgoing; Wed, 12 Nov 1997 03:11:50 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from pluto.senet.com.au (root@pluto.senet.com.au [203.11.90.2]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id DAA26085 for ; Wed, 12 Nov 1997 03:11:41 -0800 (PST) (envelope-from darius@holly.rd.net) Received: from holly.rd.net (c6-p45.senet.com.au [203.56.238.110]) by pluto.senet.com.au (8.8.7/8.8.7) with ESMTP id VAA05503 for ; Wed, 12 Nov 1997 21:41:26 +1030 Received: from holly.rd.net (localhost.rd.net [127.0.0.1]) by holly.rd.net (8.8.5/8.8.5) with ESMTP id VAA04516 for ; Wed, 12 Nov 1997 21:45:43 +1030 (CST) Message-Id: <199711121115.VAA04516@holly.rd.net> X-Mailer: exmh version 2.0zeta 7/24/97 To: freebsd-hackers@freebsd.org Subject: Dial on demand with dynamic IP Reply-to: doconnor@ist.flinders.edu.au Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 12 Nov 1997 21:45:43 +1030 From: "Daniel J. O'Connor" Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi, I was wondering if it was possible to get dial on demand working with a dynamic IP. I realise it would be difficult, and as far as I can tell you'd _need_ IP aliasing, but how I envisage it working would be as follows. Run an app that sends a packet(telnet, mail.. whatever)0 The PPP process dials up, and then gets the IP it's to use, and then aliases the packet according to that IP. Everything works like normal :) I think this would be possible with IJPPP but I'm not sure (you'd have to make sure the aliasing happens at the right time - ie after any dialup event). Is it worth a try? Is anyone alreay doing it? :) --------------- Daniel O'Connor 3rd Year Computer Science at Flinders University http://www.geocities.com.au/CapeCanaveral/7200 From owner-freebsd-hackers Wed Nov 12 03:37:26 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id DAA27141 for hackers-outgoing; Wed, 12 Nov 1997 03:37:26 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from DNS.Lamb.net (root@DNS.Lamb.net [207.90.181.1]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id DAA27135 for ; Wed, 12 Nov 1997 03:37:23 -0800 (PST) (envelope-from ulf@Gatekeeper.Alameda.net) Received: (from uucp@localhost) by DNS.Lamb.net (8.8.6/8.8.6) id DAA15855; Wed, 12 Nov 1997 03:37:24 -0800 (PST) Received: from gatekeeper.Alameda.net(207.90.181.2) via SMTP by DNS.Lamb.net, id smtpd015853; Wed Nov 12 03:37:22 1997 Received: (from ulf@localhost) by Gatekeeper.Alameda.net (8.8.6/8.7.6) id DAA05116; Wed, 12 Nov 1997 03:37:20 -0800 (PST) From: Ulf Zimmermann Message-Id: <199711121137.DAA05116@Gatekeeper.Alameda.net> Subject: Re: Perl 5.004 In-Reply-To: <19971112083449.00854@keltia.freenix.fr> from Ollivier Robert at "Nov 12, 97 08:34:49 am" To: roberto@keltia.freenix.fr (Ollivier Robert) Date: Wed, 12 Nov 1997 03:37:20 -0800 (PST) Cc: hackers@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-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > According to Ulf Zimmermann: > > Anyone has idea why this happens with the port of perl5.00401 and 5.00404: > > > > Gatekeeper root local/mrtg # ./mrtg.test mrtg.cfg.test > > (null): Undefined symbol "___inet_ntoa" called from perl5.00404:/usr/local/lib/perl5/i386-freebsd/5.00404/auto/Socket/Socket.so at 0x8127110 > > You have compiled Perl with the header files from bind 8.1. Ensure that > every file in arpa/ is taken from the system files not from the directory > installed by bind in /usr/local/include. > > I usually rename /usr/local/include/arpa into /usr/local/bind/bind/ to > avoid conflicts. > > I think 8.1.1's header files have been fixed but I've not verified it. > -- > Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- roberto@keltia.freenix.fr > FreeBSD keltia.freenix.fr 3.0-CURRENT #48: Sat Nov 8 18:08:59 CET 1997 Thanks, that was it. Should I submit the perl5.004_04 port ? -current is still 5.004_01 Ulf. --------------------------------------------------------------------- Ulf Zimmermann, 1525 Pacific Ave., Alameda, CA-94501, #: 510-769-2936 Alameda Networks, Inc. | http://www.Alameda.net | Fax#: 510-521-5073 From owner-freebsd-hackers Wed Nov 12 04:03:53 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id EAA29190 for hackers-outgoing; Wed, 12 Nov 1997 04:03:53 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.5]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id EAA29179 for ; Wed, 12 Nov 1997 04:03:32 -0800 (PST) (envelope-from erakupa@kk.etx.ericsson.se) Received: from kkb3 (kkb3.kk.etx.ericsson.se [130.100.97.23]) by penguin.wise.edt.ericsson.se (8.7.5/8.7.3/glacier-1.12) with SMTP id NAA22818 for ; Wed, 12 Nov 1997 13:02:57 +0100 (MET) Received: from kk662.kk.etx.ericsson.se by kkb3 (SMI-8.6/LME-2.2.6) id NAA12617; Wed, 12 Nov 1997 13:02:55 +0100 From: erakupa@kk.etx.ericsson.se (ETX-B-SL Martti Kuparinen) Received: by kk662.kk.etx.ericsson.se (SMI-8.6/client-1.6) id NAA00859; Wed, 12 Nov 1997 13:02:56 +0100 Date: Wed, 12 Nov 1997 13:02:56 +0100 Message-Id: <199711121202.NAA00859@kk662.kk.etx.ericsson.se> To: freebsd-hackers@freebsd.org Subject: IFF_OACTIVE for fxp X-Sun-Charset: US-ASCII Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I am running 2.2.5-RELEASE with 4 EtherExpress Pro 10/100B cards (the fxp driver). But why, oh why isn't the IFF_OACTIVE flag set when the card's transmit buffer is full? I would need this piece of information in a priority scheduler I have written... How can I check if the card's write buffer is full? Or do I have to add somewhere "ifp->if_flags |= IFF_OACTIVE" ? /Martti From owner-freebsd-hackers Wed Nov 12 04:22:04 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id EAA29946 for hackers-outgoing; Wed, 12 Nov 1997 04:22:04 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from dfw-ix12.ix.netcom.com (dfw-ix12.ix.netcom.com [206.214.98.12]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id EAA29940 for ; Wed, 12 Nov 1997 04:21:59 -0800 (PST) (envelope-from wghhicks@ix.netcom.com) Received: (from smap@localhost) by dfw-ix12.ix.netcom.com (8.8.4/8.8.4) id GAA25187 for ; Wed, 12 Nov 1997 06:21:26 -0600 (CST) Received: from atl-ga11-19.ix.netcom.com(199.183.210.179) by dfw-ix12.ix.netcom.com via smap (V1.3) id rma025174; Wed Nov 12 06:21:24 1997 Message-ID: <34699F38.330982A9@ix.netcom.com> Date: Wed, 12 Nov 1997 07:21:12 -0500 From: Jerry Hicks Reply-To: jerry_hicks@bigfoot.com Organization: TerraEarth X-Mailer: Mozilla 4.03b8 [en] (X11; I; FreeBSD 2.2.5-STABLE i386) MIME-Version: 1.0 To: hackers@FreeBSD.ORG Subject: Re: A stylistic question... References: <199711120858.JAA06510@labinfo.iet.unipi.it> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Luigi Rizzo wrote: > > I have always wondered about this: most if not all programs, and some > pieces of the kernel as well (e.g. userconfig.c) > have a menu/usage function which is written like this: > > usage() > { > printf( "bla bla bla...\n" ); > printf( "bla bla bla...\n" ); > printf( "bla bla bla...\n" ); > ... > printf( "bla bla bla...\n" ); > } > > instead of what in my opinion would be much better: > > usage() > { > printf( "%s", "bla bla bla...\n" > "bla bla bla...\n" > ... > "bla bla bla...\n"); > } > > yes the code savings are modest (5-10 bytes/call ? but in the kernel > or boot blocks they still matter...) but at runtime the second > approach is faster since the format string must be parsed only once > and it is the shortest possible. > > Any reason not to use the second method ? > > Cheers > Luigi > -----------------------------+-------------------------------------- > Luigi Rizzo | Dip. di Ingegneria dell'Informazione > email: luigi@iet.unipi.it | Universita' di Pisa > tel: +39-50-568533 | via Diotisalvi 2, 56126 PISA (Italy) > fax: +39-50-568522 | http://www.iet.unipi.it/~luigi/ > _____________________________|______________________________________ Actually, the second form probably lends itself to internationalization better. J. Hicks jerry_hicks@bigfoot.com From owner-freebsd-hackers Wed Nov 12 04:26:25 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id EAA00333 for hackers-outgoing; Wed, 12 Nov 1997 04:26:25 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from isgate.is (isgate.is [193.4.58.51]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id EAA00322 for ; Wed, 12 Nov 1997 04:26:21 -0800 (PST) (envelope-from spammer@spam.org) Received: from didda.est.is (ppp-22.est.is [194.144.208.122]) by isgate.is (8.7.5-M/) with ESMTP id MAA16120; Wed, 12 Nov 1997 12:26:12 GMT Received: from didda.est.is (didda.est.is [192.168.255.1]) by didda.est.is (8.8.7/8.8.5) with SMTP id MAA06373; Wed, 12 Nov 1997 12:26:09 GMT Message-ID: <3469A061.41C67EA6@spam.org> Date: Wed, 12 Nov 1997 12:26:09 +0000 From: =?iso-8859-1?Q?=DEor=F0ur?= Ivarsson X-Mailer: Mozilla 3.01Gold (X11; I; FreeBSD 2.2.5-RELEASE i386) MIME-Version: 1.0 To: doconnor@ist.flinders.edu.au CC: freebsd-hackers@FreeBSD.ORG Subject: Re: Dial on demand with dynamic IP References: <199711121115.VAA04516@holly.rd.net> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by hub.freebsd.org id EAA00326 Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Daniel J. O'Connor wrote: > > Hi, > I was wondering if it was possible to get dial on demand working with a > dynamic IP. I realise it would be difficult, and as far as I can tell you'd > _need_ IP aliasing, but how I envisage it working would be as follows. > > Run an app that sends a packet(telnet, mail.. whatever)0 > The PPP process dials up, and then gets the IP it's to use, and then aliases > the packet according to that IP. > Everything works like normal :) > > I think this would be possible with IJPPP but I'm not sure (you'd have to make > sure the aliasing happens at the right time - ie after any dialup event). > > Is it worth a try? Is anyone alreay doing it? :) > > --------------- > Daniel O'Connor > 3rd Year Computer Science at Flinders University > http://www.geocities.com.au/CapeCanaveral/7200 I do run IIJPPP with dynamic IP and IP aliasing auto: set authname bla bla bla set authkey bla bla bla accept pap set ifaddr 194.144.208.200/24 194.144.208.34/24 add 0 255.255.255.255 194.144.208.34 # and start 'ppp -alias -auto auto' this works for me! You have to change the IP to something resonable for your end -- Þórður Ívarsson Thordur Ivarsson Rafeindavirki Electronic technician Norðurgötu 30 Nordurgotu 30 Box 309 Box 309 602 Akureyri 602 Akureyri Ísland Iceland --------------------------------------------- FreeBSD has good features, Some others are full of unwanted features! --------------------------------------------- From owner-freebsd-hackers Wed Nov 12 04:29:21 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id EAA00485 for hackers-outgoing; Wed, 12 Nov 1997 04:29:21 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from isgate.is (isgate.is [193.4.58.51]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id EAA00480 for ; Wed, 12 Nov 1997 04:29:18 -0800 (PST) (envelope-from totii@est.is) Received: from didda.est.is (ppp-22.est.is [194.144.208.122]) by isgate.is (8.7.5-M/) with ESMTP id MAA16190; Wed, 12 Nov 1997 12:29:15 GMT Received: from didda.est.is (didda.est.is [192.168.255.1]) by didda.est.is (8.8.7/8.8.5) with SMTP id MAA06379; Wed, 12 Nov 1997 12:29:12 GMT Message-ID: <3469A118.167EB0E7@est.is> Date: Wed, 12 Nov 1997 12:29:12 +0000 From: =?iso-8859-1?Q?=DEor=F0ur?= Ivarsson X-Mailer: Mozilla 3.01Gold (X11; I; FreeBSD 2.2.5-RELEASE i386) MIME-Version: 1.0 To: doconnor@ist.flinders.edu.au CC: freebsd-hackers@FreeBSD.ORG Subject: Re: Dial on demand with dynamic IP References: <199711121115.VAA04516@holly.rd.net> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by hub.freebsd.org id EAA00481 Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Wrong Email address got to my last mail! Sorry everyone! shouldn't be working on sendmail fixes on the main username of mine! -- Þórður Ívarsson Thordur Ivarsson Rafeindavirki Electronic technician Norðurgötu 30 Nordurgotu 30 Box 309 Box 309 602 Akureyri 602 Akureyri Ísland Iceland --------------------------------------------- FreeBSD has good features, Some others are full of unwanted features! --------------------------------------------- From owner-freebsd-hackers Wed Nov 12 04:33:08 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id EAA00766 for hackers-outgoing; Wed, 12 Nov 1997 04:33:08 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from awfulhak.demon.co.uk (awfulhak.demon.co.uk [158.152.17.1]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id EAA00721; Wed, 12 Nov 1997 04:32:57 -0800 (PST) (envelope-from brian@awfulhak.org) Received: from gate.lan.awfulhak.org (localhost [127.0.0.1]) by awfulhak.demon.co.uk (8.8.7/8.8.5) with ESMTP id MAA29463; Wed, 12 Nov 1997 12:31:20 GMT Message-Id: <199711121231.MAA29463@awfulhak.demon.co.uk> X-Mailer: exmh version 2.0zeta 7/24/97 To: doconnor@ist.flinders.edu.au cc: freebsd-hackers@FreeBSD.org, eivind@FreeBSD.org Subject: Re: Dial on demand with dynamic IP In-reply-to: Your message of "Wed, 12 Nov 1997 21:45:43 +1030." <199711121115.VAA04516@holly.rd.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 12 Nov 1997 12:31:20 +0000 From: Brian Somers Sender: owner-freebsd-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk [cc'd to Eivind 'cos we were talking about this recently] > Hi, > I was wondering if it was possible to get dial on demand working with a > dynamic IP. I realise it would be difficult, and as far as I can tell you'd > _need_ IP aliasing, but how I envisage it working would be as follows. > > Run an app that sends a packet(telnet, mail.. whatever)0 > The PPP process dials up, and then gets the IP it's to use, and then aliases > the packet according to that IP. > Everything works like normal :) > > I think this would be possible with IJPPP but I'm not sure (you'd have to make > sure the aliasing happens at the right time - ie after any dialup event). > > Is it worth a try? Is anyone alreay doing it? :) This is only half the problem, but it would probably make things better for most sites. The ``other'' problem is when a process bind()s to an IP number that gets dynamically re-assigned. Perhaps the *real* answer is to never change the IP number of the interface, and to change all IP numbers that are the same as the one netogitated through IPCP to that of the interface. Hmmm, that would work wouldn't it ? > --------------- > Daniel O'Connor > 3rd Year Computer Science at Flinders University > http://www.geocities.com.au/CapeCanaveral/7200 > > > -- Brian , , Don't _EVER_ lose your sense of humour.... From owner-freebsd-hackers Wed Nov 12 04:42:09 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id EAA01196 for hackers-outgoing; Wed, 12 Nov 1997 04:42:09 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from implode.root.com (implode.root.com [198.145.90.17]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id EAA01191 for ; Wed, 12 Nov 1997 04:42:07 -0800 (PST) (envelope-from root@implode.root.com) Received: from implode.root.com (localhost [127.0.0.1]) by implode.root.com (8.8.5/8.8.5) with ESMTP id EAA06966; Wed, 12 Nov 1997 04:43:42 -0800 (PST) Message-Id: <199711121243.EAA06966@implode.root.com> To: erakupa@kk.etx.ericsson.se (ETX-B-SL Martti Kuparinen) cc: freebsd-hackers@FreeBSD.ORG Subject: Re: IFF_OACTIVE for fxp In-reply-to: Your message of "Wed, 12 Nov 1997 13:02:56 +0100." <199711121202.NAA00859@kk662.kk.etx.ericsson.se> From: David Greenman Reply-To: dg@root.com Date: Wed, 12 Nov 1997 04:43:42 -0800 Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >I am running 2.2.5-RELEASE with 4 EtherExpress Pro 10/100B >cards (the fxp driver). > >But why, oh why isn't the IFF_OACTIVE flag set when the card's >transmit buffer is full? I would need this piece of information >in a priority scheduler I have written... > >How can I check if the card's write buffer is full? Or do I have >to add somewhere "ifp->if_flags |= IFF_OACTIVE" ? It's not set because it is optional and because it is higher overhead to set/clear than it is to just return when we run out of buffers. -DG David Greenman Core-team/Principal Architect, The FreeBSD Project From owner-freebsd-hackers Wed Nov 12 05:04:15 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id FAA02417 for hackers-outgoing; Wed, 12 Nov 1997 05:04:15 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from hda.hda.com (hda-bicnet.bicnet.net [208.220.66.37]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id FAA02406 for ; Wed, 12 Nov 1997 05:04:09 -0800 (PST) (envelope-from dufault@hda.hda.com) Received: (from dufault@localhost) by hda.hda.com (8.8.5/8.8.5) id TAA00327; Tue, 11 Nov 1997 19:55:20 -0500 (EST) From: Peter Dufault Message-Id: <199711120055.TAA00327@hda.hda.com> Subject: Re: LabPC+ Driver Specifics In-Reply-To: from "Jamil J. Weatherbee" at "Nov 11, 97 02:02:32 pm" To: jamil@trojanhorse.ml.org (Jamil J. Weatherbee) Date: Tue, 11 Nov 1997 19:55:18 -0500 (EST) Cc: hackers@freebsd.org X-Mailer: ELM [version 2.4ME+ PL25 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > Can you possibly take a glance at my source in a few days? Yes. > > There is only one clock on that board. > > does that mean if you say set AD_MICRO_PERIOD = 10000 and you are reading > from 4 of the 8 channels then really each channel is only getting 25 > readings per second. (I can't remember of the labpc if internally > multiplexed like my board) The board has a single A-D converter connected to a mux. It has a scanning mode where it will scan through sequential channels from 0 to the selected channel encoded in the minor number. It has a single gain selection for all channels. Each tick of the clock will convert the next channel and clock it into the board FIFO. In my experience, a general data acq interface should be frame (another term is record) based, where you can specify a channel list, a gain list, a trigger specification, and a sampling specification. Channel and gain lists are common and set the specifics for each channel (The LabPC is restrictive in that there is a single gain for all channels and the channel list can only be 0...N, where N is one of the channels). The trigger specification states when to start the frame (or record) collection process. This is typically immediately on read, via an external TTL input, via a timer, or dependant on the data. The sampling specification states the details of the time between samples and is typically either an external input or an inter-sample timer. More complicated specifications such as you present (i.e., setting different per-channel sample rates) should be handled as separate devices even when implemented in a single driver. > > If you have (or are implementing) independent clocks you probably have > > (or are implementing) independent FIFOs or other memory channels > > and you should handle it as separate instances of the driver, i.e., > > as if each is a separate board. > > Not possible (there is only one clock) and any drivers would have to be > cooperating with each other You should have a single driver implementing multiple devices. You would treat part of your driver as the firmware of a virtual board where you design as if that piece can be pushed off on a dedicated microcontroller. This part should be fast, low overhead, and a candidate for execution at an elevated priority level. It would do little other than demux your data into software FIFOs and implement the timing strategy. > So data acquisiton doesn't start on a labpc channel until the _first_ > read, then it is continuous until closing? Until closing or until an error such as FIFO overrun. > I was going to have my channels when open not spew any data. > when you ioctl() AD_START they start to read at the MICRO_PERIOD rate. > when you AD_STOP they stop spewing. Of course if each has its own virtual > clock this might not be neccessary. > That was my problem in a multiplexed system say you have 3 channels open. > > channel 1 wants 10hz signal > channel 2 wants 20hz signal > channel 3 wants 30hz signal > > then for me you have to do some pretty fancy scheduling stuff and run the > 8253 at 60 hz having it go through a scheduling list on each interrupt of > which channel to read. This particular example is easy, and any example which is a multiple of a base clock rate will be easy, either by using "skip counters" or a callout table (ordered list of expired timers as used in the kernel timeout). You are right in that in general this can't be done properly especially if you need temporaly clean data. I'd prefer this to be three separate devices where your driver demuxes these channels - I don't want to sort that out in software, I'd rather open channel 1 set to 10 Hz, open channel 2 set to 2 Hz, etc. > Can you explain what the concept of frame means to you in this context? By a frame I mean a record of data described using the ioctl calls we discussed earlier. For example, three channels at 500 Hz and four other channels at 60 Hz are two frames at different frame rates. Whether or not these frames can be supported by a single piece of hardware are an issue of the hardware and software design. > I fear that the labpc can get 8 readings on one interrupt ... The LabPC will get a single DONE interrupt after a counter expires. That counter is set based on the size of the read. I punt as much control as possible back to the application programmer. > wheras I really > only have one port but it is double multiplexed (reading is the two step > process of setting a multilplexer address, and letting that settle for 1 > click then (thus the external multiplexer signal) then starting a > conversion going a click (always more than the 30microsecond conversion > time) and reading the result. Starting the conversion would be a good candidate for moving into your hardware so that the conversion begins after a timer expires that is started by the mux write. > if I want 48 channels at 10 samples/sec each my clock rate is 960hz Using my terminology you have a channel list of 48 channels with an immediate trigger (start ASAP) and a sample spec of 960 Hz. Though it may put a nasty, bursty load on the system, someone will reasonably want the same 48 channels sampled as close together as they can at the 10 Hz rate. Then you have a clocked trigger set at 10 Hz and a sample spec of "as fast as the hardware can do it". You can see how with a mux settle timer, an interval timer and a simple counter you could implement that same sequential scan that the LabPC has and move that part out of the driver. I'm not saying you should do that but that you should structure your software with that in mind. Peter -- Peter Dufault (dufault@hda.com) Realtime development, Machine control, HD Associates, Inc. Safety critical systems, Agency approval From owner-freebsd-hackers Wed Nov 12 06:02:04 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id GAA05524 for hackers-outgoing; Wed, 12 Nov 1997 06:02:04 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from konig.elte.hu (konig.elte.hu [157.181.6.22]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id GAA05482; Wed, 12 Nov 1997 06:01:51 -0800 (PST) (envelope-from sebesty@cs.elte.hu) Received: from neumann.cs.elte.hu (neumann [157.181.6.200]) by konig.elte.hu (8.8.3/8.7.3/7s) with ESMTP id NAA21992; Wed, 12 Nov 1997 13:04:38 +0100 Received: from localhost (sebesty@localhost) by neumann.cs.elte.hu (8.8.3/8.7.3/4c) with SMTP id NAA24228; Wed, 12 Nov 1997 13:04:04 +0100 X-Authentication-Warning: neumann.cs.elte.hu: sebesty owned process doing -bs Date: Wed, 12 Nov 1997 13:04:04 +0100 (MET) From: Zoltan Sebestyen To: FreeBSD questions mailinglist cc: FreeBSD hackers mailinglist Subject: Q: about procfs Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I'd like to know what will be the future of procfs on FreeBSD. Will it provide more information about the system and the processes like it does on Linux, or will I have to keep using kernel calls like the kvm_ functions? This question raises everytime I port a Linux application that uses procfs to gain some pieces of system level information. P.S.: A month ago or more I asked for on application which tracks the cpuload the same way that top does, but its source code is much simpler so I can learn how to do it. Finally I found that program, it's called iostat. -------------------------------------------------------------------------------- Sebestyen Zoltan It all seems so stupid, it makes me want to give up. szoli@digo.inf..elte.hu But why should I give up, when it all seems so stupid? MAKE INSTALL NOT WAR From owner-freebsd-hackers Wed Nov 12 06:17:46 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id GAA06103 for hackers-outgoing; Wed, 12 Nov 1997 06:17:46 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from mail.virginia.edu (mail.Virginia.EDU [128.143.2.9]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id GAA06095 for ; Wed, 12 Nov 1997 06:17:39 -0800 (PST) (envelope-from atf3r@cs.virginia.edu) Received: from ares.cs.virginia.edu by mail.virginia.edu id aa17697; 12 Nov 97 9:17 EST Received: from stretch.cs.virginia.edu (atf3r@stretch-fo.cs.Virginia.EDU [128.143.136.14]) by ares.cs.Virginia.EDU (8.8.5/8.8.5) with ESMTP id JAA07208; Wed, 12 Nov 1997 09:17:00 -0500 (EST) Received: (from atf3r@localhost) by stretch.cs.virginia.edu (8.8.5/8.8.5) id JAA11595; Wed, 12 Nov 1997 09:16:58 -0500 (EST) Date: Wed, 12 Nov 1997 09:16:58 -0500 (EST) From: "Adrian T. Filipi-Martin" Reply-To: adrian@virginia.edu To: Luigi Rizzo cc: hackers@freebsd.org Subject: Re: A stylistic question... In-Reply-To: <199711120858.JAA06510@labinfo.iet.unipi.it> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Wed, 12 Nov 1997, Luigi Rizzo wrote: > I have always wondered about this: most if not all programs, and some > pieces of the kernel as well (e.g. userconfig.c) > have a menu/usage function which is written like this: > > usage() > { > printf( "bla bla bla...\n" ); > printf( "bla bla bla...\n" ); > printf( "bla bla bla...\n" ); > ... > printf( "bla bla bla...\n" ); > } > > instead of what in my opinion would be much better: > > usage() > { > printf( "%s", "bla bla bla...\n" > "bla bla bla...\n" > ... > "bla bla bla...\n"); > } > > yes the code savings are modest (5-10 bytes/call ? but in the kernel > or boot blocks they still matter...) but at runtime the second > approach is faster since the format string must be parsed only once > and it is the shortest possible. > > Any reason not to use the second method ? Not really. It will compile into slightly smaller code and it will have better runtime performance since there will only one function call to printf(). Why do yo feel that you need the "%s" though? Just make the "blah..." your format string. The parsing of the format string is pretty efficient. It reads a char and then switch()'s on it to what to do. That's one comparison per character. Printing a string using "%s" will still need to do one comparison with each character when looking for '\0'. The overhead of the indexed jump is probably not worth worying about. Adrian -- adrian@virginia.edu ---->>>>| If I were stranded on a desert island, and System Administrator --->>>| I could only have one OS for my computer, Neurosurgical Visualzation Lab -->>| it would be FreeBSD. Think about it..... http://www.nvl.virginia.edu/ ->| http://www.freebsd.org/ From owner-freebsd-hackers Wed Nov 12 06:20:16 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id GAA06291 for hackers-outgoing; Wed, 12 Nov 1997 06:20:16 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id GAA06286 for ; Wed, 12 Nov 1997 06:20:14 -0800 (PST) (envelope-from rcdii@inlink.com) Received: from thor.inlink.com (ultra.inlink.com [206.196.96.100]) by freefall.freebsd.org (8.8.6/8.8.5) with ESMTP id GAA19081 for ; Wed, 12 Nov 1997 06:17:55 -0800 (PST) Received: from shell. (rcdii@shell1.inlink.com [206.196.96.60]) by thor.inlink.com (8.8.7/V8) with SMTP id IAA19895 for ; Wed, 12 Nov 1997 08:19:47 -0600 (CST) Received: from localhost by shell. (SMI-8.6/SMI-SVR4) id IAA10657; Wed, 12 Nov 1997 08:19:37 -0600 Date: Wed, 12 Nov 1997 08:19:37 -0600 (CST) From: Robert Dunn X-Sender: rcdii@shell To: hackers@freebsd.com Subject: Subscribe Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Subscribe Thanks rcdii@inlink.com Suite 268, SJMMC, 621 S. New Ballas Rd., TEL 314-569-6386 St. Louis, Mo 63141 FAX 314-995-4111 From owner-freebsd-hackers Wed Nov 12 06:21:50 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id GAA06397 for hackers-outgoing; Wed, 12 Nov 1997 06:21:50 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from guacari.udem.edu.co ([206.114.14.85]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id GAA06381 for ; Wed, 12 Nov 1997 06:21:37 -0800 (PST) (envelope-from root@guacari.udem.edu.co) Received: from localhost (root@localhost) by guacari.udem.edu.co (8.8.5/8.8.5) with SMTP id EAA12921 for ; Wed, 12 Nov 1997 04:17:59 -0500 (EST) Date: Wed, 12 Nov 1997 04:17:58 -0500 (EST) From: Administrador UdeM To: freebsd-hackers@freebsd.org Subject: Problem with pop3 (popper) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi everyone, I'm obtain popper from ftp.freebsd.org/ports-217/qpopper..., nexrt, i active this but i obtain this message: +OK QPOP (version 2.4b2) at guacari.udem.edu.co starting. <12914.879326175@guac ari.udem.edu.co> user dlagb330 +OK Password required for dlagb330. pass -ERR System error, can't open temporary file, do you own it? +OK Pop server at guacari.udem.edu.co signing off. please, helpme. Thanks P.D. I use FreeBSD 2.1.7.1. From owner-freebsd-hackers Wed Nov 12 06:28:19 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id GAA06791 for hackers-outgoing; Wed, 12 Nov 1997 06:28:19 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from mail.virginia.edu (mail.Virginia.EDU [128.143.2.9]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id GAA06785 for ; Wed, 12 Nov 1997 06:28:13 -0800 (PST) (envelope-from atf3r@cs.virginia.edu) Received: from ares.cs.virginia.edu by mail.virginia.edu id aa22736; 12 Nov 97 9:28 EST Received: from stretch.cs.virginia.edu (atf3r@stretch-fo.cs.Virginia.EDU [128.143.136.14]) by ares.cs.Virginia.EDU (8.8.5/8.8.5) with ESMTP id JAA07782; Wed, 12 Nov 1997 09:28:06 -0500 (EST) Received: (from atf3r@localhost) by stretch.cs.virginia.edu (8.8.5/8.8.5) id JAA11610; Wed, 12 Nov 1997 09:28:05 -0500 (EST) Date: Wed, 12 Nov 1997 09:28:04 -0500 (EST) From: "Adrian T. Filipi-Martin" Reply-To: adrian@virginia.edu To: Tom cc: Alfred Perlstein , hackers@freebsd.org Subject: Re: LFS system? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Tue, 11 Nov 1997, Tom wrote: > > On Wed, 12 Nov 1997, Alfred Perlstein wrote: > > > has any though been put towards a log based File system? > > Lots. See mount_lfs code (keep in mind that it doesn't work). Do a > "man -k lfs" to get the whole picture. Yep, lots. Ousterhout, one of the designers of LFS, was at Berkely. I belive the BS support was put in by his group originally. The concept was first implemented under the SPRITE OS. It just hasn't been maintained in the 4.4BSD's though. :-( > > would it be a performance gain at all? i think it could be a major > > improvement on heavily modified file systems for instance on a large News > > server were a sync might take a few seconds to complete. > > Performance gain? I always though LFS files systems were slow, due to > the extra overhead. However, that overhead buys you security, and fast > filesystems checks during start up. LFS is fast for filesystems with lots of write activity. LFS is optimized for large reads and writes by always writing tracks and such in a single pass. Futhermore, disk blocks are never updated, they are just rewitten to a new location. The clean-up you allude to does need to be done asynchronously though by a cleaner-process. It is akin to garbage collection which make alot of people wrongly assume it has bad runtime performance or predictability. The log structure does provide nive data security, but it is also a performance booster. For more info look for a paper called "Breaking the I/O Bottleneck" by Ousterhout, et al. Adrian -- adrian@virginia.edu ---->>>>| If I were stranded on a desert island, and System Administrator --->>>| I could only have one OS for my computer, Neurosurgical Visualzation Lab -->>| it would be FreeBSD. Think about it..... http://www.nvl.virginia.edu/ ->| http://www.freebsd.org/ From owner-freebsd-hackers Wed Nov 12 06:49:22 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id GAA07925 for hackers-outgoing; Wed, 12 Nov 1997 06:49:22 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from guacari.udem.edu.co ([206.114.14.85]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id GAA07911 for ; Wed, 12 Nov 1997 06:48:59 -0800 (PST) (envelope-from root@guacari.udem.edu.co) Received: from localhost (root@localhost) by guacari.udem.edu.co (8.8.5/8.8.5) with SMTP id EAA13457 for ; Wed, 12 Nov 1997 04:45:11 -0500 (EST) Date: Wed, 12 Nov 1997 04:45:10 -0500 (EST) From: Administrador UdeM Reply-To: Administrador UdeM To: freebsd-hackers@freebsd.org Subject: Problems to make a new Kernel Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi, I'm configure (compile) FreeBSD 2.1.7.1 and i receive this message: cc -c -O -W -Wreturn-type -Wcomment -Wredundant-decls -Wimplicit -nostdinc -I. -I../.. -I../../sys -I/usr/include -DNEXTSTEP -DI586_CPU -DI486_CPU -DI386_CPU - DATAPI -DSYSVMSG -DSYSVSEM -DSYSVSHM -DVISUAL_USERCONFIG -DUSERCONFIG -DUCONSOLE -DBOUNCE_BUFFERS -DSCSI_DELAY=15 -DCOMPAT_43 -DPROCFS -DCD9660 -DMSDOSFS -DNFS -DFFS -DINET -DMATH_EMULATE -DSYSVSHM -DLINUX -DQUOTA -DKERNEL -Di386 -DLOAD_ADD RESS=0xF0100000 ../../i386/i386/machdep.c *** Error code 1 Stop. My configuration file is: # # GENERIC -- Generic machine with WD/AHx/NCR/BTx family disks # # $Id: GENERIC,v 1.46.2.19 1996/10/16 02:20:56 jkh Exp $ # machine "i386" cpu "I386_CPU" cpu "I486_CPU" cpu "I586_CPU" ident NextSTEP maxusers 32 options QUOTA options LINUX options SYSVSHM options MATH_EMULATE #Support for x87 emulation options INET #InterNETworking options FFS #Berkeley Fast Filesystem options NFS #Network Filesystem options MSDOSFS #MSDOS Filesystem options "CD9660" #ISO 9660 Filesystem options PROCFS #Process filesystem options "COMPAT_43" #Compatible with BSD 4.3 options "SCSI_DELAY=15" #Be pessimistic about Joe SCSI device options BOUNCE_BUFFERS #include support for DMA bounce buffers options UCONSOLE #Allow users to grab the console options USERCONFIG #boot -c editor options VISUAL_USERCONFIG #visual boot -c editor options SYSVSHM options SYSVSEM options SYSVMSG config kernel root on wd0 controller isa0 controller eisa0 controller pci0 controller fdc0 at isa? port "IO_FD1" bio irq 6 drq 2 vector fdintr disk fd0 at fdc0 drive 0 disk fd1 at fdc0 drive 1 tape ft0 at fdc0 drive 2 controller wdc0 at isa? port "IO_WD1" bio irq 14 vector wdintr disk wd0 at wdc0 drive 0 disk wd1 at wdc0 drive 1 controller wdc1 at isa? port "IO_WD2" bio irq 15 vector wdintr disk wd2 at wdc1 drive 0 disk wd3 at wdc1 drive 1 options ATAPI #Enable ATAPI support for IDE bus device wcd0 #IDE CD-ROM controller ncr0 controller ahb0 controller ahc0 controller bt0 at isa? port "IO_BT0" bio irq ? vector bt_isa_intr controller uha0 at isa? port "IO_UHA0" bio irq ? drq 5 vector uhaintr controller aha0 at isa? port "IO_AHA0" bio irq ? drq 5 vector ahaintr controller aic0 at isa? port 0x340 bio irq 11 vector aicintr controller nca0 at isa? port 0x1f88 bio irq 10 vector ncaintr controller nca1 at isa? port 0x350 bio irq 5 vector ncaintr controller sea0 at isa? bio irq 5 iomem 0xc8000 iosiz 0x2000 vector seaintr controller scbus0 device sd0 device st0 device cd0 #Only need one of these, the code dynamically grows device wt0 at isa? port 0x300 bio irq 5 drq 1 vector wtintr device mcd0 at isa? port 0x300 bio irq 10 vector mcdintr controller matcd0 at isa? port 0x230 bio device scd0 at isa? port 0x230 bio # syscons is the default console driver, resembling an SCO console device sc0 at isa? port "IO_KBD" tty irq 1 vector scintr # Enable this and PCVT_FREEBSD for pcvt vt220 compatible console driver #device vt0 at isa? port "IO_KBD" tty irq 1 vector pcrint #options "PCVT_FREEBSD=210" # pcvt running on FreeBSD 2.1 #options XSERVER # include code for XFree86 # If you have a ThinkPAD, uncomment this along with the rest of the PCVT lines #options PCVT_SCANSET=2 # IBM keyboards are non-std # Mandatory, don't remove device npx0 at isa? port "IO_NPX" irq 13 vector npxintr # # Laptop support (see LINT for more options) # #device apm0 at isa? # Advanced Power Management #options APM_BROKEN_STATCLOCK # Workaround some buggy APM BIOS device sio0 at isa? port "IO_COM1" tty irq 4 vector siointr device sio1 at isa? port "IO_COM2" tty irq 3 vector siointr device sio2 at isa? disable port "IO_COM3" tty irq 5 vector siointr device sio3 at isa? disable port "IO_COM4" tty irq 9 vector siointr device lpt0 at isa? port? tty irq 7 vector lptintr device lpt1 at isa? port? tty device mse0 at isa? port 0x23c tty irq 5 vector mseintr device psm0 at isa? disable port "IO_KBD" conflicts tty irq 12 vector psmintr # Order is important here due to intrusive probes, do *not* alphabetize # this list of network interfaces until the probes have been fixed. # Right now it appears that the ie0 must be probed before ep0. See # revision 1.20 of this file. device de0 device fxp0 device vx0 device ed0 at isa? port 0x280 net irq 5 iomem 0xd8000 vector edintr device ed1 at isa? port 0x300 net irq 5 iomem 0xd8000 vector edintr device ie0 at isa? port 0x360 net irq 7 iomem 0xd0000 vector ieintr device ep0 at isa? port 0x300 net irq 10 vector epintr device ix0 at isa? port 0x300 net irq 10 iomem 0xd0000 iosiz 32768 vector ixintr device le0 at isa? port 0x300 net irq 5 iomem 0xd0000 vector le_intr device lnc0 at isa? port 0x280 net irq 10 drq 0 vector lncintr device ze0 at isa? port 0x300 net irq 5 iomem 0xd8000 vector zeintr device zp0 at isa? port 0x300 net irq 10 iomem 0xd8000 vector zpintr pseudo-device loop pseudo-device ether pseudo-device log pseudo-device sl 1 # ijppp uses tun instead of ppp device #pseudo-device ppp 1 pseudo-device tun 1 pseudo-device pty 16 pseudo-device gzip # Exec gzipped a.out's What's wrong????? Thanks for all! From owner-freebsd-hackers Wed Nov 12 06:58:38 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id GAA08435 for hackers-outgoing; Wed, 12 Nov 1997 06:58:38 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from implode.root.com (implode.root.com [198.145.90.17]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id GAA08430; Wed, 12 Nov 1997 06:58:35 -0800 (PST) (envelope-from root@implode.root.com) Received: from implode.root.com (localhost [127.0.0.1]) by implode.root.com (8.8.5/8.8.5) with ESMTP id GAA08154; Wed, 12 Nov 1997 06:50:22 -0800 (PST) Message-Id: <199711121450.GAA08154@implode.root.com> To: Zoltan Sebestyen cc: FreeBSD questions mailinglist , FreeBSD hackers mailinglist Subject: Re: Q: about procfs In-reply-to: Your message of "Wed, 12 Nov 1997 13:04:04 +0100." From: David Greenman Reply-To: dg@root.com Date: Wed, 12 Nov 1997 06:50:22 -0800 Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >I'd like to know what will be the future of procfs on FreeBSD. Will it >provide more information about the system and the processes like it does >on Linux, or will I have to keep using kernel calls like the kvm_ >functions? This question raises everytime I port a Linux application that >uses procfs to gain some pieces of system level information. For most system information, I prefer the sysctl mechanism. For process information, I prefer procfs. We'll be extending both of these interfaces in the future to provide more information. -DG David Greenman Core-team/Principal Architect, The FreeBSD Project From owner-freebsd-hackers Wed Nov 12 07:26:45 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id HAA10563 for hackers-outgoing; Wed, 12 Nov 1997 07:26:45 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from labinfo.iet.unipi.it (labinfo.iet.unipi.it [131.114.9.5]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id HAA10540 for ; Wed, 12 Nov 1997 07:26:29 -0800 (PST) (envelope-from luigi@labinfo.iet.unipi.it) Received: from localhost (luigi@localhost) by labinfo.iet.unipi.it (8.6.5/8.6.5) id PAA07129; Wed, 12 Nov 1997 15:16:57 +0100 From: Luigi Rizzo Message-Id: <199711121416.PAA07129@labinfo.iet.unipi.it> Subject: Re: A stylistic question... To: adrian@virginia.edu Date: Wed, 12 Nov 1997 15:16:57 +0100 (MET) Cc: hackers@freebsd.org In-Reply-To: from "Adrian T. Filipi-Martin" at Nov 12, 97 09:16:39 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > > > usage() > > { > > printf( "%s", "bla bla bla...\n" > > "bla bla bla...\n" > > ... > > "bla bla bla...\n"); > > } ... > > Any reason not to use the second method ? > > Not really. It will compile into slightly smaller code and it > will have better runtime performance since there will only one function > call to printf(). > > Why do yo feel that you need the "%s" though? Just make the > "blah..." your format string. The parsing of the format string is pretty > efficient. It reads a char and then switch()'s on it to what to do. the "%s" was added on the fly while composing the message and not knowing the details of format string parsing. After your clarification, then the only possible usefulness is that one must not worry to escape % chars ... a very weak motivation indeed. Luigi -----------------------------+-------------------------------------- Luigi Rizzo | Dip. di Ingegneria dell'Informazione email: luigi@iet.unipi.it | Universita' di Pisa tel: +39-50-568533 | via Diotisalvi 2, 56126 PISA (Italy) fax: +39-50-568522 | http://www.iet.unipi.it/~luigi/ _____________________________|______________________________________ From owner-freebsd-hackers Wed Nov 12 07:30:06 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id HAA10887 for hackers-outgoing; Wed, 12 Nov 1997 07:30:06 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from lab321.ru (anonymous1.omsk.net.ru [194.226.32.34]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id HAA10639 for ; Wed, 12 Nov 1997 07:27:43 -0800 (PST) (envelope-from Eugeny.Kuzakov@lab321.ru) Received: from lab321.ru (kev.l321.omsk.net.ru [194.226.33.68]) by lab321.ru (8.8.5-MVC-230497/8.8.5) with ESMTP id VAA07016; Wed, 12 Nov 1997 21:20:12 +0600 (OSK) Message-ID: <346A1DF8.6AC36E98@lab321.ru> Date: Wed, 12 Nov 1997 21:22:00 +0000 From: Eugeny Kuzakov X-Mailer: Mozilla 4.03b8 [en] (X11; I; FreeBSD 3.0-971022-SNAP i386) MIME-Version: 1.0 To: Administrador UdeM CC: freebsd-hackers@FreeBSD.ORG Subject: Re: Problem with pop3 (popper) References: Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Administrador UdeM wrote: > > Hi everyone, I'm obtain popper from ftp.freebsd.org/ports-217/qpopper..., > nexrt, i active this but i obtain this message: > > +OK QPOP (version 2.4b2) at guacari.udem.edu.co starting. > ?12914.879326175@guac > ari.udem.edu.co? > user dlagb330 > +OK Password required for dlagb330. > pass ?my password? > -ERR System error, can't open temporary file, do you own it? > +OK Pop server at guacari.udem.edu.co signing off. For every new user you should do same: > /var/mail/.username.pop chown username /var/mail/.username.pop chmod go-rwx /var/mail/.username.pop -- Best wishes, Eugeny Kuzakov Laboratory 321 ( Omsk, Russia ) kev@lab321.ru From owner-freebsd-hackers Wed Nov 12 07:45:49 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id HAA12075 for hackers-outgoing; Wed, 12 Nov 1997 07:45:49 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from anlsun.ebr.anlw.anl.gov (anlsun.ebr.anlw.anl.gov [141.221.1.2]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id HAA12065 for ; Wed, 12 Nov 1997 07:45:46 -0800 (PST) (envelope-from cmott@srv.net) Received: from darkstar.home (tc-if3-21.ida.net [208.141.171.126]) by anlsun.ebr.anlw.anl.gov (8.6.11/8.6.11) with SMTP id IAA08072; Wed, 12 Nov 1997 08:45:22 -0700 Date: Wed, 12 Nov 1997 08:44:49 -0700 (MST) From: Charles Mott X-Sender: cmott@darkstar.home To: doconnor@ist.flinders.edu.au cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Dial on demand with dynamic IP In-Reply-To: <199711121115.VAA04516@holly.rd.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On successive dialups where different IPs are assigned, it is not possible to maintain a continuous tcp connection from any computer on your network -- either the ppp host or any box which is being NAT'ed by ppp -alias. >From the ISP side of things, if caller-id was available to the network access server (NAS), then it might actually be possible to hack radius so that it preferrentially hands over the same IP address when someone redials within 5 minutes. If there are any ISPs that have caller-id and want to experiment a little, I am willing to write some experimental code here. I think that under periods of light to medium load, it probably would work pretty well. Charles Mott On Wed, 12 Nov 1997, Daniel J. O'Connor wrote: > Hi, > I was wondering if it was possible to get dial on demand working with a > dynamic IP. I realise it would be difficult, and as far as I can tell you'd > _need_ IP aliasing, but how I envisage it working would be as follows. > > Run an app that sends a packet(telnet, mail.. whatever)0 > The PPP process dials up, and then gets the IP it's to use, and then aliases > the packet according to that IP. > Everything works like normal :) > > I think this would be possible with IJPPP but I'm not sure (you'd have to make > sure the aliasing happens at the right time - ie after any dialup event). > > Is it worth a try? Is anyone alreay doing it? :) > > --------------- > Daniel O'Connor > 3rd Year Computer Science at Flinders University > http://www.geocities.com.au/CapeCanaveral/7200 > > > > From owner-freebsd-hackers Wed Nov 12 07:46:32 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id HAA12142 for hackers-outgoing; Wed, 12 Nov 1997 07:46:32 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from zeus.carroll.com (zeus.carroll.com [199.224.10.2]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id HAA12129 for ; Wed, 12 Nov 1997 07:46:27 -0800 (PST) (envelope-from jim@carroll.com) Received: from apollo.carroll.com [199.224.10.3] by zeus.carroll.com with ESMTP (8.8.5/0) id KAA20534; Wed, 12 Nov 1997 10:46:24 -0500 Received: by apollo.carroll.com (8.8.5) is KAA17640; Wed, 12 Nov 1997 10:45:18 -0500 Date: Wed, 12 Nov 1997 10:45:16 -0500 From: Jim Carroll To: Administrador UdeM cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Problem with pop3 (popper) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Wed, 12 Nov 1997, Administrador UdeM wrote: > Date: Wed, 12 Nov 1997 04:17:58 -0500 (EST) > From: Administrador UdeM > To: freebsd-hackers@FreeBSD.ORG > Subject: Problem with pop3 (popper) > > > Hi everyone, I'm obtain popper from ftp.freebsd.org/ports-217/qpopper..., > nexrt, i active this but i obtain this message: > > +OK QPOP (version 2.4b2) at guacari.udem.edu.co starting. > <12914.879326175@guac > ari.udem.edu.co> > user dlagb330 > +OK Password required for dlagb330. > pass > -ERR System error, can't open temporary file, do you own it? > +OK Pop server at guacari.udem.edu.co signing off. The POP drop used by poppper for this user has someone elses permissions. Check your POP_DROP (constant defined in popper.h) to see if a popdrop exists for this user. On my system, this is set to /var/tmp. If the pop drop has another users permissions, just delete the drop file. popper will re-create it as necessary. The most likely cause of this problem is you deleted, then re-created this user's account. When they were re-created, the permissions on the drop file were set to the users old uid. They were now locked out. --- Jim C., President | C A R R O L L - N E T, Inc. 201-488-1332 | New Jersey's Premier Internet Service Provider www.carroll.com | | Want to make your business more competitive, and | at the same time, decrease costs? Ask about the www.message-server.com | Carroll-Net Message Server. From owner-freebsd-hackers Wed Nov 12 08:13:35 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id IAA14087 for hackers-outgoing; Wed, 12 Nov 1997 08:13:35 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from tick.ssec.wisc.edu (tick.ssec.wisc.edu [144.92.108.121]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id IAA14079 for ; Wed, 12 Nov 1997 08:13:30 -0800 (PST) (envelope-from dglo@tick.ssec.wisc.edu) Received: from tick.ssec.wisc.edu (localhost [127.0.0.1]) by tick.ssec.wisc.edu (8.8.7/8.8.7) with ESMTP id KAA28670; Wed, 12 Nov 1997 10:02:59 -0600 (CST) From: Dave Glowacki Message-Id: <199711121602.KAA28670@tick.ssec.wisc.edu> X-Mailer: exmh version 2.0zeta 7/24/97 To: adrian@virginia.edu cc: Luigi Rizzo , hackers@freebsd.org Subject: Re: A stylistic question... In-reply-to: Your message of "Wed, 12 Nov 1997 09:16:58 EST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 12 Nov 1997 10:02:59 -0600 Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Adrian T. Filipi-Martin wrote: > On Wed, 12 Nov 1997, Luigi Rizzo wrote: > > > > usage() > > { > > printf( "%s", "bla bla bla...\n" > > "bla bla bla...\n" > > ... > > "bla bla bla...\n"); > > } > > Why do yo feel that you need the "%s" though? Probably because somebody will eventually change "printf("bla blah bla\n");" to "printf("bla bla 17%\n");" or something more insidious... From owner-freebsd-hackers Wed Nov 12 08:45:38 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id IAA16557 for hackers-outgoing; Wed, 12 Nov 1997 08:45:38 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from horst.bfd.com (horst.bfd.com [204.160.242.10]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id IAA16549 for ; Wed, 12 Nov 1997 08:45:29 -0800 (PST) (envelope-from ejs@bfd.com) Received: from harlie.bfd.com (bastion.bfd.com [204.160.242.14]) by horst.bfd.com (8.8.5/8.7.3) with SMTP id IAA05474; Wed, 12 Nov 1997 08:45:20 -0800 (PST) Date: Wed, 12 Nov 1997 08:45:20 -0800 (PST) From: "Eric J. Schwertfeger" To: gad@eclipse.its.rpi.edu cc: hackers@FreeBSD.ORG Subject: Re: Virtual Intel Machines? In-Reply-To: <9711120909.AA16549@mlor.its.rpi.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Wed, 12 Nov 1997, Garance A Drosehn wrote: > In the land of IBM mainframes, there's an operating system (of > sorts) called VM. This is an operating system which lets you run > multiple operating systems on a single machine, at the same time. > VM can allocate devices between the running systems, so that one > running OS sees a given hard disk (for example), but no other > operating systems can possibly get to that hard disk. > > What I was wondering is if something similar could be done with > Intel-ish chips? I realize this wouldn't be a trivial thing to > write, but it'd be mighty convenient to have in some circumstances > (at least in an academic setting). Not in the strictest sense, because Intel, in their infinite wisdom, decided that certain privledged instructions, if executed in an unprivledged state, would not trap, but rather reduce to a NOP. Hence, the VM equiv can't trap the OS's attempt to do this, and make it happen, given appropriate permissions. From owner-freebsd-hackers Wed Nov 12 09:32:30 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id JAA20136 for hackers-outgoing; Wed, 12 Nov 1997 09:32:30 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from db2server.voga.com.br (db2server.voga.com.br [200.239.39.7]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id JAA20122 for ; Wed, 12 Nov 1997 09:32:23 -0800 (PST) (envelope-from Daniel_Sobral@voga.com.br) Received: from papagaio.voga.com.br (papagaio.voga.com.br [200.239.39.2]) by db2server.voga.com.br (8.8.3+2.6Wbeta9/8.8.7) with SMTP id OAA14332 for ; Wed, 12 Nov 1997 14:29:45 -0300 Received: by papagaio.voga.com.br(Lotus SMTP MTA v1.06 (346.7 3-18-1997)) id 0325654D.0060199D ; Wed, 12 Nov 1997 14:29:40 -0300 X-Lotus-FromDomain: VOGA From: "Daniel Sobral" To: hackers@FreeBSD.ORG Message-ID: <0325654D.005FFDE1.00@papagaio.voga.com.br> Date: Wed, 12 Nov 1997 14:29:27 -0300 Subject: Re: mv /usr/src/games /dev/null - any objections? Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Well, though this matter is probably set by now, I'd really like pom to be available somehow (ports or otherwise). (not to mention fortune, of course) From owner-freebsd-hackers Wed Nov 12 09:44:25 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id JAA20941 for hackers-outgoing; Wed, 12 Nov 1997 09:44:25 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from spiv.fnal.gov (spiv.fnal.gov [131.225.124.126]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id JAA20936 for ; Wed, 12 Nov 1997 09:44:22 -0800 (PST) (envelope-from neswold@spiv.fnal.gov) Received: from localhost (neswold@localhost) by spiv.fnal.gov (8.8.5/8.8.5) with SMTP id LAA20802 for ; Wed, 12 Nov 1997 11:44:19 -0600 (CST) Date: Wed, 12 Nov 1997 11:44:19 -0600 (CST) From: "Richard M. Neswold" Reply-To: neswold@fnal.gov To: FreeBSD-Hackers Subject: Pentium Bug Fix... Message-ID: X-Spambot-Food: abuse@localhost postmaster@localhost abuse@fbi.gov MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Apparently Intel has helped BSDI in creating a fix to the Pentium bug: ftp://ftp.bsdi.com/bsdi/patches/patches-3.1/M310-hangfix Rich ------------------------------------------------------------------------ Richard Neswold, Accelerator Div./Controls Dept | neswold@fnal.gov Fermilab, PO Box 500, MS 347, Batavia, IL 60510 | voice (630) 840-3454 'finger neswold@aduxb.fnal.gov' for PGP key | fax (630) 840-3093 From owner-freebsd-hackers Wed Nov 12 10:00:05 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id KAA22309 for hackers-outgoing; Wed, 12 Nov 1997 10:00:05 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from out1.ibm.net (out1.ibm.net [165.87.194.252]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id JAA22208 for ; Wed, 12 Nov 1997 09:59:59 -0800 (PST) (envelope-from mouth@ibm.net) Received: from slip129-37-195-100.nc.us.ibm.net (slip129-37-195-100.nc.us.ibm.net [129.37.195.100]) by out1.ibm.net (8.8.5/8.6.9) with SMTP id RAA51370; Wed, 12 Nov 1997 17:58:44 GMT From: mouth@ibm.net (John Kelly) To: Bruce Evans Cc: hackers@freebsd.org Subject: Re: Status of 650 UART support Date: Wed, 12 Nov 1997 18:59:59 GMT Message-ID: <3469e29a.47593226@smtp-gw01.ny.us.ibm.net> References: <199711120647.RAA10782@godzilla.zeta.org.au> In-Reply-To: <199711120647.RAA10782@godzilla.zeta.org.au> X-Mailer: Forte Agent 1.01/16.397 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by hub.freebsd.org id KAA22209 Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Wed, 12 Nov 1997 17:47:08 +1100, Bruce Evans wrote: >>Did you know that the 650 UART has on-chip "auto" RTS flow control >On some (early? all?) 16650s it is said to be just a pessimization >to use it, since it is invoked when the trigger level is reached, >so it is invoked for almost every input interrupt. It may seem like a pessimization if your ISR always starts quickly enough to avoid UART overruns. However, when using a 550 UART, presumably the serial ISR could safely raise RTS as its first duty when the FIFO trigger level has been reached, since the external device would be expected to have a large buffer of its own. If true, then why not have the 650 chip raise RTS automatically? That buys insurance against interrupt latency, pessimistically or not. Don't tell me you don't have life insurance. :-) Does the sio.c ISR raise RTS when servicing a UART trigger level interrupt, or does it simply drain the UART FIFO while letting the external device keep streaming inbound bytes? If the latter is true, I can see how 650 auto RTS might be viewed as a pessimization, although it's still unclear to me whether it might cause any loss of efficiency. >I don't know what happens when the driver sets RTS directly. The Startech databook says: > RTS pin will be forced to high state regardless of its original > state when receive FIFO reaches to the programmed trigger > level. RTS pin resumes it original state after content of the > data buffer (FIFO) drops below the next lower trigger level. > ... hardware ... flow controls can be enabled for automatic > operation. During these conditions the ST16C650 will accept > additional data to fill the unused ... recieve FIFO locations. My understanding of this is: 1) The 650 RTS pin honors the driver setting, unless overridden by the automatic on-chip RTS, and in all cases the on-chip value takes precedence. In other words, the 650 does not change the value set by the driver, it simply hides it when it wants to raise RTS on its own. Or in yet other words, the state of the actual UART RTS pin results from ORing MCR bit 1 (RTS controlled by the software driver) and the current state of the auto on-chip RTS. 2) Receive (not transmit) FIFO trigger levels, 550 vs. 650: FCR bit 7 and 6 550 650 00 1 8 01 4 16 10 8 24 11 14 28 If the software driver sets FCR to "10" as you would expect in the case of a 550 UART, the 650 trigger level will actually be 24 and the next lower trigger level will be 16. The excerpt from the databook above indicates that when using auto RTS, the chip will raise RTS as soon as the external device fills the UART up to its trigger lever of 24. Perhaps one more byte will come into the UART before the external can recognize RTS and stop streaming. At that point the FIFO interrupt should invoke the ISR which will drain enough bytes to cause the UART to drop RTS when 16 bytes, the next lower trigger level, remain in the UART. At that instant, the external device will start streaming again because the chip dropped RTS, unless of course, the software driver had raised it, in which case the external device will remain silent until the ISR drains the UART completely and drops RTS again. Since the behavior will be different depending on whether the ISR raises RTS or not, I need to learn how sio.c acts in that regard. > Perhaps auto flow control interferes with this and causes your buffer > overflows. Possible fix: turn off auto flow control at least when clearing > RTS directly. Turning auto flow control on once when opening your device is fine, but turning it off and back on again during data transfer would cause a loss of efficiency. You must first write hex "BF" to the LCR to make the EFR visible, then you must set bit 6 in the EFR, then you must restore the previous value to the LCR. Not to mention the fact that changing the LCR values even momentarily to make the EFR visible may cause unexpected side effects or bring out heretofore unknown bugs in the 650 chip, as the LCR controls word size and parity. I would not feel safe changing the LCR after establishing communications with the external device. It should not be necessary anyway, since as stated by the databook, auto RTS vs. driver RTS will have no adverse impact on each other. >I think the best available setup is to use 16550 mode with the tx fifo >size set to match the flow control. The 16650 configuration is too >specific - it forces 16650 flow control and a 32 byte tx fifo size. I don't follow you here. FCR bits 5 and 4 on the 650 allow setting the transmit FIFO to 16, 8, 24, or 30. The default is 16. However, none of these are in effect unless, as the databook says: > ... user can write to transmit trigger levels but activation will not > take place till ST16C650 special mode is selected (EFR bit-4 > is set to "1"). > ... to be compatible with ... 550, 1 bytes transmit trigger level is > selected after reset. So if you don't set EFR bit 4, the 650 transmit FIFO is still only one byte just like a 550. And I don't recall seeing any code in sio.c to set EFR bit 4. Whew! I'm getting hungry. I'll have to analyze the rest of your message later. John From owner-freebsd-hackers Wed Nov 12 10:38:40 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id KAA25677 for hackers-outgoing; Wed, 12 Nov 1997 10:38:40 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from sasami.jurai.net (winter@sasami.jurai.net [207.96.1.17]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id KAA25660 for ; Wed, 12 Nov 1997 10:38:33 -0800 (PST) (envelope-from winter@jurai.net) Received: from localhost (winter@localhost) by sasami.jurai.net (8.8.7/8.8.7) with SMTP id NAA19694; Wed, 12 Nov 1997 13:38:05 -0500 (EST) Date: Wed, 12 Nov 1997 13:38:04 -0500 (EST) From: "Matthew N. Dodd" To: adrian@virginia.edu cc: Tom , Alfred Perlstein , hackers@FreeBSD.ORG Subject: Re: LFS system? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Wed, 12 Nov 1997, Adrian T. Filipi-Martin wrote: > Yep, lots. Ousterhout, one of the designers of LFS, was at > Berkely. I belive the BS support was put in by his group originally. The > concept was first implemented under the SPRITE OS. It just hasn't been > maintained in the 4.4BSD's though. :-( I think it works only slightly better under Sprite than it does under 4.4. I was lucky to go an hour with LFS under Sprite. Switching to the other Sprite filesystem made the machines fairly well behaved. /* Matthew N. Dodd | A memory retaining a love you had for life winter@jurai.net | As cruel as it seems nothing ever seems to http://www.jurai.net/~winter | go right - FLA M 3.1:53 */ From owner-freebsd-hackers Wed Nov 12 10:57:27 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id KAA27610 for hackers-outgoing; Wed, 12 Nov 1997 10:57:27 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from whistle.com (s205m131.whistle.com [207.76.205.131]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id KAA27596 for ; Wed, 12 Nov 1997 10:57:22 -0800 (PST) (envelope-from archie@whistle.com) Received: (from smap@localhost) by whistle.com (8.7.5/8.6.12) id KAA05087; Wed, 12 Nov 1997 10:56:47 -0800 (PST) Received: from bubba.whistle.com(207.76.205.7) by whistle.com via smap (V1.3) id sma005085; Wed Nov 12 10:56:34 1997 Received: (from archie@localhost) by bubba.whistle.com (8.8.5/8.6.12) id KAA09309; Wed, 12 Nov 1997 10:56:25 -0800 (PST) From: Archie Cobbs Message-Id: <199711121856.KAA09309@bubba.whistle.com> Subject: Re: mpd -- configuration for "server" side? In-Reply-To: <87n2ja8zag.fsf@absinthe.i3inc.com> from Chris Shenton at "Nov 12, 97 00:19:19 am" To: chris@absinthe.i3inc.com (Chris Shenton) Date: Wed, 12 Nov 1997 10:56:25 -0800 (PST) Cc: hackers@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-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Chris Shenton writes: > 1. On the "server side" I see complaints in the logs which usually, > after 6 repetitions or so, have caused the "server" to drop the link: > > Nov 12 00:16:06 Placebo mpd: [usr0] LCP: no reply to 1 echo request(s) This is normal.. the point of sending echo requests is that sometimes a modem will freeze/crap out without dropping CD, or the remote server will die without hanging up the modem, or whatever. The only way to detect these situations is with LCP echos. You can adjust the interval and the maximum failure count in mpd.conf, or disable it altogether if you like. > 3. Triggering demand causes the client side to attempt to re-establish > the link, but the *server* is still sitting there at LCP DEAD. It > never goes back to waiting by the phone. How to I get it to reset > so that it will handle repeated incoming demand dials? Don't have an idle timeout on the server... set bundle idle 0 This is kindof broken that you have to do this... > 4. Can I set it up so that demand is there to ensure that if the link > goes down it will get re-established, but that it never times out > from being idle? My POTS line is unmetered, but I have a finite > amount of "free" calls I can make per month. Does idle=0 imply > infinite connection? (or hangup immediately, like an Ascend? :-) Yes, idle 0 is what you want here. > 5. Something in my mpd.conf and/or mpd.links sometimes generates "Line > too long, truncated" warnings. The error doesn't identify which > file, line number, or the line contents. It seems usually to associated > with the "load log-normal" if the "log-normal:" specifier has stuff > after it like miscellaneous comments, possibly even separated with > the desired blank line. It would be real nice to have file:line > identifiers to track this down, or at least a dislay of the > offending line. Perhaps there's some confusion parsing the file > looking for the last hunk and my trailing comments may be throwing > it off? Good idea... thanks. Hash-sign (#) comments should start at the beginning of the line, btw. -Archie ___________________________________________________________________________ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com From owner-freebsd-hackers Wed Nov 12 11:16:09 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id LAA29238 for hackers-outgoing; Wed, 12 Nov 1997 11:16:09 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from out2.ibm.net (out2.ibm.net [165.87.194.229]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id LAA29233 for ; Wed, 12 Nov 1997 11:16:05 -0800 (PST) (envelope-from mouth@ibm.net) Received: from slip129-37-195-100.nc.us.ibm.net (slip129-37-195-100.nc.us.ibm.net [129.37.195.100]) by out2.ibm.net (8.8.5/8.6.9) with SMTP id TAA24812; Wed, 12 Nov 1997 19:14:30 GMT From: mouth@ibm.net (John Kelly) To: Bruce Evans Cc: hackers@freebsd.org Subject: Re: Status of 650 UART support Date: Wed, 12 Nov 1997 20:15:45 GMT Message-ID: <346d0534.56453013@smtp-gw01.ny.us.ibm.net> References: <199711120647.RAA10782@godzilla.zeta.org.au> In-Reply-To: <199711120647.RAA10782@godzilla.zeta.org.au> X-Mailer: Forte Agent 1.01/16.397 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by hub.freebsd.org id LAA29234 Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Wed, 12 Nov 1997 17:47:08 +1100, Bruce Evans wrote: >A 64-byte fifo probably won't work unless the fifo trigger level is >reduced (defeating the point of the larger fifo). There may be just >enough margin if the default (highest) trigger level is enough below >64. Why won't a 64-byte FIFO work? Is it for the same reason as stated in the following excerpt from sio.c? >#ifdef COM_ESP > if (com->esp) { > /* > * Set 16550 compatibility mode. > * We don't use the ESP_MODE_SCALE bit to increase the > * fifo trigger levels because we can't handle large > * bursts of input. Why can't we handle large bursts of input? >I think the best available setup is to use 16550 mode with the tx fifo >size set to match the flow control. I do not understand "tx fifo size set to match the flow control." >The 16650 configuration is too specific - it forces 16650 flow > control and a 32 byte tx fifo size. As mentioned in my earlier response, transmit FIFO can be set independently of receive FIFO. And by default, transmit FIFO is set to one byte like the 550. I don't see why that is bad. >The interrupt latency is low enough for auto flow control to be >unnecessary in most cases (and there is another 6 character times of >slop available by reducing the 16550 trigger level from 14 to 8 to >handle overloaded cases). Perhaps true, but it won't hurt to have hardware insurance against interrupt latency. I already paid for the insurance when I bought the 650. I would like to use it, as long as it does not cause any loss of efficiency. >Another problem with auto flow control is that it doesn't actually >work if the sender can't stop soon enough. E.g., if the sender is >a 16550, then it can't reasonably stop before sending 16 characters >if it has 16 characters in its tx fifo. Why not? When auto CTS is activated with EFR bit 7, the 650 will stop sending if the external device drops CTS, even with bytes remaining in the transmit FIFO. That should have no adverse impact on sio.c, should it? It's all internal to the chip itself. >The receiver must have a rx fifo trigger level 16+ below the fifo size > to handle this completely in hardware (+ = a few more to give the > interrupt handler time to run before flow control is actually invoked). Yes, but I don't see why the design of the 650 would make you want to handle it completely in hardware. If the 650 will merely raise RTS on its own, telling the external device to stop streaming, that should enhance the operation of sio.c without any negative side effects, as far as I can see. >16+ below the 16650 fifo size of 32 is too many. 16+ below the 16654 > fifo size of 64 is better. If I was trying to handle it completely in hardware, I could set FCR bits 7 and 6 to "00" to give a 650 trigger level of 8, similar to a 550, and also have 24 bytes of headroom. But I'm not trying to handle it completely in hardware, I only want the hardware and sio.c to cooperate. I'm learning much from this discussion. I only want to be sure I have an accurate understanding of what you are saying. >>I increased the software buffer size from 256 to 512, and that seemed >>to reduce the number of overflows, but a burst of disk activity would >>still trigger one even with the larger buffer. > >That breaks the watermarks in the tty buffer unless the tty buffer size >(TTYHOG) is increased too. I'm only testing with PPPD. Does it use tty buffers? John From owner-freebsd-hackers Wed Nov 12 11:32:58 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id LAA00470 for hackers-outgoing; Wed, 12 Nov 1997 11:32:58 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from dfw-ix2.ix.netcom.com (dfw-ix2.ix.netcom.com [206.214.98.2]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id LAA00463 for ; Wed, 12 Nov 1997 11:32:55 -0800 (PST) (envelope-from wghhicks@ix.netcom.com) Received: (from smap@localhost) by dfw-ix2.ix.netcom.com (8.8.4/8.8.4) id NAA10122; Wed, 12 Nov 1997 13:31:50 -0600 (CST) Received: from atl-ga9-05.ix.netcom.com(199.183.210.101) by dfw-ix2.ix.netcom.com via smap (V1.3) id rma009969; Wed Nov 12 13:31:17 1997 Message-ID: <346A03FA.FB710E25@ix.netcom.com> Date: Wed, 12 Nov 1997 14:31:06 -0500 From: Jerry Hicks Reply-To: jerry_hicks@bigfoot.com Organization: TerraEarth X-Mailer: Mozilla 4.03b8 [en] (X11; I; FreeBSD 2.2.5-STABLE i386) MIME-Version: 1.0 To: neswold@fnal.gov CC: FreeBSD-Hackers Subject: Re: Pentium Bug Fix... References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Richard M. Neswold wrote: > > Apparently Intel has helped BSDI in creating a fix to the Pentium bug: > > ftp://ftp.bsdi.com/bsdi/patches/patches-3.1/M310-hangfix > > Rich > > ------------------------------------------------------------------------ > Richard Neswold, Accelerator Div./Controls Dept | neswold@fnal.gov > Fermilab, PO Box 500, MS 347, Batavia, IL 60510 | voice (630) 840-3454 > 'finger neswold@aduxb.fnal.gov' for PGP key | fax (630) 840-3093 And I get: The M310-hangfix beta patch is unavailable at the moment. We'll keep everyone posted. Sounds stable. From owner-freebsd-hackers Wed Nov 12 11:35:05 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id LAA00715 for hackers-outgoing; Wed, 12 Nov 1997 11:35:05 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from smtp03.primenet.com (smtp03.primenet.com [206.165.5.84]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id LAA00668 for ; Wed, 12 Nov 1997 11:34:45 -0800 (PST) (envelope-from tlambert@usr09.primenet.com) Received: (from daemon@localhost) by smtp03.primenet.com (8.8.7/8.8.7) id MAA28917; Wed, 12 Nov 1997 12:34:41 -0700 (MST) Received: from usr09.primenet.com(206.165.6.209) via SMTP by smtp03.primenet.com, id smtpd028911; Wed Nov 12 12:34:36 1997 Received: (from tlambert@localhost) by usr09.primenet.com (8.8.5/8.8.5) id MAA04831; Wed, 12 Nov 1997 12:34:33 -0700 (MST) From: Terry Lambert Message-Id: <199711121934.MAA04831@usr09.primenet.com> Subject: Re: A stylistic question... To: luigi@labinfo.iet.unipi.it (Luigi Rizzo) Date: Wed, 12 Nov 1997 19:34:33 +0000 (GMT) Cc: adrian@virginia.edu, hackers@FreeBSD.ORG In-Reply-To: <199711121416.PAA07129@labinfo.iet.unipi.it> from "Luigi Rizzo" at Nov 12, 97 03:16:57 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > Why do yo feel that you need the "%s" though? Just make the > > "blah..." your format string. The parsing of the format string is pretty > > efficient. It reads a char and then switch()'s on it to what to do. > > the "%s" was added on the fly while composing the message and not > knowing the details of format string parsing. After your clarification, > then the only possible usefulness is that one must not worry to > escape % chars ... a very weak motivation indeed. Use puts(): it will also aboid the formatting code. Actually use "fputs()" and specify stderr, where usage messages are supposed be sent. The motivation in using "fprintf()" in that case is to specify stderr up front instead if as an after though that people might not reaad to. It's defensible that the stream should be the first, not last, argument to "fputs()". Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Wed Nov 12 13:05:15 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id NAA08801 for hackers-outgoing; Wed, 12 Nov 1997 13:05:15 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from shell6.ba.best.com (root@shell6.ba.best.com [206.184.139.137]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id NAA08786 for ; Wed, 12 Nov 1997 13:05:10 -0800 (PST) (envelope-from bannai@shell6.ba.best.com) Received: (from bannai@localhost) by shell6.ba.best.com (8.8.7/8.7.3) id NAA11130; Wed, 12 Nov 1997 13:04:04 -0800 (PST) From: Vinay Bannai Message-Id: <199711122104.NAA11130@shell6.ba.best.com> Subject: Re: Problems to make a new Kernel In-Reply-To: from Administrador UdeM at "Nov 12, 97 04:45:10 am" To: root@guacari.udem.edu.co Date: Wed, 12 Nov 1997 13:04:04 -0800 (PST) Cc: freebsd-hackers@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL32 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk According to Administrador UdeM: > > Hi, I'm configure (compile) FreeBSD 2.1.7.1 and i receive this message: > > cc -c -O -W -Wreturn-type -Wcomment -Wredundant-decls -Wimplicit > -nostdinc -I. > -I../.. -I../../sys -I/usr/include -DNEXTSTEP -DI586_CPU -DI486_CPU > -DI386_CPU - > DATAPI -DSYSVMSG -DSYSVSEM -DSYSVSHM -DVISUAL_USERCONFIG -DUSERCONFIG > -DUCONSOLE > -DBOUNCE_BUFFERS -DSCSI_DELAY=15 -DCOMPAT_43 -DPROCFS -DCD9660 -DMSDOSFS Please do not post these questions to hackers mailing list. There is a separate mailing list for these types of questions. As it is I am having trouble keeping up with hackers mailing list volume... Thanks Vinay -- Vinay Bannai E-mail: bannai@best.com From owner-freebsd-hackers Wed Nov 12 13:09:26 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id NAA09092 for hackers-outgoing; Wed, 12 Nov 1997 13:09:26 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from inertia.dfacades.com (inertia.dfacades.com [207.155.93.5]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id NAA09070; Wed, 12 Nov 1997 13:09:21 -0800 (PST) (envelope-from dleeds@dfacades.com) Received: (from dleeds@localhost) by inertia.dfacades.com (8.8.7/8.8.7) id NAA18379; Wed, 12 Nov 1997 13:12:42 -0800 (PST) From: Daniel Leeds Message-Id: <199711122112.NAA18379@inertia.dfacades.com> Subject: adaptec pcmcia scsi To: hackers@freebsd.org Date: Wed, 12 Nov 1997 13:12:42 -0800 (PST) Cc: questions@freebsd.org X-Mailer: ELM [version 2.4ME+ PL35 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi, I have an adaptec slim-scsi 1460 pcmcia card i am desperately trying to get to be recognized and used by my laptop running freebsd 2.2.5 to no avail. upon boot, its seen by the ze driver (which runs my ibm pcmcia ethernet) and reports as an adaptec scsi controller. but i cannot get it to be recognized by pccard i have an adaptec entry in pccard.conf, and i enabled pccard in /etc/rc.conf but nothing works. i also added the aic driver and the st and sd drivers in my kernel since the pccard.conf shows it to use aic0 as the controller. im at a loss here. s someone help! :))) thanks From owner-freebsd-hackers Wed Nov 12 13:55:07 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id NAA12766 for hackers-outgoing; Wed, 12 Nov 1997 13:55:07 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from smtp03.primenet.com (smtp03.primenet.com [206.165.5.84]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id NAA12753 for ; Wed, 12 Nov 1997 13:55:00 -0800 (PST) (envelope-from tlambert@usr05.primenet.com) Received: (from daemon@localhost) by smtp03.primenet.com (8.8.7/8.8.7) id OAA07028; Wed, 12 Nov 1997 14:54:57 -0700 (MST) Received: from usr05.primenet.com(206.165.6.205) via SMTP by smtp03.primenet.com, id smtpd006993; Wed Nov 12 14:54:48 1997 Received: (from tlambert@localhost) by usr05.primenet.com (8.8.5/8.8.5) id OAA20137; Wed, 12 Nov 1997 14:54:42 -0700 (MST) From: Terry Lambert Message-Id: <199711122154.OAA20137@usr05.primenet.com> Subject: Re: Status of 650 UART support To: mouth@ibm.net (John Kelly) Date: Wed, 12 Nov 1997 21:54:42 +0000 (GMT) Cc: bde@zeta.org.au, hackers@FreeBSD.ORG In-Reply-To: <346d0534.56453013@smtp-gw01.ny.us.ibm.net> from "John Kelly" at Nov 12, 97 08:15:45 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > >#ifdef COM_ESP > > if (com->esp) { > > /* > > * Set 16550 compatibility mode. > > * We don't use the ESP_MODE_SCALE bit to increase the > > * fifo trigger levels because we can't handle large > > * bursts of input. > > Why can't we handle large bursts of input? Bruce can correct me, but I believe it's because the FASTINTR code expects to run to completion, and that expectation means that it can't take more than a small amount of time to process the interrupt. Processing the additional caharacters puts it over the limit. > Yes, but I don't see why the design of the 650 would make you want to > handle it completely in hardware. If the 650 will merely raise RTS on > its own, telling the external device to stop streaming, that should > enhance the operation of sio.c without any negative side effects, as > far as I can see. > > >16+ below the 16650 fifo size of 32 is too many. 16+ below the 16654 > > fifo size of 64 is better. > > If I was trying to handle it completely in hardware, I could set FCR > bits 7 and 6 to "00" to give a 650 trigger level of 8, similar to a > 550, and also have 24 bytes of headroom. But I'm not trying to handle > it completely in hardware, I only want the hardware and sio.c to > cooperate. I don't think you can split interrupt types for this. I think the reason the code is FASTINTR code is so that it can deal with the characters and prevent an input overflow. If you can do that in hardware, you should instead of doing it via FASTINTR to reduce the amount of code you actually run at high spl. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Wed Nov 12 13:57:41 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id NAA13010 for hackers-outgoing; Wed, 12 Nov 1997 13:57:41 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from smtp03.primenet.com (smtp03.primenet.com [206.165.5.84]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id NAA12999 for ; Wed, 12 Nov 1997 13:57:38 -0800 (PST) (envelope-from tlambert@usr05.primenet.com) Received: (from daemon@localhost) by smtp03.primenet.com (8.8.7/8.8.7) id OAA07269; Wed, 12 Nov 1997 14:57:37 -0700 (MST) Received: from usr05.primenet.com(206.165.6.205) via SMTP by smtp03.primenet.com, id smtpd007243; Wed Nov 12 14:57:30 1997 Received: (from tlambert@localhost) by usr05.primenet.com (8.8.5/8.8.5) id OAA20294; Wed, 12 Nov 1997 14:57:26 -0700 (MST) From: Terry Lambert Message-Id: <199711122157.OAA20294@usr05.primenet.com> Subject: Re: LFS system? To: adrian@virginia.edu Date: Wed, 12 Nov 1997 21:57:26 +0000 (GMT) Cc: tom@sdf.com, perlsta@cs.sunyit.edu, hackers@FreeBSD.ORG In-Reply-To: from "Adrian T. Filipi-Martin" at Nov 12, 97 09:28:04 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > Yep, lots. Ousterhout, one of the designers of LFS, was at > Berkely. I belive the BS support was put in by his group originally. The > concept was first implemented under the SPRITE OS. It just hasn't been > maintained in the 4.4BSD's though. :-( FWIW: Margo Seltzer has been maintaining this code in BSD -- just not in FreeBSD specifically. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Wed Nov 12 14:29:06 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id OAA15765 for hackers-outgoing; Wed, 12 Nov 1997 14:29:06 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from out5.ibm.net (out5.ibm.net [165.87.194.245]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id OAA15759 for ; Wed, 12 Nov 1997 14:29:04 -0800 (PST) (envelope-from mouth@ibm.net) Received: from slip129-37-53-67.ca.us.ibm.net (slip129-37-53-67.ca.us.ibm.net [129.37.53.67]) by out5.ibm.net (8.8.5/8.6.9) with SMTP id WAA30020; Wed, 12 Nov 1997 22:28:28 GMT From: mouth@ibm.net (John Kelly) To: Terry Lambert Cc: bde@zeta.org.au, hackers@FreeBSD.ORG Subject: Re: Status of 650 UART support Date: Wed, 12 Nov 1997 23:29:39 GMT Message-ID: <346b36af.1755787@smtp-gw01.ny.us.ibm.net> References: <199711122154.OAA20137@usr05.primenet.com> In-Reply-To: <199711122154.OAA20137@usr05.primenet.com> X-Mailer: Forte Agent 1.01/16.397 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by hub.freebsd.org id OAA15761 Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Wed, 12 Nov 1997 21:54:42 +0000 (GMT), Terry Lambert wrote: >> Why can't we handle large bursts of input? > >Bruce can correct me, but I believe it's because the FASTINTR code >expects to run to completion, and that expectation means that it >can't take more than a small amount of time to process the interrupt. >Processing the additional caharacters puts it over the limit. Anybody know how high the limit is? >> Yes, but I don't see why the design of the 650 would make you want to >> handle it completely in hardware. >I don't think you can split interrupt types for this. I think the >reason the code is FASTINTR code is so that it can deal with the >characters and prevent an input overflow. If you can do that in >hardware, you should The 650 auto RTS function is "automatic" -- the chip knows when to raise RTS and suspend the input stream from the external device. In that sense, we would be "doing it in hardware." But that does not mean doing it "all" in hardware. My reason for wanting to use 650 auto RTS is to guarantee that interrupt latency will never cause the UART to be overrun and sio.c report silo overflows. I don't see that it matters whether it's ever invoked or not -- sio.c should be able to work pretty much the way it always has. > instead of doing it via FASTINTR to reduce the amount of code you > actually run at high spl. I don't want to split interrupt types. The serial ISR running at high privilege level can continue working the way it always has. The 650 auto RTS should work transparently to sio.c, with perhaps a few minor changes to accommodate the auto RTS/CTS and larger FIFO buffers. Someone has already tried to do this in sio.c, but it's not working right yet -- with auto RTS/CTS enabled, interrupt-level overflows occur. I'm trying to understand why so I can hack mine to make it work right. John From owner-freebsd-hackers Wed Nov 12 15:00:56 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id PAA17851 for hackers-outgoing; Wed, 12 Nov 1997 15:00:56 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from whistle.com (s205m131.whistle.com [207.76.205.131]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id PAA17845 for ; Wed, 12 Nov 1997 15:00:53 -0800 (PST) (envelope-from archie@whistle.com) Received: (from smap@localhost) by whistle.com (8.7.5/8.6.12) id PAA06960 for ; Wed, 12 Nov 1997 15:00:22 -0800 (PST) Received: from bubba.whistle.com(207.76.205.7) by whistle.com via smap (V1.3) id sma006958; Wed Nov 12 15:00:13 1997 Received: (from archie@localhost) by bubba.whistle.com (8.8.5/8.6.12) id PAA10914 for freebsd-hackers@freebsd.org; Wed, 12 Nov 1997 15:00:13 -0800 (PST) From: Archie Cobbs Message-Id: <199711122300.PAA10914@bubba.whistle.com> Subject: unkillable process To: freebsd-hackers@freebsd.org Date: Wed, 12 Nov 1997 15:00:13 -0800 (PST) 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-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Try the following experiment (on 2.2 and mabye 3.0): 1. Create a named pipe 2. Start typing into it using cat 3. Hit control-C as many times as you want You'll see that the process will not die even with kill -9, as it is stuck in uninterrupible disk sleep ("fifo"). But as soon as you read from the other end of the pipe, the process exits. Is there a missing PCATCH flag to tsleep() somewhere? Is this appropriate behavior? (hint: rhetorical question) Just Curious, -Archie ___________________________________________________________________________ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com From owner-freebsd-hackers Wed Nov 12 15:02:49 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id PAA18012 for hackers-outgoing; Wed, 12 Nov 1997 15:02:49 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from frmug.org (frmug-gw.frmug.org [193.56.58.252]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id PAA17995 for ; Wed, 12 Nov 1997 15:02:41 -0800 (PST) (envelope-from roberto@keltia.freenix.fr) Received: (from uucp@localhost) by frmug.org (8.8.8/frmug-2.1/nospam) with UUCP id AAA29895 for hackers@FreeBSD.ORG; Thu, 13 Nov 1997 00:02:36 +0100 (CET) (envelope-from roberto@keltia.freenix.fr) Received: (from roberto@localhost) by keltia.freenix.fr (8.8.7/keltia-2.12/nospam) id AAA07276; Thu, 13 Nov 1997 00:00:14 +0100 (CET) (envelope-from roberto) Message-ID: <19971113000014.04668@keltia.freenix.fr> Date: Thu, 13 Nov 1997 00:00:14 +0100 From: Ollivier Robert To: hackers@FreeBSD.ORG Subject: Re: Perl 5.004 References: <19971112083449.00854@keltia.freenix.fr> <199711121137.DAA05116@Gatekeeper.Alameda.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84 In-Reply-To: <199711121137.DAA05116@Gatekeeper.Alameda.net>; from Ulf Zimmermann on Wed, Nov 12, 1997 at 03:37:20AM -0800 X-Operating-System: FreeBSD 3.0-CURRENT ctm#3797 AMD-K6 MMX @ 208 MHz Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk According to Ulf Zimmermann: > Thanks, that was it. I know, I got bitten during pre-5.004 testing after upgrading to 8.1... > Should I submit the perl5.004_04 port ? -current is still 5.004_01 Please do. I have no date for 5.004_05 for the moment so having the port updated would be nice. -- Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- roberto@keltia.freenix.fr FreeBSD keltia.freenix.fr 3.0-CURRENT #48: Sat Nov 8 18:08:59 CET 1997 From owner-freebsd-hackers Wed Nov 12 15:33:36 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id PAA20138 for hackers-outgoing; Wed, 12 Nov 1997 15:33:36 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from battra.telebase.com (mail@battra.telebase.com [192.132.57.100]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id PAA20112 for ; Wed, 12 Nov 1997 15:33:30 -0800 (PST) (envelope-from rjc@n2k.com) Received: (from mail@localhost) by battra.telebase.com (8.8.3/8.8.1) id SAA21825; Wed, 12 Nov 1997 18:33:25 -0500 (EST) Received: from unknown(172.16.2.129) by battra.telebase.com via smap/n2k (V1.3) id sma021812; Wed Nov 12 18:32:56 1997 Received: from nog.telebase.com (nog.telebase.com [172.16.2.211]) by wormhole.telebase.com (8.8.5/8.8.1) with ESMTP id SAA14964; Wed, 12 Nov 1997 18:32:55 -0500 (EST) Received: from nog.telebase.com (localhost.telebase.com [127.0.0.1]) by nog.telebase.com (8.8.1/8.8.1) with SMTP id SAA10323; Wed, 12 Nov 1997 18:32:55 -0500 (EST) Message-ID: <346A3CA7.237C228A@n2k.com> Date: Wed, 12 Nov 1997 19:32:55 -0400 From: Richard Costine X-Mailer: Mozilla 3.0Gold (X11; I; FreeBSD 2.1.5-RELEASE i386) MIME-Version: 1.0 To: hackers@FreeBSD.ORG CC: ejs@bfd.com, gad@eclipse.its.rpi.edu Subject: Re: Virtual Intel Machines? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk I'm an old VM'er myself, and often wondered about this. From what I remember, VM did (does) run virtual machine code on the real machine until a privop is encountered. It does make the distinction between Virtual supervisor state and Virtual user (problem) state. There's also Real supervisor state and a real problem state. Unless things have changed, CMS (the loose equivalent of VM's shell) always runs in supervisor state under a virtual machine. Virtual machines run in real problem state. The nucleus or VM's kernel code runs in real supervisor state. So, when the CMS "operating system" makes a system call (in Mainframe lingo - an SVC) control is transferred to a subroutine that runs in the Virtual Address space of that virtual machine by the "real" VM operating system. There are ways to "talk" to the actual underlying emulator, or VM nucleus. The way you do it is by using the "Diagnose" instruction - a real 370 instruction (X'83'). On the real machine, "Diagnose" is the garbage can of instructions - it's hardware dependent. If run "virtually", it effects a "hypervisor" call, which doesn't generate a privileged operation execption in the virtual machine because the virtual machine is a "process" running in real problem state and is virtually allowed to run virtual privileged operations, and the diagnose instruction is run. However, when this happens the "real" privop exception handler gets invoked and the diagnose instruction is handled by a subroutine in the VM nucleus (or kernel). Virtual diagnoses are used for lots of things, block reading of minidisks, VMCF and IUCV (akin to message queues in Unix), getting the VM OS Level, Virtual console handling - there's lots of 'em. There's somewhat more to it than that, there's different classes of users (A-Z) and unlike unix, a user (virtual machine) can only log on once. Different classes can do different "diagnoses" and "cp" commands (which are done by a "diagnose 8"). Classes are not inclusive - that is class F users may be able to to things that Class A users can't, but generally lower letters (A,B,C) give you the equivalent of superuser, but I digress. Given the way Intel has designed its architecture, I agree that you couldn't do it exactly the way that VM is doing it. You would have to emulate everything. That is you would need to write a program that simulates an Intel 486/Pentium/Pentium-pro architecture. The opcodes that work differently in the non-privileged state would need to be emulated so as to produce a virtual trap, that is the emulation software would simulate the trap. This would make the emulator much slower than a real pentium, but with the speed of today's processors, now in the 200MhZ range, it may be able to simulate at least to the speed of a 50Mhz 486 or even a low speed pentium (75MHz). Yes, this would be a "Nice Thing to Have". It opens up lots of possibilities. You could have a real sandbox to run intel-based code in. We all know there's lots of that about. You could run Windows 95 or even NT under FreeBSD (you would need a copy of those operating systems), kind of like "DOSEMU". You could bring up the next version of freebsd under freebsd. You could perhaps (if you run multiple emulators on the same box) simulate a network of PCs all with virtual ethernet cards. Are you afraid of running that latest ".exe" file that someone sent you? Fire up the emulator with your basic Windows 95 "C" disk junk on a "minidisk" - run the .exe file they sent. If it is virused, you'll booger up the virtual environment. Who cares? Blow it away after you're done - you have a copy of the "minidisk" (which is merely a file on freebsd) somewhere to use for another emulaed session. The point is not how fast it'll run but *that* it'll run. > From: "Eric J. Schwertfeger" > Date: Wed, 12 Nov 1997 08:45:20 -0800 (PST) > Subject: Re: Virtual Intel Machines? > To: gad@eclipse.its.rpi.edu > Cc: hackers@FreeBSD.ORG > > On Wed, 12 Nov 1997, Garance A Drosehn wrote: > > > In the land of IBM mainframes, there's an operating system (of > > sorts) called VM. This is an operating system which lets you run > > multiple operating systems on a single machine, at the same time. > > VM can allocate devices between the running systems, so that one > > running OS sees a given hard disk (for example), but no other > > operating systems can possibly get to that hard disk. > > > > What I was wondering is if something similar could be done with > > Intel-ish chips? I realize this wouldn't be a trivial thing to > > write, but it'd be mighty convenient to have in some circumstances > > (at least in an academic setting). > > Not in the strictest sense, because Intel, in their infinite wisdom, > decided that certain privledged instructions, if executed in an > unprivledged state, would not trap, but rather reduce to a NOP. Hence, > the VM equiv can't trap the OS's attempt to do this, and make it happen, > given appropriate permissions. From owner-freebsd-hackers Wed Nov 12 15:38:47 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id PAA20718 for hackers-outgoing; Wed, 12 Nov 1997 15:38:47 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from burka.carrier.kiev.ua ([195.145.31.17]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id PAA20615 for ; Wed, 12 Nov 1997 15:38:14 -0800 (PST) (envelope-from archer@grape.carrier.kiev.ua) Received: from sivka.carrier.kiev.ua (root@sivka.carrier.kiev.ua [193.193.193.101]) by burka.carrier.kiev.ua (8.8.6/8.Who.Cares) with ESMTP id BAA25563 for ; Thu, 13 Nov 1997 01:05:35 +0200 (EET) Received: from bucefal.carrier.kiev.ua (bucefal.carrier.kiev.ua [193.193.193.110]) by sivka.carrier.kiev.ua (8.8.7/8.8.7) with ESMTP id BAA08017 for ; Thu, 13 Nov 1997 01:05:36 +0200 (EET) Received: (from uucp@localhost) by bucefal.carrier.kiev.ua (8.8.6/8.8.6/8.Who.Cares) with UUCP id BAA17798 for hackers@freebsd.org; Thu, 13 Nov 1997 01:05:02 +0200 (EET) Received: (from archer@localhost) by grape.carrier.kiev.ua (8.8.7/8.8.7) id AAA00743; Thu, 13 Nov 1997 00:48:51 +0200 (EET) Message-ID: <19971113004848.26628@grape.carrier.kiev.ua> Date: Thu, 13 Nov 1997 00:48:48 +0200 From: Alexander Litvin To: hackers@freebsd.org Subject: 2.2-stable, panic Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi, hackers! It's not the first time I'm asking here for some help. Though before I haven't received substantial assistance, where else can I ask for it? So, again, sorry for bothering you. That's 2.2.5-STABLE, CVSupped and built at November 11. P-II 266Mhz, ASUS P2L97 MB, 128M RAM, Adaptec 2940U, 3 IBM DCAS-34330W SCSI drives (ccd'ed), Intel EtherExpress ethernet (100M). Proxy server. May be, I just miss something? There was a message about PMAP_SHPGPERPROC, though I'm not sure if it is what hits me. Below I tried to provide as much info as I can imagine is necessary. Crash dump is still available, so I can examine it further. Alexander Litvin P.S. Not directly connected to the topic, but the wierd thing happened with the same box once. I noticed that there were two usless devices in kernel - ed0 and ed1 (left there from kernel config made from GENERIC). I decided that it was time to get rid of them, and rebuild kernel without ed0/ed1. But when a box came up and squid started, in a minute it was in a state then ping gave "No buffer space available"! ifconfig down/up helped for a 5-10 seconds, then it repeated :( I decided to put that ed0/ed1 back, and the problem dissappiared. There you still can see that dummy ed0/1 in dmesg output :-\ ----------------------------------------------------------------------------- bash# dmesg Copyright (c) 1992-1997 FreeBSD Inc. Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. FreeBSD 2.2.5-STABLE #0: Wed Nov 12 20:02:39 EET 1997 archer@zebra.carrier.kiev.ua:/usr/local/squid/src/sys/compile/zebra.s CPU: Pentium Pro (267.27-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x633 Stepping=3 Features=0x80f9ff,MTRR,PGE,MCA,CMOV> real memory = 134217728 (131072K bytes) avail memory = 129732608 (126692K bytes) Probing for devices on PCI bus 0: chip0 rev 3 on pci0:0 chip1 rev 3 on pci0:1 chip2 rev 1 on pci0:4:0 pci0:4:1: Intel Corporation, device=0x7111, class=storage (ide) [no driver assigned] pci0:4:2: Intel Corporation, device=0x7112, class=0x0c, subclass=0x03 int d irq 11 [no driver assigned] chip3 rev 1 on pci0:4:3 fxp0 rev 1 int a irq 12 on pci0:10 fxp0: Ethernet address 00:a0:c9:1c:a3:3f vga0 rev 227 int a irq 14 on pci0:11 ahc0 rev 0 int a irq 15 on pci0:12 ahc0: aic7880 Wide Channel, SCSI Id=7, 16 SCBs (ahc0:0:0): "IBM DCAS-34330W S61A" type 0 fixed SCSI 2 sd0(ahc0:0:0): Direct-Access 4134MB (8467200 512 byte sectors) sd0(ahc0:0:0): with 8205 cyls, 6 heads, and an average 171 sectors/track (ahc0:1:0): "IBM DCAS-34330W S61A" type 0 fixed SCSI 2 sd1(ahc0:1:0): Direct-Access 4134MB (8467200 512 byte sectors) sd1(ahc0:1:0): with 8205 cyls, 6 heads, and an average 171 sectors/track (ahc0:2:0): "IBM DCAS-34330W S61A" type 0 fixed SCSI 2 sd2(ahc0:2:0): Direct-Access 4134MB (8467200 512 byte sectors) sd2(ahc0:2:0): with 8205 cyls, 6 heads, and an average 171 sectors/track Probing for devices on PCI bus 1: Probing for devices on the ISA bus: sc0 at 0x60-0x6f irq 1 on motherboard sc0: VGA color <16 virtual consoles, flags=0x0> ed0 not found at 0x280 ed1 not found at 0x300 sio0 not found at 0x3f8 fdc0: direction bit not set fdc0: cmd 3 failed at out byte 1 of 3 fdc0 not found at 0x3f0 npx0 flags 0x7 on motherboard npx0: INT 16 interface ccd0-3: Concatenated disk drivers ----------------------------------------------------------------------------- bash# 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 1c3000 current pcb at 1ac980 panic: page fault #0 boot (howto=260) at ../../kern/kern_shutdown.c:266 266 dumppcb.pcb_cr3 = rcr3(); (kgdb) bt #0 boot (howto=260) at ../../kern/kern_shutdown.c:266 #1 0xf01116e2 in panic (fmt=0xf017b84f "page fault") at ../../kern/kern_shutdown.c:390 #2 0xf017c3b6 in trap_fatal (frame=0xf01a0d18) at ../../i386/i386/trap.c:742 #3 0xf017bea4 in trap_pfault (frame=0xf01a0d18, usermode=0) at ../../i386/i386/trap.c:653 #4 0xf017bb7f in trap (frame={tf_es = 16, tf_ds = 16, tf_edi = 0, tf_esi = -202662272, tf_ebp = -266728092, tf_isp = -266728128, tf_ebx = -201014528, tf_edx = 0, tf_ecx = -206575104, tf_eax = -200789120, tf_trapno = 12, tf_err = 0, tf_eip = -267186362, tf_cs = 8, tf_eflags = 66118, tf_esp = 0, tf_ss = -201014528}) at ../../i386/i386/trap.c:311 #5 0xf0130f46 in vget (vp=0xf404c300, lockflag=1) at ../../kern/vfs_subr.c:817 #6 0xf015cd3c in ffs_sync (mp=0xf3b07400, waitfor=2, cred=0xf20ad880, p=0xf01b7ab4) at ../../ufs/ffs/ffs_vfsops.c:819 #7 0xf0132407 in sync (p=0xf01b7ab4, uap=0x0, retval=0x0) at ../../kern/vfs_syscalls.c:360 #8 0xf01112ed in boot (howto=256) at ../../kern/kern_shutdown.c:199 #9 0xf01116e2 in panic (fmt=0xf017b84f "page fault") at ../../kern/kern_shutdown.c:390 #10 0xf017c3b6 in trap_fatal (frame=0xf01a0e9c) at ../../i386/i386/trap.c:742 #11 0xf017bea4 in trap_pfault (frame=0xf01a0e9c, usermode=0) at ../../i386/i386/trap.c:653 #12 0xf017bb7f in trap (frame={tf_es = -233046000, tf_ds = 16, tf_edi = -234080244, tf_esi = 1103282625, tf_ebp = -266727700, tf_isp = -266727740, tf_ebx = 60, tf_edx = 37648, tf_ecx = -206539140, tf_eax = 124, tf_trapno = 12, tf_err = 0, tf_eip = -267116173, tf_cs = 8, tf_eflags = 66070, tf_esp = 40, tf_ss = 0}) at ../../i386/i386/trap.c:311 #13 0xf0142173 in in_pcblookuphash (pcbinfo=0xf01b80f4, faddr={ s_addr = 1103282625}, fport_arg=37648, laddr={s_addr = 1640088001}, lport_arg=14348, wildcard=1) at ../../netinet/in_pcb.c:677 #14 0xf0147091 in tcp_input (m=0xf2155500, iphlen=20) at ../../netinet/tcp_input.c:362 #15 0xf0143bd4 in ip_input (m=0xf2155500) at ../../netinet/ip_input.c:564 #16 0xf0143c4c in ipintr () at ../../netinet/ip_input.c:585 ------------------------------------------------------------------------ machine "i386" ident zerba maxusers 160 options "MAXDSIZ=(256*1024*1024)" options "DFLDSIZ=(256*1024*1024)" options FAILSAFE options INCLUDE_CONFIG_FILE # Include this file in kernel config kernel root on sd0 dumps on sd0 cpu "I686_CPU" # aka Pentium Pro(tm) options "COMPAT_43" options SYSVSHM options SYSVSEM options SYSVMSG options "MD5" options USERCONFIG #boot -c editor options VISUAL_USERCONFIG #visual boot -c editor options INET #Internet communications protocols pseudo-device ether #Generic Ethernet pseudo-device loop #Network loopback device options FFS #Fast filesystem options PROCFS #Process filesystem options NSWAPDEV=4 options QUOTA #enable disk quotas controller scbus0 #base SCSI code device sd0 #SCSI disks options SCSI_REPORT_GEOMETRY pseudo-device pty 32 #Pseudo ttys - can go as high as 256 pseudo-device speaker #Play IBM BASIC-style noises out your speaker pseudo-device log #Kernel syslog interface (/dev/klog) pseudo-device gzip #Exec gzipped a.out's pseudo-device vn #Vnode driver (turns a file into a device) pseudo-device snp 3 #Snoop device - to look at pty/vty/etc.. pseudo-device ccd 4 #Concatenated disk driver controller isa0 options "MAXMEM=(128*1024)" options BROKEN_KEYBOARD_RESET device sc0 at isa? port "IO_KBD" tty irq 1 vector scintr options MAXCONS=16 # number of virtual consoles device npx0 at isa? port "IO_NPX" iosiz 0x0 flags 0x7 irq 13 vector npxintr controller fdc0 at isa? port "IO_FD1" bio irq 6 drq 2 vector fdintr disk fd0 at fdc0 drive 0 device sio0 at isa? port "IO_COM1" tty irq 4 vector siointr device ed0 at isa? port 0x280 net irq 5 iomem 0xd8000 vector edintr device ed1 at isa? port 0x300 net irq 5 iomem 0xd8000 vector edintr controller pci0 controller ahc0 device fxp0 device vx0 From owner-freebsd-hackers Wed Nov 12 17:38:50 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id RAA00598 for hackers-outgoing; Wed, 12 Nov 1997 17:38:50 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from diablo.ppp.de (diablo.ppp.de [193.141.101.34]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id RAA00593 for ; Wed, 12 Nov 1997 17:38:42 -0800 (PST) (envelope-from Hanse.DE!Stefan.Bethke@ppp.de) Received: by diablo.ppp.de (Smail3.1.28.1 #1) id m0xVoEx-000Ta8C; Thu, 13 Nov 97 02:38 MET Received: from [193.141.161.123] (monster.pong.ppp.de [193.141.161.123]) by pong.PPP.DE (8.7.5/8.6.12) with ESMTP id BAA15899; Thu, 13 Nov 1997 01:55:12 +0100 (MET) X-Sender: stefan@pong.ppp.de Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 13 Nov 1997 01:38:04 +0100 To: freebsd-hackers@freebsd.org From: Stefan Bethke Subject: Eicon sync serial for IP? Cc: stefan@promo.de Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk For a private project, I'd like to use an old Eicon ISA card a friend will be donating to me to interface to a Cisco router. The Cisco has a sync X.21 or V.35 interface, to which my solution must connect to transport IP. Obviously, I'd like to use FreeBSD, but I'd accept any low-price (not not say: cheap) solution to route IP to an Ethernet or async PPP connection. Alternativly, another cheap sync card (<$200) would be OK. Or, a cheap sync-async adapter might work also. Any ideas? [ No, attaching any other way to the Cisco is impossible due to political reasons. ] Thanks, Stefan -- Stefan Bethke Hamburg, Germany From owner-freebsd-hackers Wed Nov 12 17:50:34 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id RAA01730 for hackers-outgoing; Wed, 12 Nov 1997 17:50:34 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from ns1.yes.no (ns1.yes.no [195.119.24.10]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id RAA01718 for ; Wed, 12 Nov 1997 17:50:30 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [194.198.43.36]) by ns1.yes.no (8.8.7/8.8.7) with ESMTP id BAA19129; Thu, 13 Nov 1997 01:50:06 GMT Received: (from eivind@localhost) by bitbox.follo.net (8.8.6/8.8.6) id CAA29329; Thu, 13 Nov 1997 02:50:00 +0100 (MET) Date: Thu, 13 Nov 1997 02:50:00 +0100 (MET) Message-Id: <199711130150.CAA29329@bitbox.follo.net> From: Eivind Eklund To: Brian Somers CC: doconnor@ist.flinders.edu.au, freebsd-hackers@FreeBSD.ORG In-reply-to: Brian Somers's message of Wed, 12 Nov 1997 12:31:20 +0000 Subject: Re: Dial on demand with dynamic IP References: <199711121115.VAA04516@holly.rd.net> <199711121231.MAA29463@awfulhak.demon.co.uk> Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk [Dial on demand with dynamic IP] > > Is it worth a try? Is anyone alreay doing it? :) > > This is only half the problem, but it would probably make things > better for most sites. > > The ``other'' problem is when a process bind()s to an IP number that > gets dynamically re-assigned. > > Perhaps the *real* answer is to never change the IP number of the > interface, and to change all IP numbers that are the same as the one > netogitated through IPCP to that of the interface. > > Hmmm, that would work wouldn't it ? Yeah, it'd likely work, but would deny one IP address from being accessed from your network. Not too big a loss, though. I'm doing it by using an interface route to tun and adding the dynamic addresses to the lo0 interface; I could probably just as well add them to tun, as long as the addresses are removed when the call is brought down - demand TCP streams must not bind to the addresses, and for an interface with addresses at demand time they will. Eivind. From owner-freebsd-hackers Wed Nov 12 18:21:53 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id SAA03882 for hackers-outgoing; Wed, 12 Nov 1997 18:21:53 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from dfw-ix6.ix.netcom.com (dfw-ix6.ix.netcom.com [206.214.98.6]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id SAA03876 for ; Wed, 12 Nov 1997 18:21:49 -0800 (PST) (envelope-from wghhicks@ix.netcom.com) Received: (from smap@localhost) by dfw-ix6.ix.netcom.com (8.8.4/8.8.4) id UAA13281 for ; Wed, 12 Nov 1997 20:21:12 -0600 (CST) Received: from atl-ga28-23.ix.netcom.com(206.214.125.87) by dfw-ix6.ix.netcom.com via smap (V1.3) id rma013224; Wed Nov 12 20:20:55 1997 Message-ID: <346A63FB.2A72AE76@ix.netcom.com> Date: Wed, 12 Nov 1997 21:20:43 -0500 From: Jerry Hicks Reply-To: jerry_hicks@bigfoot.com Organization: TerraEarth X-Mailer: Mozilla 4.03b8 [en] (X11; I; FreeBSD 2.2.5-STABLE i386) MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Subject: Pentium bug (really) Content-Type: multipart/mixed; boundary="------------F1DC78B07DA0C49CA7316A39" Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk This is a multi-part message in MIME format. --------------F1DC78B07DA0C49CA7316A39 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Found over in comp.os.qnx > > Geoff Roberts wrote: > > > I have a lot of friends who have Linux as they can't afford anything > > else in the way of a UNIX, and based on their experience with it, I > > wouldn't touch it with a barge pole. It's value I feel is in the fact > > that it *does* teach people about UNIX per se, but as a serious > > contender for industrial/high reliability (mission critical as they > > say) applications, I personally rank it alongside NT. And that is not > > very high. > > Perhaps your friends haven't read the HOWTOs or purchase cheap > hardware, but my experience with Linux is the opposite. I find it > remarkably stable (over 160 days of uptime on our main server). > > It also has one of the best "bug" fix rates I've ever seen. > Ping-of-Death, Flood SYN, etc.. And as of today, it's one of a > few OSes that have fixes for the Pentium f00f bug (the one that ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > locks up your system because of a bug in Intel's chip). > > Try it for yourself and see what it's like. > > - Paul Interesting... Jerry Hicks jerry_hicks@bigfoot.com --------------F1DC78B07DA0C49CA7316A39 Content-Type: message/rfc822 Content-Transfer-Encoding: 7bit Content-Disposition: inline Path: ix.netcom.com!visi.com!chippy.visi.com!news-out.visi.com!news.sprintisp.com!sprintisp!news-peer-west.sprintlink.net!news-peer.sprintlink.net!news-pull.sprintlink.net!news-in-east.sprintlink.net!news.sprintlink.net!Sprint!209.89.75.15!News.Toronto.iSTAR.net!News1.Ottawa.iSTAR.net!news.istar.net!news.achilles.net!not-for-mail From: "Paul J.Y. Lahaie" Newsgroups: comp.os.qnx Subject: Re: QNX vs Linux Date: Wed, 12 Nov 1997 23:20:49 +0000 Organization: Atlantis Scientific Inc. Message-ID: <346A39D1.9418FD00@atlsci.com> References: <63o5ik$ak0@qnx.com> <01bced67$b82c59e0$64930cc0@ta_sn_1> <647tql$5h8@drn.zippo.com> <346A0003.3CD8@cww.de> <3469807f.1509700@news.zippo.com> NNTP-Posting-Host: elenuial.atlsci.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 4.04 [en] (X11; I; Linux 2.1.63 i586) Xref: ix.netcom.com comp.os.qnx:16747 Geoff Roberts wrote: > I have a lot of friends who have Linux as they can't afford anything > else in the way of a UNIX, and based on their experience with it, I > wouldn't touch it with a barge pole. It's value I feel is in the fact > that it *does* teach people about UNIX per se, but as a serious > contender for industrial/high reliability (mission critical as they > say) applications, I personally rank it alongside NT. And that is not > very high. Perhaps your friends haven't read the HOWTOs or purchase cheap hardware, but my experience with Linux is the opposite. I find it remarkably stable (over 160 days of uptime on our main server). It also has one of the best "bug" fix rates I've ever seen. Ping-of-Death, Flood SYN, etc.. And as of today, it's one of a few OSes that have fixes for the Pentium f00f bug (the one that locks up your system because of a bug in Intel's chip). Try it for yourself and see what it's like. - Paul --------------F1DC78B07DA0C49CA7316A39-- From owner-freebsd-hackers Wed Nov 12 18:28:56 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id SAA04268 for hackers-outgoing; Wed, 12 Nov 1997 18:28:56 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from darius.concentric.net (root@darius.concentric.net [207.155.184.79]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id SAA04253 for ; Wed, 12 Nov 1997 18:28:48 -0800 (PST) (envelope-from j-f-h@concentric.net) Received: from mcfeely.concentric.net (mcfeely.concentric.net [207.155.184.83]) by darius.concentric.net (8.8.7/(97/09/12 5.7)) id VAA16882; Wed, 12 Nov 1997 21:28:37 -0500 (EST) [1-800-745-2747 The Concentric Network] Received: from concentric.net (ts002d31.lax-ca.concentric.net [206.173.239.91]) by mcfeely.concentric.net (8.8.7) id VAA03655; Wed, 12 Nov 1997 21:28:35 -0500 (EST) Message-ID: <346A65A8.51084007@concentric.net> Date: Wed, 12 Nov 1997 18:27:52 -0800 From: j-f-h Reply-To: j-f-h@concentric.net X-Mailer: Mozilla 4.04 [en] (Win95; I) MIME-Version: 1.0 To: freebsd-hackers@FreeBSD.ORG Subject: Mailing List Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Please include me in your FreeBSD technical discussions mailing list. I really appreciate it. From owner-freebsd-hackers Wed Nov 12 19:31:42 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id TAA08366 for hackers-outgoing; Wed, 12 Nov 1997 19:31:42 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from ren.dtir.qld.gov.au (firewall-user@ns.dtir.qld.gov.au [203.108.138.66]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id TAA08224 for ; Wed, 12 Nov 1997 19:30:36 -0800 (PST) (envelope-from syssgm@dtir.qld.gov.au) Received: by ren.dtir.qld.gov.au; id NAA06621; Thu, 13 Nov 1997 13:46:51 +1000 (EST) Received: from ogre.dtir.qld.gov.au(167.123.8.3) by ren.dtir.qld.gov.au via smap (3.2) id xma006614; Thu, 13 Nov 97 13:46:37 +1000 Received: from localhost.dtir.qld.gov.au (localhost.dtir.qld.gov.au [127.0.0.1]) by ogre.dtir.qld.gov.au (8.8.7/8.8.7) with SMTP id NAA24138; Thu, 13 Nov 1997 13:29:00 +1000 (EST) Message-Id: <199711130329.NAA24138@ogre.dtir.qld.gov.au> X-Authentication-Warning: ogre.dtir.qld.gov.au: localhost.dtir.qld.gov.au [127.0.0.1] didn't use HELO protocol To: "Adrian T. Filipi-Martin" , Luigi Rizzo cc: freebsd-hackers@freebsd.org, syssgm@dtir.qld.gov.au Subject: Re: A stylistic question... References: In-Reply-To: from "Adrian T. Filipi-Martin" at "Wed, 12 Nov 1997 14:16:58 +0000" Date: Thu, 13 Nov 1997 13:29:00 +1000 From: Stephen McKay Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Wednesday, 12th November 1997, "Adrian T. Filipi-Martin" wrote: >On Wed, 12 Nov 1997, Luigi Rizzo wrote: > >> I have always wondered about this: most if not all programs, and some >> pieces of the kernel as well (e.g. userconfig.c) >> have a menu/usage function which is written like this: >> >> usage() >> { >> printf( "bla bla bla...\n" ); >> printf( "bla bla bla...\n" ); >> printf( "bla bla bla...\n" ); >> ... >> printf( "bla bla bla...\n" ); >> } >> >> instead of what in my opinion would be much better: >> >> usage() >> { >> printf( "%s", "bla bla bla...\n" >> "bla bla bla...\n" >> ... >> "bla bla bla...\n"); >> } >> >> yes the code savings are modest (5-10 bytes/call ? but in the kernel >> or boot blocks they still matter...) but at runtime the second >> approach is faster since the format string must be parsed only once >> and it is the shortest possible. >> >> Any reason not to use the second method ? > > Not really. It will compile into slightly smaller code and it >will have better runtime performance since there will only one function >call to printf(). >That's one comparison per character. Printing a string using "%s" will >still need to do one comparison with each character when looking for '\0'. >The overhead of the indexed jump is probably not worth worying about. Yow! You guys are really counting the time it takes to print the usage string? How's your best time on an optimised idle loop? Step back a moment and consider the purpose of your code. If it is code for a boot block and is severely space constrained, consider using one puts() or even write() (maybe you can get rid of stdio completely). If it is a time critical subroutine, use some clever algorithm or even some assembler. But for a humble usage message, and indeed most normal code, the absolutely number one most important requirement is human readability. Your processor and memory subsystem is getting faster every year, but your programmers (yourself and others here) are just getting older and grumpier. :-) Pick whichever one looks most pleasing and easiest to understand. For my money, that is the first one. You are wasting your precious programmer time considering such marginal time and space costs. Stephen. From owner-freebsd-hackers Wed Nov 12 19:34:44 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id TAA08623 for hackers-outgoing; Wed, 12 Nov 1997 19:34:44 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from iclub.nsu.ru (iclub.nsu.ru [193.124.222.66]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id TAA08574 for ; Wed, 12 Nov 1997 19:34:39 -0800 (PST) (envelope-from max@iclub.nsu.ru) Received: from localhost (max@localhost) by iclub.nsu.ru (8.8.7/8.8.5) with SMTP id JAA22641 for ; Thu, 13 Nov 1997 09:35:11 +0600 (NS) Date: Thu, 13 Nov 1997 09:35:11 +0600 (NS) From: Max Khon To: freebsd-hackers@freebsd.org Subject: BSDI F0 bug workaround implementation Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi, there! ---------- Forwarded message ---------- Date: Wed, 12 Nov 1997 22:37:10 +0000 From: Alan Cox To: BUGTRAQ@NETSPACE.ORG Subject: Re: mode of the i586 F0 bug > manufacturer that the Intel hardware designers forgot to unlock the > bus before trying to load the descriptor for the appropriate > exception handler, which would explain why locking it into the > L1 cache helps. I suppose the hardware does unlock it before actually It would also explain how the real fix works. If you take a BSDI box after the patch and before the patch and compare the MMU tables via /dev/mem etc you'll find there are a pair of funny pages where the interrupt descriptor table has moved. Odder still the low part of it doesnt have a pte. What it seems is done is to put the low descriptors into an invalid page and take a page fault when it tries to handle the fault from the lock cmpxchg8. The linux code is based on this observation and does this trick. The page fault handler then checks the fault and sees a kernel mode fault on the descriptor block[1] and works out what the real fault was. It then calls the relevant kernel function instead of doing normal page fault processing. We could probably just remap the page then but its faster to call the functions by hand than map and remap the page (causing tlb flushes). Hopefully that info and the 2.1.63 linux patch is enough to get the fix into other free OS's too. And if anyone can find a way to break the linux 2.1.63 fix we'd all love to know. Hopefully a complete official intel workaround will appear shortly and we can switch to that. Alan [1] This is important - or we might take a fault for a user process at the same address by chance and do a trap instead .. From owner-freebsd-hackers Wed Nov 12 20:12:30 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id UAA11162 for hackers-outgoing; Wed, 12 Nov 1997 20:12:30 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from trojanhorse.ml.org (mdean.vip.best.com [206.86.94.101]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id UAA11157 for ; Wed, 12 Nov 1997 20:12:25 -0800 (PST) (envelope-from jamil@trojanhorse.ml.org) Received: from localhost (jamil@localhost) by trojanhorse.ml.org (8.8.8/8.8.5) with SMTP id UAA00794; Wed, 12 Nov 1997 20:12:08 -0800 (PST) Date: Wed, 12 Nov 1997 20:12:08 -0800 (PST) From: "Jamil J. Weatherbee" To: Peter Dufault cc: hackers@FreeBSD.ORG Subject: Re: LabPC+ Driver Specifics In-Reply-To: <199711120055.TAA00327@hda.hda.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Well I throughly investigated doing TAILQ's of bio buffers in the driver, and even started to code it in for aiox. After I realized how much more complicated and seemingly useless (and kind of looked mighty inneffiecient especially in the intr routine which already eats up enough time at full blast as it is) for my purposes since unlike the labpc I have seperate fifos for each of the 128 channels in memory. The inb() --> fifo --> bio buffer in the interrupt routine seemed a little bit of overkill. Since my fifos are 64 entry per channel (I made also a define for the config file "options AIOX_CHANNELS=??) so tha a user with a different length analog multiplexer chain could optimize memory usage, which is 16kb by default. (128channels * 64 shorts) instead i am doing intr: inb() --> fifo --> wakeup and strategy: fifo-> (sleep) --> buffer I'll also put in select() handles for user multiplexing. At 500 microsecond intervals on 128 channels your fifos will overflow in about 4 seconds. I am also implementing AD_STOP and AD_START i think you know what they do by now opening state if same as AD_STOP my fifo overflow mode is to log a console message and throw out the oldest entry. That way in something like a control application (my prime interest) you are never denied the most recent values even after an overflow. I never plan on using more than 48 channels myself but I do have some doubts about any application that would be handling 128 file descriptors, seems kind of evil to me, you? From owner-freebsd-hackers Wed Nov 12 20:33:40 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id UAA12405 for hackers-outgoing; Wed, 12 Nov 1997 20:33:40 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from nomis.i-connect.net (nomis.i-Connect.Net [206.190.143.100]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id UAA12379 for ; Wed, 12 Nov 1997 20:33:35 -0800 (PST) (envelope-from shimon@i-connect.net) Received: (qmail 28137 invoked by uid 1000); 13 Nov 1997 04:33:50 -0000 Message-ID: X-Mailer: XFMail 1.2-beta-111097 [p0] on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit MIME-Version: 1.0 In-Reply-To: <199711122300.PAA10914@bubba.whistle.com> Date: Wed, 12 Nov 1997 20:33:50 -0800 (PST) Organization: Atlas Telecom From: Simon Shapiro To: Archie Cobbs Subject: RE: unkillable process Cc: freebsd-hackers@FreeBSD.ORG Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hi Archie Cobbs; On 12-Nov-97 you wrote: > > Try the following experiment (on 2.2 and mabye 3.0): > > 1. Create a named pipe > 2. Start typing into it using cat > 3. Hit control-C as many times as you want > > You'll see that the process will not die even with kill -9, > as it is stuck in uninterrupible disk sleep ("fifo"). > > But as soon as you read from the other end of the pipe, > the process exits. > > Is there a missing PCATCH flag to tsleep() somewhere? > Is this appropriate behavior? (hint: rhetorical question) >From what I remember, this is a typical (if ugly Unix behavior. Simon From owner-freebsd-hackers Wed Nov 12 22:38:21 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id WAA20053 for hackers-outgoing; Wed, 12 Nov 1997 22:38:21 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from smoke.marlboro.vt.us (smoke.marlboro.vt.us [198.206.215.91]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id WAA20033 for ; Wed, 12 Nov 1997 22:38:13 -0800 (PST) (envelope-from cgull@smoke.marlboro.vt.us) Received: (from cgull@localhost) by smoke.marlboro.vt.us (8.8.7/8.8.7/cgull) id BAA16748; Thu, 13 Nov 1997 01:38:01 -0500 (EST) Date: Thu, 13 Nov 1997 01:38:01 -0500 (EST) Message-Id: <199711130638.BAA16748@smoke.marlboro.vt.us> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: cgull+usenet-879403020@smoke.marlboro.vt.us (john hood) To: jerry_hicks@bigfoot.com Cc: FreeBSD-Hackers Subject: Re: Pentium Bug Fix... In-Reply-To: <346A03FA.FB710E25@ix.netcom.com> References: <346A03FA.FB710E25@ix.netcom.com> X-Mailer: VM 6.31 under Emacs 19.34.2 Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Jerry Hicks writes: > Richard M. Neswold wrote: > > > > Apparently Intel has helped BSDI in creating a fix to the Pentium bug: > > > > ftp://ftp.bsdi.com/bsdi/patches/patches-3.1/M310-hangfix > > > > Rich > > > > ------------------------------------------------------------------------ > > Richard Neswold, Accelerator Div./Controls Dept | neswold@fnal.gov > > Fermilab, PO Box 500, MS 347, Batavia, IL 60510 | voice (630) 840-3454 > > 'finger neswold@aduxb.fnal.gov' for PGP key | fax (630) 840-3093 > > And I get: > > The M310-hangfix beta patch is unavailable at the moment. We'll > keep everyone posted. It's still available on the ftp.uu.net mirror. --jh -- Mr. Belliveau said, "the difference was the wise, John Hood, cgull intelligent look on the face of the cow." He was @ *so* right. --Ofer Inbar smoke.marlboro.vt.us From owner-freebsd-hackers Wed Nov 12 23:43:29 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id XAA25378 for hackers-outgoing; Wed, 12 Nov 1997 23:43:29 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id XAA25370 for ; Wed, 12 Nov 1997 23:43:24 -0800 (PST) (envelope-from bde@zeta.org.au) Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.7/8.6.9) id SAA02104; Thu, 13 Nov 1997 18:37:56 +1100 Date: Thu, 13 Nov 1997 18:37:56 +1100 From: Bruce Evans Message-Id: <199711130737.SAA02104@godzilla.zeta.org.au> To: bde@zeta.org.au, mouth@ibm.net Subject: Re: Status of 650 UART support Cc: hackers@freebsd.org Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >>>Did you know that the 650 UART has on-chip "auto" RTS flow control > >>On some (early? all?) 16650s it is said to be just a pessimization >>to use it, since it is invoked when the trigger level is reached, >>so it is invoked for almost every input interrupt. > >It may seem like a pessimization if your ISR always starts quickly >enough to avoid UART overruns. However, when using a 550 UART, My ISRs always do :-). >presumably the serial ISR could safely raise RTS as its first duty >when the FIFO trigger level has been reached, since the external >device would be expected to have a large buffer of its own. If true, >then why not have the 650 chip raise RTS automatically? That buys It is unkind to the external device. It would approximately triple the number of interrupts for a similar device that is only sending. E.g., for a sender that sends 32 bytes at a time, and a receiver with a trigger level of 28, there would be about two useless modem status change interrupts in the sender for every 32 bytes sent. >Does the sio.c ISR raise RTS when servicing a UART trigger level >interrupt, or does it simply drain the UART FIFO while letting the >external device keep streaming inbound bytes? If the latter is true, >>I don't know what happens when the driver sets RTS directly. > >The Startech databook says: > >> RTS pin will be forced to high state regardless of its original >> state when receive FIFO reaches to the programmed trigger level. So the pessimization is standard on Startechs :-(. The RTS trigger level should be slightly higher than the FIFO trigger level. >> RTS pin resumes it original state after content of the >> data buffer (FIFO) drops below the next lower trigger level. >> ... hardware ... flow controls can be enabled for automatic >> operation. During these conditions the ST16C650 will accept >> additional data to fill the unused ... recieve FIFO locations. This is OK. >2) Receive (not transmit) FIFO trigger levels, 550 vs. 650: > >=46CR bit 7 and 6 550 650 > 00 1 8 > 01 4 16 > 10 8 24 > 11 14 28 > >If the software driver sets FCR to "10" as you would expect in the >case of a 550 UART, the 650 trigger level will actually be 24 and the >next lower trigger level will be 16. The excerpt from the databook sio actually uses 11. This gives a useful reduction of input inputs vs. 10 and doesn't cause slo overflows for normal setups with <= 4 ports and no (broken) bus-hogging DMA controllers. >>I think the best available setup is to use 16550 mode with the tx fifo >>size set to match the flow control. The 16650 configuration is too >>specific - it forces 16650 flow control and a 32 byte tx fifo size. > >I don't follow you here. FCR bits 5 and 4 on the 650 allow setting >the transmit FIFO to 16, 8, 24, or 30. The default is 16. However, >none of these are in effect unless, as the databook says: > >> ... user can write to transmit trigger levels but activation will not >> take place till ST16C650 special mode is selected (EFR bit-4 >> is set to "1"). > >> ... to be compatible with ... 550, 1 bytes transmit trigger level is >> selected after reset. > >So if you don't set EFR bit 4, the 650 transmit FIFO is still only one >byte just like a 550. And I don't recall seeing any code in sio.c to >set EFR bit 4. It only sets the software tx_fifo_size to 32. This is apparently the default if the fifos are enabled in the 16550 way. This is 16550- compatible because the space in the fifo is not readable so 16550 drivers would only ever put 16 bytes in the fifo. Bruce From owner-freebsd-hackers Thu Nov 13 00:33:17 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id AAA28332 for hackers-outgoing; Thu, 13 Nov 1997 00:33:17 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id AAA28317 for ; Thu, 13 Nov 1997 00:33:13 -0800 (PST) (envelope-from egon@computronic.at) Received: from mail.computronic.at ([194.177.146.5] (may be forged)) by freefall.freebsd.org (8.8.6/8.8.5) with ESMTP id AAA11647 for ; Thu, 13 Nov 1997 00:30:44 -0800 (PST) Received: from atambs0e ([195.212.97.39]) by mail.computronic.at (post.office MTA v2.0 0813 ID# 0-33306U110) with ESMTP id AAA162; Thu, 13 Nov 1997 09:34:01 +0100 Message-ID: <346ABBED.9B263F33@computronic.at> Date: Thu, 13 Nov 1997 09:35:58 +0100 From: "Barfuß Egon jun." Reply-To: egon@computronic.at Organization: Home X-Mailer: Mozilla 4.01 [en] (WinNT; I) MIME-Version: 1.0 To: firewalls@GreatCircle.COM, ntsecurity@iss.net, hackers@FreeBSD.COM Subject: Need a Firewall but don´t know which one X-Priority: 3 (Normal) Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hi there, Big problem! We are running an internet server but till now we don´t have any firewall. Now I´m searching one but don´t know which one I should take. I found a site http://www.waterw.com/~manowar/vendor.html with many various products and platforms and I got some informations about WatchGuard. Does anyone know something about it? Is NT a good platform??? I heard that it is a bit unsecure because some problems with TCP/IP ports and Redbutton. What do you think about it and which platform/system is the best/better one?? Thanks in advance Egon -- Egon Barfusz Gottschallingerstr. 6 4030 Linz mailto:egon@computronic.at mailto:egon.barfusz@ambos.co.at From owner-freebsd-hackers Thu Nov 13 01:38:55 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id BAA00854 for hackers-outgoing; Thu, 13 Nov 1997 01:38:55 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id BAA00849 for ; Thu, 13 Nov 1997 01:38:52 -0800 (PST) (envelope-from bde@zeta.org.au) Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.7/8.6.9) id UAA06342; Thu, 13 Nov 1997 20:35:53 +1100 Date: Thu, 13 Nov 1997 20:35:53 +1100 From: Bruce Evans Message-Id: <199711130935.UAA06342@godzilla.zeta.org.au> To: bde@zeta.org.au, mouth@ibm.net Subject: Re: Status of 650 UART support Cc: hackers@freebsd.org Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >>A 64-byte fifo probably won't work unless the fifo trigger level is >>reduced (defeating the point of the larger fifo). There may be just >>enough margin if the default (highest) trigger level is enough below >>64. > >Why won't a 64-byte FIFO work? Is it for the same reason as stated in >the following excerpt from sio.c? Yes. >>#ifdef COM_ESP >> if (com->esp) { >> /* >> * Set 16550 compatibility mode. >> * We don't use the ESP_MODE_SCALE bit to increase the >> * fifo trigger levels because we can't handle large >> * bursts of input. > >Why can't we handle large bursts of input? Buffer sizes are finite. >>I think the best available setup is to use 16550 mode with the tx fifo >>size set to match the flow control. > >I do not understand "tx fifo size set to match the flow control." Neither do I :-). I should have said "with the tx fifo size set to match the 16x5x variant". >>The 16650 configuration is too specific - it forces 16650 flow >> control and a 32 byte tx fifo size. > >As mentioned in my earlier response, transmit FIFO can be set >independently of receive FIFO. And by default, transmit FIFO is set >to one byte like the 550. I don't see why that is bad. It is 16 for the 16550 if the fifos are enabled, and surely at least as large for later variants. You probably want to use 64 instead of 32 if possible. >>The interrupt latency is low enough for auto flow control to be >>unnecessary in most cases (and there is another 6 character times of >... >Perhaps true, but it won't hurt to have hardware insurance against >interrupt latency. I already paid for the insurance when I bought the >650. I would like to use it, as long as it does not cause any loss of >efficiency. Apparently it does. >>Another problem with auto flow control is that it doesn't actually >>work if the sender can't stop soon enough. E.g., if the sender is >>a 16550, then it can't reasonably stop before sending 16 characters >>if it has 16 characters in its tx fifo. > >Why not? When auto CTS is activated with EFR bit 7, the 650 will stop >sending if the external device drops CTS, even with bytes remaining in >the transmit FIFO. That should have no adverse impact on sio.c, >should it? It's all internal to the chip itself. Auto CTS only helps if the sender has it or something else that allows it to stop soon. 8250 senders can stop sooner than 16550 senders :-). >>The receiver must have a rx fifo trigger level 16+ below the fifo size >> to handle this completely in hardware (+ =3D a few more to give the >> interrupt handler time to run before flow control is actually invoked). > >Yes, but I don't see why the design of the 650 would make you want to >handle it completely in hardware. If the 650 will merely raise RTS on It's because OS's that can't guarantee a (serial) interrupt latency of <= 2 to 8 character times also have problems guaranteeing an interrupt latency of 100's of character times. It would be nice for hardware flow control to completely handle this case. >>>I increased the software buffer size from 256 to 512, and that seemed >>>to reduce the number of overflows, but a burst of disk activity would >>>still trigger one even with the larger buffer. >> >>That breaks the watermarks in the tty buffer unless the tty buffer size >>(TTYHOG) is increased too. > >I'm only testing with PPPD. Does it use tty buffers? No. Only the termios line discpline uses them. This also makes RTS flow control much less important with pppd. Bruce From owner-freebsd-hackers Thu Nov 13 01:43:35 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id BAA01047 for hackers-outgoing; Thu, 13 Nov 1997 01:43:35 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id BAA01039 for ; Thu, 13 Nov 1997 01:43:30 -0800 (PST) (envelope-from johannes.schwabe@informatik.tu-chemnitz.de) Received: from obelix.hrz.tu-chemnitz.de (obelix.hrz.tu-chemnitz.de [134.109.132.55]) by freefall.freebsd.org (8.8.6/8.8.5) with ESMTP id BAA11912 for ; Thu, 13 Nov 1997 01:41:06 -0800 (PST) Received: from mailbox.hrz.tu-chemnitz.de by obelix.hrz.tu-chemnitz.de with Local SMTP (PP); Thu, 13 Nov 1997 10:41:54 +0100 Received: from pandora.hrz.tu-chemnitz.de (pandora.hrz.tu-chemnitz.de [134.109.132.63]) by mailbox.hrz.tu-chemnitz.de (8.8.5/8.8.3) with ESMTP id KAA21126; Thu, 13 Nov 1997 10:41:51 +0100 (MET) Received: from localhost by pandora.hrz.tu-chemnitz.de (8.8.5/client-1.5) id KAA11984; Thu, 13 Nov 1997 10:41:50 +0100 Date: Thu, 13 Nov 1997 10:41:48 +0100 (MET) From: Johannes Schwabe To: "Barfu Egon jun." cc: firewalls@GreatCircle.COM, ntsecurity@iss.net, hackers@FreeBSD.COM Subject: =?ISO-8859-1?Q?Re=3A_Need_a_Firewall_but_don=B4t_know_which?= =?ISO-8859-1?Q?_one?= In-Reply-To: <346ABBED.9B263F33@computronic.at> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Thu, 13 Nov 1997, Barfu Egon jun. wrote: > What do you think about it and which platform/system is the best/better > one?? I think you sound like someone who sees a firewall as the ultimate solution to security problems, which it is not, of course. See http://flummi.de/~bofh/security-faq.html. From owner-freebsd-hackers Thu Nov 13 02:26:27 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id CAA02961 for hackers-outgoing; Thu, 13 Nov 1997 02:26:27 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id CAA02956 for ; Thu, 13 Nov 1997 02:26:25 -0800 (PST) (envelope-from ewout@pinewood.nl) Received: from gw.pinewood.nl (gw.pinewood.nl [194.171.50.9]) by freefall.freebsd.org (8.8.6/8.8.5) with ESMTP id CAA12187 for ; Thu, 13 Nov 1997 02:24:00 -0800 (PST) Received: (from smap@localhost) by gw.pinewood.nl (8.8.4/8.6.12) id LAA25698; Thu, 13 Nov 1997 11:26:19 +0100 (CET) X-Authentication-Warning: gw.pinewood.nl: smap set sender to using -f Received: from pwood1.pinewood.nl(192.168.1.10) by gw.pinewood.nl via smap (V1.3) id sma025696; Thu Nov 13 11:26:13 1997 Received: (from ewout@localhost) by pwood1.pinewood.nl (8.7.3/8.6.12) id LAA10755; Thu, 13 Nov 1997 11:26:12 +0100 (MET) From: "Ewout Meij" Message-Id: <971113112612.ZM10751@pwood1.pinewood.nl> Date: Thu, 13 Nov 1997 11:26:12 +0100 In-Reply-To: =?iso-8859-1?Q?=22Barfu=DF_Egon_jun=2E=22_=3Cegon=40computron?= =?iso-8859-1?Q?ic=2Eat=3E?= =?iso-8859-1?Q?________=22=5BNTSEC=5D_Need_a_Firewall_but_don=B4t_know_wh?= =?iso-8859-1?Q?ich_one=22_=28Nov_13=2C__9=3A35=29?= References: <346ABBED.9B263F33@computronic.at> X-Face: 'BsFf8'k.q?J#?|$D*,)/?sRB{woUK&9\5K{ERmT;VTSyNLBb?muLf>b:Pt&VTDw8YCaC]6 C!MRSMr5UNjZLa]fi? X-Mailer: Z-Mail (4.0.1 13Jan97) To: =?iso-8859-1?Q?=22Barfu=DF_Egon_jun=2E=22?= , firewalls@GreatCircle.COM, ntsecurity@iss.net, hackers@FreeBSD.COM Subject: =?iso-8859-1?Q?Re=3A_=5BNTSEC=5D_Need_a_Firewall_but_don=B4t_know?= =?iso-8859-1?Q?_which_one?= MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by hub.freebsd.org id CAA02957 Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Nov 13, 9:35, Barfuß Egon jun. wrote: > Subject: [NTSEC] Need a Firewall but don´t know which one > > Hi there, > > Big problem! > We are running an internet server but till now we don´t have any > firewall. [snip] I guess you'll draw a *lot* of extra attention to your site this way ;-) current hits 009413 and counting! From owner-freebsd-hackers Thu Nov 13 02:29:56 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id CAA03130 for hackers-outgoing; Thu, 13 Nov 1997 02:29:56 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id CAA03125 for ; Thu, 13 Nov 1997 02:29:53 -0800 (PST) (envelope-from bde@zeta.org.au) Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.7/8.6.9) id VAA08134; Thu, 13 Nov 1997 21:25:13 +1100 Date: Thu, 13 Nov 1997 21:25:13 +1100 From: Bruce Evans Message-Id: <199711131025.VAA08134@godzilla.zeta.org.au> To: mouth@ibm.net, tlambert@primenet.com Subject: Re: Status of 650 UART support Cc: bde@zeta.org.au, hackers@FreeBSD.ORG Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >> Why can't we handle large bursts of input? > >Bruce can correct me, but I believe it's because the FASTINTR code >expects to run to completion, and that expectation means that it >can't take more than a small amount of time to process the interrupt. >Processing the additional caharacters puts it over the limit. This becomes important for some fifo size, but the immediate problem is that one of the watermarks only has 64 characters of headroom. There are also some limits from having to fit the headroom in a 256 byte software fifo. The buffer size was chosen to support speeds of up to 115200 bps, without much thought given to fitting the headroom. Fastintr handlers are already not so fast with 16550s. The normal worst case is sending 16 characters and receiving 15 characters and handling a modem status change. This takes about 70 usec with a reasonably fast processor on an 8MHz ISA bus. (It can take much longer, perhaps infinitely long, if the modem status changes a lot.) This means that 3 active 16550s may increase the interrupt latency too much for a 16450 to work at 115200 bps (the maximum viable latency is 87 usec), and 3 active 16550s may increase the interrupt latency too much for another 16550 to work with the default agressive fifo trigger level (the maximum viable latency is 2*87 usec). Multiply some of these numbers by 4 for 64-bit fifos and you have seriously high (normal worst case) latencies. (My definition of ``high'' is anything that would stop an 8250 from working at 115200 bps - 87 usec :-). I will reduce this when faster speeds become common.) Bruce From owner-freebsd-hackers Thu Nov 13 04:56:49 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id EAA12131 for hackers-outgoing; Thu, 13 Nov 1997 04:56:49 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from Kitten.mcs.com (Kitten.mcs.com [192.160.127.90]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id EAA12126 for ; Thu, 13 Nov 1997 04:56:46 -0800 (PST) (envelope-from nash@Mercury.mcs.net) Received: from Mercury.mcs.net (nash@Mercury.mcs.net [192.160.127.80]) by Kitten.mcs.com (8.8.5/8.8.2) with ESMTP id GAA24453 for ; Thu, 13 Nov 1997 06:56:45 -0600 (CST) Received: from localhost (nash@localhost) by Mercury.mcs.net (8.8.7/8.8.2) with SMTP id GAA28451 for ; Thu, 13 Nov 1997 06:56:45 -0600 (CST) Date: Thu, 13 Nov 1997 06:56:45 -0600 (CST) From: Alex Nash To: hackers@freebsd.org Subject: [linux-security] Linux F00F Patch [Forwarded e-mail from Aleph One] (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk ---------- Forwarded message ---------- Date: Wed, 12 Nov 1997 21:02:32 -0500 From: Jeff Uphoff Reply-To: juphoff@nrao.edu To: linux-security@redhat.com Subject: [linux-security] Linux F00F Patch [Forwarded e-mail from Aleph One] Resent-Date: 13 Nov 1997 08:57:26 -0000 Resent-From: linux-security@redhat.com Resent-cc: recipient list not shown: ; [mod: The first message would've been rejected on the grounds "no security related information", but it gives ME a warm feeling too, so I'm allowing it to piggyback on the announcement of the "fix". Note that Linux-2.1.63 simply implements a fix for the problem, instead of applying this fix, upgrading to 2.1.63 might be an option for you. Linus indicated that this fix WILL be moving into 2.0.3x . Case closed? Oh, and allow me to aplogise in public to all that I told that I did not believe them when they told me that P6 processors (P-Pro and P-II) have a writable microcode feature. They do. (Assignment for Crypto-101: Decode the encrypted microcode that is avaible at http://www.sandpile.org/80x86/mcupdate/update32.zip --16 hours) I mentioned that I expected Pentium overdrives to be affected. Several people have confirmed that they aren't. Odd. The fix relies on the CPUID information, do they get detected as having the F00F bug? -- REW] ------------------------------------------------------------------ Related to the "F0 OF C7 C8" bug, from http://support.intel.com/support/processors/pentium/ppiie/index.htm The execution of that reported instruction sequence causes systems with Pentium processors and Pentium processor with MMX technology to hang instead of terminating the application. This hang condition is observed on multiple operating systems (DOS*, Windows* 95, Windows* NT, and Linux*) when used with this instruction sequence. Intel has reproduced the behavior. Linux got equal billing with all of MS's OS's (and quasi-OS's). Intel's acknowledgement of Linux gave me a fuzzy. (The * is footnoted as "These trademarks are property of their respective owners." That now means Linus in our community. Thanks to all involved parties for helping make that come true.) --Up. ------------------------------------------------------------------ Forwarding headers mangle patches. Mind the gap. --Up. ------- start of forwarded message (RFC 934 encapsulation) ------- From: Aleph One Sender: Bugtraq List To: BUGTRAQ@NETSPACE.ORG Subject: Linux F00F Patch Date: Wed, 12 Nov 1997 18:45:15 -0600 Reply-To: Aleph One This are the relevant parts of the linux kernel 2.1.63 patch that fix the Pentium bug that Alan mentioned. Aleph One / aleph1@dfw.net http://underground.org/ KeyID 1024/948FD6B5 Fingerprint EE C9 E8 AA CB AF 09 61 8C 39 EA 47 A8 6A B8 01 diff -u --recursive --new-file v2.1.62/linux/arch/i386/kernel/setup.c linux/arch/i386/kernel/setup.c - --- v2..1.62/linux/arch/i386/kernel/setup.c Tue Sep 23 16:48:46 1997 +++ linux/arch/i386/kernel/setup.c Wed Nov 12 11:09:56 1997 @@ -42,6 +42,7 @@ char x86_mask = 0; /* set by kernel/head.S */ int x86_capability = 0; /* set by kernel/head.S */ int fdiv_bug = 0; /* set if Pentium(TM) with FP bug */ +int pentium_f00f_bug = 0; /* set if Pentium(TM) with F00F bug */ int have_cpuid = 0; /* set if CPUID instruction works */ char x86_vendor_id[13] = "unknown"; @@ -359,6 +360,7 @@ "fdiv_bug\t: %s\n" "hlt_bug\t\t: %s\n" "sep_bug\t\t: %s\n" + "pentium_f00f_bug\t\t: %s\n" "fpu\t\t: %s\n" "fpu_exception\t: %s\n" "cpuid\t\t: %s\n" @@ -367,6 +369,7 @@ CD(fdiv_bug) ? "yes" : "no", CD(hlt_works_ok) ? "no" : "yes", sep_bug ? "yes" : "no", + pentium_f00f_bug ? "yes" : "no", CD(hard_math) ? "yes" : "no", (CD(hard_math) && ignore_irq13) ? "yes" : "no", diff -u --recursive --new-file v2.1.62/linux/arch/i386/kernel/traps.c linux/arch/i386/kernel/traps.c - --- v2.1.62/linux/arch/i386/kernel/traps.c Sun Sep 7 13:10:42 1997 +++ linux/arch/i386/kernel/traps.c Wed Nov 12 11:09:56 1997 @@ -413,6 +413,51 @@ #endif /* CONFIG_MATH_EMULATION */ +static struct +{ + short limit __attribute__((packed)); + void * addr __attribute__((packed)); + short __pad __attribute__((packed)); +} idt_d; + +void * idt2; + +__initfunc(void trap_init_f00f_bug(void)) +{ + pgd_t * pgd; + pmd_t * pmd; + pte_t * pte; + unsigned long twopage; + + printk("moving IDT ... "); + + twopage = (unsigned long) vmalloc (2*PAGE_SIZE); + + idt2 = (void *)(twopage + 4096-7*8); + + memcpy(idt2,&idt,sizeof(idt)); + + idt_d.limit = 256*8-1; + idt_d.addr = idt2; + idt_d.__pad = 0; + + __asm__ __volatile__("\tlidt %0": "=m" (idt_d)); + + /* + * Unmap lower page: + */ + pgd = pgd_offset(current->mm, twopage); + pmd = pmd_offset(pgd, twopage); + pte = pte_offset(pmd, twopage); + + pte_clear(pte); + flush_tlb_all(); + + printk(" ... done\n"); +} + + + __initfunc(void trap_init(void)) { int i; diff -u --recursive --new-file v2.1.62/linux/arch/i386/mm/fault.c linux/arch/i386/mm/fault.c - --- v2.1.62/linux/arch/i386/mm/fault.c Wed Oct 15 16:04:23 1997 +++ linux/arch/i386/mm/fault.c Wed Nov 12 11:09:55 1997 @@ -74,6 +74,25 @@ return 0; } +asmlinkage void divide_error(void); +asmlinkage void debug(void); +asmlinkage void nmi(void); +asmlinkage void int3(void); +asmlinkage void overflow(void); +asmlinkage void bounds(void); +asmlinkage void invalid_op(void); + +asmlinkage void do_divide_error (struct pt_regs *, unsigned long); +asmlinkage void do_debug (struct pt_regs *, unsigned long); +asmlinkage void do_nmi (struct pt_regs *, unsigned long); +asmlinkage void do_int3 (struct pt_regs *, unsigned long); +asmlinkage void do_overflow (struct pt_regs *, unsigned long); +asmlinkage void do_bounds (struct pt_regs *, unsigned long); +asmlinkage void do_invalid_op (struct pt_regs *, unsigned long); + +extern int * idt2; +extern int pentium_f00f_bug; + /* * This routine handles page faults. It determines the address, * and the problem, and then passes it off to one of the appropriate @@ -170,6 +189,46 @@ goto out; } + printk("<%p/%p>\n", idt2, (void *)address); + /* + * Pentium F0 0F C7 C8 bug workaround: + */ + if ( pentium_f00f_bug && (address >= (unsigned long)idt2) && + (address < (unsigned long)idt2+256*8) ) { + + void (*handler) (void); + int nr = (address-(unsigned long)idt2)/8; + unsigned long low, high; + + low = idt[nr].a; + high = idt[nr].b; + + handler = (void (*) (void)) ((low&0x0000ffff) | (high&0xffff0000)); + printk("\n"); + goto out; + } + /* Are we prepared to handle this kernel fault? */ if ((fixup = search_exception_table(regs->eip)) != 0) { printk(KERN_DEBUG "%s: Exception at [<%lx>] cr2=%lx (fixup: %lx)\n", @@ -193,6 +252,7 @@ flush_tlb(); goto out; } + if (address < PAGE_SIZE) printk(KERN_ALERT "Unable to handle kernel NULL pointer dereference"); else diff -u --recursive --new-file v2.1.62/linux/include/asm-i386/bugs.h linux/include/asm-i386/bugs.h - --- v2.1.62/linux/include/asm-i386/bugs.h Thu Sep 11 09:02:24 1997 +++ linux/include/asm-i386/bugs.h Wed Nov 12 11:09:55 1997 @@ -166,6 +166,32 @@ } } +/* + * All current models of Pentium and Pentium with MMX technology CPUs + * have the F0 0F bug, which lets nonpriviledged users lock up the system: + */ + +extern int pentium_f00f_bug; + +__initfunc(static void check_pentium_f00f(void)) +{ + /* + * Pentium and Pentium MMX + */ + printk("checking for F00F bug ..."); + if(x86==5 && !memcmp(x86_vendor_id, "GenuineIntel", 12)) + { + extern void trap_init_f00f_bug(void); + + printk(KERN_INFO "\nIntel Pentium/[MMX] F0 0F bug detected - turning on workaround.\n"); + pentium_f00f_bug = 1; + trap_init_f00f_bug(); + } else { + printk(KERN_INFO " no F0 0F bug in this CPU, great!\n"); + pentium_f00f_bug = 0; + } +} + __initfunc(static void check_bugs(void)) { check_tlb(); @@ -173,5 +199,6 @@ check_hlt(); check_popad(); check_amd_k6(); + check_pentium_f00f(); system_utsname.machine[1] = '0' + x86; } ------- end ------- -- ---------------------------------------------------------------------- Please refere to the information about this list as well as general information about Linux security at http://www.aoy.com/Linux/Security. ---------------------------------------------------------------------- To unsubscribe: mail -s unsubscribe test-list-request@redhat.com < /dev/null From owner-freebsd-hackers Thu Nov 13 05:03:47 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id FAA12498 for hackers-outgoing; Thu, 13 Nov 1997 05:03:47 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from net1.nw.com.au (root@Net1.nw.com.au [203.18.240.2]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id FAA12493 for ; Thu, 13 Nov 1997 05:03:41 -0800 (PST) (envelope-from beav@nw.com.au) Received: from jts.aceonline.com.au (beav@[203.33.252.143]) by net1.nw.com.au (8.7.6/8.7.3) with ESMTP id UAA04803 for ; Thu, 13 Nov 1997 20:58:55 +0800 Message-Id: <199711131258.UAA04803@net1.nw.com.au> From: "beav" To: Subject: Technical know-how Date: Thu, 13 Nov 1997 21:03:43 +0800 X-MSMail-Priority: Normal X-Priority: 3 X-Mailer: Microsoft Internet Mail 4.70.1161 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi people :) Just wondering if anyone had any experience with NEC IDE 6x4 CD changers working in 2.2.x? I know they work in Linux, using a proggie called eject and another called cdload. Any ideas? regards, -- beav. From owner-freebsd-hackers Thu Nov 13 05:39:30 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id FAA14389 for hackers-outgoing; Thu, 13 Nov 1997 05:39:30 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id FAA14384 for ; Thu, 13 Nov 1997 05:39:28 -0800 (PST) (envelope-from mfearer@mail.fearernet.com) Received: from mail.fearernet.com (mfearer@mail.fearernet.com [207.22.35.20]) by freefall.freebsd.org (8.8.6/8.8.5) with ESMTP id FAA15414 for ; Thu, 13 Nov 1997 05:37:03 -0800 (PST) Received: from localhost (mfearer@localhost) by mail.fearernet.com (8.8.4/8.8.4) with SMTP id JAA01632; Thu, 13 Nov 1997 09:05:55 -0500 Date: Thu, 13 Nov 1997 09:05:54 -0500 (EST) From: Mark Fearer To: "Barfu Egon jun." cc: firewalls@GreatCircle.COM, ntsecurity@iss.net, hackers@FreeBSD.COM Subject: Re: [NTSEC] Need a Firewall but dont know which one In-Reply-To: <346ABBED.9B263F33@computronic.at> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by hub.freebsd.org id FAA14385 Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Try checking out www.raptor.com. We are running the Eagle NT 4.0 where I work. Same GUI as the unix version. ----------- Mark Fearer mfearer@mail.fearernet.com On Thu, 13 Nov 1997, Barfu Egon jun. wrote: > > Hi there, > > Big problem! > We are running an internet server but till now we don´t have any > firewall. Now I´m searching one but don´t know which one I should take. > > I found a site http://www.waterw.com/~manowar/vendor.html with many > various products and platforms and I got some informations about > WatchGuard. Does anyone know something about it? > > Is NT a good platform??? I heard that it is a bit unsecure because some > problems with TCP/IP ports and Redbutton. > > What do you think about it and which platform/system is the best/better > one?? > > Thanks in advance > > Egon > > -- > Egon Barfusz > Gottschallingerstr. 6 > 4030 Linz > mailto:egon@computronic.at > mailto:egon.barfusz@ambos.co.at > > From owner-freebsd-hackers Thu Nov 13 06:23:40 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id GAA16353 for hackers-outgoing; Thu, 13 Nov 1997 06:23:40 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from outmail.utsunomiya-u.ac.jp (outmail.utsunomiya-u.ac.jp [160.12.196.3]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id GAA16342 for ; Thu, 13 Nov 1997 06:23:34 -0800 (PST) (envelope-from yokota@zodiac.mech.utsunomiya-u.ac.jp) Received: by outmail.utsunomiya-u.ac.jp id AA05675; Thu, 13 Nov 1997 23:23:32 +0900 Received: from zodiac.mech.utsunomiya-u.ac.jp (zodiac.mech.utsunomiya-u.ac.jp [160.12.42.1]) by zodiac.mech.utsunomiya-u.ac.jp (8.7.6+2.6Wbeta7/3.4W/zodiac-May96) with ESMTP id XAA27445; Thu, 13 Nov 1997 23:30:08 +0900 (JST) Message-Id: <199711131430.XAA27445@zodiac.mech.utsunomiya-u.ac.jp> To: freebsd-hackers@freebsd.org Cc: yokota@zodiac.mech.utsunomiya-u.ac.jp Subject: Extended mouse support Date: Thu, 13 Nov 1997 23:30:07 +0900 From: Kazutaka YOKOTA Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk This is to announce the third test release of the set of patch files for 3.0-CURRENT, 2.2-STABLE and 2.2.5-RELEASE to modify device drivers (psm, mse), `moused' and `sysmouse (syscons)' to take advantage of new features (such as a wheel) of recent mouse products. It will add support for the following mice: Microsoft IntelliMouse (serial, PS/2, 3 buttons, wheel) Kensignton ThinkingMouse (serial, PS/2$@!$(J4 buttons) ALPS GlidePoint (serial, PS/2$@!$(J3 buttons) Genius NetScroll (PS/2$@!$(J4 buttons, wheel) Genius NetMouse (serial, PS/2, 2 buttons, magic button) ASCII MieMouse (serial, PS/2, 3 buttons, wheel) (Recent Logitech products, MouseMan+ and FirstMouse+ with a wheel, are not supported yet, as I haven't put my hands on them. If you own one and could help me to develop drivers, I would be very happy.) I have placed the patch files and documentation in ftp://ftp.freebsd.org/pub/FreeBSD/incoming/mouse971113.tar.gz I also included the patch for XFree86 3.30/3.31. Installation procedure and details of modifications are described in NOTES in the tar file. Please read included man pages too. I would be grateful if you could kindly try it and send me some comments. Kazu From owner-freebsd-hackers Thu Nov 13 06:31:48 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id GAA16778 for hackers-outgoing; Thu, 13 Nov 1997 06:31:48 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from terra.Sarnoff.COM (terra.sarnoff.com [130.33.11.203]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id GAA16773 for ; Thu, 13 Nov 1997 06:31:45 -0800 (PST) (envelope-from rminnich@Sarnoff.COM) Received: (from rminnich@localhost) by terra.Sarnoff.COM (8.6.12/8.6.12) id JAA05626; Thu, 13 Nov 1997 09:31:08 -0500 Date: Thu, 13 Nov 1997 09:31:07 -0500 (EST) From: "Ron G. Minnich" X-Sender: rminnich@terra To: freebsd-hackers@FreeBSD.ORG Subject: Re: BSDI F0 bug workaround implementation In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk I'm not sure I understand the full implications of the impact of this hack, although it is worrisome. Judging by what my pentium book says about the layout of the IDT, it seems like it will increase interrupt latency for page faults and many maskable interrupts. Can anyone more knowledgeable than I comment on this? Page fault overhead on freebsd is pretty high: would a short-cut make sense that does not go through the full vm system for this? Otherwise page fault overhead may come close to doubling ... thanks ron Ron Minnich |Java: an operating-system-independent, rminnich@sarnoff.com |architecture-independent programming language (609)-734-3120 |for Windows/95 and Windows/NT on the Pentium ftp://ftp.sarnoff.com/pub/mnfs/www/docs/cluster.html From owner-freebsd-hackers Thu Nov 13 07:20:19 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id HAA19887 for hackers-outgoing; Thu, 13 Nov 1997 07:20:19 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from ussenterprise.ufp.org (bicknell@ussenterprise.ufp.org [209.12.7.40]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id HAA19877 for ; Thu, 13 Nov 1997 07:20:14 -0800 (PST) (envelope-from bicknell@ussenterprise.ufp.org) Received: (from bicknell@localhost) by ussenterprise.ufp.org (8.8.7/8.8.7) id KAA09225; Thu, 13 Nov 1997 10:20:09 -0500 (EST) From: Leo Bicknell Message-Id: <199711131520.KAA09225@ussenterprise.ufp.org> Subject: AHC / SCSI Problem? To: freebsd-hackers@freebsd.org Date: Thu, 13 Nov 1997 10:20:08 -0500 (EST) Cc: jaitken@dimension.net Reply-To: bicknell@ufp.org X-Mailer: ELM [version 2.4ME+ PL32 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk We've been having some problems here with FreeBSD, Adaptec 2940's, and various disk drives. I think we're hitting some sort of driver bug but would like feedback. Basically we get these errors from time to time, usualy during a backup operation. Other than a few complaints from dump they don't seem to have any operation impact. I do find it interesting that it happens on the Micropolis 4221 disks. Perhaps there is something "special" about them. I have a theory myself that turning on TAGENABLE and SCBPAGING_ENABLE might actually help this situation, but I'm not going to try it unless an expert thinks this is a good idea as well. These are both production machines, so experimenting is a problem, but if we have some good leads we can do some work to track this down. Please include a direct e-mail to me with any responces, for better or for worse freebsd-hackers is low on the mail priority list. Thanks. On system number 1 we have: ahc0 rev 0 int a irq 9 on pci0:18 ahc0: aic7880 Single Channel, SCSI Id=7, 16 SCBs ahc0 waiting for scsi devices to settle (ahc0:0:0): "MICROP 4221-09 1128RV 28RV" type 0 fixed SCSI 2 sd0(ahc0:0:0): Direct-Access 1955MB (4004219 512 byte sectors) (ahc0:1:0): "MICROP 4221-09 1128RV 28RV" type 0 fixed SCSI 2 sd1(ahc0:1:0): Direct-Access 1955MB (4004219 512 byte sectors) (ahc0:2:0): "SEAGATE ST15150N 0022" type 0 fixed SCSI 2 sd2(ahc0:2:0): Direct-Access 4095MB (8388315 512 byte sectors) Kernel Config: options AHC_ALLOW_MEMIO #options AHC_TAGENABLE #options AHC_SCBPAGING_ENABLE controller ahc0 controller scbus0 at ahc0 device sd0 at scbus0 target 0 device sd1 at scbus0 target 1 device sd2 at scbus0 target 2 device sd3 at scbus0 target 3 device sd4 at scbus0 target 4 device st0 device cd0 And have received the error: sd0(ahc0:0:0): SCB 0x0 - timed out while idle, LASTPHASE == 0x1, SCSISIGI == 0x0 SEQADDR = 0x8 SCSISEQ = 0x12 SSTAT0 = 0x5 SSTAT1 = 0xa sd0(ahc0:0:0): Queueing an Abort SCB sd0(ahc0:0:0): Abort Message Sent sd0(ahc0:0:0): SCB 0 - Abort Completed. sd0(ahc0:0:0): no longer in timeout On system number 2 we have: ahc0 rev 1 int a irq 9 on pci0:18 ahc0: aic7860 Single Channel, SCSI Id=7, 3 SCBs ahc0 waiting for scsi devices to settle (ahc0:0:0): "MICROP 4221-09 1128RQAV RQAV" type 0 fixed SCSI 2 sd0(ahc0:0:0): Direct-Access 1955MB (4004219 512 byte sectors) (ahc0:1:0): "MICROP 4221-09 1128RQAV RQAV" type 0 fixed SCSI 2 sd1(ahc0:1:0): Direct-Access 1955MB (4004219 512 byte sectors) Kernel Config: options AHC_ALLOW_MEMIO #options AHC_TAGENABLE #options AHC_SCBPAGING_ENABLE controller ahc0 controller scbus0 at ahc0 device sd0 at scbus0 target 0 device sd1 at scbus0 target 1 device sd2 at scbus0 target 2 device sd3 at scbus0 target 3 device sd4 at scbus0 target 4 device st0 device cd0 And have received the error: Unexpected busfree. LASTPHASE == 0x40 SEQADDR == 0x129 sd1(ahc0:1:0): SCB 0x2 - timed out while idle, LASTPHASE == 0x1, SCSISIGI == 0x0 SEQADDR = 0x5 SCSISEQ = 0x12 SSTAT0 = 0x5 SSTAT1 = 0xa sd1(ahc0:1:0): Queueing an Abort SCB sd1(ahc0:1:0): Abort Message Sent sd1(ahc0:1:0): SCB 2 - Abort Completed. sd1(ahc0:1:0): no longer in timeout sd1(ahc0:1:0): SCB 0x2 - timed out while idle, LASTPHASE == 0x1, SCSISIGI == 0x0 SEQADDR = 0x8 SCSISEQ = 0x12 SSTAT0 = 0x5 SSTAT1 = 0xa sd1(ahc0:1:0): Queueing an Abort SCB sd1(ahc0:1:0): no longer in timeout sd1(ahc0:1:0): SCB 0x2 - timed out while idle, LASTPHASE == 0x1, SCSISIGI == 0x0 SEQADDR = 0x5 SCSISEQ = 0x12 SSTAT0 = 0x5 SSTAT1 = 0xa sd1(ahc0:1:0): Queueing an Abort SCB sd1(ahc0:1:0): Abort Message Sent sd1(ahc0:1:0): SCB 2 - Abort Completed. sd1(ahc0:1:0): no longer in timeout Unexpected busfree. LASTPHASE == 0x40 SEQADDR == 0x129 -- Leo Bicknell - bicknell@ufp.org System Administration - Network Design TMBG List - tmbg-list-request@tmbg.org From owner-freebsd-hackers Thu Nov 13 07:25:01 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id HAA20321 for hackers-outgoing; Thu, 13 Nov 1997 07:25:01 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from pip.cc.brandeis.edu (pip.cc.brandeis.edu [129.64.1.40]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id HAA20308 for ; Thu, 13 Nov 1997 07:24:55 -0800 (PST) (envelope-from ST963602@PIP.CC.BRANDEIS.EDU) Received: from PIP.CC.BRANDEIS.EDU by PIP.CC.BRANDEIS.EDU (PMDF V5.1-5 #17139) id <01IPYHJG4NJ6014Z4H@PIP.CC.BRANDEIS.EDU> for hackers@hub.freebsd.org; Thu, 13 Nov 1997 10:20:36 EDT Date: Thu, 13 Nov 1997 10:20:36 -0400 (EDT) From: st963602@PIP.CC.BRANDEIS.EDU Subject: localtalk card To: FreeBSD-Hackers Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk I read on the web an email that someone had developed or ported a driver for the apple localtalk ISA card. I was wondering if anyone had information on this. Or if anyone can help me with my localtalk card. Thank you Arie From owner-freebsd-hackers Thu Nov 13 07:30:32 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id HAA20721 for hackers-outgoing; Thu, 13 Nov 1997 07:30:32 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from ns.samara.net (ns.samara.net [195.128.128.1]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id HAA20675 for ; Thu, 13 Nov 1997 07:30:21 -0800 (PST) (envelope-from pm@ns.online.samara.ru) Received: from ns.online.samara.ru ([195.128.128.206]) by ns.samara.net (8.7.5/8.7.3) with ESMTP id TAA15420 for ; Thu, 13 Nov 1997 19:50:25 +0400 (KSK) Received: by ns.online.samara.ru id TAA00215; (8.8.5/vak/1.9) Thu, 13 Nov 1997 19:21:56 GMT To: freebsd-hackers@freebsd.org Message-ID: Organization: Cronyx Ltd. From: "Postmaster" Date: Thu, 13 Nov 97 19:21:56 +0000 X-Mailer: BML [UNIX Beauty Mail v.1.39] Subject: ipfw and syslog.conf Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I insert in syslog.conf next strings !ipfw *.* /var/log/ipfw.log but all ipfw output direct to console What I must doing that the ipfw output put to ipfw.log From owner-freebsd-hackers Thu Nov 13 07:47:18 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id HAA21835 for hackers-outgoing; Thu, 13 Nov 1997 07:47:18 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from sos.freebsd.dk (sos.freebsd.dk [195.8.129.33]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id HAA21830 for ; Thu, 13 Nov 1997 07:47:14 -0800 (PST) (envelope-from sos@sos.freebsd.dk) Received: (from sos@localhost) by sos.freebsd.dk (8.8.8/8.7.3) id QAA05296; Thu, 13 Nov 1997 16:47:49 +0100 (MET) Message-Id: <199711131547.QAA05296@sos.freebsd.dk> Subject: Re: Technical know-how In-Reply-To: <199711131258.UAA04803@net1.nw.com.au> from beav at "Nov 13, 97 09:03:43 pm" To: beav@nw.com.au (beav) Date: Thu, 13 Nov 1997 16:47:48 +0100 (MET) Cc: hackers@FreeBSD.ORG From: Søren Schmidt Reply-to: sos@FreeBSD.dk X-Mailer: ELM [version 2.4ME+ PL30 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk In reply to beav who wrote: > Hi people :) > > Just wondering if anyone had any experience with NEC IDE 6x4 CD changers > working in 2.2.x? I know they work in Linux, using a proggie called eject > and another called cdload. Any ideas? There is rudimentary support in -current. You could take the relevant files (wcd.c & atapi.h I think), and stick them into a 2.2.x system, should work with minimal patches... The support will be better as soon as I get a little time and get the stuff committed... -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Søren Schmidt (sos@FreeBSD.org) FreeBSD Core Team Even more code to hack -- will it ever end .. From owner-freebsd-hackers Thu Nov 13 08:51:21 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id IAA25758 for hackers-outgoing; Thu, 13 Nov 1997 08:51:21 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from iworks.InterWorks.org (deischen@iworks.interworks.org [128.255.18.10]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id IAA25749 for ; Thu, 13 Nov 1997 08:51:16 -0800 (PST) (envelope-from deischen@iworks.InterWorks.org) Received: (from deischen@localhost) by iworks.InterWorks.org (8.7.5/) id KAA24076; Thu, 13 Nov 1997 10:52:37 -0600 (CST) Message-Id: <199711131652.KAA24076@iworks.InterWorks.org> Date: Thu, 13 Nov 1997 10:52:37 -0600 (CST) From: "Daniel M. Eischen" To: bicknell@ufp.org, freebsd-hackers@FreeBSD.ORG Subject: Re: AHC / SCSI Problem? Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > We've been having some problems here with FreeBSD, > Adaptec 2940's, and various disk drives. I think we're > hitting some sort of driver bug but would like feedback. > Basically we get these errors from time to time, usualy > during a backup operation. Other than a few complaints > from dump they don't seem to have any operation impact. > I do find it interesting that it happens on the Micropolis > 4221 disks. Perhaps there is something "special" about them. > > I have a theory myself that turning on TAGENABLE and > I have a theory myself that turning on TAGENABLE and > SCBPAGING_ENABLE might actually help this situation, but > I'm not going to try it unless an expert thinks this is a > good idea as well. These are both production machines, so > experimenting is a problem, but if we have some good leads > we can do some work to track this down. > On system number 1 we have: > ahc0 rev 0 int a irq 9 on pci0:18 > ahc0: aic7880 Single Channel, SCSI Id=7, 16 SCBs > ahc0 waiting for scsi devices to settle > (ahc0:0:0): "MICROP 4221-09 1128RV 28RV" type 0 fixed SCSI 2 > sd0(ahc0:0:0): Direct-Access 1955MB (4004219 512 byte sectors) > (ahc0:1:0): "MICROP 4221-09 1128RV 28RV" type 0 fixed SCSI 2 > sd1(ahc0:1:0): Direct-Access 1955MB (4004219 512 byte sectors) > (ahc0:2:0): "SEAGATE ST15150N 0022" type 0 fixed SCSI 2 > sd2(ahc0:2:0): Direct-Access 4095MB (8388315 512 byte sectors) Methinks you're leaving out some important information. What is the rest of this list of devices? How is the bus terminated? I'm guessing you're using the tape drive to terminate one end of the bus. If so, don't do that and use one of the drives to terminate the bus as it will (most likely) use active termination as opposed to passive termination that you're probably getting with the tape drive. Aside from possible driver bugs, improper termination and /or cabling is probably at fault. Dan Eischen deischen@iworks.InterWorks.org From owner-freebsd-hackers Thu Nov 13 08:56:47 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id IAA26422 for hackers-outgoing; Thu, 13 Nov 1997 08:56:47 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from trojanhorse.ml.org (mdean.vip.best.com [206.86.94.101]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id IAA26412 for ; Thu, 13 Nov 1997 08:56:41 -0800 (PST) (envelope-from jamil@trojanhorse.ml.org) Received: from localhost (jamil@localhost) by trojanhorse.ml.org (8.8.8/8.8.5) with SMTP id IAA00247; Thu, 13 Nov 1997 08:56:06 -0800 (PST) Date: Thu, 13 Nov 1997 08:56:06 -0800 (PST) From: "Jamil J. Weatherbee" To: john hood cc: jerry_hicks@bigfoot.com, FreeBSD-Hackers Subject: Re: Pentium Bug Fix... In-Reply-To: <199711130638.BAA16748@smoke.marlboro.vt.us> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Oh thats good, just what we need. Hack a damn module binary to figure out what it is doing. Anybody have any real data on how this might be repaired? Makes me wonder if they are scanning the code segment of all loaded programs for that pattern or something evil to that extent. That would be basically like a heuristic virus scanner under dos? I guess the intel bug just made a whole lot of servers into dos machines. On Thu, 13 Nov 1997, john hood wrote: > Jerry Hicks writes: > > Richard M. Neswold wrote: > > > > > > Apparently Intel has helped BSDI in creating a fix to the Pentium bug: > > > > > > ftp://ftp.bsdi.com/bsdi/patches/patches-3.1/M310-hangfix > > > > > > Rich > > > > > > ------------------------------------------------------------------------ > > > Richard Neswold, Accelerator Div./Controls Dept | neswold@fnal.gov > > > Fermilab, PO Box 500, MS 347, Batavia, IL 60510 | voice (630) 840-3454 > > > 'finger neswold@aduxb.fnal.gov' for PGP key | fax (630) 840-3093 > > > > And I get: > > > > The M310-hangfix beta patch is unavailable at the moment. We'll > > keep everyone posted. > > It's still available on the ftp.uu.net mirror. > > --jh > > -- > Mr. Belliveau said, "the difference was the wise, John Hood, cgull > intelligent look on the face of the cow." He was @ > *so* right. --Ofer Inbar smoke.marlboro.vt.us > From owner-freebsd-hackers Thu Nov 13 09:15:20 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id JAA27834 for hackers-outgoing; Thu, 13 Nov 1997 09:15:20 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id JAA27829 for ; Thu, 13 Nov 1997 09:15:16 -0800 (PST) (envelope-from perlsta@cs.sunyit.edu) Received: from pooh.cdrom.com (pooh.cdrom.com [204.216.28.222]) by freefall.freebsd.org (8.8.6/8.8.5) with ESMTP id JAA07573 for ; Thu, 13 Nov 1997 09:12:51 -0800 (PST) Received: from server.local.sunyit.edu (A-T34.rh.sunyit.edu [150.156.210.241]) by pooh.cdrom.com (8.8.5/8.7.3) with ESMTP id JAA05955 for ; Thu, 13 Nov 1997 09:14:56 -0800 (PST) Received: from localhost (perlsta@localhost) by server.local.sunyit.edu (8.8.7/8.8.5) with SMTP id NAA15440; Thu, 13 Nov 1997 13:15:58 -0500 (EST) X-Authentication-Warning: server.local.sunyit.edu: perlsta owned process doing -bs Date: Thu, 13 Nov 1997 13:15:57 -0500 (EST) From: Alfred Perlstein X-Sender: perlsta@server.local.sunyit.edu To: "Barfuß Egon jun." cc: firewalls@GreatCircle.COM, ntsecurity@iss.net, hackers@FreeBSD.com Subject: Re: Need a Firewall but don´t know which one In-Reply-To: <346ABBED.9B263F33@computronic.at> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by hub.freebsd.org id JAA27830 Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk simply, FreeBSD offers a firewall where TCP and UDP traffic can be blocked, allowed or even diverted into a program for it to processes. and it's free. -Al On Thu, 13 Nov 1997, Barfuß Egon jun. wrote: > Hi there, > > Big problem! > We are running an internet server but till now we don´t have any > firewall. Now I´m searching one but don´t know which one I should take. > > I found a site http://www.waterw.com/~manowar/vendor.html with many > various products and platforms and I got some informations about > WatchGuard. Does anyone know something about it? > > Is NT a good platform??? I heard that it is a bit unsecure because some > problems with TCP/IP ports and Redbutton. > > What do you think about it and which platform/system is the best/better > one?? > > Thanks in advance > > Egon > > -- > Egon Barfusz > Gottschallingerstr. 6 > 4030 Linz > mailto:egon@computronic.at > mailto:egon.barfusz@ambos.co.at > > > From owner-freebsd-hackers Thu Nov 13 09:27:15 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id JAA28895 for hackers-outgoing; Thu, 13 Nov 1997 09:27:15 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from spiv.fnal.gov (spiv.fnal.gov [131.225.124.126]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id JAA28879 for ; Thu, 13 Nov 1997 09:27:03 -0800 (PST) (envelope-from neswold@spiv.fnal.gov) Received: from localhost (neswold@localhost) by spiv.fnal.gov (8.8.5/8.8.5) with SMTP id LAA26430; Thu, 13 Nov 1997 11:26:34 -0600 (CST) Date: Thu, 13 Nov 1997 11:26:33 -0600 (CST) From: "Richard M. Neswold" Reply-To: neswold@fnal.gov To: "Jamil J. Weatherbee" cc: FreeBSD-Hackers Subject: Re: Pentium Bug Fix... In-Reply-To: Message-ID: X-Spambot-Food: abuse@localhost postmaster@localhost abuse@fbi.gov MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Thu, 13 Nov 1997, Jamil J. Weatherbee wrote: > > Oh thats good, just what we need. Hack a damn module binary to figure out > what it is doing. Anybody have any real data on how this might be > repaired? > > > > Richard M. Neswold wrote: > > > > > > > > Apparently Intel has helped BSDI in creating a fix to the Pentium bug: > > > > > > > > ftp://ftp.bsdi.com/bsdi/patches/patches-3.1/M310-hangfix I never said it could directly be used in FreeBSD; I thought it was interesting that Intel helped BSDI come up with a fix (before Microsoft.) I also thought my posting would give kernel-knowledgable people another direction in which to solve this problem. I apologize, Jamil, for not posting the exact lines of code needed to fix the problem. Sheesh. Rich ------------------------------------------------------------------------ Richard Neswold, Accelerator Div./Controls Dept | neswold@fnal.gov Fermilab, PO Box 500, MS 347, Batavia, IL 60510 | voice (630) 840-3454 'finger neswold@aduxb.fnal.gov' for PGP key | fax (630) 840-3093 From owner-freebsd-hackers Thu Nov 13 10:09:23 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id KAA03684 for hackers-outgoing; Thu, 13 Nov 1997 10:09:23 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from phoenix.its.rpi.edu (phoenix.its.rpi.edu [128.113.161.45]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id KAA03671 for ; Thu, 13 Nov 1997 10:09:09 -0800 (PST) (envelope-from dec@phoenix.its.rpi.edu) Received: from localhost (dec@localhost) by phoenix.its.rpi.edu (8.8.7/8.8.7) with SMTP id NAA07356 for ; Thu, 13 Nov 1997 13:09:18 -0500 (EST) (envelope-from dec@phoenix.its.rpi.edu) Date: Thu, 13 Nov 1997 13:09:17 -0500 (EST) From: "David E. Cross" To: freebsd-hackers@freebsd.org Subject: Re: Pentium Bug Fix... In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Thu, 13 Nov 1997, Richard M. Neswold wrote: > On Thu, 13 Nov 1997, Jamil J. Weatherbee wrote: > > > > > Oh thats good, just what we need. Hack a damn module binary to figure out > > what it is doing. Anybody have any real data on how this might be > > repaired? > > > > > > Richard M. Neswold wrote: > > > > > > > > > > Apparently Intel has helped BSDI in creating a fix to the Pentium bug: > > > > > > > > > > ftp://ftp.bsdi.com/bsdi/patches/patches-3.1/M310-hangfix > > I never said it could directly be used in FreeBSD; I thought it was > interesting that Intel helped BSDI come up with a fix (before Microsoft.) I > also thought my posting would give kernel-knowledgable people another > direction in which to solve this problem. > > I apologize, Jamil, for not posting the exact lines of code needed to fix > the problem. I would be interested in seeing the alledged Linux 'fix'. -- David Cross ACS Consultant From owner-freebsd-hackers Thu Nov 13 10:10:03 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id KAA03758 for hackers-outgoing; Thu, 13 Nov 1997 10:10:03 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from mail1.its.rpi.edu (root@mail1.its.rpi.edu [128.113.100.7]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id KAA03726 for ; Thu, 13 Nov 1997 10:09:55 -0800 (PST) (envelope-from gad@eclipse.its.rpi.edu) Received: from eclipse.its.rpi.edu (gad@eclipse.its.rpi.edu [128.113.24.33]) by mail1.its.rpi.edu (8.8.5/8.8.5) with SMTP id NAA117794 for ; Thu, 13 Nov 1997 13:09:44 -0500 Received: by eclipse.its.rpi.edu (NX5.67e/NX3.0M) id AA29400; Thu, 13 Nov 97 13:09:43 -0500 Message-Id: <9711131809.AA29400@eclipse.its.rpi.edu> Mime-Version: 1.0 (NeXT Mail 3.3 v118.2) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Received: by NeXT.Mailer (1.118.2) From: Garance A Drosehn Date: Thu, 13 Nov 97 13:09:40 -0500 To: hackers@FreeBSD.ORG Subject: Re: Virtual Intel Machines? References: <346A3CA7.237C228A@n2k.com> Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Richard Costine wrote: > ... I agree that you couldn't do it exactly the way that VM is > doing it. You would have to emulate everything. [...] This would > make the emulator much slower than a real pentium, ... This would basically be the same as the VirtualPC product that exists for the PowerMac. > Yes, this would be a "Nice Thing to Have". It opens up lots of > possibilities. You could have a real sandbox to run intel-based > code in. We all know there's lots of that about. It is nice to have (I do have VirtualPC on the PowerMac), although the performance hit of an emulator makes it much less enticing for what I wanted to do with it. We (RPI) will be getting more high-end Intel-based systems for public labs here, and I'd love to set them up to run multiple operating systems (WinNT, Rhapsody, and FreeBSD, for instance). The trick is to set that up in such a way that we don't have to worry about students playing with the machines. I had this vision of freebsd being the "real" operating system (in the roll of VM on an IBM mainframe), and then have the other operating systems running as virtual machines underneath that. We wouldn't have to care as much about what students did in those virtual machines, as the "real" OS could always reset the state of a virtual machine to what we (the computing center) wanted it to be. > The point is not how fast it'll run but *that* it'll run. Well, for the things I wanted it *is* important how fast it runs. I don't think I could get away with a public lab of new high-end Pentium II machines that ran like 75Mhz pentiums!! :-) Of course, given that Intel chips work the way they do, it sounds like it'd be pretty much impossible to do what I was hoping for. Sigh. It was such a cool idea, too. --- Garance Alistair Drosehn = gad@eclipse.its.rpi.edu Senior Systems Programmer (MIME & NeXTmail capable) Rensselaer Polytechnic Institute; Troy NY USA From owner-freebsd-hackers Thu Nov 13 10:16:54 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id KAA04309 for hackers-outgoing; Thu, 13 Nov 1997 10:16:54 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from out1.ibm.net (out1.ibm.net [165.87.194.252]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id KAA04301 for ; Thu, 13 Nov 1997 10:16:50 -0800 (PST) (envelope-from mouth@ibm.net) Received: from slip129-37-53-98.ca.us.ibm.net (slip129-37-53-98.ca.us.ibm.net [129.37.53.98]) by out1.ibm.net (8.8.5/8.6.9) with SMTP id SAA16948; Thu, 13 Nov 1997 18:16:35 GMT From: mouth@ibm.net (John Kelly) To: Bruce Evans Cc: hackers@freebsd.org Subject: Re: Status of 650 UART support Date: Thu, 13 Nov 1997 19:17:49 GMT Message-ID: <346e5246.10042871@smtp-gw01.ny.us.ibm.net> References: <199711130737.SAA02104@godzilla.zeta.org.au> In-Reply-To: <199711130737.SAA02104@godzilla.zeta.org.au> X-Mailer: Forte Agent 1.01/16.397 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by hub.freebsd.org id KAA04302 Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Thu, 13 Nov 1997 18:37:56 +1100, Bruce Evans wrote: >>> RTS pin will be forced to high state regardless of its original >>> state when receive FIFO reaches to the programmed trigger level. > >So the pessimization is standard on Startechs :-(. The RTS trigger >level should be slightly higher than the FIFO trigger level. Not standard. It's only activated if you set EFR bit 6 to 1, which sio.c apparently does for a 650. >>=46CR bit 7 and 6 550 650 >> 00 1 8 >> 01 4 16 >> 10 8 24 >> 11 14 28 >sio actually uses 11. This gives a useful reduction of input inputs >vs. 10 and doesn't cause slo overflows for normal setups with <= 4 ports >and no (broken) bus-hogging DMA controllers. I have a near worst case scenario. I have an interrupt-sharing multiport serial adapter with eight 650s all sharing one interrupt. The clock for each UART can be individually set (via hardware jumper) to 1.8432MHz, 3.6864MHz, or 7.3728MHz, for a maximum port speed of 115.2k, 230.4k, or 460.8k. I seem to recall from sio.c that in the case of a multiport serial adapter, the ISR itself will look at every port and try to drain it. Since reducing input interrupts is a worthy goal, why not enable auto RTS and simply run the 650 receive FIFO in polled mode? You could start up in normal interrupt driven mode and jump to polled mode when data starts streaming in. With the auto RTS feature activated, the 650 will suspend the inbound data stream from the external device when necessary to prevent UART overruns, as the external device would be expected to have a large (2k? 4k?) buffer of its own to accumulate inbound data until the 650 gives it the green light again. In the case of a multiport serial adapter, each port could have a flag in sio.c which tells whether it's working in polled mode or interrupt mode. Whenever you poll the ports which are streaming data in, you would only have to check the ones which have their polling flag on, because any of the other ports not being polled would still get your attention by means of an interrupt. With a multiport serial adapter, that would eliminate some of the present overhead in the ISR where you have to check each port for inbound data every time the ISR runs. The ISR would still have to check each port which does not have its polling flag on, but as port usage increases, that ISR overhead would decrease. >>So if you don't set EFR bit 4, the 650 transmit FIFO is still only one >>byte just like a 550. And I don't recall seeing any code in sio.c to >>set EFR bit 4. > >It only sets the software tx_fifo_size to 32. This is apparently the >default if the fifos are enabled in the 16550 way. This is 16550- >compatible because the space in the fifo is not readable so 16550 >drivers would only ever put 16 bytes in the fifo. After rereading my statement above it appears misleading. It should say the 650 transmit FIFO "interrupt trigger level" is one byte after reset, but the actual FIFO capacity is nevertheless 32 bytes. The databook says the 650 "will issue a transmit empty interrupt when number of characters in FIFO drops *below* selected trigger level" So with FIFOs enabled and a default transmit trigger level of 1 (after reset) the transmitter interrupt will be issued when the FIFO drops *below* 1, not to 1. That would make the transmit interrupt function emulate the 550 which issues the interrupt when the transmit FIFO is empty, at least by default. I was somewhat confused by the *below* 1 wording before. John From owner-freebsd-hackers Thu Nov 13 10:17:08 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id KAA04346 for hackers-outgoing; Thu, 13 Nov 1997 10:17:08 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from out1.ibm.net (out1.ibm.net [165.87.194.252]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id KAA04329 for ; Thu, 13 Nov 1997 10:17:03 -0800 (PST) (envelope-from mouth@ibm.net) Received: from slip129-37-53-98.ca.us.ibm.net (slip129-37-53-98.ca.us.ibm.net [129.37.53.98]) by out1.ibm.net (8.8.5/8.6.9) with SMTP id SAA83994; Thu, 13 Nov 1997 18:16:53 GMT From: mouth@ibm.net (John Kelly) To: Bruce Evans Cc: hackers@FreeBSD.ORG Subject: Re: Status of 650 UART support Date: Thu, 13 Nov 1997 19:18:08 GMT Message-ID: <346d4ceb.8671504@smtp-gw01.ny.us.ibm.net> References: <199711130935.UAA06342@godzilla.zeta.org.au> In-Reply-To: <199711130935.UAA06342@godzilla.zeta.org.au> X-Mailer: Forte Agent 1.01/16.397 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by hub.freebsd.org id KAA04330 Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Thu, 13 Nov 1997 20:35:53 +1100, Bruce Evans wrote: >>Why can't we handle large bursts of input? > >Buffer sizes are finite. Can't we use malloc to create elastic buffers on the fly? Is that a no-no in the kernel? >Multiply some of these numbers by 4 for 64-bit fifos and you have >seriously high (normal worst case) latencies. (My definition of ``high'' >is anything that would stop an 8250 from working at 115200 bps - 87 >usec :-). I will reduce this when faster speeds become common.) Why not start from scratch and develop siov2.c which uses elastic buffers, 650 polled vs. interrupt mode switching, yada, yada, yada. Sio.c could still be the default while siov2.c could be selected on a port by port basis with a kernel config flag. Now if someone foolhardy enough to undertake such a project would step forward (don't look in my direction, I know better). ;-) John From owner-freebsd-hackers Thu Nov 13 10:19:45 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id KAA04557 for hackers-outgoing; Thu, 13 Nov 1997 10:19:45 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from milf18.bus.net (milf18.bus.net [207.41.25.18]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id KAA04551 for ; Thu, 13 Nov 1997 10:19:40 -0800 (PST) (envelope-from cao@bus.net) Received: from localhost (cao@localhost) by milf18.bus.net (8.8.5/8.8.5) with SMTP id NAA00305 for ; Thu, 13 Nov 1997 13:19:26 -0500 (EST) X-Authentication-Warning: milf18.bus.net: cao owned process doing -bs Date: Thu, 13 Nov 1997 13:19:26 -0500 (EST) From: "Chuck O'Donnell" To: freebsd-hackers@freebsd.org Subject: /dev/speaker Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Does anyone know a good way to beep the speaker from a CGI script? I found the 'pseudo-device speaker' in /sys/i386/conf/LINT, which uses the spkr.c driver to gain access through open("/dev/speaker", ...). Are there any other ways to access the computer speaker directly? I am not subscribed to this list so please send responses directly. Thank you. Chuck O'Donnell From owner-freebsd-hackers Thu Nov 13 10:44:38 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id KAA06662 for hackers-outgoing; Thu, 13 Nov 1997 10:44:38 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from whistle.com (s205m131.whistle.com [207.76.205.131]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id KAA06656 for ; Thu, 13 Nov 1997 10:44:35 -0800 (PST) (envelope-from archie@whistle.com) Received: (from smap@localhost) by whistle.com (8.7.5/8.6.12) id KAA13401; Thu, 13 Nov 1997 10:44:04 -0800 (PST) Received: from bubba.whistle.com(207.76.205.7) by whistle.com via smap (V1.3) id sma013395; Thu Nov 13 10:43:51 1997 Received: (from archie@localhost) by bubba.whistle.com (8.8.5/8.6.12) id KAA19571; Thu, 13 Nov 1997 10:43:51 -0800 (PST) From: Archie Cobbs Message-Id: <199711131843.KAA19571@bubba.whistle.com> Subject: Re: ipfw and syslog.conf In-Reply-To: from Postmaster at "Nov 13, 97 07:21:56 pm" To: pm@ns.online.samara.ru (Postmaster) Date: Thu, 13 Nov 1997 10:43:51 -0800 (PST) Cc: freebsd-hackers@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-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Postmaster writes: > I insert in syslog.conf next strings > > !ipfw > *.* /var/log/ipfw.log > > but all ipfw output direct to console > What I must doing that the ipfw output put to ipfw.log What appears on the console is determined by a different line in /etc/syslog.conf (namely, the one that says "/dev/console"). Take a look at the syslog.conf(5) man page and compare with the entries in your /etc/syslog.conf to see if the behavior you're seeing makes sense. -Archie ___________________________________________________________________________ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com From owner-freebsd-hackers Thu Nov 13 10:49:12 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id KAA07077 for hackers-outgoing; Thu, 13 Nov 1997 10:49:12 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from whistle.com (s205m131.whistle.com [207.76.205.131]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id KAA07066 for ; Thu, 13 Nov 1997 10:49:09 -0800 (PST) (envelope-from archie@whistle.com) Received: (from smap@localhost) by whistle.com (8.7.5/8.6.12) id KAA13431; Thu, 13 Nov 1997 10:48:34 -0800 (PST) Received: from bubba.whistle.com(207.76.205.7) by whistle.com via smap (V1.3) id sma013429; Thu Nov 13 10:48:17 1997 Received: (from archie@localhost) by bubba.whistle.com (8.8.5/8.6.12) id KAA19595; Thu, 13 Nov 1997 10:48:17 -0800 (PST) From: Archie Cobbs Message-Id: <199711131848.KAA19595@bubba.whistle.com> Subject: Re: unkillable process In-Reply-To: from Simon Shapiro at "Nov 12, 97 08:33:50 pm" To: Shimon@i-connect.net (Simon Shapiro) Date: Thu, 13 Nov 1997 10:48:17 -0800 (PST) Cc: freebsd-hackers@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-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Simon Shapiro writes: > Hi Archie Cobbs; On 12-Nov-97 you wrote: > > Try the following experiment (on 2.2 and mabye 3.0): > > > > 1. Create a named pipe > > 2. Start typing into it using cat > > 3. Hit control-C as many times as you want > > > > You'll see that the process will not die even with kill -9, > > as it is stuck in uninterrupible disk sleep ("fifo"). > > > > But as soon as you read from the other end of the pipe, > > the process exits. > > > > Is there a missing PCATCH flag to tsleep() somewhere? > > Is this appropriate behavior? (hint: rhetorical question) > > From what I remember, this is a typical (if ugly Unix behavior. Hmm... does anyone else besides me have the opinion that, while it may be typical, this behavior is also *broken*? Still Curious, -Archie ___________________________________________________________________________ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com From owner-freebsd-hackers Thu Nov 13 10:50:24 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id KAA07185 for hackers-outgoing; Thu, 13 Nov 1997 10:50:24 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id KAA07171 for ; Thu, 13 Nov 1997 10:50:18 -0800 (PST) (envelope-from julian@whistle.com) Received: (from daemon@localhost) by alpo.whistle.com (8.8.5/8.8.5) id KAA11857 for ; Thu, 13 Nov 1997 10:40:58 -0800 (PST) Received: from UNKNOWN(), claiming to be "current1.whistle.com" via SMTP by alpo.whistle.com, id smtpd011853; Thu Nov 13 10:40:55 1997 Message-ID: <346B4942.15FB7483@whistle.com> Date: Thu, 13 Nov 1997 10:38:59 -0800 From: Julian Elischer Organization: Whistle Communications X-Mailer: Mozilla 3.0Gold (X11; I; FreeBSD 2.2-CURRENT i386) MIME-Version: 1.0 To: hackers@freebsd.org Subject: SUID-Directories patch Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I'd like to move this to 2.2.x It is all hidden behind #ifdef SUIDDIR so I can guarantee that it won't BREAK anything. I really need it n 2.2 rather than 3.0 so I'd like to merge it in from -current later thes afternoon if I don't hear any objections. I'm also soliciting more 'reviewers' to check what I've done. julian From owner-freebsd-hackers Thu Nov 13 10:59:38 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id KAA07963 for hackers-outgoing; Thu, 13 Nov 1997 10:59:38 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from nomis.i-connect.net (nomis.i-Connect.Net [206.190.143.100] (may be forged)) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id KAA07952 for ; Thu, 13 Nov 1997 10:59:35 -0800 (PST) (envelope-from shimon@i-connect.net) Received: (qmail 15662 invoked by uid 1000); 13 Nov 1997 18:59:43 -0000 Message-ID: X-Mailer: XFMail 1.2-beta-111097 [p0] on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit MIME-Version: 1.0 In-Reply-To: <199711131848.KAA19595@bubba.whistle.com> Date: Thu, 13 Nov 1997 10:59:43 -0800 (PST) Organization: Atlas Telecom From: Simon Shapiro To: Archie Cobbs Subject: Re: unkillable process Cc: freebsd-hackers@FreeBSD.ORG Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hi Archie Cobbs; On 13-Nov-97 you wrote: > Simon Shapiro writes: > > Hi Archie Cobbs; On 12-Nov-97 you wrote: > > > Try the following experiment (on 2.2 and mabye 3.0): > > > > > > 1. Create a named pipe > > > 2. Start typing into it using cat > > > 3. Hit control-C as many times as you want > > > > > > You'll see that the process will not die even with kill -9, > > > as it is stuck in uninterrupible disk sleep ("fifo"). > > > > > > But as soon as you read from the other end of the pipe, > > > the process exits. > > > > > > Is there a missing PCATCH flag to tsleep() somewhere? > > > Is this appropriate behavior? (hint: rhetorical question) > > > > From what I remember, this is a typical (if ugly Unix behavior. > > Hmm... does anyone else besides me have the opinion that, > while it may be typical, this behavior is also *broken*? Oh, I agree it is broken. I could never understand why certain syscalls block without PCATCH. --- If Microsoft Built Cars: Every time they repainted the lines on the road, you'd have to buy a new car. Sincerely Yours, Simon Shapiro Atlas Telecom Senior Architect 14355 SW Allen Blvd., Suite 130 Beaverton OR 97005 Shimon@i-Connect.Net Voice: 503.799.2313 From owner-freebsd-hackers Thu Nov 13 11:08:19 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id LAA08709 for hackers-outgoing; Thu, 13 Nov 1997 11:08:19 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from smtp04.primenet.com (smtp04.primenet.com [206.165.5.85]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id LAA08704 for ; Thu, 13 Nov 1997 11:08:12 -0800 (PST) (envelope-from tlambert@usr08.primenet.com) Received: (from daemon@localhost) by smtp04.primenet.com (8.8.7/8.8.7) id MAA14341; Thu, 13 Nov 1997 12:08:03 -0700 (MST) Received: from usr08.primenet.com(206.165.6.208) via SMTP by smtp04.primenet.com, id smtpd014331; Thu Nov 13 12:07:59 1997 Received: (from tlambert@localhost) by usr08.primenet.com (8.8.5/8.8.5) id MAA28899; Thu, 13 Nov 1997 12:07:58 -0700 (MST) From: Terry Lambert Message-Id: <199711131907.MAA28899@usr08.primenet.com> Subject: Re: BSDI F0 bug workaround implementation To: rminnich@Sarnoff.COM (Ron G. Minnich) Date: Thu, 13 Nov 1997 19:07:58 +0000 (GMT) Cc: freebsd-hackers@FreeBSD.ORG In-Reply-To: from "Ron G. Minnich" at Nov 13, 97 09:31:07 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > I'm not sure I understand the full implications of the impact of this > hack, although it is worrisome. Judging by what my pentium book says about > the layout of the IDT, it seems like it will increase interrupt latency > for page faults and many maskable interrupts. Can anyone more > knowledgeable than I comment on this? Page fault overhead on freebsd is > pretty high: would a short-cut make sense that does not go through the > full vm system for this? Otherwise page fault overhead may come close to > doubling ... Only the first 7 IDT entries are affected (at least in the Linux workaround), not the whole table. On the minus side, the impact *is* non-zero. Like the FPU bug, since a workaround exists, it's likely to be swept under the software as well. 8-(. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Thu Nov 13 11:39:32 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id LAA11968 for hackers-outgoing; Thu, 13 Nov 1997 11:39:32 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from trojanhorse.ml.org (mdean.vip.best.com [206.86.94.101]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id LAA11962 for ; Thu, 13 Nov 1997 11:39:29 -0800 (PST) (envelope-from jamil@trojanhorse.ml.org) Received: from localhost (jamil@localhost) by trojanhorse.ml.org (8.8.8/8.8.5) with SMTP id LAA00539; Thu, 13 Nov 1997 11:39:06 -0800 (PST) Date: Thu, 13 Nov 1997 11:39:06 -0800 (PST) From: "Jamil J. Weatherbee" To: "Chuck O'Donnell" cc: freebsd-hackers@FreeBSD.ORG Subject: Re: /dev/speaker In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk printf "\a" On Thu, 13 Nov 1997, Chuck O'Donnell wrote: > > Does anyone know a good way to beep the speaker from a CGI script? > > I found the 'pseudo-device speaker' in /sys/i386/conf/LINT, which uses the > spkr.c driver to gain access through open("/dev/speaker", ...). > > Are there any other ways to access the computer speaker directly? > > I am not subscribed to this list so please send responses directly. > > Thank you. > > Chuck O'Donnell > > From owner-freebsd-hackers Thu Nov 13 11:50:23 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id LAA13237 for hackers-outgoing; Thu, 13 Nov 1997 11:50:23 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from trojanhorse.ml.org (mdean.vip.best.com [206.86.94.101]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id LAA13212 for ; Thu, 13 Nov 1997 11:50:05 -0800 (PST) (envelope-from jamil@trojanhorse.ml.org) Received: from localhost (jamil@localhost) by trojanhorse.ml.org (8.8.8/8.8.5) with SMTP id LAA00560; Thu, 13 Nov 1997 11:49:36 -0800 (PST) Date: Thu, 13 Nov 1997 11:49:36 -0800 (PST) From: "Jamil J. Weatherbee" To: John Kelly cc: Bruce Evans , hackers@FreeBSD.ORG Subject: Re: Status of 650 UART support In-Reply-To: <346d4ceb.8671504@smtp-gw01.ny.us.ibm.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Speaking of elastic buffers, this is the kind of thing that I really need in my data acquisition stuff because much like sio once those things are open data is basically spewed in. Perhaps somebody would care to do a general "elastic buffer" implementation where the driver could set a threshold saying that for instance "there is no way I could fill more than nn bytes in a second" and then every second the elastic buffer module could reevaluate the drivers need for buffer based on how much it had actually filled and provide additional margin until the next second. Of course this would also need to be bounded someway. A better solution of course would be a realtime extension where you could somehow force the incoming data off into userspace (and you wonder why networking is done in the kernel??). ** Note: very general idea!! Someone help me out here ** The big difference on these kind of devices is that the user _doesn't_ ask for data, it just arrives. So all the fancy buffering in the world isn't worth shit if it is not _immediately_ available in the interrupt routine. Hell that might be the solution -- you should be able to have 2 fifos, when A fills up switch to B and force the A to be exchanged for C by the kernel. Then maybye A would be force off to a unix domain socket somewhere. I am not really sure what happens to unix sockets that get spewed to. On Thu, 13 Nov 1997, John Kelly wrote: > On Thu, 13 Nov 1997 20:35:53 +1100, Bruce Evans > wrote: > > >>Why can't we handle large bursts of input? > > > >Buffer sizes are finite. > > Can't we use malloc to create elastic buffers on the fly? Is that a > no-no in the kernel? > > >Multiply some of these numbers by 4 for 64-bit fifos and you have > >seriously high (normal worst case) latencies. (My definition of ``high'' > >is anything that would stop an 8250 from working at 115200 bps - 87 > >usec :-). I will reduce this when faster speeds become common.) > > Why not start from scratch and develop siov2.c which uses elastic > buffers, 650 polled vs. interrupt mode switching, yada, yada, yada. > Sio.c could still be the default while siov2.c could be selected on a > port by port basis with a kernel config flag. > > Now if someone foolhardy enough to undertake such a project would step > forward (don't look in my direction, I know better). ;-) > > John > > > From owner-freebsd-hackers Thu Nov 13 11:57:08 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id LAA13955 for hackers-outgoing; Thu, 13 Nov 1997 11:57:08 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from server.local.sunyit.edu (A-T34.rh.sunyit.edu [150.156.210.241]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id LAA13940 for ; Thu, 13 Nov 1997 11:56:57 -0800 (PST) (envelope-from perlsta@cs.sunyit.edu) Received: from localhost (perlsta@localhost) by server.local.sunyit.edu (8.8.7/8.8.5) with SMTP id QAA15677 for ; Thu, 13 Nov 1997 16:00:54 -0500 (EST) X-Authentication-Warning: server.local.sunyit.edu: perlsta owned process doing -bs Date: Thu, 13 Nov 1997 16:00:54 -0500 (EST) From: Alfred Perlstein X-Sender: perlsta@server.local.sunyit.edu To: hackers@FreeBSD.org Subject: Re: BSDI F0 bug workaround implementation (help with understanding) In-Reply-To: <199711131907.MAA28899@usr08.primenet.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk I've been following the thread on the Pentium CPU bug, i was wondering how a workaround is possible? it just seems very interesting. -Alfred On Thu, 13 Nov 1997, Terry Lambert wrote: > > I'm not sure I understand the full implications of the impact of this > > hack, although it is worrisome. Judging by what my pentium book says about > > the layout of the IDT, it seems like it will increase interrupt latency > > for page faults and many maskable interrupts. Can anyone more > > knowledgeable than I comment on this? Page fault overhead on freebsd is > > pretty high: would a short-cut make sense that does not go through the > > full vm system for this? Otherwise page fault overhead may come close to > > doubling ... > > Only the first 7 IDT entries are affected (at least in the Linux > workaround), not the whole table. > > On the minus side, the impact *is* non-zero. > > Like the FPU bug, since a workaround exists, it's likely to be swept > under the software as well. 8-(. > > > Terry Lambert > terry@lambert.org > --- > Any opinions in this posting are my own and not those of my present > or previous employers. > From owner-freebsd-hackers Thu Nov 13 11:57:53 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id LAA14045 for hackers-outgoing; Thu, 13 Nov 1997 11:57:53 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from phoenix.its.rpi.edu (phoenix.its.rpi.edu [128.113.161.45]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id LAA14035 for ; Thu, 13 Nov 1997 11:57:41 -0800 (PST) (envelope-from dec@phoenix.its.rpi.edu) Received: from localhost (dec@localhost) by phoenix.its.rpi.edu (8.8.7/8.8.7) with SMTP id OAA08389; Thu, 13 Nov 1997 14:57:45 -0500 (EST) (envelope-from dec@phoenix.its.rpi.edu) Date: Thu, 13 Nov 1997 14:57:45 -0500 (EST) From: "David E. Cross" To: Terry Lambert cc: "Ron G. Minnich" , freebsd-hackers@FreeBSD.ORG Subject: Re: BSDI F0 bug workaround implementation In-Reply-To: <199711131907.MAA28899@usr08.primenet.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Thu, 13 Nov 1997, Terry Lambert wrote: > Only the first 7 IDT entries are affected (at least in the Linux > workaround), not the whole table. > > On the minus side, the impact *is* non-zero. > > Like the FPU bug, since a workaround exists, it's likely to be swept > under the software as well. 8-(. > Yes, but Interupts are called much more frequently than floating-point instructions. I for one am going to email my intel representative and ask for a replacement... I think that it would be in intel's best interest to handle this with as little fuss as possible. -- David Cross ACS Consultant From owner-freebsd-hackers Thu Nov 13 11:58:52 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id LAA14160 for hackers-outgoing; Thu, 13 Nov 1997 11:58:52 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from server.local.sunyit.edu (A-T34.rh.sunyit.edu [150.156.210.241]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id LAA14136 for ; Thu, 13 Nov 1997 11:58:34 -0800 (PST) (envelope-from perlsta@cs.sunyit.edu) Received: from localhost (perlsta@localhost) by server.local.sunyit.edu (8.8.7/8.8.5) with SMTP id QAA15681; Thu, 13 Nov 1997 16:02:23 -0500 (EST) X-Authentication-Warning: server.local.sunyit.edu: perlsta owned process doing -bs Date: Thu, 13 Nov 1997 16:02:23 -0500 (EST) From: Alfred Perlstein X-Sender: perlsta@server.local.sunyit.edu To: Archie Cobbs cc: Simon Shapiro , freebsd-hackers@FreeBSD.ORG Subject: Re: unkillable process In-Reply-To: <199711131848.KAA19595@bubba.whistle.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >From what i understand the process 'cat' is not broken, the shell excuting the command will terminate if issued a 'kill -9' .________________________________________________________________________ __ _ |Alfred Perlstein - Programming & SysAdmin --"Have you seen my FreeBSD tatoo?" |perlsta@sunyit.edu --"who was that masked admin?" |http://www.cs.sunyit.edu/~perlsta : ' On Thu, 13 Nov 1997, Archie Cobbs wrote: > Simon Shapiro writes: > > Hi Archie Cobbs; On 12-Nov-97 you wrote: > > > Try the following experiment (on 2.2 and mabye 3.0): > > > > > > 1. Create a named pipe > > > 2. Start typing into it using cat > > > 3. Hit control-C as many times as you want > > > > > > You'll see that the process will not die even with kill -9, > > > as it is stuck in uninterrupible disk sleep ("fifo"). > > > > > > But as soon as you read from the other end of the pipe, > > > the process exits. > > > > > > Is there a missing PCATCH flag to tsleep() somewhere? > > > Is this appropriate behavior? (hint: rhetorical question) > > > > From what I remember, this is a typical (if ugly Unix behavior. > > Hmm... does anyone else besides me have the opinion that, > while it may be typical, this behavior is also *broken*? > > Still Curious, > -Archie > > ___________________________________________________________________________ > Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com > From owner-freebsd-hackers Thu Nov 13 12:01:12 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id MAA14429 for hackers-outgoing; Thu, 13 Nov 1997 12:01:12 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from whistle.com (s205m131.whistle.com [207.76.205.131]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id MAA14423 for ; Thu, 13 Nov 1997 12:01:10 -0800 (PST) (envelope-from archie@whistle.com) Received: (from smap@localhost) by whistle.com (8.7.5/8.6.12) id MAA14091; Thu, 13 Nov 1997 12:00:36 -0800 (PST) Received: from bubba.whistle.com(207.76.205.7) by whistle.com via smap (V1.3) id sma014087; Thu Nov 13 12:00:22 1997 Received: (from archie@localhost) by bubba.whistle.com (8.8.5/8.6.12) id MAA26869; Thu, 13 Nov 1997 12:00:21 -0800 (PST) From: Archie Cobbs Message-Id: <199711132000.MAA26869@bubba.whistle.com> Subject: Re: unkillable process In-Reply-To: from Alfred Perlstein at "Nov 13, 97 04:02:23 pm" To: perlsta@cs.sunyit.edu (Alfred Perlstein) Date: Thu, 13 Nov 1997 12:00:21 -0800 (PST) Cc: archie@whistle.com, Shimon@i-connect.net, freebsd-hackers@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-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Alfred Perlstein writes: > From what i understand the process 'cat' is not broken, the shell excuting > the command will terminate if issued a 'kill -9' Not on my machine... kill -9 does nothing (see original email). -Archie > .________________________________________________________________________ __ _ > |Alfred Perlstein - Programming & SysAdmin --"Have you seen my FreeBSD tatoo?" > |perlsta@sunyit.edu --"who was that masked admin?" > |http://www.cs.sunyit.edu/~perlsta > : > ' > > On Thu, 13 Nov 1997, Archie Cobbs wrote: > > > Simon Shapiro writes: > > > Hi Archie Cobbs; On 12-Nov-97 you wrote: > > > > Try the following experiment (on 2.2 and mabye 3.0): > > > > > > > > 1. Create a named pipe > > > > 2. Start typing into it using cat > > > > 3. Hit control-C as many times as you want > > > > > > > > You'll see that the process will not die even with kill -9, > > > > as it is stuck in uninterrupible disk sleep ("fifo"). > > > > > > > > But as soon as you read from the other end of the pipe, > > > > the process exits. > > > > > > > > Is there a missing PCATCH flag to tsleep() somewhere? > > > > Is this appropriate behavior? (hint: rhetorical question) > > > > > > From what I remember, this is a typical (if ugly Unix behavior. > > > > Hmm... does anyone else besides me have the opinion that, > > while it may be typical, this behavior is also *broken*? > > > > Still Curious, > > -Archie > > > > ___________________________________________________________________________ > > Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com > > > > ___________________________________________________________________________ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com From owner-freebsd-hackers Thu Nov 13 12:11:54 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id MAA15421 for hackers-outgoing; Thu, 13 Nov 1997 12:11:54 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from super-g.inch.com (super-g.com [207.240.140.161]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id MAA15401 for ; Thu, 13 Nov 1997 12:11:47 -0800 (PST) (envelope-from spork@super-g.com) Received: from localhost (localhost [127.0.0.1]) by super-g.inch.com (8.8.7/8.8.5) with SMTP id PAA19010; Thu, 13 Nov 1997 15:06:53 -0500 (EST) Date: Thu, 13 Nov 1997 15:06:53 -0500 (EST) From: spork X-Sender: spork@super-g.inch.com To: "David E. Cross" cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Pentium Bug Fix... In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > I would be interested in seeing the alledged Linux 'fix'. Here ya go: Date: Wed, 12 Nov 1997 18:45:15 -0600 From: Aleph One To: BUGTRAQ@NETSPACE.ORG Subject: Linux F00F Patch This are the relevant parts of the linux kernel 2.1.63 patch that fix the Pentium bug that Alan mentioned. Aleph One / aleph1@dfw.net http://underground.org/ KeyID 1024/948FD6B5 Fingerprint EE C9 E8 AA CB AF 09 61 8C 39 EA 47 A8 6A B8 01 diff -u --recursive --new-file v2.1.62/linux/arch/i386/kernel/setup.c linux/arch/i386/kernel/setup.c --- v2.1.62/linux/arch/i386/kernel/setup.c Tue Sep 23 16:48:46 1997 +++ linux/arch/i386/kernel/setup.c Wed Nov 12 11:09:56 1997 @@ -42,6 +42,7 @@ char x86_mask = 0; /* set by kernel/head.S */ int x86_capability = 0; /* set by kernel/head.S */ int fdiv_bug = 0; /* set if Pentium(TM) with FP bug */ +int pentium_f00f_bug = 0; /* set if Pentium(TM) with F00F bug */ int have_cpuid = 0; /* set if CPUID instruction works */ char x86_vendor_id[13] = "unknown"; @@ -359,6 +360,7 @@ "fdiv_bug\t: %s\n" "hlt_bug\t\t: %s\n" "sep_bug\t\t: %s\n" + "pentium_f00f_bug\t\t: %s\n" "fpu\t\t: %s\n" "fpu_exception\t: %s\n" "cpuid\t\t: %s\n" @@ -367,6 +369,7 @@ CD(fdiv_bug) ? "yes" : "no", CD(hlt_works_ok) ? "no" : "yes", sep_bug ? "yes" : "no", + pentium_f00f_bug ? "yes" : "no", CD(hard_math) ? "yes" : "no", (CD(hard_math) && ignore_irq13) ? "yes" : "no", diff -u --recursive --new-file v2.1.62/linux/arch/i386/kernel/traps.c linux/arch/i386/kernel/traps.c --- v2.1.62/linux/arch/i386/kernel/traps.c Sun Sep 7 13:10:42 1997 +++ linux/arch/i386/kernel/traps.c Wed Nov 12 11:09:56 1997 @@ -413,6 +413,51 @@ #endif /* CONFIG_MATH_EMULATION */ +static struct +{ + short limit __attribute__((packed)); + void * addr __attribute__((packed)); + short __pad __attribute__((packed)); +} idt_d; + +void * idt2; + +__initfunc(void trap_init_f00f_bug(void)) +{ + pgd_t * pgd; + pmd_t * pmd; + pte_t * pte; + unsigned long twopage; + + printk("moving IDT ... "); + + twopage = (unsigned long) vmalloc (2*PAGE_SIZE); + + idt2 = (void *)(twopage + 4096-7*8); + + memcpy(idt2,&idt,sizeof(idt)); + + idt_d.limit = 256*8-1; + idt_d.addr = idt2; + idt_d.__pad = 0; + + __asm__ __volatile__("\tlidt %0": "=m" (idt_d)); + + /* + * Unmap lower page: + */ + pgd = pgd_offset(current->mm, twopage); + pmd = pmd_offset(pgd, twopage); + pte = pte_offset(pmd, twopage); + + pte_clear(pte); + flush_tlb_all(); + + printk(" ... done\n"); +} + + + __initfunc(void trap_init(void)) { int i; diff -u --recursive --new-file v2.1.62/linux/arch/i386/mm/fault.c linux/arch/i386/mm/fault.c --- v2.1.62/linux/arch/i386/mm/fault.c Wed Oct 15 16:04:23 1997 +++ linux/arch/i386/mm/fault.c Wed Nov 12 11:09:55 1997 @@ -74,6 +74,25 @@ return 0; } +asmlinkage void divide_error(void); +asmlinkage void debug(void); +asmlinkage void nmi(void); +asmlinkage void int3(void); +asmlinkage void overflow(void); +asmlinkage void bounds(void); +asmlinkage void invalid_op(void); + +asmlinkage void do_divide_error (struct pt_regs *, unsigned long); +asmlinkage void do_debug (struct pt_regs *, unsigned long); +asmlinkage void do_nmi (struct pt_regs *, unsigned long); +asmlinkage void do_int3 (struct pt_regs *, unsigned long); +asmlinkage void do_overflow (struct pt_regs *, unsigned long); +asmlinkage void do_bounds (struct pt_regs *, unsigned long); +asmlinkage void do_invalid_op (struct pt_regs *, unsigned long); + +extern int * idt2; +extern int pentium_f00f_bug; + /* * This routine handles page faults. It determines the address, * and the problem, and then passes it off to one of the appropriate @@ -170,6 +189,46 @@ goto out; } + printk("<%p/%p>\n", idt2, (void *)address); + /* + * Pentium F0 0F C7 C8 bug workaround: + */ + if ( pentium_f00f_bug && (address >= (unsigned long)idt2) && + (address < (unsigned long)idt2+256*8) ) { + + void (*handler) (void); + int nr = (address-(unsigned long)idt2)/8; + unsigned long low, high; + + low = idt[nr].a; + high = idt[nr].b; + + handler = (void (*) (void)) ((low&0x0000ffff) | (high&0xffff0000)); + printk("\n"); + goto out; + } + /* Are we prepared to handle this kernel fault? */ if ((fixup = search_exception_table(regs->eip)) != 0) { printk(KERN_DEBUG "%s: Exception at [<%lx>] cr2=%lx (fixup: %lx)\n", @@ -193,6 +252,7 @@ flush_tlb(); goto out; } + if (address < PAGE_SIZE) printk(KERN_ALERT "Unable to handle kernel NULL pointer dereference"); else diff -u --recursive --new-file v2.1.62/linux/include/asm-i386/bugs.h linux/include/asm-i386/bugs.h --- v2.1.62/linux/include/asm-i386/bugs.h Thu Sep 11 09:02:24 1997 +++ linux/include/asm-i386/bugs.h Wed Nov 12 11:09:55 1997 @@ -166,6 +166,32 @@ } } +/* + * All current models of Pentium and Pentium with MMX technology CPUs + * have the F0 0F bug, which lets nonpriviledged users lock up the system: + */ + +extern int pentium_f00f_bug; + +__initfunc(static void check_pentium_f00f(void)) +{ + /* + * Pentium and Pentium MMX + */ + printk("checking for F00F bug ..."); + if(x86==5 && !memcmp(x86_vendor_id, "GenuineIntel", 12)) + { + extern void trap_init_f00f_bug(void); + + printk(KERN_INFO "\nIntel Pentium/[MMX] F0 0F bug detected - turning on workaround.\n"); + pentium_f00f_bug = 1; + trap_init_f00f_bug(); + } else { + printk(KERN_INFO " no F0 0F bug in this CPU, great!\n"); + pentium_f00f_bug = 0; + } +} + __initfunc(static void check_bugs(void)) { check_tlb(); @@ -173,5 +199,6 @@ check_hlt(); check_popad(); check_amd_k6(); + check_pentium_f00f(); system_utsname.machine[1] = '0' + x86; } From owner-freebsd-hackers Thu Nov 13 12:31:19 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id MAA17242 for hackers-outgoing; Thu, 13 Nov 1997 12:31:19 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from kithrup.com (kithrup.com [205.179.156.40]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id MAA17224 for ; Thu, 13 Nov 1997 12:31:14 -0800 (PST) (envelope-from sef@kithrup.com) Received: (from sef@localhost) by kithrup.com (8.8.7/8.8.7) id MAA16638; Thu, 13 Nov 1997 12:30:43 -0800 (PST) (envelope-from sef) Date: Thu, 13 Nov 1997 12:30:43 -0800 (PST) From: Sean Eric Fagan Message-Id: <199711132030.MAA16638@kithrup.com> To: hackers@freebsd.org Reply-To: hackers@freebsd.org In-Reply-To: References: Organization: Kithrup Enterprises, Ltd. Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >I would be interested in seeing the alledged Linux 'fix'. But not interested enough to read the other messages in the thread, or do a simple scan of comp.os.linux.announce to see if it cropped up there? (Which it did, in fact, yesterday.) I grabbed the patch, and looked at what it did. It's fairly straightforward -- it takes the interrupt descriptor table (IDT), and moves it into a new location, starting at 7 entries below the page boundary. That is (bah, where's Terry's line-art drawing program when you need it?): idt entry 0 idt entry 1 idt entry 2 idt entry 3 idt entry 4 idt entry 5 idt entry 6 <-- just before end of 4096-byte page idt entry 7 <-- at begining of 4096-byte boundary idt entry 8 ... It sets the IDT register to point to 'idt entry 0' (using the "lidt" instruction; we have a function in locore.s that does that). Then, it removes the mapping for that page -- it leaves the mapping for the one containing 'idt entry 7', though. (This is important, because the page fault entry needs to be mapped, for somewhat obvious reasons ;).) Those vectors are for: divide, debug, nmi, breakpoint, overflow, bounds check, illegal instruction, and then device not available is in the page that stays mapped. The illegal instruction is the important one -- that is the one that will cause a page fault when lock cmpxchg8b %eax is executed, if the page is unmapped. (If it is mapped, of course, then the processor locks up if it is a Pentium.) Then, in the kernel's page fault handler, it examines the address that caused the fault (register %rc2); if the address was in the range of the unmapped IDT entries, the handler then dispatches the correct function; otherwise, it continues as normal. The BSDi fix appears to do the same thing, although I think they may have done it slightly wrong. Also, I've seen one report from someone that a 75MHz Pentium still hangs, under Linux with the patch. I haven't seen any confirmations for that, though. The performance impact of this, under linux at least, is minimal -- of the unmapped vectors, only overflow and bounds check are likely to be used by a real program in a time-critical way; page faults will take a slight hit -- three comparisons, two loads, an add, and a couple of branches as part of the if statement. I have been trying to get this working in FreeBSD since last night; right now, I'm not sure why what is happening is happening. But I'm giving up -- I've had it "explained" to me by Jordan that even if I got it working, it would not be considered, because this is simply not anything that anyone needs to worry about. (Even though I do know someone whose machine has been crashed four times since Friday by this. But since he's running SCOnix instead of FreeBSd, he doesn't count -- never mind the fact that, even if he were running FreeBSD, he'd be affected.) So all you people who are worried -- either switch to a different processor (the Cyrix chips should do fine, as should the IDT WinCPU or whatever they call it), or switch to Linux or an SCO OS. Or wait until Intel deigns to say what the official workaround is, and then wait however long it takes David Greenman to come up with an implementation that he thinks is aesthetically pleasing to him. (I am desperately hoping that he already has an implmentation, but just isn't releasing it, so that any delay after Intel decides that we're all worthy can be minimized. But if he has, he hasn't told anyone -- probably a smart thing, since he'd be flooded with requests, probably.) (And, yes, I find Jordan's attitude that nobody should care, since there are other things that can be done to destroy a system, offensive. Just as offensive as Intel's official suggestion that you can always reboot your system.) From owner-freebsd-hackers Thu Nov 13 13:03:48 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id NAA20675 for hackers-outgoing; Thu, 13 Nov 1997 13:03:48 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from whistle.com (s205m131.whistle.com [207.76.205.131]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id NAA20664 for ; Thu, 13 Nov 1997 13:03:40 -0800 (PST) (envelope-from archie@whistle.com) Received: (from smap@localhost) by whistle.com (8.7.5/8.6.12) id NAA14850; Thu, 13 Nov 1997 13:03:07 -0800 (PST) Received: from bubba.whistle.com(207.76.205.7) by whistle.com via smap (V1.3) id sma014846; Thu Nov 13 13:03:01 1997 Received: (from archie@localhost) by bubba.whistle.com (8.8.5/8.6.12) id NAA27953; Thu, 13 Nov 1997 13:03:01 -0800 (PST) From: Archie Cobbs Message-Id: <199711132103.NAA27953@bubba.whistle.com> Subject: Re: unkillable process In-Reply-To: <19971113154657.06089@milkyway.com> from Brian Campbell at "Nov 13, 97 03:46:57 pm" To: brianc@milkyway.com (Brian Campbell) Date: Thu, 13 Nov 1997 13:03:01 -0800 (PST) Cc: hackers@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-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Brian Campbell writes: > On Thu, Nov 13, 1997 at 10:48:17AM -0800, Archie Cobbs wrote: > > Simon Shapiro writes: > > > Hi Archie Cobbs; On 12-Nov-97 you wrote: > > > > 1. Create a named pipe > > > > 2. Start typing into it using cat > > > > 3. Hit control-C as many times as you want > > > > > > > > You'll see that the process will not die even with kill -9, > > > > as it is stuck in uninterrupible disk sleep ("fifo"). > > > > > > > > But as soon as you read from the other end of the pipe, > > > > the process exits. > > > > > > > > Is there a missing PCATCH flag to tsleep() somewhere? > > > > Is this appropriate behavior? (hint: rhetorical question) > > > > > > From what I remember, this is a typical (if ugly Unix behavior. > > > > Hmm... does anyone else besides me have the opinion that, > > while it may be typical, this behavior is also *broken*? > > I don't think my 2.2.5 system behaves as you describe. > > `mkfifo p; cat >p` followed by ^C complains about not being able to > create p. It does, however, interrupt immediately. If you type some > stuff before hitting ^C, cat still hasn't managed to open the fifo > (same complaint) but the command is still immediately interrupted. > > If you use `cat <>p` (to open the fifo read-write so the open doesn't > have to wait for a reader), the open will succeed and you can write > some data that will be readable by another process, unless you > interrupt it in which case the command immediately exits and the data > is lost. > > Perhaps you're seeing some funny behaviour due to your shell? You're right.. it must be a tcsh(1) problem... the following command hangs in tcsh but not sh: $ mkfifo p; cat > p ^C But it's still a kernel bug, no? The tcsh process is stuck in some kind of uninterruptible sleep, which is not appropriate here: UID PID PPID CPU PRI NI VSZ RSS WCHAN STAT TT TIME COMMAND 0 4042 4041 0 10 0 612 868 ppwait Ds p2 0:01.09 -tcsh (tcsh) 0 4177 4042 0 2 0 612 888 fifo SV+ p2 0:00.01 -tcsh (tcsh) I can kill the second process (pid 4177) but not the first (pid 4042), even with kill -9. -Archie P.S. How do you annotate a previously sent bug report? :-) ___________________________________________________________________________ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com From owner-freebsd-hackers Thu Nov 13 13:05:01 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id NAA20863 for hackers-outgoing; Thu, 13 Nov 1997 13:05:01 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from ns.mt.sri.com (SRI-56K-FR.mt.net [206.127.65.42]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id NAA20846 for ; Thu, 13 Nov 1997 13:04:52 -0800 (PST) (envelope-from nate@rocky.mt.sri.com) Received: from rocky.mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.8.8/8.8.8) with ESMTP id OAA21385; Thu, 13 Nov 1997 14:04:49 -0700 (MST) (envelope-from nate@rocky.mt.sri.com) Received: (from nate@localhost) by rocky.mt.sri.com (8.7.5/8.7.3) id OAA10484; Thu, 13 Nov 1997 14:04:47 -0700 (MST) Date: Thu, 13 Nov 1997 14:04:47 -0700 (MST) Message-Id: <199711132104.OAA10484@rocky.mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Julian Elischer Cc: hackers@freebsd.org Subject: Re: SUID-Directories patch In-Reply-To: <346B4942.15FB7483@whistle.com> References: <346B4942.15FB7483@whistle.com> X-Mailer: VM 6.29 under 19.15 XEmacs Lucid Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > I really need it n 2.2 rather than 3.0 so I'd like to merge it in from > -current later thes afternoon if I don't hear any objections. No way. It needs some time to 'cook' awhile in 3.0 before it goes into current. This code greatly affects the entire system, and it hasn't had hardly any time to be reviewed/tested in -current. Nate From owner-freebsd-hackers Thu Nov 13 13:05:25 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id NAA20914 for hackers-outgoing; Thu, 13 Nov 1997 13:05:25 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from nomis.i-connect.net (nomis.i-Connect.Net [206.190.143.100] (may be forged)) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id NAA20854 for ; Thu, 13 Nov 1997 13:04:57 -0800 (PST) (envelope-from shimon@i-connect.net) Received: (qmail 24940 invoked by uid 1000); 13 Nov 1997 21:04:10 -0000 Message-ID: X-Mailer: XFMail 1.2-beta-111097 [p0] on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit MIME-Version: 1.0 In-Reply-To: <199711132000.MAA26869@bubba.whistle.com> Date: Thu, 13 Nov 1997 13:04:09 -0800 (PST) Organization: Atlas Telecom From: Simon Shapiro To: Archie Cobbs Subject: Re: unkillable process Cc: freebsd-hackers@FreeBSD.ORG, (Alfred Perlstein) Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hi Archie Cobbs; On 13-Nov-97 you wrote: > > Alfred Perlstein writes: > > From what i understand the process 'cat' is not broken, the shell > > excuting > > the command will terminate if issued a 'kill -9' > > Not on my machine... kill -9 does nothing (see original email). Yup. This is how it is written. Why it is written this way, I dunno. I cannot come up with a good reason. > > -Archie > > > ._______________________________________________________________________ > > _ __ _ > > |Alfred Perlstein - Programming & SysAdmin --"Have you seen my FreeBSD > > |tatoo?" > > |perlsta@sunyit.edu --"who was that masked > > |admin?" > > |http://www.cs.sunyit.edu/~perlsta > > : > > ' > > > > On Thu, 13 Nov 1997, Archie Cobbs wrote: > > > > > Simon Shapiro writes: > > > > Hi Archie Cobbs; On 12-Nov-97 you wrote: > > > > > Try the following experiment (on 2.2 and mabye 3.0): > > > > > > > > > > 1. Create a named pipe > > > > > 2. Start typing into it using cat > > > > > 3. Hit control-C as many times as you want > > > > > > > > > > You'll see that the process will not die even with kill -9, > > > > > as it is stuck in uninterrupible disk sleep ("fifo"). > > > > > > > > > > But as soon as you read from the other end of the pipe, > > > > > the process exits. > > > > > > > > > > Is there a missing PCATCH flag to tsleep() somewhere? > > > > > Is this appropriate behavior? (hint: rhetorical question) > > > > > > > > From what I remember, this is a typical (if ugly Unix behavior. > > > > > > Hmm... does anyone else besides me have the opinion that, > > > while it may be typical, this behavior is also *broken*? > > > > > > Still Curious, > > > -Archie > > > > > > ______________________________________________________________________ > > > _____ > > > Archie Cobbs * Whistle Communications, Inc. * > > > http://www.whistle.com > > > > > > > > > _________________________________________________________________________ > __ > Archie Cobbs * Whistle Communications, Inc. * > http://www.whistle.com --- If Microsoft Built Cars: Every time they repainted the lines on the road, you'd have to buy a new car. Sincerely Yours, Simon Shapiro Atlas Telecom Senior Architect 14355 SW Allen Blvd., Suite 130 Beaverton OR 97005 Shimon@i-Connect.Net Voice: 503.799.2313 From owner-freebsd-hackers Thu Nov 13 13:34:47 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id NAA23170 for hackers-outgoing; Thu, 13 Nov 1997 13:34:47 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from sos.freebsd.dk (sos.freebsd.dk [195.8.129.33]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id NAA23160 for ; Thu, 13 Nov 1997 13:34:40 -0800 (PST) (envelope-from sos@sos.freebsd.dk) Received: (from sos@localhost) by sos.freebsd.dk (8.8.8/8.7.3) id WAA00279; Thu, 13 Nov 1997 22:35:29 +0100 (MET) Message-Id: <199711132135.WAA00279@sos.freebsd.dk> Subject: Re: SUID-Directories patch In-Reply-To: <346B4942.15FB7483@whistle.com> from Julian Elischer at "Nov 13, 97 10:38:59 am" To: julian@whistle.com (Julian Elischer) Date: Thu, 13 Nov 1997 22:35:28 +0100 (MET) Cc: hackers@FreeBSD.ORG From: Søren Schmidt Reply-to: sos@FreeBSD.dk X-Mailer: ELM [version 2.4ME+ PL30 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk In reply to Julian Elischer who wrote: > I'd like to move this to 2.2.x > > It is all hidden behind #ifdef SUIDDIR > so I can guarantee that it won't BREAK anything. > > I really need it n 2.2 rather than 3.0 so I'd like to merge it in from > -current later thes afternoon if I don't hear any objections. Objection. If you need this for Whistle, you should keep it in your own tree, its does NOT belong in the generic FreeBSD tree. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Søren Schmidt (sos@FreeBSD.org) FreeBSD Core Team Even more code to hack -- will it ever end .. From owner-freebsd-hackers Thu Nov 13 13:35:34 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id NAA23264 for hackers-outgoing; Thu, 13 Nov 1997 13:35:34 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from email.gcn.net.tw (email.gcn.net.tw [203.77.2.139]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id NAA23256 for ; Thu, 13 Nov 1997 13:35:29 -0800 (PST) (envelope-from keith@email.gcn.net.tw) Received: from darthvader.keith.tw (dial88.203708.gcn.net.tw [203.70.8.88]) by email.gcn.net.tw (8.8.8/8.8.8) with SMTP id VAA31338 for ; Thu, 13 Nov 1997 21:38:12 GMT Message-ID: <346B729B.167EB0E7@email.gcn.net.tw> Date: Fri, 14 Nov 1997 05:35:23 +0800 From: Keith Jang X-Mailer: Mozilla 3.01Gold (X11; I; FreeBSD 3.0-CURRENT i386) MIME-Version: 1.0 To: hackers@freebsd.org Subject: Where to commit patches? [MS Joliet Ext. to CD9660] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I've added some code to the existing CD9660 part, to let it recognize MS Joliet CD and the long filenames on it. I would like to commit it, of course. The handbook says that I should post the patches here. But I read this mailing list for some time, and seems it's not the right place. Can anyone tell me where the patches should be sent? Thanks. From owner-freebsd-hackers Thu Nov 13 13:46:41 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id NAA24106 for hackers-outgoing; Thu, 13 Nov 1997 13:46:41 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from heron.doc.ic.ac.uk (rAgXTqqLR1NctZao4N5+0hSnL5yRokvn@heron.doc.ic.ac.uk [146.169.43.9]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id NAA24100 for ; Thu, 13 Nov 1997 13:46:35 -0800 (PST) (envelope-from njs3@doc.ic.ac.uk) Received: from ash3.doc.ic.ac.uk [146.169.16.31] ([jU7dkYhn+fc4wXTaAyplmO/h6G42WOwm]) by heron.doc.ic.ac.uk with smtp (Exim 1.62 #3) id 0xW774-0005ZY-00; Thu, 13 Nov 1997 21:47:46 +0000 Received: from njs3 by ash3.doc.ic.ac.uk with local (Exim 1.62 #1) id 0xW75o-00013t-00; Thu, 13 Nov 1997 21:46:28 +0000 From: njs3@doc.ic.ac.uk (Niall Smart) Date: Thu, 13 Nov 1997 21:46:28 +0000 X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: hackers@freebsd.org Subject: Intel Pentium bugfix for FreeBSD Message-Id: Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi, Someone recently suggested here (I would quote them if I hadn't inadvertantly typed "delete" then "update") that the workaround for intels latest bug may not be integrated into FreeBSD because if you wanted to crash a machine, you can do it regardless. However, most other methods for crashing a machine that I can think of require a pretty concerted effort to exhaust system resources, and are therefore relatively easily traceable. The F00F bug however, is untraceable, and therefore I feel that it should be integrated into the source tree. A kernel configuration option to turn it on/off might be useful if it has a performance impact. Or then again, maybe you should go and get a new CPU from Intel. :) Hmm there's a thought - I wonder if you would have to give the old one back, if not .. SMP here I come! Niall From owner-freebsd-hackers Thu Nov 13 13:48:19 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id NAA24381 for hackers-outgoing; Thu, 13 Nov 1997 13:48:19 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from nomis.i-connect.net (nomis.i-Connect.Net [206.190.143.100] (may be forged)) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id NAA24365 for ; Thu, 13 Nov 1997 13:48:12 -0800 (PST) (envelope-from shimon@i-connect.net) Received: (qmail 1078 invoked by uid 1000); 13 Nov 1997 21:48:31 -0000 Message-ID: X-Mailer: XFMail 1.2-beta-111097 [p0] on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <346d4ceb.8671504@smtp-gw01.ny.us.ibm.net> Date: Thu, 13 Nov 1997 13:48:31 -0800 (PST) Organization: Atlas Telecom From: Simon Shapiro To: (John Kelly) Subject: Re: Status of 650 UART support Cc: hackers@FreeBSD.ORG, Bruce Evans Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hi John Kelly; On 13-Nov-97 you wrote: > On Thu, 13 Nov 1997 20:35:53 +1100, Bruce Evans > wrote: > > >>Why can't we handle large bursts of input? > > > >Buffer sizes are finite. > > Can't we use malloc to create elastic buffers on the fly? Is that a > no-no in the kernel? > > >Multiply some of these numbers by 4 for 64-bit fifos and you have > >seriously high (normal worst case) latencies. (My definition of > >``high'' > >is anything that would stop an 8250 from working at 115200 bps - 87 > >usec :-). I will reduce this when faster speeds become common.) > > Why not start from scratch and develop siov2.c which uses elastic > buffers, 650 polled vs. interrupt mode switching, yada, yada, yada. > Sio.c could still be the default while siov2.c could be selected on a > port by port basis with a kernel config flag. > > Now if someone foolhardy enough to undertake such a project would step > forward (don't look in my direction, I know better). ;-) a. Define ALL the entry points into the driver b. Gather the documentation for all UARTs you want to work b. Send to Simon If the answer to a. or b. is ``read the code'' then do not do c. :-) --- If Microsoft Built Cars: Every time they repainted the lines on the road, you'd have to buy a new car. Sincerely Yours, Simon Shapiro Atlas Telecom Senior Architect 14355 SW Allen Blvd., Suite 130 Beaverton OR 97005 Shimon@i-Connect.Net Voice: 503.799.2313 From owner-freebsd-hackers Thu Nov 13 14:01:24 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id OAA25917 for hackers-outgoing; Thu, 13 Nov 1997 14:01:24 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id OAA25904 for ; Thu, 13 Nov 1997 14:01:18 -0800 (PST) (envelope-from julian@whistle.com) Received: (from daemon@localhost) by alpo.whistle.com (8.8.5/8.8.5) id NAA19493; Thu, 13 Nov 1997 13:52:44 -0800 (PST) Received: from UNKNOWN(), claiming to be "current1.whistle.com" via SMTP by alpo.whistle.com, id smtpd019486; Thu Nov 13 13:52:36 1997 Message-ID: <346B762F.41C67EA6@whistle.com> Date: Thu, 13 Nov 1997 13:50:39 -0800 From: Julian Elischer Organization: Whistle Communications X-Mailer: Mozilla 3.0Gold (X11; I; FreeBSD 2.2-CURRENT i386) MIME-Version: 1.0 To: "Chuck O'Donnell" CC: freebsd-hackers@FreeBSD.ORG Subject: Re: /dev/speaker References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Chuck O'Donnell wrote: > > Does anyone know a good way to beep the speaker from a CGI script? > > I found the 'pseudo-device speaker' in /sys/i386/conf/LINT, which uses the > spkr.c driver to gain access through open("/dev/speaker", ...). > > Are there any other ways to access the computer speaker directly? > > I am not subscribed to this list so please send responses directly. > > Thank you. > > Chuck O'Donnell define what you mean by "access the computer speaker directly" the speaker is physically attached to the counter-timer chip. you can program the counter to toggle the speaker at a known speed, for a known period of time. or pulse once with a known pulse length. That's about all. of course htere are other tricks that can be achieved using this.. the pca device for example uses a high frequency (16kHz) carrier which it modulates using PWM to produce a reasonable audio output. From owner-freebsd-hackers Thu Nov 13 14:11:26 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id OAA26613 for hackers-outgoing; Thu, 13 Nov 1997 14:11:26 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from kithrup.com (kithrup.com [205.179.156.40]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id OAA26607; Thu, 13 Nov 1997 14:11:16 -0800 (PST) (envelope-from sef@kithrup.com) Received: (from sef@localhost) by kithrup.com (8.8.7/8.8.7) id OAA25835; Thu, 13 Nov 1997 14:11:15 -0800 (PST) (envelope-from sef) Date: Thu, 13 Nov 1997 14:11:15 -0800 (PST) From: Sean Eric Fagan Message-Id: <199711132211.OAA25835@kithrup.com> To: hackers@freebsd.org Subject: I would like to apologise Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk To both Jordan and David... My last message (the one with the embarassing lack of subject, *blush*) was a bit heated. I do not like the lack of a workaround for FreeBSD, and I do not like waiting until Intel decides to release information about it. But, really, I don't like Intel either, so, go figger ;). I obviously do not agree with Jordan's attitude about this... but I do understand his position. (Barely, though, I have to admit that.) And I don't doubt that either of them is doing what they think is right and best for the freebsd users. And, no, nobody yelled at me or threatened me about my message. :) Sean. From owner-freebsd-hackers Thu Nov 13 14:26:45 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id OAA27480 for hackers-outgoing; Thu, 13 Nov 1997 14:26:45 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from ghost.mep.ruhr-uni-bochum.de (ghost.mep.ruhr-uni-bochum.de [134.147.6.33]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id OAA27472 for ; Thu, 13 Nov 1997 14:26:40 -0800 (PST) (envelope-from roberte@ghost.mep.ruhr-uni-bochum.de) Received: (from roberte@localhost) by ghost.mep.ruhr-uni-bochum.de (8.8.5/8.8.4) id XAA01539; Thu, 13 Nov 1997 23:25:43 +0100 (MEZ) From: Robert Eckardt Message-Id: <199711132225.XAA01539@ghost.mep.ruhr-uni-bochum.de> Subject: Re: unkillable process In-Reply-To: <199711131848.KAA19595@bubba.whistle.com> from Archie Cobbs at "Nov 13, 97 10:48:17 am" To: archie@whistle.com (Archie Cobbs) Date: Thu, 13 Nov 1997 23:25:43 +0100 (MEZ) Cc: Shimon@i-connect.net, freebsd-hackers@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-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk It was Archie Cobbs who wrote: > Simon Shapiro writes: > > Hi Archie Cobbs; On 12-Nov-97 you wrote: > > > Try the following experiment (on 2.2 and mabye 3.0): > > > > > > 1. Create a named pipe > > > 2. Start typing into it using cat > > > 3. Hit control-C as many times as you want > > > > > > You'll see that the process will not die even with kill -9, > > > as it is stuck in uninterrupible disk sleep ("fifo"). I tried with `cat'. 23:16 ghost: /home/re 0% mkfifo p 23:16 ghost: /home/re 0% /bin/cat - > p sdjksdfjk lksjflsfjkd ^C^C^?^? ^Z^Z^Z Beendet 23:17 ghost: /home/re 143% 23:17 ghost: /home/re 143% I didn't find `cat' in the process list, though I used the tcsh-external program in /bin. However, `ps -auxlw' showed: roberte 1524 0.0 1.3 696 784 p4 IV+ 11:16pm 0:00.00 -csh (tcsh) 100 1524 307 0 2 0 696 784 fifo IV+ p4 0:00.00 -csh (tcsh) After a simple `kill 1524' the above cat returned (`Beendet'). This is on 2.2.2-RELEASE. > Hmm... does anyone else besides me have the opinion that, > while it may be typical, this behavior is also *broken*? If at least `kill -9' doesn't/didn't work, I would definitely call it an error (since it may cause e.g. an uncleanly umounted filesystem). > Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com Robert -- Robert Eckardt \\ FreeBSD -- solutions for a large universe.(tm) RobertE@MEP.Ruhr-Uni-Bochum.de \\ What do you want to boot tomorrow ?(tm) http://WWW.MEP.Ruhr-Uni-Bochum.de/~roberte For PGP-key finger roberte@gluon.MEP.Ruhr-Uni-Bochum.de From owner-freebsd-hackers Thu Nov 13 14:34:42 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id OAA28035 for hackers-outgoing; Thu, 13 Nov 1997 14:34:42 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id OAA28029 for ; Thu, 13 Nov 1997 14:34:37 -0800 (PST) (envelope-from julian@whistle.com) Received: (from daemon@localhost) by alpo.whistle.com (8.8.5/8.8.5) id OAA20848; Thu, 13 Nov 1997 14:22:03 -0800 (PST) Received: from UNKNOWN(), claiming to be "current1.whistle.com" via SMTP by alpo.whistle.com, id smtpd020843; Thu Nov 13 14:21:55 1997 Message-ID: <346B7D0F.446B9B3D@whistle.com> Date: Thu, 13 Nov 1997 14:19:59 -0800 From: Julian Elischer Organization: Whistle Communications X-Mailer: Mozilla 3.0Gold (X11; I; FreeBSD 2.2-CURRENT i386) MIME-Version: 1.0 To: sos@FreeBSD.dk CC: hackers@FreeBSD.ORG Subject: Re: SUID-Directories patch References: <199711132135.WAA00279@sos.freebsd.dk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk S?ren Schmidt wrote: > > In reply to Julian Elischer who wrote: > > I'd like to move this to 2.2.x > > > > It is all hidden behind #ifdef SUIDDIR > > so I can guarantee that it won't BREAK anything. > > > > I really need it in 2.2 rather than 3.0 so I'd like to merge it in from > > -current later thes afternoon if I don't hear any objections. > > Objection. If you need this for Whistle, you should keep it in your > own tree, its does NOT belong in the generic FreeBSD tree. > I asked if people thought it would be useful.. I got 20 replies saying that YES it would be useful, so I've added it to -current. It's #ifdef'ed out as it is. You need to specifically compile it in to make use of it. Most people I know who are running company file servers for this sort of thing are running 2.2.x rather than 3.0, so making it only available in 3.0 doesn't help them. We are running it here on 2.2 on N machines (where N is a large number) so the 2.2 patches are much more tested than the 3.0 version. I have a 2.2 set of patches that are tested and known to work sitting in my freebsd CVS-d tree waiting for the words "cvs commit" but I haven't said them. but as I said. they are bracketted in #ifdef SUIDDIR #endif so without the change there are 0 bytes of binary change in the kernel. The risk is minimal. When we started the -stable/-current split, the requirement for adding code to -stabe branches was: 1/ "Not breaking any existing features/interfaces" [this is a NEW feature] 2/ "Must be tested" [how many 0s do I need to put on the number of machines running this before it's 'tested'?] If it's not in 2.2 it can't be tested in 2.2,and We've tested it as much as we can in our application it's time for wider distribution.. what I'm asking is: "Can I check in some code that is presently #ifdef'd out" is this such a risk? the request to do this came from the Samba developers as a way to make things work the way that PC usesrs expect. We did so for them because their product is integral to ours. I don't know if they will be getting the same changes into Linux but it wouldn't surprise me. From owner-freebsd-hackers Thu Nov 13 14:37:20 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id OAA28302 for hackers-outgoing; Thu, 13 Nov 1997 14:37:20 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from dns (dns.ida.net [204.228.203.1]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id OAA28293 for ; Thu, 13 Nov 1997 14:37:16 -0800 (PST) (envelope-from cmott@srv.net) Received: from darkstar.home (dialin1.anlw.anl.gov [141.221.254.101]) by dns (SMI-8.6/mail.byaddr) with SMTP id PAA01779 for ; Thu, 13 Nov 1997 15:32:00 -0700 Date: Thu, 13 Nov 1997 15:37:08 -0700 (MST) From: Charles Mott X-Sender: cmott@darkstar.home Reply-To: Charles Mott To: hackers@FreeBSD.ORG Subject: Re: Sean Eric Fagin's posting In-Reply-To: <199711132030.MAA16638@kithrup.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk [Very informative summary by Sean nipped.] > (And, yes, I find Jordan's attitude that nobody should care, since there are > other things that can be done to destroy a system, offensive. Just as > offensive as Intel's official suggestion that you can always reboot your > system.) If you do write a kernel patch, you might make it available on the web to those who are interested. This is sometimes the best way to deal with things that are controversial. I don't think Jordan's attitude is really that offensive (although his mailing list persona is sort of grumpy). I am actually more interested that the operating system be made more solid in a general way rather than seeing people scrambling to deal with the crisis du jour. Charles Mott From owner-freebsd-hackers Thu Nov 13 14:40:27 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id OAA28610 for hackers-outgoing; Thu, 13 Nov 1997 14:40:27 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id OAA28604 for ; Thu, 13 Nov 1997 14:40:25 -0800 (PST) (envelope-from julian@whistle.com) Received: (from daemon@localhost) by alpo.whistle.com (8.8.5/8.8.5) id OAA21546; Thu, 13 Nov 1997 14:40:09 -0800 (PST) Received: from UNKNOWN(), claiming to be "current1.whistle.com" via SMTP by alpo.whistle.com, id smtpd021523; Thu Nov 13 14:40:00 1997 Message-ID: <346B814B.794BDF32@whistle.com> Date: Thu, 13 Nov 1997 14:38:03 -0800 From: Julian Elischer Organization: Whistle Communications X-Mailer: Mozilla 3.0Gold (X11; I; FreeBSD 2.2-CURRENT i386) MIME-Version: 1.0 To: Keith Jang CC: hackers@FreeBSD.ORG Subject: Re: Where to commit patches? [MS Joliet Ext. to CD9660] References: <346B729B.167EB0E7@email.gcn.net.tw> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Keith Jang wrote: > > I've added some code to the existing CD9660 part, to > let it recognize MS Joliet CD and the long filenames > on it. I would like to commit it, of course. The handbook > says that I should post the patches here. But I read > this mailing list for some time, and seems it's not > the right place. Can anyone tell me where the patches > should be sent? Thanks. use send-pr (try it.. it's on your BSD box) From owner-freebsd-hackers Thu Nov 13 14:48:27 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id OAA29331 for hackers-outgoing; Thu, 13 Nov 1997 14:48:27 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id OAA29314 for ; Thu, 13 Nov 1997 14:48:19 -0800 (PST) (envelope-from julian@whistle.com) Received: (from daemon@localhost) by alpo.whistle.com (8.8.5/8.8.5) id OAA21786; Thu, 13 Nov 1997 14:45:41 -0800 (PST) Received: from UNKNOWN(), claiming to be "current1.whistle.com" via SMTP by alpo.whistle.com, id smtpd021779; Thu Nov 13 14:45:33 1997 Message-ID: <346B8299.15FB7483@whistle.com> Date: Thu, 13 Nov 1997 14:43:37 -0800 From: Julian Elischer Organization: Whistle Communications X-Mailer: Mozilla 3.0Gold (X11; I; FreeBSD 2.2-CURRENT i386) MIME-Version: 1.0 To: hackers@FreeBSD.ORG CC: terry@whistle.com Subject: Re: References: <199711132030.MAA16638@kithrup.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk dinner? From owner-freebsd-hackers Thu Nov 13 14:52:13 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id OAA29671 for hackers-outgoing; Thu, 13 Nov 1997 14:52:13 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from fission (fission.dt.wdc.com [129.253.40.1]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id OAA29653 for ; Thu, 13 Nov 1997 14:52:05 -0800 (PST) (envelope-from kehlet@dt.wdc.com) Received: from cygnus.dt.wdc.com (root@[172.31.1.2]) by fission (8.7.1/8.7.1) with ESMTP id OAA13641 for ; Thu, 13 Nov 1997 14:51:58 -0800 (PST) Received: from mockingbird.dt.wdc.com (mockingbird [172.31.10.16]) by cygnus.dt.wdc.com (8.7.1/8.7.1) with ESMTP id OAA23959 for ; Thu, 13 Nov 1997 14:51:55 -0800 (PST) Received: from localhost (kehlet@localhost) by mockingbird.dt.wdc.com (8.8.5/8.8.5) with SMTP id OAA04038 for ; Thu, 13 Nov 1997 14:50:17 -0800 (PST) X-Authentication-Warning: mockingbird.dt.wdc.com: kehlet owned process doing -bs Date: Thu, 13 Nov 1997 14:50:17 -0800 (PST) From: Steven Kehlet Reply-To: Steven Kehlet To: hackers@freebsd.org Subject: diskless freebsd, can't mount local msdos disk Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I'm booting FreeBSD 2.2.5 diskless with the kernel's BOOTP features. It detects the local hardware just fine (e.g. ethernet (obviously), hard drive, floppy, etc), but if I try to mount the local msdos disk like I would on a non-diskless station, it doesn't work. Floppy operations (mounting, hexdumping, fdwriting) seem to work, however. Anyone know what's wrong, or have any suggestions what I could do? If I can give any more information, please let me know. wdc0 at 0x1f0-0x1f7 irq 14 on isa wdc0: unit 0 (wd0): wd0: 3098MB (6346368 sectors), 6296 cyls, 16 heads, 63 S/T, 512 B/S # foreach i (1 2 3 4) ? mount_msdos /dev/wd0s$i /mnt ? end mount_msdos: /dev/wd0s1: Invalid argument mount_msdos: /dev/wd0s2: Invalid argument mount_msdos: /dev/wd0s3: Invalid argument mount_msdos: /dev/wd0s4: Invalid argument # The msdos module loaded okay: mockingbird:/home/kehlet-> modstat Type Id Off Loadaddr Size Info Rev Module Name MISC 0 0 f43ea000 0008 f43eb000 1 blank_saver_mod VFS 1 4 f442f000 001c f4435090 1 msdos Weird, too, if I try to hexdump the raw disk, nothing comes up: # hd -v /dev/rwd0 |more # Thanks a ton, Steve Kehlet Here's some other info, just for fun: mockingbird:/home/kehlet-> uname -a FreeBSD mockingbird 2.2.5-RELEASE FreeBSD 2.2.5-RELEASE #0: Wed Nov 12 17:13:41 PST 1997 kehlet@daemon:/usr/src/sys.2.2.5/compile/DISKLESS i386 mockingbird:/home/kehlet-> dmesg Copyright (c) 1992-1997 FreeBSD Inc. Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. FreeBSD 2.2.5-RELEASE #0: Wed Nov 12 17:13:41 PST 1997 kehlet@daemon:/usr/src/sys.2.2.5/compile/DISKLESS CPU: Pentium (166.34-MHz 586-class CPU) Origin = "GenuineIntel" Id = 0x52c Stepping=12 Features=0x1bf real memory = 33554432 (32768K bytes) avail memory = 30560256 (29844K bytes) Probing for devices on PCI bus 0: chip0 rev 1 on pci0:0 chip1 rev 1 on pci0:7:0 pci0:7:1: Intel Corporation, device=0x7111, class=storage (ide) [no driver assigned] pci0:7:2: Intel Corporation, device=0x7112, class=0x0c, subclass=0x03 int d irq 11 [no driver assigned] chip2 rev 1 on pci0:7:3 vga0 rev 154 int a irq ?? on pci0:8 vx0 <3COM 3C905 Fast Etherlink XL PCI> rev 0 int a irq 5 on pci0:13 mii[*mii*]: disable 'auto select' with DOS util! address 00:60:08:32:cb:96 vga1 rev 1 int a irq 9 on pci0:14 Probing for devices on the ISA bus: sc0 at 0x60-0x6f irq 1 on motherboard sc0: VGA color <16 virtual consoles, flags=0x0> ed0 not found at 0x300 sio0 at 0x3f8-0x3ff irq 4 on isa sio0: type 16550A sio1 not found at 0x2f8 lpt0 at 0x378-0x37f irq 7 on isa lpt0: Interrupt-driven port lp0: TCP/IP capable interface psm0 at 0x60-0x64 irq 12 on motherboard psm0: device ID 0 fdc0 at 0x3f0-0x3f7 irq 6 drq 2 on isa fdc0: FIFO enabled, 8 bytes threshold fd0: 1.44MB 3.5in wdc0 at 0x1f0-0x1f7 irq 14 on isa wdc0: unit 0 (wd0): wd0: 3098MB (6346368 sectors), 6296 cyls, 16 heads, 63 S/T, 512 B/S ep0 not found at 0x300 npx0 on motherboard npx0: INT 16 interface bootpc_init: using network interface 'vx0' Bootpc testing starting bootpc hw address is 0:60:8:32:cb:96 My ip address is 172.31.10.16 Server ip address is 172.31.2.30 Gateway ip address is 0.0.0.0 Server name is bootes boot file is /kernel Subnet mask is 255.255.0.0 Router is 172.31.1.254 rootfs is 172.31.6.4:/diskless/FreeBSD/rootfs/mockingbird Hostname is mockingbird swapfs is 172.31.6.4:/diskless/FreeBSD/swapfs md_lookup_swap: Swap size is 32768 KB NFS SWAP: 172.31.6.4:/diskless/FreeBSD/swapfs NFS ROOT: 172.31.6.4:/diskless/FreeBSD/rootfs/mockingbird From owner-freebsd-hackers Thu Nov 13 15:33:16 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id PAA02897 for hackers-outgoing; Thu, 13 Nov 1997 15:33:16 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id PAA02887 for ; Thu, 13 Nov 1997 15:33:08 -0800 (PST) (envelope-from julian@whistle.com) Received: (from daemon@localhost) by alpo.whistle.com (8.8.5/8.8.5) id PAA23680; Thu, 13 Nov 1997 15:33:03 -0800 (PST) Received: from UNKNOWN(), claiming to be "current1.whistle.com" via SMTP by alpo.whistle.com, id smtpd023666; Thu Nov 13 15:32:56 1997 Message-ID: <346B8DB4.2781E494@whistle.com> Date: Thu, 13 Nov 1997 15:31:00 -0800 From: Julian Elischer Organization: Whistle Communications X-Mailer: Mozilla 3.0Gold (X11; I; FreeBSD 2.2-CURRENT i386) MIME-Version: 1.0 To: hackers@FreeBSD.ORG, terry@whistle.com Subject: Re: SF FBSD user's group pre-dinner References: <199711132030.MAA16638@kithrup.com> <346B8299.15FB7483@whistle.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Julian Elischer wrote: > > dinner? er, sorry. forgot about that CC line however of course anyone in the Bay Area is welcome to join us at the FreeBSD User's Group tonight. From owner-freebsd-hackers Thu Nov 13 15:35:56 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id PAA03158 for hackers-outgoing; Thu, 13 Nov 1997 15:35:56 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from ns.mt.sri.com (SRI-56K-FR.mt.net [206.127.65.42]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id PAA03129; Thu, 13 Nov 1997 15:35:49 -0800 (PST) (envelope-from nate@rocky.mt.sri.com) Received: from rocky.mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.8.8/8.8.8) with ESMTP id QAA22501; Thu, 13 Nov 1997 16:35:43 -0700 (MST) (envelope-from nate@rocky.mt.sri.com) Received: (from nate@localhost) by rocky.mt.sri.com (8.7.5/8.7.3) id QAA11405; Thu, 13 Nov 1997 16:35:41 -0700 (MST) Date: Thu, 13 Nov 1997 16:35:41 -0700 (MST) Message-Id: <199711132335.QAA11405@rocky.mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: hackers@freebsd.org CC: sef@kithrup.com, jkh@freebsd.org Subject: Re: Pentium lockup fix in FreeBSD In-Reply-To: <199711132030.MAA16638@kithrup.com> References: <199711132030.MAA16638@kithrup.com> X-Mailer: VM 6.29 under 19.15 XEmacs Lucid Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk .. > I have been trying to get this working in FreeBSD since last night; right > now, I'm not sure why what is happening is happening. But I'm giving up -- > I've had it "explained" to me by Jordan that even if I got it working, it > would not be considered, because this is simply not anything that anyone > needs to worry about. I think we need to give Jordan a big noogey if he indeed said that. For many people with shell machines, running 'crashable' in unacceptable, and if many of the other shell-account OS's allow them to workaround this bug (albeit with a performance hit, however major or minor) then they'll simply switch. Plus, as you pointed out to me in private email, any programs running as root that are network accessible that have the possibility of executing instructions (over-writing boundaries, etc..) are possible targets. In short, running any sort of public system on a P5 chip w/out the workaround is simply trouble waiting to happen, and if *we* as FreeBSD don't provide a fix and others do, we're screwing our customers. > (And, yes, I find Jordan's attitude that nobody should care, since there are > other things that can be done to destroy a system, offensive. Just as > offensive as Intel's official suggestion that you can always reboot your > system.) I disagree with Jordan as well. The crack/hack has been posted too widely across the internet so much that even curious folks who normally wouldn't do malicious things will end up crashing computers 'just to see if it works'. How many developers wiped out our boxes out of curiousity sakes because we didn't believe it could actually kill it? Nate From owner-freebsd-hackers Thu Nov 13 15:39:50 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id PAA03538 for hackers-outgoing; Thu, 13 Nov 1997 15:39:50 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from whistle.com (s205m131.whistle.com [207.76.205.131]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id PAA03502; Thu, 13 Nov 1997 15:39:43 -0800 (PST) (envelope-from archie@whistle.com) Received: (from smap@localhost) by whistle.com (8.7.5/8.6.12) id PAA16707; Thu, 13 Nov 1997 15:39:12 -0800 (PST) Received: from bubba.whistle.com(207.76.205.7) by whistle.com via smap (V1.3) id sma016703; Thu Nov 13 15:38:54 1997 Received: (from archie@localhost) by bubba.whistle.com (8.8.5/8.6.12) id PAA15786; Thu, 13 Nov 1997 15:38:54 -0800 (PST) From: Archie Cobbs Message-Id: <199711132338.PAA15786@bubba.whistle.com> Subject: Re: unkillable process In-Reply-To: <199711122300.PAA10914@bubba.whistle.com> from Archie Cobbs at "Nov 12, 97 03:00:13 pm" To: hackers@freebsd.org Date: Thu, 13 Nov 1997 15:38:53 -0800 (PST) Cc: sef@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-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I wrote: > 1. Create a named pipe > 2. Start typing into it using cat > 3. Hit control-C as many times as you want > > You'll see that the process will not die even with kill -9, > as it is stuck in uninterrupible disk sleep ("fifo"). According to sef, the problem is that the child (csh or tcsh but not sh) is ignoring SIGINT, the parent opens the file after vfork()'ing, and something else (now I forgot already). Maybe Sean could summarize to the list? Thanks, -Archie ___________________________________________________________________________ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com From owner-freebsd-hackers Thu Nov 13 15:41:01 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id PAA03727 for hackers-outgoing; Thu, 13 Nov 1997 15:41:01 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from ns.mt.sri.com (SRI-56K-FR.mt.net [206.127.65.42]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id PAA03722 for ; Thu, 13 Nov 1997 15:40:56 -0800 (PST) (envelope-from nate@rocky.mt.sri.com) Received: from rocky.mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.8.8/8.8.8) with ESMTP id QAA22563; Thu, 13 Nov 1997 16:40:38 -0700 (MST) (envelope-from nate@rocky.mt.sri.com) Received: (from nate@localhost) by rocky.mt.sri.com (8.7.5/8.7.3) id QAA11433; Thu, 13 Nov 1997 16:40:36 -0700 (MST) Date: Thu, 13 Nov 1997 16:40:36 -0700 (MST) Message-Id: <199711132340.QAA11433@rocky.mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Julian Elischer Cc: sos@freebsd.dk, hackers@freebsd.org Subject: Re: SUID-Directories patch In-Reply-To: <346B7D0F.446B9B3D@whistle.com> References: <199711132135.WAA00279@sos.freebsd.dk> <346B7D0F.446B9B3D@whistle.com> X-Mailer: VM 6.29 under 19.15 XEmacs Lucid Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > > I really need it in 2.2 rather than 3.0 so I'd like to merge it in from > > > -current later thes afternoon if I don't hear any objections. > > > > Objection. If you need this for Whistle, you should keep it in your > > own tree, its does NOT belong in the generic FreeBSD tree. > > > > > I asked if people thought it would be useful.. > I got 20 replies saying that YES it would be useful, > so I've added it to -current. I didnt' see 20 replies. I saw alot of "hmmm..., I can see where you would want it, but I don't think it's a good idea". I'm still of the mind (as I replied already) that it *definitely* shouldn't go in 2.2, and I'm not even sure I like it in 3.0 personally, but since 3.0 is for experimental stuff, I'm less likely to raise a stink about it. Nate From owner-freebsd-hackers Thu Nov 13 15:44:32 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id PAA04095 for hackers-outgoing; Thu, 13 Nov 1997 15:44:32 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from kithrup.com (kithrup.com [205.179.156.40]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id PAA04083 for ; Thu, 13 Nov 1997 15:44:16 -0800 (PST) (envelope-from sef@kithrup.com) Received: (from sef@localhost) by kithrup.com (8.8.7/8.8.7) id PAA04605 for hackers@freebsd.org; Thu, 13 Nov 1997 15:44:15 -0800 (PST) (envelope-from sef) Date: Thu, 13 Nov 1997 15:44:15 -0800 (PST) From: Sean Eric Fagan Message-Id: <199711132344.PAA04605@kithrup.com> To: hackers@freebsd.org Subject: Re: unkillable process Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >I wrote: >> 1. Create a named pipe >> 2. Start typing into it using cat >> 3. Hit control-C as many times as you want >> >> You'll see that the process will not die even with kill -9, >> as it is stuck in uninterrupible disk sleep ("fifo"). > >According to sef, the problem is that the child (csh or tcsh >but not sh) is ignoring SIGINT, the parent opens the file >after vfork()'ing, and something else (now I forgot already). My quick summary (I haven't dived into csh code yet) is that csh (and tcsh) are doing: vfork() -- parent sleeps uninterruptably until child exec's or exits signal(SIGINT, SIG_IGN); -- and other signals, presumably open("pipe", O_CREAT|O_TRUNC, ...) At that piont, the child is asleep in fifo_open(). It is interruptable -- but SIGINT is ignored! So are some other signals. The parent is unkillable; it cannot be made killable, since a vfork'd parent process is not really there -- the child is really it. (This is a holdover from the original implementation.) I think the fix is going to be in csh and tcsh -- I don't think they should be opening the file in teh child, but should only do it in the parent. I'm waiting to hear from some other people as well. Sean. From owner-freebsd-hackers Thu Nov 13 16:00:37 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id QAA05239 for hackers-outgoing; Thu, 13 Nov 1997 16:00:37 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id QAA05233 for ; Thu, 13 Nov 1997 16:00:30 -0800 (PST) (envelope-from julian@whistle.com) Received: (from daemon@localhost) by alpo.whistle.com (8.8.5/8.8.5) id PAA24320; Thu, 13 Nov 1997 15:45:03 -0800 (PST) Received: from UNKNOWN(), claiming to be "current1.whistle.com" via SMTP by alpo.whistle.com, id smtpd024290; Thu Nov 13 15:44:53 1997 Message-ID: <346B9081.15FB7483@whistle.com> Date: Thu, 13 Nov 1997 15:42:57 -0800 From: Julian Elischer Organization: Whistle Communications X-Mailer: Mozilla 3.0Gold (X11; I; FreeBSD 2.2-CURRENT i386) MIME-Version: 1.0 To: Steven Kehlet CC: hackers@FreeBSD.ORG Subject: Re: diskless freebsd, can't mount local msdos disk References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Steven Kehlet wrote: > > I'm booting FreeBSD 2.2.5 diskless with the kernel's BOOTP features. > It detects the local hardware just fine (e.g. ethernet (obviously), > hard drive, floppy, etc), but if I try to mount the local msdos disk > like I would on a non-diskless station, it doesn't work. Floppy > operations (mounting, hexdumping, fdwriting) seem to work, however. > Anyone know what's wrong, or have any suggestions what I could do? If > I can give any more information, please let me know. > > wdc0 at 0x1f0-0x1f7 irq 14 on isa > wdc0: unit 0 (wd0): > wd0: 3098MB (6346368 sectors), 6296 cyls, 16 heads, 63 S/T, 512 B/S > > # foreach i (1 2 3 4) > ? mount_msdos /dev/wd0s$i /mnt use mount -t msdos does wd0 have 4 DOS slices on it? what does '/sbin/fdisk' have to say about it? do those partitions appear in /dev? > ? end > mount_msdos: /dev/wd0s1: Invalid argument > mount_msdos: /dev/wd0s2: Invalid argument > mount_msdos: /dev/wd0s3: Invalid argument > mount_msdos: /dev/wd0s4: Invalid argument > # > > The msdos module loaded okay: > > mockingbird:/home/kehlet-> modstat > Type Id Off Loadaddr Size Info Rev Module Name > MISC 0 0 f43ea000 0008 f43eb000 1 blank_saver_mod > VFS 1 4 f442f000 001c f4435090 1 msdos > > Weird, too, if I try to hexdump the raw disk, nothing comes up: > > # hd -v /dev/rwd0 |more > # > > Thanks a ton, > > Steve Kehlet > From owner-freebsd-hackers Thu Nov 13 16:06:26 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id QAA05650 for hackers-outgoing; Thu, 13 Nov 1997 16:06:26 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from fission (fission.dt.wdc.com [129.253.40.1]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id QAA05635 for ; Thu, 13 Nov 1997 16:06:15 -0800 (PST) (envelope-from kehlet@dt.wdc.com) Received: from cygnus.dt.wdc.com (root@[172.31.1.2]) by fission (8.7.1/8.7.1) with ESMTP id QAA15666; Thu, 13 Nov 1997 16:06:11 -0800 (PST) Received: from mockingbird.dt.wdc.com (mockingbird [172.31.10.16]) by cygnus.dt.wdc.com (8.7.1/8.7.1) with ESMTP id QAA26313; Thu, 13 Nov 1997 16:06:07 -0800 (PST) Received: from localhost (kehlet@localhost) by mockingbird.dt.wdc.com (8.8.5/8.8.5) with SMTP id QAA04483; Thu, 13 Nov 1997 16:04:31 -0800 (PST) X-Authentication-Warning: mockingbird.dt.wdc.com: kehlet owned process doing -bs Date: Thu, 13 Nov 1997 16:04:31 -0800 (PST) From: Steven Kehlet To: Julian Elischer cc: hackers@freebsd.org Subject: Re: diskless freebsd, can't mount local msdos disk In-Reply-To: <346B9081.15FB7483@whistle.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hmm, "mount -t msdos" doesn't work. I thought "mount" was just a wrapper for "mount_" anyway.. # mount -t msdos /dev/wd0s1 /mnt msdos: /dev/wd0s1: Invalid argument Oops, yeah, I forgot about fdisk being weird (I suppose this definitely shows there's a problem... ;-)): # fdisk fdisk: Can't get disk parameters on /dev/rwd0; supplying dummy ones ******* Working on device /dev/rwd0 ******* parameters extracted from in-core disklabel are: cylinders=1 heads=1 sectors/track=1 (1 blks/cyl) parameters to be used for BIOS calculations are: cylinders=1 heads=1 sectors/track=1 (1 blks/cyl) fdisk: Invalid fdisk partition table found Warning: BIOS sector numbering starts with sector 1 Information from DOS bootblock is: The data for partition 0 is: The data for partition 1 is: The data for partition 2 is: The data for partition 3 is: sysid 165,(FreeBSD/NetBSD/386BSD) start 1, size 0 (0 Meg), flag 80 beg: cyl 1/ sector 1/ head 0; end: cyl 0/ sector 0/ head 0 Hmm, now why wouldn't it be able to get the disk parameters? (these are wrong, of course--there is one DOS partition on this disk). Steve On Thu, 13 Nov 1997, Julian Elischer wrote: > Date: Thu, 13 Nov 1997 15:42:57 -0800 > From: Julian Elischer > To: Steven Kehlet > Cc: hackers@freebsd.org > Subject: Re: diskless freebsd, can't mount local msdos disk > > Steven Kehlet wrote: > > > > I'm booting FreeBSD 2.2.5 diskless with the kernel's BOOTP features. > > It detects the local hardware just fine (e.g. ethernet (obviously), > > hard drive, floppy, etc), but if I try to mount the local msdos disk > > like I would on a non-diskless station, it doesn't work. Floppy > > operations (mounting, hexdumping, fdwriting) seem to work, however. > > Anyone know what's wrong, or have any suggestions what I could do? If > > I can give any more information, please let me know. > > > > wdc0 at 0x1f0-0x1f7 irq 14 on isa > > wdc0: unit 0 (wd0): > > wd0: 3098MB (6346368 sectors), 6296 cyls, 16 heads, 63 S/T, 512 B/S > > > > # foreach i (1 2 3 4) > > ? mount_msdos /dev/wd0s$i /mnt > > use mount -t msdos > > does wd0 have 4 DOS slices on it? > what does '/sbin/fdisk' have to say about it? > do those partitions appear in /dev? > > > > ? end > > mount_msdos: /dev/wd0s1: Invalid argument > > mount_msdos: /dev/wd0s2: Invalid argument > > mount_msdos: /dev/wd0s3: Invalid argument > > mount_msdos: /dev/wd0s4: Invalid argument > > # > > > > The msdos module loaded okay: > > > > mockingbird:/home/kehlet-> modstat > > Type Id Off Loadaddr Size Info Rev Module Name > > MISC 0 0 f43ea000 0008 f43eb000 1 blank_saver_mod > > VFS 1 4 f442f000 001c f4435090 1 msdos > > > > Weird, too, if I try to hexdump the raw disk, nothing comes up: > > > > # hd -v /dev/rwd0 |more > > # > > > > Thanks a ton, > > > > Steve Kehlet > > > From owner-freebsd-hackers Thu Nov 13 17:11:24 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id RAA10557 for hackers-outgoing; Thu, 13 Nov 1997 17:11:24 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from time.cdrom.com (root@time.cdrom.com [204.216.27.226]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id RAA10540 for ; Thu, 13 Nov 1997 17:11:20 -0800 (PST) (envelope-from jkh@time.cdrom.com) Received: from time.cdrom.com (jkh@localhost.cdrom.com [127.0.0.1]) by time.cdrom.com (8.8.7/8.6.9) with ESMTP id RAA04972 for ; Thu, 13 Nov 1997 17:11:20 -0800 (PST) To: hackers@FreeBSD.ORG In-reply-to: Your message of "Thu, 13 Nov 1997 12:30:43 PST." <199711132030.MAA16638@kithrup.com> Date: Thu, 13 Nov 1997 17:11:19 -0800 Message-ID: <4968.879469879@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > I have been trying to get this working in FreeBSD since last night; right > now, I'm not sure why what is happening is happening. But I'm giving up -- > I've had it "explained" to me by Jordan that even if I got it working, it > would not be considered, because this is simply not anything that anyone > needs to worry about. (Even though I do know someone whose machine has been Sean appears top have radically misunderstood my position on this, so let me just state it for the group here: 1. There is a Linux fix which David has seen and considers highly hacky. There was also the BSDI fix which would appear to have mysteriously disappeared about 24 hours after their announcement, something I found to only further support the "let's wait and see just a little longer" attitude which I'm really expounding here. 2. Intel has not yet announced the full details of their own fix but promises to do so in the next couple of days. 3. I stated facts #1 and #2 in a newsgroup posting and Sean appears to have somehow this equated with saying "FreeBSD doesn't care" or "FreeBSD will not fix this." For the record, I said no such thing and simply asked that people stop raising such an unholy ruckus about this problem until we've both heard from Intel and have had the chance to come up with a more well considered fix which is both applicable to FreeBSD and does not impose undue penalties of its own. I believe my exact phrasing was "let's make sure that the cure is not worse than the disease" and I stand by that statement, Sean's misunderstanding notwithstanding. That is all. Jordan From owner-freebsd-hackers Thu Nov 13 17:18:10 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id RAA10944 for hackers-outgoing; Thu, 13 Nov 1997 17:18:10 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from time.cdrom.com (root@time.cdrom.com [204.216.27.226]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id RAA10939 for ; Thu, 13 Nov 1997 17:18:06 -0800 (PST) (envelope-from jkh@time.cdrom.com) Received: from time.cdrom.com (jkh@localhost.cdrom.com [127.0.0.1]) by time.cdrom.com (8.8.7/8.6.9) with ESMTP id RAA05029; Thu, 13 Nov 1997 17:17:55 -0800 (PST) To: Nate Williams cc: hackers@freebsd.org Subject: Re: Pentium lockup fix in FreeBSD In-reply-to: Your message of "Thu, 13 Nov 1997 16:35:41 MST." <199711132335.QAA11405@rocky.mt.sri.com> Date: Thu, 13 Nov 1997 17:17:54 -0800 Message-ID: <5025.879470274@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > I think we need to give Jordan a big noogey if he indeed said that. For > many people with shell machines, running 'crashable' in unacceptable, I think people need to read my newsgroup posting and find out what I *actually* said before they start reacting to the words which have been placed in my mouth. And that's all I'm going to say on this topic since I don't think that responding to disinformation is all that helpful to anyone. Jordan From owner-freebsd-hackers Thu Nov 13 17:18:35 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id RAA10996 for hackers-outgoing; Thu, 13 Nov 1997 17:18:35 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from smtp04.primenet.com (smtp04.primenet.com [206.165.5.85]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id RAA10984 for ; Thu, 13 Nov 1997 17:18:32 -0800 (PST) (envelope-from tlambert@usr08.primenet.com) Received: (from daemon@localhost) by smtp04.primenet.com (8.8.7/8.8.7) id SAA16294; Thu, 13 Nov 1997 18:18:31 -0700 (MST) Received: from usr08.primenet.com(206.165.6.208) via SMTP by smtp04.primenet.com, id smtpd016277; Thu Nov 13 18:18:23 1997 Received: (from tlambert@localhost) by usr08.primenet.com (8.8.5/8.8.5) id SAA18982; Thu, 13 Nov 1997 18:18:20 -0700 (MST) From: Terry Lambert Message-Id: <199711140118.SAA18982@usr08.primenet.com> Subject: Re: SUID-Directories patch To: sos@FreeBSD.dk Date: Fri, 14 Nov 1997 01:18:20 +0000 (GMT) Cc: julian@whistle.com, hackers@FreeBSD.ORG In-Reply-To: <199711132135.WAA00279@sos.freebsd.dk> from "S?ren Schmidt" at Nov 13, 97 10:35:28 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > I'd like to move this to 2.2.x > > > > It is all hidden behind #ifdef SUIDDIR > > so I can guarantee that it won't BREAK anything. > > > > I really need it n 2.2 rather than 3.0 so I'd like to merge it in from > > -current later thes afternoon if I don't hear any objections. > > Objection. If you need this for Whistle, you should keep it in your > own tree, its does NOT belong in the generic FreeBSD tree. Time to move the boot code into the Whistle tree and take it out of the FreeBSD tree? (Whistle needs boot code, too..). One of the main incentives for commercial entities to give code back is offloading of maintenance. You can of course pick and choose what you want to take, but the fix seems generically useful (expecially the kernel vs. exported flags stuff that it requires to make it work, which frees up 13 bits(!) in the external flags for yet more mount options (like the rather less useful -- but still useful -- symbolic link defeating options). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Thu Nov 13 17:30:11 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id RAA11759 for hackers-outgoing; Thu, 13 Nov 1997 17:30:11 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from ns.mt.sri.com (SRI-56K-FR.mt.net [206.127.65.42]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id RAA11748 for ; Thu, 13 Nov 1997 17:30:07 -0800 (PST) (envelope-from nate@rocky.mt.sri.com) Received: from rocky.mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.8.8/8.8.8) with ESMTP id SAA23249; Thu, 13 Nov 1997 18:30:04 -0700 (MST) (envelope-from nate@rocky.mt.sri.com) Received: (from nate@localhost) by rocky.mt.sri.com (8.7.5/8.7.3) id SAA11853; Thu, 13 Nov 1997 18:30:03 -0700 (MST) Date: Thu, 13 Nov 1997 18:30:03 -0700 (MST) Message-Id: <199711140130.SAA11853@rocky.mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: "Jordan K. Hubbard" Cc: Nate Williams , hackers@freebsd.org Subject: Re: Pentium lockup fix in FreeBSD In-Reply-To: <5025.879470274@time.cdrom.com> References: <199711132335.QAA11405@rocky.mt.sri.com> <5025.879470274@time.cdrom.com> X-Mailer: VM 6.29 under 19.15 XEmacs Lucid Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > I think we need to give Jordan a big noogey if he indeed said that. For > > many people with shell machines, running 'crashable' in unacceptable, > > I think people need to read my newsgroup posting and find out what I > *actually* said before they start reacting to the words which have > been placed in my mouth. Some of us don't have time for newsgroups, especially consider the signal/noise ratio nowadays is about nil. Send it to announce if you want us all to read it. Nate From owner-freebsd-hackers Thu Nov 13 17:41:31 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id RAA12508 for hackers-outgoing; Thu, 13 Nov 1997 17:41:31 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from time.cdrom.com (root@time.cdrom.com [204.216.27.226]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id RAA12501 for ; Thu, 13 Nov 1997 17:41:29 -0800 (PST) (envelope-from jkh@time.cdrom.com) Received: from time.cdrom.com (jkh@localhost.cdrom.com [127.0.0.1]) by time.cdrom.com (8.8.7/8.6.9) with ESMTP id RAA05168; Thu, 13 Nov 1997 17:41:21 -0800 (PST) To: Nate Williams cc: hackers@freebsd.org Subject: Re: Pentium lockup fix in FreeBSD In-reply-to: Your message of "Thu, 13 Nov 1997 18:30:03 MST." <199711140130.SAA11853@rocky.mt.sri.com> Date: Thu, 13 Nov 1997 17:41:21 -0800 Message-ID: <5164.879471681@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > Some of us don't have time for newsgroups, especially consider the > signal/noise ratio nowadays is about nil. Send it to announce if you > want us all to read it. Sorry, if you want to know what I actually said then you'll have to make the effort. My posting wasn't announce material or I'd have sent it there in the first place. In any case, I'd be appreciative if people who have enough time to react to Sean's version of events could also take the time to learn the actual version by reading the newsgroups. I know how bad the SNR problems are there but I think you're also a big boy now, Nate, and you can probably handle it. Jordan From owner-freebsd-hackers Thu Nov 13 17:43:58 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id RAA12657 for hackers-outgoing; Thu, 13 Nov 1997 17:43:58 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from ns.mt.sri.com (SRI-56K-FR.mt.net [206.127.65.42]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id RAA12644 for ; Thu, 13 Nov 1997 17:43:55 -0800 (PST) (envelope-from nate@rocky.mt.sri.com) Received: from rocky.mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.8.8/8.8.8) with ESMTP id SAA23332; Thu, 13 Nov 1997 18:43:52 -0700 (MST) (envelope-from nate@rocky.mt.sri.com) Received: (from nate@localhost) by rocky.mt.sri.com (8.7.5/8.7.3) id SAA11955; Thu, 13 Nov 1997 18:43:50 -0700 (MST) Date: Thu, 13 Nov 1997 18:43:50 -0700 (MST) Message-Id: <199711140143.SAA11955@rocky.mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: "Jordan K. Hubbard" Cc: Nate Williams , hackers@freebsd.org Subject: Re: Pentium lockup fix in FreeBSD In-Reply-To: <5164.879471681@time.cdrom.com> References: <199711140130.SAA11853@rocky.mt.sri.com> <5164.879471681@time.cdrom.com> X-Mailer: VM 6.29 under 19.15 XEmacs Lucid Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > Some of us don't have time for newsgroups, especially consider the > > signal/noise ratio nowadays is about nil. Send it to announce if you > > want us all to read it. > > In any case, I'd be appreciative if people who have enough time to > react to Sean's version of events could also take the time to learn > the actual version by reading the newsgroups. There was no mention of 'newsgroups' in Sean postings, so how were we to know that is where this discussion between Sean and you took place. The first I heard about it was your last email to me. And, if you're going to make policy decisions that affect alot of users, discussion on Usenet are *NOT* the place to make them. Nate From owner-freebsd-hackers Thu Nov 13 17:51:18 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id RAA13194 for hackers-outgoing; Thu, 13 Nov 1997 17:51:18 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from time.cdrom.com (root@time.cdrom.com [204.216.27.226]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id RAA13188 for ; Thu, 13 Nov 1997 17:51:16 -0800 (PST) (envelope-from jkh@time.cdrom.com) Received: from time.cdrom.com (jkh@localhost.cdrom.com [127.0.0.1]) by time.cdrom.com (8.8.7/8.6.9) with ESMTP id RAA05226; Thu, 13 Nov 1997 17:51:08 -0800 (PST) To: Nate Williams cc: hackers@freebsd.org Subject: Re: Pentium lockup fix in FreeBSD In-reply-to: Your message of "Thu, 13 Nov 1997 18:43:50 MST." <199711140143.SAA11955@rocky.mt.sri.com> Date: Thu, 13 Nov 1997 17:51:08 -0800 Message-ID: <5222.879472268@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > There was no mention of 'newsgroups' in Sean postings, so how were we to > know that is where this discussion between Sean and you took place. The > first I heard about it was your last email to me. I hardly see how that's relevant since you just refused to read it there in any case, so what good would it have done for Sean to mention it anyway? You'd have simply refused to read it earlier is all. :) > And, if you're going to make policy decisions that affect alot of users, > discussion on Usenet are *NOT* the place to make them. I'm not making policy decisions. I was suggesting to Timo, before Sean dragged this into -hackers, that we should proceed carefully and not just blindly adopt the first hack to drop into our hands. I never said that we weren't going to fix the problem at all and I never said that it was something that FreeBSD didn't care about, I simply said that BSDI's withdrawal of their fix was suspicious and that David had reviewed the Linux fix and deemed it a disgusting hack. I then went on to say that there seemed to be a lot of scare-mongering about this particular bug considering that it was hardly the only possible DoS attack on a shell account machine. I don't see how you or Sean can equate this with "Jordan says that FreeBSD could give a shit." What Jordan is saying is that FreeBSD could stand to wait a couple of more days to see Intel's work-around and it wouldn't result in the collapse of western society as we know it. Clearly there are some here, however, who feel that it's the worst bug they've ever seen and that FreeBSD as a project will end in disaster and disgrace if we don't rush to fix it in the next 24 hours, and to that all I can say is "sheesh!" Jordan From owner-freebsd-hackers Thu Nov 13 17:52:52 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id RAA13339 for hackers-outgoing; Thu, 13 Nov 1997 17:52:52 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from whistle.com (s205m131.whistle.com [207.76.205.131]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id RAA13330 for ; Thu, 13 Nov 1997 17:52:50 -0800 (PST) (envelope-from archie@whistle.com) Received: (from smap@localhost) by whistle.com (8.7.5/8.6.12) id RAA17911; Thu, 13 Nov 1997 17:52:15 -0800 (PST) Received: from bubba.whistle.com(207.76.205.7) by whistle.com via smap (V1.3) id sma017907; Thu Nov 13 17:52:12 1997 Received: (from archie@localhost) by bubba.whistle.com (8.8.5/8.6.12) id RAA04996; Thu, 13 Nov 1997 17:52:12 -0800 (PST) From: Archie Cobbs Message-Id: <199711140152.RAA04996@bubba.whistle.com> Subject: Re: SUID-Directories patch In-Reply-To: <199711132340.QAA11433@rocky.mt.sri.com> from Nate Williams at "Nov 13, 97 04:40:36 pm" To: nate@mt.sri.com (Nate Williams) Date: Thu, 13 Nov 1997 17:52:11 -0800 (PST) Cc: julian@whistle.com, sos@freebsd.dk, hackers@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-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Nate Williams writes: > > > > I really need it in 2.2 rather than 3.0 so I'd like to merge it in from > > > > -current later thes afternoon if I don't hear any objections. > > > > > > Objection. If you need this for Whistle, you should keep it in your > > > own tree, its does NOT belong in the generic FreeBSD tree. > > > > I asked if people thought it would be useful.. > > I got 20 replies saying that YES it would be useful, > > so I've added it to -current. > > I didnt' see 20 replies. I saw alot of "hmmm..., I can see where you > would want it, but I don't think it's a good idea". I'm still of the > mind (as I replied already) that it *definitely* shouldn't go in 2.2, > and I'm not even sure I like it in 3.0 personally, but since 3.0 is for > experimental stuff, I'm less likely to raise a stink about it. Don't mind Julian, he's just being lazy :-) We have our own "patch" source tree for this kind of stuff. However, it will be interesting to see if over time anyone else finds this useful in similarly restricted settings (SAMBA servers, etc). -Archie ___________________________________________________________________________ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com From owner-freebsd-hackers Thu Nov 13 18:11:12 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id SAA14857 for hackers-outgoing; Thu, 13 Nov 1997 18:11:12 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id SAA14851 for ; Thu, 13 Nov 1997 18:11:09 -0800 (PST) (envelope-from michaelh@cet.co.jp) Received: from parkplace.cet.co.jp (parkplace.cet.co.jp [202.32.64.1]) by freefall.freebsd.org (8.8.6/8.8.5) with ESMTP id SAA11553 for ; Thu, 13 Nov 1997 18:08:41 -0800 (PST) Received: from localhost (michaelh@localhost) by parkplace.cet.co.jp (8.8.8/CET-v2.2) with SMTP id CAA03446; Fri, 14 Nov 1997 02:10:16 GMT Date: Fri, 14 Nov 1997 11:10:16 +0900 (JST) From: Michael Hancock To: "Barfuß Egon jun." cc: hackers@FreeBSD.com Subject: Re: Need a Firewall but don´t know which one In-Reply-To: <346ABBED.9B263F33@computronic.at> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk http://www.gnatbox.com. Floppy based system that is based on a culled version of FreeBSD. From owner-freebsd-hackers Thu Nov 13 18:17:56 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id SAA15419 for hackers-outgoing; Thu, 13 Nov 1997 18:17:56 -0800 (PST) (envelope-from owner-freebsd-hackers) Date: Thu, 13 Nov 1997 18:17:56 -0800 (PST) From: owner-freebsd-hackers Message-Id: <199711140217.SAA15419@hub.freebsd.org> To: undisclosed-recipients:; From owner-freebsd-hackers Thu Nov 13 18:20:03 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id SAA15611 for hackers-outgoing; Thu, 13 Nov 1997 18:20:03 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from ns.mt.sri.com (SRI-56K-FR.mt.net [206.127.65.42]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id SAA15409 for ; Thu, 13 Nov 1997 18:17:49 -0800 (PST) (envelope-from nate@rocky.mt.sri.com) Received: from rocky.mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.8.8/8.8.8) with ESMTP id TAA23547; Thu, 13 Nov 1997 19:17:45 -0700 (MST) (envelope-from nate@rocky.mt.sri.com) Received: (from nate@localhost) by rocky.mt.sri.com (8.7.5/8.7.3) id TAA12083; Thu, 13 Nov 1997 19:17:43 -0700 (MST) Date: Thu, 13 Nov 1997 19:17:43 -0700 (MST) Message-Id: <199711140217.TAA12083@rocky.mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: "Jordan K. Hubbard" Cc: Nate Williams , hackers@freebsd.org Subject: Re: Pentium lockup fix in FreeBSD In-Reply-To: <5222.879472268@time.cdrom.com> References: <199711140143.SAA11955@rocky.mt.sri.com> <5222.879472268@time.cdrom.com> X-Mailer: VM 6.29 under 19.15 XEmacs Lucid Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk [ Private email ] > > There was no mention of 'newsgroups' in Sean postings, so how were we to > > know that is where this discussion between Sean and you took place. The > > first I heard about it was your last email to me. > > I hardly see how that's relevant since you just refused to read it > there in any case, so what good would it have done for Sean to mention > it anyway? You'd have simply refused to read it earlier is all. :) Well, I didn't have the ability to read it, and won't until tomorrow since my ISP's new server is on/off. > I'm not making policy decisions.... > attack on a shell account machine. I don't see how you or Sean can > equate this with "Jordan says that FreeBSD could give a shit." Based on what I heard from Sean, it sounded like a policy decision based on 'people can break into FreeBSD'. Here, let me go get the original so I'm not speaking w/out basis. I quote: I have been trying to get this working in FreeBSD since last night; right now, I'm not sure why what is happening is happening. But I'm giving up -- I've had it "explained" to me by Jordan that even if I got it working, it would not be considered, because this is simply not anything that anyone needs to worry about. I read: Jordan isn't worried about the bug. Later on he writes: (And, yes, I find Jordan's attitude that nobody should care, since there are other things that can be done to destroy a system, offensive. Just as offensive as Intel's official suggestion that you can always reboot your system.) I read: Jordan claims that there are bigger breakin problems than this, and we haven't expended any resources at fixing them, so why should we expend resources fixing this. > What Jordan is saying is that FreeBSD could stand to wait a couple of > more days to see Intel's work-around and it wouldn't result in the > collapse of western society as we know it. That's not what I read above. Now, I'm getting it 2nd hand from SEF, but the *impression* I got was that you and him had had a discussion in private email about his fix, and you told him to bugger off and not worry about the bug. What you're saying now is that "let's wait a few days and see what happens", which is valid. However, letting Sean come up with a disgusting hack 'for now' that can be pulled out and replaced in the near future when something better comes along is just as valid todo, given the seriousness of the bug. Nate From owner-freebsd-hackers Thu Nov 13 18:22:23 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id SAA15763 for hackers-outgoing; Thu, 13 Nov 1997 18:22:23 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from sasami.jurai.net (winter@sasami.jurai.net [207.96.1.17]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id SAA15755; Thu, 13 Nov 1997 18:22:17 -0800 (PST) (envelope-from winter@jurai.net) Received: from localhost (winter@localhost) by sasami.jurai.net (8.8.7/8.8.7) with SMTP id VAA06601; Thu, 13 Nov 1997 21:21:13 -0500 (EST) Date: Thu, 13 Nov 1997 21:21:12 -0500 (EST) From: "Matthew N. Dodd" To: Nate Williams cc: hackers@FreeBSD.ORG, sef@kithrup.com, jkh@FreeBSD.ORG Subject: Re: Pentium lockup fix in FreeBSD In-Reply-To: <199711132335.QAA11405@rocky.mt.sri.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Thu, 13 Nov 1997, Nate Williams wrote: > I think we need to give Jordan a big noogey if he indeed said that. For > many people with shell machines, running 'crashable' in unacceptable, If you're running shell machines where a user can execute arbitrary non-approved code, your box is root compromised already. (or will be) /* Matthew N. Dodd | A memory retaining a love you had for life winter@jurai.net | As cruel as it seems nothing ever seems to http://www.jurai.net/~winter | go right - FLA M 3.1:53 */ From owner-freebsd-hackers Thu Nov 13 18:33:06 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id SAA16479 for hackers-outgoing; Thu, 13 Nov 1997 18:33:06 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from ns.mt.sri.com (SRI-56K-FR.mt.net [206.127.65.42]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id SAA16473 for ; Thu, 13 Nov 1997 18:33:02 -0800 (PST) (envelope-from nate@rocky.mt.sri.com) Received: from rocky.mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.8.8/8.8.8) with ESMTP id TAA23655; Thu, 13 Nov 1997 19:32:54 -0700 (MST) (envelope-from nate@rocky.mt.sri.com) Received: (from nate@localhost) by rocky.mt.sri.com (8.7.5/8.7.3) id TAA12159; Thu, 13 Nov 1997 19:32:51 -0700 (MST) Date: Thu, 13 Nov 1997 19:32:51 -0700 (MST) Message-Id: <199711140232.TAA12159@rocky.mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: "Matthew N. Dodd" Cc: Nate Williams , hackers@freebsd.org Subject: Re: Pentium lockup fix in FreeBSD In-Reply-To: References: <199711132335.QAA11405@rocky.mt.sri.com> X-Mailer: VM 6.29 under 19.15 XEmacs Lucid Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > On Thu, 13 Nov 1997, Nate Williams wrote: > > I think we need to give Jordan a big noogey if he indeed said that. For > > many people with shell machines, running 'crashable' in unacceptable, > > If you're running shell machines where a user can execute arbitrary > non-approved code, your box is root compromised already. (or will be) Not! Just because a user can run a compiler doesn't mean you're root compromised. If you really think that it's impossible to secure your system you've never been a system administrator of a student system whose only purpose in life is to break root, where you learn to make a secure system. :) Nate From owner-freebsd-hackers Thu Nov 13 18:48:37 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id SAA17352 for hackers-outgoing; Thu, 13 Nov 1997 18:48:37 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from ns.mt.sri.com (SRI-56K-FR.mt.net [206.127.65.42]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id SAA17345 for ; Thu, 13 Nov 1997 18:48:33 -0800 (PST) (envelope-from nate@rocky.mt.sri.com) Received: from rocky.mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.8.8/8.8.8) with ESMTP id TAA23794; Thu, 13 Nov 1997 19:48:11 -0700 (MST) (envelope-from nate@rocky.mt.sri.com) Received: (from nate@localhost) by rocky.mt.sri.com (8.7.5/8.7.3) id TAA12336; Thu, 13 Nov 1997 19:48:09 -0700 (MST) Date: Thu, 13 Nov 1997 19:48:09 -0700 (MST) Message-Id: <199711140248.TAA12336@rocky.mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Terry Lambert Cc: sos@freebsd.dk, julian@whistle.com, hackers@freebsd.org Subject: Re: SUID-Directories patch In-Reply-To: <199711140118.SAA18982@usr08.primenet.com> References: <199711132135.WAA00279@sos.freebsd.dk> <199711140118.SAA18982@usr08.primenet.com> X-Mailer: VM 6.29 under 19.15 XEmacs Lucid Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > One of the main incentives for commercial entities to give code > back is offloading of maintenance. You can of course pick and > choose what you want to take, but the fix seems generically > useful And is in 3.0-current, but doesn't belong in 2.2. On the flip side, just because a commercial entity donates code doesn't mean we should take it into the source tree lock/stock/and barrel. Nate From owner-freebsd-hackers Thu Nov 13 18:55:59 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id SAA17626 for hackers-outgoing; Thu, 13 Nov 1997 18:55:59 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from awfulhak.demon.co.uk (awfulhak.demon.co.uk [158.152.17.1]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id SAA17619 for ; Thu, 13 Nov 1997 18:55:50 -0800 (PST) (envelope-from brian@awfulhak.org) Received: from gate.lan.awfulhak.org (localhost [127.0.0.1]) by awfulhak.demon.co.uk (8.8.7/8.8.7) with ESMTP id CAA27532; Fri, 14 Nov 1997 02:39:09 GMT (envelope-from brian@gate.lan.awfulhak.org) Message-Id: <199711140239.CAA27532@awfulhak.demon.co.uk> X-Mailer: exmh version 2.0zeta 7/24/97 To: Charles Mott cc: hackers@FreeBSD.ORG Subject: Re: Sean Eric Fagin's posting In-reply-to: Your message of "Thu, 13 Nov 1997 15:37:08 MST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 14 Nov 1997 02:39:08 +0000 From: Brian Somers Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > I don't think Jordan's attitude is really that offensive (although his > mailing list persona is sort of grumpy). I am actually more interested > that the operating system be made more solid in a general way rather than > seeing people scrambling to deal with the crisis du jour. I think Jordan is faced with a rather unique perspective. He's the person that *must* be ``grumpy''. No-one else `protects the objectives' ! But, hey ! you're reading Jordan, aren't you ! ;-I > Charles Mott -- Brian , , Don't _EVER_ lose your sense of humour.... From owner-freebsd-hackers Thu Nov 13 19:00:49 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id TAA17988 for hackers-outgoing; Thu, 13 Nov 1997 19:00:49 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from dns (dns.ida.net [204.228.203.1]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id TAA17983 for ; Thu, 13 Nov 1997 19:00:43 -0800 (PST) (envelope-from cmott@srv.net) Received: from darkstar.home (dialin1.anlw.anl.gov [141.221.254.101]) by dns (SMI-8.6/mail.byaddr) with SMTP id TAA16095; Thu, 13 Nov 1997 19:54:46 -0700 Date: Thu, 13 Nov 1997 19:59:54 -0700 (MST) From: Charles Mott X-Sender: cmott@darkstar.home To: Brian Somers cc: hackers@FreeBSD.ORG Subject: Re: Sean Eric Fagin's posting In-Reply-To: <199711140239.CAA27532@awfulhak.demon.co.uk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Fri, 14 Nov 1997, Brian Somers wrote: > > I don't think Jordan's attitude is really that offensive (although his > > mailing list persona is sort of grumpy). I am actually more interested > > that the operating system be made more solid in a general way rather than > > seeing people scrambling to deal with the crisis du jour. > > I think Jordan is faced with a rather unique perspective. He's the > person that *must* be ``grumpy''. No-one else `protects the > objectives' ! > > But, hey ! you're reading Jordan, aren't you ! ;-I > Well. you know, time heals past wounds. From owner-freebsd-hackers Thu Nov 13 19:03:51 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id TAA18196 for hackers-outgoing; Thu, 13 Nov 1997 19:03:51 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id TAA18189 for ; Thu, 13 Nov 1997 19:03:48 -0800 (PST) (envelope-from bde@zeta.org.au) Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.7/8.6.9) id OAA11983; Fri, 14 Nov 1997 14:01:41 +1100 Date: Fri, 14 Nov 1997 14:01:41 +1100 From: Bruce Evans Message-Id: <199711140301.OAA11983@godzilla.zeta.org.au> To: bde@zeta.org.au, mouth@ibm.net Subject: Re: Status of 650 UART support Cc: hackers@FreeBSD.ORG Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >>>Why can't we handle large bursts of input? >> >>Buffer sizes are finite. > >Can't we use malloc to create elastic buffers on the fly? Is that a >no-no in the kernel? It is impossible to do in fast interrrupt handlers like siointr(), tricky to do in ordinary interrupt handlers, and not done any interrupt handlers except network ones (including ppp). >Why not start from scratch and develop siov2.c which uses elastic >buffers, 650 polled vs. interrupt mode switching, yada, yada, yada. High costs/benefits. It can't be made more than about 10% faster in that way on a reasonably fast CPU, since most of the overheads are for waiting for the ISA bus. Bruce From owner-freebsd-hackers Thu Nov 13 19:03:57 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id TAA18219 for hackers-outgoing; Thu, 13 Nov 1997 19:03:57 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from ns.mt.sri.com (SRI-56K-FR.mt.net [206.127.65.42]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id TAA18205 for ; Thu, 13 Nov 1997 19:03:53 -0800 (PST) (envelope-from nate@rocky.mt.sri.com) Received: from rocky.mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.8.8/8.8.8) with ESMTP id UAA23879 for ; Thu, 13 Nov 1997 20:03:50 -0700 (MST) (envelope-from nate@rocky.mt.sri.com) Received: (from nate@localhost) by rocky.mt.sri.com (8.7.5/8.7.3) id UAA12385; Thu, 13 Nov 1997 20:03:48 -0700 (MST) Date: Thu, 13 Nov 1997 20:03:48 -0700 (MST) Message-Id: <199711140303.UAA12385@rocky.mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: hackers@freebsd.org Subject: FreeBSD interrupt code experts? X-Mailer: VM 6.29 under 19.15 XEmacs Lucid Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I'm trying to track down a bug in the pccard code. Basically, I need to have the PCIC controller interrupt to have 'priority' over any of the device interrupts. I *thought* the code that is in the tree implements this correctly, but apparently not as some have pointed out in both public and private email by showing log messages. So, does anyone know what is wrong with the current code, or can help me debug it? Bruce has been too busy to help significantly, so I need some other expert. What's happening now is that depending on the IRQ's in question, the PCIC controller *can* interrupt the card driver (desired), or if the PCIC controller and the card driver's interrupts are allocated differently (at boot time, not swapped at runtime) the card driver interrupt is *NOT* capable of being interrupt by the PCIC controller. The code and masks are obviously registered the same way both time, just the interrupt #'s have changed. I know of one possible bug in the code now (the pcic controller's interrupt mask is not properly registered), but that shouldn't affect the PCIC ISR from interrupting the card driver's ISR. The card driver's ISR is only affected by their own interrupt masks. When I look at the current code (which I wrote) it appears to be doing the exact opposite of what I want it to know do *now* (I need to change things so they are exactly opposite of my original design), but Bruce assures me it's correct for what I now intend to do. In any case, I'm getting a bit confused, so I need someone who has time to straighten me out and explain to me that why what I wrote originally was backward, or explain to me it was correct with bugs in it. No matter what, the code as it stands doesn't do what I intended it to do originally, nor what I need it to do now correctly. Nate From owner-freebsd-hackers Thu Nov 13 19:54:11 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id TAA21112 for hackers-outgoing; Thu, 13 Nov 1997 19:54:11 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from pandora.hh.kew.com (root@kendra.ne.mediaone.net [24.128.53.73]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id TAA21102 for ; Thu, 13 Nov 1997 19:54:08 -0800 (PST) (envelope-from ahd@kew.com) Received: from kew.com (sonata.hh.kew.com [192.195.203.135]) by pandora.hh.kew.com (8.8.5/8.8.5) with ESMTP id WAA20066 for ; Thu, 13 Nov 1997 22:54:05 -0500 (EST) Message-ID: <346BCB5F.E8C4F50F@kew.com> Date: Thu, 13 Nov 1997 22:54:07 -0500 From: Drew Derbyshire Organization: Kendra Electronic Wonderworks, Stoneham MA 02180 X-Mailer: Mozilla 4.04 [en]C-MOENE (WinNT; I) MIME-Version: 1.0 To: hackers@freebsd.org Subject: Pentium Bug to be ignored -- say it ain't so References: <199711132030.MAA16638@kithrup.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Sean Eric Fagan wrote: > I have been trying to get this working in FreeBSD since last night; right > now, I'm not sure why what is happening is happening. But I'm giving up -- > I've had it "explained" to me by Jordan that even if I got it working, it > would not be considered, because this is simply not anything that anyone > needs to worry about. I was under the impression that the FreeBSD core team took support of web servers and the like very seriously. For anyone to take the opinion that such an obvious Denial of Service attack is not something to worry about is at best unfortunate, and seriously conflicts with my believe about the seriousness of the support of FreeBSD. Depressed, -ahd- -- Internet: ahd@kew.com Voice: 781-279-9812 "Kyrie Eleison down the road that I must travel . . ." From owner-freebsd-hackers Thu Nov 13 20:26:15 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id UAA22537 for hackers-outgoing; Thu, 13 Nov 1997 20:26:15 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from time.cdrom.com (root@time.cdrom.com [204.216.27.226]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id UAA22531 for ; Thu, 13 Nov 1997 20:26:10 -0800 (PST) (envelope-from jkh@time.cdrom.com) Received: from time.cdrom.com (jkh@localhost.cdrom.com [127.0.0.1]) by time.cdrom.com (8.8.7/8.6.9) with ESMTP id UAA05783; Thu, 13 Nov 1997 20:26:04 -0800 (PST) To: Nate Williams cc: hackers@freebsd.org Subject: Re: Pentium lockup fix in FreeBSD In-reply-to: Your message of "Thu, 13 Nov 1997 19:17:43 MST." <199711140217.TAA12083@rocky.mt.sri.com> Date: Thu, 13 Nov 1997 20:26:04 -0800 Message-ID: <5779.879481564@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > [ Private email ] Oh? Just between you, me and all of -hackers, eh? :-) If you're going to send something in private email then cc'ing hackers doesn't make a lot of sense (not that much of this discussion has so far). > I quote: > I have been trying to get this working in FreeBSD since last night; right > now, I'm not sure why what is happening is happening. But I'm giving up -- > I've had it "explained" to me by Jordan that even if I got it working, it > would not be considered, because this is simply not anything that anyone > needs to worry about. > > I read: > > Jordan isn't worried about the bug. Sure, if you believe Sean's statements over reality then that would be the right conclusion. However, that's not what I said to Sean. What I said was that David felt the original Linux fix to be a disgusting hack. I didn't say that any fix at all would be unacceptable and I didn't say that the bug was completely beneath our dignity to fix, I simply relayed an opinion that the one that Linux used was not considered all that clean (and I didn't even claim it as *my* opinion, something which Sean conveniently glossed over in his own attacks on "my position"). > Later on he writes: > (And, yes, I find Jordan's attitude that nobody should care, since there are > other things that can be done to destroy a system, offensive. Just as > offensive as Intel's official suggestion that you can always reboot your > system.) > > I read: > > Jordan claims that there are bigger breakin problems than this, and we > haven't expended any resources at fixing them, so why should we expend > resources fixing this. Yes, again, you're reacting not to what I said but to what someone else says I said. If you believe everything you read 2nd hand then there's really no point in continuing this discussion anyway since facts are evidently unimportant to you (see? Two can play the "let's jump to idiotic conclusions given an insufficiency of facts" game :-). If we're going to debate what someone said I said vs what I actually said then I really don't see the merit of even continuing this discussion. You are knocking down straw men, nothing more. Jordan From owner-freebsd-hackers Thu Nov 13 20:37:21 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id UAA23046 for hackers-outgoing; Thu, 13 Nov 1997 20:37:21 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from time.cdrom.com (root@time.cdrom.com [204.216.27.226]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id UAA23041 for ; Thu, 13 Nov 1997 20:37:19 -0800 (PST) (envelope-from jkh@time.cdrom.com) Received: from time.cdrom.com (jkh@localhost.cdrom.com [127.0.0.1]) by time.cdrom.com (8.8.7/8.6.9) with ESMTP id UAA05871; Thu, 13 Nov 1997 20:37:15 -0800 (PST) To: Drew Derbyshire cc: hackers@FreeBSD.ORG Subject: Re: Pentium Bug to be ignored -- say it ain't so In-reply-to: Your message of "Thu, 13 Nov 1997 22:54:07 EST." <346BCB5F.E8C4F50F@kew.com> Date: Thu, 13 Nov 1997 20:37:14 -0800 Message-ID: <5867.879482234@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > I was under the impression that the FreeBSD core team took support of web > servers and the like very seriously. For anyone to take the opinion that > such an obvious Denial of Service attack is not something to worry about is > at best unfortunate, and seriously conflicts with my believe about the > seriousness of the support of FreeBSD. Sean is twisting the truth beyond all measure here and has now joined my procmail file as someone I'm no longer interested in dealing with. If you're into believing outright falsehoods then continue being depressed, otherwise please wait for us to collect the relevant information and make a proper fix which neither adversely impacts performance nor obfuscates the code beyond any reasonable degree. Jordan From owner-freebsd-hackers Thu Nov 13 21:04:37 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id VAA24523 for hackers-outgoing; Thu, 13 Nov 1997 21:04:37 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from kithrup.com (kithrup.com [205.179.156.40]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id VAA24516 for ; Thu, 13 Nov 1997 21:04:33 -0800 (PST) (envelope-from sef@kithrup.com) Received: (from sef@localhost) by kithrup.com (8.8.7/8.8.7) id VAA06875; Thu, 13 Nov 1997 21:04:20 -0800 (PST) (envelope-from sef) Date: Thu, 13 Nov 1997 21:04:20 -0800 (PST) From: Sean Eric Fagan Message-Id: <199711140504.VAA06875@kithrup.com> To: hackers@freebsd.org Reply-To: hackers@freebsd.org Subject: Re: Pentium Bug to be ignored -- say it ain't so In-Reply-To: <346BCB5F.E8C4F50F.kithrup.freebsd.hackers@kew.com> References: <199711132030.MAA16638@kithrup.com> Organization: Kithrup Enterprises, Ltd. Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In article <346BCB5F.E8C4F50F.kithrup.freebsd.hackers@kew.com> you write: >I was under the impression that the FreeBSD core team took support of web >servers and the like very seriously. For anyone to take the opinion that >such an obvious Denial of Service attack is not something to worry about is >at best unfortunate, and seriously conflicts with my believe about the >seriousness of the support of FreeBSD. This is what Jordan posted to the net. In email, he explained that, should a FreeBSD version of the linux workaround be checked in, it would immediately be removed. As I have said: I know someone who was affected by this. Fortunately, he wasn't running FreeBSD, and his OS vendor did supply a patch. Of course, that vendor is not a free-software vendor, and so was able to sign Intel's presumed NDA, which the free software folks could not. Note his declaration that this is "hardly a critical emergency". And that he assumes BSDi has thrown out their solution -- which I haven't heard them say at all. (I don't know why BSDi withdrew their patch; I can think of several reasons, actually. And SCO has not, to the best of my knowledge, withdrew *their* patch.) From: "Jordan K. Hubbard" Newsgroups: comp.unix.bsd.freebsd.misc Subject: Re: Pentium bug: FreeBSD workaround ? Date: Thu, 13 Nov 1997 08:13:31 -0800 Message-ID: <346B272B.167EB0E7@FreeBSD.org> [posted and mailed] Timo J Rinne wrote: > You understood wrong. The patch makes idt entries 0-6 to point to > unmapped space. Then pagefault handler resolves, whether it's really > a pagefault or should it forward call to the corresponding exception > handler. > > The patch should go into machdep.c and locore.s or trap.c in > /sys/i386/i386 and it of course should be optional. > > Is someone working on this or should I do it? Well, several things to note here: 1. BSDI would appear to have *withdrawn* the patch which they released to great fanfare yesterday. This is disturbing and merits closer attention before we make any moves ourselves. 2. Our principal architect has reviewed the Linux patch that someone forwarded to us and he considers it, to use his own words, "a totally disgusting hack." Let's make sure that in our haste to deal with this latest political football, we don't come up with a cure that's worse than the disease. I also hasten to note that I've yet to hear *any* reports of serious DoS attacks stemming from this bug, this being in all likelyhood another FDIV-type situation where people who wouldn't be affected in a million years by the bug are nonetheless steaming about it as if Intel had shot their dog and raped their mothers. I think folks need to put this in perspective and stop this silly scare-mongering over it - this is hardly a critical emergency and I suspect that many of the folks who are racing to implement a solution simply so that they can claim the dubious distinction of "solving it first" are only going to end up going back over their fixes later, perhaps to do as BSDI has done in throwing out the first attempt. Let's at least wait for Intel to release full details of their proposed work-around in a day or two as they've promised, eh? Again, if I were hearing anguished cries from the ISPs about this then it would be a different matter, but I haven't heard so much as a squeak from them and this would all appear to be simply another chicken little episode, with various people running around flapping and squawking simply because it makes them feel important to be given the opportunity to run around and flap about something. :-) -- - Jordan Hubbard FreeBSD core team / Walnut Creek CDROM. From owner-freebsd-hackers Thu Nov 13 21:32:56 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id VAA26757 for hackers-outgoing; Thu, 13 Nov 1997 21:32:56 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from out1.ibm.net (out1.ibm.net [165.87.194.252]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id VAA26752 for ; Thu, 13 Nov 1997 21:32:54 -0800 (PST) (envelope-from mouth@ibm.net) Received: from slip129-37-53-114.ca.us.ibm.net (slip129-37-53-114.ca.us.ibm.net [129.37.53.114]) by out1.ibm.net (8.8.5/8.6.9) with SMTP id FAA85668; Fri, 14 Nov 1997 05:32:37 GMT From: mouth@ibm.net (John Kelly) To: Bruce Evans Cc: hackers@FreeBSD.ORG Subject: Re: Status of 650 UART support Date: Fri, 14 Nov 1997 06:33:52 GMT Message-ID: <346ced6b.754999@smtp-gw01.ny.us.ibm.net> References: <199711140301.OAA11983@godzilla.zeta.org.au> In-Reply-To: <199711140301.OAA11983@godzilla.zeta.org.au> X-Mailer: Forte Agent 1.01/16.397 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by hub.freebsd.org id VAA26753 Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Fri, 14 Nov 1997 14:01:41 +1100, Bruce Evans wrote: >>Why not start from scratch and develop siov2.c which uses elastic >>buffers, 650 polled vs. interrupt mode switching, yada, yada, yada. > >High costs/benefits. It can't be made more than about 10% faster in >that way on a reasonably fast CPU, since most of the overheads are >for waiting for the ISA bus. I recall reading that 16-bit ISA I/O is faster, per byte, than 8-bit ISA I/O. I wonder how much better you could do with a card which transferred two bytes at once on the 16-bit bus. You would just need some kind of buffer between the UARTs and the bus. Maybe even shared memory ... oh well I guess I could buy a Cyclades card or such rather than go to all that trouble. John From owner-freebsd-hackers Thu Nov 13 22:02:49 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id WAA28953 for hackers-outgoing; Thu, 13 Nov 1997 22:02:49 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from crh.cl.msu.edu (crh.cl.msu.edu [35.8.1.24]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id WAA28941 for ; Thu, 13 Nov 1997 22:02:47 -0800 (PST) (envelope-from henrich@crh.cl.msu.edu) Received: (from henrich@localhost) by crh.cl.msu.edu (8.8.7/8.8.7) id BAA01225; Fri, 14 Nov 1997 01:02:45 -0500 (EST) (envelope-from henrich) Date: Fri, 14 Nov 1997 01:02:45 -0500 (EST) From: Charles Henrich Message-Id: <199711140602.BAA01225@crh.cl.msu.edu> To: jkh@time.cdrom.com, freebsd-hackers@freebsd.org Subject: Re: Pentium lockup fix in FreeBSD Newsgroups: lists.freebsd.hackers References: <64gl3p$9oe$1@msunews.cl.msu.edu> X-Newsreader: NN version 6.5.0 CURRENT #1 Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In lists.freebsd.hackers you write: >> [ Private email ] >Oh? Just between you, me and all of -hackers, eh? :-) If you're going >to send something in private email then cc'ing hackers doesn't make a >lot of sense (not that much of this discussion has so far). Okay Kids, Go back to your room. Sean, you need to learn some etiquette and A) not repost private email, and B) jump to conclusions that are contrary to what many years of FreeBSD operation has shown us. As with all security patches, one will be provided in due time, after it is evaluated critically. In this case I can honestly say "Fooey", yes its a really NASTY bug for those of us with Pentium systems that have normal users with accounts on them. However, its not the most security hole to ever be invented. Lets all act like adults here, and let this thread drop right now. -Crh -- Charles Henrich Michigan State University henrich@msu.edu http://pilot.msu.edu/~henrich From owner-freebsd-hackers Thu Nov 13 22:23:46 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id WAA00640 for hackers-outgoing; Thu, 13 Nov 1997 22:23:46 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from super-g.inch.com (super-g.com [207.240.140.161]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id WAA00635 for ; Thu, 13 Nov 1997 22:23:43 -0800 (PST) (envelope-from spork@super-g.com) Received: from localhost (localhost [127.0.0.1]) by super-g.inch.com (8.8.7/8.8.5) with SMTP id BAA12904; Fri, 14 Nov 1997 01:18:21 -0500 (EST) Date: Fri, 14 Nov 1997 01:18:21 -0500 (EST) From: spork X-Sender: spork@super-g.inch.com To: Charles Henrich cc: jkh@time.cdrom.com, freebsd-hackers@FreeBSD.ORG Subject: Re: Pentium lockup fix in FreeBSD In-Reply-To: <199711140602.BAA01225@crh.cl.msu.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk And on a practical note, let's remember that those of us who run a public-access machine generally have spare parts around. Why not make your next spare processor a K6? For me, $140 is worth about two trips in to work to hit "reset". This is the "workaround" that we used on our shell machine, and we were able to implement it right after the first user that tried it "because I didn't think it would work". Charles Charles Sprickman spork@super-g.com ---- "I'm not a prophet or a stone-age man Just a mortal with potential of a superman I'm living on" -DB On Fri, 14 Nov 1997, Charles Henrich wrote: > In lists.freebsd.hackers you write: > > >> [ Private email ] > > >Oh? Just between you, me and all of -hackers, eh? :-) If you're going > >to send something in private email then cc'ing hackers doesn't make a > >lot of sense (not that much of this discussion has so far). > > Okay Kids, Go back to your room. Sean, you need to learn some etiquette and > A) not repost private email, and B) jump to conclusions that are contrary to > what many years of FreeBSD operation has shown us. > > As with all security patches, one will be provided in due time, after it is > evaluated critically. In this case I can honestly say "Fooey", yes its a > really NASTY bug for those of us with Pentium systems that have normal users > with accounts on them. However, its not the most security hole to ever be > invented. > > Lets all act like adults here, and let this thread drop right now. > > -Crh > -- > > Charles Henrich Michigan State University henrich@msu.edu > > http://pilot.msu.edu/~henrich > From owner-freebsd-hackers Thu Nov 13 22:53:40 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id WAA03051 for hackers-outgoing; Thu, 13 Nov 1997 22:53:40 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id WAA03046 for ; Thu, 13 Nov 1997 22:53:38 -0800 (PST) (envelope-from bde@zeta.org.au) Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.7/8.6.9) id RAA20946; Fri, 14 Nov 1997 17:49:28 +1100 Date: Fri, 14 Nov 1997 17:49:28 +1100 From: Bruce Evans Message-Id: <199711140649.RAA20946@godzilla.zeta.org.au> To: bde@zeta.org.au, mouth@ibm.net Subject: Re: Status of 650 UART support Cc: hackers@FreeBSD.ORG Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >>>Why not start from scratch and develop siov2.c which uses elastic >>>buffers, 650 polled vs. interrupt mode switching, yada, yada, yada. >> >>High costs/benefits. It can't be made more than about 10% faster in >>that way on a reasonably fast CPU, since most of the overheads are >>for waiting for the ISA bus. > >I recall reading that 16-bit ISA I/O is faster, per byte, than 8-bit >ISA I/O. I wonder how much better you could do with a card which >transferred two bytes at once on the 16-bit bus. You would just need It's about twice as fast. Under Linux, Rocketport devices are reported to be about twice as efficient as the 16550 devices. This is possible because they are 16-bit devices. I haven't seen any reports of the efficiencies of Rocketports under FreeBSD but expect they are less efficient than 16550s for termios because they use the very inefficient ttyinput() routine. They should be better for slip and ppp. >some kind of buffer between the UARTs and the bus. Maybe even shared >memory ... oh well I guess I could buy a Cyclades card or such rather >than go to all that trouble. Be sure to buy one with a fast bus interface. My old ISA one is about as efficient as a 16550. Bruce From owner-freebsd-hackers Thu Nov 13 23:09:07 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id XAA04901 for hackers-outgoing; Thu, 13 Nov 1997 23:09:07 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from implode.root.com (implode.root.com [198.145.90.17]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id XAA04891 for ; Thu, 13 Nov 1997 23:09:00 -0800 (PST) (envelope-from root@implode.root.com) Received: from implode.root.com (localhost [127.0.0.1]) by implode.root.com (8.8.5/8.8.5) with ESMTP id XAA29918; Thu, 13 Nov 1997 23:10:23 -0800 (PST) Message-Id: <199711140710.XAA29918@implode.root.com> To: Charles Henrich cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Pentium lockup fix in FreeBSD In-reply-to: Your message of "Fri, 14 Nov 1997 01:02:45 EST." <199711140602.BAA01225@crh.cl.msu.edu> From: David Greenman Reply-To: dg@root.com Date: Thu, 13 Nov 1997 23:10:23 -0800 Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >In lists.freebsd.hackers you write: > >>> [ Private email ] > >>Oh? Just between you, me and all of -hackers, eh? :-) If you're going >>to send something in private email then cc'ing hackers doesn't make a >>lot of sense (not that much of this discussion has so far). > >Okay Kids, Go back to your room. Sean, you need to learn some etiquette and >A) not repost private email, and B) jump to conclusions that are contrary to >what many years of FreeBSD operation has shown us. > >As with all security patches, one will be provided in due time, after it is >evaluated critically. In this case I can honestly say "Fooey", yes its a >really NASTY bug for those of us with Pentium systems that have normal users >with accounts on them. However, its not the most security hole to ever be >invented. > >Lets all act like adults here, and let this thread drop right now. Thanks, Charles. I guess it's time that I said something as well. First, it has not been my deliberate intention to ignore Sean's private email regarding his problems trying to come up with a workaround for FreeBSD. I've spent the entire day (and the last several as well) in meetings negotiating a $200K Internet services contract for Walnut Creek CDROM. This has left me stressed out to the point of shaking and quite unable to deal with any email that didn't have quick answers. I did take some time out to look at the proposed patch for Linux. I have little to say about it other than it's not directly applicable to FreeBSD (both in terms of source code structure and algorithmic nature) and I think it is barely okay even for Linux. It seems to seriously violate machine dependant/independant seperation of the kernel sources by putting Pentium specific stuff in the generic VM fault handler, etc, not to mention being incredibly esoteric. When I say esoteric, I mean that in terms of Intel's lack of disclosure about how this fixes the problem more than I do about Linux's guesses. For these reasons and others, I refered to it as "a totally disgusting hack". On the other hand, I'm impressed that the Linux people have been able to get as far as they did with so little information from Intel. As mentioned above, I don't have any time to work on this problem myself, but I do very much appreciate the efforts that Sean and others have made on trying to make a FreeBSD workaround...I just can't be involved myself right now. With above said, I need to make one more important point. I have absolutely no problem with people coming up with a workaround for this, no matter how disgusting, if it does the job and doesn't harm people further. I fully support them making such a workaround available to anyone who wants it. HOWEVER, I do strongly object to the notion that such a hack should be brought into the FreeBSD source code repository at the first sign of life. Doing so would be a poor mode of operation in general and we must avoid this if we stand any chance of maintaining the high quality of our source tree. This is a policy issue that I believe enjoys full support of the entire FreeBSD core team. -DG David Greenman Core-team/Principal Architect, The FreeBSD Project From owner-freebsd-hackers Thu Nov 13 23:12:19 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id XAA05325 for hackers-outgoing; Thu, 13 Nov 1997 23:12:19 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from trojanhorse.ml.org (mdean.vip.best.com [206.86.94.101]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id XAA05313 for ; Thu, 13 Nov 1997 23:12:15 -0800 (PST) (envelope-from jamil@trojanhorse.ml.org) Received: from localhost (jamil@localhost) by trojanhorse.ml.org (8.8.8/8.8.5) with SMTP id XAA00978; Thu, 13 Nov 1997 23:11:53 -0800 (PST) Date: Thu, 13 Nov 1997 23:11:53 -0800 (PST) From: "Jamil J. Weatherbee" To: spork cc: Charles Henrich , jkh@time.cdrom.com, freebsd-hackers@FreeBSD.ORG Subject: Re: Pentium lockup fix in FreeBSD In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Right on my brother --- Actually I'd go for a 6x86-200 (which run about $189) I consider Intel to be responsible for their little screw up which they probably tried to cover up to minimize losses. To hell with them. The only Intel thing in my machine is my motherboard chipset (unfortunately). What AMD should do is offer a special deal where you get a discount for replacing a faulty intel processor with a K6. On Fri, 14 Nov 1997, spork wrote: > And on a practical note, let's remember that those of us who run a > public-access machine generally have spare parts around. Why not make > your next spare processor a K6? For me, $140 is worth about two trips in > to work to hit "reset". This is the "workaround" that we used on our > shell machine, and we were able to implement it right after the first user > that tried it "because I didn't think it would work". > > Charles > > Charles Sprickman > spork@super-g.com > ---- > "I'm not a prophet or a stone-age man > Just a mortal with potential of a superman > I'm living on" -DB > > On Fri, 14 Nov 1997, Charles Henrich wrote: > > > In lists.freebsd.hackers you write: > > > > >> [ Private email ] > > > > >Oh? Just between you, me and all of -hackers, eh? :-) If you're going > > >to send something in private email then cc'ing hackers doesn't make a > > >lot of sense (not that much of this discussion has so far). > > > > Okay Kids, Go back to your room. Sean, you need to learn some etiquette and > > A) not repost private email, and B) jump to conclusions that are contrary to > > what many years of FreeBSD operation has shown us. > > > > As with all security patches, one will be provided in due time, after it is > > evaluated critically. In this case I can honestly say "Fooey", yes its a > > really NASTY bug for those of us with Pentium systems that have normal users > > with accounts on them. However, its not the most security hole to ever be > > invented. > > > > Lets all act like adults here, and let this thread drop right now. > > > > -Crh > > -- > > > > Charles Henrich Michigan State University henrich@msu.edu > > > > http://pilot.msu.edu/~henrich > > > > From owner-freebsd-hackers Thu Nov 13 23:40:24 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id XAA07756 for hackers-outgoing; Thu, 13 Nov 1997 23:40:24 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from gatekeeper.tsc.tdk.com (root@gatekeeper.tsc.tdk.com [207.113.159.21]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id XAA07735 for ; Thu, 13 Nov 1997 23:40:19 -0800 (PST) (envelope-from gdonl@tsc.tdk.com) Received: from sunrise.gv.tsc.tdk.com (root@sunrise.gv.tsc.tdk.com [192.168.241.191]) by gatekeeper.tsc.tdk.com (8.8.4/8.8.4) with ESMTP id XAA15631 for ; Thu, 13 Nov 1997 23:40:13 -0800 (PST) Received: from salsa.gv.tsc.tdk.com (salsa.gv.tsc.tdk.com [192.168.241.194]) by sunrise.gv.tsc.tdk.com (8.8.5/8.8.5) with ESMTP id XAA10838 for ; Thu, 13 Nov 1997 23:40:12 -0800 (PST) Received: (from gdonl@localhost) by salsa.gv.tsc.tdk.com (8.8.5/8.8.5) id XAA12969 for hackers@FreeBSD.ORG; Thu, 13 Nov 1997 23:40:07 -0800 (PST) From: Don Lewis Message-Id: <199711140740.XAA12969@salsa.gv.tsc.tdk.com> Date: Thu, 13 Nov 1997 23:40:06 -0800 In-Reply-To: Sean Eric Fagan "Re: Pentium Bug to be ignored -- say it ain't so" (Nov 13, 9:04pm) X-Mailer: Mail User's Shell (7.2.6 alpha(3) 7/19/95) To: hackers@FreeBSD.ORG Subject: Re: Pentium Bug to be ignored -- say it ain't so Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Nov 13, 9:04pm, Sean Eric Fagan wrote: } Subject: Re: Pentium Bug to be ignored -- say it ain't so } Note his declaration that this is "hardly a critical emergency". And that } he assumes BSDi has thrown out their solution -- which I haven't heard them } say at all. (I don't know why BSDi withdrew their patch; I can think of } several reasons, actually. And SCO has not, to the best of my knowledge, } withdrew *their* patch.) What SCO patch? The only SCO patch I've heard of is a PPro and P-II microcode patch, and those processors don't have the Pentium lockup problem. From owner-freebsd-hackers Thu Nov 13 23:40:27 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id XAA07765 for hackers-outgoing; Thu, 13 Nov 1997 23:40:27 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from safeconcept.utimaco.co.at (mail-gw.utimaco.co.at [195.96.28.162]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id XAA07730 for ; Thu, 13 Nov 1997 23:40:16 -0800 (PST) (envelope-from Michael.Schuster@utimaco.co.at) Received: (from uucp@localhost) by safeconcept.utimaco.co.at (8.8.5/8.8.5) id IAA23016 for ; Fri, 14 Nov 1997 08:27:14 +0100 (CET) Received: from wshpux.utimaco.co.at(10.0.0.18) by safeconcept via smap (V2.0) id xma023013; Fri, 14 Nov 97 08:26:42 +0100 Message-ID: <346BFFA4.D440E962@utimaco.co.at> Date: Fri, 14 Nov 1997 08:37:09 +0100 From: Michael Schuster Organization: Utimaco Safe Concept GmbH., Linz, Austria X-Mailer: Mozilla 4.03 [de] (X11; I; HP-UX B.10.01 9000/715) MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Subject: Re: diskless freebsd, can't mount local msdos disk Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Steven Kehlet wrote: > # foreach i (1 2 3 4) > ? mount_msdos /dev/wd0s$i /mnt > ? end > mount_msdos: /dev/wd0s1: Invalid argument > mount_msdos: /dev/wd0s2: Invalid argument > mount_msdos: /dev/wd0s3: Invalid argument > mount_msdos: /dev/wd0s4: Invalid argument > # This is what I did just yesterday in a similar situation (I didn't know which device my DOS drive E: was located on, I just knew it was the second disk); this is bash, not (t)csh: for x in /dev/sd1*; do mount -t msdos $x /e if [ $? = 0 ]; then break; fi done so, as soon as a mount operation is successful, the loop terminates (have no worry about already-mounted disks - you get a "disk busy" message). Of course, you have to replace sd1* with your resp. device. cheers Michael -- Michael Schuster Utimaco Safe Concept GmbH. | Tel: +43 732 655755 41 Europaplatz 6 | Fax: +43 732 655755 5 A-4020 Linz Austria | email: Michael.Schuster@utimaco.co.at From owner-freebsd-hackers Thu Nov 13 23:49:10 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id XAA08662 for hackers-outgoing; Thu, 13 Nov 1997 23:49:10 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from nomis.i-connect.net (nomis.i-Connect.Net [206.190.143.100]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id XAA08652 for ; Thu, 13 Nov 1997 23:49:05 -0800 (PST) (envelope-from shimon@i-connect.net) Received: (qmail 13163 invoked by uid 1000); 14 Nov 1997 07:49:27 -0000 Message-ID: X-Mailer: XFMail 1.2-beta-111097 [p0] on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <5025.879470274@time.cdrom.com> Date: Thu, 13 Nov 1997 23:49:27 -0800 (PST) Organization: Atlas Telecom From: Simon Shapiro To: "Jordan K. Hubbard" Subject: Re: Pentium lockup fix in FreeBSD Cc: hackers@FreeBSD.ORG, Nate Williams Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hi Jordan K. Hubbard; On 14-Nov-97 you wrote: > I think people need to read my newsgroup posting and find out what I > *actually* said before they start reacting to the words which have > been placed in my mouth. And that's all I'm going to say on this > topic since I don't think that responding to disinformation is all > that helpful to anyone. You are trying to take all the fun out of it :-) Being actually factual, rather than basshing you? Bahh! What I cannot understand is why would anyone call you grumpy. You always sound so cheerful to me. Really! Simon Besides, anyone who buys an Intel product and does not run M$ software on it deserves the punsihment. Besides, where is M$ fix for this? Oh, I forgot... From owner-freebsd-hackers Thu Nov 13 23:51:03 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id XAA08872 for hackers-outgoing; Thu, 13 Nov 1997 23:51:03 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from trojanhorse.ml.org (mdean.vip.best.com [206.86.94.101]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id XAA08862 for ; Thu, 13 Nov 1997 23:50:58 -0800 (PST) (envelope-from jamil@trojanhorse.ml.org) Received: from localhost (jamil@localhost) by trojanhorse.ml.org (8.8.8/8.8.5) with SMTP id XAA01014; Thu, 13 Nov 1997 23:50:42 -0800 (PST) Date: Thu, 13 Nov 1997 23:50:42 -0800 (PST) From: "Jamil J. Weatherbee" To: Drew Derbyshire cc: hackers@FreeBSD.ORG Subject: Re: Pentium Bug to be ignored -- say it ain't so In-Reply-To: <346BCB5F.E8C4F50F@kew.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Analogies of FreeBSD pentium Bug Patch: Problem: 3rd gear on my car doesn't work Patch: Switch from 2nd to 4th Problem: Theres a hole in the bottom of my favorite coffee cup Solution: Cover the hole with your finger when drinking Problem: Intraoffice email to my boss is not working Solution: Print the email, fax it to the secretary and have her scan it into the bosses machine Problem: I broke my lifetime guaranteed Stanley wrench Solution: Wrap plenty of medical guage around it and get back to work Problem: I am always late to work Solution: Set your clock forward 5 minutes (you idiot) Problem: I want to buy a $22000 sports car Solution: Buy a $13000 Honda. Then spend $12000: lower it, put huge chrome tail pipes on it, remove the shocks, put a spoiler bigger than a learjets rear stabilizer, replace the engine control computer so it sounds like a harley, put racing stripes, a roll bar, and huge stickers reading: Kumumoto Racing Team and always, always drive 55 mph in first gear. Send me $300 dollars and I will gladly send you a Pentium Bug patch. * Precision microfabrication factory not included. Some restrictions may apply. I guess this is very much like race, if you ain't it how can you understand it? Problem is you can't. But personally (and maybye it is because I don't have an intel { when I bought my last processor if i had bought an intel it would of been a P120, that was what was in my price range a the time } I think that this whole argument over a SOFTWARE fix for a HARDWARE bug is PRETTY F___ING STUPID. It is like asking the freebsd core team to make your machine more stable through power outages. If the damn hardware doesn't work the way it is supposed to, no amount of software is going to fix that. End of story. Now go away, I don't want to hear anymore about it. From owner-freebsd-hackers Fri Nov 14 00:36:06 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id AAA11567 for hackers-outgoing; Fri, 14 Nov 1997 00:36:06 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from sos.freebsd.dk (sos.freebsd.dk [195.8.129.33]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id AAA11526 for ; Fri, 14 Nov 1997 00:36:01 -0800 (PST) (envelope-from sos@sos.freebsd.dk) Received: (from sos@localhost) by sos.freebsd.dk (8.8.8/8.7.3) id JAA01286; Fri, 14 Nov 1997 09:36:38 +0100 (MET) Message-Id: <199711140836.JAA01286@sos.freebsd.dk> Subject: Re: SUID-Directories patch In-Reply-To: <199711140248.TAA12336@rocky.mt.sri.com> from Nate Williams at "Nov 13, 97 07:48:09 pm" To: nate@mt.sri.com (Nate Williams) Date: Fri, 14 Nov 1997 09:36:38 +0100 (MET) Cc: tlambert@primenet.com, sos@freebsd.dk, julian@whistle.com, hackers@freebsd.org From: Søren Schmidt Reply-to: sos@freebsd.dk X-Mailer: ELM [version 2.4ME+ PL30 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In reply to Nate Williams who wrote: > > One of the main incentives for commercial entities to give code > > back is offloading of maintenance. You can of course pick and > > choose what you want to take, but the fix seems generically > > useful > > And is in 3.0-current, but doesn't belong in 2.2. On the flip side, > just because a commercial entity donates code doesn't mean we should > take it into the source tree lock/stock/and barrel. Exactly. I wont accecpt that YOU guys offloads YOUR maintenance on our backs, we have had PLENTY of that allready, thankyou... Now kill this thread, and get back to work... -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Søren Schmidt (sos@FreeBSD.org) FreeBSD Core Team Even more code to hack -- will it ever end .. From owner-freebsd-hackers Fri Nov 14 01:01:02 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id BAA13532 for hackers-outgoing; Fri, 14 Nov 1997 01:01:02 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id BAA13521 for ; Fri, 14 Nov 1997 01:00:59 -0800 (PST) (envelope-from julian@whistle.com) Received: (from daemon@localhost) by alpo.whistle.com (8.8.5/8.8.5) id AAA05650; Fri, 14 Nov 1997 00:55:47 -0800 (PST) Received: from UNKNOWN(), claiming to be "current1.whistle.com" via SMTP by alpo.whistle.com, id smtpd005646; Fri Nov 14 00:55:43 1997 Message-ID: <346C119A.ABD322C@whistle.com> Date: Fri, 14 Nov 1997 00:53:46 -0800 From: Julian Elischer Organization: Whistle Communications X-Mailer: Mozilla 3.0Gold (X11; I; FreeBSD 2.2-CURRENT i386) MIME-Version: 1.0 To: Terry Lambert CC: sos@FreeBSD.dk, hackers@FreeBSD.ORG Subject: Re: SUID-Directories patch References: <199711140118.SAA18982@usr08.primenet.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Terry Lambert wrote: > (expecially the kernel vs. exported flags stuff that it > requires to make it work, which frees up 13 bits(!) in the > external flags for yet more mount options (like the rather less > useful -- but still useful -- symbolic link defeating options). actually terry I already snuck those changes into 3.0 as it wasn't really that much of a change. They are not really needed in 2.2, as there are still a couple of free bits and I doubt that 2.2.x will use them all. (if we do then we can do it then). In 3.0 I actually only freed up 3 bits, bringing it to a total of 8 bits free. (5 were recently freed, but I don't want to re-use them as old copies of 'mount' may get upset if I do) There are a couple more that should move, I think, but I'm not sure about them. I didn't notice that they were freed when I posted my first 'out of bits' message, only that the 3 free bits in 2.2 were all used up. Sorry about misleading you. I should have looked better. The total score is, (from memory) 19 exported visible bona-fide bits (including 4 internal status bits) leaving 13. made up of: 1 exportable but invisible (no idea why) 4 command modifiers 8 free, all in 0x0FF00000 I THINK that two of the internal status bits (MNT_LOCAL & MNT_ROOTFS) need not be exported and should also shift. (I've never seen the root one set and do we need to be told that wd0a is local?) (well ok, maybe they can stay. From owner-freebsd-hackers Fri Nov 14 01:20:27 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id BAA14827 for hackers-outgoing; Fri, 14 Nov 1997 01:20:27 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id BAA14822 for ; Fri, 14 Nov 1997 01:20:24 -0800 (PST) (envelope-from julian@whistle.com) Received: (from daemon@localhost) by alpo.whistle.com (8.8.5/8.8.5) id BAA05807; Fri, 14 Nov 1997 01:05:57 -0800 (PST) Received: from UNKNOWN(), claiming to be "current1.whistle.com" via SMTP by alpo.whistle.com, id smtpd005804; Fri Nov 14 01:05:53 1997 Message-ID: <346C13FC.31DFF4F5@whistle.com> Date: Fri, 14 Nov 1997 01:03:56 -0800 From: Julian Elischer Organization: Whistle Communications X-Mailer: Mozilla 3.0Gold (X11; I; FreeBSD 2.2-CURRENT i386) MIME-Version: 1.0 To: sos@freebsd.dk CC: Nate Williams , tlambert@primenet.com, hackers@freebsd.org Subject: Re: SUID-Directories patch References: <199711140836.JAA01286@sos.freebsd.dk> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk S?ren Schmidt wrote: > > In reply to Nate Williams who wrote: > > > One of the main incentives for commercial entities to give code > > > back is offloading of maintenance. You can of course pick and > > > choose what you want to take, but the fix seems generically > > > useful > > > > And is in 3.0-current, but doesn't belong in 2.2. On the flip side, > > just because a commercial entity donates code doesn't mean we should > > take it into the source tree lock/stock/and barrel. > > Exactly. I wont accecpt that YOU guys offloads YOUR maintenance on > our backs, we have had PLENTY of that allready, thankyou... actually it's not a maintainance for you.. actually the opposite. To me it means I can easier maintain the whole thing.. Without it I maintain only ours, and then have to worry about if I back-ported fixes to freeBSD. We've already pulled several bugs out of this code for FreeBSD and more will come. I accept that you won't take this simple change into 2.2, but that's fine. I offered, and you decided no. My reasn for doing it is that I don;t want to diverge from FBSD enough to divert my attentions away from it. The utility to us is undeniable, so we'll bear the cost. > > Now kill this thread, and get back to work... yes SIR! > > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > Søren Schmidt (sos@FreeBSD.org) FreeBSD Core Team > Even more code to hack -- will it ever end > .. From owner-freebsd-hackers Fri Nov 14 01:28:41 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id BAA15299 for hackers-outgoing; Fri, 14 Nov 1997 01:28:41 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id BAA15293 for ; Fri, 14 Nov 1997 01:28:38 -0800 (PST) (envelope-from bde@zeta.org.au) Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.7/8.6.9) id UAA25820; Fri, 14 Nov 1997 20:28:05 +1100 Date: Fri, 14 Nov 1997 20:28:05 +1100 From: Bruce Evans Message-Id: <199711140928.UAA25820@godzilla.zeta.org.au> To: bde@zeta.org.au, mouth@ibm.net Subject: Re: Status of 650 UART support Cc: hackers@FreeBSD.ORG Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >>>> RTS pin will be forced to high state regardless of its original >>>> state when receive FIFO reaches to the programmed trigger level. >> >>So the pessimization is standard on Startechs :-(. The RTS trigger >>level should be slightly higher than the FIFO trigger level. > >Not standard. It's only activated if you set EFR bit 6 to 1, which >sio.c apparently does for a 650. That's not much help. You get either no auto RTS flow control or pessimized auto RTS flow control. Auto CTS flow control is more useful. >I have a near worst case scenario. I have an interrupt-sharing >multiport serial adapter with eight 650s all sharing one interrupt. >The clock for each UART can be individually set (via hardware jumper) >to 1.8432MHz, 3.6864MHz, or 7.3728MHz, for a maximum port speed of >115.2k, 230.4k, or 460.8k. You'll need bigger buffers and maybe smaller fifo trigger levels for this, at least above 115.2k. The extra headroom provided by the 16650 may be enough at 115.2k. >I seem to recall from sio.c that in the case of a multiport serial >adapter, the ISR itself will look at every port and try to drain it. =20 I don't like it much, but decided to leave it alone because it is efficient enough and if many ports are concurrently active, and otherwise you probably have cycles to spare. >Since reducing input interrupts is a worthy goal, why not enable auto >RTS and simply run the 650 receive FIFO in polled mode? You could >start up in normal interrupt driven mode and jump to polled mode when >data starts streaming in. With the auto RTS feature activated, the I'm not sure what you mean here. If you mean a low priority polled mode, then it won't work because ports with data streaming in must be given high priority so that the polling doesn't get interrupted. If you mean a really normal (non-fast) interrupt driven mode and a high priority polled mode (essentially fast interrupt mode with CPU interrupts disabled), then it won't work because normal interrupt driven mode doesn't have enough priority to always get the polling started early enough. Complicated variations of these schemes (based on scheduling all interrupt handlers to limit latency) can work. >650 will suspend the inbound data stream from the external device when >necessary to prevent UART overruns, as the external device would be >expected to have a large (2k? 4k?) buffer of its own to accumulate >inbound data until the 650 gives it the green light again. The external device may not be able to stop in time, and you lose input. If it stops, then you lose throughput. You don't want either unless you are overloaded. Then losing throughput automatically is good, and the amount of lost input may be smaller. >In the case of a multiport serial adapter, each port could have a flag >in sio.c which tells whether it's working in polled mode or interrupt >mode. Whenever you poll the ports which are streaming data in, you >would only have to check the ones which have their polling flag on, >because any of the other ports not being polled would still get your >attention by means of an interrupt. I don't see how to make this work with edge-triggered interrupts. E.g., suppose no ports are active and we get an interrupt. Then all ports must be in interrupt mode and we have to check them all and turn off the interrupt enables for those that are generating an interrupt. Then we return from the interrupt and switch to polled mode. This costs more than the current checking. We still have to check all ports (an average of 1.5 times around the loop for an average active port found half way round the loop). There are extra costs for context switching and toggling the interrupt enables. >With a multiport serial adapter, that would eliminate some of the >present overhead in the ISR where you have to check each port for >inbound data every time the ISR runs. The ISR would still have to >check each port which does not have its polling flag on, but as port >usage increases, that ISR overhead would decrease. There should be an average of signifcantly less than 1 port with its polling flag on! An average of 1 means that the system is polling serial ports almost 100% of the time. The relative overhead for searching for active ports also decreases as the port usage increases. Bruce From owner-freebsd-hackers Fri Nov 14 01:33:04 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id BAA15654 for hackers-outgoing; Fri, 14 Nov 1997 01:33:04 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from thorin.hway.ru (root@thorin.hway.ru [194.87.58.130]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id BAA15642 for ; Fri, 14 Nov 1997 01:32:58 -0800 (PST) (envelope-from tischenko@intech.hway.ru) Received: from flash.intech.hway.ru (flash.intech.hway.ru [192.168.1.16]) by thorin.hway.ru (8.8.6/8.8.6) with ESMTP id MAA00188; Fri, 14 Nov 1997 12:24:07 +0300 (MSK) Message-Id: <199711140924.MAA00188@thorin.hway.ru> From: "Alexander V. Tischenko" To: "Nate Williams" , "Terry Lambert" Cc: , , Subject: Re: SUID-Directories patch Date: Fri, 14 Nov 1997 12:25:57 +0300 X-MSMail-Priority: Normal X-Priority: 3 X-Mailer: Microsoft Internet Mail 4.70.1161 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > From: Nate Williams > To: Terry Lambert > Cc: sos@freebsd.dk; julian@whistle.com; hackers@FreeBSD.ORG > Subject: Re: SUID-Directories patch > > > One of the main incentives for commercial entities to give code > > back is offloading of maintenance. You can of course pick and > > choose what you want to take, but the fix seems generically > > useful > > And is in 3.0-current, but doesn't belong in 2.2. On the flip side, > just because a commercial entity donates code doesn't mean we should > take it into the source tree lock/stock/and barrel. > > > > Nate I am not shure people running network file servers will be eager to upgrade to _ANY_ new version unless expressely needed (i will not for shure!), so to have an incorporated patch for 2.2 that will solve administrative problems IS a good thing and also a must. And as for 3.0 - it is very unstable yet and shurely can't be used for building corporate heavy load servers. IMHO, the patch MUST be incorporated. Alexander V. Tischenko. From owner-freebsd-hackers Fri Nov 14 01:34:51 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id BAA15856 for hackers-outgoing; Fri, 14 Nov 1997 01:34:51 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from sos.freebsd.dk (sos.freebsd.dk [195.8.129.33]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id BAA15842 for ; Fri, 14 Nov 1997 01:34:46 -0800 (PST) (envelope-from sos@sos.freebsd.dk) Received: (from sos@localhost) by sos.freebsd.dk (8.8.8/8.7.3) id KAA01418; Fri, 14 Nov 1997 10:35:28 +0100 (MET) Message-Id: <199711140935.KAA01418@sos.freebsd.dk> Subject: Re: SUID-Directories patch In-Reply-To: <346C119A.ABD322C@whistle.com> from Julian Elischer at "Nov 14, 97 00:53:46 am" To: julian@whistle.com (Julian Elischer) Date: Fri, 14 Nov 1997 10:35:28 +0100 (MET) Cc: tlambert@primenet.com, sos@FreeBSD.dk, hackers@FreeBSD.ORG From: Søren Schmidt Reply-to: sos@FreeBSD.dk X-Mailer: ELM [version 2.4ME+ PL30 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk In reply to Julian Elischer who wrote: > Terry Lambert wrote: > > (expecially the kernel vs. exported flags stuff that it > > requires to make it work, which frees up 13 bits(!) in the > > external flags for yet more mount options (like the rather less > > useful -- but still useful -- symbolic link defeating options). > > actually terry I already snuck those changes into 3.0 ^^^^^ See!!, THAT is the problem I'm seeing with all of this, it has to STOP! And I mean it. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Søren Schmidt (sos@FreeBSD.org) FreeBSD Core Team Even more code to hack -- will it ever end .. From owner-freebsd-hackers Fri Nov 14 01:44:37 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id BAA16470 for hackers-outgoing; Fri, 14 Nov 1997 01:44:37 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from love.MCCP.com (love.MCCP.com [206.86.92.190]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id BAA16465 for ; Fri, 14 Nov 1997 01:44:33 -0800 (PST) (envelope-from root@love.MCCP.com) Received: (from root@localhost) by love.MCCP.com (8.8.7/8.7.3) id BAA00493 for hackers@freebsd.org; Fri, 14 Nov 1997 01:44:26 -0800 (PST) From: Charlie Root Message-Id: <199711140944.BAA00493@love.MCCP.com> Subject: I have this problem To: hackers@freebsd.org Date: Fri, 14 Nov 1997 01:44:26 -0800 (PST) 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-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I want to play mp3 files, and it plays but, it is like i do not have enough buffering space... but then I looked at the console: Sound: DMA timed out - IRQ/DRQ config error? >> this is my /dev/sndstat: VoxWare Sound Driver:3.0-beta-950506 (Sun Feb 5 14:38:12 EST 1995 freebsd-hackers@freefall.cdrom.com) Config options: ffffffff Installed drivers: Type 1: OPL-2/OPL-3 FM Type 2: SoundBlaster Type 6: SoundBlaster16 Type 7: SB16 MIDI Card config: SoundBlaster at 0x220 irq 7 drq 1 SoundBlaster16 at 0x0 irq 65535 drq 5 SB16 MIDI at 0x330 irq 65535 drq 4294967295 OPL-2/OPL-3 FM at 0x388 irq 65535 drq 4294967295 Audio devices: 0: SoundBlaster 16 4.5 Synth devices: 0: Yamaha OPL-3 Midi devices: 0: SoundBlaster 16 Midi Timers: 0: System Timer Mixers: 0: SoundBlaster >> this is my `dmesg`: sb0 at 0x220 irq 7 drq 1 on isa sb0: sbxvi0 at 0x0 drq 5 on isa sbxvi0: sbmidi0 at 0x330 on isa opl0 at 0x388 on isa opl0: Sound: DMA timed out - IRQ/DRQ config error? Sound: DMA timed out - IRQ/DRQ config error? Sound: DMA timed out - IRQ/DRQ config error? what did I do wrong? -- Gena Gulchin P.S. under Win95 it works perfectly.... so I do not think it is hardware problem ; -) From owner-freebsd-hackers Fri Nov 14 01:47:42 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id BAA16797 for hackers-outgoing; Fri, 14 Nov 1997 01:47:42 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from implode.root.com (implode.root.com [198.145.90.17]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id BAA16787 for ; Fri, 14 Nov 1997 01:47:39 -0800 (PST) (envelope-from root@implode.root.com) Received: from implode.root.com (localhost [127.0.0.1]) by implode.root.com (8.8.5/8.8.5) with ESMTP id BAA03021; Fri, 14 Nov 1997 01:49:04 -0800 (PST) Message-Id: <199711140949.BAA03021@implode.root.com> To: Julian Elischer cc: hackers@FreeBSD.ORG Subject: Re: SUID-Directories patch In-reply-to: Your message of "Fri, 14 Nov 1997 00:53:46 PST." <346C119A.ABD322C@whistle.com> From: David Greenman Reply-To: dg@root.com Date: Fri, 14 Nov 1997 01:49:04 -0800 Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >I THINK that two of the internal status bits (MNT_LOCAL & MNT_ROOTFS) >need not be exported and should also shift. If you think that then you'd be wrong about MNT_LOCAL. It's used to distinguish local (non network) from network filesystems and affects utilities like find(1) and perhaps others. -DG David Greenman Core-team/Principal Architect, The FreeBSD Project From owner-freebsd-hackers Fri Nov 14 02:20:31 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id CAA18603 for hackers-outgoing; Fri, 14 Nov 1997 02:20:31 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id CAA18597 for ; Fri, 14 Nov 1997 02:20:27 -0800 (PST) (envelope-from julian@whistle.com) Received: (from daemon@localhost) by alpo.whistle.com (8.8.5/8.8.5) id CAA06714; Fri, 14 Nov 1997 02:08:00 -0800 (PST) Received: from UNKNOWN(), claiming to be "current1.whistle.com" via SMTP by alpo.whistle.com, id smtpd006712; Fri Nov 14 02:07:59 1997 Message-ID: <346C228A.2F1CF0FB@whistle.com> Date: Fri, 14 Nov 1997 02:06:02 -0800 From: Julian Elischer Organization: Whistle Communications X-Mailer: Mozilla 3.0Gold (X11; I; FreeBSD 2.2-CURRENT i386) MIME-Version: 1.0 To: sos@freebsd.dk CC: Nate Williams , tlambert@primenet.com, hackers@FreeBSD.ORG Subject: Re: SUID-Directories patch References: <199711140836.JAA01286@sos.freebsd.dk> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk S?ren Schmidt wrote: > > In reply to Nate Williams who wrote: > > > One of the main incentives for commercial entities to give code > > > back is offloading of maintenance. You can of course pick and > > > choose what you want to take, but the fix seems generically > > > useful > > > > And is in 3.0-current, but doesn't belong in 2.2. On the flip side, > > just because a commercial entity donates code doesn't mean we should > > take it into the source tree lock/stock/and barrel. > > Exactly. I wont accecpt that YOU guys offloads YOUR maintenance on > our backs, we have had PLENTY of that allready, thankyou... yeah I've inflicted SO MUCH on you sd.c aha1542.c aha1740.c st.c /sys/i386/boot/biosboot/*(50%) fdisk, ref.tfs.com etc. etc. etc. etc. etc. > > Now kill this thread, and get back to work... > > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > Søren Schmidt (sos@FreeBSD.org) FreeBSD Core Team > Even more code to hack -- will it ever end > .. From owner-freebsd-hackers Fri Nov 14 02:53:42 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id CAA20169 for hackers-outgoing; Fri, 14 Nov 1997 02:53:42 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from sos.freebsd.dk (sos.freebsd.dk [195.8.129.33]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id CAA20162 for ; Fri, 14 Nov 1997 02:53:38 -0800 (PST) (envelope-from sos@sos.freebsd.dk) Received: (from sos@localhost) by sos.freebsd.dk (8.8.8/8.7.3) id LAA01685; Fri, 14 Nov 1997 11:54:11 +0100 (MET) Message-Id: <199711141054.LAA01685@sos.freebsd.dk> Subject: Re: SUID-Directories patch In-Reply-To: <346C228A.2F1CF0FB@whistle.com> from Julian Elischer at "Nov 14, 97 02:06:02 am" To: julian@whistle.com (Julian Elischer) Date: Fri, 14 Nov 1997 11:54:11 +0100 (MET) Cc: sos@freebsd.dk, nate@mt.sri.com, tlambert@primenet.com, hackers@FreeBSD.ORG From: Søren Schmidt Reply-to: sos@freebsd.dk X-Mailer: ELM [version 2.4ME+ PL30 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk In reply to Julian Elischer who wrote: > S?ren Schmidt wrote: > > > yeah I've inflicted SO MUCH on you > sd.c aha1542.c aha1740.c st.c /sys/i386/boot/biosboot/*(50%) > fdisk, ref.tfs.com etc. etc. etc. etc. etc. Well, you wouldn't want me to comment on this now would you :) Just an example: DEVFS.... -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Søren Schmidt (sos@FreeBSD.org) FreeBSD Core Team Even more code to hack -- will it ever end .. From owner-freebsd-hackers Fri Nov 14 03:40:28 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id DAA22222 for hackers-outgoing; Fri, 14 Nov 1997 03:40:28 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id DAA22216 for ; Fri, 14 Nov 1997 03:40:25 -0800 (PST) (envelope-from julian@whistle.com) Received: (from daemon@localhost) by alpo.whistle.com (8.8.5/8.8.5) id DAA07994; Fri, 14 Nov 1997 03:39:27 -0800 (PST) Received: from UNKNOWN(), claiming to be "current1.whistle.com" via SMTP by alpo.whistle.com, id smtpd007991; Fri Nov 14 03:39:25 1997 Message-ID: <346C37F8.62319AC4@whistle.com> Date: Fri, 14 Nov 1997 03:37:28 -0800 From: Julian Elischer Organization: Whistle Communications X-Mailer: Mozilla 3.0Gold (X11; I; FreeBSD 2.2-CURRENT i386) MIME-Version: 1.0 To: sos@freebsd.dk CC: nate@mt.sri.com, tlambert@primenet.com, hackers@FreeBSD.ORG Subject: Re: SUID-Directories patch References: <199711141054.LAA01685@sos.freebsd.dk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk S?ren Schmidt wrote: > > In reply to Julian Elischer who wrote: > > S?ren Schmidt wrote: > > > > > yeah I've inflicted SO MUCH on you > > sd.c aha1542.c aha1740.c st.c /sys/i386/boot/biosboot/*(50%) > > fdisk, ref.tfs.com etc. etc. etc. etc. etc. > > Well, you wouldn't want me to comment on this now would you :) Why not? when BSD desperatly needed a SCSI system, I had to fight all the way up from floppies to get to it and by the time I finished there was one that was sufficiently general to last till the present. I'm looking forward to the CAM stuff, but that doesn't draw from the fact that the BSD SCSI system was miles ahead of what was avaliable at the time, and I had to fight bloody hard to get it into BSD. (corporate lawyers don't often like employees ding that sort of thing) If you think I had an easy time convincing purists that using the BIOS for booting was the 'right thing', then you weren't watching. "Greatness is achieved on the shoulders of others". This implies that others come after us ond improve what we have done. In the rear view mirror,it often looks like "It should have been done that way to start with" but we can allsay that looking back. > > Just an example: DEVFS.... And what's so bad about devfs and divert sockets(mentionned in your other mail)? Divert sockets came directly from a conversation with Kieth Sklower of the CSRG who wanted a way of bringing some packets out of the kernel for processing because there was too much in there already. It's an anti-kernel-bloat tool, and it works great. You've never needed it obviously. (actually DIVERT is not my baby I just checked it in for someone else) If I ever got the help I've asked for so many times devfs would be finished by now. It's really the only way to go in the future of fully loadable devices, and I really feel let down by the lack of support I got from everyone on it. I've asked so many times for people to read it and help me with parts of the VFS that I don't understand, any I got some patches from 1 person, and PHK has looked at it for a short time. I've had real-life (TM) including a divorce, a 3 year time crunch and a startup company, to contend with and I think it's a it bloody cheak to bring up devfs as a bad thing considerning no-one else has even TRIED to solve the probelm it tries to solve, and no-one else has helped either. I'd like nothing better than to have the time to do more on it. (which incidentally I am getting a bit of now) I've bet my entire career on freeBSD, got jobs for several others doing the same and tried at every turn to push it forward. It's appreciation like this that make me feel like throwing the whole thing in and going to take that job streamlining NT I keep getting told about. I won't of course because I have a vision of what can be done here. I realise that others have lives too. So should you. I've done as much as I could given the cicumstances. Your support is appreciated. julian From owner-freebsd-hackers Fri Nov 14 03:51:19 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id DAA22635 for hackers-outgoing; Fri, 14 Nov 1997 03:51:19 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from sos.freebsd.dk (sos.freebsd.dk [195.8.129.33]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id DAA22629 for ; Fri, 14 Nov 1997 03:51:13 -0800 (PST) (envelope-from sos@sos.freebsd.dk) Received: (from sos@localhost) by sos.freebsd.dk (8.8.8/8.7.3) id MAA01829; Fri, 14 Nov 1997 12:51:31 +0100 (MET) Message-Id: <199711141151.MAA01829@sos.freebsd.dk> Subject: Re: SUID-Directories patch In-Reply-To: <346C37F8.62319AC4@whistle.com> from Julian Elischer at "Nov 14, 97 03:37:28 am" To: julian@whistle.com (Julian Elischer) Date: Fri, 14 Nov 1997 12:51:31 +0100 (MET) Cc: sos@freebsd.dk, nate@mt.sri.com, tlambert@primenet.com, hackers@FreeBSD.ORG From: Søren Schmidt Reply-to: sos@freebsd.dk X-Mailer: ELM [version 2.4ME+ PL30 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk In reply to Julian Elischer who wrote: > > I've had real-life (TM) including a divorce, a 3 year time crunch > and a startup company, > to contend with and I think it's a it bloody cheak to bring up devfs > as a bad thing considerning no-one else has even TRIED to solve the > probelm it tries to solve, and no-one else has helped either. Oh, to make this short, I havn't had a divorce, but two kids, a wife, a fulltime job, a house, two cars, a cat, a garden etc etc so I know how it is not having the time... > I'd like nothing better than to have the time to do more on it. > (which incidentally I am getting a bit of now) Great!, may I suggest that you use the time to finish DEVFS, and do it so it can pass a review, then I'll promise you it will be welcomed with open arms. Dont waste the time by makeing new halfbaked features, which probably won't get in... -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Søren Schmidt (sos@FreeBSD.org) FreeBSD Core Team Even more code to hack -- will it ever end .. From owner-freebsd-hackers Fri Nov 14 04:26:00 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id EAA24297 for hackers-outgoing; Fri, 14 Nov 1997 04:26:00 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from dyson.iquest.net (dyson.iquest.net [198.70.144.127]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id EAA24287 for ; Fri, 14 Nov 1997 04:25:53 -0800 (PST) (envelope-from toor@dyson.iquest.net) Received: (from root@localhost) by dyson.iquest.net (8.8.7/8.8.5) id HAA00859 for hackers@freebsd.org; Fri, 14 Nov 1997 07:25:51 -0500 (EST) From: "John S. Dyson" Message-Id: <199711141225.HAA00859@dyson.iquest.net> Subject: Re: SUID-Directories patch In-Reply-To: <346C119A.ABD322C@whistle.com> from Julian Elischer at "Nov 14, 97 00:53:46 am" To: hackers@freebsd.org Date: Fri, 14 Nov 1997 07:25:51 -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-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > actually terry I already snuck those changes into 3.0 > Please!!! Let's not "sneek" anything into the code. This is an open development, with consensus, I thought. There are times (mostly in the past) that we needed desperate measures. I have been trying to tame myself also. We have non-developer people *really* dependent on our code now. -- John dyson@freebsd.org jdyson@nc.com From owner-freebsd-hackers Fri Nov 14 04:36:26 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id EAA24836 for hackers-outgoing; Fri, 14 Nov 1997 04:36:26 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from dyson.iquest.net (dyson.iquest.net [198.70.144.127]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id EAA24831 for ; Fri, 14 Nov 1997 04:36:23 -0800 (PST) (envelope-from toor@dyson.iquest.net) Received: (from root@localhost) by dyson.iquest.net (8.8.7/8.8.5) id HAA00884; Fri, 14 Nov 1997 07:36:10 -0500 (EST) From: "John S. Dyson" Message-Id: <199711141236.HAA00884@dyson.iquest.net> Subject: Re: Pentium lockup fix in FreeBSD In-Reply-To: <199711140710.XAA29918@implode.root.com> from David Greenman at "Nov 13, 97 11:10:23 pm" To: dg@root.com Date: Fri, 14 Nov 1997 07:36:10 -0500 (EST) Cc: henrich@crh.cl.msu.edu, freebsd-hackers@FreeBSD.ORG 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-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk David Greenman said: > > With above said, I need to make one more important point. I have absolutely > no problem with people coming up with a workaround for this, no matter how > disgusting, if it does the job and doesn't harm people further. I fully > support them making such a workaround available to anyone who wants it. > HOWEVER, I do strongly object to the notion that such a hack should be brought > into the FreeBSD source code repository at the first sign of life. Doing so > would be a poor mode of operation in general and we must avoid this if we > stand any chance of maintaining the high quality of our source tree. This > is a policy issue that I believe enjoys full support of the entire FreeBSD > core team. > Yes. I also greatly respect/appreciate the work that people have done to try to create a fix. I think that we should not tell people that we have fixed the problem, only to leave a more subtile hole in the system for some hacker to take advantage of, or perhaps destablize the system in some way that none of us will easily understand. It is not a good idea to tell an ISP, for example, that we have fixed the problem, when we really have not. Remember, we will likely have to change both -stable and -current, and we need to be especially careful with -stable in representing the fix status. I think that we all can understand the panic (no pun) that people might feel about this problem. -- John dyson@freebsd.org jdyson@nc.com From owner-freebsd-hackers Fri Nov 14 05:09:31 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id FAA26553 for hackers-outgoing; Fri, 14 Nov 1997 05:09:31 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from out1.ibm.net (out1.ibm.net [165.87.194.252]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id FAA26546 for ; Fri, 14 Nov 1997 05:09:27 -0800 (PST) (envelope-from mouth@ibm.net) Received: from slip129-37-53-71.ca.us.ibm.net (slip129-37-53-71.ca.us.ibm.net [129.37.53.71]) by out1.ibm.net (8.8.5/8.6.9) with SMTP id NAA55264; Fri, 14 Nov 1997 13:09:18 GMT From: mouth@ibm.net (John Kelly) To: Bruce Evans Cc: bde@zeta.org.au, hackers@FreeBSD.ORG Subject: Re: Status of 650 UART support Date: Fri, 14 Nov 1997 14:10:33 GMT Message-ID: <346c51c4.1329130@smtp-gw01.ny.us.ibm.net> References: <199711140928.UAA25820@godzilla.zeta.org.au> In-Reply-To: <199711140928.UAA25820@godzilla.zeta.org.au> X-Mailer: Forte Agent 1.01/16.397 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by hub.freebsd.org id FAA26547 Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Fri, 14 Nov 1997 20:28:05 +1100, Bruce Evans wrote: >>In the case of a multiport serial adapter, each port could have a flag >>in sio.c which tells whether it's working in polled mode or interrupt >>mode. Whenever you poll the ports which are streaming data in, you >>would only have to check the ones which have their polling flag on, >>because any of the other ports not being polled would still get your >>attention by means of an interrupt. > >I don't see how to make this work with edge-triggered interrupts. Edge triggered interrupts are not a factor. >E.g., suppose no ports are active and we get an interrupt. Then all >ports must be in interrupt mode and we have to check them all and turn >off the interrupt enables for those that are generating an interrupt. >Then we return from the interrupt and switch to polled mode. This costs >more than the current checking. We still have to check all ports No. >average of 1.5 times around the loop for an average active port found >half way round the loop). There are extra costs for context switching >and toggling the interrupt enables. I also want to pursue some other points in your reply, but I want to clear up this point before proceeding. A port would not be switched to polled mode until its inbound data throughput crosses some defined threshold for some defined period of time -- think of it like a starship making the jump from impulse power to warp drive -- you don't make the switch until you near light speed. :-) As long as data streams in at high speed, you leave the port in polled mode, grabbing its inbound data, not with a fast interrupt, but with a normal scheduled interrupt with other interrupts *enabled*. Remember, it won't matter whether you *always* service the inbound data fast enough, or whether your normal scheduled interrupt is interrupted to run some other task, because the 650 auto RTS will do inbound flow control all by itself. If you see that the inbound FIFO is always full when you start to empty it, you know you are not servicing the data stream fast enough. You can then adjust the scheduling priority and/or time as needed to keep up with the inbound data. That is how you will avoid loss of throughput and efficiency. If the data stream throughput falls below the "warp" threshold, you drop the port back to impulse power -- er, interrupt mode. Each port would be switched individually, according to its data stream throughput (you would have to track that for each port), no matter whether you have an interrupt sharing multiport card, plain old serial cards, or some mix of the two (but only for ports with 650 UARTs). All this would require looking at the kernel scheduling code. That's why I earlier suggested it might take someone foolhardy to attempt it. But for now at least, I only want to know whether the concept is good, without concern for how much work it might require. John From owner-freebsd-hackers Fri Nov 14 05:18:18 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id FAA27088 for hackers-outgoing; Fri, 14 Nov 1997 05:18:18 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id FAA27083 for ; Fri, 14 Nov 1997 05:18:15 -0800 (PST) (envelope-from jamie@itribe.net) Received: from gatekeeper.itribe.net (gatekeeper.itribe.net [209.49.144.254]) by freefall.freebsd.org (8.8.6/8.8.5) with SMTP id FAA15836 for ; Fri, 14 Nov 1997 05:15:44 -0800 (PST) Message-Id: <199711141318.IAA13544@gatekeeper.itribe.net> Received: forwarded by SMTP 1.5.2. Date: Fri, 14 Nov 1997 08:16:23 -0500 (EST) From: Jamie Bowden To: Michael Hancock cc: hackers@FreeBSD.com Subject: Re: Need a Firewall but don´t know which one In-Reply-To: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Fri, 14 Nov 1997, Michael Hancock wrote: > http://www.gnatbox.com. Floppy based system that is based on a culled > version of FreeBSD. The GNAT boxes are indeed very nice. You can build a low end 486 box with no hdd, and have a firewall/natd router up in about 10 minutes. It works over ethernet, isdn, and plain jane dialup. Very cool stuff. We use it's big brother here (GTA's GFX-94 Double Firewall) here. The newest versions of the software for it are also FreeBSD based. Something about BSDi wanting a ludicrous license agreement to continue using it. Jamie Bowden Systems Administrator, iTRiBE.net If we've got to fight over grep, sign me up. But boggle can go. -Ted Faber (on Hasbro's request for removal of /usr/games/boggle) From owner-freebsd-hackers Fri Nov 14 05:31:09 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id FAA28040 for hackers-outgoing; Fri, 14 Nov 1997 05:31:09 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from ifi.uio.no (ifi.uio.no [129.240.64.2]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id FAA28029 for ; Fri, 14 Nov 1997 05:31:06 -0800 (PST) (envelope-from dag-erli@ifi.uio.no) Received: from hridil.ifi.uio.no (2602@hridil.ifi.uio.no [129.240.64.48]) by ifi.uio.no (8.8.7/8.8.7/ifi0.2) with ESMTP id OAA08053 for ; Fri, 14 Nov 1997 14:31:02 +0100 (MET) Received: (from dag-erli@localhost) by hridil.ifi.uio.no ; Fri, 14 Nov 1997 14:31:01 +0100 (MET) To: hackers@FreeBSD.ORG Subject: Re: Ethernet packet generation References: Organization: Folkerørsla Mot Knut Yrvin X-url: http://www.ifi.uio.no/~dag-erli/ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit From: dag-erli@ifi.uio.no (Dag-Erling Coidan Smørgrav) Date: 14 Nov 1997 14:30:59 +0100 In-Reply-To: Curt Sampson's message of Tue, 11 Nov 1997 17:30:00 -0800 (PST) Message-ID: Lines: 14 X-Mailer: Gnus v5.3/Emacs 19.34 Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Curt Sampson writes: > On Tue, 11 Nov 1997, Michael Knoll wrote: > > Is there a way to generate an ethernet packet, with an unsupported protocol > > through a user level program? > Yes. Use bpf. On a related subject, is there documentation available on how to program BPF under FreeBSD or other BSD unices? I think I've mostly figured it out from reading tcpdump and trafshow source as well as the Usenix'93 BPF paper, but I'd still like docs. -- * Finrod (INTJ) * Unix weenie * dag-erli@ifi.uio.no * cellular +47-92835919 * RFC1123: "Be liberal in what you accept, and conservative in what you send" From owner-freebsd-hackers Fri Nov 14 05:34:20 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id FAA28359 for hackers-outgoing; Fri, 14 Nov 1997 05:34:20 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from algw1.lucent.com (algw1.lucent.com [205.147.213.1]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id FAA28354 for ; Fri, 14 Nov 1997 05:34:18 -0800 (PST) (envelope-from dmobrien@algw1.lucent.com) Received: from nmcoma.netminder.lucent.com by alig1.firewall.lucent.com (SMI-8.6/EMS-L sol2) id IAA07286; Fri, 14 Nov 1997 08:41:43 -0500 Received: from lucent.com by nmcoma.netminder.lucent.com (SMI-8.6/EMS-L sol2) id IAA24449; Fri, 14 Nov 1997 08:32:46 -0500 Message-ID: <346C52F8.ADF4D658@lucent.com> Date: Fri, 14 Nov 1997 08:32:40 -0500 From: "Dan O'Brien" X-Mailer: Mozilla 4.03 [en] (Win95; U) MIME-Version: 1.0 To: hackers@freebsd.org Subject: [Fwd: Pentium bug: FreeBSD workaround ?] Content-Type: multipart/mixed; boundary="------------B65F27E85DB1D044A31810D1" Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk This is a multi-part message in MIME format. --------------B65F27E85DB1D044A31810D1 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Just for the record. Here is the posting. His reasoning is rational and clear. I support his "wait and see" attitude. Thanks, Dan O'Brien (dmobrien@lucent.com) Lucent Technologies, Bell Labs Innovations, Columbus OH 43213 Internal URL: External URL: Work: 614-860-2392 Home: 614-927-2178 Fax: 614-868-3810 Home2: 614-927-2955 ------------------------------------------------------ --------------B65F27E85DB1D044A31810D1 Content-Type: message/rfc822 Content-Transfer-Encoding: 7bit Content-Disposition: inline Path: nntphub.cb.lucent.com!uunet!in5.uu.net!nntprelay.mathworks.com!news1.best.com!nntp2.ba.best.com!not-for-mail From: "Jordan K. Hubbard" Newsgroups: comp.unix.bsd.freebsd.misc Subject: Re: Pentium bug: FreeBSD workaround ? Date: Thu, 13 Nov 1997 08:13:31 -0800 Organization: Walnut Creek CDROM Message-ID: <346B272B.167EB0E7@FreeBSD.org> References: <64ckdr$2gg_002@cris.com> <64diac$k7t$3@otis.netspace.net.au> <346ADA14.C167CFD7@domgen.com> NNTP-Posting-Host: time.cdrom.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: 879437616 7114 jkh 206.86.0.12 X-Mailer: Mozilla 3.03 (X11; I; FreeBSD 2.2.5-STABLE i386) To: tri@iki.fi Xref: nntphub.cb.lucent.com comp.unix.bsd.freebsd.misc:54115 [posted and mailed] Timo J Rinne wrote: > You understood wrong. The patch makes idt entries 0-6 to point to > unmapped space. Then pagefault handler resolves, whether it's really > a pagefault or should it forward call to the corresponding exception > handler. > > The patch should go into machdep.c and locore.s or trap.c in > /sys/i386/i386 and it of course should be optional. > > Is someone working on this or should I do it? Well, several things to note here: 1. BSDI would appear to have *withdrawn* the patch which they released to great fanfare yesterday. This is disturbing and merits closer attention before we make any moves ourselves. 2. Our principal architect has reviewed the Linux patch that someone forwarded to us and he considers it, to use his own words, "a totally disgusting hack." Let's make sure that in our haste to deal with this latest political football, we don't come up with a cure that's worse than the disease. I also hasten to note that I've yet to hear *any* reports of serious DoS attacks stemming from this bug, this being in all likelyhood another FDIV-type situation where people who wouldn't be affected in a million years by the bug are nonetheless steaming about it as if Intel had shot their dog and raped their mothers. I think folks need to put this in perspective and stop this silly scare-mongering over it - this is hardly a critical emergency and I suspect that many of the folks who are racing to implement a solution simply so that they can claim the dubious distinction of "solving it first" are only going to end up going back over their fixes later, perhaps to do as BSDI has done in throwing out the first attempt. Let's at least wait for Intel to release full details of their proposed work-around in a day or two as they've promised, eh? Again, if I were hearing anguished cries from the ISPs about this then it would be a different matter, but I haven't heard so much as a squeak from them and this would all appear to be simply another chicken little episode, with various people running around flapping and squawking simply because it makes them feel important to be given the opportunity to run around and flap about something. :-) -- - Jordan Hubbard FreeBSD core team / Walnut Creek CDROM. --------------B65F27E85DB1D044A31810D1-- From owner-freebsd-hackers Fri Nov 14 05:53:36 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id FAA29310 for hackers-outgoing; Fri, 14 Nov 1997 05:53:36 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from time.cdrom.com (root@time.cdrom.com [204.216.27.226]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id FAA29305 for ; Fri, 14 Nov 1997 05:53:33 -0800 (PST) (envelope-from jkh@time.cdrom.com) Received: from time.cdrom.com (jkh@localhost.cdrom.com [127.0.0.1]) by time.cdrom.com (8.8.7/8.6.9) with ESMTP id FAA09946; Fri, 14 Nov 1997 05:53:32 -0800 (PST) To: Julian Elischer cc: hackers@FreeBSD.ORG Subject: Re: SUID-Directories patch In-reply-to: Your message of "Fri, 14 Nov 1997 03:37:28 PST." <346C37F8.62319AC4@whistle.com> Date: Fri, 14 Nov 1997 05:53:32 -0800 Message-ID: <9942.879515612@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk [Cc trimmed to just include -hackers] > And what's so bad about devfs and divert sockets(mentionned in your > other mail)? > Divert sockets came directly from a conversation with > Kieth Sklower of the CSRG who wanted a way of bringing some > packets out of the kernel for processing because there was too much > in there already. It's an anti-kernel-bloat tool, and it works great. > You've never needed it obviously. (actually DIVERT is not my baby I > just checked it in for someone else) > > If I ever got the help I've asked for so many times > devfs would be finished by now. Just my two bits, and I should probably stay out of this since I've had absolutely zero luck lately dealing with "the august body" of -hackers (it was literally all I could do to prevent myself from unsubscribing for good last night), but I think that this whole argument stands in danger of becoming polarized to the point where feelings are unnecessarily bruised on both sides and that's something I think we've seen way too much of lately, so let me try and put things in some perspective. First off, I just got done defending your past contributions in -core so don't please think that I'm lining up to give Julian a shot in the goolies along some of the others who have already done so - I and many other folks greatly appreciate the work you did with the early SCSI subsystem, along with some of your more recent contributions, and I'd hate to see you go off in a huff, feeling distinctly unappreciated and unfairly judged. I don't think that anyone would dispute the fact that you played a very pivotal role in the early days of FreeBSD. However, like all projects, we've also matured over the last 4+ years and with that maturity has come a greater degree of conservatism in how we do development and in what we expect from any contributor who seeks to take on a fairly major chunk of development. What might have been considered reasonably acceptable development practice 4 or even 2 years ago simply won't fly now that we have a much larger user base and are under considerable pressure to produce a professional quality operating system which sets itself well apart from our "competition" in this arena. This means that any work started in the tree needs to be taken to completion regardless of the degree of participation by others, and anything you "sign up for" needs to be something which: A) You are capable of completing by yourself, any additional help being in the "nice to have" category but not strictly necessary to the project since additional volunteer help simply cannot be counted on as any kind of given. B) Something which *is* completed and in a timely fashion, not simply left as an "exercise to the reader" as it were. I don't mean to speak for Soren, but I do believe that he brought up DEVFS more as an example of something which violated both A and B than as an attempt to twist your tail and I can speak without fear of contradiction when I say that it would simply not be possible for you to introduce such an unfinished work in today's FreeBSD. Yours is also hardly the only example of this, others being the aborted ISDN project (which I brought in, to my later embarassment) or Garrett's devconf stuff which never fulfulled its promise and was later yanked out to general bitterness and mutual finger-pointing. We obviously don't want a repeat of those sorts of situations again and I think that folks have reasonable grounds to worry about *anyone* who has been responsible for such half-baked assaults on the tree in the past. It doesn't mean that said person will be judged unfit for all time, simply that they will have to work just a bit harder in proving to a skeptical audience that they've fully grasped these new operating principles and *will* finish anything they start, whether or not anyone else comes forward to help them with the burden. It's simply the only way to do things now if we want to avoid a tree full of good intentions but non-working code. So, what would probably help greatly at this point in proving to the skeptics that Julian Elischer, Esq is capable of working within these new operating parameters would be an acknowlegement on your part that you understand the A/B principles given above and a further committment to either removing all traces of DEVFS from the system or implementing it entirely to spec sometime within the next 60 days. If it also seems like I'm unfairly singling out DEVFS among your other notable accompishments (and I, for one, rather *like* the divert socket mechanism - well done, Whistle) then please understand that I'm underscoring it for the simple reason that it's your current unfinished opus and something which stands in the way of your "rehabilition", so to speak. It's also something which simply needs to either be finished or yanked out, like the other examples I listed above, and if you're keen to work with us then this is obviously the first item on the worksheet. Again, make no mistake. If you or anyone else wishes to develop something of an experimental nature for FreeBSD then you should by all means feel free to do so, but *in your own tree*. FreeBSD-current is a good place to refine and test new mechanisms but not the place to start placing the initial scaffolding in hopes that a few more builders will show up and help you erect the supporting members of the house. The time when that kind of approach was workable is well behind us now and people simply need to adjust to that fact. Regards, Jordan From owner-freebsd-hackers Fri Nov 14 05:58:28 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id FAA29605 for hackers-outgoing; Fri, 14 Nov 1997 05:58:28 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id FAA29591 for ; Fri, 14 Nov 1997 05:58:24 -0800 (PST) (envelope-from bde@zeta.org.au) Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.7/8.6.9) id AAA01430; Sat, 15 Nov 1997 00:53:34 +1100 Date: Sat, 15 Nov 1997 00:53:34 +1100 From: Bruce Evans Message-Id: <199711141353.AAA01430@godzilla.zeta.org.au> To: bde@zeta.org.au, mouth@ibm.net Subject: Re: Status of 650 UART support Cc: hackers@freebsd.org Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >>I don't see how to make this work with edge-triggered interrupts. > >Edge triggered interrupts are not a factor. Yes they are. >A port would not be switched to polled mode until its inbound data >throughput crosses some defined threshold for some defined period of >time -- think of it like a starship making the jump from impulse power >to warp drive -- you don't make the switch until you near light speed. >:-) This would put ports in polled mode even less than I thought you meant. It would be even more common for all ports to have their interrupts enabled, so the interrupt handler would have go round the loop checking them all an average of almost 1.5 times. (The current version goes round an average of 0.5 times too many.) >As long as data streams in at high speed, you leave the port in polled >mode, grabbing its inbound data, not with a fast interrupt, but with a >normal scheduled interrupt with other interrupts *enabled*. This won't work, since interrupts need to be reenabled on the polled ports as soon as everything in them is polled. Otherwise you may not get around to looking at them soon enough. The next clock interrupt is an average of 5 msec away, and it's silly to delay processing of warp speed ports _more_ than ordinary ports. The reverse would work better: keep interrupts disabled on ports that were inactive for the last few msec and poll these ports every 10 msec. Otherwise handle them the same as now except for skipping the polled ports in the loop in siointr(). >All this would require looking at the kernel scheduling code. That's Actually not. Low priority polling is already supported (configure without a vector). There just needs some code to move ports on and off the polled list. The loop should skip polled ports now but it doesn't bother. It doesn't even bother ports skipping closed ports. This is currently reasonable since polled ports are very uncommon and closed ports are probably uncommon (half-open ports waiting for carrier are probably common). Bruce From owner-freebsd-hackers Fri Nov 14 06:15:24 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id GAA01128 for hackers-outgoing; Fri, 14 Nov 1997 06:15:24 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id GAA01106 for ; Fri, 14 Nov 1997 06:15:19 -0800 (PST) (envelope-from Eugeny.Kuzakov@lab321.ru) Received: from lab321.ru (anonymous1.omsk.net.ru [194.226.32.34]) by freefall.freebsd.org (8.8.6/8.8.5) with ESMTP id GAA16369 for ; Fri, 14 Nov 1997 06:12:18 -0800 (PST) Received: from lab321.ru (kev.l321.omsk.net.ru [194.226.33.68]) by lab321.ru (8.8.5-MVC-230497/8.8.5) with ESMTP id TAA08272; Fri, 14 Nov 1997 19:44:06 +0600 (OSK) Message-ID: <346CAA7D.A3521404@lab321.ru> Date: Fri, 14 Nov 1997 19:46:05 +0000 From: Eugeny Kuzakov Organization: Powered by FreeBSD. X-Mailer: Mozilla 4.04 [en] (X11; I; FreeBSD 3.0-971022-SNAP i386) MIME-Version: 1.0 To: Alfred Perlstein CC: "Barfuß Egon jun." , firewalls@GreatCircle.COM, ntsecurity@iss.net, hackers@FreeBSD.com Subject: Re: Need a Firewall but don´t know which one References: Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Alfred Perlstein wrote: > > simply, FreeBSD offers a firewall where TCP and UDP traffic can be > blocked, allowed or even diverted into a program for it to processes. ipfw ? I like more ipfilter. It can customize responses to packets. -- Best wishes, Eugeny Kuzakov Laboratory 321 ( Omsk, Russia ) kev@lab321.ru From owner-freebsd-hackers Fri Nov 14 06:31:27 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id GAA02215 for hackers-outgoing; Fri, 14 Nov 1997 06:31:27 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from lab321.ru (anonymous1.omsk.net.ru [194.226.32.34]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id GAA02200 for ; Fri, 14 Nov 1997 06:31:19 -0800 (PST) (envelope-from Eugeny.Kuzakov@lab321.ru) Received: from lab321.ru (kev.l321.omsk.net.ru [194.226.33.68]) by lab321.ru (8.8.5-MVC-230497/8.8.5) with ESMTP id UAA10852; Fri, 14 Nov 1997 20:24:16 +0600 (OSK) Message-ID: <346CB3E6.D78E80FD@lab321.ru> Date: Fri, 14 Nov 1997 20:26:14 +0000 From: Eugeny Kuzakov Organization: Powered by FreeBSD. X-Mailer: Mozilla 4.04 [en] (X11; I; FreeBSD 3.0-971022-SNAP i386) MIME-Version: 1.0 To: Keith Jang CC: hackers@FreeBSD.ORG Subject: Re: Where to commit patches? [MS Joliet Ext. to CD9660] References: <346B729B.167EB0E7@email.gcn.net.tw> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Keith Jang wrote: > > I've added some code to the existing CD9660 part, to > let it recognize MS Joliet CD and the long filenames > on it. I would like to commit it, of course. The handbook > says that I should post the patches here. But I read > this mailing list for some time, and seems it's not > the right place. Can anyone tell me where the patches > should be sent? Thanks. Can you post it to this mailing list or to me ? Thanks. -- Best wishes, Eugeny Kuzakov Laboratory 321 ( Omsk, Russia ) kev@lab321.ru From owner-freebsd-hackers Fri Nov 14 06:34:18 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id GAA02504 for hackers-outgoing; Fri, 14 Nov 1997 06:34:18 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from dyson.iquest.net (dyson.iquest.net [198.70.144.127]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id GAA02495 for ; Fri, 14 Nov 1997 06:34:13 -0800 (PST) (envelope-from toor@dyson.iquest.net) Received: (from root@localhost) by dyson.iquest.net (8.8.7/8.8.5) id JAA01323 for hackers@freebsd.org; Fri, 14 Nov 1997 09:34:05 -0500 (EST) From: "John S. Dyson" Message-Id: <199711141434.JAA01323@dyson.iquest.net> Subject: Need some input re: named pipes To: hackers@freebsd.org Date: Fri, 14 Nov 1997 09:33:59 -0500 (EST) 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-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Could anyone give me some feedback on an idea of making our pipe code (fast) used for named pipes? I don't think that it is hard to implement, but do people usually use the socket ioctl's for named pipes? Many of those would go-away when moving to the pipe code. -- John dyson@freebsd.org jdyson@nc.com From owner-freebsd-hackers Fri Nov 14 07:48:32 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id HAA08023 for hackers-outgoing; Fri, 14 Nov 1997 07:48:32 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from ussenterprise.ufp.org (bicknell@ussenterprise.ufp.org [209.12.7.40]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id HAA08017 for ; Fri, 14 Nov 1997 07:48:28 -0800 (PST) (envelope-from bicknell@ussenterprise.ufp.org) Received: (from bicknell@localhost) by ussenterprise.ufp.org (8.8.7/8.8.7) id KAA17951 for freebsd-hackers@freebsd.org; Fri, 14 Nov 1997 10:48:27 -0500 (EST) From: Leo Bicknell Message-Id: <199711141548.KAA17951@ussenterprise.ufp.org> Subject: AHC / SCSI UPDATE To: freebsd-hackers@freebsd.org Date: Fri, 14 Nov 1997 10:48:26 -0500 (EST) Reply-To: bicknell@ufp.org X-Mailer: ELM [version 2.4ME+ PL32 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I have now received many replies to my post about the AHC / SCSI problems. There is an amazing pattern here. It would seem there are a great many users of Micropolis Disks and DAT tape drives who see the exact same problems I see with several adaptec controllers (2940, 1540, and others). These same people report no problems with these devices on Buglogics or NCR controllers. Several people also report they see no problems on systems with an Adaptec Segate or Adaptec Quantum pairing. So, I think there is some issue here with Micropolis / DAT drives and the Adaptec card/driver. What I am at a loss to is how to track this down. How do I go about verifing that it is a driver bug, or a SCSI incompatability between the Micropolis and the Adaptec? -- Leo Bicknell - bicknell@ufp.org System Administration - Network Design TMBG List - tmbg-list-request@tmbg.org From owner-freebsd-hackers Fri Nov 14 07:54:16 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id HAA08338 for hackers-outgoing; Fri, 14 Nov 1997 07:54:16 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from keith.private (dial97.203708.gcn.net.tw [203.70.8.97]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id HAA08328 for ; Fri, 14 Nov 1997 07:54:09 -0800 (PST) (envelope-from keith@keith.private) Received: (from keith@localhost) by keith.private (8.8.7/8.7.3) id XAA01463; Fri, 14 Nov 1997 23:53:17 +0800 (CST) Message-ID: <19971114235317.02926@email.gcn.net.tw> Date: Fri, 14 Nov 1997 23:53:17 +0800 From: Keith Jang To: Eugeny Kuzakov Cc: hackers@freebsd.org Subject: Re: Where to commit patches? [MS Joliet Ext. to CD9660] Reply-To: keith@email.gcn.net.tw References: <346B729B.167EB0E7@email.gcn.net.tw> <346CB3E6.D78E80FD@lab321.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.75 In-Reply-To: <346CB3E6.D78E80FD@lab321.ru>; from Eugeny Kuzakov on Fri, Nov 14, 1997 at 08:26:14PM +0000 Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Fri, Nov 14, 1997 at 08:26:14PM +0000, Eugeny Kuzakov wrote: > Keith Jang wrote: > > > > I've added some code to the existing CD9660 part, to > > let it recognize MS Joliet CD and the long filenames > > on it. I would like to commit it, of course. The handbook > Can you post it to this mailing list or to me ? I've searched the spec of Joliet for weeks, and the only thing I could find is the Linux patch. Therefore I must steal from it. :> Joliet uses Supplementary Volume Descriptor to store its data. SVD has the same format as Primary Volume Descriptor, except for byte position 8 & 89-120. The first three bytes starting from the 89th identifies a Joliet CD. The first two must be 0x25 & 0x2f. The third represents the level, 0x40, 0x43, 0x45 for level 1, 2, 3, respectively. The extent of Root Directory Record in SVD is different from that in PVD. So that the old code follows PVD->root, and obtains filenames like xxx~1. The patch just follows SVD->root to get the right one. The filename in directory record are stored as unicode. Since I have no idea of unicode, for now just strip null bytes. Are there any *free* unicode resources on the net? That's all I know about Joliet. :) This patch is only sufficient to read long filenames. Maybe I'll add an option to make it treat U/L cases the same. It does not utilize the three Joliet levels, neither the unicode support (I'm not sure whether unicode is supported in FreeBSD.) From owner-freebsd-hackers Fri Nov 14 08:05:45 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id IAA09226 for hackers-outgoing; Fri, 14 Nov 1997 08:05:45 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from word.smith.net.au (client42.securenet.net [205.236.147.58]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id IAA09219 for ; Fri, 14 Nov 1997 08:05:39 -0800 (PST) (envelope-from mike@word.smith.net.au) Received: from word (localhost [127.0.0.1]) by word.smith.net.au (8.8.7/8.8.5) with ESMTP id CAA00369 for ; Sat, 15 Nov 1997 02:17:07 +1030 (CST) Message-Id: <199711141547.CAA00369@word.smith.net.au> X-Mailer: exmh version 2.0zeta 7/24/97 To: hackers@FreeBSD.ORG In-reply-to: Your message of "Thu, 13 Nov 1997 12:30:43 -0800." <199711132030.MAA16638@kithrup.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 15 Nov 1997 02:17:07 +1030 From: Mike Smith Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > I have been trying to get this working in FreeBSD since last night; right > now, I'm not sure why what is happening is happening. But I'm giving up -- > I've had it "explained" to me by Jordan that even if I got it working, it > would not be considered, because this is simply not anything that anyone > needs to worry about. Uh, what? And based solely on that, you are giving up? How many other dissenting voices do you need before you're willing to pick it up again? Sure, technically, it's somewhat of a nonissue, but from the publicity point of view it's really a pretty critical matter. Why is it that Jordan is "Mr FreeBSD" in your eyes? What about the rest of us? mike From owner-freebsd-hackers Fri Nov 14 08:06:42 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id IAA09301 for hackers-outgoing; Fri, 14 Nov 1997 08:06:42 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from word.smith.net.au (client42.securenet.net [205.236.147.58]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id IAA09289 for ; Fri, 14 Nov 1997 08:06:36 -0800 (PST) (envelope-from mike@word.smith.net.au) Received: from word (localhost [127.0.0.1]) by word.smith.net.au (8.8.7/8.8.5) with ESMTP id CAA00340; Sat, 15 Nov 1997 02:07:18 +1030 (CST) Message-Id: <199711141537.CAA00340@word.smith.net.au> X-Mailer: exmh version 2.0zeta 7/24/97 To: Garance A Drosehn cc: hackers@FreeBSD.ORG Subject: Re: Virtual Intel Machines? In-reply-to: Your message of "Thu, 13 Nov 1997 13:09:40 CDT." <9711131809.AA29400@eclipse.its.rpi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 15 Nov 1997 02:07:17 +1030 From: Mike Smith Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > Richard Costine wrote: > > ... I agree that you couldn't do it exactly the way that VM is > > doing it. You would have to emulate everything. [...] This would > > make the emulator much slower than a real pentium, ... > > This would basically be the same as the VirtualPC product that > exists for the PowerMac. There is a portable emulator ('Bochs') that is showing a lot of promise in this regard. mike From owner-freebsd-hackers Fri Nov 14 08:07:43 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id IAA09386 for hackers-outgoing; Fri, 14 Nov 1997 08:07:43 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from dfw-ix10.ix.netcom.com (dfw-ix10.ix.netcom.com [206.214.98.10]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id IAA09381 for ; Fri, 14 Nov 1997 08:07:40 -0800 (PST) (envelope-from a.conrad@ix.netcom.com) Received: (from smap@localhost) by dfw-ix10.ix.netcom.com (8.8.4/8.8.4) id KAA15294 for ; Fri, 14 Nov 1997 10:07:09 -0600 (CST) Received: from socks11d.raleigh.ibm.com(204.146.167.233) by dfw-ix10.ix.netcom.com via smap (V1.3) id rma015268; Fri Nov 14 10:07:04 1997 Message-ID: <346C7705.7AD1@ix.netcom.com> Date: Fri, 14 Nov 1997 11:06:29 -0500 From: Aaron Springer X-Mailer: Mozilla 3.0 (WinNT; I) MIME-Version: 1.0 To: freebsd-hackers@FreeBSD.ORG Subject: subscribe Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk subscribe a.conrad@ix.netcom.com From owner-freebsd-hackers Fri Nov 14 08:08:25 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id IAA09470 for hackers-outgoing; Fri, 14 Nov 1997 08:08:25 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from etinc.com (et-gw-fr1.etinc.com [204.141.244.98]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id IAA09463; Fri, 14 Nov 1997 08:08:22 -0800 (PST) (envelope-from dennis@etinc.com) Received: from dbsys.etinc.com (dbsys.etinc.com [204.141.95.138]) by etinc.com (8.8.3/8.6.9) with SMTP id LAA25237; Fri, 14 Nov 1997 11:12:27 -0500 (EST) Message-Id: <3.0.32.19971114111030.00d344b0@etinc.com> X-Sender: dennis@etinc.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Fri, 14 Nov 1997 11:10:30 -0500 To: freebsd-isp@freebsd.org From: dennis Subject: 8 pci ports Cc: hackers@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Does anyone have info on an ALL pci MB that works with Freebsd 2.2.5R? Something that fits in a standard case (ie NOT passive backplane). Are there any issues with FreeBSD supporting PCI-PCI bridges for such a MB? Dennis From owner-freebsd-hackers Fri Nov 14 08:33:39 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id IAA11151 for hackers-outgoing; Fri, 14 Nov 1997 08:33:39 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from echonyc.com (echonyc.com [198.67.15.2]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id IAA11146 for ; Fri, 14 Nov 1997 08:33:35 -0800 (PST) (envelope-from benedict@echonyc.com) Received: from localhost (benedict@localhost) by echonyc.com (8.8.7/8.8.7) with SMTP id LAA16295; Fri, 14 Nov 1997 11:33:22 -0500 (EST) Date: Fri, 14 Nov 1997 11:33:22 -0500 (EST) From: Snob Art Genre To: Dag-Erling Coidan Smørgrav cc: hackers@FreeBSD.ORG Subject: Re: Ethernet packet generation In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by hub.freebsd.org id IAA11147 Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk I think the book you want is _Unix Network Programming_, by W. Richard Stevens. I have a copy on order, when it arrives I'll see if it has BPF stuff. But chances are it does. On 14 Nov 1997, Dag-Erling Coidan Smørgrav wrote: > Curt Sampson writes: > > On Tue, 11 Nov 1997, Michael Knoll wrote: > > > Is there a way to generate an ethernet packet, with an unsupported protocol > > > through a user level program? > > Yes. Use bpf. > > On a related subject, is there documentation available on how to > program BPF under FreeBSD or other BSD unices? I think I've mostly > figured it out from reading tcpdump and trafshow source as well as the > Usenix'93 BPF paper, but I'd still like docs. > > -- > * Finrod (INTJ) * Unix weenie * dag-erli@ifi.uio.no * cellular +47-92835919 * > RFC1123: "Be liberal in what you accept, and conservative in what you send" > Ben "You have your mind on computers, it seems." From owner-freebsd-hackers Fri Nov 14 09:21:20 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id JAA15088 for hackers-outgoing; Fri, 14 Nov 1997 09:21:20 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id JAA15075 for ; Fri, 14 Nov 1997 09:21:12 -0800 (PST) (envelope-from pem@provedor.com) Received: from alaska.bitline.com.br ([200.245.15.13] (may be forged)) by freefall.freebsd.org (8.8.6/8.8.5) with ESMTP id JAA03266 for ; Fri, 14 Nov 1997 09:18:34 -0800 (PST) Received: from modem3.bitline.com.br ([200.245.15.33]) by alaska.bitline.com.br (Netscape Mail Server v2.02) with SMTP id AAA161 for ; Fri, 14 Nov 1997 15:13:11 -0300 Received: by modem3.bitline.com.br with Microsoft Mail id <01BCF111.045C7F00@modem3.bitline.com.br>; Fri, 14 Nov 1997 15:21:44 -0300 Message-ID: <01BCF111.045C7F00@modem3.bitline.com.br> From: Paulino Michelazzo To: "hackers@FreeBSD.com" Date: Fri, 14 Nov 1997 15:21:41 -0300 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk subscribe hackers@FreeBSD.com From owner-freebsd-hackers Fri Nov 14 09:29:09 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id JAA15821 for hackers-outgoing; Fri, 14 Nov 1997 09:29:09 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from shell.firehouse.net (brian@shell.firehouse.net [209.42.203.45]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id JAA15808 for ; Fri, 14 Nov 1997 09:29:00 -0800 (PST) (envelope-from brian@shell.firehouse.net) Received: from localhost (brian@localhost) by shell.firehouse.net (8.8.5/8.8.5) with SMTP id MAA09912; Fri, 14 Nov 1997 12:28:13 -0500 (EST) Date: Fri, 14 Nov 1997 12:28:10 -0500 (EST) From: Brian Mitchell To: Snob Art Genre cc: Dag-Erling Coidan Smørgrav , hackers@FreeBSD.ORG Subject: Re: Ethernet packet generation In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Fri, 14 Nov 1997, Snob Art Genre wrote: > I think the book you want is _Unix Network Programming_, by W. Richard > Stevens. I have a copy on order, when it arrives I'll see if it has BPF > stuff. But chances are it does. UNP is strictly a sockets book (well -- sockets and tli, i should say; however, nobody cares about tli) > > On a related subject, is there documentation available on how to > > program BPF under FreeBSD or other BSD unices? I think I've mostly > > figured it out from reading tcpdump and trafshow source as well as the > > Usenix'93 BPF paper, but I'd still like docs. From owner-freebsd-hackers Fri Nov 14 09:34:21 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id JAA16246 for hackers-outgoing; Fri, 14 Nov 1997 09:34:21 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from implode.root.com (implode.root.com [198.145.90.17]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id JAA16222 for ; Fri, 14 Nov 1997 09:34:14 -0800 (PST) (envelope-from root@implode.root.com) Received: from implode.root.com (localhost [127.0.0.1]) by implode.root.com (8.8.5/8.8.5) with ESMTP id JAA07171; Fri, 14 Nov 1997 09:35:21 -0800 (PST) Message-Id: <199711141735.JAA07171@implode.root.com> To: bicknell@ufp.org cc: freebsd-hackers@FreeBSD.ORG Subject: Re: AHC / SCSI UPDATE In-reply-to: Your message of "Fri, 14 Nov 1997 10:48:26 EST." <199711141548.KAA17951@ussenterprise.ufp.org> From: David Greenman Reply-To: dg@root.com Date: Fri, 14 Nov 1997 09:35:21 -0800 Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > So, I think there is some issue here with >Micropolis / DAT drives and the Adaptec card/driver. >What I am at a loss to is how to track this down. >How do I go about verifing that it is a driver bug, >or a SCSI incompatability between the Micropolis and >the Adaptec? I have 5 ultra-wide Micropolis drives on wcarchive, which uses Adaptec controllers. I've never had a problem with them. -DG David Greenman Core-team/Principal Architect, The FreeBSD Project From owner-freebsd-hackers Fri Nov 14 09:39:37 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id JAA16908 for hackers-outgoing; Fri, 14 Nov 1997 09:39:37 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from picnic.mat.net (picnic.mat.net [206.246.122.117]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id JAA16900 for ; Fri, 14 Nov 1997 09:39:29 -0800 (PST) (envelope-from chuckr@glue.umd.edu) Received: from localhost (chuckr@localhost) by picnic.mat.net (8.8.7/8.8.5) with SMTP id LAA28723; Fri, 14 Nov 1997 11:35:30 -0500 (EST) X-Authentication-Warning: picnic.mat.net: chuckr owned process doing -bs Date: Fri, 14 Nov 1997 11:35:30 -0500 (EST) From: Chuck Robey X-Sender: chuckr@picnic.mat.net To: Snob Art Genre cc: =?iso-8859-1?Q?Dag-Erling_Coidan_Sm=F8rgrav?= , hackers@FreeBSD.ORG Subject: Re: Ethernet packet generation In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by hub.freebsd.org id JAA16903 Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Fri, 14 Nov 1997, Snob Art Genre wrote: > I think the book you want is _Unix Network Programming_, by W. Richard > Stevens. I have a copy on order, when it arrives I'll see if it has BPF > stuff. But chances are it does. Doesn't, but recommending that book will _never_ get you in trouble. It will show you enough network programming to where you can just read the bpf man page and use that. > > On 14 Nov 1997, Dag-Erling Coidan Smørgrav wrote: > > > Curt Sampson writes: > > > On Tue, 11 Nov 1997, Michael Knoll wrote: > > > > Is there a way to generate an ethernet packet, with an unsupported protocol > > > > through a user level program? > > > Yes. Use bpf. > > > > On a related subject, is there documentation available on how to > > program BPF under FreeBSD or other BSD unices? I think I've mostly > > figured it out from reading tcpdump and trafshow source as well as the > > Usenix'93 BPF paper, but I'd still like docs. > > > > -- > > * Finrod (INTJ) * Unix weenie * dag-erli@ifi.uio.no * cellular +47-92835919 * > > RFC1123: "Be liberal in what you accept, and conservative in what you send" > > > > > > Ben > > "You have your mind on computers, it seems." > > > ----------------------------+----------------------------------------------- Chuck Robey | Interests include any kind of voice or data chuckr@glue.umd.edu | communications topic, C programming, and Unix. 213 Lakeside Drive Apt T-1 | Greenbelt, MD 20770 | I run Journey2 and picnic, both FreeBSD (301) 220-2114 | version 3.0 current -- and great FUN! ----------------------------+----------------------------------------------- From owner-freebsd-hackers Fri Nov 14 09:59:50 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id JAA18468 for hackers-outgoing; Fri, 14 Nov 1997 09:59:50 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from trojanhorse.ml.org (mdean.vip.best.com [206.86.94.101]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id JAA18448 for ; Fri, 14 Nov 1997 09:59:42 -0800 (PST) (envelope-from jamil@trojanhorse.ml.org) Received: from localhost (jamil@localhost) by trojanhorse.ml.org (8.8.8/8.8.5) with SMTP id JAA00861 for ; Fri, 14 Nov 1997 09:59:24 -0800 (PST) Date: Fri, 14 Nov 1997 09:59:24 -0800 (PST) From: "Jamil J. Weatherbee" To: hackers@freebsd.org Subject: Kernel Debugging Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I am trying to track down a driver bug, however I've figured out that using DDB I can get the funtion name and code offset on a panic. But how do I figure out what C line that is in the source? I know how to do this with a user process running gdb, but I am a little confused here as to how you get debugging info into the kernel binary? From owner-freebsd-hackers Fri Nov 14 10:46:58 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id KAA22057 for hackers-outgoing; Fri, 14 Nov 1997 10:46:58 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from smtp03.primenet.com (smtp03.primenet.com [206.165.5.84]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id KAA22051 for ; Fri, 14 Nov 1997 10:46:55 -0800 (PST) (envelope-from tlambert@usr05.primenet.com) Received: (from daemon@localhost) by smtp03.primenet.com (8.8.7/8.8.7) id LAA22515; Fri, 14 Nov 1997 11:41:11 -0700 (MST) Received: from usr05.primenet.com(206.165.6.205) via SMTP by smtp03.primenet.com, id smtpd022490; Fri Nov 14 11:41:03 1997 Received: (from tlambert@localhost) by usr05.primenet.com (8.8.5/8.8.5) id LAA11596; Fri, 14 Nov 1997 11:40:58 -0700 (MST) From: Terry Lambert Message-Id: <199711141840.LAA11596@usr05.primenet.com> Subject: Re: SUID-Directories patch To: nate@mt.sri.com (Nate Williams) Date: Fri, 14 Nov 1997 18:40:57 +0000 (GMT) Cc: tlambert@primenet.com, sos@freebsd.dk, julian@whistle.com, hackers@freebsd.org In-Reply-To: <199711140248.TAA12336@rocky.mt.sri.com> from "Nate Williams" at Nov 13, 97 07:48:09 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > One of the main incentives for commercial entities to give code > > back is offloading of maintenance. You can of course pick and > > choose what you want to take, but the fix seems generically > > useful > > And is in 3.0-current, but doesn't belong in 2.2. On the flip side, > just because a commercial entity donates code doesn't mean we should > take it into the source tree lock/stock/and barrel. Uh... that's what I said. 8-). It's why I pointed out that I thought it wass generically useful (I admit that it's generically useful mostly for administrators of Samba and Appletalk servers, if that's any consolation. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Fri Nov 14 10:52:42 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id KAA22543 for hackers-outgoing; Fri, 14 Nov 1997 10:52:42 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from ns.dsms.com (root@dsms.jsnet.com [207.82.57.142]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id KAA22538 for ; Fri, 14 Nov 1997 10:52:40 -0800 (PST) (envelope-from hbarker@rhiannon.sm.dsms.com) Received: from fs.sm.dsms.com (fs.sm.dsms.com [199.89.215.10]) by ns.dsms.com (8.8.5/8.8.4) with ESMTP id KAA19700; Fri, 14 Nov 1997 10:52:12 -0800 (PST) Received: from rhiannon.sm.dsms.com (rhiannon.sm.dsms.com [199.89.215.11]) by fs.sm.dsms.com (8.8.7/8.8.4sm1) with SMTP id KAA07728; Fri, 14 Nov 1997 10:52:01 -0800 (PST) Received: by rhiannon.sm.dsms.com (NX5.67g/NX3.0S) id AA01103; Fri, 14 Nov 97 10:51:50 -0800 Message-Id: <9711141851.AA01103@rhiannon.sm.dsms.com> Mime-Version: 1.0 (NeXT Mail 4.0 v146.2) Content-Type: multipart/alternative; boundary=NeXT-Mail-2128060069-1 Content-Transfer-Encoding: 7bit In-Reply-To: <199711141548.KAA17951@ussenterprise.ufp.org> X-Nextstep-Mailer: Mail 4.0 (Enhance 2.0b4) Received: by NeXT.Mailer (1.146.2) From: harold barker Hbarker Date: Fri, 14 Nov 97 10:51:48 -0800 To: bicknell@ufp.org Subject: Re: AHC / SCSI UPDATE Cc: freebsd-hackers@freebsd.org Reply-To: hbarker@dsms.com References: <199711141548.KAA17951@ussenterprise.ufp.org> Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk --NeXT-Mail-2128060069-1 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline If the person responsible for the code in question will email me, i will ship/open for login a machine that exibits the broblem. You wrote: > I have now received many replies to my post > about the AHC / SCSI problems. There is an amazing > pattern here. It would seem there are a great many > users of Micropolis Disks and DAT tape drives who > see the exact same problems I see with several adaptec > controllers (2940, 1540, and others). These same > people report no problems with these devices on > Buglogics or NCR controllers. Several people also > report they see no problems on systems with an > Adaptec Segate or Adaptec Quantum pairing. > > So, I think there is some issue here with > Micropolis / DAT drives and the Adaptec card/driver. > What I am at a loss to is how to track this down. > How do I go about verifing that it is a driver bug, > or a SCSI incompatability between the Micropolis and > the Adaptec? > > -- > Leo Bicknell - bicknell@ufp.org > System Administration - Network Design > TMBG List - tmbg-list-request@tmbg.org > --- mailto:hbarker@dsms.com Do or do not, there is no try, Yoda --NeXT-Mail-2128060069-1 Content-Type: text/enriched; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline If the person responsible for the code in question will email me, i will ship/open for login a machine that exibits the broblem. You wrote: > I have now received many replies to my post > about the AHC / SCSI problems. There is an amazing > pattern here. It would seem there are a great many > users of Micropolis Disks and DAT tape drives who > see the exact same problems I see with several adaptec > controllers (2940, 1540, and others). These same > people report no problems with these devices on > Buglogics or NCR controllers. Several people also > report they see no problems on systems with an > Adaptec Segate or Adaptec Quantum pairing. > > So, I think there is some issue here with > Micropolis / DAT drives and the Adaptec card/driver. > What I am at a loss to is how to track this down. > How do I go about verifing that it is a driver bug, > or a SCSI incompatability between the Micropolis and > the Adaptec? > > -- > Leo Bicknell - bicknell@ufp.org > System Administration - Network Design > TMBG List - tmbg-list-request@tmbg.org > --- mailto:hbarker@dsms.com Do or do not, there is no try, Yoda --NeXT-Mail-2128060069-1-- From owner-freebsd-hackers Fri Nov 14 11:08:50 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id LAA23802 for hackers-outgoing; Fri, 14 Nov 1997 11:08:50 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from alpha.xerox.com (alpha.Xerox.COM [13.1.64.93]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id LAA23797 for ; Fri, 14 Nov 1997 11:08:47 -0800 (PST) (envelope-from fenner@parc.xerox.com) Received: from crevenia.parc.xerox.com ([13.2.116.11]) by alpha.xerox.com with SMTP id <54409(5)>; Fri, 14 Nov 1997 11:08:06 PST Received: from localhost by crevenia.parc.xerox.com with SMTP id <177476>; Fri, 14 Nov 1997 11:07:31 -0800 To: Snob Art Genre cc: Dag-Erling Coidan Smørgrav , hackers@freebsd.org Subject: Re: Ethernet packet generation In-reply-to: Your message of "Fri, 14 Nov 97 08:33:22 PST." Date: Fri, 14 Nov 1997 11:07:24 PST From: Bill Fenner Message-Id: <97Nov14.110731pst.177476@crevenia.parc.xerox.com> Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Snob Art Genre wrote: >I think the book you want is _Unix Network Programming_, by W. Richard >Stevens. The original _Unix Network Programming_, published in 1990, doesn't have anything about BPF, designed in 1993 =) However, _Unix Network Programming, Volume 1, Second Edition: Networking APIs: Sockets and XTI_, to be published in 1998, will have a chapter on direct link access. However, in my review copy, it focuses on reading from BPF, and basically says to look at rarpd if you want to know how to write. Bill From owner-freebsd-hackers Fri Nov 14 13:41:35 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id NAA06181 for hackers-outgoing; Fri, 14 Nov 1997 13:41:35 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from trojanhorse.ml.org (mdean.vip.best.com [206.86.94.101]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id NAA06174 for ; Fri, 14 Nov 1997 13:41:32 -0800 (PST) (envelope-from jamil@trojanhorse.ml.org) Received: from localhost (jamil@localhost) by trojanhorse.ml.org (8.8.8/8.8.5) with SMTP id NAA00306 for ; Fri, 14 Nov 1997 13:40:46 -0800 (PST) Date: Fri, 14 Nov 1997 13:40:46 -0800 (PST) From: "Jamil J. Weatherbee" To: hackers@freebsd.org Subject: GDB symbols in 9MB kernel Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Is there a better way than just sticking -g in the CFLAGS= in the kernel Makefile? Also when you drop to panic in DDB, it doesn't show the full path of the file and line number that caused to panic. However about 1/2 the path and the :lineno was there. And I knew what function it was end so there is not problem. What is wrong with DDB, it can't wrap lines? or is there not enough space in the GDB symbol tables for full /usr/src/sys/* file pathname? From owner-freebsd-hackers Fri Nov 14 13:59:20 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id NAA07230 for hackers-outgoing; Fri, 14 Nov 1997 13:59:20 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from etinc.com (et-gw-fr1.etinc.com [204.141.244.98]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id NAA07225 for ; Fri, 14 Nov 1997 13:59:16 -0800 (PST) (envelope-from dennis@etinc.com) Received: from dbsys.etinc.com (dbsys.etinc.com [204.141.95.138]) by etinc.com (8.8.3/8.6.9) with SMTP id RAA27820 for ; Fri, 14 Nov 1997 17:03:22 -0500 (EST) Message-Id: <3.0.32.19971114170123.00d074d0@etinc.com> X-Sender: dennis@etinc.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Fri, 14 Nov 1997 17:01:24 -0500 To: hackers@freebsd.org From: dennis Subject: 256Meg Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Is there a maximum that FreeBSD can support? Dennis From owner-freebsd-hackers Fri Nov 14 14:00:32 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id OAA07374 for hackers-outgoing; Fri, 14 Nov 1997 14:00:32 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from nomis.i-connect.net (nomis.i-Connect.Net [206.190.143.100]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id OAA07369 for ; Fri, 14 Nov 1997 14:00:28 -0800 (PST) (envelope-from shimon@i-connect.net) Received: (qmail 13777 invoked by uid 1000); 14 Nov 1997 20:14:17 -0000 Message-ID: X-Mailer: XFMail 1.2-beta-111097 [p0] on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit MIME-Version: 1.0 Date: Fri, 14 Nov 1997 12:14:17 -0800 (PST) Organization: Atlas Telecom From: Simon Shapiro To: freebsd-hackers@freebsd.org Subject: Bad Winds of Winter - Please Read! Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Please read... I am reading with great interest two debates in this list. I do not have much to add to the facts or technical aspects of these arguments. I am concerned with the escalating tone of the discussion. For a bunch of devoted digital engineers, we sure are losing our minds. We can disagree, argue, but why pull low punches and try to abuse each other? It gains you nothing; We are too far apart physically to enjoy the pain on the other's face. It looses us everything; The desire to work together, the appreciation and respect towards each other. I attribute it all to the changing weather. Gloomness of winter brings the worst in us. Simon From owner-freebsd-hackers Fri Nov 14 14:40:34 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id OAA09760 for hackers-outgoing; Fri, 14 Nov 1997 14:40:34 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from dyson.iquest.net (dyson.iquest.net [198.70.144.127]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id OAA09753 for ; Fri, 14 Nov 1997 14:40:30 -0800 (PST) (envelope-from toor@dyson.iquest.net) Received: (from root@localhost) by dyson.iquest.net (8.8.7/8.8.5) id RAA00469; Fri, 14 Nov 1997 17:40:18 -0500 (EST) From: "John S. Dyson" Message-Id: <199711142240.RAA00469@dyson.iquest.net> Subject: Re: 256Meg In-Reply-To: <3.0.32.19971114170123.00d074d0@etinc.com> from dennis at "Nov 14, 97 05:01:24 pm" To: dennis@etinc.com (dennis) Date: Fri, 14 Nov 1997 17:40:18 -0500 (EST) Cc: hackers@FreeBSD.ORG 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-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk dennis said: > > Is there a maximum that FreeBSD can support? > With very special care and feeding, 2-3 Gbytes should work. 1Gbyte is definitely okay, with a little care and feeding. -- John dyson@freebsd.org jdyson@nc.com From owner-freebsd-hackers Fri Nov 14 15:09:53 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id PAA11252 for hackers-outgoing; Fri, 14 Nov 1997 15:09:53 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from out2.ibm.net (out2.ibm.net [165.87.194.229]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id PAA11245 for ; Fri, 14 Nov 1997 15:09:51 -0800 (PST) (envelope-from mouth@ibm.net) Received: from slip129-37-53-73.ca.us.ibm.net (slip129-37-53-73.ca.us.ibm.net [129.37.53.73]) by out2.ibm.net (8.8.5/8.6.9) with SMTP id XAA197816; Fri, 14 Nov 1997 23:09:33 GMT From: mouth@ibm.net (John Kelly) To: Bruce Evans Cc: hackers@FreeBSD.ORG Subject: Re: Status of 650 UART support Date: Sat, 15 Nov 1997 00:10:47 GMT Message-ID: <346ce808.39734173@smtp-gw01.ny.us.ibm.net> References: <199711141353.AAA01430@godzilla.zeta.org.au> In-Reply-To: <199711141353.AAA01430@godzilla.zeta.org.au> X-Mailer: Forte Agent 1.01/16.397 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by hub.freebsd.org id PAA11247 Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Sat, 15 Nov 1997 00:53:34 +1100, Bruce Evans wrote: >>Edge triggered interrupts are not a factor. > >Yes they are. In what way? John From owner-freebsd-hackers Fri Nov 14 15:30:37 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id PAA12311 for hackers-outgoing; Fri, 14 Nov 1997 15:30:37 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id PAA12306 for ; Fri, 14 Nov 1997 15:30:33 -0800 (PST) (envelope-from julian@whistle.com) Received: (from daemon@localhost) by alpo.whistle.com (8.8.5/8.8.5) id PAA27746; Fri, 14 Nov 1997 15:27:23 -0800 (PST) Received: from UNKNOWN(), claiming to be "current1.whistle.com" via SMTP by alpo.whistle.com, id smtpd027744; Fri Nov 14 15:27:22 1997 Message-ID: <346CDDE4.5656AEC7@whistle.com> Date: Fri, 14 Nov 1997 15:25:24 -0800 From: Julian Elischer Organization: Whistle Communications X-Mailer: Mozilla 3.0Gold (X11; I; FreeBSD 2.2-CURRENT i386) MIME-Version: 1.0 To: "Jordan K. Hubbard" CC: hackers@FreeBSD.ORG Subject: Re: SUID-Directories patch References: <9942.879515612@time.cdrom.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Jordan K. Hubbard wrote: > > > > However, like all projects, we've also matured over the last 4+ years > and with that maturity has come a greater degree of conservatism in > how we do development and in what we expect from any contributor who > seeks to take on a fairly major chunk of development. What might have > been considered reasonably acceptable development practice 4 or even 2 > years ago simply won't fly now that we have a much larger user base > and are under considerable pressure to produce a professional quality > operating system which sets itself well apart from our "competition" > in this arena. ok, then we need another place for 'bleeding edge' then. SMP is anexample of development going on in -current, that defies both your categories below. If we make -curent into -stable, then where does the development go? Development needs to go somewhere where people can test it out and take it for a test-drive. > > This means that any work started in the tree needs to be taken to > completion regardless of the degree of participation by others, > and anything you "sign up for" needs to be something which: > > A) You are capable of completing by yourself, any additional > help being in the "nice to have" category but not strictly > necessary to the project since additional volunteer help > simply cannot be counted on as any kind of given. > > B) Something which *is* completed and in a timely fashion, not > simply left as an "exercise to the reader" as it were. > > I don't mean to speak for Soren, but I do believe that he brought up > DEVFS more as an example of something which violated both A and B than > as an attempt to twist your tail and I can speak without fear of > contradiction when I say that it would simply not be possible for you > to introduce such an unfinished work in today's FreeBSD. Yours is > also hardly the only example of this, others being the aborted ISDN > project (which I brought in, to my later embarassment) or Garrett's > devconf stuff which never fulfulled its promise and was later yanked > out to general bitterness and mutual finger-pointing. The reason devfs is in the tree is because it needs people to USE it to find out what's wrong with it. It was totally broken by a later development.. BDE's slice code. I'm working offline to replace all that stuff. (The BDE slice code) and till that's done devfs is being static but really there is work going on elsewhere. > > We obviously don't want a repeat of those sorts of situations again > and I think that folks have reasonable grounds to worry about *anyone* > who has been responsible for such half-baked assaults on the tree in > the past. It doesn't mean that said person will be judged unfit for > all time, simply that they will have to work just a bit harder in > proving to a skeptical audience that they've fully grasped these new > operating principles and *will* finish anything they start, whether or > not anyone else comes forward to help them with the burden. It's > simply the only way to do things now if we want to avoid a tree full > of good intentions but non-working code. what else have I done that is 'non working?' The boot floppy creation code has worked after every time I've updated it, but you've always been to busy to cut-over to it, so it always gets out of date. Despite the fact that people are always wanting to be able to make boot disks, and that the only way the existing code allows this is in a 'make release' and the other code only needs a 'make world' which is much more acceptable.. So I am interested in your definition of 'responsible for such half-baked assaults' most of the things I have added have been compete working items. > > So, what would probably help greatly at this point in proving to the > skeptics that Julian Elischer, Esq is capable of working within these > new operating parameters would be an acknowlegement on your part that > you understand the A/B principles given above and a further > committment to either removing all traces of DEVFS from the system or > implementing it entirely to spec sometime within the next 60 days. Dont be silly. > > If it also seems like I'm unfairly singling out DEVFS among your other > notable accompishments (and I, for one, rather *like* the divert > socket mechanism - well done, Whistle) then please understand that I'm > underscoring it for the simple reason that it's your current > unfinished opus and something which stands in the way of your > "rehabilition", so to speak. It's also something which simply needs > to either be finished or yanked out, like the other examples I listed > above, and if you're keen to work with us then this is obviously the > first item on the worksheet. It actually works and is in production use in many places. I don't understand why people consider it to be a non-functional item. It works on everthing except in some cases of multiple disks. Of course that doesn't mean that ther isnt stuff to FIX on it. But it'd be nice if some other people even tried to USE it. > > Again, make no mistake. If you or anyone else wishes to develop > something of an experimental nature for FreeBSD then you should by all > means feel free to do so, but *in your own tree*. FreeBSD-current is > a good place to refine and test new mechanisms but not the place to > start placing the initial scaffolding in hopes that a few more > builders will show up and help you erect the supporting members of the > house. The time when that kind of approach was workable is well > behind us now and people simply need to adjust to that fact. On January 1 I will be checking in (with permission) a whole extra branch of the networking code. It will be (it is already) complete and working. it has been in SERIOUS production in 2.2 for most of a year. it requires no edits to external files other than /sys/conf/files yet it really makes most sense for this to go to 2.2.x first, and then migrate to 3.0, because it's been running in 2.2 for 9 months but has never been tested on 3.0. what's the consensus on this? > > Regards, > > Jordan From owner-freebsd-hackers Fri Nov 14 15:30:48 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id PAA12340 for hackers-outgoing; Fri, 14 Nov 1997 15:30:48 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from sumatra.americantv.com (sumatra.americantv.com [207.170.17.37]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id PAA12333 for ; Fri, 14 Nov 1997 15:30:44 -0800 (PST) (envelope-from jlemon@americantv.com) Received: from right.PCS (right.PCS [148.105.10.31]) by sumatra.americantv.com (8.8.5/8.8.5) with ESMTP id RAA11212 for ; Fri, 14 Nov 1997 17:12:46 -0600 (CST) Received: (from jlemon@localhost) by right.PCS (8.6.13/8.6.4) id RAA07326; Fri, 14 Nov 1997 17:12:15 -0600 Message-ID: <19971114171214.44521@right.PCS> Date: Fri, 14 Nov 1997 17:12:15 -0600 From: Jonathan Lemon To: hackers@freebsd.org Subject: FreeBSD Pentium Bug fix (proposed) Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.61.1 Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Alright, I've been watching the debate about the LOCK CMPXCHG8 bug, and decided to take a crack at it. While I believe that for the most case, this is probably just a tempest in a teapot, for some, it probably represents a serious DOS that should be addressed. IMHO, the "take page fault on any trapno < 7" solution is a very ugly hack, but it got me thinking about a better way to solve this. The solution seems to depend on the fact that a page fault has a higher priority than an illegal instruction fault, and thus, if both are posted first, then the page fault takes precedence. This made me think that there might be other faults that also have higher precedence than the illegal instruction fault, and which could be localized to just the #UD handler. It turns out that exceeding the segment limit is one of them. My ``fix'' is to have the IDT descriptor reference a segemnt which has a length of 0. This has the effect of mapping SIGILL into SIGBUS, so that the `cmpxchg8' crash now generates a Bus error. (I didn't bother returning the correct signal; it can probably be added if it is important) This fix works on my machine, takes no overhead, and the only breaks BDE_DEBUGGER, which wants to hoard all the GDT entries for itself. :-) I'd appreciate it if interested parties could try this out and see if it also fixes the problem on other machines. -- Jonathan --------------------------------- cut here --------------------------------- Index: machdep.c =================================================================== RCS file: /tuna/ncvs/src/sys/i386/i386/machdep.c,v retrieving revision 1.270 diff -c -r1.270 machdep.c *************** *** 981,986 **** --- 993,1009 ---- 0, 0, 1, /* default 32 vs 16 bit size */ 1 /* limit granularity (byte/page units)*/ }, + #ifdef CMPXCHG8_BUG + /* GBUG_SEL 11 Invalid Descriptor for CMPXCHG8_BUG */ + { 0x0, /* segment base address */ + 0x0, /* length - none */ + SDT_MEMERA, /* segment type */ + 0, /* segment descriptor priority level */ + 1, /* segment descriptor present */ + 0, 0, + 1, /* default 32 vs 16 bit size */ + 1 /* limit granularity (byte/page units)*/ }, + #endif }; static struct soft_segment_descriptor ldt_segs[] = { *************** *** 1209,1216 **** --- 1232,1244 ---- #endif finishidentcpu(); /* Final stage of CPU initialization */ + #ifdef CMPXCHG8_BUG + setidt(6, &IDTVEC(ill), SDT_SYS386TGT, SEL_KPL, GSEL(GBUG_SEL, SEL_KPL)); + #else setidt(6, &IDTVEC(ill), SDT_SYS386TGT, SEL_KPL, GSEL(GCODE_SEL, SEL_KPL)); + #endif initializecpu(); /* Initialize CPU registers */ + /* Use BIOS values stored in RTC CMOS RAM, since probing * breaks certain 386 AT relics. Index: include/segments.h =================================================================== RCS file: /tuna/ncvs/src/sys/i386/include/segments.h,v retrieving revision 1.17 diff -c -r1.17 segments.h *** segments.h 1997/08/21 06:32:49 1.17 --- segments.h 1997/11/14 22:34:58 *************** *** 215,225 **** --- 215,232 ---- #define GAPMCODE32_SEL 8 /* APM BIOS 32-bit interface (32bit Code) */ #define GAPMCODE16_SEL 9 /* APM BIOS 32-bit interface (16bit Code) */ #define GAPMDATA_SEL 10 /* APM BIOS 32-bit interface (Data) */ + #ifdef CMPXCHG8_BUG + #define GBUG_SEL 11 /* Invalid Descriptor for CMPXCHG8_BUG */ + #endif #ifdef BDE_DEBUGGER #define NGDT 18 /* some of 11-17 are reserved for debugger */ #else + #ifdef CMPXCHG8_BUG + #define NGDT (GBUG_SEL + 1) + #else #define NGDT (GAPMDATA_SEL + 1) + #endif #endif /* From owner-freebsd-hackers Fri Nov 14 15:45:37 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id PAA13305 for hackers-outgoing; Fri, 14 Nov 1997 15:45:37 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from fission (fission.dt.wdc.com [129.253.40.1]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id PAA13293 for ; Fri, 14 Nov 1997 15:45:23 -0800 (PST) (envelope-from kehlet@dt.wdc.com) Received: from cygnus.dt.wdc.com (root@[172.31.1.2]) by fission (8.7.1/8.7.1) with ESMTP id PAA25786 for ; Fri, 14 Nov 1997 15:44:49 -0800 (PST) Received: from daemon.dt.wdc.com (daemon [172.31.10.129]) by cygnus.dt.wdc.com (8.7.1/8.7.1) with ESMTP id PAA17938 for ; Fri, 14 Nov 1997 15:44:43 -0800 (PST) Received: from localhost (kehlet@localhost) by daemon.dt.wdc.com (8.8.5/8.8.5) with SMTP id PAA05795 for ; Fri, 14 Nov 1997 15:45:32 -0800 (PST) X-Authentication-Warning: daemon.dt.wdc.com: kehlet owned process doing -bs Date: Fri, 14 Nov 1997 15:45:32 -0800 (PST) From: Steven Kehlet Reply-To: Steven Kehlet To: hackers@freebsd.org Subject: Re: diskless freebsd, can't mount local msdos disk (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi, I have some more information about the problem I've been having mounting local disks while booting diskless. I've been trying to trace through the kernel code, and it looks to me like the code that checks all the slices on each local disk isn't called if mounting root over NFS (nfs_mountroot()). I was trying to tackle this problem by going through the code both starting both from "the top" (main() in kern/init_main.c) and from "the bottom" (check_port() in i386/isa/diskslice_machdep.c--where the slices are detected and displayed with "boot -v"), but it got a little complicated and I could never quite meet up ;-). Hats off to the folks who understand this code better... I hope to join you someday.. ;-) I'm thinking the folks who wrote the nfs_mountroot() stuff figured since you're booting diskless, you wouldn't want to access any local hard drives. Hopefully I could just pop in the code that initializes local drives into the nfs_mountroot() stuff... and it will all just work perfectly the first time... ;-) Thanks for taking the time to think about this and to give me any suggestions if you can. Steve Here's the tail of dmesg (boot -v) for a non-diskless machine (not mine). Note the disks and slices are detected and displayed: BIOS Geometries: 0:026a7f3f 0..618=619 cylinders, 0..127=128 heads, 1..63=63 sectors 0 accounted for Device configuration finished. Considering FFS root f/s. configure() finished. bpf: tun0 attached bpf: tun1 attached bpf: lo0 attached ccd0: Concatenated disk driver IP packet filtering initialized, divert disabled, unlimited logging > wd0s1: type 0x6, start 3967488, end = 4999679, size 1032192 > wd0s1: C/H/S end 618/127/63 (4991615) != end 4999679: invalid > wd0s2: type 0xa5, start 1, end = 2322431, size 2322431 : OK > wd0s3: type 0x4d, start 2322432, end = 3967487, size 1645056 : OK > sd0s1: type 0xa5, start 261990, end = 4446800, size 4184811 : OK > sd0s2: type 0x6, start 1, end = 261989, size 261989 : OK > sd1s1: type 0xa5, start 1, end = 4446800, size 4446800 : OK Here's the tail of my diskless dmesg. No disks or slices: BIOS Geometries: 0:03117f3f 0..785=786 cylinders, 0..127=128 heads, 1..63=63 sectors 0 accounted for Device configuration finished. Considering BOOTP NFS root f/s. configure() finished. bpf: lo0 attached bootpc_init: using network interface 'vx0' Bootpc testing starting bootpc hw address is 0:60:8:32:cb:96 My ip address is 172.31.10.16 Server ip address is 172.31.2.30 Gateway ip address is 0.0.0.0 Server name is bootes boot file is /kernel Subnet mask is 255.255.0.0 Router is 172.31.1.254 rootfs is 172.31.6.4:/diskless/FreeBSD/rootfs/mockingbird Hostname is mockingbird swapfs is 172.31.6.4:/diskless/FreeBSD/swapfs md_lookup_swap: Swap size is 65536 KB NFS SWAP: 172.31.6.4:/diskless/FreeBSD/swapfs NFS ROOT: 172.31.6.4:/diskless/FreeBSD/rootfs/mockingbird Note there's no listing of each drive and each slice. Also, the OS doesn't give me an accurate "fdisk" reading (of course, since it never initialized the disk): # fdisk fdisk: Can't get disk parameters on /dev/rwd0; supplying dummy ones ******* Working on device /dev/rwd0 ******* parameters extracted from in-core disklabel are: cylinders=1 heads=1 sectors/track=1 (1 blks/cyl) parameters to be used for BIOS calculations are: cylinders=1 heads=1 sectors/track=1 (1 blks/cyl) fdisk: Invalid fdisk partition table found Warning: BIOS sector numbering starts with sector 1 Information from DOS bootblock is: The data for partition 0 is: The data for partition 1 is: The data for partition 2 is: The data for partition 3 is: sysid 165,(FreeBSD/NetBSD/386BSD) start 1, size 0 (0 Meg), flag 80 beg: cyl 1/ sector 1/ head 0; end: cyl 0/ sector 0/ head 0 And also, a hexdump doesn't find anything (again, of course): # hd -v /dev/rwd0 # Thanks... Steve On Thu, 13 Nov 1997, Brian Campbell wrote: > Date: Thu, 13 Nov 1997 20:41:50 -0500 > From: Brian Campbell > To: Steven Kehlet > Subject: Re: diskless freebsd, can't mount local msdos disk > > On Thu, Nov 13, 1997 at 05:12:17PM -0800, Steven Kehlet wrote: > > Thanks for replying. I tried booting with -v (I've included it all). > > Do you see anything wrong? For one thing, I don't see it detecting > > any slices... > > No ... can't see anything "wrong". But I think there's some stuff > missing at the end. Perhaps your boot messages are too long to be > "remembered" by dmesg. > > I've included the tail of my dmesg after yours. The last several > lines indicate the drives and the parititions on them. > > In any event, even if your dmesg doesn't show you want you want, > fdisk (as suggested by someone else) will. For me (where my DOS > partition is wd0s1) `fdisk wd0` gives: > > ******* Working on device /dev/rwd0 ******* > parameters extracted from in-core disklabel are: > cylinders=620 heads=128 sectors/track=63 (8064 blks/cyl) > > parameters to be used for BIOS calculations are: > cylinders=620 heads=128 sectors/track=63 (8064 blks/cyl) > > Media sector size is 512 > Warning: BIOS sector numbering starts with sector 1 > Information from DOS bootblock is: > The data for partition 1 is: > sysid 6,(Primary 'big' DOS (> 32MB)) > start 3967488, size 1032192 (504 Meg), flag 0 > beg: cyl 492/ sector 1/ head 0; > end: cyl 618/ sector 63/ head 127 > The data for partition 2 is: > sysid 165,(FreeBSD/NetBSD/386BSD) > start 1, size 2322431 (1133 Meg), flag 80 > beg: cyl 0/ sector 2/ head 0; > end: cyl 287/ sector 63/ head 127 > The data for partition 3 is: > sysid 77,(unknown) > start 2322432, size 1645056 (803 Meg), flag 0 > beg: cyl 288/ sector 1/ head 0; > end: cyl 491/ sector 63/ head 127 > The data for partition 4 is: > > > > mockingbird:/home/kehlet-> dmesg > > Copyright (c) 1992-1997 FreeBSD Inc. > > Copyright (c) 1982, 1986, 1989, 1991, 1993 > > The Regents of the University of California. All rights > > reserved. > > > > FreeBSD 2.2.5-RELEASE #0: Thu Nov 13 14:26:21 PST 1997 > > kehlet@daemon:/usr/src/sys.2.2.5/compile/DISKLESS > > Calibrating clock(s) ... i586 clock: 166378926 Hz, i8254 clock: > > 1193436 Hz > > CLK_USE_I8254_CALIBRATION not specified - using default frequency > > CLK_USE_I586_CALIBRATION not specified - using old calibration method > > CPU: Pentium (166.34-MHz 586-class CPU) > > Origin = "GenuineIntel" Id = 0x52c Stepping=12 > > Features=0x1bf > > real memory = 33554432 (32768K bytes) > > Physical memory chunk(s): > > 0x00001000 - 0x0009efff, 647168 bytes (158 pages) > > 0x00209000 - 0x01ffdfff, 31412224 bytes (7669 pages) > > avail memory = 30547968 (29832K bytes) > > pcibus_setup(1): mode 1 addr port (0x0cf8) is 0x80000058 > > pcibus_setup(1a): mode1res=0x80000000 (0x80000000) > > pcibus_check: device 0 is there (id=71008086) > > Probing for devices on PCI bus 0: > > configuration mode 1 allows 32 devices. > > chip0 rev 1 > > on pci0:0 > > chip1 rev 1 > > on pci0:7:0 > > pci0:7:1: Intel Corporation, device=0x7111, class=storage (ide) [no > > driver assigned] > > map(20): io(fc90) > > pci0:7:2: Intel Corporation, device=0x7112, class=0x0c, subclass=0x03 > > int d irq 11 [no driver assigned] > > map(20): io(fca0) > > chip2 rev > > 1 on pci0:7:3 > > vga0 rev 154 int a irq ?? on pci0:8 > > vx0 <3COM 3C905 Fast Etherlink XL PCI> rev 0 int a irq 5 on pci0:13 > > mapreg[10] type=1 addr=0000fcc0 size=0040. > > mii[*mii*]: disable 'auto select' with DOS util! address > > 00:60:08:32:cb:96 > > bpf: vx0 attached > > vga1 rev 1 int a irq 9 on pci0:14 > > mapreg[10] type=0 addr=fedfc000 size=4000. > > mapreg[14] type=0 addr=fe000000 size=800000. > > pci0: uses 8404992 bytes of memory from fe000000 upto fedfffff. > > pci0: uses 64 bytes of I/O space from fcc0 upto fcff. > > Probing for devices on the ISA bus: > > sc0: the current keyboard controller command byte 0047 > > kbdio: DIAGNOSE status:0055 > > kbdio: TEST_KBD_PORT status:0000 > > kbdio: RESET_KBD return code:00fa > > kbdio: RESET_KBD status:00aa > > sc0 at 0x60-0x6f irq 1 on motherboard > > sc0: BIOS video mode:3 > > sc0: VGA registers upon power-up > > 50 18 10 00 10 00 03 00 02 67 60 4f 50 83 55 81 > > bf 1f 00 4f 0d 0e 00 00 03 70 9c 8e 8f 28 1f 96 > > b9 a3 ff 00 01 02 03 04 05 14 07 38 39 3a 3b 3c > > 3d 3e 3f 0c 00 0f 08 00 00 00 00 00 10 0e 00 ff > > sc0: video mode:24 > > sc0: VGA registers for mode:24 > > 50 18 10 00 10 00 03 00 02 67 60 4f 50 83 55 81 > > bf 1f 00 4f 0d 0e 00 00 00 00 9c 8e 8f 28 1f 96 > > b9 a3 ff 00 01 02 03 04 05 14 07 38 39 3a 3b 3c > > 3d 3e 3f 0c 00 0f 08 00 00 00 00 00 10 0e 00 ff > > sc0: VGA color <16 virtual consoles, flags=0x0> > > ed0 not found at 0x300 > > sio0 at 0x3f8-0x3ff irq 4 on isa > > sio0: type 16550A > > sio1 not found at 0x2f8 > > lpt0 at 0x378-0x37f irq 7 on isa > > lpt0: Interrupt-driven port > > lp0: TCP/IP capable interface > > bpf: lp0 attached > > psm0: current command byte:0047 > > kbdio: TEST_AUX_PORT status:0000 > > kbdio: RESET_AUX return code:00fa > > kbdio: RESET_AUX status:00aa > > kbdio: RESET_AUX ID:0000 > > psm0: status after reset 00 02 64 > > psm: status 00 00 64 (get_mouse_buttons) > > psm0: status 00 02 64 > > psm0 at 0x60-0x64 irq 12 on motherboard > > psm0: device ID 0, 2 buttons > > fdc0 at 0x3f0-0x3f7 irq 6 drq 2 on isa > > fdc0: FIFO enabled, 8 bytes threshold > > fd0: 1.44MB 3.5in > > wdc0 at 0x1f0-0x1f7 irq 14 on isa > > wdc0: unit 0 (wd0): > > wd0: 3098MB (6346368 sectors), 6296 cyls, 16 heads, 63 S/T, 512 B/S > > ep0 not found at 0x300 > > npx0 on motherboard > > npx0: INT 16 interface > > imasks: bio c0004040, tty c0031092, net c0020020 > > BIOS Geometries: > > 0:03117f3f 0..785=786 cylinders, 0..127=128 heads, 1..63=63 sectors > > 0 accounted for > > Device configuration finished. > > Considering BOOTP NFS root f/s. > > configure() finished. > > bpf: lo0 attached > > bootpc_init: using network interface 'vx0' > > Bootpc testing starting > > bootpc hw address is 0:60:8:32:cb:96 > > My ip address is 172.31.10.16 > > Server ip address is 172.31.2.30 > > Gateway ip address is 0.0.0.0 > > Server name is bootes > > boot file is /kernel > > Subnet mask is 255.255.0.0 > > Router is 172.31.1.254 > > rootfs is 172.31.6.4:/diskless/FreeBSD/rootfs/mockingbird > > Hostname is mockingbird > > swapfs is 172.31.6.4:/diskless/FreeBSD/swapfs > > md_lookup_swap: Swap size is 65536 KB > > NFS SWAP: 172.31.6.4:/diskless/FreeBSD/swapfs > > NFS ROOT: 172.31.6.4:/diskless/FreeBSD/rootfs/mockingbird > > > > > > On Thu, 13 Nov 1997, Brian Campbell wrote: > > > On Thu, Nov 13, 1997 at 02:50:17PM -0800, Steven Kehlet wrote: > > > > I'm booting FreeBSD 2.2.5 diskless with the kernel's BOOTP features. > > > > It detects the local hardware just fine (e.g. ethernet (obviously), > > > > hard drive, floppy, etc), but if I try to mount the local msdos disk > > > > like I would on a non-diskless station, it doesn't work. Floppy > > > > operations (mounting, hexdumping, fdwriting) seem to work, however. > > > > Anyone know what's wrong, or have any suggestions what I could do? If > > > > I can give any more information, please let me know. > > > > > > > > wdc0 at 0x1f0-0x1f7 irq 14 on isa > > > > wdc0: unit 0 (wd0): > > > > wd0: 3098MB (6346368 sectors), 6296 cyls, 16 heads, 63 S/T, 512 B/S > > > > > > > > # foreach i (1 2 3 4) > > > > ? mount_msdos /dev/wd0s$i /mnt > > > > ? end > > > > mount_msdos: /dev/wd0s1: Invalid argument > > > > mount_msdos: /dev/wd0s2: Invalid argument > > > > mount_msdos: /dev/wd0s3: Invalid argument > > > > mount_msdos: /dev/wd0s4: Invalid argument > > > > > > If you boot -v it'll tell you what types the detected partitions > > > on wd0 are ... > > > > > > Your DOS partition(s) will likely be type 0x6 > > psm0: status after reset 00 02 64 > psm: status d0 03 c8 (get_mouse_buttons) > psm0: status 00 02 64 > psm0 at 0x60-0x64 irq 12 on motherboard > psm0: device ID 0, 3 buttons > fdc0 at 0x3f0-0x3f7 irq 6 drq 2 on isa > fdc0: FIFO enabled, 8 bytes threshold > fd0: 1.44MB 3.5in > wdc0 at 0x1f0-0x1f7 irq 14 flags 0xa0ffa0ff on isa > wdc0: unit 0 (wd0): , DMA, 32-bit, multi-block-16 > wd0: 2441MB (4999680 sectors), 4960 cyls, 16 heads, 63 S/T, 512 B/S > wd0: ATA INQUIRE valid = 0003, dmamword = 0407, apio = 0003, udma = 0000 > wdc1 at 0x170-0x177 irq 15 flags 0xa0ffa0ff on isa > wdc1: unit 0 (atapi): , removable, dma, iordy > wcd0: 1376Kb/sec, 128Kb cache, audio play, 256 volume levels, ejectable tray > wcd0: medium type unknown, unlocked > npx0 on motherboard > npx0: INT 16 interface > sb0 at 0x220 irq 5 drq 1 on isa > sb0: > sbxvi0 at 0x220 drq 5 on isa > sbxvi0: > sbmidi0 at 0x300 on isa > > opl0 at 0x388 on isa > opl0: > gus0 at 0x240 irq 7 drq 7 flags 0x3 on isa > gus0: > gus0: > mpu0 at 0x330 irq 9 drq 0 on isa > mpu0: > apm0 on isa > apm: found APM BIOS version 1.1 > imasks: bio c000c840, tty c003101a, net c0020000 > BIOS Geometries: > 0:026a7f3f 0..618=619 cylinders, 0..127=128 heads, 1..63=63 sectors > 0 accounted for > Device configuration finished. > Considering FFS root f/s. > configure() finished. > bpf: tun0 attached > bpf: tun1 attached > bpf: lo0 attached > ccd0: Concatenated disk driver > IP packet filtering initialized, divert disabled, unlimited logging > wd0s1: type 0x6, start 3967488, end = 4999679, size 1032192 > wd0s1: C/H/S end 618/127/63 (4991615) != end 4999679: invalid > wd0s2: type 0xa5, start 1, end = 2322431, size 2322431 : OK > wd0s3: type 0x4d, start 2322432, end = 3967487, size 1645056 : OK > sd0s1: type 0xa5, start 261990, end = 4446800, size 4184811 : OK > sd0s2: type 0x6, start 1, end = 261989, size 261989 : OK > sd1s1: type 0xa5, start 1, end = 4446800, size 4446800 : OK > Full dmesg: > > mockingbird:/home/kehlet-> dmesg > > Copyright (c) 1992-1997 FreeBSD Inc. > > Copyright (c) 1982, 1986, 1989, 1991, 1993 > > The Regents of the University of California. All rights > > reserved. > > > > FreeBSD 2.2.5-RELEASE #0: Thu Nov 13 14:26:21 PST 1997 > > kehlet@daemon:/usr/src/sys.2.2.5/compile/DISKLESS > > Calibrating clock(s) ... i586 clock: 166378926 Hz, i8254 clock: > > 1193436 Hz > > CLK_USE_I8254_CALIBRATION not specified - using default frequency > > CLK_USE_I586_CALIBRATION not specified - using old calibration method > > CPU: Pentium (166.34-MHz 586-class CPU) > > Origin = "GenuineIntel" Id = 0x52c Stepping=12 > > Features=0x1bf > > real memory = 33554432 (32768K bytes) > > Physical memory chunk(s): > > 0x00001000 - 0x0009efff, 647168 bytes (158 pages) > > 0x00209000 - 0x01ffdfff, 31412224 bytes (7669 pages) > > avail memory = 30547968 (29832K bytes) > > pcibus_setup(1): mode 1 addr port (0x0cf8) is 0x80000058 > > pcibus_setup(1a): mode1res=0x80000000 (0x80000000) > > pcibus_check: device 0 is there (id=71008086) > > Probing for devices on PCI bus 0: > > configuration mode 1 allows 32 devices. > > chip0 rev 1 > > on pci0:0 > > chip1 rev 1 > > on pci0:7:0 > > pci0:7:1: Intel Corporation, device=0x7111, class=storage (ide) [no > > driver assigned] > > map(20): io(fc90) > > pci0:7:2: Intel Corporation, device=0x7112, class=0x0c, subclass=0x03 > > int d irq 11 [no driver assigned] > > map(20): io(fca0) > > chip2 rev > > 1 on pci0:7:3 > > vga0 rev 154 int a irq ?? on pci0:8 > > vx0 <3COM 3C905 Fast Etherlink XL PCI> rev 0 int a irq 5 on pci0:13 > > mapreg[10] type=1 addr=0000fcc0 size=0040. > > mii[*mii*]: disable 'auto select' with DOS util! address > > 00:60:08:32:cb:96 > > bpf: vx0 attached > > vga1 rev 1 int a irq 9 on pci0:14 > > mapreg[10] type=0 addr=fedfc000 size=4000. > > mapreg[14] type=0 addr=fe000000 size=800000. > > pci0: uses 8404992 bytes of memory from fe000000 upto fedfffff. > > pci0: uses 64 bytes of I/O space from fcc0 upto fcff. > > Probing for devices on the ISA bus: > > sc0: the current keyboard controller command byte 0047 > > kbdio: DIAGNOSE status:0055 > > kbdio: TEST_KBD_PORT status:0000 > > kbdio: RESET_KBD return code:00fa > > kbdio: RESET_KBD status:00aa > > sc0 at 0x60-0x6f irq 1 on motherboard > > sc0: BIOS video mode:3 > > sc0: VGA registers upon power-up > > 50 18 10 00 10 00 03 00 02 67 60 4f 50 83 55 81 > > bf 1f 00 4f 0d 0e 00 00 03 70 9c 8e 8f 28 1f 96 > > b9 a3 ff 00 01 02 03 04 05 14 07 38 39 3a 3b 3c > > 3d 3e 3f 0c 00 0f 08 00 00 00 00 00 10 0e 00 ff > > sc0: video mode:24 > > sc0: VGA registers for mode:24 > > 50 18 10 00 10 00 03 00 02 67 60 4f 50 83 55 81 > > bf 1f 00 4f 0d 0e 00 00 00 00 9c 8e 8f 28 1f 96 > > b9 a3 ff 00 01 02 03 04 05 14 07 38 39 3a 3b 3c > > 3d 3e 3f 0c 00 0f 08 00 00 00 00 00 10 0e 00 ff > > sc0: VGA color <16 virtual consoles, flags=0x0> > > ed0 not found at 0x300 > > sio0 at 0x3f8-0x3ff irq 4 on isa > > sio0: type 16550A > > sio1 not found at 0x2f8 > > lpt0 at 0x378-0x37f irq 7 on isa > > lpt0: Interrupt-driven port > > lp0: TCP/IP capable interface > > bpf: lp0 attached > > psm0: current command byte:0047 > > kbdio: TEST_AUX_PORT status:0000 > > kbdio: RESET_AUX return code:00fa > > kbdio: RESET_AUX status:00aa > > kbdio: RESET_AUX ID:0000 > > psm0: status after reset 00 02 64 > > psm: status 00 00 64 (get_mouse_buttons) > > psm0: status 00 02 64 > > psm0 at 0x60-0x64 irq 12 on motherboard > > psm0: device ID 0, 2 buttons > > fdc0 at 0x3f0-0x3f7 irq 6 drq 2 on isa > > fdc0: FIFO enabled, 8 bytes threshold > > fd0: 1.44MB 3.5in > > wdc0 at 0x1f0-0x1f7 irq 14 on isa > > wdc0: unit 0 (wd0): > > wd0: 3098MB (6346368 sectors), 6296 cyls, 16 heads, 63 S/T, 512 B/S > > ep0 not found at 0x300 > > npx0 on motherboard > > npx0: INT 16 interface > > imasks: bio c0004040, tty c0031092, net c0020020 > > BIOS Geometries: > > 0:03117f3f 0..785=786 cylinders, 0..127=128 heads, 1..63=63 sectors > > 0 accounted for > > Device configuration finished. > > Considering BOOTP NFS root f/s. > > configure() finished. > > bpf: lo0 attached > > bootpc_init: using network interface 'vx0' > > Bootpc testing starting > > bootpc hw address is 0:60:8:32:cb:96 > > My ip address is 172.31.10.16 > > Server ip address is 172.31.2.30 > > Gateway ip address is 0.0.0.0 > > Server name is bootes > > boot file is /kernel > > Subnet mask is 255.255.0.0 > > Router is 172.31.1.254 > > rootfs is 172.31.6.4:/diskless/FreeBSD/rootfs/mockingbird > > Hostname is mockingbird > > swapfs is 172.31.6.4:/diskless/FreeBSD/swapfs > > md_lookup_swap: Swap size is 65536 KB > > NFS SWAP: 172.31.6.4:/diskless/FreeBSD/swapfs > > NFS ROOT: 172.31.6.4:/diskless/FreeBSD/rootfs/mockingbird > > From owner-freebsd-hackers Fri Nov 14 15:47:22 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id PAA13393 for hackers-outgoing; Fri, 14 Nov 1997 15:47:22 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from smtp03.primenet.com (smtp03.primenet.com [206.165.5.84]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id PAA13385 for ; Fri, 14 Nov 1997 15:47:11 -0800 (PST) (envelope-from tlambert@usr06.primenet.com) Received: (from daemon@localhost) by smtp03.primenet.com (8.8.7/8.8.7) id QAA26247; Fri, 14 Nov 1997 16:47:08 -0700 (MST) Received: from usr06.primenet.com(206.165.6.206) via SMTP by smtp03.primenet.com, id smtpd026233; Fri Nov 14 16:47:04 1997 Received: (from tlambert@localhost) by usr06.primenet.com (8.8.5/8.8.5) id QAA17421; Fri, 14 Nov 1997 16:46:59 -0700 (MST) From: Terry Lambert Message-Id: <199711142346.QAA17421@usr06.primenet.com> Subject: Re: SUID-Directories patch To: sos@freebsd.dk Date: Fri, 14 Nov 1997 23:46:59 +0000 (GMT) Cc: nate@mt.sri.com, tlambert@primenet.com, julian@whistle.com, hackers@FreeBSD.ORG In-Reply-To: <199711140836.JAA01286@sos.freebsd.dk> from "S?ren Schmidt" at Nov 14, 97 09:36:38 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > > One of the main incentives for commercial entities to give code > > > back is offloading of maintenance. You can of course pick and > > > choose what you want to take, but the fix seems generically > > > useful > > > > And is in 3.0-current, but doesn't belong in 2.2. On the flip side, > > just because a commercial entity donates code doesn't mean we should > > take it into the source tree lock/stock/and barrel. > > Exactly. I wont accecpt that YOU guys offloads YOUR maintenance on > our backs, we have had PLENTY of that allready, thankyou... Well, I've already answered this in context of a reply to Nate's message that you quote here. But you are furthering a misunderstanding. The "maintenance" that is being "offloaded" is not the code rot that normally occurs, but the possibility that the FreeBSD code tree will try to implement something similar because of similar (but not identical) needs. One good example is the IP firewall code, for which there were two versions for a long time. Another example (from your own experience) is the syscons/pccons code dichotomy. Many people spent a lot of bandwith beating on Dennis from ET Inc. for *not* donating his commercial code to FreeBSD (the sync serial drivers which could be applied to hardware not sold by Dennis). When a commercial organization donates code, they are "paid" in the FreeBSD code not changing to unusability out from under them. At the same time, FreeBSD is "paid" by getting code written by paid professional programmers that they might not otherwise have gotten. For example, a lot of the work John Dyson has done has been paid for by his employer -- another example is the invaluable work Jordan did as an employee of Walnut Creek CDROM. Both of these were instances of code contributed to the FreeBSD project in avoidance of the effort of tracking and maintaining an interface between an official FreeBSD source tree, and a source tree with commercial components. Linux has the GPL to encourage commercial vendors to donate back; FreeBSD has a lot of hackers pushing fast enough that a commercial vendor might have to spend all his time tracking instead of doing new work, after they've diverged far enough from the main line. Both are incentive. But neither *require* that the party being donated to accept the donation, unless they feel it's generally useful. My post was only intended to argue two points: o First, that we are seeing one of FreeBSD's *only* methods of incentivizing commercial donations in action, and it should be encouraged if at all possible so FreeBSD can point at it and say "see, you don't need GPL for the system to work". This helps FreeBSD's legitimacy, especially when it comes to *excellent* developers, like Larry McVoy, who have been burned by it not working, and have turned to GPL as a refuge more than as a political statement. If the system can work without GPL, then those people who view GPL as a necessary evil will be more likely to dual-license their code. o Second, that I think the change is genuinely useful to some audiences, even if I don't think it's as general as, say, a console driver. For those audiences (Samba and Appletalk server administrators, and perhaps PCNFS server administrators), this helps FreeBSD technically. I *personally* think it's a net win for FreeBSD, whether it helps a particular commercial user or not. If I *personally* thought it was bad for FreeBSD, I'd argue against it... whether it hurt a particular commercial vendor, or not. > Now kill this thread, and get back to work... Happy to... so long as no one yells "300 Joules! ...Clear!" ;-). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Fri Nov 14 15:52:50 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id PAA13788 for hackers-outgoing; Fri, 14 Nov 1997 15:52:50 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from out1.ibm.net (out1.ibm.net [165.87.194.252]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id PAA13779 for ; Fri, 14 Nov 1997 15:52:47 -0800 (PST) (envelope-from mouth@ibm.net) Received: from slip129-37-53-73.ca.us.ibm.net (slip129-37-53-73.ca.us.ibm.net [129.37.53.73]) by out1.ibm.net (8.8.5/8.6.9) with SMTP id XAA75254; Fri, 14 Nov 1997 23:52:35 GMT From: mouth@ibm.net (John Kelly) To: Bruce Evans Cc: hackers@FreeBSD.ORG Subject: Re: Status of 650 UART support Date: Sat, 15 Nov 1997 00:53:49 GMT Message-ID: <346eea54.40322529@smtp-gw01.ny.us.ibm.net> References: <199711141353.AAA01430@godzilla.zeta.org.au> In-Reply-To: <199711141353.AAA01430@godzilla.zeta.org.au> X-Mailer: Forte Agent 1.01/16.397 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by hub.freebsd.org id PAA13780 Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Sat, 15 Nov 1997 00:53:34 +1100, Bruce Evans wrote: >interrupts need to be reenabled on the polled ports as soon as everything > in them is polled Only if your clock interrupt is too slow. But I wanted to change that and leave the UART in polled mode after draining it. Only after 5 polls with no data would I switch it back to interrupt mode. Then the serial ISR could ignore all ports being polled. >The next clock interrupt is an average of 5 msec away Would it be feasible to tick the clock every 1ms to schedule UART polling and on every fifth tick run the usual kernel scheduling? John From owner-freebsd-hackers Fri Nov 14 15:57:24 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id PAA13974 for hackers-outgoing; Fri, 14 Nov 1997 15:57:24 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from smtp03.primenet.com (smtp03.primenet.com [206.165.5.84]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id PAA13969 for ; Fri, 14 Nov 1997 15:57:22 -0800 (PST) (envelope-from tlambert@usr06.primenet.com) Received: (from daemon@localhost) by smtp03.primenet.com (8.8.7/8.8.7) id QAA27463; Fri, 14 Nov 1997 16:57:17 -0700 (MST) Received: from usr06.primenet.com(206.165.6.206) via SMTP by smtp03.primenet.com, id smtpd027451; Fri Nov 14 16:57:08 1997 Received: (from tlambert@localhost) by usr06.primenet.com (8.8.5/8.8.5) id QAA18184; Fri, 14 Nov 1997 16:57:08 -0700 (MST) From: Terry Lambert Message-Id: <199711142357.QAA18184@usr06.primenet.com> Subject: Re: Need some input re: named pipes To: toor@dyson.iquest.net (John S. Dyson) Date: Fri, 14 Nov 1997 23:57:07 +0000 (GMT) Cc: hackers@FreeBSD.ORG In-Reply-To: <199711141434.JAA01323@dyson.iquest.net> from "John S. Dyson" at Nov 14, 97 09:33:59 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > Could anyone give me some feedback on an idea of making our pipe code (fast) > used for named pipes? I don't think that it is hard to implement, but > do people usually use the socket ioctl's for named pipes? Many of those > would go-away when moving to the pipe code. Wouldn't this break X? Yes, I know I'm the one who's always trying to kill struct fileops... Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Fri Nov 14 16:10:12 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id QAA14692 for hackers-outgoing; Fri, 14 Nov 1997 16:10:12 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from ns.mt.sri.com (sri-gw.MT.net [206.127.105.141]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id QAA14680 for ; Fri, 14 Nov 1997 16:10:08 -0800 (PST) (envelope-from nate@rocky.mt.sri.com) Received: from rocky.mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.8.8/8.8.8) with ESMTP id RAA00413; Fri, 14 Nov 1997 17:10:00 -0700 (MST) (envelope-from nate@rocky.mt.sri.com) Received: (from nate@localhost) by rocky.mt.sri.com (8.7.5/8.7.3) id RAA17065; Fri, 14 Nov 1997 17:09:59 -0700 (MST) Date: Fri, 14 Nov 1997 17:09:59 -0700 (MST) Message-Id: <199711150009.RAA17065@rocky.mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Julian Elischer Cc: "Jordan K. Hubbard" , hackers@freebsd.org Subject: Re: SUID-Directories patch In-Reply-To: <346CDDE4.5656AEC7@whistle.com> References: <9942.879515612@time.cdrom.com> <346CDDE4.5656AEC7@whistle.com> X-Mailer: VM 6.29 under 19.15 XEmacs Lucid Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > On January 1 I will be checking in (with permission) a whole extra > branch of the networking code. > It will be (it is already) complete and working. > it has been in SERIOUS production in 2.2 for most of a year. It has been working in the Whistle version of 2.2, which is different from FreeBSD 2.2. > it requires no edits to external files other than > /sys/conf/files yet it really makes most sense for this to go to > 2.2.x first, and then migrate to 3.0, because it's been running in 2.2 > for 9 months but has never been tested on 3.0. > > what's the consensus on this? Bring it into 3.0. The 2.* branch is only for bugfixes and security problems. No 'new functionality' should ever be brought directly into 2.2. Nate From owner-freebsd-hackers Fri Nov 14 16:23:39 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id QAA15573 for hackers-outgoing; Fri, 14 Nov 1997 16:23:39 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from smtp04.primenet.com (smtp04.primenet.com [206.165.5.85]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id QAA15558 for ; Fri, 14 Nov 1997 16:23:32 -0800 (PST) (envelope-from tlambert@usr06.primenet.com) Received: (from daemon@localhost) by smtp04.primenet.com (8.8.7/8.8.7) id RAA05506; Fri, 14 Nov 1997 17:23:07 -0700 (MST) Received: from usr06.primenet.com(206.165.6.206) via SMTP by smtp04.primenet.com, id smtpd005496; Fri Nov 14 17:22:57 1997 Received: (from tlambert@localhost) by usr06.primenet.com (8.8.5/8.8.5) id RAA20050; Fri, 14 Nov 1997 17:22:44 -0700 (MST) From: Terry Lambert Message-Id: <199711150022.RAA20050@usr06.primenet.com> Subject: Re: Where to commit patches? [MS Joliet Ext. to CD9660] To: keith@email.gcn.net.tw Date: Sat, 15 Nov 1997 00:22:43 +0000 (GMT) Cc: Eugeny.Kuzakov@lab321.ru, hackers@FreeBSD.ORG In-Reply-To: <19971114235317.02926@email.gcn.net.tw> from "Keith Jang" at Nov 14, 97 11:53:17 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > I've searched the spec of Joliet for weeks, and the only thing I could > find is the Linux patch. Therefore I must steal from it. :> If you are an MSDN level II developer,or you have purchased the DDK, then there is a "Joliet.doc" file in "DDK\DOCS\". I *was* an MSDN II developer at my previous empolyer, but now I have purchased the "Visual Interdev" ``upgrade'' for my Borland C++, and the DDK. If you have specific questions, I can give you answers, but my license precludes posting the documents (for example). I *thought* the Joliet stuff had actually been disclosed at one time. > Joliet uses Supplementary Volume Descriptor to store its data. SVD has > the same format as Primary Volume Descriptor, except for byte position > 8 & 89-120. The first three bytes starting from the 89th identifies a > Joliet CD. The first two must be 0x25 & 0x2f. The third represents the > level, 0x40, 0x43, 0x45 for level 1, 2, 3, respectively. There is also a volume recognition sequence. You must go to the last non-audio session of a multisession CD to perform the recognition. > The extent of Root Directory Record in SVD is different from that in PVD. > So that the old code follows PVD->root, and obtains filenames like xxx~1. > The patch just follows SVD->root to get the right one. This is the DOS Namespace post collision name. Windows 95 does not do late-binding of short names for long file names; they eat the not inconsiderable overhead up front instead of when a supplementary reference occurs. If you had a VFAT/VFAT32 writeable FS that you were working on, I'd be happy to describe the collision algorithm in detail. ;-). > The filename in directory record are stored as unicode. Since I have no > idea of unicode, for now just strip null bytes. Are there any *free* > unicode resources on the net? Real Unicode handling requires that you abstract the cn_pnbuf contents; this is a lot of work on namei(), every FS's VOP_READIR, VOP_ABORTOP, VOP_RENAME, etc., etc.. To fake Unicode handling, it's pretty simple: treat the character strings as 16 bit characters (ie: pretend the FreeBSD port of GCC had gotten wchar_t right). Then do something like: FAKE_unicode_to_iso8859_1( int length, unsigned short *from_unicode, unsigned char *to_8859_1) { register int i; for( i = length -1 ; i >= 0; i--) to_8859_1[ i] = (unsigned char)(from_unicode[ i] & 0x00ff); to_8859_1[ i] = 0; } This assumes that from_unicode and to_8859_1 point to preallocated buffers, and the string in from_unicode is length characters long and there are at least length+1 bytes in to_8859_1. This works because the values 0x0000 to 0x00ff of the Unicode standard are ISO 8859-1 characters (8859-1 is a subset of ISO 10646 -- Unicode). You may want to look at both the Plan9 released code at research.att.com and the Unicode pages at taligent.com. Also see the newsgroup comp.standard.internat. > That's all I know about Joliet. :) This patch is only sufficient to read > long filenames. Maybe I'll add an option to make it treat U/L cases the > same. It does not utilize the three Joliet levels, neither the unicode > support (I'm not sure whether unicode is supported in FreeBSD.) The files are case insensitive on lookup, case sensitive on storage (just like the Mac and OS/2) FS's. I would not make that work at this time -- the proper place to handle that is in another VFS layer stacked on top and grabbing the directory operations. The big problem is that pattern matching in user space (like UNIX does) is inherently case sensitive, even if the VOP_LOOKUP can be made case insensitive. Plus, any code you write for case folding ought to be portable to the other FS types that require it. Assuming you use a filebox or browser picklist, etc., the files will always be referenced in the correct case, 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-hackers Fri Nov 14 16:38:26 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id QAA16551 for hackers-outgoing; Fri, 14 Nov 1997 16:38:26 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from time.cdrom.com (root@time.cdrom.com [204.216.27.226]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id QAA16542 for ; Fri, 14 Nov 1997 16:38:22 -0800 (PST) (envelope-from jkh@time.cdrom.com) Received: from time.cdrom.com (jkh@localhost.cdrom.com [127.0.0.1]) by time.cdrom.com (8.8.7/8.6.9) with ESMTP id QAA12931; Fri, 14 Nov 1997 16:38:19 -0800 (PST) To: Simon Shapiro cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Bad Winds of Winter - Please Read! In-reply-to: Your message of "Fri, 14 Nov 1997 12:14:17 PST." Date: Fri, 14 Nov 1997 16:38:18 -0800 Message-ID: <12926.879554298@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Simon, it's already over. You're late! :) From owner-freebsd-hackers Fri Nov 14 16:44:38 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id QAA16968 for hackers-outgoing; Fri, 14 Nov 1997 16:44:38 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from zippy.dyn.ml.org (seoul-210.ppp.hooked.net [206.169.228.210]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id QAA16963 for ; Fri, 14 Nov 1997 16:44:33 -0800 (PST) (envelope-from garbanzo@hooked.net) Received: from localhost (garbanzo@localhost) by zippy.dyn.ml.org (8.8.7/8.8.7) with SMTP id QAA01747; Fri, 14 Nov 1997 16:45:02 -0800 (PST) X-Authentication-Warning: zippy.dyn.ml.org: garbanzo owned process doing -bs Date: Fri, 14 Nov 1997 16:45:02 -0800 (PST) From: Alex X-Sender: garbanzo@zippy.dyn.ml.org To: "Jamil J. Weatherbee" cc: hackers@FreeBSD.ORG Subject: Re: GDB symbols in 9MB kernel In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Fri, 14 Nov 1997, Jamil J. Weatherbee wrote: > > Is there a better way than just sticking -g in the > CFLAGS= in the kernel Makefile? config -g - alex From owner-freebsd-hackers Fri Nov 14 16:47:08 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id QAA17082 for hackers-outgoing; Fri, 14 Nov 1997 16:47:08 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from time.cdrom.com (root@time.cdrom.com [204.216.27.226]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id QAA17077 for ; Fri, 14 Nov 1997 16:47:03 -0800 (PST) (envelope-from jkh@time.cdrom.com) Received: from time.cdrom.com (jkh@localhost.cdrom.com [127.0.0.1]) by time.cdrom.com (8.8.7/8.6.9) with ESMTP id QAA12978; Fri, 14 Nov 1997 16:47:04 -0800 (PST) To: Julian Elischer cc: hackers@FreeBSD.ORG Subject: Re: SUID-Directories patch In-reply-to: Your message of "Fri, 14 Nov 1997 15:25:24 PST." <346CDDE4.5656AEC7@whistle.com> Date: Fri, 14 Nov 1997 16:47:04 -0800 Message-ID: <12974.879554824@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > ok, then we need another place for 'bleeding edge' then. Your personal tree. That's where truly bleeding edge stuff should go, period (substitute "you" for whomever "you" are - I'm talking generally here). > SMP is anexample of development going on in -current, that > defies both your categories below. If we make -curent into No, actually SMP is a good example as it was done in its own completely different repository for a long time until it was "done" enough to work generally. And it does. I and many other people are running it now and if DEVFS worked half as well as SMP we wouldn't be counting it as an unfinished opus. > -stable, then where does the development go? Development needs > to go somewhere where people can test it out and take it for a > test-drive. I think we have fundamentally different definitions of "test drive." When I think of something worthy of test driving in -current, I think of a situation like "this is done, guys, and I've been testing it for awhile with a small team of private BETA testers. Now I just need a little wider testing to make sure it works as well for everyone else as it does for me and my gang." I don't think "this is something I would like everyone to help me with so that we can finish it and make it work" qualifies. > The reason devfs is in the tree is because it needs people to USE it > to find out what's wrong with it. It was totally broken by a later Julian, I'm sorry, but the DEVFS code has never worked well enough for general use and every time someone has run a /dev mounted with it they've either missed a number of important devices or experienced a system crash in short order. This is code which was integrated prematurely, not code in need of "testing" by the definition I stated earlier. > I'm working offline to replace all that stuff. (The BDE slice code) Good. > > So, what would probably help greatly at this point in proving to the > > skeptics that Julian Elischer, Esq is capable of working within these > > new operating parameters would be an acknowlegement on your part that > > you understand the A/B principles given above and a further > > committment to either removing all traces of DEVFS from the system or > > implementing it entirely to spec sometime within the next 60 days. > > Dont be silly. I'm not being silly. If you don't do precisely as requested above, someone else will be removing DEVFS from the tree in short order. This is not a threat, this is a statement of fact and something we've been discussing in core for awhile now. > It actually works and is in production use in many places. > I don't understand why people consider it to be a non-functional item. > It works on everthing except in some cases of multiple disks. I'm not even going to touch that statement since I think it stands as a perfect example of what I'm talking about, all by itself. Jordan From owner-freebsd-hackers Fri Nov 14 17:05:58 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id RAA18140 for hackers-outgoing; Fri, 14 Nov 1997 17:05:58 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from misery.sdf.com (misery.sdf.com [204.244.210.193]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id RAA18134 for ; Fri, 14 Nov 1997 17:05:53 -0800 (PST) (envelope-from tom@sdf.com) Received: from tom by misery.sdf.com with smtp (Exim 1.73 #1) id 0xWWZR-0003nS-00; Fri, 14 Nov 1997 16:58:45 -0800 Date: Fri, 14 Nov 1997 16:58:39 -0800 (PST) From: Tom To: dennis cc: hackers@freebsd.org Subject: Re: 256Meg In-Reply-To: <3.0.32.19971114170123.00d074d0@etinc.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Fri, 14 Nov 1997, dennis wrote: > Is there a maximum that FreeBSD can support? > > Dennis What? Filesystems? RAM? Something else? RAM... no problem. I'm running two 256MB RAM servers now. Tom From owner-freebsd-hackers Fri Nov 14 17:15:45 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id RAA18618 for hackers-outgoing; Fri, 14 Nov 1997 17:15:45 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from picnic.mat.net (picnic.mat.net [206.246.122.117]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id RAA18612 for ; Fri, 14 Nov 1997 17:15:38 -0800 (PST) (envelope-from chuckr@glue.umd.edu) Received: from localhost (chuckr@localhost) by picnic.mat.net (8.8.7/8.8.5) with SMTP id TAA02779; Fri, 14 Nov 1997 19:11:03 -0500 (EST) X-Authentication-Warning: picnic.mat.net: chuckr owned process doing -bs Date: Fri, 14 Nov 1997 19:11:02 -0500 (EST) From: Chuck Robey X-Sender: chuckr@picnic.mat.net To: Julian Elischer cc: "Jordan K. Hubbard" , hackers@FreeBSD.ORG Subject: Re: SUID-Directories patch In-Reply-To: <346CDDE4.5656AEC7@whistle.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Fri, 14 Nov 1997, Julian Elischer wrote: > Jordan K. Hubbard wrote: > > > > > > > > However, like all projects, we've also matured over the last 4+ years > > and with that maturity has come a greater degree of conservatism in > > how we do development and in what we expect from any contributor who > > seeks to take on a fairly major chunk of development. What might have > > been considered reasonably acceptable development practice 4 or even 2 > > years ago simply won't fly now that we have a much larger user base > > and are under considerable pressure to produce a professional quality > > operating system which sets itself well apart from our "competition" > > in this arena. > > ok, then we need another place for 'bleeding edge' then. > SMP is anexample of development going on in -current, that > defies both your categories below. If we make -curent into > -stable, then where does the development go? Development needs > to go somewhere where people can test it out and take it for a > test-drive. I'm not sure that hackers is the right place for this (current would IMO be more correct) but I have to say that I feel Julian has a strong point, current _is_ the place for experimentation. It would be different if the code that he's bringing in was non-functional, but it isn't. The argument that it was a small part of the whole, and non-functional even in part, could only be made about the older DEVFS, not the SUID stuff, so that argument isn't valid. Julian hasn't been one to show up on the list and howl when someone accuses him of not being perfect ... I see reasoned discussion (so far). Asking someone to experiment ONLY on their own machines means, since their universe is much smaller, it really doesn't get the last stage of testing at all. Is what he's asking to remain something that is very fragmentary? No. Is it is going in without prior testing? No, not according to Julian's statements. Is it going to break something else in the tree? I don't _think_ so, although if someone brings something like that up, it would sure be a major strike against it. The only thing I've heard so far is someone saying they don't need the feature. Seeing as I don't know ANYBODY who uses all the features, well, that didn't hit me as a major complaint. How about we let it sit in the tree a month, and revisit it either at the end of the month, or at the first real, functional complaint? Julian gets his testing done for him (current users will surely complain if it breaks something) and in a month, if you still feel the same way, I think Julian could take it out, and would, if opinion still goes that way. I mean, what's the downside of this? Current isn't stable, that's one of it's major attractions to me. Let's not become too conservative ... ----------------------------+----------------------------------------------- Chuck Robey | Interests include any kind of voice or data chuckr@glue.umd.edu | communications topic, C programming, and Unix. 213 Lakeside Drive Apt T-1 | Greenbelt, MD 20770 | I run Journey2 and picnic, both FreeBSD (301) 220-2114 | version 3.0 current -- and great FUN! ----------------------------+----------------------------------------------- From owner-freebsd-hackers Fri Nov 14 17:21:29 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id RAA19047 for hackers-outgoing; Fri, 14 Nov 1997 17:21:29 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from time.cdrom.com (root@time.cdrom.com [204.216.27.226]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id RAA19042 for ; Fri, 14 Nov 1997 17:21:25 -0800 (PST) (envelope-from jkh@time.cdrom.com) Received: from time.cdrom.com (jkh@localhost.cdrom.com [127.0.0.1]) by time.cdrom.com (8.8.7/8.6.9) with ESMTP id RAA13191; Fri, 14 Nov 1997 17:21:09 -0800 (PST) To: Chuck Robey cc: Julian Elischer , hackers@FreeBSD.ORG Subject: Re: SUID-Directories patch In-reply-to: Your message of "Fri, 14 Nov 1997 19:11:02 EST." Date: Fri, 14 Nov 1997 17:21:09 -0800 Message-ID: <13187.879556869@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > I'm not sure that hackers is the right place for this (current would IMO > be more correct) but I have to say that I feel Julian has a strong point, > current _is_ the place for experimentation. It would be different if the I think that I already made my points about this about as well as I'm ever going to make them, so I'll say no more on the topic of what constitutes proper "experimentation" in -current. If you want my rebuttal to this, read my original message again. :) > code that he's bringing in was non-functional, but it isn't. The argument > that it was a small part of the whole, and non-functional even in part, > could only be made about the older DEVFS, not the SUID stuff, so that But I wasn't talking about the SUID stuff. > Is what he's asking to remain something that is very fragmentary? No. > Is it is going in without prior testing? No, not according to Julian's What Julian considers "prior testing" and what we in core consider prior testing are fundamentally at odds here. That's all I need to say. > I mean, what's the downside of this? Current isn't stable, that's one of > it's major attractions to me. Let's not become too conservative ... If anything, history will show that we haven't been nearly conservative enough. Jordan From owner-freebsd-hackers Fri Nov 14 17:22:20 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id RAA19138 for hackers-outgoing; Fri, 14 Nov 1997 17:22:20 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from ppp6558.on.bellglobal.com (ppp6441.on.bellglobal.com [206.172.208.33]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id RAA19105 for ; Fri, 14 Nov 1997 17:22:04 -0800 (PST) (envelope-from tim@ppp6558.on.bellglobal.com) Received: from localhost (tim@localhost) by ppp6558.on.bellglobal.com (8.8.7/8.8.7) with SMTP id UAA06472; Fri, 14 Nov 1997 20:12:46 -0500 (EST) (envelope-from tim@ppp6558.on.bellglobal.com) Date: Fri, 14 Nov 1997 20:12:45 -0500 (EST) From: Tim Vanderhoek Reply-To: ac199@hwcn.org To: "Jamil J. Weatherbee" cc: "Chuck O'Donnell" , freebsd-hackers@FreeBSD.ORG Subject: Re: /dev/speaker In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Thu, 13 Nov 1997, Jamil J. Weatherbee wrote: > printf "\a" > /dev/console with appropriate privs, of course. -- tIM...HOEk OPTIMIZATION: the process of using many one-letter variables names hoping that the resultant code will run faster. From owner-freebsd-hackers Fri Nov 14 17:36:45 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id RAA20055 for hackers-outgoing; Fri, 14 Nov 1997 17:36:45 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from picnic.mat.net (picnic.mat.net [206.246.122.117]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id RAA20050 for ; Fri, 14 Nov 1997 17:36:40 -0800 (PST) (envelope-from chuckr@glue.umd.edu) Received: from localhost (chuckr@localhost) by picnic.mat.net (8.8.7/8.8.5) with SMTP id TAA05754; Fri, 14 Nov 1997 19:32:35 -0500 (EST) X-Authentication-Warning: picnic.mat.net: chuckr owned process doing -bs Date: Fri, 14 Nov 1997 19:32:34 -0500 (EST) From: Chuck Robey X-Sender: chuckr@picnic.mat.net To: "Jordan K. Hubbard" cc: Julian Elischer , hackers@FreeBSD.ORG Subject: Re: SUID-Directories patch In-Reply-To: <13187.879556869@time.cdrom.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Fri, 14 Nov 1997, Jordan K. Hubbard wrote: > > I'm not sure that hackers is the right place for this (current would IMO > > be more correct) but I have to say that I feel Julian has a strong point, > > current _is_ the place for experimentation. It would be different if the > > I think that I already made my points about this about as well as I'm > ever going to make them, so I'll say no more on the topic of what > constitutes proper "experimentation" in -current. If you want my > rebuttal to this, read my original message again. :) > > > code that he's bringing in was non-functional, but it isn't. The argument > > that it was a small part of the whole, and non-functional even in part, > > could only be made about the older DEVFS, not the SUID stuff, so that > > But I wasn't talking about the SUID stuff. I just saw his SUID stuff go thru ... I thought that was what you guys were referring to. Sorry. > > > Is what he's asking to remain something that is very fragmentary? No. > > Is it is going in without prior testing? No, not according to Julian's > > What Julian considers "prior testing" and what we in core consider > prior testing are fundamentally at odds here. That's all I need to > say. > > > I mean, what's the downside of this? Current isn't stable, that's one of > > it's major attractions to me. Let's not become too conservative ... > > If anything, history will show that we haven't been nearly > conservative enough. > > Jordan > > ----------------------------+----------------------------------------------- Chuck Robey | Interests include any kind of voice or data chuckr@glue.umd.edu | communications topic, C programming, and Unix. 213 Lakeside Drive Apt T-1 | Greenbelt, MD 20770 | I run Journey2 and picnic, both FreeBSD (301) 220-2114 | version 3.0 current -- and great FUN! ----------------------------+----------------------------------------------- From owner-freebsd-hackers Fri Nov 14 17:59:12 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id RAA21578 for hackers-outgoing; Fri, 14 Nov 1997 17:59:12 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from hwcn.org (main.hwcn.org [199.212.94.65]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id RAA21559 for ; Fri, 14 Nov 1997 17:59:01 -0800 (PST) (envelope-from hoek@hwcn.org) Received: from james.freenet.hamilton.on.ca (ac199@james.hwcn.org [199.212.94.66]) by hwcn.org (8.8.7/8.8.7) with ESMTP id UAA13656; Fri, 14 Nov 1997 20:59:36 -0500 (EST) Received: from localhost (ac199@localhost) by james.freenet.hamilton.on.ca (8.8.7/8.8.7) with SMTP id VAA27056; Fri, 14 Nov 1997 21:00:10 -0500 (EST) X-Authentication-Warning: james.freenet.hamilton.on.ca: ac199 owned process doing -bs Date: Fri, 14 Nov 1997 21:00:09 -0500 (EST) From: Tim Vanderhoek X-Sender: ac199@james.freenet.hamilton.on.ca Reply-To: freebsd-chat@FreeBSD.ORG To: "Jordan K. Hubbard" cc: Simon Shapiro , freebsd-hackers@FreeBSD.ORG Subject: Re: Bad Winds of Winter - Please Read! In-Reply-To: <12926.879554298@time.cdrom.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk [hint: further replies-to -chat] On Fri, 14 Nov 1997, Jordan K. Hubbard wrote: > Simon, it's already over. You're late! :) No, we had a fairly reasonable storm today (although only a meager ~10cm accumulation), and I can definitely still see a few flakes coming down. :-) -- Outnumbered? Maybe. Outspoken? Never! tIM...HOEk From owner-freebsd-hackers Fri Nov 14 18:18:47 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id SAA22558 for hackers-outgoing; Fri, 14 Nov 1997 18:18:47 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from dyson.iquest.net (dyson.iquest.net [198.70.144.127]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id SAA22553 for ; Fri, 14 Nov 1997 18:18:40 -0800 (PST) (envelope-from toor@dyson.iquest.net) Received: (from root@localhost) by dyson.iquest.net (8.8.7/8.8.5) id VAA01287; Fri, 14 Nov 1997 21:18:31 -0500 (EST) From: "John S. Dyson" Message-Id: <199711150218.VAA01287@dyson.iquest.net> Subject: Re: Need some input re: named pipes In-Reply-To: <199711142357.QAA18184@usr06.primenet.com> from Terry Lambert at "Nov 14, 97 11:57:07 pm" To: tlambert@primenet.com (Terry Lambert) Date: Fri, 14 Nov 1997 21:18:31 -0500 (EST) Cc: hackers@FreeBSD.ORG 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-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Terry Lambert said: > > Could anyone give me some feedback on an idea of making our pipe code (fast) > > used for named pipes? I don't think that it is hard to implement, but > > do people usually use the socket ioctl's for named pipes? Many of those > > would go-away when moving to the pipe code. > > > Wouldn't this break X? > > Yes, I know I'm the one who's always trying to kill struct fileops... > Well, that is one of the reasons that I wanted to look at doing the change. Of course, one of the major goals would be X compatibility. If it means that some ioctls or somesuch had to be implemented, so be it... -- John dyson@freebsd.org jdyson@nc.com From owner-freebsd-hackers Fri Nov 14 18:38:51 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id SAA23578 for hackers-outgoing; Fri, 14 Nov 1997 18:38:51 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from time.cdrom.com (root@time.cdrom.com [204.216.27.226]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id SAA23571 for ; Fri, 14 Nov 1997 18:38:47 -0800 (PST) (envelope-from jkh@time.cdrom.com) Received: from time.cdrom.com (jkh@localhost.cdrom.com [127.0.0.1]) by time.cdrom.com (8.8.7/8.6.9) with ESMTP id SAA13786 for ; Fri, 14 Nov 1997 18:38:50 -0800 (PST) To: hackers@freebsd.org Subject: Just FYI [F00F bug] Date: Fri, 14 Nov 1997 18:38:49 -0800 Message-ID: <13781.879561529@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I was contacted today by Sunil Saxena and Woody Cohn at Intel who apologised for the aformentioned bug and promised to provide any and all information required to fix it. Apparently, they called me some 3 days ago at Walnut Creek CDROM but the folks there didn't think to pass the message on (grr!). They've been working flat-out on this bug over there and are treating it very seriously indeed. In any case, this is just FYI and Intel *is* quite interested in our having a fix for this problem. I gave them Bruce Evans' email address and asked them to supply the details directly to him as he's our resident IDT expert and I think we've burned up more than enough bandwidth in -hackers over this issue as it is. Please don't pester myself or Bruce for more details on this unless you want to see a solution delayed even more - when a fix hits the tree, you'll know all about it. Thanks to those who have also been forwarding us details on this but really, please, you can also stop forwarding the same bugtrax advisory to us over and over again now (current count: 8 copies) since we HAVE seen it and you aren't doing us any favors by continuing to post it to the various FreeBSD mailing lists! :-( I also think that this whole episode starkly illustrates the need for greater patience on the part of our users. We've been literally inundated over the past 3 days with questions, flames and well-intentioned but wholly redundant forwards on the topic and all other work has more or less ground to a halt under the onslaught. If this project is to remain an effective development body, it needs to be given a little more time and space to work than it has been given in this particular instance. Don't kill the golden goose here, folks! We're only human, and spending hours wading through such mailstorms only detracts from the time we might have spent more constructively working on the problem. Each such incident also results in more core members unsubscribing from -hackers and, unless you want to eventually see our mailing lists populated only by users and none of the developers, please spare a thought for our overflowing mailboxes before you hit that "send" button. Thanks. Jordan From owner-freebsd-hackers Fri Nov 14 18:54:17 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id SAA24378 for hackers-outgoing; Fri, 14 Nov 1997 18:54:17 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from ns.mt.sri.com (sri-gw.MT.net [206.127.105.141]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id SAA24369 for ; Fri, 14 Nov 1997 18:54:14 -0800 (PST) (envelope-from nate@rocky.mt.sri.com) Received: from rocky.mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.8.8/8.8.8) with ESMTP id TAA01436; Fri, 14 Nov 1997 19:54:07 -0700 (MST) (envelope-from nate@rocky.mt.sri.com) Received: (from nate@localhost) by rocky.mt.sri.com (8.7.5/8.7.3) id TAA17745; Fri, 14 Nov 1997 19:54:04 -0700 (MST) Date: Fri, 14 Nov 1997 19:54:04 -0700 (MST) Message-Id: <199711150254.TAA17745@rocky.mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Chuck Robey Cc: Julian Elischer , "Jordan K. Hubbard" , hackers@freebsd.org Subject: Re: SUID-Directories patch In-Reply-To: References: <346CDDE4.5656AEC7@whistle.com> X-Mailer: VM 6.29 under 19.15 XEmacs Lucid Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk [ Where does experimental code go? ] > I'm not sure that hackers is the right place for this (current would IMO > be more correct) but I have to say that I feel Julian has a strong point, > current _is_ the place for experimentation. It would be different if the > code that he's bringing in was non-functional, but it isn't. The code isn't non-functional, but it is dys-functional. I think that's the crux of Jordan argument, that it isn't up to the users/developers of -current to flesh out/finish the work. Or even 'macro-debug' it. Hopefully by the time the code is in -current it's 'mostly working', with bugs that can only be found by large-scale testing, and not missing large pieces of necessary functionality. Saying it works 'most of the time, except when you have more than one disk' is like saying the code works on all machines except those machines who run X, which it doesn't work on. Nate From owner-freebsd-hackers Fri Nov 14 19:02:02 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id TAA24909 for hackers-outgoing; Fri, 14 Nov 1997 19:02:02 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from time.cdrom.com (root@time.cdrom.com [204.216.27.226]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id TAA24903 for ; Fri, 14 Nov 1997 19:01:59 -0800 (PST) (envelope-from jkh@time.cdrom.com) Received: from time.cdrom.com (jkh@localhost.cdrom.com [127.0.0.1]) by time.cdrom.com (8.8.7/8.6.9) with ESMTP id TAA14191; Fri, 14 Nov 1997 19:01:41 -0800 (PST) To: Nate Williams cc: Chuck Robey , Julian Elischer , hackers@freebsd.org Subject: Re: SUID-Directories patch In-reply-to: Your message of "Fri, 14 Nov 1997 19:54:04 MST." <199711150254.TAA17745@rocky.mt.sri.com> Date: Fri, 14 Nov 1997 19:01:41 -0800 Message-ID: <14187.879562901@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > The code isn't non-functional, but it is dys-functional. I think that's > the crux of Jordan argument, that it isn't up to the users/developers of > -current to flesh out/finish the work. Or even 'macro-debug' it. Precisely. History has also shown us that this invariably doesn't even work, said code having a far greater tendency to rot rather than get fixed. Did not Julian himself start his defense of DEVFS with a comment that he'd gotten none of the help he'd hoped for? I rest my case. :) Jordan From owner-freebsd-hackers Fri Nov 14 19:03:44 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id TAA25006 for hackers-outgoing; Fri, 14 Nov 1997 19:03:44 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id TAA24999 for ; Fri, 14 Nov 1997 19:03:41 -0800 (PST) (envelope-from bde@zeta.org.au) Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.7/8.6.9) id NAA25462; Sat, 15 Nov 1997 13:53:51 +1100 Date: Sat, 15 Nov 1997 13:53:51 +1100 From: Bruce Evans Message-Id: <199711150253.NAA25462@godzilla.zeta.org.au> To: bde@zeta.org.au, mouth@ibm.net Subject: Re: Status of 650 UART support Cc: hackers@FreeBSD.ORG Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >>interrupts need to be reenabled on the polled ports as soon as = >everything >> in them is polled > >Only if your clock interrupt is too slow. But I wanted to change that It is too slow (10 msec). >Would it be feasible to tick the clock every 1ms to schedule UART >polling and on every fifth tick run the usual kernel scheduling? There would be no point interrupting 10 times as often just to poll twice as often. Polling every 1ms tick would be often enough for there to be almost no need for serial input interrupts or auto RTS flow control at 115200 bps (since 14 character times is 1.216ms which is slightly more than the polling interval). OTOH, the polling routines can't be guaranteed to run (at low priority) every 1ms - even the current 10ms can't be guaranteed - so auto RTS flow control would still be necessary. I think this would be a pessimization in practice. First you waste cycles processing more clock interrupts, then you waste more by polling more often. Bruce From owner-freebsd-hackers Fri Nov 14 19:08:00 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id TAA25146 for hackers-outgoing; Fri, 14 Nov 1997 19:08:00 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from dyson.iquest.net (dyson.iquest.net [198.70.144.127]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id TAA25133; Fri, 14 Nov 1997 19:07:55 -0800 (PST) (envelope-from toor@dyson.iquest.net) Received: (from root@localhost) by dyson.iquest.net (8.8.7/8.8.5) id WAA01607; Fri, 14 Nov 1997 22:07:53 -0500 (EST) From: "John S. Dyson" Message-Id: <199711150307.WAA01607@dyson.iquest.net> Subject: Re: Bad Winds of Winter - Please Read! In-Reply-To: from Tim Vanderhoek at "Nov 14, 97 09:00:09 pm" To: freebsd-chat@FreeBSD.ORG Date: Fri, 14 Nov 1997 22:07:53 -0500 (EST) Cc: jkh@time.cdrom.com, Shimon@i-connect.net, freebsd-hackers@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-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Tim Vanderhoek said: > [hint: further replies-to -chat] > > On Fri, 14 Nov 1997, Jordan K. Hubbard wrote: > > > Simon, it's already over. You're late! :) > > No, we had a fairly reasonable storm today (although only a > meager ~10cm accumulation), and I can definitely still see a few > flakes coming down. > I just landed in Indianapolis last night (from the Bay area), in a twin engine plane, with approx 5cm of slush. We had approx 10-12cm of snow approx 1 month early, and a VERY VERY unpleasant surprise, after being at work (NCI) this week. If Indy wasn't home and very strong emotional ties, I would move to the Bay area in a second!!! At least there isn't snow out where I work, until you get up to at least 1K meters or so. -- John dyson@freebsd.org jdyson@nc.com From owner-freebsd-hackers Fri Nov 14 19:30:00 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id TAA25939 for hackers-outgoing; Fri, 14 Nov 1997 19:30:00 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from mom.hooked.net (root@mom.hooked.net [206.80.6.10]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id TAA25934 for ; Fri, 14 Nov 1997 19:29:58 -0800 (PST) (envelope-from garbanzo@hooked.net) Received: from fish.hooked.net (garbanzo@fish.hooked.net [206.80.6.48]) by mom.hooked.net (8.8.5/8.8.5) with SMTP id TAA25177; Fri, 14 Nov 1997 19:29:45 -0800 (PST) Date: Sat, 15 Nov 1997 03:29:54 +0000 (GMT) From: Alex To: "Jordan K. Hubbard" cc: hackers@FreeBSD.ORG Subject: Re: Just FYI [F00F bug] In-Reply-To: <13781.879561529@time.cdrom.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk [snip] > Please don't pester myself or Bruce for more details on this unless > you want to see a solution delayed even more - when a fix hits the > tree, you'll know all about it. Thanks to those who have also been > forwarding us details on this but really, please, you can also stop > forwarding the same bugtrax advisory to us over and over again now > (current count: 8 copies) since we HAVE seen it and you aren't doing > us any favors by continuing to post it to the various FreeBSD mailing > lists! :-( At least, there was an article posted to BugTraq as to why the two previous atempts at fixing the bug weren't worth using. > Each such incident also results in more core members unsubscribing > from -hackers and, unless you want to eventually see our mailing lists > populated only by users and none of the developers, please spare a > thought for our overflowing mailboxes before you hit that "send" > button. - alex From owner-freebsd-hackers Fri Nov 14 19:33:20 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id TAA26140 for hackers-outgoing; Fri, 14 Nov 1997 19:33:20 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from mailhost.Ipsilon.COM (mailhost.ipsilon.com [205.226.5.12]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id TAA26134 for ; Fri, 14 Nov 1997 19:33:18 -0800 (PST) (envelope-from jre@ipsilon.com) Received: from radio.ipsilon.com (radio.Ipsilon.COM [205.226.28.3]) by mailhost.Ipsilon.COM (8.6.11/8.6.10) with SMTP id TAA05410; Fri, 14 Nov 1997 19:32:15 -0800 Message-ID: <346D17BA.1B37ADEA@ipsilon.com> Date: Fri, 14 Nov 1997 19:32:10 -0800 From: Joe Eykholt Organization: Ipsilon Software Engineering X-Mailer: Mozilla 3.01Gold (X11; I; FreeBSD 2.1.0-RELEASE i386) MIME-Version: 1.0 To: jlemon@americantv.com CC: freebsd-hackers@freebsd.org Subject: Re: FreeBSD Pentium Bug fix (proposed) References: <199711150115.RAA18627@hub.freebsd.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Jonathan Lemon wrote: > My ``fix'' is to have the IDT descriptor reference a segemnt which has > a length of 0. This has the effect of mapping SIGILL into SIGBUS, so that > the `cmpxchg8' crash now generates a Bus error. (I didn't bother returning > the correct signal; it can probably be added if it is important) Cool fix! It should work and seems much nicer than the two-page IDT fix. One point, though. The segment length is at least one byte since the limit in the descriptor is the last valid offset in the segment, not the length. That means that the address might be referenced. The granularity should be 0 for bytes. I think a user can map address 0 (at least on one OS) containing a single-byte instruction that might be run in ring 0, so another, guaranteed-invalid address might be better, or you might leave the P bit off in that segment or (better) in the IDT entry 6 descriptor, causing a segment-not-present fault. (I haven't tried any of this). Joe From owner-freebsd-hackers Fri Nov 14 19:36:02 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id TAA26380 for hackers-outgoing; Fri, 14 Nov 1997 19:36:02 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from anlsun.ebr.anlw.anl.gov (anlsun.ebr.anlw.anl.gov [141.221.1.2]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id TAA26353 for ; Fri, 14 Nov 1997 19:35:58 -0800 (PST) (envelope-from cmott@srv.net) Received: from darkstar.home (dialin1.anlw.anl.gov [141.221.254.101]) by anlsun.ebr.anlw.anl.gov (8.6.11/8.6.11) with SMTP id UAA15072 for ; Fri, 14 Nov 1997 20:35:53 -0700 Date: Fri, 14 Nov 1997 20:35:18 -0700 (MST) From: Charles Mott X-Sender: cmott@darkstar.home To: hackers@FreeBSD.ORG Subject: Re: Just FYI [F00F bug] In-Reply-To: <13781.879561529@time.cdrom.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Fri, 14 Nov 1997, Jordan K. Hubbard wrote: > In any case, this is just FYI and Intel *is* quite interested in our > having a fix for this problem. I gave them Bruce Evans' email address > and asked them to supply the details directly to him as he's our > resident IDT expert and I think we've burned up more than enough > bandwidth in -hackers over this issue as it is. > You might also want to give them Jonathon Lemon's e-mail address (jlemon@americantv.com). It appears that Jonathan came up with a very clever solution. From owner-freebsd-hackers Fri Nov 14 20:15:56 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id UAA28058 for hackers-outgoing; Fri, 14 Nov 1997 20:15:56 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from vinyl.quickweb.com (vinyl.quickweb.com [209.112.4.14]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id UAA28049 for ; Fri, 14 Nov 1997 20:15:47 -0800 (PST) (envelope-from mark@quickweb.com) Received: (from mark@localhost) by vinyl.quickweb.com (8.8.7/8.6.12) id XAA08237; Fri, 14 Nov 1997 23:16:46 -0500 (EST) Message-ID: <19971114231646.51209@vmunix.com> Date: Fri, 14 Nov 1997 23:16:46 -0500 From: Mark Mayo To: Julian Elischer Cc: "Jordan K. Hubbard" , hackers@FreeBSD.ORG Subject: Re: SUID-Directories patch References: <9942.879515612@time.cdrom.com> <346CDDE4.5656AEC7@whistle.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.85e In-Reply-To: <346CDDE4.5656AEC7@whistle.com>; from Julian Elischer on Fri, Nov 14, 1997 at 03:25:24PM -0800 X-Operating-System: FreeBSD 2.2.5-STABLE i386 Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Fri, Nov 14, 1997 at 03:25:24PM -0800, Julian Elischer wrote: > Jordan K. Hubbard wrote: > > > > However, like all projects, we've also matured over the last 4+ years > > and with that maturity has come a greater degree of conservatism in > > how we do development and in what we expect from any contributor who > > seeks to take on a fairly major chunk of development. What might have > > been considered reasonably acceptable development practice 4 or even 2 > > years ago simply won't fly now that we have a much larger user base > > and are under considerable pressure to produce a professional quality > > operating system which sets itself well apart from our "competition" > > in this arena. > > ok, then we need another place for 'bleeding edge' then. > SMP is anexample of development going on in -current, that > defies both your categories below. If we make -curent into > -stable, then where does the development go? Development needs > to go somewhere where people can test it out and take it for a > test-drive. I think my project database will sort of serve this purpose. The idea is to have a central, organized repository that lists the projects that are happening outside the main FreeBSD -CURRENT and -STABLE trees. My idea is to have a Project Page that contains information about projects: Project Title, Description, Team Leader, Members, etc, etc.. The entire thing is worked from a web page, and people can browse projects, if they're interested in checking out the work of the project (a SUID patch for Samba sites, for example) they just cruise on over to the project web page and grab the goods. People can also of course join projects, suggest projects, etc. It's become obvious that it would be good to encourage more development from beginers, or bleeding edge work, and it's also obvious that much of this stuff doesn't belong in the main FreeBSD CVS trees. I think a project database would work wonders; it will allow more creative development projects, encourage the up and coming young guns to write more code, and it still sticks with the more organised, central approach of FreeBSD. I'm building the thing ontop of the PostgreSQL relational database, controlled competely from the web. I've got the design done, and I'm going to post it here next week for feedback. I've also got a good part of it coded up, I'm hoping it will be ready for public review within 2 weeks. I have a week of exams coming up, after which I should have enough time to finish the prototype... I also have to finish some parts of the FreeBSD book I'm working on with Chris Coleman.. ahh, if only there were more hours in the day... :-) I'm stumbling on technical problems right now - I've been testing PostgreSQL with some high loads (trying to simulate 1 million+ hits a night) and it appears to leak memory like a stuck pig.. It's also core dumped on me twice.. Luckily I've tracked down the problem and the PostgreSQL team says it's fixed now! The only other thing I'm not sure of is whether or not the project database should actually maintain its own CVS tree of code from the various projects.. Initally at least, it will just contain hyperlinks to offsite project pages - it might be nice, however, if people could use the familiar CVSup interface to suck down a project they are interested in. This does become a maintanence hassle, however, since it implies that the project leaders have to check code in, blah, blah.. It might discourage development, so my initial impression is to just point to web pages, or at the most have a mechanism to drop off and check out tar-balls integrated into the web interface. Thoughts? Anyways, I'll keep -hackers posted when the system is ready to be prototyped. cya, -Mark -- ------------------------------------------------------------------------ Mark Mayo mark@vmunix.com RingZero Comp. http://www.vmunix.com/mark finger mark@vmunix.com for my PGP key and GCS code ------------------------------------------------------------------------ Win95/NT - 32 bit extensions and a graphical shell for a 16 bit patch to an an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition. -UGU From owner-freebsd-hackers Fri Nov 14 20:23:52 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id UAA28404 for hackers-outgoing; Fri, 14 Nov 1997 20:23:52 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id UAA28397 for ; Fri, 14 Nov 1997 20:23:47 -0800 (PST) (envelope-from bde@zeta.org.au) Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.7/8.6.9) id PAA28278; Sat, 15 Nov 1997 15:23:09 +1100 Date: Sat, 15 Nov 1997 15:23:09 +1100 From: Bruce Evans Message-Id: <199711150423.PAA28278@godzilla.zeta.org.au> To: bde@zeta.org.au, mouth@ibm.net Subject: Re: Status of 650 UART support Cc: hackers@FreeBSD.ORG Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >>>Edge triggered interrupts are not a factor. >> >>Yes they are. > >In what way? They force the interrupt handler to check all possible sources of the interrupt, although 90-99% of the times there will only be one interrupt source so returning after handling only one is best if checking the others is expensive (as it is for separate ISA devices). Bruce From owner-freebsd-hackers Fri Nov 14 20:26:04 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id UAA28519 for hackers-outgoing; Fri, 14 Nov 1997 20:26:04 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from dyson.iquest.net (dyson.iquest.net [198.70.144.127]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id UAA28514 for ; Fri, 14 Nov 1997 20:25:57 -0800 (PST) (envelope-from toor@dyson.iquest.net) Received: (from root@localhost) by dyson.iquest.net (8.8.7/8.8.5) id XAA01801; Fri, 14 Nov 1997 23:25:34 -0500 (EST) From: "John S. Dyson" Message-Id: <199711150425.XAA01801@dyson.iquest.net> Subject: Re: SUID-Directories patch In-Reply-To: <14187.879562901@time.cdrom.com> from "Jordan K. Hubbard" at "Nov 14, 97 07:01:41 pm" To: jkh@time.cdrom.com (Jordan K. Hubbard) Date: Fri, 14 Nov 1997 23:25:34 -0500 (EST) Cc: nate@mt.sri.com, chuckr@glue.umd.edu, julian@whistle.com, hackers@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-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Jordan K. Hubbard said: > > The code isn't non-functional, but it is dys-functional. I think that's > > the crux of Jordan argument, that it isn't up to the users/developers of > > -current to flesh out/finish the work. Or even 'macro-debug' it. > > Precisely. History has also shown us that this invariably doesn't > even work, said code having a far greater tendency to rot rather than > get fixed. Did not Julian himself start his defense of DEVFS with a > comment that he'd gotten none of the help he'd hoped for? > > I rest my case. :) > I sure hope that dys-functional isn't short for dyson-functional :-). -- John dyson@freebsd.org jdyson@nc.com From owner-freebsd-hackers Fri Nov 14 20:29:47 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id UAA28766 for hackers-outgoing; Fri, 14 Nov 1997 20:29:47 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from vinyl.quickweb.com (vinyl.quickweb.com [209.112.4.14]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id UAA28761 for ; Fri, 14 Nov 1997 20:29:44 -0800 (PST) (envelope-from mark@quickweb.com) Received: (from mark@localhost) by vinyl.quickweb.com (8.8.7/8.6.12) id XAA08303; Fri, 14 Nov 1997 23:30:45 -0500 (EST) Message-ID: <19971114233044.08889@vmunix.com> Date: Fri, 14 Nov 1997 23:30:44 -0500 From: Mark Mayo To: Jonathan Lemon Cc: hackers@FreeBSD.ORG Subject: Re: FreeBSD Pentium Bug fix (proposed) References: <19971114171214.44521@right.PCS> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.85e In-Reply-To: <19971114171214.44521@right.PCS>; from Jonathan Lemon on Fri, Nov 14, 1997 at 05:12:15PM -0600 X-Operating-System: FreeBSD 2.2.5-STABLE i386 Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Fri, Nov 14, 1997 at 05:12:15PM -0600, Jonathan Lemon wrote: > [SNIP] > My ``fix'' is to have the IDT descriptor reference a segemnt which has > a length of 0. This has the effect of mapping SIGILL into SIGBUS, so that > the `cmpxchg8' crash now generates a Bus error. (I didn't bother returning > the correct signal; it can probably be added if it is important) Cool idea! FWIW, I applied the changes on the 4 remaining Pentium systems I have (everything else has gotten a K6 upgrade, or has been moved to PPro): 90MHz Classic, 150MHz Classic, 166MHz MMX, 233MHz MMX. In short, it worked. No measurable performance loss as far as I can tell. Hip Hip hooray! I'd buy you a beer if you were within a 100km radius of me! :-) -Mark -- ------------------------------------------------------------------------ Mark Mayo mark@vmunix.com RingZero Comp. http://www.vmunix.com/mark finger mark@vmunix.com for my PGP key and GCS code ------------------------------------------------------------------------ Win95/NT - 32 bit extensions and a graphical shell for a 16 bit patch to an an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition. -UGU From owner-freebsd-hackers Fri Nov 14 20:50:15 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id UAA29616 for hackers-outgoing; Fri, 14 Nov 1997 20:50:15 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from out2.ibm.net (out2.ibm.net [165.87.194.229]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id UAA29603 for ; Fri, 14 Nov 1997 20:50:07 -0800 (PST) (envelope-from mouth@ibm.net) Received: from slip129-37-53-78.ca.us.ibm.net (slip129-37-53-78.ca.us.ibm.net [129.37.53.78]) by out2.ibm.net (8.8.5/8.6.9) with SMTP id EAA67410; Sat, 15 Nov 1997 04:49:57 GMT From: mouth@ibm.net (John Kelly) To: Bruce Evans Cc: hackers@FreeBSD.ORG Subject: Re: Status of 650 UART support Date: Sat, 15 Nov 1997 05:51:11 GMT Message-ID: <346d33da.1391195@smtp-gw01.ny.us.ibm.net> References: <199711150423.PAA28278@godzilla.zeta.org.au> In-Reply-To: <199711150423.PAA28278@godzilla.zeta.org.au> X-Mailer: Forte Agent 1.01/16.397 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by hub.freebsd.org id UAA29607 Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Sat, 15 Nov 1997 15:23:09 +1100, Bruce Evans wrote: >>>>Edge triggered interrupts >They force the interrupt handler to check all possible sources of the >interrupt, although 90-99% of the times there will only be one interrupt >source so returning after handling only one is best if checking the >others is expensive (as it is for separate ISA devices). Right. And that brings up something I've been wondering about on my 8-port serial card with 650s. Suppose I set all 8 ports to 460,800 bps and saturate them with inbound data. With the 32-byte FIFO I might set the trigger level to 16, giving 16 bytes of headroom in each UART, or possibly set the trigger level to 8, giving 24 bytes of headroom. Once I start draining the first UART, will I reach the eighth UART before it's overrun, and if so, how much margin will I have? I'm not sure how to calculate the time required for the 8-bit bus cycles. John From owner-freebsd-hackers Fri Nov 14 20:54:44 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id UAA29839 for hackers-outgoing; Fri, 14 Nov 1997 20:54:44 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from implode.root.com (implode.root.com [198.145.90.17]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id UAA29831 for ; Fri, 14 Nov 1997 20:54:20 -0800 (PST) (envelope-from root@implode.root.com) Received: from implode.root.com (localhost [127.0.0.1]) by implode.root.com (8.8.5/8.8.5) with ESMTP id UAA14831; Fri, 14 Nov 1997 20:54:57 -0800 (PST) Message-Id: <199711150454.UAA14831@implode.root.com> To: dennis cc: hackers@FreeBSD.ORG Subject: Re: 256Meg In-reply-to: Your message of "Fri, 14 Nov 1997 17:01:24 EST." <3.0.32.19971114170123.00d074d0@etinc.com> From: David Greenman Reply-To: dg@root.com Date: Fri, 14 Nov 1997 20:54:57 -0800 Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >Is there a maximum that FreeBSD can support? There are some problems with going >256MB that will require some special tuning of kernel parameters (which ones depend entirely on what you're doing), but there are several FreeBSD machines that I know of running with 1GB of RAM - wcarchive being one of them. -DG David Greenman Core-team/Principal Architect, The FreeBSD Project From owner-freebsd-hackers Fri Nov 14 21:09:52 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id VAA00521 for hackers-outgoing; Fri, 14 Nov 1997 21:09:52 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from sumatra.americantv.com (sumatra.americantv.com [207.170.17.37]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id VAA00514 for ; Fri, 14 Nov 1997 21:09:48 -0800 (PST) (envelope-from jlemon@americantv.com) Received: from right.PCS (right.PCS [148.105.10.31]) by sumatra.americantv.com (8.8.5/8.8.5) with ESMTP id XAA11803; Fri, 14 Nov 1997 23:09:46 -0600 (CST) Received: (from jlemon@localhost) by right.PCS (8.6.13/8.6.4) id XAA11123; Fri, 14 Nov 1997 23:09:15 -0600 Message-ID: <19971114230915.12485@right.PCS> Date: Fri, 14 Nov 1997 23:09:15 -0600 From: Jonathan Lemon To: Joe Eykholt Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: FreeBSD Pentium Bug fix (proposed) References: <199711150115.RAA18627@hub.freebsd.org> <346D17BA.1B37ADEA@ipsilon.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.61.1 In-Reply-To: <346D17BA.1B37ADEA@ipsilon.com>; from Joe Eykholt on Nov 11, 1997 at 07:32:10PM -0800 Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Nov 11, 1997 at 07:32:10PM -0800, Joe Eykholt wrote: > One point, though. The segment length is at least one byte > since the limit in the descriptor is the last valid offset > in the segment, not the length. That means that the address might > be referenced. The granularity should be 0 for bytes. The address within in the segment is specified by the vector address contained within the IDT descriptor, so we don't have to worry about that. > so another, guaranteed-invalid address might be better, or you might > leave the P bit off in that segment or (better) in the > IDT entry 6 descriptor, causing a segment-not-present fault. > (I haven't tried any of this). Leaving the `P'resent bit off does generate a segment-not-present fault. Unfortunately, this is of lower priority than a illegal instruction fault, and doesn't work. (This was the first thing I tried) -- Jonathan From owner-freebsd-hackers Fri Nov 14 21:58:40 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id VAA02386 for hackers-outgoing; Fri, 14 Nov 1997 21:58:40 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id VAA02378 for ; Fri, 14 Nov 1997 21:58:37 -0800 (PST) (envelope-from bde@zeta.org.au) Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.7/8.6.9) id QAA31140; Sat, 15 Nov 1997 16:53:53 +1100 Date: Sat, 15 Nov 1997 16:53:53 +1100 From: Bruce Evans Message-Id: <199711150553.QAA31140@godzilla.zeta.org.au> To: bde@zeta.org.au, mouth@ibm.net Subject: Re: Status of 650 UART support Cc: hackers@freebsd.org Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >Suppose I set all 8 ports to 460,800 bps and saturate them with >inbound data. With the 32-byte FIFO I might set the trigger level to >16, giving 16 bytes of headroom in each UART, or possibly set the >trigger level to 8, giving 24 bytes of headroom. > >Once I start draining the first UART, will I reach the eighth UART >before it's overrun, and if so, how much margin will I have? I'm not >sure how to calculate the time required for the 8-bit bus cycles. 16 character times at 460800 bps is about 348 usec. The worst case is approximately 8 ports saturated with 32 bytes of input, 32 bytes of output and a modem status change. This takes about 2*32 + 1*32 + 5 i/o's per port. Each i/o takes about 1 usec on an 8MHz ISA bus (perhaps 125 nsec more or less). Altogether, it takes about 8*101 = 808. usec. It won't work. OTOH, there will often be less than 32 bytes of input per port (there will normally be >= 16 because the trigger level is 16), and there may be very little input, depending on the application. Altogether, with saturated input and no output it takes at least about 8*37 = 296 usec. This leaves a whole 52 usec for doing real work. It won't work well. Non-saturated cases might work well. Bruce From owner-freebsd-hackers Fri Nov 14 22:07:11 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id WAA02677 for hackers-outgoing; Fri, 14 Nov 1997 22:07:11 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from moss.verinet.com (root@moss.verinet.com [204.144.246.15]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id WAA02671 for ; Fri, 14 Nov 1997 22:07:09 -0800 (PST) (envelope-from allenc@verinet.com) Received: from bamboo.verinet.com (root@bamboo.verinet.com [204.144.246.3]) by moss.verinet.com (8.8.8/8.6.9) with ESMTP id XAA08677 for ; Fri, 14 Nov 1997 23:06:59 -0700 Received: from pragma (port73.verinet.com [204.144.246.172]) by bamboo.verinet.com (8.8.8/8.7.1) with SMTP id XAA24003 for ; Fri, 14 Nov 1997 23:06:58 -0700 Message-ID: <346D3BF3.2982@verinet.com> Date: Fri, 14 Nov 1997 23:06:43 -0700 From: Allen Campbell Reply-To: allenc@verinet.com X-Mailer: Mozilla 3.01Gold (Win95; I) MIME-Version: 1.0 To: hackers@FreeBSD.ORG Subject: Re: hackers-digest V3 #429 References: <199711141434.GAA02518@hub.freebsd.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > Problem: I am always late to work > Solution: Set your clock forward 5 minutes (you idiot) That IS idiotic. You need at least 10 for this to be effective. :) From owner-freebsd-hackers Fri Nov 14 22:42:03 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id WAA03855 for hackers-outgoing; Fri, 14 Nov 1997 22:42:03 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from time.cdrom.com (root@time.cdrom.com [204.216.27.226]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id WAA03850 for ; Fri, 14 Nov 1997 22:42:00 -0800 (PST) (envelope-from jkh@time.cdrom.com) Received: from time.cdrom.com (jkh@localhost.cdrom.com [127.0.0.1]) by time.cdrom.com (8.8.7/8.6.9) with ESMTP id WAA14857; Fri, 14 Nov 1997 22:41:58 -0800 (PST) To: Mark Mayo cc: Julian Elischer , hackers@FreeBSD.ORG Subject: Re: SUID-Directories patch In-reply-to: Your message of "Fri, 14 Nov 1997 23:16:46 EST." <19971114231646.51209@vmunix.com> Date: Fri, 14 Nov 1997 22:41:57 -0800 Message-ID: <14853.879576117@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > I think my project database will sort of serve this purpose. > The idea is to have a central, organized repository that lists > the projects that are happening outside the main FreeBSD This sounds very promising! > The only other thing I'm not sure of is whether or not the project > database should actually maintain its own CVS tree of code from the Perhaps at some point, but I think that this would present a stumbling block to most people likely to participate in such an endeavor and you should probably keep it as simple as possible for now. Jordan From owner-freebsd-hackers Fri Nov 14 23:16:06 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id XAA04959 for hackers-outgoing; Fri, 14 Nov 1997 23:16:06 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from time.cdrom.com (root@time.cdrom.com [204.216.27.226]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id XAA04952 for ; Fri, 14 Nov 1997 23:16:03 -0800 (PST) (envelope-from jkh@time.cdrom.com) Received: from time.cdrom.com (jkh@localhost.cdrom.com [127.0.0.1]) by time.cdrom.com (8.8.7/8.6.9) with ESMTP id XAA16657 for ; Fri, 14 Nov 1997 23:16:07 -0800 (PST) To: hackers@freebsd.org Subject: David Greenman and I will be at Comdex this coming week. Date: Fri, 14 Nov 1997 23:16:07 -0800 Message-ID: <16653.879578167@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In the Walnut Creek CDROM booth (sorry, I don't have a booth number but we're in the show roster). I will be there Sunday - Wednesday and David will be there Wednesday - Friday. If you're in Las Vegas, why not stop by the booth and see us? We'll also be selling the new FreeBSD Polo shirts and T-shirts, for those who are interested in these latest bits of FreeBSD memorabilia (and the polo shirts look quite nice, if I do say so myself - I took a crude but reasonably descriptive scan of one and stuck it up at http://time.cdrom.com/~jkh/polo.jpg) Also, if there are any Las Vegas area ISP or university folks who would be willing to give me temporary use of a dialup so that I can keep up with my email, I'd be much appreciative since I'll be taking a laptop with me and will otherwise have to call back to the California to check my mail. Please drop me a short note with the details. Thanks! Jordan From owner-freebsd-hackers Sat Nov 15 02:28:41 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id CAA11776 for hackers-outgoing; Sat, 15 Nov 1997 02:28:41 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from omnix.net (root@omnix.net [194.183.217.130]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id CAA11770 for ; Sat, 15 Nov 1997 02:28:35 -0800 (PST) (envelope-from didier@omnix.net) Received: from localhost (didier@localhost.omnix.net [127.0.0.1]) by omnix.net (8.8.5/8.8.5) with SMTP id KAA06982; Sat, 15 Nov 1997 10:28:14 GMT Date: Sat, 15 Nov 1997 11:28:14 +0100 (CET) From: Didier Derny To: Jonathan Lemon cc: hackers@FreeBSD.ORG Subject: Re: FreeBSD Pentium Bug fix (proposed) In-Reply-To: <19971114171214.44521@right.PCS> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Fri, 14 Nov 1997, Jonathan Lemon wrote: > > Alright, I've been watching the debate about the LOCK CMPXCHG8 bug, > and decided to take a crack at it. While I believe that for the most > case, this is probably just a tempest in a teapot, for some, it probably > represents a serious DOS that should be addressed. > I installed it on a 2.2.2-Release machine with a Pentium 166 MMX and it works fine for me. By the way, I think that the only acceptable solution to this problem is the replacement of the defective parts by Intel. -- Didier Derny didier@omnix.net From owner-freebsd-hackers Sat Nov 15 06:33:57 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id GAA06274 for hackers-outgoing; Sat, 15 Nov 1997 06:33:57 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from hwcn.org (main.hwcn.org [199.212.94.65]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id GAA06237; Sat, 15 Nov 1997 06:33:49 -0800 (PST) (envelope-from hoek@hwcn.org) Received: from james.freenet.hamilton.on.ca (ac199@james.hwcn.org [199.212.94.66]) by hwcn.org (8.8.7/8.8.7) with ESMTP id JAA14666; Sat, 15 Nov 1997 09:34:25 -0500 (EST) Received: from localhost (ac199@localhost) by james.freenet.hamilton.on.ca (8.8.7/8.8.7) with SMTP id JAA19383; Sat, 15 Nov 1997 09:34:58 -0500 (EST) X-Authentication-Warning: james.freenet.hamilton.on.ca: ac199 owned process doing -bs Date: Sat, 15 Nov 1997 09:34:58 -0500 (EST) From: Tim Vanderhoek X-Sender: ac199@james.freenet.hamilton.on.ca To: "John S. Dyson" cc: freebsd-chat@FreeBSD.ORG, jkh@time.cdrom.com, Shimon@i-connect.net, freebsd-hackers@FreeBSD.ORG Subject: Re: Bad Winds of Winter - Please Read! In-Reply-To: <199711150307.WAA01607@dyson.iquest.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Fri, 14 Nov 1997, John S. Dyson wrote: > I just landed in Indianapolis last night (from the Bay area), in a twin > engine plane, with approx 5cm of slush. We had approx 10-12cm of snow Well, if it makes you feel any better, the official count now puts us at 17cm of snow. :) -- Outnumbered? Maybe. Outspoken? Never! tIM...HOEk From owner-freebsd-hackers Sat Nov 15 06:53:26 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id GAA07488 for hackers-outgoing; Sat, 15 Nov 1997 06:53:26 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from hwcn.org (main.hwcn.org [199.212.94.65]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id GAA07483 for ; Sat, 15 Nov 1997 06:53:19 -0800 (PST) (envelope-from hoek@hwcn.org) Received: from james.freenet.hamilton.on.ca (ac199@james.hwcn.org [199.212.94.66]) by hwcn.org (8.8.7/8.8.7) with ESMTP id JAA16459; Sat, 15 Nov 1997 09:53:56 -0500 (EST) Received: from localhost (ac199@localhost) by james.freenet.hamilton.on.ca (8.8.7/8.8.7) with SMTP id JAA21896; Sat, 15 Nov 1997 09:54:28 -0500 (EST) X-Authentication-Warning: james.freenet.hamilton.on.ca: ac199 owned process doing -bs Date: Sat, 15 Nov 1997 09:54:27 -0500 (EST) From: Tim Vanderhoek X-Sender: ac199@james.freenet.hamilton.on.ca To: Mark Mayo cc: Julian Elischer , "Jordan K. Hubbard" , hackers@FreeBSD.ORG Subject: Re: SUID-Directories patch In-Reply-To: <19971114231646.51209@vmunix.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Fri, 14 Nov 1997, Mark Mayo wrote: > The only other thing I'm not sure of is whether or not the project > database should actually maintain its own CVS tree of code from the > various projects.. Initally at least, it will just contain hyperlinks Looking at other "project databases", it would definitely be nice to keep the idea more centralized. If it's a project, it should be officially a project (even though it may never reach completion or a state of usability). Vague project statements with no concrete information are a definite turn off (IMHO). However, it certainly wouldn't be good to force everyone to be using a cvs tree... :) A little encouragement couldn't hurt, though... :) -- Outnumbered? Maybe. Outspoken? Never! tIM...HOEk From owner-freebsd-hackers Sat Nov 15 08:21:34 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id IAA15904 for hackers-outgoing; Sat, 15 Nov 1997 08:21:34 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from phoenix.its.rpi.edu (phoenix.its.rpi.edu [128.113.161.45]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id IAA15898 for ; Sat, 15 Nov 1997 08:21:26 -0800 (PST) (envelope-from dec@phoenix.its.rpi.edu) Received: from localhost (dec@localhost) by phoenix.its.rpi.edu (8.8.7/8.8.7) with SMTP id LAA23140 for ; Sat, 15 Nov 1997 11:21:37 -0500 (EST) (envelope-from dec@phoenix.its.rpi.edu) Date: Sat, 15 Nov 1997 11:21:37 -0500 (EST) From: "David E. Cross" To: freebsd-hackers@freebsd.org Subject: AFS for FreeBSD Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I have retrieved a new copy of the AFS source tree, 3.4a-p6, and will begin the porting process arrround december (Now I am awaiting to hear back from transarc's legal department on all of this). If anyone else has a source license, and a desire to help, please let me know. (tis a shame that by the time this is done DFS will be taking hold in most of the market) -- David Cross ACS Consultant From owner-freebsd-hackers Sat Nov 15 10:02:09 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id KAA21668 for hackers-outgoing; Sat, 15 Nov 1997 10:02:09 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from dyson.iquest.net (dyson.iquest.net [198.70.144.127]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id KAA21662 for ; Sat, 15 Nov 1997 10:02:06 -0800 (PST) (envelope-from toor@dyson.iquest.net) Received: (from root@localhost) by dyson.iquest.net (8.8.7/8.8.5) id NAA04228; Sat, 15 Nov 1997 13:01:58 -0500 (EST) From: "John S. Dyson" Message-Id: <199711151801.NAA04228@dyson.iquest.net> Subject: Re: Just FYI [F00F bug] In-Reply-To: <13781.879561529@time.cdrom.com> from "Jordan K. Hubbard" at "Nov 14, 97 06:38:49 pm" To: jkh@time.cdrom.com (Jordan K. Hubbard) Date: Sat, 15 Nov 1997 13:01:58 -0500 (EST) Cc: hackers@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-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Jordan K. Hubbard said: > I was contacted today by Sunil Saxena and Woody Cohn at Intel who > apologised for the aformentioned bug and promised to provide any and > all information required to fix it. Apparently, they called me some 3 > days ago at Walnut Creek CDROM but the folks there didn't think to > pass the message on (grr!). They've been working flat-out on this bug > over there and are treating it very seriously indeed. > FYI, Intel had called me also, and I neglected to check my messages :-(. -- John dyson@freebsd.org jdyson@nc.com From owner-freebsd-hackers Sat Nov 15 10:04:00 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id KAA21828 for hackers-outgoing; Sat, 15 Nov 1997 10:04:00 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from ns1.yes.no (ns1.yes.no [195.119.24.10]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id KAA21801 for ; Sat, 15 Nov 1997 10:03:53 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [194.198.43.36]) by ns1.yes.no (8.8.7/8.8.7) with ESMTP id SAA02559; Sat, 15 Nov 1997 18:03:35 GMT Received: (from eivind@localhost) by bitbox.follo.net (8.8.6/8.8.6) id TAA01032; Sat, 15 Nov 1997 19:03:31 +0100 (MET) Date: Sat, 15 Nov 1997 19:03:31 +0100 (MET) Message-Id: <199711151803.TAA01032@bitbox.follo.net> From: Eivind Eklund To: Mark Mayo CC: julian@whistle.com, jkh@time.cdrom.com, hackers@FreeBSD.ORG In-reply-to: Mark Mayo's message of Fri, 14 Nov 1997 23:16:46 -0500 Subject: Re: SUID-Directories patch References: <9942.879515612@time.cdrom.com> <346CDDE4.5656AEC7@whistle.com> <19971114231646.51209@vmunix.com> Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > if they're interested in checking out the work of the project (a > SUID patch for Samba sites, for example) they just cruise on > over to the project web page and grab the goods. People can also > of course join projects, suggest projects, etc. Sounds like a great initiative! > I'm building the thing ontop of the PostgreSQL relational database, > controlled competely from the web. I've got the design done, and I'm > going to post it here next week for feedback. I've also got a good > part of it coded up, I'm hoping it will be ready for public review > within 2 weeks. Great! How is this going to be licensed? Would you be interested in working to integrate it with a commercial project? (I'm out of time, and I'm starting to get minor conscience problems for not having given enough back to the projects I leech off yet). > The only other thing I'm not sure of is whether or not the project > database should actually maintain its own CVS tree of code from the > various projects.. Initally at least, it will just contain hyperlinks > to offsite project pages - it might be nice, however, if people could > use the familiar CVSup interface to suck down a project they are > interested in. This does become a maintanence hassle, however, since it > implies that the project leaders have to check code in, blah, blah.. > It might discourage development, so my initial impression is to just > point to web pages, or at the most have a mechanism to drop off and > check out tar-balls integrated into the web interface. > Thoughts? I'd say a cvsup-service would be nice. Not a central CVS repository - just a service that collect the different repositories and provide them as a central feed from somewhere with OK bandwidth. Almost all projects I'm involved with run under CVS anyway; I think that would be true for a lot of other freeware projects, too. Eivind. From owner-freebsd-hackers Sat Nov 15 10:08:14 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id KAA22142 for hackers-outgoing; Sat, 15 Nov 1997 10:08:14 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from reb2.ivev.bau.tu-bs.de (reb2.ivev.bau.tu-bs.de [134.169.17.82]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id KAA22136 for ; Sat, 15 Nov 1997 10:08:03 -0800 (PST) (envelope-from J.Bredemeyer@tu-bs.de) From: J.Bredemeyer@tu-bs.de Received: from localhost (jochen@localhost) by reb2.ivev.bau.tu-bs.de (8.8.7/8.8.7) with SMTP id TAA03540; Sat, 15 Nov 1997 19:10:06 +0100 (CET) (envelope-from J.Bredemeyer@tu-bs.de) X-Authentication-Warning: reb2.ivev.bau.tu-bs.de: jochen owned process doing -bs Date: Sat, 15 Nov 1997 19:10:05 +0100 (CET) X-Sender: jochen@reb2.ivev.bau.tu-bs.de To: freebsd-hackers cc: Jochen Bredemeyer Subject: LKM and interrupts: it works! Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hello, I recently posted a question concerning the usage of interrupts within Loadable Kernel Modules (LKM). After scanning several sources, especially "/sys/i386/isa/isa.c" and its included files, I found a working solution - here is an extract of my device driver: ------------------------------------------------------------------------- #include #include #include #include #include #include #include #define _IRQ IRQ12 /* Interrupt number */ [...] /* not really necessary */ static struct isa_device dev =3D {0, &hexdriver, BASEADDR, 12, -1, (caddr_t)0, 0,&hexintr, 0, 0, 0, 1, 0, 0, 1, 0, 0}; int hex_load (struct lkm_table *lkmtp, int cmd) { if (!hexprobe(&dev)) { uprintf ("Hexlink driver: probe failed\n"); return 1; } /* register_intr() from "isa.c" */ if(register_intr(ffs(_IRQ)-1,0,0,(inthand2_t *)hexintr,&tty_imask,0)) { uprintf ("Hexlink driver: register_intr() failed\n"); return 1; } INTREN(_IRQ); /* Enable Interrupt, see "icu.h" */ uprintf ("Hexlink driver loaded\n"); hexattach(&dev); return 0; } int hex_unload (struct lkm_table *lkmtp, int cmd) { INTRDIS(_IRQ); /* Disable IRQ */ unregister_intr(ffs(_IRQ)-1,(inthand2_t *)hexintr); /* Release IRQ */ uprintf ("Hexlink driver unloaded\n"); return 0; } void hexintr (int unit) { printf("\nInterrupt occured!\n"); } [...] ------------------------------------------------------------------------- I hope this helps! Bye, Jochen DJ 5 BA J.Bredemeyer@tu-bs.de dj5ba@amsat.org From owner-freebsd-hackers Sat Nov 15 10:30:15 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id KAA23170 for hackers-outgoing; Sat, 15 Nov 1997 10:30:15 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from david.siemens.de (david.siemens.de [139.23.36.11]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id KAA23165 for ; Sat, 15 Nov 1997 10:30:12 -0800 (PST) (envelope-from andre.albsmeier@mchp.siemens.de) Received: from salomon.mchp.siemens.de (mail.siemens.de [139.23.33.13]) by david.siemens.de (8.8.8/8.8.8) with ESMTP id TAA22929 for ; Sat, 15 Nov 1997 19:30:06 +0100 (MET) Received: from curry.mchp.siemens.de (daemon@curry.mchp.siemens.de [146.180.31.23]) by salomon.mchp.siemens.de (8.8.8/8.8.5) with ESMTP id TAA22460 for ; Sat, 15 Nov 1997 19:30:08 +0100 (CET) Received: (from daemon@localhost) by curry.mchp.siemens.de (8.8.7/8.8.7) id TAA00693 for ; Sat, 15 Nov 1997 19:30:07 +0100 (MET) From: Andre Albsmeier Message-Id: <199711151830.TAA21413@intern> Subject: Re: How useful is this patch? In-Reply-To: from Julian Elischer at "Nov 9, 97 05:23:10 pm" To: julian@whistle.com (Julian Elischer) Date: Sat, 15 Nov 1997 19:30:00 +0100 (CET) Cc: hackers@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL32 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > of course, > but who said that you have to enable it in you HOME directory? > We want to do this in users 'dropbox' directories > which is not the same as their ho,e directories. > without it there is a never-ending set of complaints about > permissions, and the admin spends a lot of time removing files for users. > As is indicated.. this is implemented as a mount option (default off) > and the directory in question must have the bit set.. > it isn't likely to happen by accident. > We can keep it as a WHISTLE-ONLY mod here, but I thought > I'd see if anyone else wants it.. > I'd rather have it in the general sources than proprietary, > but That's a decision that's beyond me to make.. > (i.e. yours). Count me on side of people who want it :-) I have got to deal with the problem a long time now and I am really tired of it... However, best would be to see it in 2.2.5... -Andre From owner-freebsd-hackers Sat Nov 15 11:27:51 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id LAA26502 for hackers-outgoing; Sat, 15 Nov 1997 11:27:51 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from trojanhorse.ml.org (mdean.vip.best.com [206.86.94.101]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id LAA26496 for ; Sat, 15 Nov 1997 11:27:48 -0800 (PST) (envelope-from jamil@trojanhorse.ml.org) Received: from localhost (jamil@localhost) by trojanhorse.ml.org (8.8.8/8.8.5) with SMTP id LAA04702; Sat, 15 Nov 1997 11:27:38 -0800 (PST) Date: Sat, 15 Nov 1997 11:27:38 -0800 (PST) From: "Jamil J. Weatherbee" Reply-To: "Jamil J. Weatherbee" To: freebsd-hackers@freebsd.org cc: dufault@hda.com Subject: AIO8-P/AT16-P Analog Driver Complete (Major Number Requested) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk A truly reasonably priced analog input board. I am now officially requesting a major number (I see that the teletype driver got one within a week, which makes me wonder why my previos Digital I/O driver was not taken seriously at all). However I have spent a considerable amount of time on an analog input board driver. This board is intended to be used with an accessory multiplexer (not required). The per channel cost is about $26, and can be expanded to 128 channels, all channels are 12-bit. I have included the manual page below for your viewing pleasure: AIOX(4) FreeBSD Kernel Interfaces Manual (i386 Architecture) AIOX(4) NAME aiox - Industrial Computer Source AIO8-P driver SYNOPSIS device aiox0 at isa? port 0x260 tty irq 5 vector aioxintr DESCRIPTION This driver supports the Industrial Computer Source AIO8-P 8-Channel 12-Bit Analog Input board. This board provides 8 12 bit, single-ended analog input ports. The driv- er also directly provides support for up to 8 daisy chained AT16-P Pro- grammable Analog Multiplexers with 16 Differential Inputs. This makes it possible to sample up to 128 differential channels with a single inter- face board. Use of at least one AT16-P is highly recommended as the AIO8-P offers no signal conditioning options and only operates in a -5 to +5 Volt input range. However, if you wish to use the AIO8-P standalone, insert the following into your kernel config(8) file: options AIOX_CHANNELS=8 Selection of the input port is through the minor number: The 9 bit minor number format is UUCCCCMMM, where UU: board unit (0-3) CCCC: external multiplexer channel (0-15) (on AT-16P units) MMM: internal multiplexer channel (0-7) (on AIO8-P card) devfs(5) device node names are of the form: aiox[0-3][a-p][0-7] IOCTL The following ioctl(2) calls apply to aiox devices. Their declaration can be found in the header files and AD_MICRO_PERIOD_SET Takes a pointer to a long argument specifying the number of microseconds between samples. Half of this is used as the external multiplexer settling time and the other half as conversion time. AD_MICRO_PERIOD_GET Takes a pointer to a long argument and returns the current number of microseconds between samples. AD_START Starts the clocked accumulation of sample values in- to a channels driver fifo. When a channel is first opened its software fifo is initialized in the stopped state. This is to prevent high sample clocks from overrunning the fifos before the user is ready to read from the channel. AD_STOP Stops the clocked accumulation of sample values into a channels driver fifo. BUGS On the AIO8-P, interrupt driven conversion (the only type supported by the aiox driver) is facilitated through 8253 timer #2. In order for in- terrrupts to be generated you must connect line 6 to line 24 (counter 2 output to interrupt input) and line 23 to line 29 (counter 2 gate to +5VDC). Due to the design of the AIO8-P this precludes the use of pro- grammable gain control. A 64 entry (128 byte) software fifo is provided for each analog channel. Reads are non-blocking on the aiox driver, so providing a read(2) buffer channels. Using this method, multichannel sample rates as high as 16,000 samples/sec have been observed. Sample rates lower than 32 Hz are not supported. SEE ALSO http://www.indcompsrc.com/products/data/html/aio8g-p.html http://www.indcompsrc.com/products/data/html/at16-p.html AUTHOR Jamil J. Weatherbee . FreeBSD November 14, 1997 2 From owner-freebsd-hackers Sat Nov 15 12:14:36 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id MAA13602 for hackers-outgoing; Sat, 15 Nov 1997 12:14:36 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from trojanhorse.ml.org (mdean.vip.best.com [206.86.94.101]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id MAA13571 for ; Sat, 15 Nov 1997 12:14:32 -0800 (PST) (envelope-from jamil@trojanhorse.ml.org) Received: from localhost (jamil@localhost) by trojanhorse.ml.org (8.8.8/8.8.5) with SMTP id MAA07058; Sat, 15 Nov 1997 12:14:23 -0800 (PST) Date: Sat, 15 Nov 1997 12:14:23 -0800 (PST) From: "Jamil J. Weatherbee" To: freebsd-hackers@freebsd.org cc: dufault@hda.com Subject: Re: AIO8-P/AT16-P Analog Driver Complete (Major Number Requested) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Oh, and by the way the aiox driver was submitted to gnats with the handle: i386/5058 The dio driver (if anyone cares to take a look) was submitted approximately a month ago on: i386/4816 Thanks again. From owner-freebsd-hackers Sat Nov 15 12:28:14 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id MAA18436 for hackers-outgoing; Sat, 15 Nov 1997 12:28:14 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from david.siemens.de (david.siemens.de [139.23.36.11]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id MAA18356 for ; Sat, 15 Nov 1997 12:28:03 -0800 (PST) (envelope-from andre.albsmeier@mchp.siemens.de) Received: from salomon.mchp.siemens.de (mail.siemens.de [139.23.33.13]) by david.siemens.de (8.8.8/8.8.8) with ESMTP id VAA26357 for ; Sat, 15 Nov 1997 21:27:54 +0100 (MET) Received: from curry.mchp.siemens.de (daemon@curry.mchp.siemens.de [146.180.31.23]) by salomon.mchp.siemens.de (8.8.8/8.8.5) with ESMTP id VAA03838 for ; Sat, 15 Nov 1997 21:27:56 +0100 (CET) Received: (from daemon@localhost) by curry.mchp.siemens.de (8.8.7/8.8.7) id VAA00954 for ; Sat, 15 Nov 1997 21:27:56 +0100 (MET) From: Andre Albsmeier Message-Id: <199711152027.VAA00200@intern> Subject: Re: SUID-Directories patch In-Reply-To: <199711140924.MAA00188@thorin.hway.ru> from "Alexander V. Tischenko" at "Nov 14, 97 12:25:57 pm" To: tischenko@intech.hway.ru (Alexander V. Tischenko) Date: Sat, 15 Nov 1997 21:27:46 +0100 (CET) Cc: julian@whistle.com, hackers@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL32 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > And is in 3.0-current, but doesn't belong in 2.2. On the flip side, > > just because a commercial entity donates code doesn't mean we should > > take it into the source tree lock/stock/and barrel. > > > > > > > > Nate > > I am not shure people running network file servers will be eager to upgrade > to _ANY_ new version unless expressely needed (i will not for shure!), so > to have an incorporated patch for 2.2 that will solve administrative > problems > IS a good thing and also a must. And as for 3.0 - it is very unstable yet > and shurely can't be used for building corporate heavy load servers. > > IMHO, the patch MUST be incorporated. I second that. I will never go away from 2.2 for my productions machines in the near future. If the decision is that it will NOT make it into 2.2, I would greatly appreciate a patch for 2.2.5 :-) Thanks, -Andre From owner-freebsd-hackers Sat Nov 15 13:32:28 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id NAA15972 for hackers-outgoing; Sat, 15 Nov 1997 13:32:28 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id NAA15961 for ; Sat, 15 Nov 1997 13:32:25 -0800 (PST) (envelope-from julian@whistle.com) Received: (from daemon@localhost) by alpo.whistle.com (8.8.5/8.8.5) id NAA22635; Sat, 15 Nov 1997 13:21:33 -0800 (PST) Received: from UNKNOWN(), claiming to be "current1.whistle.com" via SMTP by alpo.whistle.com, id smtpd022632; Sat Nov 15 13:21:23 1997 Date: Sat, 15 Nov 1997 13:19:25 -0800 (PST) From: Julian Elischer To: Andre Albsmeier cc: hackers@FreeBSD.ORG Subject: Re: How useful is this patch In-Reply-To: <199711151830.TAA21413@intern> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk yes, but it's been devreed 'un-needed' by core an dprobably won't appear there for a while. I will put up a 2.2.5 relative version of the patch.. it will be ftp://ftp.freebsd.org/pub/FreeBSD/incoming/suiddir.diff.2.2 look for it in an hour or so.. (back to the old 'patchkit' days.. :) On Sat, 15 Nov 1997, Andre Albsmeier wrote: > > of course, > > but who said that you have to enable it in you HOME directory? > > We want to do this in users 'dropbox' directories > > which is not the same as their ho,e directories. > > without it there is a never-ending set of complaints about > > permissions, and the admin spends a lot of time removing files for users. > > As is indicated.. this is implemented as a mount option (default off) > > and the directory in question must have the bit set.. > > it isn't likely to happen by accident. > > We can keep it as a WHISTLE-ONLY mod here, but I thought > > I'd see if anyone else wants it.. > > I'd rather have it in the general sources than proprietary, > > but That's a decision that's beyond me to make.. > > (i.e. yours). > > Count me on side of people who want it :-) I have got to deal > with the problem a long time now and I am really tired of it... > > However, best would be to see it in 2.2.5... > > -Andre > From owner-freebsd-hackers Sat Nov 15 13:38:47 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id NAA18896 for hackers-outgoing; Sat, 15 Nov 1997 13:38:47 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from shadows.aeon.net (root@shadows.aeon.net [194.100.41.1]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id NAA18821 for ; Sat, 15 Nov 1997 13:38:40 -0800 (PST) (envelope-from bsdhack@shadows.aeon.net) Received: (from bsdhack@localhost) by shadows.aeon.net (8.8.7/8.8.3) id XAA07172 for hackers@freebsd.org; Sat, 15 Nov 1997 23:01:17 +0200 (EET) From: mika ruohotie Message-Id: <199711152101.XAA07172@shadows.aeon.net> Subject: Re: IDT processors? In-Reply-To: <11094.879118603@time.cdrom.com> from "Jordan K. Hubbard" at "Nov 9, 97 03:36:43 pm" To: hackers@freebsd.org Date: Sat, 15 Nov 1997 23:01:16 +0200 (EET) 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-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > now, _that_ would be a port i'd like to see, freebsd on SGI platform. > Depends on how fast you're able to do the port, I guess! :) uh, people, we'd all die before _that_ day. =) (and i'm being _optimistic_) > Seriously, simply calling for a port to a new platform is a waste of > time since we've been asked, at one point or another, to port FreeBSD > to just about every architecture on the market today and we've even > been offered money to port to architectures like the UltraSPARC. yeah, i know, i was rather asking around if there's someone out there who's already doing/interested about it. i didnt mean it to be an average "do this for me" posting, even if it sounded that way... > alone on this topic unless they're also willing to do the work of > porting FreeBSD to a new architecture *and* be willing maintain it in i'd be more than happy to help, really, but it might take a while. what i'm saying, after there's _some_ sort of version, i hope i'm able to offer a platform where i can run it, and giving feedback how well it runs... with my skills, there's not much more i can offer, unfortunatelly. > Jordan mickey From owner-freebsd-hackers Sat Nov 15 15:18:44 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id PAA03219 for hackers-outgoing; Sat, 15 Nov 1997 15:18:44 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from news1.gtn.com (news1.gtn.com [192.109.159.3]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id PAA03209 for ; Sat, 15 Nov 1997 15:18:36 -0800 (PST) (envelope-from andreas@klemm.gtn.com) Received: (from uucp@localhost) by news1.gtn.com (8.8.6/8.8.6) with UUCP id AAA01903 for hackers@FreeBSD.ORG; Sun, 16 Nov 1997 00:15:16 +0100 (MET) Received: (from andreas@localhost) by klemm.gtn.com (8.8.8/8.8.7) id XAA02958; Sat, 15 Nov 1997 23:10:43 +0100 (CET) (envelope-from andreas) Message-ID: <19971115231043.02073@klemm.gtn.com> Date: Sat, 15 Nov 1997 23:10:43 +0100 From: Andreas Klemm To: hackers@FreeBSD.ORG Subject: kernel options for turning off source routing and ip accounting ? Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84 X-Disclaimer: A free society is one where it is safe to be unpopular X-Operating-System: FreeBSD 3.0-CURRENT SMP Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Just read an article about Linux as firewall system and noticed the ability to turn off source routing and turn on ip accounting. http://www.linux-magazin.de/ Do we also have such options ? Andreas /// -- Andreas Klemm powered by ,,symmetric multiprocessor FreeBSD'' From owner-freebsd-hackers Sat Nov 15 16:21:05 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id QAA06296 for hackers-outgoing; Sat, 15 Nov 1997 16:21:05 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from awfulhak.demon.co.uk (awfulhak.demon.co.uk [158.152.17.1]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id QAA06291 for ; Sat, 15 Nov 1997 16:20:53 -0800 (PST) (envelope-from brian@awfulhak.org) Received: from gate.lan.awfulhak.org (localhost [127.0.0.1]) by awfulhak.demon.co.uk (8.8.7/8.8.7) with ESMTP id AAA22259 for ; Sun, 16 Nov 1997 00:10:14 GMT (envelope-from brian@gate.lan.awfulhak.org) Message-Id: <199711160010.AAA22259@awfulhak.demon.co.uk> X-Mailer: exmh version 2.0zeta 7/24/97 To: freebsd-hackers@FreeBSD.org Subject: /etc/mail filters in 2.2.5 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 16 Nov 1997 00:10:14 +0000 From: Brian Somers Sender: owner-freebsd-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk Hi. I'm no sendmail expert, so perhaps someone with more of a clue than I do can tell me if I've got a pilot error. I installed the /etc/mail stuff a few days ago, and added a few sites to domains.txt, specifically: BIGFOOT.DALTEK.NET^M #blocked. contact postmaster I did a ``make install'' and HUP'd sendmail and checked the log to see that it had restarted. Just to confirm things, grepping for ``bigfoot.daltek.net'' in spamsites.db says it's there, and grepping for ``spamsites.db'' in /etc/sendmail.cf gives: Kspamsites hash -o -a.REJECT /etc/mail/spamsites.db I just received this: Nov 15 23:50:50 gate sendmail[21528]: XAA21528: from=, size=1874, class=0, pri=31874, nrcpts=1, msgid=<199711152014.OAA26126@merc ury.gmds.com>, proto=SMTP, relay=punt-1a.mail.demon.net [194.217.242.134] Shouldn't this have been rejected ? I've enclosed my complete .mc if anyone's interested. The second bit was directly copied from the stuff in /etc/mail. Thanks for any suggestions. -- Brian , , Don't _EVER_ lose your sense of humour.... VERSIONID(`gate.mc version 1.2') OSTYPE(bsd4.4)dnl FEATURE(nouucp)dnl MAILER(local)dnl MAILER(smtp)dnl define(`confQUEUE_FACTOR',1)dnl Cwgate.lan.awfulhak.org Cwawfulhak.demon.co.uk Cwawfulhak.org define(`confTO_QUEUEWARN',3d)dnl define(`confFORWARD_PATH', `/var/forward/$u:$z/.forward')dnl MASQUERADE_AS(`awfulhak.org')dnl FEATURE(allmasquerade)dnl FEATURE(masquerade_envelope)dnl FEATURE(nocanonify)dnl FEATURE(nodns)dnl Dmawfulhak.demon.co.uk define(`confDOMAIN_NAME',`awfulhak.demon.co.uk')dnl define(`confDELIVERY_MODE', `d')dnl # database declarations Kdenyip hash -o -a.REJECT /etc/mail/denyip.db Kspamsites hash -o -a.REJECT /etc/mail/spamsites.db # called with host.tld and IP address of connecting host. # ip address must NOT be in the "denyip" database Scheck_relay R$* $| [$+ $1 $| $2 should not be needed R$* $| $+] $1 $| $2 same (bat 2nd ed p510) R$* $| $* $: $1 $| $(denyip $2 $) R$* $| $*.REJECT $#error $: 521 blocked. contact postmaster@FreeBSD.ORG ($2) # host must *not* be in the "spamsites" database R$+.$+.$+ $| $* $2.$3 $| $4 R$+.$+ $| $* $: $(spamsites $1.$2 $) $| $3 R$*.REJECT $| $* $#error $: 521 blocked. contact postmaster@FreeBSD.ORG ($1) # Host must be resolvable, currently not used at hub.freebsd.org #R$* $| $* $: <$1 $| $2> $>3 foo@$1 #R <$*> $*<@$*.> $: $1 #R <$*> $*<@$*> $#error $: 451 Domain does not resolve ($1) # called with envelope sender, "Mail From: xxx", of SMTP conversation # Scheck_mail R$* $: $>3 $1 R $* < @ $+ . > $: $2 # R $* < @ $+ > $#error $: "451 Domain does not resolve" R $* < @ $+ > $: $2 R$+.$+.$+ $2.$3 R$* $: $(spamsites $1 $: OK $) ROK $@ OK R$+.REJECT $#error $: 521 $1 # for testing check_relay and check_mail # if we type "$|", sendmail will split this into two tokens "$" and "|" # this rule glues prevent sendmail from splitting "$|" # to use: /usr/sbin/sendmail -bt # host.domain.tld $| 111.222.333.444 Sxlat R$* $$| $* $: $1 $| $2 R$* $| $* $@ $>check_relay $1 $| $2 From owner-freebsd-hackers Sat Nov 15 16:34:23 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id QAA06914 for hackers-outgoing; Sat, 15 Nov 1997 16:34:23 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from d198-232.uoregon.edu (d198-232.uoregon.edu [128.223.198.232]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id QAA06907 for ; Sat, 15 Nov 1997 16:34:19 -0800 (PST) (envelope-from mini@d198-232.uoregon.edu) Received: (from mini@localhost) by d198-232.uoregon.edu (8.8.5/8.8.5) id QAA15844; Sat, 15 Nov 1997 16:34:00 -0800 (PST) Message-ID: <19971115163359.29992@micron.mini.net> Date: Sat, 15 Nov 1997 16:33:59 -0800 From: Jonathan Mini To: hackers@freebsd.org Subject: VESA VBE 1.2 and 2.0 library Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.85e X-files: The Truth is Out There Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I am developing a library which will provide VESA VBE 1.2 and 2.0 support for FreeBSD. It works as follows : 1) There is a device in the kernel which provides memory mappings for the video card, and (if needed) a virtual framebuffer mapping in kernel memory. (this ensures that the framebuffer won't get swapped out) 2) a vm86 daemon which contains mappings to the virtual framebuffer (if in use) and io privelege to the video card's I/O space. This daemon has two purposes : one, it performs VBE calls requested by the vesa device and returns the results (often data tables) where the vesa device can reach them to pass back to the caller. 3) A library which acts as a front-end for the vesa device and hides the whole interface between the vesa device and userland. It also will manage contention against syscons, if enabled. (For example, it will handle switching between vtys, changing the keyboard mode, etc) This provides support for all VESA VBE video modes on any card which supports 1.2 or better of the spec. (I have never seen a card which did not suport at least VBE 1.2, and this is including old 8 bit VGA wanna-be cards that are so slow you would never want to use one) It will also use a linear framebuffer if the card provides it, and if not, a virtual frambuffer will be made available. The virtual framebuffer is much slower, but it works. So, I am officially requesting a major number to be assigned to me for the device 'vesa' which provides the memory mappings needed for this system to work. -- Jonathan Mini Ingenious Productions Software Development P.O. Box 5693, Eugene, Or. 97405 "A child of five could understand this! Quick -- Fetch me a child of five." From owner-freebsd-hackers Sat Nov 15 17:28:56 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id RAA09068 for hackers-outgoing; Sat, 15 Nov 1997 17:28:56 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from kott.my.domain (root@pm234-06.dialip.mich.net [198.110.144.138]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id RAA09063 for ; Sat, 15 Nov 1997 17:28:53 -0800 (PST) (envelope-from dakott@kott.my.domain) Received: from kott.my.domain (dakott@kott.my.domain [192.168.0.1]) by kott.my.domain (8.8.8/8.8.5) with SMTP id FAA01577; Sat, 15 Nov 1997 05:46:42 -0500 (EST) Date: Sat, 15 Nov 1997 05:46:02 -0500 (EST) From: David Kott To: Charlie Root cc: hackers@FreeBSD.ORG Subject: Re: I have this problem In-Reply-To: <199711140944.BAA00493@love.MCCP.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Fri, 14 Nov 1997, Charlie Root wrote: > > I want to play mp3 files, and it plays but, > it is like i do not have enough buffering space... > > Sound: DMA timed out - IRQ/DRQ config error? Is your LPT port using that interrupt? You may not share interrupts. If this is the problem, you may configure your lpt driver for polling only, thus saving yourself that precious IRQ line. Change: device lpt0 at isa? port? tty irq 7 vector lptintr in your kernel config. file to: device lpt0 at isa? port? tty recompile, etc. > > P.S. under Win95 it works perfectly.... so I do not think it is hardware > problem ; -) You're using logic. Doesn't work with '95... '95 is "intuitive" *quiver* -d From owner-freebsd-hackers Sat Nov 15 18:09:59 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id SAA10652 for hackers-outgoing; Sat, 15 Nov 1997 18:09:59 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from Kitten.mcs.com (Kitten.mcs.com [192.160.127.90]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id SAA10647 for ; Sat, 15 Nov 1997 18:09:56 -0800 (PST) (envelope-from nash@Jupiter.Mcs.Net) Received: from Jupiter.Mcs.Net (nash@Jupiter.mcs.net [192.160.127.88]) by Kitten.mcs.com (8.8.5/8.8.2) with ESMTP id UAA24219; Sat, 15 Nov 1997 20:09:55 -0600 (CST) Received: from localhost (nash@localhost) by Jupiter.Mcs.Net (8.8.7/8.8.2) with SMTP id UAA16267; Sat, 15 Nov 1997 20:09:55 -0600 (CST) Date: Sat, 15 Nov 1997 20:09:55 -0600 (CST) From: Alex Nash To: Andreas Klemm cc: hackers@FreeBSD.ORG Subject: Re: kernel options for turning off source routing and ip accounting ? In-Reply-To: <19971115231043.02073@klemm.gtn.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Sat, 15 Nov 1997, Andreas Klemm wrote: > Just read an article about Linux as firewall system and noticed > the ability to turn off source routing and turn on ip accounting. > > http://www.linux-magazin.de/ > > Do we also have such options ? Source routing: sysctl net.inet.ip.sourceroute Accounting: man ipfw I'll give you one guess as to where the original firewall code in Linux comes from :) Alex From owner-freebsd-hackers Sat Nov 15 18:18:54 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id SAA11012 for hackers-outgoing; Sat, 15 Nov 1997 18:18:54 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from misery.sdf.com (misery.sdf.com [204.244.210.193]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id SAA11001 for ; Sat, 15 Nov 1997 18:18:50 -0800 (PST) (envelope-from tom@sdf.com) Received: from tom by misery.sdf.com with smtp (Exim 1.73 #1) id 0xWuAt-0004lH-00; Sat, 15 Nov 1997 18:10:59 -0800 Date: Sat, 15 Nov 1997 18:10:57 -0800 (PST) From: Tom To: Andreas Klemm cc: hackers@freebsd.org Subject: Re: kernel options for turning off source routing and ip accounting ? In-Reply-To: <19971115231043.02073@klemm.gtn.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Sat, 15 Nov 1997, Andreas Klemm wrote: > Just read an article about Linux as firewall system and noticed > the ability to turn off source routing and turn on ip accounting. > > http://www.linux-magazin.de/ > > Do we also have such options ? This doesn't belong on the hackers list. See sysctl to turn off source routing. It defaults to off already. See ipfw to do packet accounting. > Andreas /// > > -- > Andreas Klemm > powered by ,,symmetric multiprocessor FreeBSD'' Tom From owner-freebsd-hackers Sat Nov 15 18:37:17 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id SAA11648 for hackers-outgoing; Sat, 15 Nov 1997 18:37:17 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from seidata.com (seidata.com [206.160.242.33]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id SAA11643 for ; Sat, 15 Nov 1997 18:37:06 -0800 (PST) (envelope-from mike@seidata.com) Received: from seidata.com ([208.10.211.44]) by seidata.com (8.8.7/8.8.5) with ESMTP id VAA01548; Sat, 15 Nov 1997 21:37:49 -0500 (EST) Message-ID: <346DB2C6.B13C80EC@seidata.com> Date: Sat, 15 Nov 1997 09:33:42 -0500 From: Mike Hoskins X-Mailer: Mozilla 4.03 [en] (Win95; I) MIME-Version: 1.0 To: bicknell@ufp.org, freebsd-hackers@freebsd.org Subject: Re: AHC / SCSI Problem? References: <199711131520.KAA09225@ussenterprise.ufp.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Leo Bicknell wrote: > We've been having some problems here with FreeBSD, > Adaptec 2940's, and various disk drives. I think we're > I do find it interesting that it happens on the Micropolis > 4221 disks. Perhaps there is something "special" about them. I would like to hear feedback relating to Adaptec's 2940 controller and Micropolis drives myself... What is the status? Are there still any bug(s) being worked out? We're running a dual Pentium Pro 200 with an Adaptec 2940 and two 4221s. Some time ago, we tried the 3.0 SMP kernel and had a serious problem... random reboots. This is a primary DNS box and we've since reverted back to 2.2.5-STABLE for a key feature - reliability. ;) > I have a theory myself that turning on TAGENABLE and > SCBPAGING_ENABLE might actually help this situation, but > I'm not going to try it unless an expert thinks this is a > good idea as well. These are both production machines, so > experimenting is a problem, but if we have some good leads > we can do some work to track this down. TAGENABLE was definately recommended to us (I think it may have even been a BSD team member?), and possibly SCBPAGIN_ENABLE. The powers that be, however, decieded to revert to STABLE until "all SMP problems are ironed out", so we never gave it a try. I've heard that the problems we were encountering have been fixed, but I'd like to be selfish and see if someone else running the same setup gets lucky before I give it a go again. --- Mike Hoskins SEI Data Network Services, Inc. mike@seidata.com From owner-freebsd-hackers Sat Nov 15 18:50:25 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id SAA12269 for hackers-outgoing; Sat, 15 Nov 1997 18:50:25 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from nomis.i-connect.net (nomis.i-Connect.Net [206.190.143.100]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id SAA12263 for ; Sat, 15 Nov 1997 18:50:21 -0800 (PST) (envelope-from shimon@i-connect.net) Received: (qmail 26928 invoked by uid 1000); 16 Nov 1997 02:50:50 -0000 Message-ID: X-Mailer: XFMail 1.2-beta-111097 [p0] on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit MIME-Version: 1.0 Date: Sat, 15 Nov 1997 18:50:50 -0800 (PST) Organization: Atlas Telecom From: Simon Shapiro To: freebsd-hackers@freebsd.org Subject: ping: sendto: No buffer space available Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I am getting this from a de Ethernet card. Setup: Nomis with Adaptec 4 ports card. >--- Connected via Category 5 cable Copper with Intel Pro/100B card. Cabling is known good. Fxp card known good Adaptec card, under eval. Nomis ifconfig: de0: flags=8c43 mtu 1500 inet 192.168.10.1 netmask 0xffffff00 broadcast 192.168.10.255 ether 00:00:92:a7:62:c1 media: autoselect (100baseTX ) status: active supported media: autoselect 100baseTX 100baseTX 10baseT/UT Pinging 192.168.10.10 (copper) does not cause any LED to blink. Pinging 192.168.10.1 (nomis) blinks the LEDs. The connection on the fxp0, on copper is known good (will talk to other fxp, etc.) Pinging from nomis (on the de0), brings no results, only ``host is down''. After 10-15 minutes the subject line appears. Oh, /etc/rc.conf on nomis (home of the de0): network_interfaces="fpa0 fxp0 de0 de1 de2 de3 lo0" ifconfig_de0="inet 192.168.10.1 netmask 255.255.255.0" Netstat -rn: Internet: Destination Gateway Flags Refs Use Netif Expire default 206.190.143.2 UGSc 8 2528 ppp0 127.0.0.1 127.0.0.1 UH 1 56 lo0 192.168 link#2 UC 0 0 192.168.0.255 ff.ff.ff.ff.ff.ff UHLWb 0 226 fpa0 192.168.10 link#3 UC 0 0 192.168.10.255 ff:ff:ff:ff:ff:ff UHLWb 0 6 de0 192.168.50 link#1 UC 0 0 192.168.50.255 ff:ff:ff:ff:ff:ff UHLWb 1 226 fxp0 206.190.143.2 206.190.143.100 UH 6 0 ppp0 206.190.143.100 127.0.0.1 UH 0 0 lo0 Help will be appreciated! --- If Microsoft Built Cars: There would be an "Engine Pro" with bigger turbos, but it would be slower on most existing roads. Sincerely Yours, Simon Shapiro Atlas Telecom Senior Architect 14355 SW Allen Blvd., Suite 130 Beaverton OR 97005 Shimon@i-Connect.Net Voice: 503.799.2313 From owner-freebsd-hackers Sat Nov 15 18:59:08 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id SAA12654 for hackers-outgoing; Sat, 15 Nov 1997 18:59:08 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from pcpsj.pfcs.com (NJm/TUZvWWqMWjU7+b5QWw146IrRu+D9@harlan.fred.net [205.252.219.31]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id SAA12640 for ; Sat, 15 Nov 1997 18:59:00 -0800 (PST) (envelope-from harlan@mumps.pfcs.com) Received: from mumps.pfcs.com (mumps.pfcs.com [192.52.69.11]) by pcpsj.pfcs.com (8.8.6/8.6.9) with SMTP id VAA06034 for ; Sat, 15 Nov 1997 21:58:11 -0500 (EST) Received: from localhost by mumps.pfcs.com with SMTP id AA09218 (5.67b/IDA-1.5 for ); Sat, 15 Nov 1997 21:58:10 -0500 To: hackers@freebsd.org Subject: mkmodules? Date: Sat, 15 Nov 1997 21:58:09 -0500 Message-Id: <9216.879649089@mumps.pfcs.com> From: Harlan Stenn Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk What happened to the mkmodules program? It doesn't seem to be build anymore (at least in -stable), and I'd like to be using CVS for other things. What's the best way to proceed here? Should I just Make It Happen? H From owner-freebsd-hackers Sat Nov 15 19:53:03 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id TAA15142 for hackers-outgoing; Sat, 15 Nov 1997 19:53:03 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from seidata.com (seidata.com [206.160.242.33]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id TAA15136 for ; Sat, 15 Nov 1997 19:53:00 -0800 (PST) (envelope-from mike@seidata.com) Received: from seidata.com ([208.10.211.44]) by seidata.com (8.8.7/8.8.5) with ESMTP id WAA10347; Sat, 15 Nov 1997 22:53:55 -0500 (EST) Message-ID: <346DC49C.A7B47F31@seidata.com> Date: Sat, 15 Nov 1997 10:49:48 -0500 From: Mike Hoskins X-Mailer: Mozilla 4.03 [en] (Win95; I) MIME-Version: 1.0 To: bicknell@ufp.org CC: freebsd-hackers@FreeBSD.ORG Subject: Re: AHC / SCSI UPDATE References: <199711141548.KAA17951@ussenterprise.ufp.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Leo Bicknell wrote: > How do I go about verifing that it is a driver bug, > or a SCSI incompatability between the Micropolis and > the Adaptec? Well, we reverted back to 2.2.5-STABLE from an earlier SMP release due to reboots and lockups that appeared to relate to the Adeptec 2940 and Micropolis drives... and we did not have a DAT drive in the system at the time. We did, however, NOT try a recompile with TAGENABLE. I would like to know what kind of, if any, problems persist after a recompile with the TAGENABLE flag on. Something for me/us to play with, eh? ;) --- Mike Hoskins SEI Data Network Services, Inc. mike@seidata.com From owner-freebsd-hackers Sat Nov 15 20:09:56 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id UAA15839 for hackers-outgoing; Sat, 15 Nov 1997 20:09:56 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: (from jmb@localhost) by hub.freebsd.org (8.8.7/8.8.7) id UAA15831; Sat, 15 Nov 1997 20:09:52 -0800 (PST) (envelope-from jmb) From: "Jonathan M. Bresler" Message-Id: <199711160409.UAA15831@hub.freebsd.org> Subject: Re: /etc/mail filters in 2.2.5 To: brian@awfulhak.org (Brian Somers) Date: Sat, 15 Nov 1997 20:09:52 -0800 (PST) Cc: freebsd-hackers@FreeBSD.org In-Reply-To: <199711160010.AAA22259@awfulhak.demon.co.uk> from "Brian Somers" at Nov 16, 97 00:10:14 am X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-freebsd-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk Brian, there are a couple issues here: Brian Somers wrote: > I installed the /etc/mail stuff a few days ago, and added a few sites > to domains.txt, specifically: > > BIGFOOT.DALTEK.NET^M #blocked. contact postmaster first, that "^M" is it in the file? is so please delete it. after deleting the "^M" cd /etc/mail; make install second, the way i wrote the rules, they block mail from a domain, hence the file is called domains.txt ;) bigfoot.daltek.net is a host, rather than a domain. you can change the entry domains.txt to "daltek.net". that will block mail from all of daltek.net. or you can use the amended rules below to block mail from both hosts and domains. then you can use entries like "bigfoot.daltek.net" in domains.txt. add the rules below that are *not* preceded by a ">" at the start of the line ;) jmb > # called with host.tld and IP address of connecting host. > # ip address must NOT be in the "denyip" database > Scheck_relay > R$* $| [$+ $1 $| $2 should not be needed > R$* $| $+] $1 $| $2 same (bat 2nd ed p510) > R$* $| $* $: $1 $| $(denyip $2 $) > R$* $| $*.REJECT $#error $: 521 blocked. contact postmaster@FreeBSD.ORG ($2) > # host must *not* be in the "spamsites" database R$+.$+.$+ $| $* $: $(spamsites $1.$2.$3 $) $1.$2.$3 $| $4 R$*.REJECT $* $| $* $#error $: 521 blocked. > R$+.$+.$+ $| $* $2.$3 $| $4 > R$+.$+ $| $* $: $(spamsites $1.$2 $) $| $3 > R$*.REJECT $| $* $#error $: 521 blocked. contact postmaster@FreeBSD.ORG ($1) > # Host must be resolvable, currently not used at hub.freebsd.org > #R$* $| $* $: <$1 $| $2> $>3 foo@$1 > #R <$*> $*<@$*.> $: $1 > #R <$*> $*<@$*> $#error $: 451 Domain does not resolve ($1) > > # called with envelope sender, "Mail From: xxx", of SMTP conversation > # > Scheck_mail > R$* $: $>3 $1 > R $* < @ $+ . > $: $2 > # R $* < @ $+ > $#error $: "451 Domain does not resolve" > R $* < @ $+ > $: $2 R$+.$+.$+ $: $(spamsites $1.$2.$3 $) $1.$2.$3 R$*.REJECT $* $#error $: 521 blocked. > R$+.$+.$+ $2.$3 > R$* $: $(spamsites $1 $: OK $) > ROK $@ OK > R$+.REJECT $#error $: 521 $1 > > # for testing check_relay and check_mail > # if we type "$|", sendmail will split this into two tokens "$" and "|" > # this rule glues prevent sendmail from splitting "$|" > # to use: /usr/sbin/sendmail -bt > # host.domain.tld $| 111.222.333.444 > Sxlat > R$* $$| $* $: $1 $| $2 > R$* $| $* $@ $>check_relay $1 $| $2 > > > From owner-freebsd-hackers Sat Nov 15 21:06:45 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id VAA18346 for hackers-outgoing; Sat, 15 Nov 1997 21:06:45 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from austin.polstra.com (austin.polstra.com [206.213.73.10]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id VAA18334 for ; Sat, 15 Nov 1997 21:06:37 -0800 (PST) (envelope-from jdp@austin.polstra.com) Received: from austin.polstra.com (jdp@localhost) by austin.polstra.com (8.8.7/8.8.7) with ESMTP id VAA26780 for ; Sat, 15 Nov 1997 21:06:36 -0800 (PST) (envelope-from jdp) Message-Id: <199711160506.VAA26780@austin.polstra.com> To: hackers@freebsd.org Subject: Problems with BusTek SCSI controller and CD-ROM Date: Sat, 15 Nov 1997 21:06:36 -0800 From: John Polstra Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I have an old ISA bus machine with a BusTek (now BusLogic) BT542 SCSI controller. It works fine with the two hard drives that I have installed. But when I added a Plextor 4x CD-ROM drive today, it caused the system to hang during the probe of the controller. The last message on the console before the hang is: bt0: reading board settings, dma=5, int=11 If I wait several minutes, it eventually gives a further message "bt0: not taking commands!". Then it drops into the kernel debugger. I get identical failures with a -current system from late September and with a 2.2.2 boot floppy. It's not a problem with termination, and I've tried rearranging the devices on the SCSI bus without results. The power-up messages from the controller's BIOS show that it recognizes the CD-ROM drive as well as both hard disks. And booting from hard disk (up until the hang) works fine. Also, if I boot from a DOS floppy with the appropriate drivers on it, DOS talks to all the devices without problems. So this seems to be a problem specific to FreeBSD. Any ideas? John -- John Polstra jdp@polstra.com John D. Polstra & Co., Inc. Seattle, Washington USA "Self-knowledge is always bad news." -- John Barth From owner-freebsd-hackers Sat Nov 15 21:12:53 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id VAA18590 for hackers-outgoing; Sat, 15 Nov 1997 21:12:53 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from pluto.plutotech.com (mail.plutotech.com [206.168.67.137]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id VAA18559; Sat, 15 Nov 1997 21:12:45 -0800 (PST) (envelope-from gibbs@plutotech.com) Received: from narnia.plutotech.com (narnia.plutotech.com [206.168.67.130]) by pluto.plutotech.com (8.8.7/8.8.5) with ESMTP id WAA24691; Sat, 15 Nov 1997 22:11:59 -0700 (MST) Message-Id: <199711160511.WAA24691@pluto.plutotech.com> X-Mailer: exmh version 2.0zeta 7/24/97 To: harold barker Hbarker cc: hackers@FreeBSD.org, scsi@FreeBSD.org, aic7xxx@FreeBSD.org Subject: Re: AHC / SCSI UPDATE Date: Sat, 15 Nov 1997 22:10:52 -0700 From: "Justin T. Gibbs" Sender: owner-freebsd-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk Sorry for not responding sooner, but I don't read this list regularly anymore... >If the person responsible for the code in question will email me, i will >ship/open for login a machine that exibits the broblem. That would be me, but I do believe that I have a system here that exibits the same problem you are having. When I have a fix for this machine, I might take you up on your offer if it doesn't seem to work with your equipment. Here's a little info about what we (Ken Merry and myself) have determined about the problem so far. System: P6-233 256k cache 2940UW (SCSI ID 7) 1 X PLEXTOR CD-ROM PX-4XCS 1.04 (SCSI ID 4) 2 X QUANTUM XP34550W LXY4 (SCSI IDs 0 and 1) How to repeat: run concurrent I/O to all 3 devices at the same time. Symptom: After a varying period of time, disk 0 or 1 stops performing reselections for it's outstanding I/O. This eventually results in a timeout, usually with the controller in an "idle" state. Using a SCSI bus analyzer, we've looked at the transactions on the bus that lead up to this state. No protocol errors were discovered. What we did find, however, was a disturbing pattern of disconnections and reconnections from the CDROM drive. The plextor seems to perform disconnections "often enough" to allow other targets to perform a reselection, but unfortunately seems to partake in the next arbitration phase if it has a task to continue. Since the arbitration algorithm breaks "ties" based on the SCSI ID (from highest to lowest priority 7->0, 15->8), this effectively gives the CD drive the bus for as long as it wants it. Since the CD drive only handles a single task at a time, one would think that there would be plenty of time that the CD was idle and not wanting the bus. Unforunately, it seems that the SCSI system/ aic7xxx driver is fast enough to process a command completion for the CD drive, setup a new command to send, and participate in the next arbitration phase. As the controller has the highest priority ID on the bus, this again "starves" the drives and opens the possibility for the CD drive to start requesting the bus. In the end, what I believe is happening is that the drive exhausts it's "reconnect attempt" count, and decides not to attempt to contact the initiator again. In the case of an Atlas II, if the initiator selects the drive (say to send an abort or abort tag message), the drive starts making reconnection attempts again and the wedge is cleared. Other drives may not behave as nicely. So, what can be done about this? I'm currently looking through the SCSI II and III specs to determine what the standard has to say about reconnect attempt failures and how to properly deal with them. It may be that the SCSI layer/Adaptec driver can take actions that will work on most devices. For a more immediate fix, I suggest experimenting with: 1) Swapping the IDs on your devices so that hard drives have higher arbitration priority on the bus. The Adaptec BIOS will still find your disks in the proper order for you to boot even if you stick your CDROM or tape drive's IDs down before the hard disks. 2) Playing with the settings in the Disconnect-Reconnect mode Page (page #0x2). Try setting the "Disconnect Time Limit" variable to something other than 0. This is the time, in hundredths of a millisecond, the device waits after disconnecting before participating in arbitration. For many of you, I would expect solution 1 to work just fine. For those of you with lots of disks on a single chain (even if you don't have a tape or cdrom drive), you will probably have to try solution #2. Remeber that it's not really the type of device that matters, but the possibility of starvation. If you have lots of concurrent I/O going on to multiple disks on a single chain, you can still experience this problem (Hi Satoshi!). More information when it becomes available. -- Justin From owner-freebsd-hackers Sat Nov 15 21:15:57 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id VAA18741 for hackers-outgoing; Sat, 15 Nov 1997 21:15:57 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from spokane.vmunix.com (p22a.lithium.sentex.ca [207.245.212.183]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id VAA18701 for ; Sat, 15 Nov 1997 21:15:47 -0800 (PST) (envelope-from mark@spokane.vmunix.com) Received: (from mark@localhost) by spokane.vmunix.com (8.8.7/8.8.7) id AAA07590; Sun, 16 Nov 1997 00:17:11 -0500 (EST) Message-ID: <19971116001710.02627@vmunix.com> Date: Sun, 16 Nov 1997 00:17:10 -0500 From: Mark Mayo To: hackers@freebsd.org Subject: de underflow errors. huh? Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.85e X-Operating-System: FreeBSD 2.2-STABLE i386 Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I posted this questions 2 weeks ago on -questions, and 1 week ago on -stable (since it's happening on a -STABLE machine..) but I haven't got a response yet. So here it is for the -hackers crowd: I've got a firewall machine with 2 ethernet cards. One Digital 21040 based card on de0, and one Intel Pro/100B on fxp0. Everything seems to be working fine, with the exception of numerous errors on the console: de0: abnormal interrupt: transmit underflow I have no clue what this means. Packets seem to be flowing through the interface nicely, and there is no noticeable packet loss. If anyone has any ideas what could be causing this, or if I should give a hoot, please let me know. TIA, -Mark P.S. The machine is up to date on the 2.2.5-STABLE branch (releng22). -- ------------------------------------------------------------------------ Mark Mayo mark@vmunix.com RingZero Comp. http://www.vmunix.com/mark finger mark@vmunix.com for my PGP key and GCS code ------------------------------------------------------------------------ Win95/NT - 32 bit extensions and a graphical shell for a 16 bit patch to an an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition. -UGU From owner-freebsd-hackers Sat Nov 15 21:22:07 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id VAA19236 for hackers-outgoing; Sat, 15 Nov 1997 21:22:07 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from zippy.dyn.ml.org (libya-202.ppp.hooked.net [206.169.227.202]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id VAA19231 for ; Sat, 15 Nov 1997 21:22:01 -0800 (PST) (envelope-from garbanzo@hooked.net) Received: from localhost (garbanzo@localhost) by zippy.dyn.ml.org (8.8.7/8.8.7) with SMTP id VAA00417; Sat, 15 Nov 1997 21:22:38 -0800 (PST) X-Authentication-Warning: zippy.dyn.ml.org: garbanzo owned process doing -bs Date: Sat, 15 Nov 1997 21:22:38 -0800 (PST) From: Alex X-Sender: garbanzo@zippy.dyn.ml.org To: Tom cc: hackers@FreeBSD.ORG Subject: Re: 256Meg In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Fri, 14 Nov 1997, Tom wrote: > > On Fri, 14 Nov 1997, dennis wrote: > > > Is there a maximum that FreeBSD can support? > > > > Dennis > > > What? Filesystems? RAM? Something else? > > RAM... no problem. I'm running two 256MB RAM servers now. Actually, there's a limit of 4GB or so of ram, on the 486 (if you call tha ta limit ;-) ), and AFAIK the P5, P6 and PII and clones as well. - alex From owner-freebsd-hackers Sat Nov 15 21:51:56 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id VAA20740 for hackers-outgoing; Sat, 15 Nov 1997 21:51:56 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from trojanhorse.ml.org (mdean.vip.best.com [206.86.94.101]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id VAA20731 for ; Sat, 15 Nov 1997 21:51:50 -0800 (PST) (envelope-from jamil@trojanhorse.ml.org) Received: from localhost (jamil@localhost) by trojanhorse.ml.org (8.8.8/8.8.5) with SMTP id VAA00433 for ; Sat, 15 Nov 1997 21:51:39 -0800 (PST) Date: Sat, 15 Nov 1997 21:51:39 -0800 (PST) From: "Jamil J. Weatherbee" To: freebsd-hackers@freebsd.org Subject: AIOX Analog driver statistical analysis Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I conducted a number of test trials doing 12bit analog sampling across 48 channels with this board and driver. The system is freebsd-2.2.5 stable with aiox driver, AIO8-P analog board and 3 external multiplexers, 48 channels total are being sampled. This is a NexGen-100 Disklessly booting system. I don't know what the computational/io performance is compared to something like a PPro but I plan on running it on a PPro-180 and finding out. The cpu time is for the driver and a process using sleeping on select to determine which channels to read. Aggregate Sample Frequency Percent Cpu Time 32 hz 2% 62.5 hz 3% 125 hz 6.2% 250 hz 12.5% 500 hz 25% 1000 hz 45% 2000 hz 90% 16000 hz Saturated But No Overruns The performance is linear (below saturation) and the sample freq to percent cpu has a 99.9% correlation. The equation: %Cpu = 0.9477 + 0.044606*(Sample Freq) Gives a very good approximation of %Cpu I wonder just how much faster a PPro or Pentium is then a NexGen machine (this is in purely integer performance since I am not doing any calculations in the user process). Keep in mind that select returns as soon as a single entry is available in any channels fifo. I am thinking about adding an ioctl() that would allow the user to specify a select() trigger point, say they could tell the driver to not do a selwakeup() unless the fifo is more than half full. Of course using blocking I/O with huge buffers solves this a bit (and I will be testing that also), but that precludes any kind of virtual multitasking in a single code thread for multiple channels. From owner-freebsd-hackers Sat Nov 15 23:12:14 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id XAA24007 for hackers-outgoing; Sat, 15 Nov 1997 23:12:14 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from trojanhorse.ml.org (mdean.vip.best.com [206.86.94.101]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id XAA23999 for ; Sat, 15 Nov 1997 23:12:11 -0800 (PST) (envelope-from jamil@trojanhorse.ml.org) Received: from localhost (jamil@localhost) by trojanhorse.ml.org (8.8.8/8.8.5) with SMTP id XAA00656 for ; Sat, 15 Nov 1997 23:12:01 -0800 (PST) Date: Sat, 15 Nov 1997 23:12:01 -0800 (PST) From: "Jamil J. Weatherbee" To: freebsd-hackers@freebsd.org Subject: 20x increase in efficiency with Select() trigger optimization on AIOX driver In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > Keep in mind that select returns as soon as a single entry is available in > any channels fifo. I am thinking about adding an ioctl() that would allow > the user to specify a select() trigger point, say they could tell the > driver to not do a selwakeup() unless the fifo is more than half full. Of I did some tests and found that increase fifo size to more than 64 entries had no significant effect on efficiency, however trigger code on the 64 entry fifo setting a trigger at 48 entries for selwakeup had a significant effect: The new figures Aggregrate Sample Frequency Percent Cpu Time <2000 hz Negligible (1%-10%) 3500 hz 15% 4000 hz Saturated It is very curious, I can run AD_MICRO_PERIOD down to 280 us with 15% cpu, so even running the user process rtprio, I can still log in to the machine and there is no noticeable effect in performance for other things. (i.e. it is still interactive) However set AD_MICRO_PERIOD down another 30us to 250us and the CPU is saturated, clearly a hardware limitation. Even huge fifos (x4 - x8) have no effect on this. The old figures > > Aggregate Sample Frequency Percent Cpu Time > > 32 hz 2% > 62.5 hz 3% > 125 hz 6.2% > 250 hz 12.5% > 500 hz 25% > 1000 hz 45% > 2000 hz 90% > 16000 hz Saturated But No Overruns > > The performance is linear (below saturation) and the sample freq to > percent cpu has a 99.9% correlation. The equation: > > %Cpu = 0.9477 + 0.044606*(Sample Freq) > > Gives a very good approximation of %Cpu > > I wonder just how much faster a PPro or Pentium is then a NexGen machine > (this is in purely integer performance since I am not doing any > calculations in the user process). > From owner-freebsd-hackers Sat Nov 15 23:19:24 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id XAA24253 for hackers-outgoing; Sat, 15 Nov 1997 23:19:24 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from misery.sdf.com (misery.sdf.com [204.244.210.193]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id XAA24244 for ; Sat, 15 Nov 1997 23:19:19 -0800 (PST) (envelope-from tom@sdf.com) Received: from tom by misery.sdf.com with smtp (Exim 1.73 #1) id 0xWysC-0004sH-00; Sat, 15 Nov 1997 23:12:00 -0800 Date: Sat, 15 Nov 1997 23:11:58 -0800 (PST) From: Tom To: Mark Mayo cc: hackers@freebsd.org Subject: Re: de underflow errors. huh? In-Reply-To: <19971116001710.02627@vmunix.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Sun, 16 Nov 1997, Mark Mayo wrote: > I posted this questions 2 weeks ago on -questions, and 1 week ago > on -stable (since it's happening on a -STABLE machine..) but I > haven't got a response yet. So here it is for the -hackers crowd: Repeating what I heard: this happens when your machine can't get data to the card fast enough, so the card drains the buffer, but more data is waiting. This warning should be harmless, as the buffer size is adjusted afterwards. You might want to look into BIOS settings which may be hampering PCI performance. Tom From owner-freebsd-hackers Sat Nov 15 23:23:53 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id XAA24488 for hackers-outgoing; Sat, 15 Nov 1997 23:23:53 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from smtp03.primenet.com (smtp03.primenet.com [206.165.5.84]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id XAA24483 for ; Sat, 15 Nov 1997 23:23:50 -0800 (PST) (envelope-from tlambert@usr06.primenet.com) Received: (from daemon@localhost) by smtp03.primenet.com (8.8.7/8.8.7) id AAA22280; Sun, 16 Nov 1997 00:23:49 -0700 (MST) Received: from usr06.primenet.com(206.165.6.206) via SMTP by smtp03.primenet.com, id smtpd022230; Sun Nov 16 00:23:43 1997 Received: (from tlambert@localhost) by usr06.primenet.com (8.8.5/8.8.5) id AAA08576; Sun, 16 Nov 1997 00:23:41 -0700 (MST) From: Terry Lambert Message-Id: <199711160723.AAA08576@usr06.primenet.com> Subject: Re: AIOX Analog driver statistical analysis To: jamil@trojanhorse.ml.org (Jamil J. Weatherbee) Date: Sun, 16 Nov 1997 07:23:41 +0000 (GMT) Cc: freebsd-hackers@FreeBSD.ORG In-Reply-To: from "Jamil J. Weatherbee" at Nov 15, 97 09:51:39 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > Keep in mind that select returns as soon as a single entry is available in > any channels fifo. I am thinking about adding an ioctl() that would allow > the user to specify a select() trigger point, say they could tell the > driver to not do a selwakeup() unless the fifo is more than half full. Of > course using blocking I/O with huge buffers solves this a bit (and I will > be testing that also), but that precludes any kind of virtual multitasking > in a single code thread for multiple channels. If it blocking I/O solves the problem, and the only thing you are doing is I/O processing (ie: you don't plan to use select to poll the device and do other things) you might consider "packetizing" data from the device. You would do this by writing a byte indicating the channel in front of each "packet" of data on the channel. (ie: if the first character read is "0x05", then the remaining data from that read is from channel 5, etc.). Effectively, you would have a device MUX. This would let you use a single read to read all channels, and block in user space pending data on any active channel. Alternately, you could "select" on the devices in user space using the select system call, with a timeout, to provide a virtual task manager for other devices if you needed that. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Sat Nov 15 23:42:38 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id XAA25133 for hackers-outgoing; Sat, 15 Nov 1997 23:42:38 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from dyson.iquest.net (dyson.iquest.net [198.70.144.127]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id XAA25128 for ; Sat, 15 Nov 1997 23:42:31 -0800 (PST) (envelope-from toor@dyson.iquest.net) Received: (from root@localhost) by dyson.iquest.net (8.8.7/8.8.5) id CAA12053; Sun, 16 Nov 1997 02:42:20 -0500 (EST) From: "John S. Dyson" Message-Id: <199711160742.CAA12053@dyson.iquest.net> Subject: Re: 256Meg In-Reply-To: from Alex at "Nov 15, 97 09:22:38 pm" To: garbanzo@hooked.net (Alex) Date: Sun, 16 Nov 1997 02:42:20 -0500 (EST) Cc: tom@sdf.com, hackers@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-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Alex said: > > > On Fri, 14 Nov 1997, Tom wrote: > > > > > On Fri, 14 Nov 1997, dennis wrote: > > > > > Is there a maximum that FreeBSD can support? > > > > > > Dennis > > > > > > What? Filesystems? RAM? Something else? > > > > RAM... no problem. I'm running two 256MB RAM servers now. > > Actually, there's a limit of 4GB or so of ram, on the 486 (if you call > tha ta limit ;-) ), and AFAIK the P5, P6 and PII and clones as well. > Physically, the limit is 36Bits on a P6. It would require some mods to the pmap layer, and maybe some enhancements to the upper level VM code. One disadvantage with the extended 3 level translation mode is that the PTE's become twice as large. I seriously doubt that we'll need that on a P6, but on future Slot1/Slot2 processors, we might find that 4GB is a real limit, and have to accomodate the modified PTD/PTE format. Imagine a processor that is perhaps 2X to 5X as fast as a P6, in a multiprocessor config -- that would appear to be able to use more than the typical upper end of 1GByte of memory, and even more than the normally addressable 4Gbytes. I haven't given this alot of thought yet, but these issues are probably going to be important in the medium-term future (approx 1yr.) -- John dyson@freebsd.org jdyson@nc.com