> i'm not entirely sure i understand. "pnp o/s = no" causes the bios
> to assign an irq to the pcic controller, meaning the pcic controller
> raises that interrupt on insertions/removals, but the driver,
> operating in polling mode, never clears the interrupt so the machine
> wedges trying to service it? if this is correct, how does ddb
> manage to unwedge things?
In some cases, the issue is that the interrupt generated by the bridge is
level-triggered, which means that a failure to handle and clear it
results in an interrupt loop. I don't know why breaking to DDB would
ever fix this. If the interrupt is shared with other hardware (in your
case, it appears to be shared with the UHCI controller, which is normal)
then the interplay simply becomes more complex (because the failure may
be due to bad behaviour in other code which responds differently when
single-stepped due to timing interactions with the hardware).
> the fix in -current is the pci interrupt routing code which allows
> us to set "pnp os = yes" in the bios and let freebsd make irq
> assignments only for devices it understands? any chance this will
> MFC-ed?
The "correct" fix is to improve our old and badly broken pccard/cardbus
code, which is a work in progress. The interrupt routing code exists so
that we can deal with bridges which don't have an interrupt correctly
assigned (typically it's connected OK, but we don't know where to).
--
... every activity meets with opposition, everyone who acts has his
rivals and unfortunately opponents also. But not because people want
to be opponents, rather because the tasks and relationships force
people to take different points of view. [Dr. Fritz Todt]
V I C T O R Y N O T V E N G E A N C E
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-stable" in the body of the message
