From owner-freebsd-current Mon Jan 17 21: 9: 6 2000 Delivered-To: freebsd-current@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (Postfix) with ESMTP id B5A4714D69 for ; Mon, 17 Jan 2000 21:09:02 -0800 (PST) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.9.3/8.9.3) with ESMTP id WAA66705; Mon, 17 Jan 2000 22:08:59 -0700 (MST) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id WAA14190; Mon, 17 Jan 2000 22:09:18 -0700 (MST) Message-Id: <200001180509.WAA14190@harmony.village.org> To: Peter Wemm Subject: Re: PnP probing in -current Cc: Brian Somers , freebsd-current@FreeBSD.org In-reply-to: Your message of "Tue, 18 Jan 2000 12:15:42 +0800." <20000118041542.A6FBC1CA0@overcee.netplex.com.au> References: <20000118041542.A6FBC1CA0@overcee.netplex.com.au> Date: Mon, 17 Jan 2000 22:09:18 -0700 From: Warner Losh Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <20000118041542.A6FBC1CA0@overcee.netplex.com.au> Peter Wemm writes: : > aha0: status reg test failed ff : > unknown9: at port 0x330-0x333 irq 11 drq 5 on isa0 : ^^^^^^^^^^^^^^^^^^^^^ : Warner, what does this mean? the status register is 0xff? Could : that mean that the 1542CP didn't get it's mapping at 0x330 : activated? Likely. The register status 0xff means that we got back garbage from the aha device. There are three bits we test for specifically, DIAG active, command register busy and reg_rscvd (which may be more than one bit). If any of these read 1, that almost always means that we're not talking to real hardware. I surmise that the mapping to 0x330 didn't actually happen. I've had some reports of oddball aha compatible EISA boards that had this problem in the past, but that was due to a minor eisa bug, iirc. We do all these tests mondo early in the probe process. We do it just after the bus_space_alloc(...RF_ACTIVE); happens. : Also: : > ADP1542: adding memory range 0xc8000-0xdc03f, size=0x40, align=0x4000 : Could this be causing a failed allocation somewhere? (pr doesn't it matter : since the ROM isn't being activated?) That I can't tell you. We're definitely failing the probe because of what the probe's talking to hardware results in its concluding that the hardware isn't there. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message