From owner-freebsd-hardware Sun May 18 00:40:50 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id AAA16222 for hardware-outgoing; Sun, 18 May 1997 00:40:50 -0700 (PDT) Received: from kyyppari.hkkk.fi (k20418@kyyppari.hkkk.fi [128.214.33.3]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id AAA16210; Sun, 18 May 1997 00:40:42 -0700 (PDT) Received: (from k20418@localhost) by kyyppari.hkkk.fi (8.8.5/8.8.3) id KAA02245; Sun, 18 May 1997 10:35:00 +0300 (EET DST) From: Teemu Kuusijarvi Message-Id: <199705180735.KAA02245@kyyppari.hkkk.fi> Subject: Re: What Printer To Get - Postscript To: sos@sos.freebsd.dk (Søren Schmidt) Date: Sun, 18 May 1997 10:35:00 +0300 (EET DST) Cc: chuckr@mat.net, se@FreeBSD.ORG, dave@persprog.com, jgrosch@sirius.com, randyk@ccsales.com, freebsd-hardware@FreeBSD.ORG In-Reply-To: <199705162101.XAA19676@sos.freebsd.dk> from "Søren Schmidt" at May 16, 97 11:01:47 pm X-Mailer: ELM [version 2.4 PL24alpha5] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hardware@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > In reply to Chuck Robey who wrote: > > On Fri, 16 May 1997, Stefan Esser wrote: > > > > > 3) From what I've heard, there is no documentation about high > > > resolution graphics commands available for any HP printer. > > > The printer's manual does not even tell about the graphic > > > compression modes supported (but you can easily find them > > > by trying all of them). This limits printing to 300dpi, while > > > the actual physical resolution (pixel size on paper) appears > > > to be better, even on plain photo-copier paper (I did not yet > > > try printing on special color inkjet paper). > > > > Stefan, I thought all the inkjets used PCL5 as their language. If that's > > true, it's completely documented in stuff available from HP. > > No, the 870 uses PCL3+ whatever superset of PCL3 that might be... > I bought one a month or so ago, and it is endeed a nice printer. > > The only matter I still persue is that it prints much too colored > images, its like the color saturation has been set too high in > ghostscript. However it can probably be corrected by fiddeling > with ghostscript.... You get color output? I have 870Cxi and Aladdin ghostscript here at work and I have managed to get b/w only. Please tell me what driver you use and where to get it. TpK -- ---------------------------------------------- Teemu Kuusijarvi http://www.iki.fi/tpk/ email tpk@iki.fi -------------- FreeBSD 2.2.1 --------------- From owner-freebsd-hardware Sun May 18 08:46:52 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id IAA01358 for hardware-outgoing; Sun, 18 May 1997 08:46:52 -0700 (PDT) Received: from lundin.abq.nm.us. (lundin.abq.nm.us [198.59.115.228]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id IAA01351 for ; Sun, 18 May 1997 08:46:47 -0700 (PDT) Received: (from aflundi@localhost) by lundin.abq.nm.us. (8.8.5/8.8.5) id JAA07429; Sun, 18 May 1997 09:17:23 -0600 (MDT) Date: Sun, 18 May 1997 09:17:23 -0600 (MDT) From: Alan Lundin Message-Id: <199705181517.JAA07429@lundin.abq.nm.us.> In-Reply-To: Teemu Kuusijarvi "Re: What Printer To Get - Postscript" (May 18, 10:35am) X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: freebsd-hardware@freebsd.org.sos@sos.freebsd.dk (Søren Schmidt) Subject: Re: What Printer To Get - Postscript Sender: owner-hardware@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On May 18, 10:35am, Teemu Kuusijarvi wrote: > Subject: Re: What Printer To Get - Postscript > > [ ... ] > You get color output? I have 870Cxi and Aladdin ghostscript here at work > and I have managed to get b/w only. Please tell me what driver you use > and where to get it. Check out Uli Wortmann's Ghostscript driver for HP850's (works great for my 870 as well). You'll have to recompile ghostscript to add the new driver. Find his driver at ftp://bonk.ethz.ch/gs-driver-distrib/hp850.zip (He wrote it for OS/2, but it works fine under Unix as well.) BTW, the cdj550 also works fine with the 850/870 printers, but you don't get the CRet enhancements. --alan From owner-freebsd-hardware Sun May 18 13:56:12 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id NAA12188 for hardware-outgoing; Sun, 18 May 1997 13:56:12 -0700 (PDT) Received: from Sisyphos.MI.Uni-Koeln.DE (Sisyphos.MI.Uni-Koeln.DE [134.95.212.10]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id NAA12183 for ; Sun, 18 May 1997 13:56:10 -0700 (PDT) Received: from x14.mi.uni-koeln.de (annexr3-10.slip.Uni-Koeln.DE) by Sisyphos.MI.Uni-Koeln.DE with SMTP id AA15079 (5.67b/IDA-1.5 for ); Sun, 18 May 1997 22:56:05 +0200 Received: (from se@localhost) by x14.mi.uni-koeln.de (8.8.5/8.6.9) id WAA00484; Sun, 18 May 1997 22:43:12 +0200 (CEST) X-Face: " Date: Sun, 18 May 1997 22:43:11 +0200 From: Stefan Esser To: Alan Lundin Cc: freebsd-hardware@FreeBSD.ORG Subject: Re: What Printer To Get - Postscript References: <199705181517.JAA07429@lundin.abq.nm.us.> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.73 In-Reply-To: <199705181517.JAA07429@lundin.abq.nm.us.>; from Alan Lundin on Sun, May 18, 1997 at 09:17:23AM -0600 Sender: owner-hardware@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On May 18, Alan Lundin wrote: > Check out Uli Wortmann's Ghostscript driver for HP850's > (works great for my 870 as well). You'll have to recompile > ghostscript to add the new driver. Find his driver at > > ftp://bonk.ethz.ch/gs-driver-distrib/hp850.zip > > (He wrote it for OS/2, but it works fine under Unix as well.) That's great news ! I'll check out that driver, and will make sure it gets included into our Ghostscript ports, at least. Regards, STefan From owner-freebsd-hardware Sun May 18 14:03:41 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id OAA12455 for hardware-outgoing; Sun, 18 May 1997 14:03:41 -0700 (PDT) Received: from Sisyphos.MI.Uni-Koeln.DE (Sisyphos.MI.Uni-Koeln.DE [134.95.212.10]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id OAA12450 for ; Sun, 18 May 1997 14:03:38 -0700 (PDT) Received: from x14.mi.uni-koeln.de (annexr3-10.slip.Uni-Koeln.DE) by Sisyphos.MI.Uni-Koeln.DE with SMTP id AA15084 (5.67b/IDA-1.5 for ); Sun, 18 May 1997 22:56:26 +0200 Received: (from se@localhost) by x14.mi.uni-koeln.de (8.8.5/8.6.9) id WAA00464; Sun, 18 May 1997 22:39:53 +0200 (CEST) X-Face: " Date: Sun, 18 May 1997 22:39:52 +0200 From: Stefan Esser To: Teemu Kuusijarvi Cc: Sxren Schmidt , chuckr@mat.net, dave@persprog.com, jgrosch@sirius.com, randyk@ccsales.com, freebsd-hardware@FreeBSD.ORG Subject: Re: What Printer To Get - Postscript References: <199705162101.XAA19676@sos.freebsd.dk> <199705180735.KAA02245@kyyppari.hkkk.fi> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.73 In-Reply-To: <199705180735.KAA02245@kyyppari.hkkk.fi>; from Teemu Kuusijarvi on Sun, May 18, 1997 at 10:35:00AM +0300 Sender: owner-hardware@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On May 18, Teemu Kuusijarvi wrote: > You get color output? I have 870Cxi and Aladdin ghostscript here at work > and I have managed to get b/w only. Please tell me what driver you use > and where to get it. I'm currently using the following filter (reads from standard input and writes to standard output): gs -dSAFER -sQUIET -sDEVICE=cdj550 -sPAPERSIZE=a4 -dBitsPerPixel=32 -sOutputFile=- - (This is with Ghostscript 4.03, but any 3.x version should do, and possibly even 2.6.2 ...) The margins are a little off for A4 paper, but I didn't have time to find out the correct ones, yet. I bought that printer only a few days ago :) Regards, STefan From owner-freebsd-hardware Sun May 18 14:38:56 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id OAA14120 for hardware-outgoing; Sun, 18 May 1997 14:38:56 -0700 (PDT) Received: from wlk.com (news.wlk.com [192.86.83.250]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id OAA14115; Sun, 18 May 1997 14:38:47 -0700 (PDT) Received: from SMTPdaemon by wlk.com (smail3.2) with SMTPL id m0wTDfC-0009rgC; Sun, 18 May 1997 16:38:46 -0500 (CDT) Received: from critter (localhost [127.0.0.1]) by critter.dk.tfs.com (8.8.5/8.8.5) with ESMTP id XAA29106; Sun, 18 May 1997 23:35:17 +0200 (CEST) To: Stefan Esser cc: Alan Lundin , freebsd-hardware@FreeBSD.ORG From: Poul-Henning Kamp Subject: Re: What Printer To Get - Postscript In-reply-to: Your message of "Sun, 18 May 1997 22:43:11 +0200." <19970518224311.36342@x14.mi.uni-koeln.de> Date: Sun, 18 May 1997 23:35:17 +0200 Message-ID: <29104.863991317@critter> Sender: owner-hardware@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk In message <19970518224311.36342@x14.mi.uni-koeln.de>, Stefan Esser writes: >On May 18, Alan Lundin wrote: >> Check out Uli Wortmann's Ghostscript driver for HP850's >> (works great for my 870 as well). You'll have to recompile >> ghostscript to add the new driver. Find his driver at >> >> ftp://bonk.ethz.ch/gs-driver-distrib/hp850.zip >> >> (He wrote it for OS/2, but it works fine under Unix as well.) > >That's great news ! > >I'll check out that driver, and will make sure it >gets included into our Ghostscript ports, at least. To late! I committed it 30mins ago :-) -- Poul-Henning Kamp | phk@FreeBSD.ORG FreeBSD Core-team. http://www.freebsd.org/~phk | phk@login.dknet.dk Private mailbox. whois: [PHK] | phk@tfs.com TRW Financial Systems, Inc. Power and ignorance is a disgusting cocktail. From owner-freebsd-hardware Sun May 18 15:58:49 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id PAA20001 for hardware-outgoing; Sun, 18 May 1997 15:58:49 -0700 (PDT) Received: from laptop.nightflight.com ([207.135.216.195]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id PAA19981; Sun, 18 May 1997 15:58:44 -0700 (PDT) Received: (from root@localhost) by laptop.nightflight.com (8.8.5/8.8.5) id PAA01687; Sun, 18 May 1997 15:58:27 -0700 (PDT) Message-ID: X-Mailer: XFMail 1.0 [p0] on FreeBSD Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Date: Sun, 18 May 1997 15:47:52 -0700 (PDT) Organization: NightFlight From: Gary Crutcher To: freebsd-hardware@freebsd.org Subject: PCMMCIA card errors Cc: freebsd-questions@freebsd.org Sender: owner-hardware@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi, I have my PCMCIA ethernet card working on my laptop, but the following msg/error upon booting the system: ze: found card in slot 0 ze0: at 0x300-0x31f irq 10 maddr 0xd8000 msize 16384 on isa ze0: address 00:04:ac:25:74:64, type IBM PCMCIA (16bit), MAU 10base2 ze0: shared memory corrupt - invalid packet length 65535 The card works fine, but I would like to rsolve this error. Thanks, Gary ---------------------------------- E-Mail: Gary Crutcher Date: 18-May-97 Time: 15:47:53 This message was sent by XFMail ---------------------------------- From owner-freebsd-hardware Sun May 18 23:31:34 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id XAA05608 for hardware-outgoing; Sun, 18 May 1997 23:31:34 -0700 (PDT) Received: from bmccane.uit.net (bmccane.uit.net [208.129.189.48]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id XAA05603 for ; Sun, 18 May 1997 23:31:31 -0700 (PDT) Received: from bmccane.uit.net (localhost.mccane.com [127.0.0.1]) by bmccane.uit.net (8.8.5/8.8.5) with ESMTP id BAA04494; Mon, 19 May 1997 01:31:22 -0500 (CDT) Message-Id: <199705190631.BAA04494@bmccane.uit.net> X-Mailer: exmh version 2.0gamma 1/27/96 To: richard@pegasus.com (Richard Foulk) cc: hardware@FreeBSD.ORG Subject: Re: scanner support? In-reply-to: Your message of "Tue, 06 May 1997 17:00:52 -1001." <199705070301.RAA26479@pegasus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 19 May 1997 01:31:22 -0500 From: Wm Brian McCane Sender: owner-hardware@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > I recently had the pleasure of using a Microtek E3 scanner. It works > quite well, has good color, reasonable reasolution (300x600dpi) and > is very inexpensive (~$190). It uses a SCSI interface and is > supposedly TWAIN compatible. > > So how hard could it be to write some code to drive this thing? > I am trying to develop an TWAIN driver of a sort. I found a kerenel driver called PINT, which stands for PINT Is Not Twain. Unfortunately, I have found the most recent version of the software out on the 'net, then I ran out of spare time (which is good when your a consultant 8). If you have the time and would like the sources, let me know and I can send what I have to you. brian From owner-freebsd-hardware Mon May 19 00:26:53 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id AAA07351 for hardware-outgoing; Mon, 19 May 1997 00:26:53 -0700 (PDT) Received: from lister.bogon.net (0@gw.bogon.net [204.137.132.49]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id AAA07346 for ; Mon, 19 May 1997 00:26:51 -0700 (PDT) Received: from kryten.bogon.net (500@kryten.bogon.net [204.137.132.58]) by lister.bogon.net (8.8.5/8.8.5) with ESMTP id AAA26844 for ; Mon, 19 May 1997 00:26:47 -0700 (PDT) From: Wes Santee Received: (from wes@localhost) by kryten.bogon.net (8.8.5/8.8.5) id AAA00299 for freebsd-hardware@freebsd.org; Mon, 19 May 1997 00:26:45 -0700 (PDT) Message-Id: <199705190726.AAA00299@kryten.bogon.net> To: freebsd-hardware@freebsd.org Date: Mon, 19 May 1997 00:26:45 -0700 (PDT) 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-hardware@freebsd.org X-Loop: FreeBSD.org Precedence: bulk who freebsd-hardware From owner-freebsd-hardware Mon May 19 11:05:11 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id LAA08112 for hardware-outgoing; Mon, 19 May 1997 11:05:11 -0700 (PDT) Received: from george.lbl.gov (george-2.lbl.gov [131.243.2.12]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id LAA08073; Mon, 19 May 1997 11:05:03 -0700 (PDT) Received: (jin@localhost) by george.lbl.gov (8.6.10/8.6.5) id LAA14553; Mon, 19 May 1997 11:05:02 -0700 Date: Mon, 19 May 1997 11:05:02 -0700 From: "Jin Guojun[ITG]" Message-Id: <199705191805.LAA14553@george.lbl.gov> To: hardware@freebsd.org Subject: ASUS P/I-P65UP5 + C-P55T2D dual Pentium MB Cc: questions@freebsd.org Sender: owner-hardware@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Has any one successfully installed FreeBSD on an ASUS P/I-P65UP5 dual Pentium motherboard with C-P55T2D (two 200 MHz Pentium CPU) daughter board? I had a memory problem on this motherboard. The same memory was used for ASUS P/I-P55TVP4 and TX97-E single Pentium 200 MHz CPU motherboards without any problem. They are 60 ns non-parity SIMM. However, the same hareware with just a different motherboard, the page fault occurred when system swithed to VM mode during the installation; that is, when installation passed all probing and switched to graphic installation menu. Does this imply I have a defective motherboard? or are some special setup required for VM start up? More info., this motherboard does not work for other UN*X system either. Any help and information will be appreciated. -Jin From owner-freebsd-hardware Mon May 19 12:33:05 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id MAA12500 for hardware-outgoing; Mon, 19 May 1997 12:33:05 -0700 (PDT) Received: from persprog.com (persprog.com [204.215.255.203]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id MAA12484; Mon, 19 May 1997 12:32:55 -0700 (PDT) Received: by persprog.com (8.7.5/4.10) id OAA26964; Mon, 19 May 1997 14:22:35 -0500 Received: from dave(192.2.2.6) by cerberus.ppi.com via smap (V1.3) id sma026960; Mon May 19 15:22:29 1997 Message-ID: <3380A876.FA4A64FE@persprog.com> Date: Mon, 19 May 1997 15:22:30 -0400 From: Dave Alderman Reply-To: dave@persprog.com Organization: Personalized Programming, Inc X-Mailer: Mozilla 4.0b4 [en] (Win95; I) MIME-Version: 1.0 To: Chris Dillon CC: Stefan Esser , freebsd-hardware@FreeBSD.ORG Subject: Re: What Printer To Get - Postscript X-Priority: 3 (Normal) References: <199705160644.XAA21927@superior.mooseriver.com> <337C7366.4A93ABDB@persprog.com> <19970516180317.27012@x14.mi.uni-koeln.de> <337D368E.167EB0E7@tri-lakes.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-hardware@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Chris Dillon wrote: > Yup... but for $500 i kind of wish I looked at one of those Epson > printers. Especially if I had waited about 2 months and bought one of > their 1440dpi printers for $100 less. BUT, I think the main reason I > bought this HP printer over any other is, well, it's from HP. ;> > I've never once had any major problems with their printers, especially > their lasers. Do you replace the Epson print head when you replace the ink cartridge(s)? One of the reasons I like the HP's is that a serious ink clog can be fixed by simply replacing the offending cartridge. If the head is permanent, clearing any ink clog might be very difficult, especially at 1440 dpi. Incidentally, the only time I have had a clog with the 855 was when I printed to a transparency with the printer in plain paper mode. It was literally shovelling ink back and forth across the page by the end of the print. I simply removed the ink cartridge and carefully removed the ink blobs with a lint free cloth and it was working again. If I had damaged the head cleaning it I was glad to know I could just go to the nearest office supply and replace it. -- It's not my fault! It's some guy named "General Protection"! --Ratbert David W. Alderman dave@persprog.com From owner-freebsd-hardware Mon May 19 19:25:26 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id TAA04004 for hardware-outgoing; Mon, 19 May 1997 19:25:26 -0700 (PDT) Received: from nightflight.com (nightflight.com [207.135.216.194]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id TAA03996; Mon, 19 May 1997 19:25:22 -0700 (PDT) Received: from laptop.nightflight.com (laptop [207.135.216.195]) by nightflight.com (8.8.5/8.6.9) with SMTP id TAA08931; Mon, 19 May 1997 19:24:32 -0700 (PDT) Message-Id: <3.0.1.32.19970519192508.006aedf4@nightflight.com> X-Sender: gcrutchr@nightflight.com X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Mon, 19 May 1997 19:25:08 -0700 To: freebsd-questions@freebsd.org From: Gary Crutcher Subject: qcam not working Cc: freebsd-hardware@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-hardware@freebsd.org X-Loop: FreeBSD.org Precedence: bulk HI, I have installed FreeBSD 2.2.1 and have set up qcam in my kernel. When the systems boots it detects qcam but when I run qcam the module will not load. Not much info is reported by the qcam program. Any ideas? Also, it works in Win95, so I know the printer port works. Gary -------------------------------------------------------------------- Gary Crutcher email: gcrutchr@nightflight.com Webmaster URL: http://www.nightflight.com Member of the Internet Developers Association ----------------------------------------------------------------- From owner-freebsd-hardware Tue May 20 12:28:05 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id MAA20838 for hardware-outgoing; Tue, 20 May 1997 12:28:05 -0700 (PDT) Received: from lister.bogon.net (500@gw.bogon.net [204.137.132.49]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id MAA20818 for ; Tue, 20 May 1997 12:28:01 -0700 (PDT) Received: (from wes@localhost) by lister.bogon.net (8.8.5/8.8.5) id MAA06138 for freebsd-hardware@freebsd.org; Tue, 20 May 1997 12:27:44 -0700 (PDT) From: Wes Santee Message-Id: <199705201927.MAA06138@lister.bogon.net> Subject: Any luck with EE Pro/10? To: freebsd-hardware@freebsd.org Date: Tue, 20 May 1997 12:27:44 -0700 (PDT) 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-hardware@freebsd.org X-Loop: FreeBSD.org Precedence: bulk 'Lo all. Are there specific problems with the ex driver in 2.2 that I should know about? Quick background: After discovering that the EE/16 support was completely broken after the merge of the ix and ie drivers, I put an EE/Pro 10 in a 2.2 box to replace the EE/16. After doing that, none of the other boxes on the network can see the box with the EE Pro/10. Here's the new network layout: +------+ |A | |Win95 |-------------+ +------------+ |EE/16 | | |C | +------+ +----+ |FreeBSD 2.2 | |Hub |----|EE Pro/10 |----PPP--->Internet +----------------+ +----+ +------------+ |B | | |FreeBSD 2.2 |---+ |EE/16 Pre-Merge | +----------------+ When the EE/16 was in machine C and the pre-merge kernel was running, all boxes saw each other, no problem. After putting in the Pro/10 and recompiling the kernel, the machine come up okay, found the card, dialed out the Internet over the PPP link and started communicating with no problems. However, now neither machine A nor B can see machine C. Running a packet trace on the Pro/10, not even ARP requests are completing between A<->C and B<->C. A and B, however can still see each other just fine. All IP addresses and subnet masks are the same. And yes, I did update /etc/sysconfig to config the ex interface instead of the old ix interface. I also ran SoftSet to make sure the configuration on the card matched the line in the kernel config file. HOWEVER, I did note that SoftSet did not have an option to setup the iomem address on the Pro/10 like it does on the EE/16. Should that raise any flags? Are there framing differences or other tidbits I should know about here? Are there inherent incompatibilities between the EE/16 and Pro/10 regardless of the OS? Any help would be appreciated. Cheers, -- ( Wes Santee PGP: e-mail w/Subject: "Send PGP Key" ) ( mailto:wes@bogon.net ) From owner-freebsd-hardware Tue May 20 13:30:32 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id NAA24100 for hardware-outgoing; Tue, 20 May 1997 13:30:32 -0700 (PDT) Received: from TRUTH.WOFFORD.EDU (truth.wofford.edu [199.190.174.30]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id NAA24093 for ; Tue, 20 May 1997 13:30:28 -0700 (PDT) Date: Tue, 20 May 1997 16:30:22 -0400 From: Dan Welch To: HARDWARE@FREEBSD.ORG CC: WELCHDW@wofford.edu Message-Id: <970520163022.22a1f853@wofford.edu> Subject: isa bus and boca multiport boards Sender: owner-hardware@FREEBSD.ORG X-Loop: FreeBSD.org Precedence: bulk I'm having quite a bit of difficulty getting Boca's 8 and 16 port boards to work in my standard isa bus machines. A few of the boards work ok, some work with a port or two appearing to be bad, others have a chunk of neighboring ports appearing not to work. Which ports are "bad" is stable in a given machine, but may differ between machines. Additionally, the boards will often cause a machine to no longer be able to complete a reboot via "shutdown -r now"; the machine will just freeze after finishing sync. Remove the board and all is well again. At first I thought I just had a bad bunch of boards (3 8's and 3 16's) and got them replaced. The replacement set is just as bad. In the 12 boards I've tried, I have only gotten one "good" 8 port and one "good" 16 port; there's a single "bad" port in each but otherwise workable, except that the 16 port prohibits full reboot except by reset button. The first Boca board I ever bought (8 port) worked flawlessly in all three machines it's occupied and still does. This problem spans 8 machines of 486 and 586 class, with clocks ranging from 20 MHz to 75 MHz. Does anybody recognize the problem? From owner-freebsd-hardware Tue May 20 13:52:59 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id NAA25333 for hardware-outgoing; Tue, 20 May 1997 13:52:59 -0700 (PDT) Received: from lariat.lariat.org (ppp0.lariat.org@[129.72.251.2]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id NAA25316 for ; Tue, 20 May 1997 13:52:48 -0700 (PDT) Received: from solo.lariat.org ([129.72.251.10]) by lariat.lariat.org (8.8.5/8.8.5) with SMTP id OAA03898; Tue, 20 May 1997 14:52:33 -0600 (MDT) Message-Id: <3.0.1.32.19970520111942.0073a958@lariat.org> X-Sender: brett@lariat.org X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Tue, 20 May 1997 11:19:42 -0600 To: WELCHDW@wofford.edu, HARDWARE@FreeBSD.ORG From: Brett Glass Subject: Re: isa bus and boca multiport boards Cc: WELCHDW@wofford.edu In-Reply-To: <8825649D.0071A448.00@IWND1.infoworld.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-hardware@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Don't know, but sounds like a case of partial address decoding on the board -- and/or port, address, or IRQ conflicts. It may be possible to jumper the board to fix the problem. Also, have you compiled your kernel with the COM_MULTIPORT option? Set the flags that indicate IRQs are shared? --Brett At 04:30 PM 5/20/97 -0300, WELCHDW@wofford.edu wrote: >I'm having quite a bit of difficulty getting Boca's 8 and 16 port >boards to work in my standard isa bus machines. A few of the boards >work ok, some work with a port or two appearing to be bad, others >have a chunk of neighboring ports appearing not to work. Which ports >are "bad" is stable in a given machine, but may differ between >machines. > >Additionally, the boards will often cause a machine to no longer >be able to complete a reboot via "shutdown -r now"; the machine will >just freeze after finishing sync. Remove the board and all is well >again. From owner-freebsd-hardware Tue May 20 14:15:14 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id OAA26453 for hardware-outgoing; Tue, 20 May 1997 14:15:14 -0700 (PDT) Received: from kilgour.nething.com (kilgour.nething.com [204.253.210.65]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id OAA26447 for ; Tue, 20 May 1997 14:15:10 -0700 (PDT) Received: from randy.nething.com (randy.nething.com [204.253.210.83]) by kilgour.nething.com (8.7.5/8.6.9) with SMTP id QAA17468; Tue, 20 May 1997 16:09:19 -0500 (CDT) Message-Id: <3.0.1.32.19970520161437.0085e2e0@nething.com> X-Sender: rberndt@nething.com X-Mailer: Windows Eudora Light Version 3.0.1 (32) Date: Tue, 20 May 1997 16:14:37 -0500 To: Dan Welch , HARDWARE@FreeBSD.ORG From: Randy Berndt Subject: Re: isa bus and boca multiport boards Cc: WELCHDW@wofford.edu In-Reply-To: <970520163022.22a1f853@wofford.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-hardware@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk At 04:30 PM 5/20/97 -0400, Dan Welch wrote: >I'm having quite a bit of difficulty getting Boca's 8 and 16 port >boards to work in my standard isa bus machines. A few of the boards >work ok, some work with a port or two appearing to be bad, others >have a chunk of neighboring ports appearing not to work. Which ports >are "bad" is stable in a given machine, but may differ between >machines. > >Additionally, the boards will often cause a machine to no longer >be able to complete a reboot via "shutdown -r now"; the machine will >just freeze after finishing sync. Remove the board and all is well >again. > >At first I thought I just had a bad bunch of boards (3 8's and 3 >16's) and got them replaced. The replacement set is just as bad. >In the 12 boards I've tried, I have only gotten one "good" 8 port and >one "good" 16 port; there's a single "bad" port in each but >otherwise workable, except that the 16 port prohibits full reboot >except by reset button. > >The first Boca board I ever bought (8 port) worked flawlessly in all >three machines it's occupied and still does. > >This problem spans 8 machines of 486 and 586 class, with clocks >ranging from 20 MHz to 75 MHz. > I had a similar problem, but it only happened on high ports. 11 and above (?). There are 4 chips each handling 4 ports, but if I recall (this was 18 months ago), the problem spanned chips. Low ports NEVER had problems. I needed 16 ports, so I just bought a second one (they are damned cheap) and only use the first 8 on each. [Wild-Ass-Guess Mode ON] Since the entire set of ports must be scanned whenever an interrupt occurs, maybe there is too much delay in getting to the upper ports. Something gets locked up if they overflow. I left several messages, but no one could figure it out. [W-A-G Mode OFF] Randy Berndt ---------------------------------- AOS/VS, FreeBSD, DOS: I'm caught in a maze of twisty little command interpreters, all different. From owner-freebsd-hardware Tue May 20 15:25:57 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id PAA01211 for hardware-outgoing; Tue, 20 May 1997 15:25:57 -0700 (PDT) Received: from lariat.lariat.org (ppp0.lariat.org@[129.72.251.2]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id PAA01205 for ; Tue, 20 May 1997 15:25:55 -0700 (PDT) Received: from solo.lariat.org ([129.72.251.10]) by lariat.lariat.org (8.8.5/8.8.5) with SMTP id QAA05174; Tue, 20 May 1997 16:24:55 -0600 (MDT) Message-Id: <3.0.1.32.19970520125159.006dbe70@lariat.org> X-Sender: brett@lariat.org X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Tue, 20 May 1997 12:51:59 -0600 To: rberndt@nething.com, WELCHDW@wofford.edu, HARDWARE@FreeBSD.ORG From: Brett Glass Subject: Re: isa bus and boca multiport boards Cc: WELCHDW@wofford.edu In-Reply-To: <8825649D.00771D31.00@IWND1.infoworld.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-hardware@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk At 04:14 PM 5/20/97 -0400, you wrote: >Since the entire set of ports must be scanned whenever an interrupt occurs, >maybe there is too much delay in getting to the upper ports. Something gets >locked up if they overflow. I left several messages, but no one could >figure it out. Maybe the sio driver should be recoded in optimized ASM. I can see some major C inefficiencies in it, including lots of repeated pointer dereferences and control structures that the compiler would probably optimize poorly. I've generated super-tight assembler for serial I/O. A stopgap might be be use a couple of IRQs for the different ports, if the board lets you do it. I put no more than 4 UARTs on an IRQ in my system because the driver loops over the UARTS at least twice per IRQ. --Brett From owner-freebsd-hardware Tue May 20 19:00:50 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id TAA09925 for hardware-outgoing; Tue, 20 May 1997 19:00:50 -0700 (PDT) Received: from TRUTH.WOFFORD.EDU (truth.wofford.edu [199.190.174.30]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id TAA09908 for ; Tue, 20 May 1997 19:00:38 -0700 (PDT) Date: Tue, 20 May 1997 22:00:35 -0400 From: Dan Welch To: brett@lariat.ORG CC: HARDWARE@FREEBSD.ORG, WELCHDW@wofford.edu Message-Id: <970520220035.22a2107f@wofford.edu> Subject: Re: isa bus and boca multiport boards Sender: owner-hardware@FREEBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >>device sio2 at isa? port 0x200 tty flags 0x1105 >>device sio3 at isa? port 0x208 tty flags 0x1105 >>... >>device sio17 at isa? port 0x278 tty flags 0x1105 irq 12 vector siointr > Ouch! Don't know what else you have in your system, but you are > probably stomping on other devices' ports something terrible. There > are bound to be major conflicts here. You might want to get a book > on the PC architecture, and survey all of your peripherals' port > usage, so you can learn to avoid the reserved ports. Good point. Before using this range I verified that there are no conflicts with the ranges listed in the dmesg output for other devices. I also experimented with addresses in the 0x100 set based on the same analysis. Nevertheless, there may well be addresses that other devices use that are not listed by dmesg, so I'll check other documents as you suggest. > Also set the flags to 0x1185 for better diagnostics. Will do. Thanks. From owner-freebsd-hardware Tue May 20 19:42:55 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id TAA12145 for hardware-outgoing; Tue, 20 May 1997 19:42:55 -0700 (PDT) Received: from hydrogen.nike.efn.org (resnet.uoregon.edu [128.223.170.28]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id TAA12137 for ; Tue, 20 May 1997 19:42:44 -0700 (PDT) Received: (from jmg@localhost) by hydrogen.nike.efn.org (8.8.5/8.8.5) id TAA27049; Tue, 20 May 1997 19:44:01 -0700 (PDT) Message-ID: <19970520194401.23424@hydrogen.nike.efn.org> Date: Tue, 20 May 1997 19:44:01 -0700 From: John-Mark Gurney To: Brett Glass Cc: rberndt@nething.com, WELCHDW@wofford.edu, HARDWARE@FreeBSD.ORG Subject: Re: isa bus and boca multiport boards References: <8825649D.00771D31.00@IWND1.infoworld.com> <3.0.1.32.19970520125159.006dbe70@lariat.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.69 In-Reply-To: <3.0.1.32.19970520125159.006dbe70@lariat.org>; from Brett Glass on Tue, May 20, 1997 at 12:51:59PM -0600 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-hardware@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Brett Glass scribbled this message on May 20: > At 04:14 PM 5/20/97 -0400, you wrote: > > >Since the entire set of ports must be scanned whenever an interrupt occurs, > >maybe there is too much delay in getting to the upper ports. Something gets > >locked up if they overflow. I left several messages, but no one could > >figure it out. > > Maybe the sio driver should be recoded in optimized ASM. I can see some > major C inefficiencies in it, including lots of repeated pointer > dereferences and control structures that the compiler would probably > optimize poorly. I've generated super-tight assembler for serial I/O. > > A stopgap might be be use a couple of IRQs for the different ports, if the > board lets you do it. I put no more than 4 UARTs on an IRQ in my system > because the driver loops over the UARTS at least twice per IRQ. well... this won't do any good... as right now when COM_MULTIPORT is used all the sio ports are scanned until they scan without hitting any change (input, signal change)... probably what should go in before this is splitting the intrrupt routine to only scan the ports that are on a certain board... this shouldn't be THAT hard to do... and I've thought about doing it... what you might try though is to set the fifo trigger level lower (I have code that allows you to have a kernel define but haven't committed it) than the default of 14 on 16550s... I had a Bt946 that would cause my multiport board to overflow... so I had to set the fifo levels lower... ttyl.. > > --Brett > -- John-Mark Cu Networking Modem/FAX: +1 541 683 6954 Live in Peace, destroy Micro$oft, support free software, run FreeBSD From owner-freebsd-hardware Tue May 20 19:57:24 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id TAA12718 for hardware-outgoing; Tue, 20 May 1997 19:57:24 -0700 (PDT) Received: from TRUTH.WOFFORD.EDU (truth.wofford.edu [199.190.174.30]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id TAA12712 for ; Tue, 20 May 1997 19:57:21 -0700 (PDT) Date: Tue, 20 May 1997 22:57:20 -0400 From: Dan Welch To: "TRUTH::WELCHDW"@wofford.edu CC: HARDWARE@FREEBSD.ORG, WELCHDW@wofford.edu Message-Id: <970520225720.22a2107f@wofford.edu> Subject: Re: isa bus and boca multiport boards Sender: owner-hardware@FREEBSD.ORG X-Loop: FreeBSD.org Precedence: bulk This is the reply I gave to Brett Glass but forgot to cc to the list: ====================== > Don't know, but sounds like a case of partial address decoding on > the board -- and/or port, address, or IRQ conflicts. I agree. > It may be possible to jumper the board to fix the problem. I wish! So far the combinations I've tried (one change at a time) were to test at address in the 0x100 and 0x200 range, and to try irq's other than ones I already know to be running something else. I've also tried the boards in machines that are not PCI just in case I might have a ROM setting incorrect there. And there's always that one Boca 8-port (my first) that works perfectly in a straight substitution with one of the 6 apparently defective one's I've received. All of which makes me suspect that I am running these boards at the ragged edge of their design somehow. Perhaps my bus speed is on the high side just enough to mess up the address decode? But on every machine in the department? Guess I could put an oscilloscope on them ... > Also, have you compiled your kernel with the COM_MULTIPORT option? > Set the flags that indicate IRQs are shared? Yes, and made the /dev entries and got getty going on all except the individually failing (seen during boot) ports. Here's a "grep irq" on dmesg: sc0 at 0x60-0x6f irq 1 on motherboard ed0 at 0x320-0x33f irq 5 on isa sio0 at 0x3f8-0x3ff irq 4 on isa sio1 at 0x2f8-0x2ff irq 3 on isa sio17 at 0x278-0x27f irq 12 flags 0x1105 on isa lpt0 at 0x378-0x37f irq 7 on isa fdc0 at 0x3f0-0x3f7 irq 6 drq 2 on isa wdc0 at 0x1f0-0x1f7 irq 14 on isa Here's the kernel incantation from the current test machine: options COM_MULTIPORT #code for some cards with shared IRQsp 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? port 0x200 tty flags 0x1105 device sio3 at isa? port 0x208 tty flags 0x1105 device sio4 at isa? port 0x210 tty flags 0x1105 device sio5 at isa? port 0x218 tty flags 0x1105 device sio6 at isa? port 0x220 tty flags 0x1105 device sio7 at isa? port 0x228 tty flags 0x1105 device sio8 at isa? port 0x230 tty flags 0x1105 device sio9 at isa? port 0x238 tty flags 0x1105 device sio10 at isa? port 0x240 tty flags 0x1105 device sio11 at isa? port 0x248 tty flags 0x1105 device sio12 at isa? port 0x250 tty flags 0x1105 device sio13 at isa? port 0x258 tty flags 0x1105 device sio14 at isa? port 0x260 tty flags 0x1105 device sio15 at isa? port 0x268 tty flags 0x1105 device sio16 at isa? port 0x270 tty flags 0x1105 device sio17 at isa? port 0x278 tty flags 0x1105 irq 12 vector siointr #device sio2 at isa? port 0x200 tty flags 0x1105 #device sio3 at isa? port 0x208 tty flags 0x1105 #device sio4 at isa? port 0x210 tty flags 0x1105 #device sio5 at isa? port 0x218 tty flags 0x1105 #device sio6 at isa? port 0x220 tty flags 0x1105 #device sio7 at isa? port 0x228 tty flags 0x1105 #device sio8 at isa? port 0x230 tty flags 0x1105 #device sio9 at isa? port 0x238 tty flags 0x1105 irq 12 vector siointr From owner-freebsd-hardware Tue May 20 20:13:26 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id UAA13326 for hardware-outgoing; Tue, 20 May 1997 20:13:26 -0700 (PDT) Received: from TRUTH.WOFFORD.EDU (truth.wofford.edu [199.190.174.30]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id UAA13321 for ; Tue, 20 May 1997 20:13:23 -0700 (PDT) Date: Tue, 20 May 1997 23:13:15 -0400 From: Dan Welch To: richard@pegasus.com CC: HARDWARE@FREEBSD.ORG, WELCHDW@wofford.edu Message-Id: <970520231315.22a2107f@wofford.edu> Subject: Re: isa bus and boca multiport boards Sender: owner-hardware@FREEBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > I've been running a Boca 16-port board on an old version of FBSD > (v1.1.5.1) for a long time with good results. I have the ports > addressed to 0x100. I'll enclose my kernel conf file to give > you an idea how it's put together. It's a little different > from the current conf files, but should still give you the idea. > ... > options "COM_BIDIR" #Bidirectional com ports > options "COM_MULTIPORT" > options "DONT_MALLOC_TTYS" > ... > controller isa0 > ... > # BocaBoard 16 Port board > device sio0 at isa? port 0x100 tty irq 3 flags 0x005 vector siointr > device sio1 at isa? port 0x108 tty flags 0x005 vector siointr > device sio2 at isa? port 0x110 tty flags 0x005 vector siointr > device sio3 at isa? port 0x118 tty flags 0x005 vector siointr > device sio4 at isa? port 0x120 tty flags 0x005 vector siointr > device sio5 at isa? port 0x128 tty flags 0x005 vector siointr > device sio6 at isa? port 0x130 tty flags 0x005 vector siointr > device sio7 at isa? port 0x138 tty flags 0x005 vector siointr > device sio8 at isa? port 0x140 tty flags 0x005 vector siointr > device sio9 at isa? port 0x148 tty flags 0x005 vector siointr > device sio10 at isa? port 0x150 tty flags 0x005 vector siointr > device sio11 at isa? port 0x158 tty flags 0x005 vector siointr > device sio12 at isa? port 0x160 tty flags 0x005 vector siointr > # next one is for mouse, so turn off fifo via flags > device sio13 at isa? port 0x168 tty flags 0x007 vector siointr > device sio14 at isa? port 0x170 tty flags 0x005 vector siointr > device sio15 at isa? port 0x178 tty flags 0x005 vector siointr > ... Yes, I see several things here for me to check and/or try. One that strikes me particularly is your specification of the irq on the first rather than the last port. For some reason I was under the impression that it had to be the last ... thanks. From owner-freebsd-hardware Tue May 20 20:45:40 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id UAA14657 for hardware-outgoing; Tue, 20 May 1997 20:45:40 -0700 (PDT) Received: from lariat.lariat.org (ppp0.lariat.org@[129.72.251.2]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id UAA14652 for ; Tue, 20 May 1997 20:45:35 -0700 (PDT) Received: from solo.lariat.org ([129.72.251.10]) by lariat.lariat.org (8.8.5/8.8.5) with SMTP id VAA09057; Tue, 20 May 1997 21:45:08 -0600 (MDT) Message-Id: <3.0.1.32.19970520181142.00734e08@lariat.org> X-Sender: brett@lariat.org X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Tue, 20 May 1997 18:11:42 -0600 To: John-Mark Gurney From: Brett Glass Subject: Re: isa bus and boca multiport boards Cc: rberndt@nething.com, WELCHDW@wofford.edu, HARDWARE@FreeBSD.ORG In-Reply-To: <19970520194401.23424@hydrogen.nike.efn.org> References: <3.0.1.32.19970520125159.006dbe70@lariat.org> <8825649D.00771D31.00@IWND1.infoworld.com> <3.0.1.32.19970520125159.006dbe70@lariat.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-hardware@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk At 07:44 PM 5/20/97 -0700, you wrote: >well... this won't do any good... as right now when COM_MULTIPORT is >used all the sio ports are scanned until they scan without hitting any >change (input, signal change)... probably what should go in before this >is splitting the intrrupt routine to only scan the ports that are on a >certain board... this shouldn't be THAT hard to do... and I've thought >about doing it... I was under the impression that this is what was already done, but now that I look at it, I see that you're right! The code loops on a variable called "unit", incrementing it from 0 to the precompiled constant NSIO. This can waste a great deal of time, especially since the interrupts are edge-triggered and the list is scanned at least twice per interrupt. Here are some other improvements that could be made to the code, based on a quick analysis: 1) The code looks at a flag called "gone" on each and every port (present or not) during each and every interrupt service. Since the presence or absence of a port is determined at boot time, it'd be MUCH more efficient if the code worked down a linear list of only the ports that were present and on the relevant IRQ. The edge-catching algorithm is also less efficient than it might be. To make sure you haven't missed an edge, you must scan the UARTs and get ALL THE WAY AROUND THE LIST ONCE without finding any more ports to service. You can then return from the ISR. The two best ways to do this are (a) set a counter to the number of UARTS and decrement as you traverse the list circularly, or (b) store the number (or port address) of the last UART that had an interrupt pending. Scan the list in a circular manner until you get back to the same UART without finding anything else to service. The current code doesn't do this efficiently; it always does an end-to-end scan of the list instead of stopping at the point of the last interrupt service. In fact, it may scan as many as NSIO-1 extra ports on each interrupt. On a system with a many serial ports, this is a LOT of extra time. Also, rather than dereferencing the pointer "com" again and again, the ISR could selectively enregister parts of the record that contain the comm port's statistics. I also see a subroutine call that could be optimized out. Finally, some things are variables that needn't be, such as I/O port numbers. Memory accesses are expensive and increments and decrements are cheap (or free due to pipelining if instructions are ordered properly). So, in my code, I've found it's faster to load the interrupt status register port number for the UART, then increment and decrement as needed rather than doing more loads to obtain other register numbers. On the Intel processors, increments and decrements don't have many scheduling constraints; they've been optimized so that they rarely cause pipeline stalls. And eliminating the stored port numbers can reduce the record size dramatically, making it easy to enregister things. I don't know what the policy on ASM code is in FreeBSD, but this seems like an opportunity to do some VERY serious optimization where it's much needed! --Brett From owner-freebsd-hardware Tue May 20 20:48:48 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id UAA14755 for hardware-outgoing; Tue, 20 May 1997 20:48:48 -0700 (PDT) Received: from u2.farm.idt.net (root@u2.farm.idt.net [169.132.8.11]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id UAA14750 for ; Tue, 20 May 1997 20:48:46 -0700 (PDT) Received: from sequoia (ppp-15.ts-1.mlb.idt.net [169.132.71.15]) by u2.farm.idt.net (8.8.5/8.8.5) with SMTP id XAA09636; Tue, 20 May 1997 23:48:38 -0400 (EDT) Message-ID: <338270C1.41C67EA6@idt.net> Date: Tue, 20 May 1997 23:50:53 -0400 From: "Gary T. Corcoran" X-Mailer: Mozilla 3.01 (X11; I; FreeBSD 2.2.1-RELEASE i386) MIME-Version: 1.0 To: Dan Welch CC: TRUTH::WELCHDW@wofford.edu, HARDWARE@FreeBSD.ORG Subject: Re: isa bus and boca multiport boards References: <970520225720.22a2107f@wofford.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-hardware@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Dan Welch wrote: > > This is the reply I gave to Brett Glass but forgot to cc to the list: > ====================== > > Don't know, but sounds like a case of partial address decoding on > > the board -- and/or port, address, or IRQ conflicts. > > I agree. > > Here's the kernel incantation from the current test machine: ... > device sio17 at isa? port 0x278 tty flags 0x1105 irq 12 vector siointr > I/O ports 0x278-0x27F are standard for an LPT (parallel) port. In addition, port 0x279 is used for Plug-N-Play setup. And, IRQ 12 is used for PS/2 mouse ports built into motherboards. Any of those resources ring a bell with your system? Gary From owner-freebsd-hardware Tue May 20 21:05:11 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id VAA15449 for hardware-outgoing; Tue, 20 May 1997 21:05:11 -0700 (PDT) Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id VAA15443 for ; Tue, 20 May 1997 21:05:03 -0700 (PDT) Received: (from msmith@localhost) by genesis.atrad.adelaide.edu.au (8.8.5/8.7.3) id NAA08585; Wed, 21 May 1997 13:34:41 +0930 (CST) From: Michael Smith Message-Id: <199705210404.NAA08585@genesis.atrad.adelaide.edu.au> Subject: Re: isa bus and boca multiport boards In-Reply-To: <3.0.1.32.19970520125159.006dbe70@lariat.org> from Brett Glass at "May 20, 97 12:51:59 pm" To: brett@lariat.org (Brett Glass) Date: Wed, 21 May 1997 13:34:41 +0930 (CST) Cc: rberndt@nething.com, WELCHDW@wofford.edu, HARDWARE@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-hardware@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Brett Glass stands accused of saying: > At 04:14 PM 5/20/97 -0400, you wrote: > > Maybe the sio driver should be recoded in optimized ASM. I can see some > major C inefficiencies in it, including lots of repeated pointer > dereferences and control structures that the compiler would probably > optimize poorly. I've generated super-tight assembler for serial I/O. (cocks an ear listening for the ICBM leaving bde's desk). I don't think that would be a very popular idea; the sio driver should be more, not less, machine independant. > A stopgap might be be use a couple of IRQs for the different ports, if the > board lets you do it. I put no more than 4 UARTs on an IRQ in my system > because the driver loops over the UARTS at least twice per IRQ. The boards in question don't. FWIW, the ISP across the hall from my office has a 386dx40 with an 8-port PC-COM (AST-alike) card and four single UARTs; it gets beaten to death and beyond using a mix of iijppp and SLiRP and keeps up quite happily. There's nothing basically wrong with the sio driver in that regard. > --Brett -- ]] Mike Smith, Software Engineer msmith@gsoft.com.au [[ ]] Genesis Software genesis@gsoft.com.au [[ ]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[ ]] realtime instrument control. (ph) +61-8-8267-3493 [[ ]] Unix hardware collector. "Where are your PEZ?" The Tick [[ From owner-freebsd-hardware Tue May 20 21:35:14 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id VAA17380 for hardware-outgoing; Tue, 20 May 1997 21:35:14 -0700 (PDT) Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id VAA17371 for ; Tue, 20 May 1997 21:35:04 -0700 (PDT) Received: (from msmith@localhost) by genesis.atrad.adelaide.edu.au (8.8.5/8.7.3) id OAA08916; Wed, 21 May 1997 14:03:39 +0930 (CST) From: Michael Smith Message-Id: <199705210433.OAA08916@genesis.atrad.adelaide.edu.au> Subject: Re: isa bus and boca multiport boards In-Reply-To: <3.0.1.32.19970520181142.00734e08@lariat.org> from Brett Glass at "May 20, 97 06:11:42 pm" To: brett@lariat.org (Brett Glass) Date: Wed, 21 May 1997 14:03:39 +0930 (CST) Cc: gurney_j@resnet.uoregon.edu, rberndt@nething.com, WELCHDW@wofford.edu, HARDWARE@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-hardware@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Brett Glass stands accused of saying: > At 07:44 PM 5/20/97 -0700, you wrote: > >change (input, signal change)... probably what should go in before this > >is splitting the intrrupt routine to only scan the ports that are on a > >certain board... this shouldn't be THAT hard to do... and I've thought > >about doing it... > > I was under the impression that this is what was already done, but now that > I look at it, I see that you're right! The code loops on a variable called > "unit", incrementing it from 0 to the precompiled constant NSIO. This can > waste a great deal of time, especially since the interrupts are > edge-triggered and the list is scanned at least twice per interrupt. You would still have to scan all possible ports and consult their softc 'master' port value. Just scanning the port directly is not much more inefficient, and may save you interrupt overhead soon therafter. > Here are some other improvements that could be made to the code, based on a > quick analysis: > > 1) The code looks at a flag called "gone" on each and every port (present > or not) during each and every interrupt service. Since the presence or > absence of a port is determined at boot time This is not true. Please note where the "gone" flag is manipulated, and post a correction to your statement when you understand. >, it'd be MUCH more efficient > if the code worked down a linear list of only the ports that were present > and on the relevant IRQ. This might well be achievable, but is unlikely to be significantly more efficient. > list instead of stopping at the point of the last interrupt service. In > fact, it may scan as many as NSIO-1 extra ports on each interrupt. On a > system with a many serial ports, this is a LOT of extra time. It's not, actually, all that much. Scanning a port is a single I/O operation, taking around 1us. At 115200bps, it takes 86us for a single character to arrive. > Also, rather than dereferencing the pointer "com" again and again, the ISR > could selectively enregister parts of the record that contain the comm > port's statistics. This is an operation possibly best left to the compiler. Have you checked the generated machine instructions? > I don't know what the policy on ASM code is in FreeBSD, but this seems like > an opportunity to do some VERY serious optimization where it's much needed! Processor-specific code in device drivers is not a viable proposition, given that portability is a significant issue. > --Brett -- ]] Mike Smith, Software Engineer msmith@gsoft.com.au [[ ]] Genesis Software genesis@gsoft.com.au [[ ]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[ ]] realtime instrument control. (ph) +61-8-8267-3493 [[ ]] Unix hardware collector. "Where are your PEZ?" The Tick [[ From owner-freebsd-hardware Tue May 20 22:21:02 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id WAA19286 for hardware-outgoing; Tue, 20 May 1997 22:21:02 -0700 (PDT) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id WAA19280 for ; Tue, 20 May 1997 22:20:59 -0700 (PDT) Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.5/8.6.9) id PAA05401; Wed, 21 May 1997 15:16:17 +1000 Date: Wed, 21 May 1997 15:16:17 +1000 From: Bruce Evans Message-Id: <199705210516.PAA05401@godzilla.zeta.org.au> To: brett@lariat.org, HARDWARE@FreeBSD.ORG, rberndt@nething.com, WELCHDW@wofford.edu Subject: Re: isa bus and boca multiport boards Sender: owner-hardware@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >>Since the entire set of ports must be scanned whenever an interrupt occurs, >>maybe there is too much delay in getting to the upper ports. Something gets >>locked up if they overflow. I left several messages, but no one could >>figure it out. Probably not. Scanning all (inactive) ports takes about 1/4 as long as handing one fully active 16550 port. Scanning 16 fully active ports at 115200 bops takes too long for the default (unconfigurable :-() fifo trigger level. However, having 16 fully active ports is rare. >Maybe the sio driver should be recoded in optimized ASM. I can see some >major C inefficiencies in it, including lots of repeated pointer >dereferences and control structures that the compiler would probably >optimize poorly. I've generated super-tight assembler for serial I/O. Nope. There are only some minor C inefficiencies in the important parts of the driver. The code is within 50% of best possible generic i386 assembler code by static instruction counts, but this is unimportant with modern CPUs. On a P5/133, about 300 pointer dereferences can be done in the time it takes to do one i/o instruction. On a 386/20, only about 6 pointer dereferences can be done in the time it takes to do one i/o instruction. There are some major C inefficiencies in tty layers outside the driver. The pppd line discipline interface and implementation is particularly inefficient. On a 486/33, it takes slightly longer than all i/o and interrupt handling. This problem is "fixed" by using a modern CPU to speed up the non-i/o parts. Bruce From owner-freebsd-hardware Tue May 20 23:37:46 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id XAA22541 for hardware-outgoing; Tue, 20 May 1997 23:37:46 -0700 (PDT) Received: from u2.farm.idt.net (root@u2.farm.idt.net [169.132.8.11]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id XAA22536 for ; Tue, 20 May 1997 23:37:44 -0700 (PDT) Received: from sequoia (ppp-15.ts-1.mlb.idt.net [169.132.71.15]) by u2.farm.idt.net (8.8.5/8.8.5) with SMTP id CAA17863; Wed, 21 May 1997 02:36:50 -0400 (EDT) Message-ID: <3382988F.167EB0E7@idt.net> Date: Wed, 21 May 1997 02:39:11 -0400 From: "Gary T. Corcoran" X-Mailer: Mozilla 3.01 (X11; I; FreeBSD 2.2.1-RELEASE i386) MIME-Version: 1.0 To: Bruce Evans CC: HARDWARE@FreeBSD.ORG Subject: Re: isa bus and boca multiport boards References: <199705210516.PAA05401@godzilla.zeta.org.au> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-hardware@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Bruce Evans wrote: > On a P5/133, about 300 pointer dereferences can be > done in the time it takes to do one i/o instruction. I know this discussion was concerning I/O ports on the ISA bus, but I'm curious if you know: How long does a single I/O (read or write) take when accessing an I/O port on the PCI bus? I _believe_ that in modern chipsets, for I/O addresses which are supposed to be "PCI only" (higher than a certain address) that the I/O operations do *not* appear on the ISA bus, and thus shouldn't be limited by the ancient ISA I/O speeds - is this true? Thanks, Gary Errr... given all the "Gary's" floating around on these lists, make that: Thanks, Gary Corcoran From owner-freebsd-hardware Wed May 21 00:12:43 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id AAA24039 for hardware-outgoing; Wed, 21 May 1997 00:12:43 -0700 (PDT) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id AAA24034 for ; Wed, 21 May 1997 00:12:38 -0700 (PDT) Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.5/8.6.9) id RAA10446; Wed, 21 May 1997 17:05:21 +1000 Date: Wed, 21 May 1997 17:05:21 +1000 From: Bruce Evans Message-Id: <199705210705.RAA10446@godzilla.zeta.org.au> To: brett@lariat.org, gurney_j@resnet.uoregon.edu Subject: Re: isa bus and boca multiport boards Cc: HARDWARE@freebsd.org, rberndt@nething.com, WELCHDW@wofford.edu Sender: owner-hardware@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >I was under the impression that this is what was already done, but now that >I look at it, I see that you're right! The code loops on a variable called >"unit", incrementing it from 0 to the precompiled constant NSIO. This can >waste a great deal of time, especially since the interrupts are >edge-triggered and the list is scanned at least twice per interrupt. Many minor improvements are possible, but significant improvements are difficult to achieve without a hardware register giving a bitmap of the active interrupts. I believe BocaBoards have register(s) for this. Someone who has a BocaBoard should implement checking the register. All ports are checked for fairness. When you have a 16 active ports on one board, it is too easy for ports on other boards to be starved. Ports with smaller fifos should be given lower unit numbers so that they get served first. The siointr1() layer attempts to return early for the COM_MULTIPORT case. It doesn't do this very well - in the worst case it does more than 3 * fifo_size i/o's per call to handle a full receiver fifo and an empty transmitter fifo. For fairness, it should handle at most one or two events per call, but this would be inefficient. >1) The code looks at a flag called "gone" on each and every port (present >or not) during each and every interrupt service. Since the presence or >absence of a port is determined at boot time, it'd be MUCH more efficient >if the code worked down a linear list of only the ports that were present >and on the relevant IRQ. This would be slightly more efficient. Not much more, because 16 com_addr(unit) != NULL && com_addr(unit)->gone != 0 checks can be done in less time than it takes to do _one_ i/o for a present port on a modern ix86 system. Using linear lists instead of linked lists is good here since it avoids cache misses. >The edge-catching algorithm is also less efficient than it might be. To >make sure you haven't missed an edge, you must scan the UARTs and get ALL >THE WAY AROUND THE LIST ONCE without finding any more ports to service. You >can then return from the ISR. The two best ways to do this are (a) set a I never got around to implementing this. >fact, it may scan as many as NSIO-1 extra ports on each interrupt. On a >system with a many serial ports, this is a LOT of extra time. For 16 ports, it takes about half as long as to do the actual i/o for one 16550 port. >Also, rather than dereferencing the pointer "com" again and again, the ISR >could selectively enregister parts of the record that contain the comm >port's statistics. It already does as much as possible. ix86's don't have enough registers to do much better, and in any case the compiler should do it. This is not very important for modern ix86's, since all accesses except the first are cache hits so they take only one cycle. >I also see a subroutine call that could be optimized out. Subroutine calls are cheap, and inlining tends to give worse register allocation. >Finally, some things are variables that needn't be, such as I/O port >numbers. Memory accesses are expensive and increments and decrements are >cheap (or free due to pipelining if instructions are ordered properly). So, Memory accesses are cheap (unless there is a cache miss, and all the pre-computed register numbers in the com struct are contiguous, so more than one cache miss would be unlucky). They take the same time as increments and decrements of registers on modern ix86's and tend to give better register allocation. Of course, you can do better in assembler by doing perfect register allocation and pipelining, but the slow i/o limits potential gains to a few percent (relative) and < 1% per port (absolute). >I don't know what the policy on ASM code is in FreeBSD, but this seems like >an opportunity to do some VERY serious optimization where it's much needed! I try to avoid it, and enjoy making serial drivers written in C several times more efficient than previous and competing versions written in assembler :-). Bruce From owner-freebsd-hardware Wed May 21 00:16:53 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id AAA24161 for hardware-outgoing; Wed, 21 May 1997 00:16:53 -0700 (PDT) Received: from hydrogen.nike.efn.org (resnet.uoregon.edu [128.223.170.28]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id AAA24155 for ; Wed, 21 May 1997 00:16:48 -0700 (PDT) Received: (from jmg@localhost) by hydrogen.nike.efn.org (8.8.5/8.8.5) id AAA27493; Wed, 21 May 1997 00:17:48 -0700 (PDT) Message-ID: <19970521001748.32607@hydrogen.nike.efn.org> Date: Wed, 21 May 1997 00:17:48 -0700 From: John-Mark Gurney To: Bruce Evans Cc: brett@lariat.org, HARDWARE@FreeBSD.ORG, rberndt@nething.com, WELCHDW@wofford.edu Subject: Re: isa bus and boca multiport boards References: <199705210516.PAA05401@godzilla.zeta.org.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.69 In-Reply-To: <199705210516.PAA05401@godzilla.zeta.org.au>; from Bruce Evans on Wed, May 21, 1997 at 03:16:17PM +1000 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-hardware@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Bruce Evans scribbled this message on May 21: > >>Since the entire set of ports must be scanned whenever an interrupt occurs, > >>maybe there is too much delay in getting to the upper ports. Something gets > >>locked up if they overflow. I left several messages, but no one could > >>figure it out. > > Probably not. Scanning all (inactive) ports takes about 1/4 as long as > handing one fully active 16550 port. Scanning 16 fully active ports > at 115200 bops takes too long for the default (unconfigurable :-() > fifo trigger level. However, having 16 fully active ports is rare. so should I commit my changes that allow the sio to set 16550's to a trigger level of 8? and possibly make it more generic than it already is and allow people to define the resulting fifo level of the uart? > Nope. There are only some minor C inefficiencies in the important parts > of the driver. The code is within 50% of best possible generic i386 > assembler code by static instruction counts, but this is unimportant hmm... now just to get a compiler like Watcomm that has optimization that works and isn't broken... a friend has this and he literally looked at code outputed by it, and couldin't inprove the asm output at ALL... of course you'd need to convince them to add support for FreeBSD's a.out format as right now it's a DOS/Win/OS2 based compiler... :( -- John-Mark Cu Networking Modem/FAX: +1 541 683 6954 Live in Peace, destroy Micro$oft, support free software, run FreeBSD From owner-freebsd-hardware Wed May 21 00:23:54 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id AAA24514 for hardware-outgoing; Wed, 21 May 1997 00:23:54 -0700 (PDT) Received: from tfs.com (tfs.com [140.145.250.1]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id AAA24508 for ; Wed, 21 May 1997 00:23:53 -0700 (PDT) Received: from critter.dk.tfs.com by tfs.com (smail3.1.28.1) with SMTP id m0wU5k1-0003wBC; Wed, 21 May 97 00:23 PDT Received: from critter (localhost [127.0.0.1]) by critter.dk.tfs.com (8.8.5/8.8.5) with ESMTP id JAA01379; Wed, 21 May 1997 09:21:46 +0200 (CEST) To: Bruce Evans cc: brett@lariat.org, HARDWARE@freebsd.org, rberndt@nething.com, WELCHDW@wofford.edu From: Poul-Henning Kamp Subject: Re: isa bus and boca multiport boards In-reply-to: Your message of "Wed, 21 May 1997 15:16:17 +1000." <199705210516.PAA05401@godzilla.zeta.org.au> Date: Wed, 21 May 1997 09:21:45 +0200 Message-ID: <1377.864199305@critter> Sender: owner-hardware@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Would anything be gained from having a #ifdef that makes the driver understand 16550A only ? -- Poul-Henning Kamp | phk@FreeBSD.ORG FreeBSD Core-team. http://www.freebsd.org/~phk | phk@login.dknet.dk Private mailbox. whois: [PHK] | phk@tfs.com TRW Financial Systems, Inc. Power and ignorance is a disgusting cocktail. From owner-freebsd-hardware Wed May 21 00:43:01 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id AAA25456 for hardware-outgoing; Wed, 21 May 1997 00:43:01 -0700 (PDT) Received: from hydrogen.nike.efn.org (resnet.uoregon.edu [128.223.170.28]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id AAA25446 for ; Wed, 21 May 1997 00:42:55 -0700 (PDT) Received: (from jmg@localhost) by hydrogen.nike.efn.org (8.8.5/8.8.5) id AAA27537; Wed, 21 May 1997 00:44:05 -0700 (PDT) Message-ID: <19970521004405.04664@hydrogen.nike.efn.org> Date: Wed, 21 May 1997 00:44:05 -0700 From: John-Mark Gurney To: Bruce Evans Cc: brett@lariat.org, HARDWARE@freebsd.org, rberndt@nething.com, WELCHDW@wofford.edu Subject: Re: isa bus and boca multiport boards References: <199705210705.RAA10446@godzilla.zeta.org.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.69 In-Reply-To: <199705210705.RAA10446@godzilla.zeta.org.au>; from Bruce Evans on Wed, May 21, 1997 at 05:05:21PM +1000 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-hardware@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Bruce Evans scribbled this message on May 21: > >I was under the impression that this is what was already done, but now that > >I look at it, I see that you're right! The code loops on a variable called > >"unit", incrementing it from 0 to the precompiled constant NSIO. This can > >waste a great deal of time, especially since the interrupts are > >edge-triggered and the list is scanned at least twice per interrupt. > > Many minor improvements are possible, but significant improvements are > difficult to achieve without a hardware register giving a bitmap of the > active interrupts. I believe BocaBoards have register(s) for this. > Someone who has a BocaBoard should implement checking the register. I have a couple 4port boards that have this... I was at one point going to work on this.. but quickly quit as I was just beging kernel work.. and didn't feel like creating a new way to map a siox to portx on the board... but right now I think that if we first break down the code to support only one set of ports per intrupt insteads of scanning 'em all then a small bit of code could be layered on that to support using the register... I'm forming an idea in my head on how to code this... if no one else is going to code this then I'll start work on it RSN... :) > >The edge-catching algorithm is also less efficient than it might be. To > >make sure you haven't missed an edge, you must scan the UARTs and get ALL > >THE WAY AROUND THE LIST ONCE without finding any more ports to service. You > >can then return from the ISR. The two best ways to do this are (a) set a > > I never got around to implementing this. hmm... this shouldn't be that hard to add... I think I'll start testing something that does this... all we can say is that smart cards are infinately better than the old 16x50 uarts in these regards... of course they happen to be quite a bit cheaper... oh well... ttyl.. -- John-Mark Cu Networking Modem/FAX: +1 541 683 6954 Live in Peace, destroy Micro$oft, support free software, run FreeBSD From owner-freebsd-hardware Wed May 21 01:16:30 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id BAA27075 for hardware-outgoing; Wed, 21 May 1997 01:16:30 -0700 (PDT) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id BAA27068 for ; Wed, 21 May 1997 01:16:28 -0700 (PDT) Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.5/8.6.9) id SAA12862; Wed, 21 May 1997 18:10:16 +1000 Date: Wed, 21 May 1997 18:10:16 +1000 From: Bruce Evans Message-Id: <199705210810.SAA12862@godzilla.zeta.org.au> To: bde@zeta.org.au, garycorc@idt.net Subject: Re: isa bus and boca multiport boards Cc: HARDWARE@FreeBSD.ORG Sender: owner-hardware@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >> On a P5/133, about 300 pointer dereferences can be >> done in the time it takes to do one i/o instruction. > >I know this discussion was concerning I/O ports on the ISA bus, >but I'm curious if you know: How long does a single I/O (read or >write) take when accessing an I/O port on the PCI bus? PCI accesses port accesses seem to average about 3 times faster on my system: Times in usec for inb() from selected ports on an ASUS P55TP4XE with a P5/133: min av max speed important for FreeBSD? ----- ----- ----- ---------------------------- 0x21 (pic0 mask) .448 .449 .451 yes 0x40 (timer counter 0) .702 .703 .704 yes (2.1), no (current) 0x43 (timer mode) 1.179 1.180 1.181 yes (2.1), no (current) 0x60 (kbd data) 1.179 1.180 1.182 no 0x64 (kbd status) 1.179 1.180 1.182 no 0x70 (rtc index) 1.236 1.237 1.239 no 0x71 (rtc data) 1.179 1.180 1.181 no 0x1f0 (wdc0 data) 0.754 0.755 0.757 yes 0x1f7 (wdc0 status) 1.176 1.177 1.178 no 0x3d4 (crtc index) 1.236 1.237 1.239 no 0x3d4 (crtc data) 0.393 0.393 0.395 no 0x3d5 (crtc data) 0.393 0.393 0.395 no 0x3f4 (fdc0 status) 1.179 1.180 1.181 no 0x3f5 (fdc0 data) 1.179 1.180 1.182 no (< other fd slowness) 0x3f8 (sio0 data) 1.179 1.180 1.182 only if you use sio a lot 0xe428 (de0 status) 0.332 0.333 0.334 yes (if = data access speed) addr+0x14 (ncr0 status) 0.363 0.363 0.394 yes (if = data access speed) I think the minimum access time is 30 nsec for PCI. There are no signs of that here. Accesses can be wider than for ISA, but cheap serial boards based on 8-bit UARTs are unlikely to implement anything other than 8-bit accesses. These times are for 356 iterations of the syscall implemented by the following lkm (recompiled for each address): --- #include #include #include #include #include #include static int mycall(struct proc *p, void *uap, int *retval); static struct sysent newent = { 0, mycall, }; MOD_SYSCALL(newsyscall_mod, -1, &newent); extern int newsyscall_mod(struct lkm_table *lkmtp, int cmd, int ver); int newsyscall_mod(struct lkm_table *lkmtp, int cmd, int ver) { MOD_DISPATCH(newsyscall_mod, lkmtp, cmd, ver, lkm_nullcmd, lkm_nullcmd, lkm_nullcmd) } static int mycall(struct proc *p, void *uap, int *retval) { int i; unsigned char icu; struct timeval f, s; icu = inb(0x21); outb(0x21, 0xff); microtime(&s); for (i = 0; i < 1000; ++i) #define IOMAPPED #ifdef IOMAPPED inb(0xe428); #else *(volatile char *)0xf461a014; /* where my ncr happened to be mapped */ #endif microtime(&f); outb(0x21, icu); *retval = 1000000 * (f.tv_sec - s.tv_sec) + f.tv_usec - s.tv_usec; return 0; } --- Bruce From owner-freebsd-hardware Wed May 21 01:21:54 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id BAA27378 for hardware-outgoing; Wed, 21 May 1997 01:21:54 -0700 (PDT) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id BAA27373 for ; Wed, 21 May 1997 01:21:51 -0700 (PDT) Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.5/8.6.9) id SAA13146; Wed, 21 May 1997 18:17:15 +1000 Date: Wed, 21 May 1997 18:17:15 +1000 From: Bruce Evans Message-Id: <199705210817.SAA13146@godzilla.zeta.org.au> To: bde@zeta.org.au, phk@dk.tfs.com Subject: Re: isa bus and boca multiport boards Cc: brett@lariat.org, HARDWARE@FreeBSD.ORG, rberndt@nething.com, WELCHDW@wofford.edu Sender: owner-hardware@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >Would anything be gained from having a #ifdef that makes the driver >understand 16550A only ? A little. Most of the gains can be obtained by just attaching a UART- specific interrupt handler. My version has the configuration of the interrupt handler moved out of the config file so that the driver can configure it better. I only use this to avoid going through siointr() to siointr1() in the non-COM_MULTIPORT case so far. Bruce From owner-freebsd-hardware Wed May 21 02:51:37 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id CAA01182 for hardware-outgoing; Wed, 21 May 1997 02:51:37 -0700 (PDT) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id CAA01174 for ; Wed, 21 May 1997 02:51:35 -0700 (PDT) Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.5/8.6.9) id TAA16556; Wed, 21 May 1997 19:48:47 +1000 Date: Wed, 21 May 1997 19:48:47 +1000 From: Bruce Evans Message-Id: <199705210948.TAA16556@godzilla.zeta.org.au> To: bde@zeta.org.au, jmg@hydrogen.nike.efn.org Subject: Re: isa bus and boca multiport boards Cc: brett@lariat.org, HARDWARE@FreeBSD.ORG, rberndt@nething.com, WELCHDW@wofford.edu Sender: owner-hardware@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >all we can say is that smart cards are infinately better than the old >16x50 uarts in these regards... of course they happen to be quite a bit >cheaper... oh well... We can't say that. Faster i/o is much better. Larger fifos are slightly better. Smartness tends to get in the way unless it implements exactly the protocol that you want. Bruce From owner-freebsd-hardware Wed May 21 02:54:58 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id CAA01378 for hardware-outgoing; Wed, 21 May 1997 02:54:58 -0700 (PDT) Received: from TRUTH.WOFFORD.EDU (truth.wofford.edu [199.190.174.30]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id CAA01373 for ; Wed, 21 May 1997 02:54:55 -0700 (PDT) Date: Wed, 21 May 1997 5:54:55 -0400 From: Dan Welch To: "TRUTH::WELCHDW"@wofford.edu CC: HARDWARE@FREEBSD.ORG, WELCHDW@wofford.edu Message-Id: <970521055455.22a210ad@wofford.edu> Subject: Re: isa bus and boca multiport boards Sender: owner-hardware@FREEBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > I/O ports 0x278-0x27F are standard for an LPT (parallel) port. Yes, that was my first thought, too, but the systems all have only lpt0 (at 0x378) as far as I can tell. > In addition, port 0x279 is used for Plug-N-Play setup. Thanks for that address. I didn't know it, so my approach was to move the board to a system older than p-n-p motherboards and non-pci for same reason: I don't know all addresses used by pci. The problem persisted in altered form on the older system. > And, IRQ 12 is used for PS/2 mouse ports built into motherboards. I used the cmos setup to turn that off. Is that reliable? I was unsure, so I tested at a couple other free irq's just in case. The "bad" ports do change with these alterations, supporting the contention hypothesis, but also consistent with a bus timing problem, I think. Those tests all have the shortcoming of having been at irq>9 since all irq<9 are busy. Guess I'll free an irq<9 and try the 0x100 range again with that. From owner-freebsd-hardware Wed May 21 03:16:58 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id DAA02279 for hardware-outgoing; Wed, 21 May 1997 03:16:58 -0700 (PDT) Received: from Sisyphos.MI.Uni-Koeln.DE (Sisyphos.MI.Uni-Koeln.DE [134.95.212.10]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id DAA02273 for ; Wed, 21 May 1997 03:16:54 -0700 (PDT) Received: from x14.mi.uni-koeln.de (annexr3-17.slip.Uni-Koeln.DE) by Sisyphos.MI.Uni-Koeln.DE with SMTP id AA05404 (5.67b/IDA-1.5 for ); Wed, 21 May 1997 12:16:33 +0200 Received: (from se@localhost) by x14.mi.uni-koeln.de (8.8.5/8.6.9) id MAA02538; Wed, 21 May 1997 12:16:34 +0200 (CEST) X-Face: " Date: Wed, 21 May 1997 12:16:33 +0200 From: Stefan Esser To: Bruce Evans Cc: garycorc@idt.net, HARDWARE@FreeBSD.ORG Subject: Re: isa bus and boca multiport boards References: <199705210810.SAA12862@godzilla.zeta.org.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.73 In-Reply-To: <199705210810.SAA12862@godzilla.zeta.org.au>; from Bruce Evans on Wed, May 21, 1997 at 06:10:16PM +1000 Sender: owner-hardware@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On May 21, Bruce Evans wrote: > >> On a P5/133, about 300 pointer dereferences can be > >> done in the time it takes to do one i/o instruction. > > > >I know this discussion was concerning I/O ports on the ISA bus, > >but I'm curious if you know: How long does a single I/O (read or > >write) take when accessing an I/O port on the PCI bus? > > PCI accesses port accesses seem to average about 3 times faster on my > system: > > Times in usec for inb() from selected ports on an ASUS P55TP4XE with > a P5/133: > > min av max speed important for FreeBSD? > ----- ----- ----- ---------------------------- > 0x3d4 (crtc data) 0.393 0.393 0.395 no > 0x3d5 (crtc data) 0.393 0.393 0.395 no > 0xe428 (de0 status) 0.332 0.333 0.334 yes (if = data access speed) > addr+0x14 (ncr0 status) 0.363 0.363 0.394 yes (if = data access speed) > > I think the minimum access time is 30 nsec for PCI. There are no signs > of that here. Accesses can be wider than for ISA, but cheap serial > boards based on 8-bit UARTs are unlikely to implement anything other > than 8-bit accesses. No, PCI uses a bus cycle time of 30ns (33MHz) maximum, but the shortest access latency to a single data item is 4 bus clocks (120ns). Your fastest register accesses seem to require 11 and 13 PCI bus cycles, though. The NCR chip uses a 12 cycle micro-program that controls all its operations, which explains the delay you found. 1) The CPU has to apply all the signals for the port access, and the host to PCI bridge has to decode them before it can start a PCI cycle. 2) The PCI bus may have been "parked" at some other bus master. In order to give the output drivers of the current master time to go into a high impedance state, one cycle of delay is added. 3) The adresses are driven on the address/data bus and the byte selects are applied. The PCI chips now have a few cycles to claim the transaction. Each device announces its maximum decode delay in a configuration space register, and it is typical to specify "middle" speed, which means one wait state is added while addresses are on the bus. (This is controlled by a chip-set register, which is set after the PCI BIOS has identified the waits required by the slowest device on the bus.) 4) While PCI uses positive decoding of address ranges throughout, there is one exception for a legacy bus allowed. This means, that after no PCI device decoded the address on the bus, the PCI to ISA bridge will claim it and will generate an ISA port access. 5) If the ISA compatibility devices are part of the PCI chip set, this chip set should claim the transaction. (I.e. there should never be a ISA transaction generated for accesses to these ports.) 6) After the PCI chip (or the PCI to ISA bridge) has applied the DEVSEL signal, the bus has to be turned around. This means changing the bus owner chip, if the host to PCI bridge and the ISA devices chip are on seperate silicon and will add the one cycle delay to turn off the drivers of the chip set. 7) After the device has claimed the transaction, it must send data after a maximum of 8 PCI bus cycles, or it must signal a retry to the chip set and release the bus (similar to a SCSI diconnect, but the initiator is responsible for retrying the transfer at a later time). 8) After the device sent its data, it will give up the bus. There will be another cycle of delay, before the host to PCI bridge will be able to put an address on the bus again ... 9) The CPU will receive the data with some delay, since it flows through a FIFO in the host to PCI bridge. 10) There appears to be a "built-in" delay in the x86 CPUs, which adds a few wait states independently of any delays caused by the devices. There also are wait states added for each I/O by the chip set (I've forgot the name of that register, but it was some thing like "I/O recovery"), typically 2 to 4 cycles, IIRC. Regards, STefan From owner-freebsd-hardware Wed May 21 03:28:18 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id DAA02876 for hardware-outgoing; Wed, 21 May 1997 03:28:18 -0700 (PDT) Received: from tfs.com (tfs.com [140.145.250.1]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id DAA02871 for ; Wed, 21 May 1997 03:28:17 -0700 (PDT) Received: from critter.dk.tfs.com by tfs.com (smail3.1.28.1) with SMTP id m0wU8cT-0003zKC; Wed, 21 May 97 03:27 PDT Received: from critter (localhost [127.0.0.1]) by critter.dk.tfs.com (8.8.5/8.8.5) with ESMTP id MAA01618; Wed, 21 May 1997 12:26:10 +0200 (CEST) To: Bruce Evans cc: brett@lariat.org, gurney_j@resnet.uoregon.edu, HARDWARE@freebsd.org, rberndt@nething.com, WELCHDW@wofford.edu From: Poul-Henning Kamp Subject: Re: isa bus and boca multiport boards In-reply-to: Your message of "Wed, 21 May 1997 17:05:21 +1000." <199705210705.RAA10446@godzilla.zeta.org.au> Date: Wed, 21 May 1997 12:26:09 +0200 Message-ID: <1616.864210369@critter> Sender: owner-hardware@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >>1) The code looks at a flag called "gone" on each and every port (present >>or not) during each and every interrupt service. Since the presence or >>absence of a port is determined at boot time, it'd be MUCH more efficient >>if the code worked down a linear list of only the ports that were present >>and on the relevant IRQ. "gone" means that somebody unplugged a PCCARD modem, and it's very important to check it before you start talking to thin air. You could #ifdef it, but you'd gain only epsilon. -- Poul-Henning Kamp | phk@FreeBSD.ORG FreeBSD Core-team. http://www.freebsd.org/~phk | phk@login.dknet.dk Private mailbox. whois: [PHK] | phk@tfs.com TRW Financial Systems, Inc. Power and ignorance is a disgusting cocktail. From owner-freebsd-hardware Wed May 21 03:44:06 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id DAA03451 for hardware-outgoing; Wed, 21 May 1997 03:44:06 -0700 (PDT) Received: from bagpuss.visint.co.uk (bagpuss.vis.net.uk [194.207.134.1]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id DAA03446 for ; Wed, 21 May 1997 03:44:01 -0700 (PDT) Received: from bagpuss.visint.co.uk (bagpuss.vis.net.uk [194.207.134.1]) by bagpuss.visint.co.uk (8.7.5/8.7.3) with SMTP id LAA00515; Wed, 21 May 1997 11:48:35 +0100 (BST) Date: Wed, 21 May 1997 11:48:35 +0100 (BST) From: Stephen Roome To: Wes Santee cc: freebsd-hardware@FreeBSD.ORG Subject: Re: Any luck with EE Pro/10? In-Reply-To: <199705201927.MAA06138@lister.bogon.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hardware@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Firstly, this might not be of help in finding problems, more of a guide that others are still having problems. On Tue, 20 May 1997, Wes Santee wrote: > 'Lo all. Are there specific problems with the ex driver in 2.2 that I > should know about? I'm not sure about specific problems, but I've experienced some rather serious problems with the etherexpress cards as well under 3.0-970209-SNAP, and -current. I just didn't get round to reporting them yet as I thought I was just being stupid again. (often the case) I don't know which driver you are using but, I've been using ex, and I've not tried ie yet, but I'm under the impression that most EE's are 82597 based and that ie(4) drives only the 82586 (according to the man page). I've noticed the following: - unable to use UTP, works to some extent over BNC. - unable to multicast etc. (this is documented in source though) - need to ifconfig many times with different (+)/-link options many times before my EE works to any extent. - Almost consistent failure to detect which network port is being used, the driver always seems to say UTP, regardless of softset or cabling. I don't think any of these problems were due to incorrect setting from softset either, as I've not had problems detecting the card yet. Mainly the problems are with the driver just not working. I expect some other people are having the same problems as well, I didn't have time to mess about last time and just swapped in a DE21140. It's often faster and I beleive there are some known problems with the EE Pro10 not actually being able to multicast properly due to it not being a very good card. (I'd normally phrase that differently!) -- Steve Roome Technical Systems Manager, Vision Interactive Ltd. E: steve@visint.co.uk M: +44 (0) 976 241 342 T: +44 (0) 117 973 0597 F: +44 (0) 117 923 8522 From owner-freebsd-hardware Wed May 21 04:10:09 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id EAA04461 for hardware-outgoing; Wed, 21 May 1997 04:10:09 -0700 (PDT) Received: from trifork.gu.net (trifork.gu.net [194.93.190.194]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id EAA04448 for ; Wed, 21 May 1997 04:10:02 -0700 (PDT) Received: from localhost (localhost.gu.kiev.ua [127.0.0.1]) by trifork.gu.net (8.8.5/8.8.5) with SMTP id OAA19585; Wed, 21 May 1997 14:11:15 +0300 (EEST) Date: Wed, 21 May 1997 14:11:15 +0300 (EEST) From: Andrew Stesin Reply-To: stesin@gu.net To: Dan Welch cc: "TRUTH::WELCHDW"@wofford.edu, HARDWARE@FreeBSD.ORG Subject: Re: isa bus and boca multiport boards In-Reply-To: <970521055455.22a210ad@wofford.edu> Message-ID: X-NCC-RegID: ua.gu MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hardware@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Wed, 21 May 1997, Dan Welch wrote: > > And, IRQ 12 is used for PS/2 mouse ports built into motherboards. > > I used the cmos setup to turn that off. Is that reliable? No. I've seen myself that disabling PS/2 mouse in BIOS doesn't leave IRQ12 for you -- last time that was on Packard Bell 486 box, with Phoenix BIOS, when we tried to install second AHA-1542 in it. Despite of disabling PS/2 in BIOS, 1542 did all kinds of strange and mysterious things ("going to polling mode", loosing interrupts, etc.) until we moved it from IRQ12 to some other one. Best regards, Andrew Stesin nic-hdl: ST73-RIPE From owner-freebsd-hardware Wed May 21 05:42:52 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id FAA08123 for hardware-outgoing; Wed, 21 May 1997 05:42:52 -0700 (PDT) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id FAA08112; Wed, 21 May 1997 05:42:35 -0700 (PDT) Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.5/8.6.9) id WAA23416; Wed, 21 May 1997 22:36:31 +1000 Date: Wed, 21 May 1997 22:36:31 +1000 From: Bruce Evans Message-Id: <199705211236.WAA23416@godzilla.zeta.org.au> To: bde@zeta.org.au, se@FreeBSD.ORG Subject: Re: isa bus and boca multiport boards Cc: garycorc@idt.net, HARDWARE@FreeBSD.ORG Sender: owner-hardware@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >> Times in usec for inb() from selected ports on an ASUS P55TP4XE with >> a P5/133: >> >> min av max speed important for FreeBSD? >> ----- ----- ----- ---------------------------- >> 0x3d4 (crtc data) 0.393 0.393 0.395 no >> 0x3d5 (crtc data) 0.393 0.393 0.395 no >> 0xe428 (de0 status) 0.332 0.333 0.334 yes (if = data access speed) >> addr+0x14 (ncr0 status) 0.363 0.363 0.394 yes (if = data access speed) I tried using 1 ins[bwl](port, dummyaddr, 1000) instead of 1000 inb's. The results were (perhaps not surprisingly) similar. They were within 1 nsec for de0, varied a lot with the access size for the crtc, and were within 1 nsec for ins[bw] from wdc0 and twice as large for insl from wdc0 (1510 nsec instead of 755 nsec). The latter is a bit surprising - my wdc0 is configured for and uses 32-bit accesses and has a 16MB/s transfer speed, yet 4 bytes per 1510 nsec is only 2.65 MB/s. I guess the wdc data register is only valid when there is real data available :-). >> I think the minimum access time is 30 nsec for PCI. There are no signs >> of that here. Accesses can be wider than for ISA, but cheap serial >> boards based on 8-bit UARTs are unlikely to implement anything other >> than 8-bit accesses. > >No, PCI uses a bus cycle time of 30ns (33MHz) maximum, >but the shortest access latency to a single data item >is 4 bus clocks (120ns). Your fastest register accesses >seem to require 11 and 13 PCI bus cycles, though. >The NCR chip uses a 12 cycle micro-program that controls >all its operations, which explains the delay you found. > >1) The CPU has to apply all the signals for the port > access, and the host to PCI bridge has to decode > them before it can start a PCI cycle. > >2) The PCI bus may have been "parked" at some other > bus master. In order to give the output drivers > of the current master time to go into a high > impedance state, one cycle of delay is added. Clearly some magic (like data available :-) is required to get burst mode. Do you thing 300+ nsec is typical for non-data registers? Bruce From owner-freebsd-hardware Wed May 21 06:02:59 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id GAA08765 for hardware-outgoing; Wed, 21 May 1997 06:02:59 -0700 (PDT) Received: from TRUTH.WOFFORD.EDU (truth.wofford.edu [199.190.174.30]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id GAA08760 for ; Wed, 21 May 1997 06:02:54 -0700 (PDT) Date: Wed, 21 May 1997 9:02:43 -0400 From: Dan Welch To: stesin@gu.net CC: HARDWARE@FREEBSD.ORG, WELCHDW@wofford.edu Message-Id: <970521090243.22a1ce87@wofford.edu> Subject: Re: isa bus and boca multiport boards Sender: owner-hardware@FREEBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >> > And, IRQ 12 is used for PS/2 mouse ports built into motherboards. >> >> I used the cmos setup to turn that off. Is that reliable? > > No. I've seen myself that disabling PS/2 mouse > in BIOS doesn't leave IRQ12 for you -- last time > that was on Packard Bell 486 box, with Phoenix BIOS, > when we tried to install second AHA-1542 in it. > > Despite of disabling PS/2 in BIOS, 1542 did all kinds > of strange and mysterious things ("going to polling > mode", loosing interrupts, etc.) until we moved it > from IRQ12 to some other one. Just as I feared ... thanks for sharing your experience. From owner-freebsd-hardware Wed May 21 06:26:02 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id GAA09588 for hardware-outgoing; Wed, 21 May 1997 06:26:02 -0700 (PDT) Received: from Sisyphos.MI.Uni-Koeln.DE (Sisyphos.MI.Uni-Koeln.DE [134.95.212.10]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id GAA09578 for ; Wed, 21 May 1997 06:25:56 -0700 (PDT) Received: from x14.mi.uni-koeln.de (annexr2-44.slip.Uni-Koeln.DE) by Sisyphos.MI.Uni-Koeln.DE with SMTP id AA08990 (5.67b/IDA-1.5 for ); Wed, 21 May 1997 15:25:44 +0200 Received: (from se@localhost) by x14.mi.uni-koeln.de (8.8.5/8.6.9) id PAA03640; Wed, 21 May 1997 15:25:45 +0200 (CEST) X-Face: " Date: Wed, 21 May 1997 15:25:44 +0200 From: Stefan Esser To: Bruce Evans Cc: garycorc@idt.net, HARDWARE@FreeBSD.ORG Subject: Re: isa bus and boca multiport boards References: <199705211236.WAA23416@godzilla.zeta.org.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.73 In-Reply-To: <199705211236.WAA23416@godzilla.zeta.org.au>; from Bruce Evans on Wed, May 21, 1997 at 10:36:31PM +1000 Sender: owner-hardware@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On May 21, Bruce Evans wrote: > I tried using 1 ins[bwl](port, dummyaddr, 1000) instead of 1000 inb's. > The results were (perhaps not surprisingly) similar. They were within 1 > nsec for de0, varied a lot with the access size for the crtc, and were > within 1 nsec for ins[bw] from wdc0 and twice as large for insl from > wdc0 (1510 nsec instead of 755 nsec). The latter is a bit surprising > - my wdc0 is configured for and uses 32-bit accesses and has a 16MB/s > transfer speed, yet 4 bytes per 1510 nsec is only 2.65 MB/s. I guess > the wdc data register is only valid when there is real data available :-). I'm not sure I understand what happens, but it might be like this: The PCI bus specs limit the time a single transfer may take to 16 bus cycles. If a device can't send deliver valid data within that time, it must back off. (If a device knows it can't deliver data with little delay, then it should acknowledge the address phase, but immediately signal a retry is necessary. This makes the bus available for other bus masters, and when the host to PCI bridge requests the same data again, a few hundred nanoseconds later, the slow chip should have prepared it in its output buffer and should respond fast to this repeated request.) Anyway, if the IDE chip finds it can't deliver any data, then it will signal an abort (and probably set a flag in a status register). The PCI IDE interface will try to retrieve the second 16bit word thereafter, if you are doing a DWORD register access, and this will fail after the same time. I guess that is ithe reason you see exactly twice delay in the insl case ... The delay of some 750ns is equivalent to 25 PCI bus cycles. This is slightly more than the allowed 16 wait cycles, but is in line with the other delays yor found (11 clocks best case). If the 25 cycles are 10 cycles for the fastests possible inb() and 15 wait cycles, then this looks self-consistent at least :) I guess the 32bit IDE hardware is just to dumb to know it need not try to fetch the second 16bits after the first transfer failed to deliver any data ... > >2) The PCI bus may have been "parked" at some other > > bus master. In order to give the output drivers > > of the current master time to go into a high > > impedance state, one cycle of delay is added. > > Clearly some magic (like data available :-) is required to > get burst mode. Do you thing 300+ nsec is typical for > non-data registers? Well, there is no such thing as burst mode I/O in PCI :) Burst transfers are only defined for memory accesses ... Regards, STefan From owner-freebsd-hardware Wed May 21 06:40:00 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id GAA10209 for hardware-outgoing; Wed, 21 May 1997 06:40:00 -0700 (PDT) Received: from lariat.lariat.org (ppp0.lariat.org@[129.72.251.2]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id GAA10203 for ; Wed, 21 May 1997 06:39:57 -0700 (PDT) Received: from solo.lariat.org ([129.72.251.10]) by lariat.lariat.org (8.8.5/8.8.5) with SMTP id HAA14215; Wed, 21 May 1997 07:39:22 -0600 (MDT) Message-Id: <3.0.1.32.19970521074016.00736a68@lariat.org> X-Sender: brett@lariat.org X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Wed, 21 May 1997 07:40:16 -0600 To: Michael Smith From: Brett Glass Subject: Re: isa bus and boca multiport boards Cc: rberndt@nething.com, WELCHDW@wofford.edu, HARDWARE@FreeBSD.ORG In-Reply-To: <199705210404.NAA08585@genesis.atrad.adelaide.edu.au> References: <3.0.1.32.19970520125159.006dbe70@lariat.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-hardware@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk At 01:34 PM 5/21/97 +0930, Michael Smith wrote: >(cocks an ear listening for the ICBM leaving bde's desk). > >I don't think that would be a very popular idea; the sio driver should be >more, not less, machine independant. It's already hopelessly machine-dependent, due to the nature of the quirky UARTs and edge-triggered interrupts. I don't think there's much value in trying to maintain machine independence in the inner loops, where the C code is slowing things down. But even with C, many optimizations would be possible, as described in my message. I've noticed a significant slowdown with the latest drivers, and would really like the speed back! --Brett From owner-freebsd-hardware Wed May 21 06:46:30 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id GAA10539 for hardware-outgoing; Wed, 21 May 1997 06:46:30 -0700 (PDT) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id GAA10534 for ; Wed, 21 May 1997 06:46:27 -0700 (PDT) Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.5/8.6.9) id XAA26555; Wed, 21 May 1997 23:44:29 +1000 Date: Wed, 21 May 1997 23:44:29 +1000 From: Bruce Evans Message-Id: <199705211344.XAA26555@godzilla.zeta.org.au> To: bde@zeta.org.au, jmg@hydrogen.nike.efn.org Subject: Re: isa bus and boca multiport boards Cc: brett@lariat.org, HARDWARE@freebsd.org, rberndt@nething.com, WELCHDW@wofford.edu Sender: owner-hardware@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >so should I commit my changes that allow the sio to set 16550's to a >trigger level of 8? and possibly make it more generic than it already >is and allow people to define the resulting fifo level of the uart? I think it should default to "medium" (FIXO_RX_MEDH) if NSIO > 4 and there should be ioctls to change both the receiver trigger level and transmitter fifo size (NetBSD users recently reported problems with external devices not being able to handle 16 bytes of buffering in the transmitter, because CTS flow control doesn't work for bytes that have been put in the tx fifo). The ioctls should be supported by comcontrol(8). Bruce From owner-freebsd-hardware Wed May 21 07:11:50 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id HAA11797 for hardware-outgoing; Wed, 21 May 1997 07:11:50 -0700 (PDT) Received: from lariat.lariat.org (ppp0.lariat.org@[129.72.251.2]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id HAA11787 for ; Wed, 21 May 1997 07:11:48 -0700 (PDT) Received: from solo.lariat.org ([129.72.251.10]) by lariat.lariat.org (8.8.5/8.8.5) with SMTP id IAA14595; Wed, 21 May 1997 08:11:18 -0600 (MDT) Message-Id: <3.0.1.32.19970521080515.0075bc30@lariat.org> X-Sender: brett@lariat.org X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Wed, 21 May 1997 08:05:15 -0600 To: Bruce Evans , gurney_j@resnet.uoregon.edu From: Brett Glass Subject: Re: isa bus and boca multiport boards Cc: HARDWARE@freebsd.org, rberndt@nething.com, WELCHDW@wofford.edu In-Reply-To: <199705210705.RAA10446@godzilla.zeta.org.au> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-hardware@freebsd.org X-Loop: FreeBSD.org Precedence: bulk At 05:05 PM 5/21/97 +1000, Bruce Evans wrote: >I try to avoid it, and enjoy making serial drivers written in C several >times more efficient than previous and competing versions written in >assembler :-). How about the best of both? By your own analysis, any approach that avoids extra ISA I/O operations is a big win. So is any solution that can drop a slew of pointer dereferences (even if the ratio is 1:16) and avoids polling ports extra times.... --Brett From owner-freebsd-hardware Wed May 21 07:11:53 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id HAA11813 for hardware-outgoing; Wed, 21 May 1997 07:11:53 -0700 (PDT) Received: from lariat.lariat.org (ppp0.lariat.org@[129.72.251.2]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id HAA11796 for ; Wed, 21 May 1997 07:11:50 -0700 (PDT) Received: from solo.lariat.org ([129.72.251.10]) by lariat.lariat.org (8.8.5/8.8.5) with SMTP id IAA14603; Wed, 21 May 1997 08:11:24 -0600 (MDT) Message-Id: <3.0.1.32.19970521081005.006a2a6c@lariat.org> X-Sender: brett@lariat.org X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Wed, 21 May 1997 08:10:05 -0600 To: Poul-Henning Kamp , Bruce Evans From: Brett Glass Subject: Re: isa bus and boca multiport boards Cc: gurney_j@resnet.uoregon.edu, HARDWARE@freebsd.org, rberndt@nething.com, WELCHDW@wofford.edu In-Reply-To: <1616.864210369@critter> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-hardware@freebsd.org X-Loop: FreeBSD.org Precedence: bulk At 12:26 PM 5/21/97 +0200, Poul-Henning Kamp wrote: >"gone" means that somebody unplugged a PCCARD modem, and it's very >important to check it before you start talking to thin air. > >You could #ifdef it, but you'd gain only epsilon. Instead, how about building the list of ports to scan outside the ISR? You'd lose the null pointer check PLUS the check of "gone," so you'd save more like a delta than an epsilon. And there'd be no need for an #ifdef there. --Brett From owner-freebsd-hardware Wed May 21 07:12:20 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id HAA11918 for hardware-outgoing; Wed, 21 May 1997 07:12:20 -0700 (PDT) Received: from lariat.lariat.org (ppp0.lariat.org@[129.72.251.2]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id HAA11911 for ; Wed, 21 May 1997 07:12:18 -0700 (PDT) Received: from solo.lariat.org ([129.72.251.10]) by lariat.lariat.org (8.8.5/8.8.5) with SMTP id IAA14592; Wed, 21 May 1997 08:11:12 -0600 (MDT) Message-Id: <3.0.1.32.19970521075940.0075bc30@lariat.org> X-Sender: brett@lariat.org X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Wed, 21 May 1997 07:59:40 -0600 To: Michael Smith From: Brett Glass Subject: Re: isa bus and boca multiport boards Cc: gurney_j@resnet.uoregon.edu, rberndt@nething.com, WELCHDW@wofford.edu, HARDWARE@FreeBSD.ORG In-Reply-To: <199705210433.OAA08916@genesis.atrad.adelaide.edu.au> References: <3.0.1.32.19970520181142.00734e08@lariat.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-hardware@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk At 02:03 PM 5/21/97 +0930, Michael Smith wrote: >You would still have to scan all possible ports and consult their softc >'master' port value. True. But you do not have to scan them extra times! One circuit around the list of ports that use the IRQ is sufficient. >> 1) The code looks at a flag called "gone" on each and every port (present >> or not) during each and every interrupt service. Since the presence or >> absence of a port is determined at boot time > >This is not true. Please note where the "gone" flag is manipulated, and >post a correction to your statement when you understand. OK, here's a correction: It's WORSE than that! The loop checks the pointer "com" to see if it's null, and THEN checks "gone." Neither should be done at interrupt time. The list of ports to scan should be built and maintained outside the ISR. >> it may scan as many as NSIO-1 extra ports on each interrupt. On a >> system with a many serial ports, this is a LOT of extra time. > >It's not, actually, all that much. Scanning a port is a single I/O >operation, taking around 1us. At 115200bps, it takes 86us for a >single character to arrive. You're omitting overhead! With a check of a pointer, the check of the flag, loading the port number, doing the I/O, loading the loop counter, and executing a conditional branch, a scan of a port costs much more. >This is an operation possibly best left to the compiler. Have you checked >the generated machine instructions? Haven't disassembled the code yet, but since I've looked at the output of GCC many times, I already know that it has trouble enregistering in loops with pointer dereferences and subroutine calls. >> I don't know what the policy on ASM code is in FreeBSD, but this seems like >> an opportunity to do some VERY serious optimization where it's much needed! > >Processor-specific code in device drivers is not a viable proposition, >given that portability is a significant issue. Is there any other processor with the brain-dead architecture that brings up all of these issues? The 16550A and edge-triggered interrupts are an artifact of the IBM PC, circa 1981; the cascaded 8259's and their quirks are a legacy of the PC/AT, circa 1984. I think that optimization of the ISRs, at the very least, is justified, since this code will NEVER be re-used on other platforms. It's necessarily hardware-dependent. There IS hardware-independent code that should remain portable, but this code can't be made portable; might as well code it tightly and efficiently! --Brett From owner-freebsd-hardware Wed May 21 07:30:19 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id HAA12975 for hardware-outgoing; Wed, 21 May 1997 07:30:19 -0700 (PDT) Received: from tfs.com (tfs.com [140.145.250.1]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id HAA12966; Wed, 21 May 1997 07:30:11 -0700 (PDT) Received: from critter.dk.tfs.com by tfs.com (smail3.1.28.1) with SMTP id m0wUCOZ-0003xVC; Wed, 21 May 97 07:29 PDT Received: from critter (localhost [127.0.0.1]) by critter.dk.tfs.com (8.8.5/8.8.5) with ESMTP id QAA02294; Wed, 21 May 1997 16:28:04 +0200 (CEST) To: Stefan Esser cc: Bruce Evans , garycorc@idt.net, HARDWARE@FreeBSD.ORG From: Poul-Henning Kamp Subject: Re: isa bus and boca multiport boards In-reply-to: Your message of "Wed, 21 May 1997 15:25:44 +0200." <19970521152544.25788@x14.mi.uni-koeln.de> Date: Wed, 21 May 1997 16:28:04 +0200 Message-ID: <2292.864224884@critter> Sender: owner-hardware@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >> Clearly some magic (like data available :-) is required to >> get burst mode. Do you thing 300+ nsec is typical for >> non-data registers? > >Well, there is no such thing as burst mode I/O in PCI :) >Burst transfers are only defined for memory accesses ... Isn't I/O and Memory symmetrical in PCI ? -- Poul-Henning Kamp | phk@FreeBSD.ORG FreeBSD Core-team. http://www.freebsd.org/~phk | phk@login.dknet.dk Private mailbox. whois: [PHK] | phk@tfs.com TRW Financial Systems, Inc. Power and ignorance is a disgusting cocktail. From owner-freebsd-hardware Wed May 21 07:47:56 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id HAA13816 for hardware-outgoing; Wed, 21 May 1997 07:47:56 -0700 (PDT) Received: from mccomm.nl (root@gateppp.mccomm.nl [193.67.87.1]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id HAA13811 for ; Wed, 21 May 1997 07:47:53 -0700 (PDT) Received: from hpserver.mccomm.nl (hpserver.mccomm.nl [193.67.87.13]) by mccomm.nl (8.7.5/8.7.3) with SMTP id QAA05321 for ; Wed, 21 May 1997 16:47:33 +0200 Message-Id: <199705211447.QAA05321@mccomm.nl> Received: by hpserver.mccomm.nl (1.38.193.5/16.2) id AA27964; Wed, 21 May 1997 16:47:33 +0200 From: Rob Schofield Subject: Re: isa bus and boca multiport boards To: freebsd-hardware@freebsd.org (Hardware list at FreeBSD) Date: Wed, 21 May 97 16:47:32 METDST In-Reply-To: <970521090243.22a1ce87@wofford.edu>; from "Dan Welch" at May 21, 97 9:02 am Mailer: Elm [revision: 70.85.2.1] Sender: owner-hardware@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > >> > And, IRQ 12 is used for PS/2 mouse ports built into motherboards. > >> > >> I used the cmos setup to turn that off. Is that reliable? > > > > No. I've seen myself that disabling PS/2 mouse > > in BIOS doesn't leave IRQ12 for you -- last time > > that was on Packard Bell 486 box, with Phoenix BIOS, > > when we tried to install second AHA-1542 in it. > > > > Despite of disabling PS/2 in BIOS, 1542 did all kinds > > of strange and mysterious things ("going to polling > > mode", loosing interrupts, etc.) until we moved it > > from IRQ12 to some other one. > > Just as I feared ... thanks for sharing your experience. > Errr... I hate to say this, but isn't this just a teensy-weensy bit subjective? *One* problem on *one* system means that all systems react the same way? I have successfully operated the same ethernet and RAID cards on interrupt 12 in three seperate systems without any trouble. If you read the PS/2 documentation, it detaches the IRQ line from the built in bus-mouse hardware by disabling a buffer. This is how it works in *PS/2 SYSTEMS ONLY*. How it works in any other system is undefined unless you contact the manufacturer and confirm it... ;^) Rob -- Witticisms are hard to define on Monday mornings... schofiel@xs4all.nl http://www.xs4all.nl/~schofiel rschof@mccomm.nl From owner-freebsd-hardware Wed May 21 09:27:35 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id JAA19048 for hardware-outgoing; Wed, 21 May 1997 09:27:35 -0700 (PDT) Received: from Sisyphos.MI.Uni-Koeln.DE (Sisyphos.MI.Uni-Koeln.DE [134.95.212.10]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id JAA19041 for ; Wed, 21 May 1997 09:27:32 -0700 (PDT) Received: from x14.mi.uni-koeln.de (annexr3-12.slip.Uni-Koeln.DE) by Sisyphos.MI.Uni-Koeln.DE with SMTP id AA12017 (5.67b/IDA-1.5 for ); Wed, 21 May 1997 18:27:20 +0200 Received: (from se@localhost) by x14.mi.uni-koeln.de (8.8.5/8.6.9) id SAA00451; Wed, 21 May 1997 18:26:35 +0200 (CEST) X-Face: " Date: Wed, 21 May 1997 18:26:34 +0200 From: Stefan Esser To: Poul-Henning Kamp Cc: Bruce Evans , garycorc@idt.net, HARDWARE@FreeBSD.ORG Subject: Re: isa bus and boca multiport boards References: <19970521152544.25788@x14.mi.uni-koeln.de> <2292.864224884@critter> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.73 In-Reply-To: <2292.864224884@critter>; from Poul-Henning Kamp on Wed, May 21, 1997 at 04:28:04PM +0200 Sender: owner-hardware@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On May 21, Poul-Henning Kamp wrote: > > >> Clearly some magic (like data available :-) is required to > >> get burst mode. Do you thing 300+ nsec is typical for > >> non-data registers? > > > >Well, there is no such thing as burst mode I/O in PCI :) > >Burst transfers are only defined for memory accesses ... > > Isn't I/O and Memory symmetrical in PCI ? No, not at all! The original PCI concept tolerated I/O ports only to allow legacy drivers to be used with PCI cards, that emulate some common ISA card (like my PCI NE2000 :). There is a note somewhere in the PCI standards docs, that mentions 8086 real mode programs may need to use port mapped I/O. (I've only once heard about some (old) PCI motherboard assigning an address below 1MB to some PCI device. This prevents DOS driver access to those memory mapped registers, and you want to use port I/O under DOS for that reason.) There are three memory read "commands" and two memory write "commands", BTW. (PCI uses the byte enables to carry a 4bit command in the address phase. There are no seperate lines to signal memory/port or read/write as they are found on most other buses.) The three read commands are: read read-line read-multiple The two write commands are: write write-and-invalidate The read command is used for single word transfers or for short bursts. If a full cache line worth of data is to be read, the read-line command is used. For two or more cache-line transfers, the read-line command is to be used. The write-and-invalidate command is to be used, if a complete cache line is to be written by some bus master. It signals to the CPU and chip set, that the contents of this cache line may be discarded if present int the primary and/or secondary cache instead of a write back that would be necessary if only part of the cache line was to be updated by the bus master. The write-and-invalidate does also allow for all but the first snoop cycles to be suppressed, since the CPU is known to not have that line in the cache, thereafter. Intel x86 CPU's don't write-allocate (the K5(?) and K6 in certain situations, though), and the cache line must be filled with the new values written by the bus-master, before the CPU can read or write them. The read-line and read-and-invalidate may reduce the number of snoop cycles, too, but their primary purpose is to make PCI to PCI bridges prefetch data from devices that are known to tolerate read-ahead. The access latency caused by a PCI to PCI bridge is multiple cycles (i never tried to measure the effect, but my estimate is some 4 to 6 PCI clocks or 120ns to 180ns), and without the read-ahead feature, this penalty had to be payed for each single DWORD transfered ... Burst modes are required to increment the targets address register by 4bytes after each transfer. There exists no burst transfer to (or from) a constant address, and that is a reason that bursts are not supported for port I/O. There is an assumption, that data can be read-ahead, and then just thrown away, if it is not accepted by the intiator of the transferi (for example because the bus-master run out of time, i.e. the latency timer expired). The initiator will in such a case restart the transfer as soon as it gets the PCI bus granted again, and it will restart the transfer at an address that is 4 higher per DWORD received. This can't be easily implemented with port mapped buffers, and for that reason no port burst transfers have been defined ... Regards, STefan From owner-freebsd-hardware Wed May 21 09:36:48 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id JAA19555 for hardware-outgoing; Wed, 21 May 1997 09:36:48 -0700 (PDT) Received: from wlk.com (news.wlk.com [192.86.83.250]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id JAA19547 for ; Wed, 21 May 1997 09:36:42 -0700 (PDT) Received: from SMTPdaemon by wlk.com (smail3.2) with SMTPL id m0wUEMP-0009roC; Wed, 21 May 1997 11:35:33 -0500 (CDT) Received: from critter (localhost [127.0.0.1]) by critter.dk.tfs.com (8.8.5/8.8.5) with ESMTP id SAA02382; Wed, 21 May 1997 18:31:38 +0200 (CEST) To: Bruce Evans cc: jmg@hydrogen.nike.efn.org.dk.tfs.com, brett@lariat.org, HARDWARE@freebsd.org, rberndt@nething.com, WELCHDW@wofford.edu From: Poul-Henning Kamp Subject: Re: isa bus and boca multiport boards In-reply-to: Your message of "Wed, 21 May 1997 23:44:29 +1000." <199705211344.XAA26555@godzilla.zeta.org.au> Date: Wed, 21 May 1997 18:31:37 +0200 Message-ID: <2380.864232297@critter> Sender: owner-hardware@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In message <199705211344.XAA26555@godzilla.zeta.org.au>, Bruce Evans writes: >>so should I commit my changes that allow the sio to set 16550's to a >>trigger level of 8? and possibly make it more generic than it already >>is and allow people to define the resulting fifo level of the uart? > >I think it should default to "medium" (FIXO_RX_MEDH) if NSIO > 4 >and there should be ioctls to change both the receiver trigger >level and transmitter fifo size (NetBSD users recently reported >problems with external devices not being able to handle 16 bytes >of buffering in the transmitter, because CTS flow control doesn't >work for bytes that have been put in the tx fifo). The ioctls >should be supported by comcontrol(8). Indeed. -- Poul-Henning Kamp | phk@FreeBSD.ORG FreeBSD Core-team. http://www.freebsd.org/~phk | phk@login.dknet.dk Private mailbox. whois: [PHK] | phk@tfs.com TRW Financial Systems, Inc. Power and ignorance is a disgusting cocktail. From owner-freebsd-hardware Wed May 21 09:48:13 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id JAA20129 for hardware-outgoing; Wed, 21 May 1997 09:48:13 -0700 (PDT) Received: from clock (clock.wlk.com [192.86.83.254]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id JAA20115 for ; Wed, 21 May 1997 09:48:10 -0700 (PDT) Received: from SMTPdaemon by clock (smail3.2.0.93) with SMTPL id m0wUEYK-0008eZC; Wed, 21 May 1997 11:47:52 -0500 (CDT) Received: from critter (localhost [127.0.0.1]) by critter.dk.tfs.com (8.8.5/8.8.5) with ESMTP id SAA02411; Wed, 21 May 1997 18:34:14 +0200 (CEST) To: Brett Glass cc: Michael Smith , gurney_j@resnet.uoregon.edu, rberndt@nething.com, WELCHDW@wofford.edu, HARDWARE@freebsd.org From: Poul-Henning Kamp Subject: Re: isa bus and boca multiport boards In-reply-to: Your message of "Wed, 21 May 1997 07:59:40 MDT." <3.0.1.32.19970521075940.0075bc30@lariat.org> Date: Wed, 21 May 1997 18:34:13 +0200 Message-ID: <2409.864232453@critter> Sender: owner-hardware@freebsd.org X-Loop: FreeBSD.org Precedence: bulk You know Brett, you have now lambasted Bruce and Michael so much about the sio driver, that it's time for you to put your code where your mouth is. When do we see it ? -- Poul-Henning Kamp | phk@FreeBSD.ORG FreeBSD Core-team. http://www.freebsd.org/~phk | phk@login.dknet.dk Private mailbox. whois: [PHK] | phk@tfs.com TRW Financial Systems, Inc. Power and ignorance is a disgusting cocktail. From owner-freebsd-hardware Wed May 21 11:45:07 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id LAA27120 for hardware-outgoing; Wed, 21 May 1997 11:45:07 -0700 (PDT) Received: from pen1.pen.k12.va.us (pen1.pen.k12.va.us [141.104.22.202]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id LAA27107 for ; Wed, 21 May 1997 11:44:59 -0700 (PDT) Received: from beowulf by pen1.pen.k12.va.us (8.7.3/8.6.6) id NAA46077; Wed, 21 May 1997 13:48:14 -0400 Message-Id: <3.0.1.32.19970521134642.0068dd14@mail.vt.edu> X-Sender: bmcgloth@mail.vt.edu (Unverified) X-Mailer: Windows Eudora Light Version 3.0.1 (32) Date: Wed, 21 May 1997 13:46:42 -0400 To: freebsd-hardware@freebsd.org From: Brian McGlothlin Subject: unsubscribe Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-hardware@freebsd.org X-Loop: FreeBSD.org Precedence: bulk unsubscribe _/_/_/_/ _/_/_/_/_/ _/ _/ _/ _/ _/_/_/_/_/ _/_/_/_/ _/ _/ _/ _/ _/ _/ _/ _/ _/ _/ _/ _/ _/ _/ _/ _/ _/ _/ _/ _/ _/ _/ _/_/_/_/_/ _/_/ _/ _/ _/ _/ _/ _/ _/ _/_/ _/ _/ _/ _/ _/ _/ _/ _/ _/ _/ _/ _/ _/ _/ _/ _/ _/ _/ _/ _/ _/ _/ _/_/_/_/ _/_/_/_/_/ _/ _/ _/ _/_/_/_/_/_/ _/_/_/_/ From owner-freebsd-hardware Wed May 21 13:12:56 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id NAA02976 for hardware-outgoing; Wed, 21 May 1997 13:12:56 -0700 (PDT) Received: from shell1.aimnet.com (tbrinck@shell1.aimnet.com [204.247.0.210]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id NAA02966 for ; Wed, 21 May 1997 13:12:52 -0700 (PDT) Received: from localhost (tbrinck@localhost) by shell1.aimnet.com (8.8.5/SHELL) with SMTP id NAA28398 for ; Wed, 21 May 1997 13:12:46 -0700 (PDT) Date: Wed, 21 May 1997 13:12:45 -0700 (PDT) From: Toby Brinck To: freebsd-hardware@FreeBSD.ORG Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hardware@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk unsubscribe From owner-freebsd-hardware Wed May 21 14:54:14 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id OAA09024 for hardware-outgoing; Wed, 21 May 1997 14:54:14 -0700 (PDT) Received: from wall.jhs.no_domain (vector.muc.ditec.de [194.120.126.35]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id OAA08927; Wed, 21 May 1997 14:53:27 -0700 (PDT) Received: from desk.jhs.no_domain (localhost [127.0.0.1]) by desk.jhs.no_domain (8.8.5/8.8.5) with ESMTP id PAA04525; Tue, 20 May 1997 15:54:43 +0200 (MET DST) Message-Id: <199705201354.PAA04525@desk.jhs.no_domain> To: Stefan Esser cc: Sxren Schmidt , Chuck Robey , dave@persprog.com, jgrosch@sirius.com, randyk@ccsales.com, freebsd-hardware@freebsd.org Subject: Re: What Printer To Get - Postscript From: "Julian H. Stacey" Reply-To: "Julian H. Stacey" X-Email: jhs@freebsd.org, Fallback: jhs@gil.physik.rwth-aachen.de X-Web: http://www.freebsd.org/~jhs/ X-Company: Vector Systems Ltd, Unix & Internet Consultants. X-Address: Holz Strasse 27d, 80469 Munich, Germany X-Tel: Phone +49.89.268616, Fax +49.89.2608126, Data +49.89.26023276 X-Software: FreeBSD (Unix) + EXMH 1.6.9 (PGP key on web) In-reply-to: Your message of "Sat, 17 May 1997 11:38:56 +0200." <19970517113856.07573@x14.mi.uni-koeln.de> Date: Tue, 20 May 1997 15:54:43 +0200 Sender: owner-hardware@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi, Reference: > From: Stefan Esser > The problem is, that while the HP-PCL manuals I have (from nearly > ten year old HP printers) still apply, but in order to use the > high-reolution graphics modes, you need undocumented ESC sequences, > that appear to be common to the HP560C and newer printers. I have a thick manual "HP PCL 5 Printer Language Tech Ref Man" ordered it from my printer shop. it did not come with printer, cost extra though. cost me German DM 45 in Sept 1991 (currently ~ DM2.85 = 1 UK pound) HP Part No. 33459 - 90903 in case you want to order one. Julian -- Julian H. Stacey jhs@freebsd.org http://www.freebsd.org/~jhs/ From owner-freebsd-hardware Wed May 21 17:38:27 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id RAA18110 for hardware-outgoing; Wed, 21 May 1997 17:38:27 -0700 (PDT) Received: from george.lbl.gov (george-2.lbl.gov [131.243.2.12]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id RAA18104; Wed, 21 May 1997 17:38:26 -0700 (PDT) Received: (jin@localhost) by george.lbl.gov (8.6.10/8.6.5) id RAA14120; Wed, 21 May 1997 17:38:22 -0700 Date: Wed, 21 May 1997 17:38:22 -0700 From: "Jin Guojun[ITG]" Message-Id: <199705220038.RAA14120@george.lbl.gov> To: brian@mpress.com, bugs@freebsd.org Subject: Re: ASUS P/I-P65UP5 + C-P55T2D dual Pentium MB Cc: hardware@freebsd.org Sender: owner-hardware@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >> Has any one successfully installed FreeBSD on an ASUS P/I-P65UP5 dual Pentium >> motherboard with C-P55T2D (two 200 MHz Pentium CPU) daughter board? >> >> I had a memory problem on this motherboard. The same memory was used for >> ASUS P/I-P55TVP4 and TX97-E single Pentium 200 MHz CPU motherboards without >> any problem. They are 60 ns non-parity SIMM. >> However, the same hareware with just a different motherboard, the page fault >> occurred when system swithed to VM mode during the installation; that is, >> when installation passed all probing and switched to graphic installation >> menu. >> Does this imply I have a defective motherboard? or are some special >> setup required for VM start up? >> More info., this motherboard does not work for other UN*X system either. > >I'm running a P65UP5 and I think the same CPU card, ok with >FreeBSD in SMP mode. It was not the motherboard's problem. It is the 2.2.2-RELEASE boot.flp bug. The problem is very strange: NCR-810 SCSI controller + 3-Quantum Fireball 3.2 GB disks causes page fault NCR-810 SCSI controller + 2-Quantum Fireball 3.2 GB disks works OK. After installation, put 3-Quantum Fireball 3.2 GB disks back on the SCSI bus, no more page fault. Also, the 2.2.2-RELEASE installation failed to set the hostname and all network info. (such as ifconfig_ed1, defaultrouter etc.) into the /etc/rc.conf. Another problem in the 2.2.2-RELEASE is that the YP (NIS) client is broken. I remember someone reported YP server is broken. So, it looks like entire YP is broken. Since I cannot make a 2.2.2 machine up, therefore, I use the regular email instead of send-pr to report all problems at this time. Thanks, -Jin From owner-freebsd-hardware Wed May 21 18:20:20 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id SAA20318 for hardware-outgoing; Wed, 21 May 1997 18:20:20 -0700 (PDT) Received: from lariat.lariat.org (ppp0.lariat.org@[129.72.251.2]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id SAA20313; Wed, 21 May 1997 18:20:16 -0700 (PDT) Received: from solo.lariat.org ([129.72.251.10]) by lariat.lariat.org (8.8.5/8.8.5) with SMTP id TAA22640; Wed, 21 May 1997 19:19:46 -0600 (MDT) Message-Id: <3.0.1.32.19970521192048.0070172c@lariat.org> X-Sender: brett@lariat.org X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Wed, 21 May 1997 19:20:48 -0600 To: jin@george.lbl.gov, brian@mpress.com, bugs@FreeBSD.ORG From: Brett Glass Subject: Re: ASUS P/I-P65UP5 + C-P55T2D dual Pentium MB Cc: hardware@FreeBSD.ORG In-Reply-To: <8825649F.00048E3D.00@IWND1.infoworld.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-hardware@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk At 05:38 PM 5/21/97 -0600, jin@george.lbl.gov wrote: >Also, the 2.2.2-RELEASE installation failed to set the hostname and all >network info. (such as ifconfig_ed1, defaultrouter etc.) into the >/etc/rc.conf. This happened during my upgrade as well. I had to edit manually. Finally got everything running. Also had to put Apache into rc.local, since the apache_httpd option from /etc/sysconfig had no counterpart in rc.conf. I'm beginning to wonder if some of the instabilities I'm seeing are due to running binaries compiled under 2.1-R with 2.2.2-R. --Brett From owner-freebsd-hardware Wed May 21 21:16:31 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id VAA28840 for hardware-outgoing; Wed, 21 May 1997 21:16:31 -0700 (PDT) Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id VAA28831 for ; Wed, 21 May 1997 21:16:27 -0700 (PDT) Received: (from msmith@localhost) by genesis.atrad.adelaide.edu.au (8.8.5/8.7.3) id NAA17969; Thu, 22 May 1997 13:45:54 +0930 (CST) From: Michael Smith Message-Id: <199705220415.NAA17969@genesis.atrad.adelaide.edu.au> Subject: Re: isa bus and boca multiport boards In-Reply-To: <3.0.1.32.19970521074016.00736a68@lariat.org> from Brett Glass at "May 21, 97 07:40:16 am" To: brett@lariat.org (Brett Glass) Date: Thu, 22 May 1997 13:45:53 +0930 (CST) Cc: msmith@atrad.adelaide.edu.au, rberndt@nething.com, WELCHDW@wofford.edu, HARDWARE@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-hardware@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Brett Glass stands accused of saying: > At 01:34 PM 5/21/97 +0930, Michael Smith wrote: > > >(cocks an ear listening for the ICBM leaving bde's desk). > > > >I don't think that would be a very popular idea; the sio driver should be > >more, not less, machine independant. > > It's already hopelessly machine-dependent, due to the nature of the quirky > UARTs and edge-triggered interrupts. The 16550 is by no means unique to the PC architecture, nor is polling for repeat business inside an interrupt handler. Neither of these features make the driver particularly machine-dependant. >I don't think there's much value in > trying to maintain machine independence in the inner loops, where the C > code is slowing things down. But even with C, many optimizations would be > possible, as described in my message. It would appear that not everyone, least of all the maintainer of the code in question, agrees with your sentiments here 8) > I've noticed a significant slowdown with the latest drivers, and would > really like the speed back! Can you link this percieved slowdown to any particular change(s)? The basic structure of the sio driver hasn't changed "recently". > --Brett -- ]] Mike Smith, Software Engineer msmith@gsoft.com.au [[ ]] Genesis Software genesis@gsoft.com.au [[ ]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[ ]] realtime instrument control. (ph) +61-8-8267-3493 [[ ]] Unix hardware collector. "Where are your PEZ?" The Tick [[ From owner-freebsd-hardware Wed May 21 21:21:33 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id VAA29068 for hardware-outgoing; Wed, 21 May 1997 21:21:33 -0700 (PDT) Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id VAA29055 for ; Wed, 21 May 1997 21:21:26 -0700 (PDT) Received: (from msmith@localhost) by genesis.atrad.adelaide.edu.au (8.8.5/8.7.3) id NAA18011; Thu, 22 May 1997 13:51:08 +0930 (CST) From: Michael Smith Message-Id: <199705220421.NAA18011@genesis.atrad.adelaide.edu.au> Subject: Re: isa bus and boca multiport boards In-Reply-To: <3.0.1.32.19970521075940.0075bc30@lariat.org> from Brett Glass at "May 21, 97 07:59:40 am" To: brett@lariat.org (Brett Glass) Date: Thu, 22 May 1997 13:51:08 +0930 (CST) Cc: msmith@atrad.adelaide.edu.au, gurney_j@resnet.uoregon.edu, rberndt@nething.com, WELCHDW@wofford.edu, HARDWARE@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-hardware@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Brett Glass stands accused of saying: > > >> 1) The code looks at a flag called "gone" on each and every port (present > >> or not) during each and every interrupt service. Since the presence or > >> absence of a port is determined at boot time > > > >This is not true. Please note where the "gone" flag is manipulated, and > >post a correction to your statement when you understand. > > OK, here's a correction: It's WORSE than that! The loop checks the pointer > "com" to see if it's null, and THEN checks "gone." Neither should be done at > interrupt time. The list of ports to scan should be built and maintained > outside the ISR. The state of the 'gone' flag may (possibly) change _during_the_execution_ of the ISR. > >It's not, actually, all that much. Scanning a port is a single I/O > >operation, taking around 1us. At 115200bps, it takes 86us for a > >single character to arrive. > > You're omitting overhead! With a check of a pointer, the check of the flag, > loading the port number, doing the I/O, loading the loop counter, and > executing a conditional branch, a scan of a port costs much more. As Bruce has already (correctly) observed, other CPU operations are lost in the noise when coupled with I/O operations. > Is there any other processor with the brain-dead architecture that brings > up all of these issues? The 16550A and edge-triggered interrupts are an > artifact of the IBM PC, circa 1981; the cascaded 8259's and their quirks > are a legacy of the PC/AT, circa 1984. the 8250 family UARTS, and macrocells compatible with them, are used on a staggering array of computing hardware. Look at the Alpha platforms that are a hot FreeBSD port target for example. As I have already noted, polling for work-to-do is an efficiency optimisation as well as a technique for avoiding the 8259's quirkiness. > I think that optimization of the ISRs, at the very least, is > justified, since this code will NEVER be re-used on other platforms. I have already used it on at least one other, non-Intel platform. > It's necessarily hardware-dependent. There IS hardware-independent > code that should remain portable, but this code can't be made > portable; might as well code it tightly and efficiently! It is hardware dependant. It is not, and should not be, processor dependant. > --Brett -- ]] Mike Smith, Software Engineer msmith@gsoft.com.au [[ ]] Genesis Software genesis@gsoft.com.au [[ ]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[ ]] realtime instrument control. (ph) +61-8-8267-3493 [[ ]] Unix hardware collector. "Where are your PEZ?" The Tick [[ From owner-freebsd-hardware Wed May 21 22:10:22 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id WAA01287 for hardware-outgoing; Wed, 21 May 1997 22:10:22 -0700 (PDT) Received: from lariat.lariat.org (ppp0.lariat.org@[129.72.251.2]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id WAA01281 for ; Wed, 21 May 1997 22:10:17 -0700 (PDT) Received: from solo.lariat.org ([129.72.251.10]) by lariat.lariat.org (8.8.5/8.8.5) with SMTP id XAA25245; Wed, 21 May 1997 23:09:24 -0600 (MDT) Message-Id: <3.0.1.32.19970521231026.006bae9c@lariat.org> X-Sender: brett@lariat.org X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Wed, 21 May 1997 23:10:26 -0600 To: Michael Smith From: Brett Glass Subject: Re: isa bus and boca multiport boards Cc: msmith@atrad.adelaide.edu.au, rberndt@nething.com, WELCHDW@wofford.edu, HARDWARE@FreeBSD.ORG In-Reply-To: <199705220415.NAA17969@genesis.atrad.adelaide.edu.au> References: <3.0.1.32.19970521074016.00736a68@lariat.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-hardware@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk At 01:45 PM 5/22/97 +0930, Michael Smith wrote: >Can you link this percieved slowdown to any particular change(s)? The >basic structure of the sio driver hasn't changed "recently". Well, I haven't updated this machine since 2.1.0-R. And the old driver WAS much faster. As for what caused this: Would have to profile the code. (By the time I could do that, I could probably learn to write a "super sio" that was x86-specific.) --Brett From owner-freebsd-hardware Wed May 21 22:20:43 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id WAA01710 for hardware-outgoing; Wed, 21 May 1997 22:20:43 -0700 (PDT) Received: from lariat.lariat.org (ppp0.lariat.org@[129.72.251.2]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id WAA01705 for ; Wed, 21 May 1997 22:20:37 -0700 (PDT) Received: from solo.lariat.org ([129.72.251.10]) by lariat.lariat.org (8.8.5/8.8.5) with SMTP id XAA25347; Wed, 21 May 1997 23:18:47 -0600 (MDT) Message-Id: <3.0.1.32.19970521231927.006a1a5c@lariat.org> X-Sender: brett@lariat.org X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Wed, 21 May 1997 23:19:27 -0600 To: Michael Smith From: Brett Glass Subject: Re: isa bus and boca multiport boards Cc: msmith@atrad.adelaide.edu.au, gurney_j@resnet.uoregon.edu, rberndt@nething.com, WELCHDW@wofford.edu, HARDWARE@FreeBSD.ORG In-Reply-To: <199705220421.NAA18011@genesis.atrad.adelaide.edu.au> References: <3.0.1.32.19970521075940.0075bc30@lariat.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-hardware@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk At 01:51 PM 5/22/97 +0930, Michael Smith wrote: >The state of the 'gone' flag may (possibly) change >_during_the_execution_ of the ISR. If so, it sounds as if there might be major synchronization and reentrancy problems. Not to mention logic glitches if the port goes away at the wrong moment. >> You're omitting overhead! With a check of a pointer, the check of the flag, >> loading the port number, doing the I/O, loading the loop counter, and >> executing a conditional branch, a scan of a port costs much more. > >As Bruce has already (correctly) observed, other CPU operations are >lost in the noise when coupled with I/O operations. The extra code that's executed includes lots of BOTH. >the 8250 family UARTS, and macrocells compatible with them, are used >on a staggering array of computing hardware. Look at the Alpha >platforms that are a hot FreeBSD port target for example. In which case, they can stick with the C version -- or, if they need performance, do a tuned ASM version for that processor. --Brett From owner-freebsd-hardware Wed May 21 23:13:06 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id XAA03736 for hardware-outgoing; Wed, 21 May 1997 23:13:06 -0700 (PDT) Received: from mail.webspan.net (mail.webspan.net [206.154.70.7]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id XAA03731 for ; Wed, 21 May 1997 23:13:03 -0700 (PDT) Received: from orion.webspan.net (orion.webspan.net [206.154.70.5]) by mail.webspan.net (WEBSPAN/970116) with ESMTP id CAA14644; Thu, 22 May 1997 02:12:17 -0400 (EDT) Received: from orion.webspan.net (localhost [127.0.0.1]) by orion.webspan.net (WEBSPN/970116) with ESMTP id CAA10602; Thu, 22 May 1997 02:12:17 -0400 (EDT) To: Brett Glass cc: HARDWARE@FreeBSD.ORG From: "Gary Palmer" Subject: Re: isa bus and boca multiport boards In-reply-to: Your message of "Wed, 21 May 1997 23:19:27 MDT." <3.0.1.32.19970521231927.006a1a5c@lariat.org> Date: Thu, 22 May 1997 02:12:16 -0400 Message-ID: <10600.864281536@orion.webspan.net> Sender: owner-hardware@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Brett Glass wrote in message ID <3.0.1.32.19970521231927.006a1a5c@lariat.org>: > >the 8250 family UARTS, and macrocells compatible with them, are used > >on a staggering array of computing hardware. Look at the Alpha > >platforms that are a hot FreeBSD port target for example. > In which case, they can stick with the C version -- or, if they need > performance, do a tuned ASM version for that processor. Please, no. I think the last thing a lot of people would want to see is 5 different versions of sio.S, one for each platform we (in the future) support. Generic drivers which are applicable to multiple platforms should stay as generic as possible. If that means sticking in C, so be it. Machine machine dependant versions just will cause hassle down the road. Example which is still fresh in peoples memories: Garrett's change to the networking code which broke some protocol families. All it takes is Bruce (for example) to do a re-write of part of the tty driver, and slightly change the interface presented, et voila, the build for multiple platforms falls over. I DO NOT expect developers to learn the assembler of every platform we support!! It's why so much of the kernel is in C when it could very easily be optimized into assembler. The advantages of keeping the code in C are clear. I, for one, do not want to see our move to multiple architecture support to a nightmare. Some common sense now about what can and cannot be done reasonably will save a lot of hassle later. Gary -- Gary Palmer FreeBSD Core Team Member FreeBSD: Turning PC's into workstations. See http://www.FreeBSD.ORG/ for info From owner-freebsd-hardware Wed May 21 23:31:29 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id XAA04580 for hardware-outgoing; Wed, 21 May 1997 23:31:29 -0700 (PDT) Received: from hydrogen.nike.efn.org (metriclient-2.uoregon.edu [128.223.172.2]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id XAA04573 for ; Wed, 21 May 1997 23:31:23 -0700 (PDT) Received: (from jmg@localhost) by hydrogen.nike.efn.org (8.8.5/8.8.5) id XAA00170; Wed, 21 May 1997 23:32:48 -0700 (PDT) Message-ID: <19970521233248.63497@hydrogen.nike.efn.org> Date: Wed, 21 May 1997 23:32:48 -0700 From: John-Mark Gurney To: Brett Glass Cc: Michael Smith , HARDWARE@FreeBSD.ORG Subject: Re: isa bus and boca multiport boards References: <3.0.1.32.19970521075940.0075bc30@lariat.org> <3.0.1.32.19970521231927.006a1a5c@lariat.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.69 In-Reply-To: <3.0.1.32.19970521231927.006a1a5c@lariat.org>; from Brett Glass on Wed, May 21, 1997 at 11:19:27PM -0600 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-hardware@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Brett Glass scribbled this message on May 21: > At 01:51 PM 5/22/97 +0930, Michael Smith wrote: > >the 8250 family UARTS, and macrocells compatible with them, are used > >on a staggering array of computing hardware. Look at the Alpha > >platforms that are a hot FreeBSD port target for example. > > In which case, they can stick with the C version -- or, if they need > performance, do a tuned ASM version for that processor. so... are you proposing to maintain the assembly sio driver for the rest of time? and include ANY C modifications that happen in to the new driver?? and provide the ability for selection of the C version so they can have a functioning driver? just so every one know... I've started working on the sio... and will be adding Bruce's/Poul-Henning's idea of using a ioctl to set the Tx/Rx FIFO trigger level.. I've already implemented the ring check, but I haven't tested it... but that improvement won't be as important once I get it so it only checks ports that are assigned to that irq.. I've also started working on supporting the IVR that 4port AST's and other cards provide... but as usual, free time is always scarce... ttyl.. -- John-Mark Cu Networking Modem/FAX: +1 541 683 6954 Live in Peace, destroy Micro$oft, support free software, run FreeBSD From owner-freebsd-hardware Wed May 21 23:38:26 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id XAA04960 for hardware-outgoing; Wed, 21 May 1997 23:38:26 -0700 (PDT) Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id XAA04951 for ; Wed, 21 May 1997 23:38:22 -0700 (PDT) Received: (from msmith@localhost) by genesis.atrad.adelaide.edu.au (8.8.5/8.7.3) id QAA19080; Thu, 22 May 1997 16:07:52 +0930 (CST) From: Michael Smith Message-Id: <199705220637.QAA19080@genesis.atrad.adelaide.edu.au> Subject: Re: isa bus and boca multiport boards In-Reply-To: <3.0.1.32.19970521231927.006a1a5c@lariat.org> from Brett Glass at "May 21, 97 11:19:27 pm" To: brett@lariat.org (Brett Glass) Date: Thu, 22 May 1997 16:07:52 +0930 (CST) Cc: msmith@atrad.adelaide.edu.au, gurney_j@resnet.uoregon.edu, rberndt@nething.com, WELCHDW@wofford.edu, HARDWARE@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-hardware@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Brett Glass stands accused of saying: > At 01:51 PM 5/22/97 +0930, Michael Smith wrote: > > >The state of the 'gone' flag may (possibly) change > >_during_the_execution_ of the ISR. > > If so, it sounds as if there might be major synchronization and reentrancy > problems. Not to mention logic glitches if the port goes away at the wrong > moment. Heh. Welcome to PCMCIA. TBH, I suspect that it's unlikely that the card is going to be flagged as gone during the interrupt handler, but it's impossible to tell that it's gone until after it already has. > >the 8250 family UARTS, and macrocells compatible with them, are used > >on a staggering array of computing hardware. Look at the Alpha > >platforms that are a hot FreeBSD port target for example. > > In which case, they can stick with the C version -- or, if they need > performance, do a tuned ASM version for that processor. ... or use a C version that just happens to be highly optimised. It just occurred to me that the author of the BNU FOSSIL driver is probably reading this. David, would you care to comment on the 'sio' driver, or do you know Bruce too well? -- ]] Mike Smith, Software Engineer msmith@gsoft.com.au [[ ]] Genesis Software genesis@gsoft.com.au [[ ]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[ ]] realtime instrument control. (ph) +61-8-8267-3493 [[ ]] Unix hardware collector. "Where are your PEZ?" The Tick [[ From owner-freebsd-hardware Wed May 21 23:39:28 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id XAA05011 for hardware-outgoing; Wed, 21 May 1997 23:39:28 -0700 (PDT) Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id XAA05005 for ; Wed, 21 May 1997 23:39:23 -0700 (PDT) Received: (from msmith@localhost) by genesis.atrad.adelaide.edu.au (8.8.5/8.7.3) id QAA19095; Thu, 22 May 1997 16:09:08 +0930 (CST) From: Michael Smith Message-Id: <199705220639.QAA19095@genesis.atrad.adelaide.edu.au> Subject: Re: isa bus and boca multiport boards In-Reply-To: <3.0.1.32.19970521231026.006bae9c@lariat.org> from Brett Glass at "May 21, 97 11:10:26 pm" To: brett@lariat.org (Brett Glass) Date: Thu, 22 May 1997 16:09:07 +0930 (CST) Cc: msmith@atrad.adelaide.edu.au, rberndt@nething.com, WELCHDW@wofford.edu, HARDWARE@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-hardware@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Brett Glass stands accused of saying: > At 01:45 PM 5/22/97 +0930, Michael Smith wrote: > > >Can you link this percieved slowdown to any particular change(s)? The > >basic structure of the sio driver hasn't changed "recently". > > Well, I haven't updated this machine since 2.1.0-R. And the old driver WAS > much faster. As for what caused this: Would have to profile the code. (By > the time I could do that, I could probably learn to write a "super sio" > that was x86-specific.) Well, how about "can you quantify this 'slowdown'"? I sure as damn don't see it. > --Brett -- ]] Mike Smith, Software Engineer msmith@gsoft.com.au [[ ]] Genesis Software genesis@gsoft.com.au [[ ]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[ ]] realtime instrument control. (ph) +61-8-8267-3493 [[ ]] Unix hardware collector. "Where are your PEZ?" The Tick [[ From owner-freebsd-hardware Thu May 22 00:13:32 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id AAA06443 for hardware-outgoing; Thu, 22 May 1997 00:13:32 -0700 (PDT) Received: from tfs.com (tfs.com [140.145.250.1]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id AAA06436 for ; Thu, 22 May 1997 00:13:29 -0700 (PDT) Received: from critter.dk.tfs.com by tfs.com (smail3.1.28.1) with SMTP id m0wUS2u-0003vyC; Thu, 22 May 97 00:12 PDT Received: from critter (localhost [127.0.0.1]) by critter.dk.tfs.com (8.8.5/8.8.5) with ESMTP id JAA00236; Thu, 22 May 1997 09:10:45 +0200 (CEST) To: Brett Glass cc: Michael Smith , gurney_j@resnet.uoregon.edu, rberndt@nething.com, WELCHDW@wofford.edu, HARDWARE@freebsd.org From: Poul-Henning Kamp Subject: Re: isa bus and boca multiport boards In-reply-to: Your message of "Wed, 21 May 1997 23:19:27 MDT." <3.0.1.32.19970521231927.006a1a5c@lariat.org> Date: Thu, 22 May 1997 09:10:45 +0200 Message-ID: <234.864285045@critter> Sender: owner-hardware@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In message <3.0.1.32.19970521231927.006a1a5c@lariat.org>, Brett Glass writes: >At 01:51 PM 5/22/97 +0930, Michael Smith wrote: > >>The state of the 'gone' flag may (possibly) change >>_during_the_execution_ of the ISR. > >If so, it sounds as if there might be major synchronization and reentrancy >problems. Not to mention logic glitches if the port goes away at the wrong >moment. There is. PCMCIA >REALLY< botched this one. At least they could have made sure that you got a defined value back if you read from a port that has recently gone AWOL, but no, gone with the wind and fair wind! :-( -- Poul-Henning Kamp | phk@FreeBSD.ORG FreeBSD Core-team. http://www.freebsd.org/~phk | phk@login.dknet.dk Private mailbox. whois: [PHK] | phk@tfs.com TRW Financial Systems, Inc. Power and ignorance is a disgusting cocktail. From owner-freebsd-hardware Thu May 22 14:31:00 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id OAA07479 for hardware-outgoing; Thu, 22 May 1997 14:31:00 -0700 (PDT) Received: from mexico.brainstorm.eu.org (root@mexico.brainstorm.fr [193.56.58.253]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id OAA07460 for ; Thu, 22 May 1997 14:30:49 -0700 (PDT) Received: from brasil.brainstorm.eu.org (brasil.brainstorm.fr [193.56.58.33]) by mexico.brainstorm.eu.org (8.8.4/8.8.4) with ESMTP id XAA01310 for ; Thu, 22 May 1997 23:30:38 +0200 Received: (from uucp@localhost) by brasil.brainstorm.eu.org (8.8.4/8.6.12) with UUCP id XAA02329 for hardware@FreeBSD.ORG; Thu, 22 May 1997 23:30:21 +0200 Received: (from roberto@localhost) by keltia.freenix.fr (8.8.5/keltia-uucp-2.9) id UAA17368; Thu, 22 May 1997 20:39:05 +0200 (CEST) Message-ID: <19970522203905.13702@keltia.freenix.fr> Date: Thu, 22 May 1997 20:39:05 +0200 From: Ollivier Robert To: hardware@FreeBSD.ORG Subject: Re: Intel Pentium II released References: <199705130853.BAA13157@admin3.calweb.com> <199705140107.SAA00204@hub.freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.67 In-Reply-To: <199705140107.SAA00204@hub.freebsd.org>; from Jonathan M. Bresler on Tue, May 13, 1997 at 06:07:47PM -0700 X-Operating-System: FreeBSD 3.0-CURRENT ctm#3283 Sender: owner-hardware@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk According to Jonathan M. Bresler: > Cameron Slye wrote: > > I am doing the make world thing of course... My last make world tests were > > on a K6 166, In the end, with it overclocked to 200mhz, it was about 8min > > slower then the p6-200. (I did not at the time have enought ram, 32mb and How is that K6-166 overclocked ? 3x 66 MHz or 2.5x 83 MHz ? I've been trying to push my own K6-166 at the latter but I can't complete the booting process. It stops very early... Many times the BIOS doesn't detect the K6 at all. -- Ollivier ROBERT -=- FreeBSD: There are no limits -=- roberto@keltia.freenix.fr FreeBSD keltia.freenix.fr 3.0-CURRENT #9: Thu May 8 20:22:51 CEST 1997 From owner-freebsd-hardware Thu May 22 15:23:56 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id PAA12444 for hardware-outgoing; Thu, 22 May 1997 15:23:56 -0700 (PDT) Received: from agora.rdrop.com (root@agora.rdrop.com [199.2.210.241]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id PAA12427 for ; Thu, 22 May 1997 15:23:52 -0700 (PDT) Received: from george.lbl.gov (george-2.lbl.gov [131.243.2.12]) by agora.rdrop.com (8.8.5/8.8.5) with SMTP id OAA12086 for ; Thu, 22 May 1997 14:54:27 -0700 (PDT) Received: (jin@localhost) by george.lbl.gov (8.6.10/8.6.5) id OAA10849; Thu, 22 May 1997 14:54:16 -0700 Date: Thu, 22 May 1997 14:54:16 -0700 From: "Jin Guojun[ITG]" Message-Id: <199705222154.OAA10849@george.lbl.gov> To: hardware@freebsd.org, roberto@keltia.freenix.fr Subject: Re: Intel Pentium II released Sender: owner-hardware@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > Cameron Slye wrote: > > I am doing the make world thing of course... My last make world tests were > > on a K6 166, In the end, with it overclocked to 200mhz, it was about 8min > > slower then the p6-200. (I did not at the time have enought ram, 32mb and As I tested, K6-200 MHz CPU is equivalent to 300 MHz Pentium CPU in integer and about 180 MHz Pentium CPU in float instructions. This is because K6 has a 32-bit FPU and Pentium family has 64-bit FPU. -Jin P.S. 32 MB memory is enough for testing "make". I will post a completed performance test including FFT test around middle next month. From owner-freebsd-hardware Fri May 23 04:12:17 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id EAA14436 for hardware-outgoing; Fri, 23 May 1997 04:12:17 -0700 (PDT) Received: from whqvax.picker.com (whqvax.picker.com [144.54.1.1]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id EAA14431 for ; Fri, 23 May 1997 04:12:12 -0700 (PDT) Received: from ct.picker.com by whqvax.picker.com with SMTP; Fri, 23 May 1997 7:11:10 -0400 (EDT) Received: from elmer.ct.picker.com ([144.54.57.34]) by ct.picker.com (4.1/SMI-4.1) id AA12292; Fri, 23 May 97 07:11:08 EDT Received: by elmer.ct.picker.com (SMI-8.6/SMI-SVR4) id HAA02430; Fri, 23 May 1997 07:10:13 -0400 Message-Id: <19970523071013.61332@ct.picker.com> Date: Fri, 23 May 1997 07:10:13 -0400 From: Randall Hopper To: "Jin Guojun[ITG]" Cc: hardware@FreeBSD.ORG Subject: Re: Intel Pentium II released References: <199705222154.OAA10849@george.lbl.gov> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.74 In-Reply-To: <199705222154.OAA10849@george.lbl.gov>; from Jin Guojun[ITG] on Thu, May 22, 1997 at 02:54:16PM -0700 Sender: owner-hardware@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Jin Guojun[ITG]: |> Cameron Slye wrote: |> > I am doing the make world thing of course... My last make world tests were |> > on a K6 166, In the end, with it overclocked to 200mhz, it was about 8min |> > slower then the p6-200. (I did not at the time have enought ram, 32mb and | |As I tested, K6-200 MHz CPU is equivalent to 300 MHz Pentium CPU in integer |and about 180 MHz Pentium CPU in float instructions. This is because K6 has |a 32-bit FPU and Pentium family has 64-bit FPU. So am I infering correctly that you have a K6-200 working under FreeBSD? That's good to hear. I've had my eye on this chip. Randall Hopper From owner-freebsd-hardware Fri May 23 09:15:22 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id JAA28315 for hardware-outgoing; Fri, 23 May 1997 09:15:22 -0700 (PDT) Received: from cold.org (cold.org [206.81.134.103]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id JAA28310 for ; Fri, 23 May 1997 09:15:17 -0700 (PDT) Received: from localhost (brandon@localhost) by cold.org (8.8.5/8.8.3) with SMTP id KAA06881 for ; Fri, 23 May 1997 10:15:19 -0600 (MDT) Date: Fri, 23 May 1997 10:15:19 -0600 (MDT) From: Brandon Gillespie To: freebsd-hardware@freebsd.org Subject: Wang DAT SCSI drive woes Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hardware@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Sorry if this is a duplicate, mail was acting VERY oddly yesterday, and I never received a echo from the hardware list about this, so I'm sending it again... Has anybody ever wrestled with a Wang DAT SCSI drive? I just dropped one in my FreeBSD box. I have used Exabytes before, but never a Wang DAT. This one is on SCSI ID 6, and shows up in the boot probes as: aic0 at 0x340-0x35f irq 11 on isa aic0 waiting for scsi devices to settle (aic0:6:0): "WangDAT Model 2600 01.2" type 1 removable SCSI 2 st0(aic0:6:0): Sequential-Access density code 0x93, 512-byte blocks, write-enabled Now.. the controller is an old Adaptec 1524, I would think it is to fault, but it hasn't given me problems with any other SCSI devices, such as CD-ROMS, SCSI disks and Exabyte tape drives. I received the drive in interesting conditions. It had been in an AT&T 3B2 (yah, ancient, whee :) And I was told by a guy who knew the administrator of the 3b2 that ''it didnt work'' and neither of them knew why. When I looked at the drive I hope I found why: two of the scsi terminators were missing, out of the three racks of pins. At least, I hope this is why :) Fixing that problem, I also pushed the scsi1/2 dip-switch to scsi2. All of the available dip switches are as follow (also showing the state they were in when I found the drive) ID2 on obvious ID1 off obvious ID0 on obvious PE off OPT off SCSI2 off SCSI1/2 switch, I switched to SCSI2 CMPR off BS off I tried to find help at Wang's web site, but it sucks. Can anybody help? Or at the lease, help me decrypt what these dip-switches are for? -Brandon Gillespie From owner-freebsd-hardware Fri May 23 10:03:01 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id KAA01645 for hardware-outgoing; Fri, 23 May 1997 10:03:01 -0700 (PDT) Received: from george.lbl.gov (george-2.lbl.gov [131.243.2.12]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id KAA01640 for ; Fri, 23 May 1997 10:02:59 -0700 (PDT) Received: (jin@localhost) by george.lbl.gov (8.6.10/8.6.5) id KAA29056; Fri, 23 May 1997 10:02:59 -0700 Date: Fri, 23 May 1997 10:02:59 -0700 From: "Jin Guojun[ITG]" Message-Id: <199705231702.KAA29056@george.lbl.gov> To: rhh@ct.picker.com Subject: Re: Intel Pentium II released Cc: hardware@FreeBSD.ORG Sender: owner-hardware@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Randall Hopper stated: } Jin Guojun[ITG]: } |> Cameron Slye wrote: } |> > I am doing the make world thing of course... My last make world tests wer } e } |> > on a K6 166, In the end, with it overclocked to 200mhz, it was about 8min } |> > slower then the p6-200. (I did not at the time have enought ram, 32mb and } | } |As I tested, K6-200 MHz CPU is equivalent to 300 MHz Pentium CPU in integer } |and about 180 MHz Pentium CPU in float instructions. This is because K6 has } |a 32-bit FPU and Pentium family has 64-bit FPU. } } So am I infering correctly that you have a K6-200 working under FreeBSD? } } That's good to hear. I've had my eye on this chip. Yup, in talking to ADM engineers, they try to convince me that K6 is P6 like CPU, but can use socket-7 to run on a P5 motherboard. In the meantime, Intel engineers told me that TX PCI chipset (latest Triton family) fixed currency and memory speed conflict issue, and ASUS just made 97TX motherboard to support K6 CPU. They all happened at same time. Well, how to know things working without trying. It looks like that K6 is good for servers who do not use float instructions or do little float calaulation. Comparing the price and performance: single K6-200 system cost: (current pricing) CPU $430 + MB $155 = $585 => 300 MHz Pentium 1.95$ / MHz dual P55-200 system cost: CPU $300 x 2 + MB $225 = $825 => 380 MHz aggregate CPU power ? or two single P55 systems: CPU $300 x 2 + MB $155 x 2 = $910 => 400 MHz Pentium 2.275$ / MHz If you need more FPU power, then, Pentium-II is a better choice. Why not PPro? Most vendors are use 440FX PCI chipset which has currency with conflict memory issue. Unless you do not need memory bandwith, P6 is not a good choice. Also, Intel may not improve PCI chipset for P6 family in the further. If you tell chip maker to add $10 more on they chips, it drives them nuts. End user may NOT care you vendor add $20 on a good motherboard ($10 for chipset and $10 for profit), but $5 for chip maker is a big deal. The point is P6 will has a short life, and Pentium-II is the next one. Pentium-II improves many things and has AGP inline. This is my few cents, -Jin From owner-freebsd-hardware Fri May 23 11:24:45 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id LAA06363 for hardware-outgoing; Fri, 23 May 1997 11:24:45 -0700 (PDT) Received: from whqvax.picker.com (whqvax.picker.com [144.54.1.1]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id LAA06349 for ; Fri, 23 May 1997 11:24:39 -0700 (PDT) Received: from ct.picker.com by whqvax.picker.com with SMTP; Fri, 23 May 1997 14:23:38 -0400 (EDT) Received: from elmer.ct.picker.com ([144.54.57.34]) by ct.picker.com (4.1/SMI-4.1) id AA25643; Fri, 23 May 97 14:23:33 EDT Received: by elmer.ct.picker.com (SMI-8.6/SMI-SVR4) id OAA03362; Fri, 23 May 1997 14:22:35 -0400 Message-Id: <19970523142235.11747@ct.picker.com> Date: Fri, 23 May 1997 14:22:35 -0400 From: Randall Hopper To: "Jin Guojun[ITG]" Cc: hardware@FreeBSD.ORG Subject: Re: Intel Pentium II released References: <199705231702.KAA29056@george.lbl.gov> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.74 In-Reply-To: <199705231702.KAA29056@george.lbl.gov>; from Jin Guojun[ITG] on Fri, May 23, 1997 at 10:02:59AM -0700 Sender: owner-hardware@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Jin Guojun[ITG]: |Randall Hopper stated: |} So am I infering correctly that you have a K6-200 working under FreeBSD? |} That's good to hear. I've had my eye on this chip. | |Yup, in talking to ADM engineers, they try to convince me that K6 is P6 like |CPU, but can use socket-7 to run on a P5 motherboard. In the meantime, |Intel engineers told me that TX PCI chipset (latest Triton family) fixed |currency and memory speed conflict issue, and ASUS just made 97TX motherboard |to support K6 CPU. They all happened at same time. Well, how to know things |working without trying. I just picked up an ASUS P55T2P4 440HX MB, and have heard a number of reports of folks having good success running K6 on rev 3.0 & 3.1 of it (supplies the needed 3.1-3.3V). But before I even consider buying one, had to know it'd work on my preferred OS :-) ...Price still needs to come down a good bit more though; right now the P200MMX is looking better -- hopefully it also works well on FreeBSD. |and $10 for profit), but $5 for chip maker is a big deal. The point is P6 |will has a short life, and Pentium-II is the next one. Pentium-II |improves many things and has AGP inline. Could be. The big con to this setup that I've heard of (which I'll avoid as long as possible) is the proprietary CPU card interface. I'll vote for a solution that lends to more vendor competition given a choice. Thanks for the info, Randall From owner-freebsd-hardware Fri May 23 11:38:30 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id LAA07184 for hardware-outgoing; Fri, 23 May 1997 11:38:30 -0700 (PDT) Received: from lariat.lariat.org (ppp0.lariat.org@[129.72.251.2]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id LAA07164; Fri, 23 May 1997 11:38:19 -0700 (PDT) Received: from solo.lariat.org (ad25-189.compuserve.com [199.174.128.189]) by lariat.lariat.org (8.8.5/8.8.5) with SMTP id MAA17111; Fri, 23 May 1997 12:37:06 -0600 (MDT) Message-Id: <3.0.1.32.19970522181207.0072d920@lariat.org> X-Sender: brett@lariat.org X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Thu, 22 May 1997 18:12:07 -0600 To: Jim Shankland , gpalmer@FreeBSD.ORG From: Brett Glass Subject: Re: isa bus and boca multiport boards Cc: HARDWARE@FreeBSD.ORG In-Reply-To: <199705221647.JAA03333@biggusdiskus.flyingfox.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-hardware@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk At 09:47 AM 5/22/97 -0700, Jim Shankland wrote: >This "tuned asm" thing is perilously close to an urban myth, anyway. >To the extent there's any "lift" to be gotten from asm at all, it's >from tiny little pieces in performance-critical inner loops, Exactly. The guts of the sio driver ARE some performance-critical inner loops. >especially >if there's a hardware-specific instruction that the compiler won't >generate. I'd have to look at the generated code to see how well I/O is done. But I'd HOPE that the macros do the right thing. >It's one thing to say, "I've just spent 3 weeks of backbreaking labor >tuning the sio driver, and made it X% faster; then I experimented and >found that, by replacing the following N lines of C code with assembler, >I made it Y% faster still"; and another to wave one's hands about >a fast sio driver written in assembler. Given the costs in portability, >maintainability, and effort required for assembler, arguments for its >use must be supported by strong, empirical evidence of benefit. My experience on other OS platforms dictates that there IS a large measure of efficiency to be gained -- on the order of 25% time savings. The improvements are partly from ASM and partly from good algorithms. --Brett From owner-freebsd-hardware Fri May 23 12:01:54 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id MAA08808 for hardware-outgoing; Fri, 23 May 1997 12:01:54 -0700 (PDT) Received: from george.lbl.gov (george-2.lbl.gov [131.243.2.12]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id MAA08801 for ; Fri, 23 May 1997 12:01:49 -0700 (PDT) Received: (jin@localhost) by george.lbl.gov (8.6.10/8.6.5) id MAA02713; Fri, 23 May 1997 12:01:49 -0700 Date: Fri, 23 May 1997 12:01:49 -0700 From: "Jin Guojun[ITG]" Message-Id: <199705231901.MAA02713@george.lbl.gov> To: rhh@ct.picker.com Subject: Re: Intel Pentium II released Cc: hardware@FreeBSD.ORG Sender: owner-hardware@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > I just picked up an ASUS P55T2P4 440HX MB, and have heard a number of > reports of folks having good success running K6 on rev 3.0 & 3.1 of it > (supplies the needed 3.1-3.3V). But before I even consider buying one, had > to know it'd work on my preferred OS :-) Probably, you meant 430HX, which is one level before TX chip. It is smimilar to 430TX, except currency and a bit more of other features. It supposes to support K6. For me, I need some high performance servers, so for the same price, I have to get the better one. -Jin From owner-freebsd-hardware Fri May 23 12:48:08 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id MAA11662 for hardware-outgoing; Fri, 23 May 1997 12:48:08 -0700 (PDT) Received: from ficus.ripn.net (root@ficus.ripn.net [144.206.130.212]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id MAA11632 for ; Fri, 23 May 1997 12:47:50 -0700 (PDT) Received: from papa.faki-campus.mipt.ru (papa.faki-campus.mipt.ru [194.85.83.109]) by ficus.ripn.net (8.6.9/8.6.9) with SMTP id DAA12691 for ; Sat, 24 May 1997 03:02:47 +0400 Message-ID: <3385F49D.51E0@faki-campus-gw.mipt.ru> Date: Fri, 23 May 1997 23:48:45 +0400 From: "Victor G. Krivulets" Reply-To: kvg@faki-campus-gw.mipt.ru Organization: MIPT X-Mailer: Mozilla 3.01Gold (Win95; I) MIME-Version: 1.0 To: hardware@freebsd.org Subject: question? Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-hardware@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hello, Please, say me, does FreeBSD support Accton network card? (accton en1650) Thank you for advance, Victor Krivulets From owner-freebsd-hardware Fri May 23 13:03:21 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id NAA12283 for hardware-outgoing; Fri, 23 May 1997 13:03:21 -0700 (PDT) Received: from cold.org (cold.org [206.81.134.103]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id NAA12267 for ; Fri, 23 May 1997 13:03:17 -0700 (PDT) Received: from localhost (brandon@localhost) by cold.org (8.8.5/8.8.3) with SMTP id OAA07404 for ; Fri, 23 May 1997 14:03:21 -0600 (MDT) Date: Fri, 23 May 1997 14:03:21 -0600 (MDT) From: Brandon Gillespie To: freebsd-hardware@freebsd.org Subject: Adaptec 2910B Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hardware@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Is the Adaptec 2910B a 'decent' SCSI controller, or are there things I should be concerned about with it? I am basically trying to find a decent PCI scsi controller that will serve a CDROM and Scanner (right now I have a cheap Future Domain 8bit piece of crap card that causes problems with my sound system). -Brandon Gillespie From owner-freebsd-hardware Fri May 23 13:11:33 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id NAA12748 for hardware-outgoing; Fri, 23 May 1997 13:11:33 -0700 (PDT) Received: from cold.org (cold.org [206.81.134.103]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id NAA12742 for ; Fri, 23 May 1997 13:11:32 -0700 (PDT) Received: from localhost (brandon@localhost) by cold.org (8.8.5/8.8.3) with SMTP id OAA07429 for ; Fri, 23 May 1997 14:11:36 -0600 (MDT) Date: Fri, 23 May 1997 14:11:36 -0600 (MDT) From: Brandon Gillespie To: freebsd-hardware@freebsd.org Subject: Re: Wang DAT SCSI drive woes In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hardware@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I just noticed in the logs, when I try 'mt status', I get: st0(aic0:6:0): timed out What would this imply? From owner-freebsd-hardware Fri May 23 13:33:29 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id NAA13977 for hardware-outgoing; Fri, 23 May 1997 13:33:29 -0700 (PDT) Received: from whqvax.picker.com (whqvax.picker.com [144.54.1.1]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id NAA13965 for ; Fri, 23 May 1997 13:33:26 -0700 (PDT) Received: from ct.picker.com by whqvax.picker.com with SMTP; Fri, 23 May 1997 16:32:25 -0400 (EDT) Received: from elmer.ct.picker.com ([144.54.57.34]) by ct.picker.com (4.1/SMI-4.1) id AA29943; Fri, 23 May 97 16:32:22 EDT Received: by elmer.ct.picker.com (SMI-8.6/SMI-SVR4) id QAA03557; Fri, 23 May 1997 16:31:26 -0400 Message-Id: <19970523163125.38983@ct.picker.com> Date: Fri, 23 May 1997 16:31:25 -0400 From: Randall Hopper To: "Jin Guojun[ITG]" Cc: hardware@FreeBSD.ORG Subject: Re: Intel Pentium II released References: <199705231901.MAA02713@george.lbl.gov> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.74 In-Reply-To: <199705231901.MAA02713@george.lbl.gov>; from Jin Guojun[ITG] on Fri, May 23, 1997 at 12:01:49PM -0700 Sender: owner-hardware@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Jin Guojun[ITG]: |> I just picked up an ASUS P55T2P4 440HX MB, and have heard a number of | |Probably, you meant 430HX, which is one level before TX chip. It is smimilar Right--slip of the finger. Randall From owner-freebsd-hardware Fri May 23 14:18:58 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id OAA17006 for hardware-outgoing; Fri, 23 May 1997 14:18:58 -0700 (PDT) Received: from whqvax.picker.com (whqvax.picker.com [144.54.1.1]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id OAA17001 for ; Fri, 23 May 1997 14:18:56 -0700 (PDT) Received: from ct.picker.com by whqvax.picker.com with SMTP; Fri, 23 May 1997 17:18:26 -0400 (EDT) Received: from elmer.ct.picker.com ([144.54.57.34]) by ct.picker.com (4.1/SMI-4.1) id AA01254; Fri, 23 May 97 17:18:23 EDT Received: by elmer.ct.picker.com (SMI-8.6/SMI-SVR4) id RAA03717; Fri, 23 May 1997 17:17:28 -0400 Message-Id: <19970523171728.63586@ct.picker.com> Date: Fri, 23 May 1997 17:17:28 -0400 From: Randall Hopper To: hardware@freebsd.org Subject: Re: Intel Pentium II released References: <199705231702.KAA29056@george.lbl.gov> <19970523142235.11747@ct.picker.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.74 In-Reply-To: <19970523142235.11747@ct.picker.com>; from Randall Hopper on Fri, May 23, 1997 at 02:22:35PM -0400 Sender: owner-hardware@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Randall Hopper: |I just picked up an ASUS P55T2P4 440HX MB, and have heard a number of |reports of folks having good success running K6 on rev 3.0 & 3.1 of it |(supplies the needed 3.1-3.3V). But before I even consider buying one, had ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Sorry, brain lapse. This is only relevent to the K6-233, which I've also had my eye on. K6-200 is "officially" supported by this MB, while the K6-233 is not, but works. Randall From owner-freebsd-hardware Fri May 23 14:22:41 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id OAA17315 for hardware-outgoing; Fri, 23 May 1997 14:22:41 -0700 (PDT) Received: from ns.tar.com (ns.tar.com [204.95.187.2]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id OAA17309 for ; Fri, 23 May 1997 14:22:38 -0700 (PDT) Received: from ppro.tar.com (ppro.tar.com [204.95.187.9]) by ns.tar.com (8.8.5/8.8.5) with SMTP id QAA04993; Fri, 23 May 1997 16:22:18 -0500 (CDT) Message-Id: <199705232122.QAA04993@ns.tar.com> From: "Richard Seaman, Jr." To: "Jin Guojun[ITG]" Cc: "hardware@FreeBSD.ORG" Date: Fri, 23 May 97 16:22:18 -0500 Reply-To: "Richard Seaman, Jr." Priority: Normal X-Mailer: PMMail 1.91 For OS/2 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: Re: Intel Pentium II released Sender: owner-hardware@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Fri, 23 May 1997 12:01:49 -0700, Jin Guojun[ITG] wrote: >Probably, you meant 430HX, which is one level before TX chip. It is smimilar >to 430TX, except currency and a bit more of other features. It supposes to >support K6. For me, I need some high performance servers, so for the same >price, I have to get the better one. One disadvantage to the TX chip is that it only does L2 caching of the first 64MB of RAM. If you have servers with large RAM levels (above 64MB) you might not get the performance you expect. The 430HX can cache up to 512MB. From owner-freebsd-hardware Fri May 23 14:30:54 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id OAA17707 for hardware-outgoing; Fri, 23 May 1997 14:30:54 -0700 (PDT) Received: from vader.cs.berkeley.edu (vader.CS.Berkeley.EDU [128.32.38.234]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id OAA17679 for ; Fri, 23 May 1997 14:30:42 -0700 (PDT) Received: (from asami@localhost) by vader.cs.berkeley.edu (8.8.5/8.7.3) id OAA02725; Fri, 23 May 1997 14:30:41 -0700 (PDT) Date: Fri, 23 May 1997 14:30:41 -0700 (PDT) Message-Id: <199705232130.OAA02725@vader.cs.berkeley.edu> To: jin@george.lbl.gov CC: rhh@ct.picker.com, hardware@freebsd.org In-reply-to: <199705231702.KAA29056@george.lbl.gov> (jin@george.lbl.gov) Subject: Re: Intel Pentium II released From: asami@vader.cs.berkeley.edu (Satoshi Asami) Sender: owner-hardware@freebsd.org X-Loop: FreeBSD.org Precedence: bulk * If you need more FPU power, then, Pentium-II is a better choice. Why not PPro? * Most vendors are use 440FX PCI chipset which has currency with conflict memory * issue. Unless you do not need memory bandwith, P6 is not a good choice. You are probably right about 440FX, but the only Pentium-II boards out there (as far as I know) still use 400FX. In which case, P6 will run faster than a PII with the same clock rate on most applications (the on-chip L2 does the trick). I'd really like to see how much faster the P6 will be for tight-loop applications (i.e., 90% of time is spent inside loop that fits (text + data) in 256K cache). Of course, I run my P6-200 at 233MHz, of course you can run your PII-233 at 266MHz, but the price/performance ratio still favors the P6. By the way, has anyone tried to overclock the PII? * Also, * Intel may not improve PCI chipset for P6 family in the further. If you tell Intel wants to drop the P6 line (right now if they can) as far as I can tell. They were never able to trim the cost, as the second die (L2 cache) had to be bonded with the main processor die before being tested (and both had to be thrown away if one of the two didn't work). That effectively doubled the failure rate, in other words, separating the chip into two dies didn't help much (the failure rate wouldn't be much different if they just made it one big die). However, the PII (Klamath) is not a replacement for P6, it is a replacement for P5. Their next chip (codenamed "Deschutes") is going to be the next-generation P6. So I guess the P6 will have at least another year or so of useful life. (1/2 ;) Satoshi P.S. By the way, nobody has sent me the results of: dd if=/dev/zero of=/dev/null bs=64k count=16000 dd if=/dev/zero of=/dev/null bs=1m count=1000 I'm interested in K6 and PII only. The FreeBSD memory speed SIG (that's Bruce and I) eagerly await your input. :) From owner-freebsd-hardware Fri May 23 17:46:06 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id RAA27262 for hardware-outgoing; Fri, 23 May 1997 17:46:06 -0700 (PDT) Received: from panda.hilink.com.au (panda.hilink.com.au [203.2.144.5]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id RAA27256 for ; Fri, 23 May 1997 17:46:03 -0700 (PDT) Received: (from danny@localhost) by panda.hilink.com.au (8.8.5/8.8.5) id KAA08601; Sat, 24 May 1997 10:45:49 +1000 (EST) Date: Sat, 24 May 1997 10:45:48 +1000 (EST) From: "Daniel O'Callaghan" To: "Richard Seaman, Jr." cc: "Jin Guojun[ITG]" , "hardware@FreeBSD.ORG" Subject: Re: Intel Pentium II released In-Reply-To: <199705232122.QAA04993@ns.tar.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hardware@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Fri, 23 May 1997, Richard Seaman, Jr. wrote: > On Fri, 23 May 1997 12:01:49 -0700, Jin Guojun[ITG] wrote: > > >Probably, you meant 430HX, which is one level before TX chip. It is smimilar > >to 430TX, except currency and a bit more of other features. It supposes to > >support K6. For me, I need some high performance servers, so for the same > >price, I have to get the better one. > > One disadvantage to the TX chip is that it only does L2 caching of the > first 64MB of RAM. If you have servers with large RAM levels (above 64MB) > you might not get the performance you expect. The 430HX can cache up to > 512MB. Can anyone please point me to a web page which describes all of these nuances in the the motherboard chipsets. I've looked on www.intel.com to no avail. Thanks, Danny From owner-freebsd-hardware Fri May 23 17:50:31 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id RAA27509 for hardware-outgoing; Fri, 23 May 1997 17:50:31 -0700 (PDT) Received: from gw1.asacomputers.com (root@gw1.asacomputers.com [204.69.220.10]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id RAA27504 for ; Fri, 23 May 1997 17:50:29 -0700 (PDT) Received: by gw1.asacomputers.com id OAA05470; Fri, 23 May 1997 14:50:43 -0700 (PDT) Message-Id: <2.2.32.19970524010118.008fbe84@gw1> X-Sender: rajadnya@gw1 X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 23 May 1997 18:01:18 -0700 To: asami@vader.cs.berkeley.edu (Satoshi Asami) From: Kedar Subject: Re: Intel Pentium II released Cc: freebsd-hardware@freebsd.org Sender: owner-hardware@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > dd if=/dev/zero of=/dev/null bs=1m count=1000 104837600 bytes/sec > dd if=/dev/zero of=/dev/null bs=128k count=8000 about twice that (I forgot to note it, and am running late). I know I changed your parameters for the L2. Worked off your earlier mail. Config: PII233, Intel board, 32mb EDO. Hope that helps. Have a good weekend, all. :) Kedar. From owner-freebsd-hardware Fri May 23 18:08:28 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id SAA28169 for hardware-outgoing; Fri, 23 May 1997 18:08:28 -0700 (PDT) Received: from gw1.asacomputers.com (root@gw1.asacomputers.com [204.69.220.10]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id SAA28163 for ; Fri, 23 May 1997 18:08:26 -0700 (PDT) Received: by gw1.asacomputers.com id PAA05563; Fri, 23 May 1997 15:09:02 -0700 (PDT) Message-Id: <2.2.32.19970524011937.006ee3d0@gw1> X-Sender: rajadnya@gw1 X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 23 May 1997 18:19:37 -0700 To: "Daniel O'Callaghan" From: Kedar Subject: Re: Intel Pentium II released Cc: freebsd-hardware@freebsd.org Sender: owner-hardware@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >Can anyone please point me to a web page which describes all of these >nuances in the the motherboard chipsets. I've looked on www.intel.com to >no avail. This site is pretty decent: http://sysdoc.pair.com/chipset.html The info is quite detailed here too, is it not?: http://developer.intel.com/design/pcisets/ Good luck, Kedar. From owner-freebsd-hardware Fri May 23 18:10:04 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id SAA28257 for hardware-outgoing; Fri, 23 May 1997 18:10:04 -0700 (PDT) Received: from Ilsa.StevesCafe.com (Ilsa.StevesCafe.com [205.168.119.129]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id SAA28223 for ; Fri, 23 May 1997 18:09:52 -0700 (PDT) Received: from Ilsa.StevesCafe.com (localhost [127.0.0.1]) by Ilsa.StevesCafe.com (8.8.5/8.8.5) with ESMTP id TAA18811; Fri, 23 May 1997 19:09:41 -0600 (MDT) Message-Id: <199705240109.TAA18811@Ilsa.StevesCafe.com> X-Mailer: exmh version 2.0gamma 1/27/96 From: Steve Passe To: "Daniel O'Callaghan" cc: "hardware@FreeBSD.ORG" Subject: Re: Intel Pentium II released In-reply-to: Your message of "Sat, 24 May 1997 10:45:48 +1000." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 23 May 1997 19:09:40 -0600 Sender: owner-hardware@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hi, > > Can anyone please point me to a web page which describes all of these > nuances in the the motherboard chipsets. I've looked on www.intel.com to > no avail. http://sysdoc.pair.com/ -- Steve Passe | powered by smp@csn.net | Symmetric MultiProcessor FreeBSD From owner-freebsd-hardware Fri May 23 18:12:41 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id SAA28368 for hardware-outgoing; Fri, 23 May 1997 18:12:41 -0700 (PDT) Received: from vader.cs.berkeley.edu (vader.CS.Berkeley.EDU [128.32.38.234]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id SAA28362 for ; Fri, 23 May 1997 18:12:39 -0700 (PDT) Received: (from asami@localhost) by vader.cs.berkeley.edu (8.8.5/8.7.3) id SAA03988; Fri, 23 May 1997 18:12:37 -0700 (PDT) Date: Fri, 23 May 1997 18:12:37 -0700 (PDT) Message-Id: <199705240112.SAA03988@vader.cs.berkeley.edu> To: kedar@asacomputers.com CC: freebsd-hardware@freebsd.org In-reply-to: <2.2.32.19970524010118.008fbe84@gw1> (message from Kedar on Fri, 23 May 1997 18:01:18 -0700) Subject: Re: Intel Pentium II released From: asami@vader.cs.berkeley.edu (Satoshi Asami) Sender: owner-hardware@freebsd.org X-Loop: FreeBSD.org Precedence: bulk * 104837600 bytes/sec * about twice that (I forgot to note it, and am running late). I know That is about what I heard from another person, too. * I changed your parameters for the L2. Worked off your earlier mail. * Config: PII233, Intel board, 32mb EDO. That's ok, it doesn't make much difference. (At least on my machine.) By the way, on my P6-233, they are about 350MB/s and 85MB/s. Satoshi From owner-freebsd-hardware Fri May 23 18:25:14 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id SAA28908 for hardware-outgoing; Fri, 23 May 1997 18:25:14 -0700 (PDT) Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id SAA28902 for ; Fri, 23 May 1997 18:25:10 -0700 (PDT) Received: (from msmith@localhost) by genesis.atrad.adelaide.edu.au (8.8.5/8.7.3) id KAA03614; Sat, 24 May 1997 10:55:04 +0930 (CST) From: Michael Smith Message-Id: <199705240125.KAA03614@genesis.atrad.adelaide.edu.au> Subject: Re: Adaptec 2910B In-Reply-To: from Brandon Gillespie at "May 23, 97 02:03:21 pm" To: brandon@cold.org (Brandon Gillespie) Date: Sat, 24 May 1997 10:55:03 +0930 (CST) Cc: freebsd-hardware@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-hardware@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Brandon Gillespie stands accused of saying: > Is the Adaptec 2910B a 'decent' SCSI controller, or are there things I > should be concerned about with it? I am basically trying to find a decent > PCI scsi controller that will serve a CDROM and Scanner (right now I have > a cheap Future Domain 8bit piece of crap card that causes problems with > my sound system). No. Get an NCR-based controller; you should be able to get a cheapie for about the same money, or less, than the Adaptec. > -Brandon Gillespie -- ]] Mike Smith, Software Engineer msmith@gsoft.com.au [[ ]] Genesis Software genesis@gsoft.com.au [[ ]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[ ]] realtime instrument control. (ph) +61-8-8267-3493 [[ ]] Unix hardware collector. "Where are your PEZ?" The Tick [[ From owner-freebsd-hardware Fri May 23 20:00:31 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id UAA02185 for hardware-outgoing; Fri, 23 May 1997 20:00:31 -0700 (PDT) Received: from crh.cl.msu.edu (crh.cl.msu.edu [35.8.1.24]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id UAA02177 for ; Fri, 23 May 1997 20:00:27 -0700 (PDT) Received: (from henrich@localhost) by crh.cl.msu.edu (8.8.5/8.8.5) id XAA06606; Fri, 23 May 1997 23:00:22 -0400 (EDT) Message-ID: <19970523230021.34111@crh.cl.msu.edu> Date: Fri, 23 May 1997 23:00:21 -0400 From: Charles Henrich To: freebsd-hardware@freebsd.org Subject: P-II/266 vs. PPro/233 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.74 X-Operating-System: FreeBSD 2.2-970422-RELENG Sender: owner-hardware@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Okay, I reran the DD tests: dd if=/dev/zero of=/dev/null bs=128k count=8000 dd if=/dev/zero of=/dev/null bs=1m count=1000 128k 1m RC5 GENERIC P-II/266 231M 106M 396K 3.8min PPro/233 340M 87M 448K -Crh Charles Henrich Michigan State University henrich@msu.edu http://pilot.msu.edu/~henrich From owner-freebsd-hardware Sat May 24 00:33:55 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id AAA11847 for hardware-outgoing; Sat, 24 May 1997 00:33:55 -0700 (PDT) Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id AAA11842 for ; Sat, 24 May 1997 00:33:51 -0700 (PDT) Received: (from msmith@localhost) by genesis.atrad.adelaide.edu.au (8.8.5/8.7.3) id RAA05396; Sat, 24 May 1997 17:03:45 +0930 (CST) From: Michael Smith Message-Id: <199705240733.RAA05396@genesis.atrad.adelaide.edu.au> Subject: Re: Wang DAT SCSI drive woes In-Reply-To: from Brandon Gillespie at "May 23, 97 10:15:19 am" To: brandon@cold.org (Brandon Gillespie) Date: Sat, 24 May 1997 17:03:45 +0930 (CST) Cc: freebsd-hardware@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-hardware@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Brandon Gillespie stands accused of saying: > > Has anybody ever wrestled with a Wang DAT SCSI drive? I just dropped one > in my FreeBSD box. I have used Exabytes before, but never a Wang DAT. > This one is on SCSI ID 6, and shows up in the boot probes as: Yeah, I have a couple. > aic0 at 0x340-0x35f irq 11 on isa > aic0 waiting for scsi devices to settle > (aic0:6:0): "WangDAT Model 2600 01.2" type 1 removable SCSI 2 > st0(aic0:6:0): Sequential-Access density code 0x93, 512-byte blocks, > write-enabled Aha, so what's the problem? > Now.. the controller is an old Adaptec 1524, I would think it is to fault, > but it hasn't given me problems with any other SCSI devices, such as > CD-ROMS, SCSI disks and Exabyte tape drives. The 152x controllers aren't the greatest, but they seem to work OK. > Or at the lease, help me decrypt what these dip-switches are for? Here is some mail I received when I was setting mine up : >From rose@locus.dml.com Thu Oct 17 16:03:09 1996 Received: from locus.dml.com [198.49.1.49] by genesis.atrad.adelaide.edu.au (8.6.12/8.6.9) with ESMTP id QAA13046 for ; Thu, 17 Oct 1996 16:02:54 +0930 Received: from localhost (rose@localhost) by locus.dml.com (8.6.12/8.6.12) with SMTP id XAA05137 for ; Wed, 16 Oct 1996 23:29:07 -0700 Date: Wed, 16 Oct 1996 23:29:07 -0700 (PDT) From: Stephen Rose To: Michael Smith Subject: Re: WangDAT 2x00 units... Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: RO I've had one of these for a couple of years. I'm happy with it. I can't say that I've used it heavily, though. I use it for the very occasional backup and transfering bits from home to work and back. I have to use uncompressed mode for that because it is incompatible with most other drives in compressed mode, as you pointed out. Here is how ncrcontrol sees it: T:L Vendor Device Rev Speed Max Wide Tags 6:0 WangDAT Model 2600 01.7 5.0 10.0 8 - The label on the drive says that it's a model 2000. The firmware for the 2600 and the 2000 is probably the same. Here is a table the manual has: Model Format Length Interface ------------------------------------------------------------ 1300 DDS 60m Single-ended 1300XL DDS 60,90m Single-ended 1300DF DDS 60m Differential 1300DL DDS 60,90m Differential 2600 WGC,DDS 60m Single-ended 2000 WGC,DDS 60,90m Single-ended I think WGC is the stack compression capability. Here are the dip switches: Number Function Default --------------------------------------- sw1-1 Buffered Mode off sw1-2 Default tape format on sw1-3 scsi-1/scsi-2 protocol off sw1-4 cassette load/unload off sw1-5 scsi bus parity enable on sw1-6 scsi bus id lsb off sw1-7 scsi bus id off sw1-8 scsi bus id msb off I think I've set sw1-2 to off to be compatible with other drives, although compression can be enabled in software. Sw1-3 is on because I wanted it to be scsi-2. I think I set sw1-4 on as well. Setting sw-1 to off lets the buffered mode be set by software. I've left that alone. JP-1 (behind the termination resistor sockets) is for enabling termination power on the scsi bus. Here is a table about sw1-4: Response to test unit ready or medium access command Condition Amber LED sw1-4 on sw1-4 off ------------------------------------------------------------------------ check condition check condition 1 Cassette off sense: not ready sense: not ready out medium not pres. medium not pres. ------------------------------------------------------------------------ check condition no check condition 2 insert start sense: not ready command accepted cassette flashing coming ready ------------------------------------------------------------------------ check condition no check condition 3 cassette flashing sense: not ready command accepted loading coming ready ------------------------------------------------------------------------ no check condition no check condition 4 cassette steady on command accepted command accepted loaded ------------------------------------------------------------------------ check condition check condition 5 cassette flashing sense: not ready sense: not ready unloading medium not pres. medium not pres. ------------------------------------------------------------------------ Here's another table: LED Color State Meaning ------------------------------------------------------------------------- Left green on drive active on scsi bus (Activity/Fault) ------------------------------------------------- red flashing drive fault condition exists ------------------------------------------------------------------------- flashing loading or unloading cassette Right amber ----------------------------------------- (Cassette/Format) on Cassette in place, format: DDS ------------------------------------------------- green on Cassette in place, format: Comp. ------------------------------------------------------------------------- It understands the usual cleaning cassette sort of thing, of course. The only other interesting thing in the manual is something called power eject. Holding the eject button in for 10 seconds causes a forced eject and a drive reset. Kind of a last resort thing. I haven't figured out how to get it to write a tape in the other format once it writes a tape in one format. I'd like to be able to write a tape in uncompressed format, if I want to, after once writing it in compressed format. It seems to insist on mounting the tape in compressed format if is sees that format. If you figure out how to do that, I'd like to know. Hope some of this is new. Steve Rose > -Brandon Gillespie > > > -- ]] Mike Smith, Software Engineer msmith@gsoft.com.au [[ ]] Genesis Software genesis@gsoft.com.au [[ ]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[ ]] realtime instrument control. (ph) +61-8-8267-3493 [[ ]] Unix hardware collector. "Where are your PEZ?" The Tick [[ From owner-freebsd-hardware Sat May 24 06:34:03 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id GAA25219 for hardware-outgoing; Sat, 24 May 1997 06:34:03 -0700 (PDT) Received: from ns.tar.com (ns.tar.com [204.95.187.2]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id GAA25214 for ; Sat, 24 May 1997 06:34:00 -0700 (PDT) Received: from ppro.tar.com (ppro.tar.com [204.95.187.9]) by ns.tar.com (8.8.5/8.8.5) with SMTP id IAA21152; Sat, 24 May 1997 08:33:48 -0500 (CDT) Message-Id: <199705241333.IAA21152@ns.tar.com> From: "Richard Seaman, Jr." To: "Daniel O'Callaghan" Cc: "hardware@FreeBSD.ORG" Date: Sat, 24 May 97 08:33:48 -0500 Reply-To: "Richard Seaman, Jr." Priority: Normal X-Mailer: PMMail 1.91 For OS/2 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: Re: Intel Pentium II released Sender: owner-hardware@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > Can anyone please point me to a web page which describes all of these > nuances in the the motherboard chipsets. I've looked on www.intel.com to > no avail. Try http://www.intel.com/design/pcisets/datashts/ From owner-freebsd-hardware Sat May 24 17:16:14 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id RAA27004 for hardware-outgoing; Sat, 24 May 1997 17:16:14 -0700 (PDT) Received: from bmccane.uit.net (bmccane.uit.net [208.129.189.48]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id RAA26999 for ; Sat, 24 May 1997 17:16:11 -0700 (PDT) Received: from bmccane.uit.net (localhost.mccane.com [127.0.0.1]) by bmccane.uit.net (8.8.5/8.8.5) with ESMTP id TAA13757; Sat, 24 May 1997 19:15:56 -0500 (CDT) Message-Id: <199705250015.TAA13757@bmccane.uit.net> X-Mailer: exmh version 2.0gamma 1/27/96 To: Brett Glass cc: hardware@FreeBSD.ORG Subject: Re: isa bus and boca multiport boards In-reply-to: Your message of "Thu, 22 May 1997 18:12:07 MDT." <3.0.1.32.19970522181207.0072d920@lariat.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 24 May 1997 19:15:55 -0500 From: Wm Brian McCane Sender: owner-hardware@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > At 09:47 AM 5/22/97 -0700, Jim Shankland wrote: > > >This "tuned asm" thing is perilously close to an urban myth, anyway. > >To the extent there's any "lift" to be gotten from asm at all, it's > >from tiny little pieces in performance-critical inner loops, > > Exactly. The guts of the sio driver ARE some performance-critical inner loops. > > >especially > >if there's a hardware-specific instruction that the compiler won't > >generate. > > I'd have to look at the generated code to see how well I/O is done. But > I'd HOPE that the macros do the right thing. > > >It's one thing to say, "I've just spent 3 weeks of backbreaking labor > >tuning the sio driver, and made it X% faster; then I experimented and > >found that, by replacing the following N lines of C code with assembler, > >I made it Y% faster still"; and another to wave one's hands about > >a fast sio driver written in assembler. Given the costs in portability, > >maintainability, and effort required for assembler, arguments for its > >use must be supported by strong, empirical evidence of benefit. > > My experience on other OS platforms dictates that there IS a large measure > of efficiency to be gained -- on the order of 25% time savings. The > improvements are partly from ASM and partly from good algorithms. > > --Brett > Tuned asm can be VERY useful. I wrote a program recently to crack PKZIP passwords for my wife (she forgot one 8-). On a test zip I created, my `C' version of the header checksum code took 7 minutes to crack a 4 character all uppercase password. I then flattened the algorithm to not use recursion, which reduced it to about 5 minutes. After writing my assembler version of the routine which did all the obvious things, (used registers for each key, one more for temporary, no unavoidable register loads, etc), the new version only took 2 minutes. Unfortunately her password was 8 characters (alpha and numeric), and took DAYS to crack. brian BTW> A cheap M$ slam. I compiled a console program under MSVC++, including inline assembler for the header computation, it took 22 minutes to crack the test file 8).