hw.pci.do_power_nodriver=3

Warner Losh imp at bsdimp.com
Fri Dec 6 20:52:16 UTC 2013


On Dec 6, 2013, at 1:26 PM, John-Mark Gurney wrote:

> Warner Losh wrote this message on Thu, Dec 05, 2013 at 22:43 -0700:
>> 
>> On Dec 5, 2013, at 9:12 PM, Eitan Adler wrote:
>>> Is there any reason we can not set  hw.pci.do_power_nodriver=3 by default?
>>> 
>>> My understanding is that there were problems with hardware being
>>> powered off and not being powered back on when drivers were loaded.
>>> Is this still a concern? If yes, can we flip the switch in HEAD and
>>> fix the drivers?
>> 
>> The reason it was for Adaptec RAID controllers.
>> 
>> They had a weird topology:
>> 
>>                            <-------------------- aac based card -------------------------->
>> 	pci bus ---- pci bridge ---- pci bus ---+----- some chip with driver
>>                                                                        +----- chip without driver
>> 
>> so, when the enumeration code saw that there was no driver attached to the second chip, it would power it down. Turns out, this chip, while it didn't have a driver, was critical to the proper functioning of the RAID card. Scott Long turned off the default power saving because he was worried there were other parts like this. In addition, in an abundance of caution, he also created stub drivers for the second chip for each of the then known aac cards.
>> 
>> Since then, it is unknown if others have followed this design or not, so it is unknown our exposure if we were to flip this to have a different default.
> 
> Should we flip this on by default in HEAD to help expose these issues?
> It is expected that people running HEAD spend a little time helping us
> debug issues, and if they don't want to take the risk, they can change
> the default...
> 
> Then maybe after a few years, maybe not 11, but for 12, we can keep it
> on by default for a release?

Scott and I talked about a possible solution that would be safe. Once I have that implemented, we can likely switch things over...

Warner



More information about the freebsd-arch mailing list