Casper.Dik at Sun.COM wrote:
>> Hmm... that's bad. It sounds like a shared interrupt. (Or the driver
>> isn't clearing the hardware interrupt before doing attach(9e), but then
>> that would indicate the same bug in both windows and solaris drivers.)
>> It also sounds like the device doesn't get reset by e.g. a PCI bus
>> reset. I've seen that before with prism cards.
>>
>
> It was a shared interrupt; yes. Yep, the fact that warm boot and cold
> boot are different is really a bug; the fact that some devices don't
> reset is an error in the hardware; working around this in software is
> the only real option.
>
> (My Ferrari 4000 fixes this interesting conundrum by making a reboot
> actually cause a < .1sec power cycle)
>
Heh. As do recent Tadpole platforms. There was an older platform
(Voyager IIi) that didn't have software controllable power supply (it
was a shoebox, portable server, not a laptop product), and suffered from
this particular problem.
>
>> devo_reset (if that's what you mean) is listed as not supported. But
>> grepping around in the code, it looks like it gets called via
>> devi_reset, which is called via reset_leaves(), and possibly via other
>> paths as well.
>>
>
> Yes. It's called on reboot and panics; it's is not a supported entry
> point but it is needed. What you can do is very limited: in panic mode,
> all interrupts are disabled.
>
I'd like to see this entry point documented properly, and supported.
The limitations are not unlike those for dump(9e), I think. And it
won't get called if your driver panics during attach or detach (I just
checked that), but even so, the very fact that this entry point might be
needed means it really should be properly documented.
For what its worth, on ~every Sun system I've ever used (at least SPARC
based) this isn't a problem, because the platform reset at boot seems to
include a power cycle. The only exception to this on SPARC platforms
that I'm aware of is the Voyager IIi, and I've always considered that a
hardware bug.
On PCs, this problem is likely to be much more pervasive, and we really,
really should document the entry point so that device driver authors can
take care to make their drivers hardened against these cases.
-- Garrett
--
Garrett D'Amore, Principal Software Engineer
Tadpole Computer / Computing Technologies Division,
General Dynamics C4 Systems
http://www.tadpolecomputer.com/
Phone: 951 325-2134 Fax: 951 325-2191
