Re: agp0 hang in 5.2.1-RELEASE

From: M. Warner Losh <imp_at_bsdimp.com>
Date: Sat, 27 Mar 2004 17:14:16 -0700 (MST)
In message: <20040319180056.A30715_at_pooker.samsco.home>
            Scott Long <scottl_at_freebsd.org> writes:
: On Sat, 20 Mar 2004, Dag-Erling [iso-8859-1] Smørgrav wrote:
: > Scott Long <scottl_at_freebsd.org> writes:
: > > On Fri, 19 Mar 2004, Dag-Erling [iso-8859-1] Smrgrav wrote:
: > > > set hint.agp.0.disabled="1"
: > > I don't see any code in the agp drivers to look at this hint.  Is this
: > > impleneted some other way?
: >
: > Doesn't newbus automatically take care of that?
: >
: > DES
: 
: No.  This has been debated occasionally, but has some landmines.  Newbus
: doesn't know what 'agp0' is until the probe bidding is complete. So you
: can really only disable the attach, not the probe.  But what if the probe
: is destructive or buggy?  You're then left to telling the parent of the
: device (usually a bus) to ignore the device.  For PCI, this requires that
: the user know the bus, device, and function numbers.  This is
: inconvenient, but not impossible.  Unfortunately, this also means that
: every bus type might have different identifiers, and no one has come up
: with a mechanism yet that can be logically extended to these arbitrary bus
: types.

That's not quite true.  Maybe desirable, but not true for newbus.
newbus doesn't deal with bus selectors or pnp information, only unit
numbers.  So don't even go there if you want newbus to do it
automatically :-).

: Maybe handling the attach phase and ignoring the probe phase is good
: enough for now.  Feel free to propose something =-)

I've actually hacked together something that should do the right
thing, but haven't extensively tested it.  If the probe succeeds, it
checks to see if the device is disabled, and if so it doesn't call
attach.  This way it would be possible to disable cbb0 but still have
cbb1 in the same location it always is at.

You also need a way to disable the driver completely, which I'm also
implementing...

Warner
Received on Sat Mar 27 2004 - 15:14:34 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:37:49 UTC