Hi Len, Le lundi 31 août 2009, Len Brown a écrit : > > > The message "ACPI: Device needs an ACPI driver" is misleading... > > > > ACPI: Device may still be supported by an ACPI driver > > > I would drop the word "still", but otherwise I think this is a good idea. > > I agree we need to clarify this message. > > Right now we have (copied from a recent bug report): > > w83627ehf: Found W83627EHG chip at 0x290 > ACPI: I/O resource w83627ehf [0x295-0x296] conflicts with ACPI region SEN1 > [0x295-0x296] > ACPI: Device needs an ACPI driver > > This results in people filing bugs against ACPI because their sensor > driver does not load -- we've seen several already. I know, and this is why I sent a patch to change the wording. > I'm okay with the 1st ACPI line -- it tells somebody who cares exactly > what is going on. > > "Device needs an ACPI driver", however, fails to tell the administrator > what they can do about it. We should probably mention that they > can test "acpi_enforce_resources=lax". However, we should probably > put a big WARNING - using-at-own-risk note in the dmesg when > that option is actually used. I don't think we want to unconditionally point the user to "acpi_enforce_resources=lax". Doing so would essentially void our effort to get rid of concurrent access to these resources. In particular, now that we have the asus_atk0110 driver and this driver loads automatically on the boards which need it, we certainly do NOT want to tell these users that they should use "acpi_enforce_resources=lax". What they should do is use the asus_atk0110 driver instead of the native driver they were using so far. Only if no ACPI-based hardware monitoring driver has been loaded, we could point the user to "acpi_enforce_resources=lax". With a warning and disclaimer, of course. > And then what is the next course of action -- possible inclusion > on a white-list if they conflict turns out to be benign, > or (less likely) possible development of a missing ACPI driver? I wasn't sure whether you would be OK with a whitelist. I too think we will need one, although this won't be in 2.6.31. Then it indeed makes sense to ask the users to test "acpi_enforce_resources=lax", and if it works, they can report to us and after a DSDT code review, their system can be added to the whitelist. I am curious how many systems will have to be added to the whitelist. I presume that the whitelist would consist in DMI board vendor + model entries? > We could have quite a few bug reports filed on this, > so wording is important. I fully agree. What I propose: * For 2.6.30 (if we are fast enough), an updated version of my patch, taking Alan Jenkins' suggestion into account, and an additional warning when "acpi_enforce_resources=lax" is used. * For 2.6.31, a whitelisting mechanism, and a verbose log message explaining the steps to get a system into this whitelist. OK? Thanks, -- Jean Delvare Suse L3 -- 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
