From: Bjorn Helgaas <bjorn.helgaas@hp.com> To: Pavel Machek <pavel@ucw.cz> Cc: Jean Delvare <khali@linux-fr.org>, 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: Fri, 13 Apr 2007 14:59:45 -0600 [thread overview] Message-ID: <200704131459.45867.bjorn.helgaas@hp.com> (raw) In-Reply-To: <20070413200746.GD28264@elf.ucw.cz> 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. Chuck's last update (http://lkml.org/lkml/2007/2/20/136) says his problem turned out to be unrelated to k8temp and may have gone away after a BIOS update. > But we already found a lock we can take; AFAICT we know how to solve > this problem. 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. (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.) Bjorn
WARNING: multiple messages have this Message-ID (diff)
From: Bjorn Helgaas <bjorn.helgaas@hp.com> To: Pavel Machek <pavel@ucw.cz> Cc: Jean Delvare <khali@linux-fr.org>, 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: Fri, 13 Apr 2007 20:59:45 +0000 [thread overview] Message-ID: <200704131459.45867.bjorn.helgaas@hp.com> (raw) In-Reply-To: <20070413200746.GD28264@elf.ucw.cz> 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. Chuck's last update (http://lkml.org/lkml/2007/2/20/136) says his problem turned out to be unrelated to k8temp and may have gone away after a BIOS update. > But we already found a lock we can take; AFAICT we know how to solve > this problem. 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. (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.) Bjorn _______________________________________________ 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-13 20:59 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 [this message] 2007-04-13 20:59 ` Bjorn Helgaas 2007-04-15 9:41 ` Jean Delvare 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=200704131459.45867.bjorn.helgaas@hp.com \ --to=bjorn.helgaas@hp.com \ --cc=cebbert@redhat.com \ --cc=khali@linux-fr.org \ --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.