lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <68676e00702200733l6e7f13a5o201bc70fed98528b@mail.gmail.com>
Date:	Tue, 20 Feb 2007 16:33:56 +0100
From:	"Luca Tettamanti" <kronos.it@...il.com>
To:	"Matthew Garrett" <mjg59@...f.ucam.org>
Cc:	"Jean Delvare" <khali@...ux-fr.org>, linux-acpi@...r.kernel.org,
	linux-kernel <linux-kernel@...r.kernel.org>,
	"Chuck Ebbert" <cebbert@...hat.com>, lm-sensors@...sensors.org
Subject: Re: [lm-sensors] Could the k8temp driver be interfering with ACPI?

On 2/20/07, Matthew Garrett <mjg59@...f.ucam.org> wrote:
> On Sun, Feb 18, 2007 at 06:38:05PM +0100, Jean Delvare wrote:
>
> > ACPI is broken here, not k8temp, so let's fix ACPI instead. ACPI
> > doesn't conflict with only k8temp, but with virtually all hardware
> > monitoring drivers, all I2C/SMBus drivers, and probably other types of
> > drivers too. We just can't restrict or blacklist all these drivers
> > because ACPI misbehaves.
>
> No, the simple fact of the matter is that if you're running on an ACPI
> platform you need to change some of your assumptions. ACPI owns the
> hardware. The OS doesn't. To an extent this has always been true on
> laptops and servers /anyway/ - the BIOS is free to have a wide variety
> of SMM insanity that invalidates basic assumptions like "If I hold this
> lock, nothing can interrupt me between this write and this read". That's
> simply not true.
>
> So this isn't about fixing ACPI. It's about trying to find a mechanism
> that allows ACPI and raw hardware drivers to coexist, which is made
> somewhat harder by it not being a situation that the platform designers
> have considered in the slightest.

Motherboard vendors usually provide tools for $(TheOtherOS) that can
read from all thermal  / fan / voltage / whatever sensors, so I guess
it's possible to make the ACPI driver and the "raw" one play nice with
each other[1].

Luca
[1] Unless their solution is "poke at the hardware and hope that ACPI
doesn't blow up", that is.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ