From owner-freebsd-hackers Wed Jun 7 09:58:14 1995 Return-Path: hackers-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id JAA25478 for hackers-outgoing; Wed, 7 Jun 1995 09:58:14 -0700 Received: from gndrsh.aac.dev.com (gndrsh.aac.dev.com [198.145.92.241]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id JAA25472 for ; Wed, 7 Jun 1995 09:58:10 -0700 Received: (from rgrimes@localhost) by gndrsh.aac.dev.com (8.6.11/8.6.9) id JAA02415; Wed, 7 Jun 1995 09:56:25 -0700 From: "Rodney W. Grimes" Message-Id: <199506071656.JAA02415@gndrsh.aac.dev.com> Subject: Re: 2.0.5 ALPHA To: esser@zpr.uni-koeln.de (Stefan Esser) Date: Wed, 7 Jun 1995 09:56:25 -0700 (PDT) Cc: dzerkel@feephi.phofarm.com, freebsd-hackers@freebsd.org In-Reply-To: <199506071142.AA07892@FileServ1.MI.Uni-Koeln.DE> from "Stefan Esser" at Jun 7, 95 01:42:06 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 4146 Sender: hackers-owner@freebsd.org Precedence: bulk > > On Jun 6, 21:36, "Danny J. Zerkel" wrote: > } Subject: Re: 2.0.5 ALPHA > > Since the PCI chip set messages are my code, > I'll comment on some of your questions. > > } Here's what dmesg says, by the way: > } CPU: 78-MHz Pentium 735\\90 or 815\\100 (Pentium-class CPU) > } Origin = "GenuineIntel" Id = 0x524 Stepping=4 > } Features=0x1bf > } real memory = 16384000 (4000 pages) > } avail memory = 15085568 (3683 pages) > > } bt0: Bt946C/ 0-PCI/EISA/VLB(32bit) bus > } bt0: reading board settings, busmastering, int=15 > } bt0: version 4.24, sync, parity, 32 mbxs, 32 ccbs > } bt0: targ 0 sync rate=10.00MB/s(100ns), offset=15 > } bt0: targ 3 sync rate= 5.00MB/s(200ns), offset=08 > } bt0: targ 6 sync rate= 4.54MB/s(220ns), offset=15 > > Hmm, that's unrelated, but quite interesting ... > The BusLogic seems to negotiate synch. transfers > before knowing the device characteristics (at least > before the SCSI code has issued an INQUIRY command). Because the BIOS on the buslogic does all that already and stores the values in a struct that is read from the board. There is no sync negotiantion code in the BT driver, it is handled by the card. > } bt0: Enabling Round robin scheme > } bt0 at 0x330 irq 15 on isa > } (bt0:0:0): "CONNER CFP1060S 1.05GB 2035" type 0 fixed SCSI 2 > } sd0(bt0:0:0): Direct-Access 1013MB (2074880 512 byte sectors) > } sd0(bt0:0:0): with 2756 cyls, 8 heads, and an average 94 sectors/track > } (bt0:3:0): "HP HP35470A 1109" type 1 removable SCSI 2 > } st0(bt0:3:0): Sequential-Access density code 0x13, variable blocks, write-enabled > } (bt0:6:0): "PLEXTOR CD-ROM PX-4XCS 1.01" type 5 removable SCSI 2 > } cd0(bt0:6:0): CD-ROM > } cd0(bt0:6:0): NOT READY asc:3a,0 Medium not present > } can't get the size > ... > } Probing for devices on the pci0 bus: > } configuration mode 2 allows 16 devices. > } chip0 rev 17 on pci0:0 > } CPU: Pentium, 100MHz, CPU->Memory posting ON > ^^^^^^ > This 100MHz value is derived from a clock > divider setting in the chip set. > (Don't know where the 78MHz in the first > lines of the boot log come from.) I do, and have seen values from 82 to 90 reported for a 90 Mhz part, but have never seen it be *this* far off. I should probably open a PR about this bug but since I have not seen it in 30 days I though it might have gone away :-(. > } CPU->PCI: posting ON, burst mode ON, PCI clocks=2-1-1-1 > } PCI->Memory: posting ON > } chip1 rev 3 on pci0:2 > } [40] 40420 [50] 0 [54] 4000000 > } pci0:3: vendor=0x1095, device=0x640, class=storage [not supported] > } pci0:13: vendor=0x104b, device=0x1040, class=storage [not supported] > } map(10): io(fcfc) > > If you know what kind of devices these are, > they can be appended to our PCI vendor and > card list. I will call the PCI office and see if I can get an updated list of ``official'' vendor ID codes. The new 2.1 spec should about have the ink dry on it too, so I will order a copy of that now. > } Note: The first line says 78MHz, sometimes it say 100MHz. > } The DRAM: line says "(70ns)", althought I have 60ns memory. > } Is there a way of changing this. > > The PCI code only displays values, since we > found that we generally can rely on the BIOS > for initialisation. Humm.. I need to look into this, SIMM's infact do have a set of signal lines on the for speed and type of module. Some chipsets do infact read these static signals to determine how fast they can run memory. You may have 60nS chips on a SIMM module set for 70nS operation (ie, this was probably a simm built for 60nS operation but failed at final sort and was strapped to ID itself as 70nS. Some one noticed they had 60nS chips on them so though that it was really a 70nS module (see this all the time in the grey memory market :-(). If you want more details I can tell you how to ID the simm modules with an ohm meter. -- Rod Grimes rgrimes@gndrsh.aac.dev.com Accurate Automation Company Custom computers for FreeBSD