[lm-sensors] Using dme1737 to read sensor data when an ACPI

[lm-sensors] Using dme1737 to read sensor data when an ACPI

[James Mills]

All,

I am working on a project with a SCH3114.  By default, when I modprobe
dme1737, it fails with an ACPI conflict.  In the short term, I have
added "acpi_enforce_resources=lax", and the module now loads and
sensors are displayed.

However, I am concerned with the dmesg:

ACPI: resource dme1737 [io  0x0a70-0x0a71] conflicts with ACPI region
RNTR [??? 0x00000a00-0x00000a7f flags 0x52]
ACPI: This conflict may cause random problems and system instability

All we want is for the sensor data provided by this module to be
polled periodically.

Can anyone tell me what the real risk is of using this module in
conjunction with "lax" ACPI?  Is there a way to put this module in
"read-only" mode or some other mode that minimizes the potential for
system instability?

Any information is appreciated!
~james

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] Using dme1737 to read sensor data when an ACPI

[James Mills]

Does anyone have any information on my question below?  I would just
like to put my mind at ease if at all possible.  Again, I will only be
using this module to poll sensors.

Thanks!
~james

On Wed, Feb 16, 2011 at 9:31 AM, James Mills <jameswmills@gmail.com> wrote:
> All,
>
> I am working on a project with a SCH3114.  By default, when I modprobe
> dme1737, it fails with an ACPI conflict.  In the short term, I have
> added "acpi_enforce_resources=lax", and the module now loads and
> sensors are displayed.
>
> However, I am concerned with the dmesg:
>
> ACPI: resource dme1737 [io  0x0a70-0x0a71] conflicts with ACPI region
> RNTR [??? 0x00000a00-0x00000a7f flags 0x52]
> ACPI: This conflict may cause random problems and system instability
>
> All we want is for the sensor data provided by this module to be
> polled periodically.
>
> Can anyone tell me what the real risk is of using this module in
> conjunction with "lax" ACPI?  Is there a way to put this module in
> "read-only" mode or some other mode that minimizes the potential for
> system instability?
>
> Any information is appreciated!
> ~james
>



-- 
you've gotta live light enough to see the humor
and long enough to see some change
~ Ani DiFranco

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] Using dme1737 to read sensor data when an ACPI

[Guenter Roeck]

On Mon, Feb 21, 2011 at 01:30:31PM -0500, James Mills wrote:
> Does anyone have any information on my question below?  I would just
> like to put my mind at ease if at all possible.  Again, I will only be
> using this module to poll sensors.
> 
Top-posting is discouraged.

Searching for dme1737, SCH3114 and acpi on the web suggests that there can be
interference between dme1737 and acpi, and that it is not a good idea to have
both active. There were a number of discussions about this issue on this forum, 
all suggesting the same.

Not sure what else can be said.

Guenter

> Thanks!
> ~james
> 
> On Wed, Feb 16, 2011 at 9:31 AM, James Mills <jameswmills@gmail.com> wrote:
> > All,
> >
> > I am working on a project with a SCH3114.  By default, when I modprobe
> > dme1737, it fails with an ACPI conflict.  In the short term, I have
> > added "acpi_enforce_resources=lax", and the module now loads and
> > sensors are displayed.
> >
> > However, I am concerned with the dmesg:
> >
> > ACPI: resource dme1737 [io  0x0a70-0x0a71] conflicts with ACPI region
> > RNTR [??? 0x00000a00-0x00000a7f flags 0x52]
> > ACPI: This conflict may cause random problems and system instability
> >
> > All we want is for the sensor data provided by this module to be
> > polled periodically.
> >
> > Can anyone tell me what the real risk is of using this module in
> > conjunction with "lax" ACPI?  Is there a way to put this module in
> > "read-only" mode or some other mode that minimizes the potential for
> > system instability?
> >
> > Any information is appreciated!
> > ~james
> >
> 
> 
> 
> -- 
> you've gotta live light enough to see the humor
> and long enough to see some change
> ~ Ani DiFranco
> 
> _______________________________________________
> lm-sensors mailing list
> lm-sensors@lm-sensors.org
> http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] Using dme1737 to read sensor data when an

[Clemens Ladisch]

James Mills wrote:
> ACPI: resource dme1737 [io  0x0a70-0x0a71] conflicts with ACPI region RNTR [??? 0x00000a00-0x00000a7f flags 0x52]
> ACPI: This conflict may cause random problems and system instability
> 
> Can anyone tell me what the real risk is of using this module in
> conjunction with "lax" ACPI?

The BIOS has created an ACPI resource to prevent the OS from accessing
this I/O region.  Whether this is to prevent the OS from putting some
other device there, or to prevent the OS from accessing the SMBus, is
not known.

If the BIOS has any hardware monitoring function that would make it
access this chip while the computer is running, then there is danger
that the BIOS and the OS try to use it at the same time.  (This usually
happens only with laptops; the DME1737 has an automatic fan control
function that needs to be configured only once when the system is
booted.)

There are other device on the SMBus, such as the clock controller and
the RAM SPD EEPROMs, but those aren't usually accessed by the BIOS
at runtime either.

> Is there a way to put this module in "read-only" mode or some other
> mode that minimizes the potential for system instability?

No; reading data registers requires writing the index register, and
the SMBus controller cannot be shared.


Regards,
Clemens

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] Using dme1737 to read sensor data when an ACPI

[James Mills]

On Tue, Feb 22, 2011 at 1:50 AM, Clemens Ladisch <clemens@ladisch.de> wrote:
> James Mills wrote:
>> ACPI: resource dme1737 [io  0x0a70-0x0a71] conflicts with ACPI region RNTR [??? 0x00000a00-0x00000a7f flags 0x52]
>> ACPI: This conflict may cause random problems and system instability
>>
>> Can anyone tell me what the real risk is of using this module in
>> conjunction with "lax" ACPI?
>
> The BIOS has created an ACPI resource to prevent the OS from accessing
> this I/O region.  Whether this is to prevent the OS from putting some
> other device there, or to prevent the OS from accessing the SMBus, is
> not known.
>
> If the BIOS has any hardware monitoring function that would make it
> access this chip while the computer is running, then there is danger
> that the BIOS and the OS try to use it at the same time.  (This usually
> happens only with laptops; the DME1737 has an automatic fan control
> function that needs to be configured only once when the system is
> booted.)
>
> There are other device on the SMBus, such as the clock controller and
> the RAM SPD EEPROMs, but those aren't usually accessed by the BIOS
> at runtime either.
>
>> Is there a way to put this module in "read-only" mode or some other
>> mode that minimizes the potential for system instability?
>
> No; reading data registers requires writing the index register, and
> the SMBus controller cannot be shared.
>
>
> Regards,
> Clemens
>

Clemens, thanks so much for the helpful answer.

~james

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors