I now have time to revisit this issue and have a few questions. First off the card in question is a dual ported adapter which has a PCI Bridge on board. So some issue may exist in the PCI Bridge code when you have two bridges back-to-back. I was reading up on power management (in I/O Kit Fundamentals) and it looks like in theory I would only need to implement a power-controller in my driver object (by overriding a few IOService methods) if I wanted to support power management. In the long run I do... but if I don't should the system not allow power down of my adapter? Seems dangerous to me (as you implied it shouldn't and we may be seeing a bug). Anyway, my driver is currently a sub-class of IOSCSIParallelController. IOSCSIParallelController doesn't appear to call PMinit in its start method and its super class IOService (naturally) doesn't call it. So if I understand things correctly my driver doesn't have a power policy-maker. Is this correct? or does it fall back to some higher/different object in this case My device is a PCI device and attaches to a PCIDevice Nub, does that connect it with a power policy-maker somehow? To enable power management in my driver do I need to implement both the power policy-maker and power-controller functionality? Or just power-controller functionality and some other object will manage policy for me (most likely dumbly because lack of particular knowledge my adapter). In the short term can I do something to block the system from powering off my adapter out from under me? This would make some early users very happy. I guess I am a little lost on this... any help would be greatly appreciated. -Shawn On Monday, October 1, 2001, at 07:03 PM, Shawn Erickson wrote: It is a QLogic 2202 64Bit/33Mhz PCI to Fibre Channel adapter. I see this problem on my test system with is a Dual 450 G4... the first of the G4 dual models. -Shawn On Monday, October 1, 2001, at 05:16 PM, Dave Suurballe wrote: You wrote: Started to test my PCI adapter driver and noticed that the system could be put to sleep and my adapters power would be shut off. On system wake the power comes back on but my driver is off in the weeds because it didn't know that the power was going to be shut off. Anyway... In the short term how can I ALWAYS veto the power down of my adapter? In the long term any pointers on how to get plugged into the power management system so I can put my driver in a safe state to allow power down of the adapter. Also how to a get up an going again at system wake? I looked over the PM related method in IOService but I am still lost at the moment... help :( -Shawn p.s. My driver is a sub-class of IOSCSIParallelController and drives a PCI based Fibre Channel adapter. I am testing Mac OS X build 5G64. 1. I don't know why the system slept; perhaps the card claims it's well-behaved with respect to power management. Still, having a non-power-managed driver should have prevented sleep. 2. There is no way to veto the power down of your adapter. However, the system should realize that there's a problem and not power down the PCI bus. I don't know why that didn't happen. 3. It isn't trivial to add power-management to your driver, but I can make it sound simple. The driver makes a couple calls to something, maybe itself. The driver implements an array which describes the power states of the device, minimally an on state and an off state. The driver implements a method that some object will call when it is time for your device to change power state. It will be told to turn off at sleep time, and it can save state, etc and turn off. At wake time it will be told to turn back on, and it can restore state, etc. The complexities are what to do if you get i/o requests while the device is off or is in the process of being turned off, what to do with i/o requests that are in progress when you are told to turn off, etc. There is a sample driver on Darwin, I think in a project called IOKitExamples or something like that. It's the networking driver. What is the PCI card? What make/model, etc? Dave Suurballe