Date: Tue, 5 Sep 2000 22:12:49 -0700 (PDT) From: Matthew Jacob <mjacob@feral.com> To: Peter Wemm <peter@netplex.com.au> Cc: Andrew Gallatin <gallatin@cs.duke.edu>, obrien@FreeBSD.ORG, alpha@FreeBSD.ORG Subject: Re: what was the last patch you sent out? Message-ID: <Pine.BSF.4.21.0009052207370.50261-100000@beppo.feral.com> In-Reply-To: <200009060344.e863i9G48367@netplex.com.au>
next in thread | previous in thread | raw e-mail | index | archive | help
> > What I'd like to know is what is different about the CIA setup in the PC164 > (vs PC164SX).. > > Also, consider this difference: > > PC164: > cia0: ALCOR/ALCOR2, pass 3 > cia0: extended capabilities: 21<DWEN,BWEN> > PC164SX: > cia0: Pyxis, pass 1 > cia0: extended capabilities: 1<BWEN> > > And consider: > if (cia_rev >= 2 || cia_ispyxis) > cia_config = REGVAL(CIA_CSR_CNFG); > else > cia_config = 0; > .. > if (alpha_implver() != ALPHA_IMPLVER_EV5 > || alpha_amask(ALPHA_AMASK_BWX) > || !(cia_config & CNFG_BWEN)) { > .. > chipset = cia_swiz_chipset; > } else { > .. > chipset = cia_bwx_chipset; > } > > IE: we are setting cia_bwx_chipset for all capable chipsets, including > both the ALCOR and Pyxis ones that I've seen console cut/pastes from. > > While later: > if (cia_ispyxis) { > snprintf(chipset_type, sizeof(chipset_type), "pyxis"); > chipset_bwx = 1; > chipset_ports = CIA_EV56_BWIO; > chipset_memory = CIA_EV56_BWMEM; > chipset_dense = CIA_PCI_DENSE; > } else { > snprintf(chipset_type, sizeof(chipset_type), "cia"); > chipset_bwx = 0; > chipset_ports = CIA_PCI_SIO1; > chipset_memory = CIA_PCI_SMEM1; > chipset_dense = CIA_PCI_DENSE; > chipset_hae_mask = 7L << 29; > } > > It seems to me that at one point, we are setting the Pyxis/ALCOR to use > BWX and later on we are setting BWX modes on Pyxis-only (missing out the > PC164's ALCOR chips), but we are leaving the chipset[] vector pointer > setup for BWX. > > Could this possibly explain it? (ie: machine half setup for SWIZ and half > for BWX) I really do not understand the finer details of this area of the > Alphas. I noticed the code. It *is* bogus. But it isn't what's killing me. I traced thing far enough to see things wedge just after it first identifies the first card in the PCI bus. I can't quite tell yet whether I'm dying right after reading the vendor id or whether the DELAY's I put in to let things drain enough so that printf's could get out weren't enough or what- part of the problem here is the !$)*@$~)(*~_)@~!)@$ stupid way FreeBSD/NetBSD do their console setup on Alpha (begging everyone's pardon- I've hated this stand on your head out of order init stuff that gets done) so it's really hard to know quite when you got stomped if you have a serial console. I won't be back in the office until tomorrow night when I'll resume. Since 4100 worked for me (to a 1st approx), which is a hard case, let's assume that the pure PC164 is 'something else' for the moment. -matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0009052207370.50261-100000>