On Tuesday 18 December 2007 10:59:18 am Jean Delvare wrote: > The real cause is pretty clear here: broken BIOS. In an ideal world we > would ask the manufacturer for a fixed BIOS and they would give that to > us, unfortunately my experience is that it won't happen. So, unless we > accept that idea that some users won't be able to use some of their > devices because of broken resource enumeration in their BIOS, we will > have to find a workaround, whatever it is. I suspect the manufacturers would say "Oh, the sensors? The BIOS isn't broken, you're just supposed to use WMI or some (undocumented) ACPI device to get at those." I know next to nothing about WMI, and there are probably IP issues in that area. But I'd rather spend effort in figuring out the "right" way to do this. Until we do it the same way as Windows, we can pile on hacks till the cows come home, and we'll still have issues. I added Carlos to the cc: list because he's been doing a lot of interesting-looking work on WMI. > My initial idea was to identify the faulty motherboard using DMI and to > force pnpacpi=off on the faulty motherboards. If this is considered too > aggressive, maybe we can just reject resource declarations that > intersect (but don't match) 0x290-0x297 for these motherboards. Either > way, we have to do something, and we have to do it quickly. 2.6.24 > final isn't too far away, and more importantly, the patch that revealed > the problem has been backported to 2.6.23.10 so people are experiencing > regressions already. Windows apparently doesn't reject those resource declarations, so I'm a bit hesitant to do it in Linux. That tends to cover up problems, and then it becomes very difficult to remove the band-aid and figure out a correct fix in the future. Bjorn - To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
