Il Wed, Apr 18, 2007 at 01:50:29AM +0200, Luca Tettamanti ha scritto:
I'm sure you've seen these:
http://lists.lm-sensors.org/pipermail/lm-sensors/2005-October/014050.html
http://www.lm-sensors.org/wiki/AsusFormulaHacking
Actually I haven't, I've happily ignored ACPI until now ;-) My
Hi Bjorn, Luca,
On Mon, 16 Apr 2007 23:14:11 +0200, Luca Tettamanti wrote:
Il Sun, Apr 15, 2007 at 06:57:02PM -0600, Bjorn Helgaas ha scritto:
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.
On 4/17/07, Bjorn Helgaas [EMAIL PROTECTED] wrote:
On Monday 16 April 2007 15:14, Luca Tettamanti wrote:
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
On Monday 16 April 2007 15:14, Luca Tettamanti wrote:
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
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
On 4/15/07, Bjorn Helgaas [EMAIL PROTECTED] wrote:
On Sunday 15 April 2007 03:41, Jean Delvare wrote:
On Fri, 13 Apr 2007 14:59:45 -0600, Bjorn Helgaas wrote:
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
On Sunday 15 April 2007 14:59, Luca Tettamanti wrote:
On 4/15/07, Bjorn Helgaas [EMAIL PROTECTED] 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
On Friday 02 March 2007 07:03, Jean Delvare 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
Hi!
... 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
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
Hi!
Actually for the acpi stuff... we might wrap ACPI interpretter with a
semaphore that needs to be taken before starting any AML code. Then
just make sure sensors take same semaphore?
I like the idea, it should work as long as we are guaranteed that all
the hwmon device accesses
Hi Richard,
On Sun, 18 Mar 2007 14:36:08 -0500, Richard Voigt wrote:
On 3/3/07, Jean Delvare wrote:
On Fri, 2 Mar 2007 21:12:51 +, Matthew Garrett wrote:
Assuming arbitration of access, what's the problem with having two
drivers accessing the same hardware? Do these chips generally
On 3/3/07, Jean Delvare [EMAIL PROTECTED] wrote:
Hi Matthew,
On Fri, 2 Mar 2007 21:12:51 +, Matthew Garrett wrote:
On Fri, Mar 02, 2007 at 10:04:54PM +0100, Jean Delvare wrote:
It might be more elegant but it won't work. We don't want to prevent
ACPI from accessing these I/O ports. If
On Fri, 9 Mar 2007 07:18:56 +, Pavel Machek wrote:
Port (and memory) addresses can be dynamically generated by the AML code
and thus, there is no way that the ACPI subsystem can statically predict
any addresses that will be accessed by the AML.
Can you take this as a wishlist item?
Jean Delvare wrote:
On Fri, 9 Mar 2007 07:18:56 +, Pavel Machek wrote:
Port (and memory) addresses can be dynamically generated by the AML code
and thus, there is no way that the ACPI subsystem can statically predict
any addresses that will be accessed by the AML.
Can you take
Hi!
Can you take this as a wishlist item?
It would be nice if next version of acpi specs supported table
'AML / SMM BIOS will access these ports'
...so we can get it correct with acpi4 or something..?
I can only second Pavel's wish here. This would be highly convenient
for OS
Hi Alexey,
On Fri, 09 Mar 2007 13:39:33 +0300, Alexey Starikovskiy wrote:
Jean Delvare wrote:
I can only second Pavel's wish here. This would be highly convenient
for OS developers to at least know which resources are accessed by AML
and SMM. Without this information, we can never be sure
Jean Delvare wrote:
Hi Alexey,
On Fri, 09 Mar 2007 13:39:33 +0300, Alexey Starikovskiy wrote:
Jean Delvare wrote:
I can only second Pavel's wish here. This would be highly convenient
for OS developers to at least know which resources are accessed by AML
and SMM. Without this
Included the Intel ACPI spec representative.
I have heard that Windows is somehow restricting the ports and memory
locations that are accessible via AML; I don't know any of the details.
Also, there are fears of an AML virus attacking the machine.
Bob
-Original Message-
From: Pavel
No ACPI discussion can be complete without mentioning Microsoft and
Microsoft compatibility -- Windows does not fully support ACPI 2.0 to
this day, even though it was released in the year 2000, and ACPI 3.0 has
been out since 2004.
-Original Message-
From: Alexey Starikovskiy
Hi!
Port (and memory) addresses can be dynamically generated by the AML code
and thus, there is no way that the ACPI subsystem can statically predict
any addresses that will be accessed by the AML.
Can you take this as a wishlist item?
It would be nice if next version of acpi specs supported
Hi Bodo,
On Tue, 6 Mar 2007 21:40:19 +0100 (CET), Bodo Eggert wrote:
On Tue, 6 Mar 2007, Jean Delvare wrote:
On Mon, 05 Mar 2007 14:56:44 +0100, Bodo Eggert wrote:
2) make ACPI take this lock whenever it touches ports not allocated by
itself
and release it on function return.
Hi!
2) make ACPI take this lock whenever it touches ports not allocated by
itself
and release it on function return.
This is costly.
TANSTAAFL. You'll need to take some lock, and if you want port emulation
or per-device-mutex, you'll have to pay the price.
True,
On Wed, 7 Mar 2007, Jean Delvare wrote:
On Tue, 6 Mar 2007 21:40:19 +0100 (CET), Bodo Eggert wrote:
1) I asume port allocations or ACPI foreign port acces to be rare, so
there would be little impact on (un)registering hardware. Off cause
there are some long ACPI calls (like reading
PM == Pavel Machek [EMAIL PROTECTED] writes:
PM ACPI AML is probably turing-complete: I'm afraid you are trying to
PM solve the halting problem (- impossible).
If you can restrict the virtual machine which AML runs in to a limited
amount of memory/storage, you can solve halting for it in
Hi David,
On Mon, 5 Mar 2007 13:35:20 -0800, David Hubbard wrote:
2* It seems to incur a signficant performance penalty.
request_resource isn't cheap as far as I know. And in the
absence of conflict, you are even allocating and releasing the resource
on _each_ I/O operation, which
Hi Bodo,
On Mon, 05 Mar 2007 14:56:44 +0100, Bodo Eggert wrote:
1) Make a general resource allocation lock, if there is none.
Such a lock certainly exists, but I doubt it is public at the moment.
2) make ACPI take this lock whenever it touches ports not allocated by itself
and release it
Hi Pavel,
On Mon, 5 Mar 2007 22:25:48 +, Pavel Machek wrote:
Is there anything preventing us from doing such a walk and pre-allocate
all the I/O ranges? I am not familiar with the ACPI code at all, would
you possibly propose a patch doing that?
ACPI AML is probably turing-complete:
Is there anything preventing us from doing such a walk and pre-allocate
all the I/O ranges? I am not familiar with the ACPI code at all, would
you possibly propose a patch doing that?
ACPI AML is probably turing-complete: I'm afraid you are trying to
solve the halting problem (-
On Tue, 6 Mar 2007, Jean Delvare wrote:
On Mon, 05 Mar 2007 14:56:44 +0100, Bodo Eggert wrote:
2) make ACPI take this lock whenever it touches ports not allocated by
itself
and release it on function return.
This is costly.
TANSTAAFL. You'll need to take some lock, and if you want
Hi!
Is there anything preventing us from doing such a walk and pre-allocate
all the I/O ranges? I am not familiar with the ACPI code at all, would
you possibly propose a patch doing that?
ACPI AML is probably turing-complete: I'm afraid you are trying to
solve the halting problem
In other words, as per my earlier message:
Port addresses can be dynamically generated by the AML code and thus,
there is no way that the ACPI subsystem can statically predict any
addresses that will be accessed by the AML.
Bob
-Original Message-
From: [EMAIL PROTECTED]
David Hubbard [EMAIL PROTECTED] wrote:
For I/O and memory that ACPI accesses and has not reserved, the AML
interpreter could allocate at run-time.
I'm not sure how to implement exactly. For example, it would be bad to
have a /proc/ioports that had a lot of single ports allocated, for
Hi Rudolf,
On Sun, 04 Mar 2007 18:29:12 +0100, Rudolf Marek wrote:
I produced some code which I proposed in mail above. The patch is not for
review
it is just a PoC to better show what I'm trying to do. It is a test case for
my
motherboard which has W83627EHF chip and ACPI thermal method
Hi Jean, Rudolf,
1* It requires that we modify each driver individually. It's quite a
shame that we have to update drivers all around the kernel tree with
specific code to workaround a problem which is originally located in a
single place (the ACPI subsystem.) That being said this isn't a
Hi!
Why would we end up with an overestimation if we check the I/O ports at
boot time? Do you have concrete cases in mind?
ACPI will often describe large operation regions, but won't necessarily
touch all of them. Effectively, every codepath would have to be walked
through at
Hi David,
On Sat, 3 Mar 2007 08:47:21 -0700, David Hubbard wrote:
Is there anything preventing us from doing such a walk and pre-allocate
all the I/O ranges? I am not familiar with the ACPI code at all, would
you possibly propose a patch doing that?
Here's a random idea -- what do you
Hello again,
I produced some code which I proposed in mail above. The patch is not for review
it is just a PoC to better show what I'm trying to do. It is a test case for my
motherboard which has W83627EHF chip and ACPI thermal method and w83627ehf
compete the device.
When no driver is loaded,
Hi Matthew,
On Fri, 2 Mar 2007 21:12:51 +, Matthew Garrett wrote:
On Fri, Mar 02, 2007 at 10:04:54PM +0100, Jean Delvare wrote:
It might be more elegant but it won't work. We don't want to prevent
ACPI from accessing these I/O ports. If we need to choose only one
driver accessing the
Hi Jean,
Is there anything preventing us from doing such a walk and pre-allocate
all the I/O ranges? I am not familiar with the ACPI code at all, would
you possibly propose a patch doing that?
Here's a random idea -- what do you think of it?
ACPI already allocates some I/O ranges, which was
On Sat, Mar 03, 2007 at 08:47:21AM -0700, David Hubbard wrote:
For I/O and memory that ACPI accesses and has not reserved, the AML
interpreter could allocate at run-time.
Not ideal. ACPI's already fiddling with ranges that have been reserved
by other drivers.
--
Matthew Garrett | [EMAIL
On Thu, 1 Mar 2007 12:48:06 -0500, Dave Jones wrote:
On Thu, Mar 01, 2007 at 03:26:55PM +0100, Jean Delvare wrote:
Firstly, the first records of hidden SMBus, in September 2000, predate
ACPI.
The earliest ACPI spec I have handy is 1.0b, which came out in Feb 2 1999
so this isn't true.
Hi!
Firstly, the first records of hidden SMBus, in September 2000, predate
ACPI.
The earliest ACPI spec I have handy is 1.0b, which came out in Feb 2 1999
so this isn't true. The all knowing (and always accurate :) wikipedia
claims it was first released in 1996, though I believe
Hi!
Well I had an idea after looking at k8temp -- why not make it default to
doing only reads from the sensor? You'd only get information from
whatever
core/sensor combination that ACPI had last used, but it would be safe.
ACPI is broken here, not k8temp, so let's fix
On Fri, 2 Mar 2007 12:31:58 +0100, Pavel Machek wrote:
My point (which you didn't quote) was that there is no correlation
between the SMBus being hidden and ACPI accessing the hardware
monitoring chip, contrary to what Pavel was suggesting.
It may not be correlated with ACPI, but BIOS
On Fri, 02 Mar 2007, Jean Delvare wrote:
(And as a side note, this is really the board's owner SMBus controller.
The hardware doesn't belong to the BIOS author.)
Especially when they won't do their job right, and won't fix it later
either...
--
One disk to rule them all, One disk to find
On Fri 2007-03-02 14:37:20, Jean Delvare wrote:
On Fri, 2 Mar 2007 12:31:58 +0100, Pavel Machek wrote:
My point (which you didn't quote) was that there is no correlation
between the SMBus being hidden and ACPI accessing the hardware
monitoring chip, contrary to what Pavel was suggesting.
On Fri 2007-03-02 11:47:47, Matthew Garrett wrote:
On Fri, Mar 02, 2007 at 12:40:23PM +0100, Pavel Machek wrote:
Whitelist seems like a way to go :(.
The DSDT code clearly can't touch the hardware itself - hardware access
is carried out by the kernel. If we can identify cases where ACPI
Hi Pavel,
On Fri, 2 Mar 2007 12:40:23 +0100, Pavel Machek wrote:
Ok. You are right that ACPI is an ugly piece of mess. But I'm pretty
sure that 90%+ of ACPI notebook implementations *will* want to talk to
their monitoring chips... for temperature readings.
So even if we fixed ACPI to reserve
Hi Matthew,
On Fri, 2 Mar 2007 11:47:47 +, Matthew Garrett wrote:
The DSDT code clearly can't touch the hardware itself - hardware access
is carried out by the kernel. If we can identify cases where ACPI reads
and writes would touch resources claimed by other drivers, that would be
a
On Fri, Mar 02, 2007 at 03:10:55PM +0100, Jean Delvare wrote:
I'm not familiar with APCI at all so I didn't know, but what you write
here brings some hope. Would it be possible to parse all the DSDT code
at boot time and deduce all the ports which ACPI would need to request
to be safe? Or do
Hi!
The DSDT code clearly can't touch the hardware itself - hardware access
is carried out by the kernel. If we can identify cases where ACPI reads
and writes would touch resources claimed by other drivers, that would be
a good starting point for working out what's going on.
I'm not
Hi!
Ok. You are right that ACPI is an ugly piece of mess. But I'm pretty
sure that 90%+ of ACPI notebook implementations *will* want to talk to
their monitoring chips... for temperature readings.
So even if we fixed ACPI to reserve the ports, you'd be still unhappy;
lm-sensors would
How about this? It's informational only, but ought to result in
complaints whenever ACPI tries to touch something that other hardware
has reserved. We can't fail these accesses, but in theory we could
consider some sort of locking layer that made it possible to interact
anyway. I haven't even
Hi Pavel,
On Fri, 2 Mar 2007 14:58:10 +0100, Pavel Machek wrote:
Actually for the acpi stuff... we might wrap ACPI interpretter with a
semaphore that needs to be taken before starting any AML code. Then
just make sure sensors take same semaphore?
I like the idea, it should work as long as we
On Fri, 2 Mar 2007 14:18:40 +, Matthew Garrett wrote:
On Fri, Mar 02, 2007 at 03:10:55PM +0100, Jean Delvare wrote:
I'm not familiar with APCI at all so I didn't know, but what you write
here brings some hope. Would it be possible to parse all the DSDT code
at boot time and deduce all
On Fri, Mar 02, 2007 at 10:04:54PM +0100, Jean Delvare wrote:
On Fri, 2 Mar 2007 14:18:40 +, Matthew Garrett wrote:
In theory I /think/ so, but it would probably end up being an
overestimate of the coverage actually needed. Trapping at runtime is
arguably more elegant?
It might be
On Fri, 02 Mar 2007, Jean Delvare wrote:
I like the idea, it should work as long as we are guaranteed that all
the hwmon device accesses happen in the AML code? I'm not familiar with
ACPI, so you tell me.
Some fubar machines do it in SMM mode, and the AML code just reads memory
regions that
Hi Matthew,
On Fri, 2 Mar 2007 14:57:09 +, Matthew Garrett wrote:
How about this? It's informational only, but ought to result in
complaints whenever ACPI tries to touch something that other hardware
has reserved. We can't fail these accesses, but in theory we could
consider some sort
On Fri, Mar 02, 2007 at 10:41:55PM +0100, Jean Delvare wrote:
I like the patch, after adding some casts to the printf args it
compiles fine. However you print warnings each time a resource has been
reserved... without checking if it hasn't been reserved by ACPI itself!
My machine looks like
Port (and memory) addresses can be dynamically generated by the AML code
and thus, there is no way that the ACPI subsystem can statically predict
any addresses that will be accessed by the AML.
-Original Message-
From: [EMAIL PROTECTED] [mailto:linux-acpi-
[EMAIL PROTECTED] On Behalf
On Fri, 2 Mar 2007 14:57:06 +0100, Pavel Machek wrote:
On Fri 2007-03-02 14:37:20, Jean Delvare wrote:
drivers/pci/quirks.c is full of things we do against the BIOS authors
intent. You don't plan to remove them all, do you?
Notice how quirks.c is careful to name machines where given quirk
Hi Pavel,
On Wed, 28 Feb 2007 21:38:04 +, Pavel Machek wrote:
Well I had an idea after looking at k8temp -- why not make it default to
doing only reads from the sensor? You'd only get information from
whatever
core/sensor combination that ACPI had last used, but it would be
On Thu, Mar 01, 2007 at 03:26:55PM +0100, Jean Delvare wrote:
Firstly, the first records of hidden SMBus, in September 2000, predate
ACPI.
The earliest ACPI spec I have handy is 1.0b, which came out in Feb 2 1999
so this isn't true. The all knowing (and always accurate :) wikipedia
claims it
Hi!
Well I had an idea after looking at k8temp -- why not make it default to
doing only reads from the sensor? You'd only get information from whatever
core/sensor combination that ACPI had last used, but it would be safe.
ACPI is broken here, not k8temp, so let's fix ACPI instead. ACPI
On Wed, 21 Feb 2007 15:19:44 -0500, Dave Jones wrote:
Ah, Fedora has this horror in its initscripts (which explains why I missed
it in my grep)..
# Initialize ACPI bits
if [ -d /proc/acpi ]; then
for module in /lib/modules/$unamer/kernel/drivers/acpi/* ; do
module=${module##*/}
On Fri, 23 Feb 2007 08:13:30 +0100, Hans de Goede wrote:
I'm thinking that it might be an idea to also use this idea of udev
autoloading
through DMI info for the abituguru and abituguru3 driver (review please). The
both only support about 12 motherboards. For the abituguru driver, dmi info
Jean Delvare wrote:
On Wed, 21 Feb 2007 15:19:44 -0500, Dave Jones wrote:
Ah, Fedora has this horror in its initscripts (which explains why I missed
it in my grep)..
# Initialize ACPI bits
if [ -d /proc/acpi ]; then
for module in /lib/modules/$unamer/kernel/drivers/acpi/* ; do
Hi Chuck,
On Tue, 20 Feb 2007 10:08:26 -0500, Chuck Ebbert wrote:
I blacklisted the k8temp driver (and the out-of-tree k8_edac driver
in Fedora) and the temps were still volatile, so that's not causing
it. Since then I've upgraded the system BIOS from F.06 to F.27 and
the problems _may_ have
Hi Luca,
On Tue, 20 Feb 2007 16:33:56 +0100, Luca Tettamanti wrote:
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].
Hi Matthew,
On Tue, 20 Feb 2007 15:18:13 +, Matthew Garrett 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
Jean Delvare wrote:
Can you try to load the i2c-dev driver, then run the following commands
and report the results:
$ i2cdetect -l
For each bus listed:
$ i2cdetect N
FWIW it's really an ATIIXP chipset, but supposedly PIIX4 compatible:
# i2cdetect -l
i2c-0 smbus SMBus PIIX4
On Tue, 20 Feb 2007 14:11:42 -0500, Dave Jones wrote:
On Tue, Feb 20, 2007 at 10:08:26AM -0500, Chuck Ebbert wrote:
i2c_core
i2c_ec
i2c_piix4
asus_acpi (on a Compaq???)
sbs
Something is pulling in asus_acpi as a dependancy. I've never
figured out what the
On Wed, 21 Feb 2007 11:03:07 -0500, Chuck Ebbert wrote:
Jean Delvare wrote:
Can you try to load the i2c-dev driver, then run the following commands
and report the results:
$ i2cdetect -l
For each bus listed:
$ i2cdetect N
FWIW it's really an ATIIXP chipset, but supposedly PIIX4
On Wed, Feb 21, 2007 at 05:17:37PM +0100, Jean Delvare wrote:
On Tue, 20 Feb 2007 14:11:42 -0500, Dave Jones wrote:
On Tue, Feb 20, 2007 at 10:08:26AM -0500, Chuck Ebbert wrote:
i2c_core
i2c_ec
i2c_piix4
asus_acpi (on a Compaq???)
On Wed, Feb 21, 2007 at 12:37:40PM -0500, Dave Jones wrote:
On Wed, Feb 21, 2007 at 05:17:37PM +0100, Jean Delvare wrote:
On Tue, 20 Feb 2007 14:11:42 -0500, Dave Jones wrote:
On Tue, Feb 20, 2007 at 10:08:26AM -0500, Chuck Ebbert wrote:
i2c_core
i2c_ec
Rudolf Marek wrote:
Hello all,
I got the DSDT from chuck and it seems there is nothing interesting - no
declaration of PCI_config for the registers. If someone wants to check it I
can
send him the DSDT.
_TMP looks like this:
Store (\_SB.PCI0.LPC0.EC0.RTMP, Local0)
On Tue, Feb 20, 2007 at 10:08:26AM -0500, Chuck Ebbert wrote:
i2c_core
i2c_ec
i2c_piix4
asus_acpi (on a Compaq???)
sbs
Something is pulling in asus_acpi as a dependancy. I've never
figured out what the cause is. For a long time I was thinking
that we had an
Hello all,
I got the DSDT from chuck and it seems there is nothing interesting - no
declaration of PCI_config for the registers. If someone wants to check it I can
send him the DSDT.
_TMP looks like this:
Store (\_SB.PCI0.LPC0.EC0.RTMP, Local0)
Store (Current temp is: ,
You could blacklist the ACPI thermal module instead. If you're
interested in monitoring your CPU temperature, k8temp is IMHO more
convenient to use than ACPI, as it interfaces properly with libsensors
and all hardware monitoring user interfaces.
That would be somewhat dangerous because ACPI
Hello Chuck,
I'm the author of K8temp. Please can you share with us your DSDT table?
(cat /proc/acpi/dsdt /tmp/dsdt.bin)
So, could ACPI and the k8temp driver be at odds?
Yes because ACPI AML code has no synchronization with Linux drivers. Second
reason is that ACPI AML code assign resource
Rudolf Marek wrote:
Hello Chuck,
I'm the author of K8temp. Please can you share with us your DSDT table?
(cat /proc/acpi/dsdt /tmp/dsdt.bin)
The system is Compaq Presario V2300 series notebook. I won't be able
to get the DSDT until tomorrow or Monday.
So, could ACPI and the k8temp
82 matches
Mail list logo
