On Mon, Jun 06, 2011 at 07:04:29PM -0600, Bjorn Helgaas wrote: > On Mon, Jun 6, 2011 at 5:45 PM, Greg KH <greg@xxxxxxxxx> wrote: > > On Mon, Jun 06, 2011 at 05:26:46PM -0600, Bjorn Helgaas wrote: > >> Maybe acpiphp can't be built in statically in its current form, but I > >> don't think we should necessarily give up and say "well, we just can't > >> make this platform work." It's likely that hotplug "just works" under > >> Windows, so it's probably *possible* to make it work well under Linux. > > > > No, the hardware really was broken, and the manufacturer told us to > > never load the acpiphp driver on it, otherwise bad things would happen. > > Supposidly they were going to fix this in future BIOS updates, but I > > never found out if that happened or not. > > > > And it wasn't just one manufacturer, it happened on a lot of machines > > when acpiphp first was added to the kernel. > > > >> My guess is that this is not really a distro issue (e.g., decisions > >> about config, autoload, /etc/modules, etc.), but rather an indication > >> that we could make something better in the kernel. Whether that's > >> some kind of acpiphp improvement, some date-based checking, or what, I > >> don't know. And it may be that nobody has the right combination of > >> interest/expertise/time/test machines to really solve it (I know I > >> don't). > > > > Maybe date-check it, for autoloading, but the problem is, you can't do > > that from within the kernel as you don't know how you were loaded. > > > > It's a mess, sorry, but blame the hardware here. I spent a lot of time > > trying to get this to work way-back-when and this was the best that we > > could come up with :( > > If we want to blame old, broken hardware for problems on that old, > broken hardware, that makes sense to me. > > But it seems like we've now crippled acpiphp forever, on all hardware, > and I'm not so sure about that. It's been that way from the very beginning, funny that it only is an issue now, years after any new hardware that needs acpiphp shows up :) > Could we at least limit the scope somehow, like have acpiphp disable > itself internally for DMI dates < 2012 or something? Then it could be > safely autoloaded on the old boxes, and presumably new ones that need > it will be better-tested. I don't care anymore, if you think it's safe to enable it, by all means, let's try it and see what falls out. As long as you are willing to help debug the systems that cause issues, I will not object to changing this now. thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
