From: Luca Tettamanti <kronos.it@gmail.com> To: Bjorn Helgaas <bjorn.helgaas@hp.com> Cc: Jean Delvare <khali@linux-fr.org>, Pavel Machek <pavel@ucw.cz>, linux-kernel <linux-kernel@vger.kernel.org>, lm-sensors@lm-sensors.org, linux-acpi@vger.kernel.org, Chuck Ebbert <cebbert@redhat.com> Subject: Re: [lm-sensors] Could the k8temp driver be interfering with ACPI? Date: Mon, 16 Apr 2007 23:14:11 +0200 [thread overview] Message-ID: <20070416211411.GA16150@dreamland.darkstar.lan> (raw) In-Reply-To: <200704151857.03115.bjorn.helgaas@hp.com> [-- Attachment #1: Type: text/plain, Size: 6102 bytes --] Il Sun, Apr 15, 2007 at 06:57:02PM -0600, Bjorn Helgaas ha scritto: > On Sunday 15 April 2007 14:59, Luca Tettamanti wrote: > > On 4/15/07, Bjorn Helgaas <bjorn.helgaas@hp.com> wrote: > > > But I missed the details, such as the specific devices in question, > > > which ports they use, how they are described in ACPI, which AML > > > methods use those ports, and which non-ACPI drivers also use them. > > > > The original report was about the temperature sensors of K8 cpus. It > > happens that ACPI reads the sensors while the linux driver is using it > > and gets garbage (and shut down the system). The problem is more > > generic though, and applies to all hardware monitoring chips for which > > a driver exists. > > Yes, I saw that much, but that's not enough detail to craft a good > solution. > > In the case of k8temp, the driver claims PCI devices with a certain > vendor and device ID. PCI devices are mostly outside the scope of > ACPI. There's a standard enumeration protocol, and a driver should > be able to claim any device it recognizes without fear of conflict. > > I claim that an AML method that accesses a PCI device is > defective because the AML can't know whether a native driver > has claimed the device. k8temp seems a special case tough. > Sometimes the firmware can hide PCI devices so the OS > enumeration doesn't find them. In that case, AML might > be able to safely use the PCI device, but the native > driver wouldn't be able to claim the device, so there > would be no conflict. (Linux sometimes uses quirks to > "unhide" things like this, which could lead to a conflict > of our own making.) > > I suspect that other sensor drivers may just probe for devices > at "known" addresses hard-coded in the driver. Usually sensors are attached to SMBUS or available in ISA IO space. AFAIK they're not enumerated anywhere (at least I2C devices are not, you poke at various addresses and see if something responds - not sure about ISA). > This is a > problem because the ACPI model is that the OS learns about > all built-in devices via the ACPI namespace. If it isn't > in the namespace, it shouldn't exist as far as the OS is > concerned. > > So we could easily have the situation where ACPI uses a > sensor and does not expose it to the OS in the namespace. > In that case, the firmware expectation is that the OS > won't touch the device. If the OS pokes around at the > magic addresses and happens to trip over the device, we > just made ourselves a problem. > > > > It also sounds like the non-ACPI drivers provide much more > > > functionality than ACPI exposes. I'd like to understand this, > > > too, because an obvious way to solve the problem would be to > > > drop the non-ACPI drivers. > > > > Problem is that ACPI may access the sensors anyway (e.g. via SMM). > > If ACPI accesses sensors but there is no native driver, there > should be no conflict. Of course. But we do have native drivers ;-) > > > Is this extra functionality available > > > on Windows? If so, do we know whether Windows uses non-ACPI drivers > > > or whether they have some smarter way to use ACPI? > > > > Usually ACPI exposes 1 or 2 temperature readings (CPU and > > motherboard), while the hw driver can also provide fans and voltages > > measurements. > > > > Vendors usually provides a monitoring utility for Win that also > > exposes these information. It's not known whether there's a way to > > avoid conflicting accesses between ACPI and the raw driver; it's > > possible that it's vendor-specific and not documented. > > I'd be surprised if Windows provided interfaces to coordinate > between two drivers. My impression is that they really want > to have a single owner for a piece of hardware. It would be > interesting to figure out how these monitoring utilities work. > Maybe the monitor and the AML both go through an embedded > controller driver and coordinate that way? Hum, the utility I have here (Asus PC Probe) seems to use ACPI: Pro2.dll: [Ordinal/Name Pointer] Table [ 11] OCAPI_ACPI_OC_PresetList [ 12] OCAPI_ACPI_OC__MB_GetBoardName [ 23] OCAPI_CheckAiGear [ 0] OCAPI_CheckIntelPowerSaving [ 6] OCAPI_CheckWorkable [ 2] OCAPI_Close [ 9] OCAPI_EnableQFan [ 16] OCAPI_GENERAL_GetList [ 14] OCAPI_GetCpuVoltRange [ 13] OCAPI_GetCurrentCpuFrequency [ 15] OCAPI_GetFanStartTemp [ 3] OCAPI_GetHealthData [ 4] OCAPI_GetHwSensorData [ 22] OCAPI_GetMBIF [ 8] OCAPI_GetQFanInfo [ 5] OCAPI_HW_EnumerateOption [ 7] OCAPI_HideQFan [ 1] OCAPI_Initialization [ 19] OCAPI_NQFAN_GetData [ 21] OCAPI_NQFAN_GetList [ 20] OCAPI_NQFAN_SetData [ 17] OCAPI_QFAN_GetData [ 18] OCAPI_QFAN_SetData [ 10] OCAPI_SetQFanTarget [ 24] ___CPPdebugHook ASiO.dll: [Ordinal/Name Pointer] Table [ 1] ASIO_Close [ 9] ASIO_GetCpuID [ 3] ASIO_InPortB [ 5] ASIO_InPortD [ 7] ASIO_MapMem [ 0] ASIO_Open [ 4] ASIO_OutPortB [ 6] ASIO_OutPortD [ 10] ASIO_ReadMSR [ 8] ASIO_UnmapMem [ 11] ASIO_WriteMSR [ 2] OC_GetCurrentCpuFrequency It seems that Asus exposes monitorining data using "ATK0110" (enumerated in DSDT); I see it both on my P5B-E motherboard and on my notebook (L3D) (they have different methods though). Another motherboard with the same device may actually call it "FOOBAR123" or "WTFISTHIS". Problem is that ACPI methods are not documented at all (how am I supposed to know that "G6T6" is the reading of the 12V rail?) while the datasheet of hw monitoring chips (w83627ehf in my case) are public (more or less). Furthermore, sensor driver exposes all the reading of the chip (e.g. in the DSDT I can't find the VSB or battery voltage). I'm attacching my DSDT, in case you want to have fun ;-) Luca -- Collect some stars to shine for you And start today 'cause there's only a few A sign of times my friend [-- Attachment #2: Asus P5B-E DSDT --] [-- Type: application/octet-stream, Size: 19170 bytes --]
WARNING: multiple messages have this Message-ID (diff)
From: Luca Tettamanti <kronos.it@gmail.com> To: Bjorn Helgaas <bjorn.helgaas@hp.com> Cc: Jean Delvare <khali@linux-fr.org>, Pavel Machek <pavel@ucw.cz>, linux-kernel <linux-kernel@vger.kernel.org>, lm-sensors@lm-sensors.org, linux-acpi@vger.kernel.org, Chuck Ebbert <cebbert@redhat.com> Subject: Re: [lm-sensors] Could the k8temp driver be interfering with ACPI? Date: Mon, 16 Apr 2007 21:14:11 +0000 [thread overview] Message-ID: <20070416211411.GA16150@dreamland.darkstar.lan> (raw) In-Reply-To: <200704151857.03115.bjorn.helgaas@hp.com> [-- Attachment #1: Type: text/plain, Size: 6102 bytes --] Il Sun, Apr 15, 2007 at 06:57:02PM -0600, Bjorn Helgaas ha scritto: > On Sunday 15 April 2007 14:59, Luca Tettamanti wrote: > > On 4/15/07, Bjorn Helgaas <bjorn.helgaas@hp.com> wrote: > > > But I missed the details, such as the specific devices in question, > > > which ports they use, how they are described in ACPI, which AML > > > methods use those ports, and which non-ACPI drivers also use them. > > > > The original report was about the temperature sensors of K8 cpus. It > > happens that ACPI reads the sensors while the linux driver is using it > > and gets garbage (and shut down the system). The problem is more > > generic though, and applies to all hardware monitoring chips for which > > a driver exists. > > Yes, I saw that much, but that's not enough detail to craft a good > solution. > > In the case of k8temp, the driver claims PCI devices with a certain > vendor and device ID. PCI devices are mostly outside the scope of > ACPI. There's a standard enumeration protocol, and a driver should > be able to claim any device it recognizes without fear of conflict. > > I claim that an AML method that accesses a PCI device is > defective because the AML can't know whether a native driver > has claimed the device. k8temp seems a special case tough. > Sometimes the firmware can hide PCI devices so the OS > enumeration doesn't find them. In that case, AML might > be able to safely use the PCI device, but the native > driver wouldn't be able to claim the device, so there > would be no conflict. (Linux sometimes uses quirks to > "unhide" things like this, which could lead to a conflict > of our own making.) > > I suspect that other sensor drivers may just probe for devices > at "known" addresses hard-coded in the driver. Usually sensors are attached to SMBUS or available in ISA IO space. AFAIK they're not enumerated anywhere (at least I2C devices are not, you poke at various addresses and see if something responds - not sure about ISA). > This is a > problem because the ACPI model is that the OS learns about > all built-in devices via the ACPI namespace. If it isn't > in the namespace, it shouldn't exist as far as the OS is > concerned. > > So we could easily have the situation where ACPI uses a > sensor and does not expose it to the OS in the namespace. > In that case, the firmware expectation is that the OS > won't touch the device. If the OS pokes around at the > magic addresses and happens to trip over the device, we > just made ourselves a problem. > > > > It also sounds like the non-ACPI drivers provide much more > > > functionality than ACPI exposes. I'd like to understand this, > > > too, because an obvious way to solve the problem would be to > > > drop the non-ACPI drivers. > > > > Problem is that ACPI may access the sensors anyway (e.g. via SMM). > > If ACPI accesses sensors but there is no native driver, there > should be no conflict. Of course. But we do have native drivers ;-) > > > Is this extra functionality available > > > on Windows? If so, do we know whether Windows uses non-ACPI drivers > > > or whether they have some smarter way to use ACPI? > > > > Usually ACPI exposes 1 or 2 temperature readings (CPU and > > motherboard), while the hw driver can also provide fans and voltages > > measurements. > > > > Vendors usually provides a monitoring utility for Win that also > > exposes these information. It's not known whether there's a way to > > avoid conflicting accesses between ACPI and the raw driver; it's > > possible that it's vendor-specific and not documented. > > I'd be surprised if Windows provided interfaces to coordinate > between two drivers. My impression is that they really want > to have a single owner for a piece of hardware. It would be > interesting to figure out how these monitoring utilities work. > Maybe the monitor and the AML both go through an embedded > controller driver and coordinate that way? Hum, the utility I have here (Asus PC Probe) seems to use ACPI: Pro2.dll: [Ordinal/Name Pointer] Table [ 11] OCAPI_ACPI_OC_PresetList [ 12] OCAPI_ACPI_OC__MB_GetBoardName [ 23] OCAPI_CheckAiGear [ 0] OCAPI_CheckIntelPowerSaving [ 6] OCAPI_CheckWorkable [ 2] OCAPI_Close [ 9] OCAPI_EnableQFan [ 16] OCAPI_GENERAL_GetList [ 14] OCAPI_GetCpuVoltRange [ 13] OCAPI_GetCurrentCpuFrequency [ 15] OCAPI_GetFanStartTemp [ 3] OCAPI_GetHealthData [ 4] OCAPI_GetHwSensorData [ 22] OCAPI_GetMBIF [ 8] OCAPI_GetQFanInfo [ 5] OCAPI_HW_EnumerateOption [ 7] OCAPI_HideQFan [ 1] OCAPI_Initialization [ 19] OCAPI_NQFAN_GetData [ 21] OCAPI_NQFAN_GetList [ 20] OCAPI_NQFAN_SetData [ 17] OCAPI_QFAN_GetData [ 18] OCAPI_QFAN_SetData [ 10] OCAPI_SetQFanTarget [ 24] ___CPPdebugHook ASiO.dll: [Ordinal/Name Pointer] Table [ 1] ASIO_Close [ 9] ASIO_GetCpuID [ 3] ASIO_InPortB [ 5] ASIO_InPortD [ 7] ASIO_MapMem [ 0] ASIO_Open [ 4] ASIO_OutPortB [ 6] ASIO_OutPortD [ 10] ASIO_ReadMSR [ 8] ASIO_UnmapMem [ 11] ASIO_WriteMSR [ 2] OC_GetCurrentCpuFrequency It seems that Asus exposes monitorining data using "ATK0110" (enumerated in DSDT); I see it both on my P5B-E motherboard and on my notebook (L3D) (they have different methods though). Another motherboard with the same device may actually call it "FOOBAR123" or "WTFISTHIS". Problem is that ACPI methods are not documented at all (how am I supposed to know that "G6T6" is the reading of the 12V rail?) while the datasheet of hw monitoring chips (w83627ehf in my case) are public (more or less). Furthermore, sensor driver exposes all the reading of the chip (e.g. in the DSDT I can't find the VSB or battery voltage). I'm attacching my DSDT, in case you want to have fun ;-) Luca -- Collect some stars to shine for you And start today 'cause there's only a few A sign of times my friend [-- Attachment #2: Asus P5B-E DSDT --] [-- Type: application/octet-stream, Size: 19170 bytes --] [-- Attachment #3: Type: text/plain, Size: 153 bytes --] _______________________________________________ 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-16 21:13 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 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 [this message] 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=20070416211411.GA16150@dreamland.darkstar.lan \ --to=kronos.it@gmail.com \ --cc=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 \ /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.