Date: Tue, 13 Oct 2009 22:04:11 -0600 (MDT) From: "M. Warner Losh" <imp@bsdimp.com> To: xcllnt@mac.com Cc: svn-src-head@FreeBSD.org, svn-src-all@FreeBSD.org, src-committers@FreeBSD.org Subject: Re: svn commit: r197969 - head/sys/conf Message-ID: <20091013.220411.-432748090.imp@bsdimp.com> In-Reply-To: <EC2B1366-67F5-4021-A5A0-040D035ADD6C@mac.com> References: <2E290D8D-BAF0-4E4E-A352-B00FAFD9DF83@mac.com> <20091013.180620.-1542634329.imp@bsdimp.com> <EC2B1366-67F5-4021-A5A0-040D035ADD6C@mac.com>
next in thread | previous in thread | raw e-mail | index | archive | help
In message: <EC2B1366-67F5-4021-A5A0-040D035ADD6C@mac.com>
Marcel Moolenaar <xcllnt@mac.com> writes:
:
: On Oct 13, 2009, at 5:06 PM, M. Warner Losh wrote:
:
: > In message: <2E290D8D-BAF0-4E4E-A352-B00FAFD9DF83@mac.com>
: > Marcel Moolenaar <xcllnt@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.
Then it isn't an ISA bus.
: > Or that it is and we just don't implement it
: > in the platform specific interfaces for it?
:
: No.
Then they aren't real ISA buses.
: > The memory space is
: > reserved for any system that has a ISA bus, but it might not be at
: > physical address 0xc0000, etc.
:
: It's uncommon to have an actual ISA bus and even more uncommon
: that the option ROM is actually being used.
ISA memory ranges are quite common on actual cards.
: > : In short: scanning for option ROMs is not possible in all cases
: > : where ISA compatibility is provided.
: >
: > Why is that? The platform specific code needs to implement the
: > necessary hooks to support this.
:
: There are no hooks to implement. If there is any FreeBSD supported
: board that actually needs to have the option ROMs scanned by orm(4),
FreeBSD does support boards that need to have option ROMs scanned.
Every PC made today even has them. Today they are primarily video
BIOS that's being scanned. They are also on SCSI controllers and can
be on network cards. FreeBSD still has support for all these
devices.
All PC Cards, even those in CardBus slots, need to have this
functionality to avoid mapping their CIS on top of a ROM that may be
there.
: then we can always make it conditional upon ``device isa_orm''. Making
: it dependent on isa(4) is causing real problems and my change limits
: the use of orm(4) to platforms where it can possibly have any chance
: of being useful -- provided orm(4) is changed to do something useful.
Every system that has an ISA bus needs to have it scanned for the
ROMs. It is part of the ISA specification. If there are variants
that don't have any way to create memory bus cycles on the ISA bus,
then we need some systemic way to cope. Remove orm is a half-assed
kludge since it breaks ISA PNP boards that have memory ranges, for
example.
So let's fix this right, and avoid yet another kludge like the one
you've committed. And this time, let's talk about the fix rather than
doing a drive-by?
Warner
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20091013.220411.-432748090.imp>