Date: Sat, 27 Mar 2004 17:14:16 -0700 (MST) From: "M. Warner Losh" <imp@bsdimp.com> To: scottl@freebsd.org Cc: current@freebsd.org Subject: Re: agp0 hang in 5.2.1-RELEASE Message-ID: <20040327.171416.00453245.imp@bsdimp.com> In-Reply-To: <20040319180056.A30715@pooker.samsco.home> References: <20040319163324.X30715@pooker.samsco.home> <xzpekro5oef.fsf@dwp.des.no> <20040319180056.A30715@pooker.samsco.home>
next in thread | previous in thread | raw e-mail | index | archive | help
In message: <20040319180056.A30715@pooker.samsco.home>
Scott Long <scottl@freebsd.org> writes:
: On Sat, 20 Mar 2004, Dag-Erling [iso-8859-1] Sm=F8rgrav wrote:
: > Scott Long <scottl@freebsd.org> writes:
: > > On Fri, 19 Mar 2004, Dag-Erling [iso-8859-1] Smrgrav wrote:
: > > > set hint.agp.0.disabled=3D"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. New=
bus
: doesn't know what 'agp0' is until the probe bidding is complete. So y=
ou
: can really only disable the attach, not the probe. But what if the p=
robe
: is destructive or buggy? You're then left to telling the parent of t=
he
: 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 tha=
t
: every bus type might have different identifiers, and no one has come =
up
: with a mechanism yet that can be logically extended to these arbitrar=
y 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 =3D-)
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040327.171416.00453245.imp>