>The problem is that if the hardware comes up with interrupts enabled, >you need to make sure that the interrupt is disabled before the >interrupt is enabled (typically in attach(9e).)
The thing is that much of the hardware that comes up with interrupts enabled is hardware that does so only on warm boot; and then you can fix it by disabling the interrupt when going down. >This can be problematic for devices that have shared interrupts. If you >are running into this problem on x86 hardware, you really should try to >assign the device its own IRQ (i.e. if it is sharing an IRQ bad things >will happen if the "other device" it is sharing the IRQ with enables the >interrupt before your driver gets a chance to make sure the interrupt is >disabled. That's why iprb now disables interrupts when the system goes down; the specific systems with the issue shared the IRQ and hung on warm reset. >Another workaround that _might_ work would be to list the device driver >in the ddi-forceattach property list (I don't recall _precisely_ how to >do that offhand), as it _may_ cause your driver to get loaded and >attach(9e)'d before the other device. Not really; the hang happens as soon as another device with the appropriate IRQ attaches. Casper
