From owner-svn-src-head@FreeBSD.ORG Wed Oct 14 04:39:11 2009 Return-Path: Delivered-To: svn-src-head@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 19B101065676; Wed, 14 Oct 2009 04:39:11 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id BB2178FC13; Wed, 14 Oct 2009 04:39:10 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.3/8.14.1) with ESMTP id n9E4YmMZ018130; Tue, 13 Oct 2009 22:34:48 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Tue, 13 Oct 2009 22:34:59 -0600 (MDT) Message-Id: <20091013.223459.-957891176.imp@bsdimp.com> To: xcllnt@mac.com From: "M. Warner Losh" In-Reply-To: References: <2E290D8D-BAF0-4E4E-A352-B00FAFD9DF83@mac.com> <20091013.180620.-1542634329.imp@bsdimp.com> X-Mailer: Mew version 5.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Multipart/Mixed; boundary="--Next_Part(Tue_Oct_13_22_34_59_2009_081)--" Content-Transfer-Encoding: 7bit Cc: svn-src-head@FreeBSD.org, svn-src-all@FreeBSD.org, src-committers@FreeBSD.org Subject: Re: svn commit: r197969 - head/sys/conf X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Oct 2009 04:39:11 -0000 ----Next_Part(Tue_Oct_13_22_34_59_2009_081)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit In message: Marcel Moolenaar writes: : : On Oct 13, 2009, at 5:06 PM, M. Warner Losh wrote: : : > In message: <2E290D8D-BAF0-4E4E-A352-B00FAFD9DF83@mac.com> : > Marcel Moolenaar 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(Tue_Oct_13_22_34_59_2009_081)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="powerpc-isa-fix.diff" 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) ----Next_Part(Tue_Oct_13_22_34_59_2009_081)----