svn commit: r197969 - head/sys/conf

[M. Warner Losh]

In message: <EC2B1366-67F5-4021-A5A0-040D035ADD6C at mac.com>
            Marcel Moolenaar <xcllnt at mac.com> writes:
: 
: On Oct 13, 2009, at 5:06 PM, M. Warner Losh wrote:
: 
: > In message: <2E290D8D-BAF0-4E4E-A352-B00FAFD9DF83 at mac.com>
: >            Marcel Moolenaar <xcllnt at mac.com> writes:
: > :
: > : On Oct 13, 2009, at 10:32 AM, M. Warner Losh wrote:
: > : > : > Why?  They should be scanned for on any system with a real isa
: > : > bus...
: > : > :
: > : > : Other than i386, those are?
: > : >
: > : > So other than i386 and amd64, what systems use the isa device?
: > :
: > : I interpret the lack of answer as: none.
: > :
: > : isa(4) is usable on various architectures where the southbridge
: > : contains a LPC or similar. The MPC8555 CDS, for example, has a
: > : VIA southbridge that we need to talk to in order to get to the
: > : ATPIC for dealing with the nested interrupt. isa(4) is the device
: > : for this, but isaorm is causing kernel panics simply because
: > : the memory between 0xC0000 and 0x100000 is not reserved for ISA
: > : option ROMs. Likewise for Itanium, sparc64, etc...
: >
: > Does this mean that the memory cycles on the I/O bus isn't supported
: > for these architectures?
: 
: Correct.

Sparc64 doesn't have an ISA bus at all.  Hmmm, NetBSD doesn't
implement it, but it looks like we have ofw_isa that does implement
it.  It looks like NetBSD implements all the ISA bus devices we have
as ebus devices.  Not sure which is more correct, but it is clear from
reading the sparc64 isa.c that it does unnatural acts to convince the
rest of the system there's really an ISA bus there.  It looks to have
memory ranges decoded form the ofw description.  It isn't clear to me
if these are additional devices that NetBSD doesn't support that hang
off a PCI-ISA bridge (in which case I'd imagine the memory cycles are
passed down), or if they are on what NetBSD calls the ebus.  However,
given the limited activity in the sparc64 port, I'm not sure a lot of
work here is warranted.  We've been scanning orm on this architecture
for a long time, and haven't had reports of crashes.

sys/powerpc/mpc85xx/isa.c could easily reflect that there's no memory
available by failing all SYS_RES_MEMORY requests.  This would properly
fix the bus to reflect reality, and would break things with a proper
message (can't allocate the memory resource on the bus).  This would
move the orm problem from a crash to minor code bloat.  That's a much
easier problem to solve, and won't break ARM systems that have a
PC-104 expansion bus that do support memory address cycles on the
pc-104 bus.  This code isn't yet in the tree.

The itanium stuff I can't comment on, but if it is the same, then a
similar trick could be used as for powerpc.

I've included something that should be sufficient for powerpc to
behave properly.

Warner
-------------- next part --------------
Index: isa.c
===================================================================
--- isa.c	(revision 197533)
+++ isa.c	(working copy)
@@ -51,6 +51,14 @@
 	struct resource_list *rl = &idev->id_resources;
 	int isdefault, passthrough, rids;
 
+	/*
+	 * MPC85xx reference boards have most of a pseudo ISA bus, but
+	 * don't pass memory cycles to the cards.  Fail all allocation
+	 * attempts to reflect this.
+	 */
+	if (type == SYS_RES_MEMORY)
+		return NULL;
+
 	isdefault = (start == 0UL && end == ~0UL) ? 1 : 0;
 	passthrough = (device_get_parent(child) != bus) ? 1 : 0;
 
@@ -59,7 +67,6 @@
 		switch (type) {
 		case SYS_RES_IOPORT:	rids = ISA_PNP_NPORT; break;
 		case SYS_RES_IRQ:	rids = ISA_PNP_NIRQ; break;
-		case SYS_RES_MEMORY:	rids = ISA_PNP_NMEM; break;
 		default:		rids = 0; break;
 		}
 		if (*rid < 0 || *rid >= rids)