From: Jean Delvare <khali@linux-fr.org> To: Bjorn Helgaas <bjorn.helgaas@hp.com> Cc: Pavel Machek <pavel@ucw.cz>, Chuck Ebbert <cebbert@redhat.com>, Rudolf Marek <r.marek@assembler.cz>, linux-acpi@vger.kernel.org, linux-kernel <linux-kernel@vger.kernel.org>, lm-sensors@lm-sensors.org Subject: Re: [lm-sensors] Could the k8temp driver be interfering with ACPI? Date: Sun, 15 Apr 2007 11:41:59 +0200 [thread overview] Message-ID: <20070415114159.05026483@hyperion.delvare> (raw) In-Reply-To: <200704131459.45867.bjorn.helgaas@hp.com> Hi Bjorn, On Fri, 13 Apr 2007 14:59:45 -0600, Bjorn Helgaas wrote: > On Friday 13 April 2007 14:07, Pavel Machek wrote: > > > > ... The primary issue is the concurrent access > > > > to resources, which cause lots of trouble which are hard to investigate. > > > > If ACPI reserves the ports, then the SMBus or hardware monitoring > > > > drivers (or any other conflicting driver) will cleanly fail to load, > > > > which would be a move in the right direction. ... > > > > > > > > So, can ACPI actually reserve the ports it accesses? > > > > > > Sorry to join this discussion so late. > > > > > > ACPI tells us the resources used by devices. Today, we don't > > > reserve > > > > Problem seems to be that ACPI does _not_ tell us which ports it > > accesses from AML code. > > I think that would violate at least the spirit of the ACPI spec. > The example in section 11.6 of the ACPI 3.0 spec shows a _TMP > method that runs an EC method to read the temp, and the EC ioport > usage is correctly declared in the EC device's _CRS method. > > Of course, there are always BIOS defects. But if we could make a > case that a BIOS that doesn't declare the resources used by the AML > is defective, we could add quirks to reserve the undeclared resources. Only realistic if the list of systems needing a quirk is small. Do you think that would be the case? > > But we already found a lock we can take; AFAICT we know how to solve > > this problem. We even have two solutions, but both have drawbacks. The AML lock solution has performance issue. It could be improved with a better semaphore primitive, but that needs to be implemented first. It also requires to modify all drivers ACPI might conflict with, and that's a rather long list. Rudolf Marek's port forwarding idea should perform better, and might also be useful for other problems than ACPI vs. regular drivers, however it makes resources bigger, and requires to modify the same long list of drivers, and with specific code for every driver. I'm not sure that it will be possible for all driver in practice, as this more or less requires to forecast the I/O access pattern of ACPI. > This might solve it, but doesn't seem like a clean way to do it. > I don't like the idea of sharing a lock between drivers and ACPI. > k8temp happens to be x86-dependent, so we'll always have ACPI, but > in principle, we could have the same problem with an arch-independent > PCI driver that only has ACPI on x86 and ia64 platforms. We can protect the additional driver code with #ifdef CONFIG_ACPI, as I did in my proof-of-concept. Not particularly elegant, granted, but it should work. If something cleaner can be done, I'm all for it. Could you please propose an implementation of your idea? It doesn't need to be perfect, but I would like to see what it would look like. > (BTW, if Chuck's problem was solved by the BIOS update, I assume > there *is* another instance of the problem that we're trying to > solve with this lock.) Yes, there are several other systems out there which are known to be affected by the problem. And probably many others where ACPI access I/O ports reserved by regular drivers and we are simply lucky that nothing bad happens. My desktop system has such a motherboard (Jetway K8M8MS). But SMP alternatives are becoming more popular, so we might start seeing more problems in practice in a near future. -- Jean Delvare
WARNING: multiple messages have this Message-ID (diff)
From: Jean Delvare <khali@linux-fr.org> To: Bjorn Helgaas <bjorn.helgaas@hp.com> Cc: Pavel Machek <pavel@ucw.cz>, Chuck Ebbert <cebbert@redhat.com>, Rudolf Marek <r.marek@assembler.cz>, linux-acpi@vger.kernel.org, linux-kernel <linux-kernel@vger.kernel.org>, lm-sensors@lm-sensors.org Subject: Re: [lm-sensors] Could the k8temp driver be interfering with ACPI? Date: Sun, 15 Apr 2007 09:41:59 +0000 [thread overview] Message-ID: <20070415114159.05026483@hyperion.delvare> (raw) In-Reply-To: <200704131459.45867.bjorn.helgaas@hp.com> Hi Bjorn, On Fri, 13 Apr 2007 14:59:45 -0600, Bjorn Helgaas wrote: > On Friday 13 April 2007 14:07, Pavel Machek wrote: > > > > ... The primary issue is the concurrent access > > > > to resources, which cause lots of trouble which are hard to investigate. > > > > If ACPI reserves the ports, then the SMBus or hardware monitoring > > > > drivers (or any other conflicting driver) will cleanly fail to load, > > > > which would be a move in the right direction. ... > > > > > > > > So, can ACPI actually reserve the ports it accesses? > > > > > > Sorry to join this discussion so late. > > > > > > ACPI tells us the resources used by devices. Today, we don't > > > reserve > > > > Problem seems to be that ACPI does _not_ tell us which ports it > > accesses from AML code. > > I think that would violate at least the spirit of the ACPI spec. > The example in section 11.6 of the ACPI 3.0 spec shows a _TMP > method that runs an EC method to read the temp, and the EC ioport > usage is correctly declared in the EC device's _CRS method. > > Of course, there are always BIOS defects. But if we could make a > case that a BIOS that doesn't declare the resources used by the AML > is defective, we could add quirks to reserve the undeclared resources. Only realistic if the list of systems needing a quirk is small. Do you think that would be the case? > > But we already found a lock we can take; AFAICT we know how to solve > > this problem. We even have two solutions, but both have drawbacks. The AML lock solution has performance issue. It could be improved with a better semaphore primitive, but that needs to be implemented first. It also requires to modify all drivers ACPI might conflict with, and that's a rather long list. Rudolf Marek's port forwarding idea should perform better, and might also be useful for other problems than ACPI vs. regular drivers, however it makes resources bigger, and requires to modify the same long list of drivers, and with specific code for every driver. I'm not sure that it will be possible for all driver in practice, as this more or less requires to forecast the I/O access pattern of ACPI. > This might solve it, but doesn't seem like a clean way to do it. > I don't like the idea of sharing a lock between drivers and ACPI. > k8temp happens to be x86-dependent, so we'll always have ACPI, but > in principle, we could have the same problem with an arch-independent > PCI driver that only has ACPI on x86 and ia64 platforms. We can protect the additional driver code with #ifdef CONFIG_ACPI, as I did in my proof-of-concept. Not particularly elegant, granted, but it should work. If something cleaner can be done, I'm all for it. Could you please propose an implementation of your idea? It doesn't need to be perfect, but I would like to see what it would look like. > (BTW, if Chuck's problem was solved by the BIOS update, I assume > there *is* another instance of the problem that we're trying to > solve with this lock.) Yes, there are several other systems out there which are known to be affected by the problem. And probably many others where ACPI access I/O ports reserved by regular drivers and we are simply lucky that nothing bad happens. My desktop system has such a motherboard (Jetway K8M8MS). But SMP alternatives are becoming more popular, so we might start seeing more problems in practice in a near future. -- Jean Delvare _______________________________________________ lm-sensors mailing list lm-sensors@lm-sensors.org http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
next prev parent reply other threads:[~2007-04-15 9:42 UTC|newest] Thread overview: 220+ messages / expand[flat|nested] mbox.gz Atom feed top 2007-02-16 17:31 Could the k8temp driver be interfering with ACPI? Chuck Ebbert 2007-02-16 17:31 ` [lm-sensors] " Chuck Ebbert 2007-02-16 17:57 ` Len Brown 2007-02-16 17:57 ` [lm-sensors] " Len Brown 2007-02-16 18:14 ` Chuck Ebbert 2007-02-16 18:14 ` [lm-sensors] " Chuck Ebbert 2007-02-16 19:59 ` Andi Kleen 2007-02-16 19:59 ` [lm-sensors] " Andi Kleen 2007-02-16 19:31 ` Chuck Ebbert 2007-02-16 19:31 ` [lm-sensors] " Chuck Ebbert 2007-02-18 17:32 ` Jean Delvare 2007-02-18 17:32 ` Jean Delvare 2007-02-18 23:22 ` Andi Kleen 2007-02-18 23:22 ` Andi Kleen 2007-02-17 10:49 ` Rudolf Marek 2007-02-17 10:49 ` [lm-sensors] " Rudolf Marek 2007-02-17 10:49 ` Rudolf Marek 2007-02-17 18:14 ` Chuck Ebbert 2007-02-17 18:14 ` Chuck Ebbert 2007-02-18 17:38 ` Jean Delvare 2007-02-18 17:38 ` Jean Delvare 2007-02-20 15:18 ` Matthew Garrett 2007-02-20 15:18 ` Matthew Garrett 2007-02-20 15:33 ` Luca Tettamanti 2007-02-20 15:33 ` Luca Tettamanti 2007-02-21 14:59 ` Jean Delvare 2007-02-21 14:59 ` Jean Delvare 2007-02-21 15:07 ` Jean Delvare 2007-02-21 15:07 ` Jean Delvare 2007-02-28 21:38 ` Pavel Machek 2007-02-28 21:38 ` Pavel Machek 2007-03-01 14:26 ` Jean Delvare 2007-03-01 14:26 ` [lm-sensors] " Jean Delvare 2007-03-01 14:26 ` Jean Delvare 2007-03-01 17:48 ` Dave Jones 2007-03-01 17:48 ` Dave Jones 2007-03-02 11:27 ` Jean Delvare 2007-03-02 11:27 ` Jean Delvare 2007-03-02 11:31 ` Pavel Machek 2007-03-02 11:31 ` Pavel Machek 2007-03-02 13:37 ` Jean Delvare 2007-03-02 13:37 ` Jean Delvare 2007-03-02 13:47 ` Henrique de Moraes Holschuh 2007-03-02 13:47 ` Henrique de Moraes Holschuh 2007-03-02 13:57 ` Pavel Machek 2007-03-02 13:57 ` Pavel Machek 2007-03-03 6:44 ` Jean Delvare 2007-03-03 6:44 ` Jean Delvare 2007-03-02 11:40 ` Pavel Machek 2007-03-02 11:40 ` Pavel Machek 2007-03-02 11:47 ` Matthew Garrett 2007-03-02 11:47 ` Matthew Garrett 2007-03-02 13:58 ` Pavel Machek 2007-03-02 13:58 ` Pavel Machek 2007-03-02 21:00 ` Jean Delvare 2007-03-02 21:00 ` Jean Delvare 2007-03-02 21:22 ` Henrique de Moraes Holschuh 2007-03-02 21:22 ` Henrique de Moraes Holschuh 2007-04-01 15:39 ` Pavel Machek 2007-04-01 15:39 ` Pavel Machek 2007-04-02 15:48 ` Jean Delvare 2007-04-02 15:48 ` [lm-sensors] " Jean Delvare 2007-04-02 19:22 ` Dave Jones 2007-04-02 19:22 ` [lm-sensors] " Dave Jones 2007-04-03 5:49 ` Jean Delvare 2007-04-03 5:49 ` [lm-sensors] " Jean Delvare 2007-04-02 20:55 ` Moore, Robert 2007-04-02 20:55 ` [lm-sensors] " Moore, Robert 2007-04-02 20:55 ` Moore, Robert 2007-04-03 7:21 ` Jean Delvare 2007-04-03 7:21 ` [lm-sensors] " Jean Delvare 2007-04-03 7:21 ` Jean Delvare 2007-04-04 21:35 ` Moore, Robert 2007-04-04 21:35 ` [lm-sensors] " Moore, Robert 2007-04-04 21:35 ` Moore, Robert 2007-03-02 14:10 ` [lm-sensors] " Jean Delvare 2007-03-02 14:10 ` Jean Delvare 2007-03-02 14:18 ` Matthew Garrett 2007-03-02 14:18 ` Matthew Garrett 2007-03-02 21:04 ` Jean Delvare 2007-03-02 21:04 ` Jean Delvare 2007-03-02 21:12 ` Matthew Garrett 2007-03-02 21:12 ` Matthew Garrett 2007-03-03 9:53 ` Jean Delvare 2007-03-03 9:53 ` Jean Delvare 2007-03-03 15:47 ` David Hubbard 2007-03-03 15:47 ` David Hubbard 2007-03-03 15:50 ` Matthew Garrett 2007-03-03 15:50 ` Matthew Garrett 2007-03-03 17:08 ` Rudolf Marek 2007-03-03 17:08 ` Rudolf Marek 2007-03-04 17:29 ` Rudolf Marek 2007-03-04 17:29 ` Rudolf Marek 2007-03-05 21:16 ` Jean Delvare 2007-03-05 21:16 ` Jean Delvare 2007-03-05 21:35 ` David Hubbard 2007-03-05 21:35 ` David Hubbard 2007-03-06 15:10 ` Jean Delvare 2007-03-06 15:10 ` Jean Delvare 2007-03-04 10:54 ` Jean Delvare 2007-03-04 10:54 ` Jean Delvare 2007-03-05 22:25 ` Pavel Machek 2007-03-05 22:25 ` Pavel Machek 2007-03-06 7:55 ` Benny Amorsen 2007-03-06 7:55 ` Benny Amorsen 2007-03-06 15:26 ` Jean Delvare 2007-03-06 15:26 ` Jean Delvare 2007-03-06 20:07 ` Stefan Monnier 2007-03-06 20:07 ` Stefan Monnier 2007-03-06 20:07 ` Stefan Monnier 2007-03-06 21:20 ` Pavel Machek 2007-03-06 21:20 ` Pavel Machek 2007-03-06 21:25 ` Moore, Robert 2007-03-06 21:25 ` Moore, Robert 2007-03-06 21:25 ` Moore, Robert 2007-03-18 19:36 ` richardvoigt 2007-03-18 19:36 ` richardvoigt at gmail.com 2007-03-19 7:08 ` Jean Delvare 2007-03-19 7:08 ` Jean Delvare 2007-03-02 22:07 ` Moore, Robert 2007-03-02 22:07 ` Moore, Robert 2007-03-02 22:07 ` Moore, Robert 2007-03-09 7:18 ` Pavel Machek 2007-03-09 7:18 ` Pavel Machek 2007-03-09 10:24 ` Jean Delvare 2007-03-09 10:24 ` Jean Delvare 2007-03-09 10:39 ` Alexey Starikovskiy 2007-03-09 10:39 ` Alexey Starikovskiy 2007-03-09 11:21 ` Pavel Machek 2007-03-09 11:21 ` Pavel Machek 2007-03-09 17:23 ` Jean Delvare 2007-03-09 17:23 ` Jean Delvare 2007-03-09 17:35 ` Alexey Starikovskiy 2007-03-09 17:35 ` Alexey Starikovskiy 2007-03-09 21:03 ` Moore, Robert 2007-03-09 21:03 ` Moore, Robert 2007-03-09 21:03 ` Moore, Robert 2007-03-09 20:56 ` Moore, Robert 2007-03-09 20:56 ` Moore, Robert 2007-03-09 20:56 ` Moore, Robert 2007-03-02 14:22 ` Pavel Machek 2007-03-02 14:22 ` Pavel Machek 2007-03-02 14:03 ` Jean Delvare 2007-03-02 14:03 ` Jean Delvare 2007-03-02 14:24 ` Pavel Machek 2007-03-02 14:24 ` Pavel Machek 2007-03-02 14:57 ` Matthew Garrett 2007-03-02 14:57 ` Matthew Garrett 2007-03-02 21:41 ` Jean Delvare 2007-03-02 21:41 ` Jean Delvare 2007-03-02 21:46 ` Matthew Garrett 2007-03-02 21:46 ` Matthew Garrett 2007-03-06 21:28 ` Jean Delvare 2007-03-06 21:28 ` Jean Delvare 2007-04-13 18:18 ` Bjorn Helgaas 2007-04-13 18:18 ` Bjorn Helgaas 2007-04-13 20:07 ` Pavel Machek 2007-04-13 20:07 ` Pavel Machek 2007-04-13 20:59 ` Bjorn Helgaas 2007-04-13 20:59 ` Bjorn Helgaas 2007-04-15 9:41 ` Jean Delvare [this message] 2007-04-15 9:41 ` Jean Delvare 2007-04-15 20:31 ` Bjorn Helgaas 2007-04-15 20:31 ` Bjorn Helgaas 2007-04-15 20:59 ` Luca Tettamanti 2007-04-15 20:59 ` Luca Tettamanti 2007-04-16 0:57 ` Bjorn Helgaas 2007-04-16 0:57 ` Bjorn Helgaas 2007-04-16 21:14 ` Luca Tettamanti 2007-04-16 21:14 ` Luca Tettamanti 2007-04-16 22:28 ` Bjorn Helgaas 2007-04-16 22:28 ` Bjorn Helgaas 2007-04-17 23:50 ` Luca Tettamanti 2007-04-17 23:50 ` Luca Tettamanti 2007-04-22 16:55 ` Luca Tettamanti 2007-04-22 16:55 ` Luca Tettamanti 2007-04-17 10:03 ` Jean Delvare 2007-04-17 10:03 ` Jean Delvare 2007-02-18 22:43 ` Rudolf Marek 2007-02-18 22:43 ` Rudolf Marek 2007-02-20 15:08 ` Chuck Ebbert 2007-02-20 15:08 ` Chuck Ebbert 2007-02-20 19:11 ` Dave Jones 2007-02-20 19:11 ` Dave Jones 2007-02-21 16:17 ` Jean Delvare 2007-02-21 16:17 ` Jean Delvare 2007-02-21 17:37 ` Dave Jones 2007-02-21 17:37 ` Dave Jones 2007-02-21 20:19 ` Dave Jones 2007-02-21 20:19 ` Dave Jones 2007-02-22 16:37 ` Jean Delvare 2007-02-22 16:37 ` Jean Delvare 2007-02-23 7:13 ` Hans de Goede 2007-02-23 7:13 ` [lm-sensors] " Hans de Goede 2007-02-23 7:13 ` Hans de Goede 2007-02-23 7:47 ` Jean Delvare 2007-02-23 7:47 ` Jean Delvare 2007-02-21 14:54 ` Jean Delvare 2007-02-21 14:54 ` Jean Delvare 2007-02-21 16:03 ` Chuck Ebbert 2007-02-21 16:03 ` Chuck Ebbert 2007-02-21 16:22 ` Jean Delvare 2007-02-21 16:22 ` Jean Delvare 2007-02-23 8:08 ` Hans de Goede 2007-02-26 17:24 ` Jean Delvare 2007-02-26 19:03 ` Hans de Goede 2007-02-27 8:45 ` Jean Delvare [not found] <7PvLN-1cj-3@gated-at.bofh.it> [not found] ` <7TEGV-6Jy-39@gated-at.bofh.it> [not found] ` <7TUBX-6TN-5@gated-at.bofh.it> [not found] ` <7UeqX-4QO-17@gated-at.bofh.it> [not found] ` <7UeqZ-4QO-27@gated-at.bofh.it> [not found] ` <7UgM5-np-1@gated-at.bofh.it> [not found] ` <7UgM8-np-11@gated-at.bofh.it> [not found] ` <7UnaS-2xP-9@gated-at.bofh.it> [not found] ` <7UnkC-2JB-9@gated-at.bofh.it> [not found] ` <7Uzcd-49u-3@gated-at.bofh.it> [not found] ` <7UEEN-4xi-3@gated-at.bofh.it> 2007-03-05 13:56 ` Bodo Eggert 2007-03-05 13:56 ` Bodo Eggert 2007-03-05 13:56 ` Bodo Eggert 2007-03-06 15:19 ` Jean Delvare 2007-03-06 15:19 ` Jean Delvare 2007-03-06 20:40 ` Bodo Eggert 2007-03-06 20:40 ` Bodo Eggert 2007-03-07 9:17 ` Jean Delvare 2007-03-07 9:17 ` Jean Delvare 2007-03-07 9:36 ` Pavel Machek 2007-03-07 9:36 ` Pavel Machek 2007-03-07 17:09 ` Bodo Eggert 2007-03-07 17:09 ` Bodo Eggert
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20070415114159.05026483@hyperion.delvare \ --to=khali@linux-fr.org \ --cc=bjorn.helgaas@hp.com \ --cc=cebbert@redhat.com \ --cc=linux-acpi@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=lm-sensors@lm-sensors.org \ --cc=pavel@ucw.cz \ --cc=r.marek@assembler.cz \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.