Hi Robert, Robert, all, Sorry for the late answer. Busy at work then long vacation and here I am again. Le samedi 04 juillet 2009, Robert Hancock a écrit : > On 07/02/2009 09:49 AM, Moore, Robert wrote: > >> -----Original Message----- > >> From: Jean Delvare [mailto:jdelvare@xxxxxxx] > > ... > >> Native Linux drivers trying to access devices which ACPI also wants > >> to access. Most frequently these are SMBus master drivers or hardware > >> monitoring drivers (for Super I/O chips) but virtually any other > >> device type could be affected, due to the fact that ACPI I/O > >> resources do not show up in /proc/ioports and /proc/iomem. > > > > > > I have some concern with this. The implication is that there is a > > serious hole in ACPI that can only be solved by monitoring > > exactly what the AML code is doing, because access to resources > > may conflict with device drivers. This is the basic idea, yes. That being said, if I/O resources used by ACPI are properly declared, then the problem is partly solved: ACPI will take care of the devices (either through a dedicated driver or through a generic ACPI driver such as "thermal") and native drivers will not attempt to access the device. Problems arise when: * ACPI declares I/O regions just because they exist, but doesn't make use of them. This will prevent native drivers from binding to the device, leaving the user without the functionality. * ACPI accesses I/O regions without declaring them. Native drivers will access them too, causing havoc. While the two issues above could be worked around by analyzing the AML code as you suggested, a better fix is to get BIOSes out there right. I know it's an on-going, never-ending battle, but it is still preferable to fix the bug where it really is, isn't it? Then there are two corner cases: * The ACPI implementation does offer the possibility to write an ACPI driver for hardware monitoring on a given machine, but we do not yet have written such a driver. This has been the case for Asus' ATK0110 driver for quite some time. This is a minor issue IMHO, not different from lack of support of other, hardware devices. * ACPI does access the hardware monitoring chip (or SMBus controller) and does something useful with it, but this is only a small subset of what a native driver would do. A typical example of this is mainboards implementing ACPI thermal zones out of a full-featured hardware monitoring chip. I have such a board here (Jetway K8M8MS). The ACPI "thermal" driver displays one temperature. The native driver (f71805f) displays 9 voltages, 3 fan speeds and 3 temperature values, all settable min and max limits, and their associated alarm flags. The ACPI "thermal" driver will load by default, while the native driver will be blocked, leaving the user with very reduced functionality. Me, I have configured by system to blacklist the thermal driver and load the f71805f driver instead, I _think_ I am safe doing this, but I'm not even sure. > > I have to think that if this were truly the case, the operating > > system vendors and the ACPI contributors would have pushed a fix > > for this problem into the ACPI specification by now (in the 13 > > years since the first release of ACPI). If they did care, yes they would have. But see below. > > The SMBus driver issue is very interesting. I have not heard of > > any conflicts between AML code and SMBus drivers on other > > operating systems, nor have we received any other complaints > > about removing the acpi_os_validate_address interface. I wonder > > if the Linux SMBus driver is doing something that it should not > > be doing. I don't think it is. The Linux SMBus drivers (note the plural, we have one driver for each separate PC SMBus implementation, that's about a dozen of them) do exactly what they have to, that is: provide the rest of the kernel with a standard API to access devices connected to the SMBus. Of course you can claim that, on ACPI systems, the OS should never attempt to access thermal-management-related devices. This solves the resource conflict problem at once, at the price of a loss of functionality for most users out there (because on most desktop and server systems, ACPI doesn't care about thermal management at all.) > > I'd like to see a concrete example of the problem. If someone can > > send me a DSDT that contains such an example, I would appreciate > > it. I want to see the exact ASL code that is causing the problem > > along with the driver code that conflicts with it. This > > information will help me understand the problem in relation to > > the ACPICA code, and I can also present this to other ACPI and > > BIOS experts for their opinions. Here you go, attached. This is the only machine I have at home with an ACPI vs. native driver resource conflict. This is the mainboard I mentioned above already: Jetway K8M8MS. Conflict is for I/O region 0x295-0x296. > > As far as an immediate fix for the problem, I suggest that you > > think about using acpi_walk_namespace to retrieve all objects of > > type Region (or field). It seems a waste to build an entire list > > of objects that duplicates information that already exists in the > > namespace. > > My guess is that exactly the same thing will happen if you install > add-on hardware monitoring software on Windows that loads drivers that > access SMBus hardware directly on such systems where ACPI accesses the > same devices. The ACPI code and the native driver will likely stomp on > each other's hardware accesses. Likely on Linux it's more frequent that > this kind of native hardware monitoring driver gets used (in some setups > it seems they will auto-load by default..) This is a very good point, although not totally exact. The key reason why the problem wasn't solved yet is because Microsoft doesn't give a damn. Last time I checked (several years ago admittedly) Windows did not offer support for hardware monitoring at all. Basically the user must choose between a vendor-provided monitoring applications (most PC mainboard vendors have one by now) or 3rd party applications such as MBM (discontinued), SpeedFan or hmonitor. With vendor applications, the problem doesn't exist, because the vendor has additional knowledge. They only support their own products, and they know what their ACPI implementation is doing or not. So they can easily access custom ACPI code if needed, use custom locking mechanism if needed, etc. With 3rd party applications, the problem is exactly the same as with Linux: this is best effort. The big advantage is a unified hardware monitoring handling across all vendors and models, but at the price of a lack of knowledge about system specifics, which means lot of trouble on some systems. As you are talking about improving the ACPI standard, here are ideas of what could be done: * ACPI could define a standard interface to access hardware monitoring chips. Something similar in essence to the thermal zones, but that would cover all the standard features of hardware monitoring chips (voltages, temperatures, fans, including limits, and if possible fan speed control.) Vendors would implement that interface in their BIOSes, and OSes would simply need one driver to support all systems out there. * ACPI could define a flag the OS would check, basically declaring whether thermal management / hardware monitoring should be handled by ACPI or by the OS on every given system. Then all we have to do is educate all drivers to check this flag and decide whether to load or not. * ACPI could offer a way to share I/O regions between AML code and OS code. Then both ACPI and native drivers could access the same device. Of course, driver code would have to be very robust (i.e. slow) because it couldn't assume _anything_ about register values and device state between accesses. But that would still be better than the current situation. Lastly, one more thought about SMBus-based hardware monitoring chips: blocking I/O access to them basically means blocking I/O access to _all_ devices connected to the SMBus. In many cases this means SPD EEPROMs, which are fun to access at run-time but we can definitely live without them. But there can be other devices on the SMBus, for example some FSC systems have a custom chip on the SMBus to handle custom function keys. If you want to let the OS drive the chip, then the best (only?) approach is to let ACPI handle the SMBus for both itself and the OS. That is, have an ACPI driver for the SMBus implementation, which must support ACPI accesses and OS accesses alike, gracefully. I'm pretty sure that ACPI _does_ define a standard SMBus API which would make writing such a driver possible... I even seem to remember that said driver did exist at some point in the past. I'm curious why it disappeared? -- Jean Delvare Suse L3
Attachment:
DSDT
Description: Binary data
