To whomever is in charge of the sensors code in the kernel:
I just noted that the temperatures being reported by gkrellm, using its
internal sensors stuff, are not correct by over 100F too low when -rc6
is running. -rc5 seems to give good readings consistent with what
I've been observing for the last year, a slowly rising cpu reading due
to the zallman flower becoming dust packed, to the point of about 150F
for a normal reading.
Today, after rebooting to -rc6, I'm seeing cpu temps ranging between
39.2 and 41.7 degress F. As the room is probably around 74F, thats a
bit of a dubious reading.
Whom do I contact about this?
--
Cheers, Gene
People having trouble with vz bouncing email to me should use this
address: <[email protected]> which bypasses vz's
stupid bounce rules. I do use spamassassin too. :-)
Yahoo.com and AOL/TW attorneys please note, additions to the above
message by Gene Heskett are:
Copyright 2005 by Maurice Eugene Heskett, all rights reserved.
On Tue, Dec 20, 2005 at 03:05:43PM -0500, Gene Heskett wrote:
> To whomever is in charge of the sensors code in the kernel:
>
> I just noted that the temperatures being reported by gkrellm, using its
> internal sensors stuff, are not correct by over 100F too low when -rc6
> is running. -rc5 seems to give good readings consistent with what
> I've been observing for the last year, a slowly rising cpu reading due
> to the zallman flower becoming dust packed, to the point of about 150F
> for a normal reading.
>
> Today, after rebooting to -rc6, I'm seeing cpu temps ranging between
> 39.2 and 41.7 degress F. As the room is probably around 74F, thats a
> bit of a dubious reading.
>
> Whom do I contact about this?
As per the MAINTAINERS file:
HARDWARE MONITORING
P: Jean Delvare
M: [email protected]
L: [email protected]
W: http://www.lm-sensors.nu/
S: Maintained
Gene Heskett <[email protected]> wrote:
>
> To whomever is in charge of the sensors code in the kernel:
>
> I just noted that the temperatures being reported by gkrellm, using its
> internal sensors stuff, are not correct by over 100F too low when -rc6
> is running. -rc5 seems to give good readings consistent with what
> I've been observing for the last year, a slowly rising cpu reading due
> to the zallman flower becoming dust packed, to the point of about 150F
> for a normal reading.
>
> Today, after rebooting to -rc6, I'm seeing cpu temps ranging between
> 39.2 and 41.7 degress F. As the room is probably around 74F, thats a
> bit of a dubious reading.
>
> Whom do I contact about this?
>
Jean.
Hi Gene,
> Gene Heskett <[email protected]> wrote:
>
> > To whomever is in charge of the sensors code in the kernel:
> >
> > I just noted that the temperatures being reported by gkrellm, using its
> > internal sensors stuff, are not correct by over 100F too low when -rc6
> > is running. -rc5 seems to give good readings consistent with what
> > I've been observing for the last year, a slowly rising cpu reading due
> > to the zallman flower becoming dust packed, to the point of about 150F
> > for a normal reading.
> >
> > Today, after rebooting to -rc6, I'm seeing cpu temps ranging between
> > 39.2 and 41.7 degress F. As the room is probably around 74F, thats a
> > bit of a dubious reading.
> >
> > Whom do I contact about this?
>
> Jean.
No hwmon driver was updated between 2.6.15-rc5 and 2.6.15-rc6.
Are you getting the temperature value from ACPI, or from a hwmon
driver? If the latter, which driver is this, and which hardware
monitoring chip do you have?
--
Jean Delvare
Hi Gene,
Please keep this conversation on the LKML, where it started.
> > Are you getting the temperature value from ACPI, or from a hwmon
> > driver? If the latter, which driver is this, and which hardware
> > monitoring chip do you have?
>
> Its coming from whatever source gkrellm-2.1.28 uses as the default src
> for this, selecting other src's results in -200F or more readings.
> Rebooting back to -rc5, the readings are normal but creeping up, about
> 152F right now.
That's hardly helpful. If gkrellm doesn't tell you where the data comes
from, we just can't use it to debug any issue. Please use "sensors"
instead.
> >From sensors-detect:
> Probing for `Winbond W83627HF'
> Trying address 0x0290... Success!
> (confidence 8, driver `w83781d')
>
> What else?
This is only one part of sensors-detect. I guess it then suggests the
w83627hf driver instead. Which driver are you using, w83627hf or
w83781d?
Please provide:
1* The complete output of sensors-detect.
2* The output of "sensors" in 2.6.15-rc5.
3* The output of "sensors" in 2.6.15-rc6.
4* The diff of your 2.6.15-rc5 kernel config file and 2.6.15-rc6
kernel config file.
Thanks,
--
Jean Delvare
On Wednesday 21 December 2005 17:07, Jean Delvare wrote:
>Hi Gene,
>
>Please keep this conversation on the LKML, where it started.
>
>> > Are you getting the temperature value from ACPI, or from a hwmon
>> > driver? If the latter, which driver is this, and which hardware
>> > monitoring chip do you have?
>>
>> Its coming from whatever source gkrellm-2.1.28 uses as the default
>> src for this, selecting other src's results in -200F or more
>> readings. Rebooting back to -rc5, the readings are normal but
>> creeping up, about 152F right now.
>
>That's hardly helpful. If gkrellm doesn't tell you where the data
> comes from, we just can't use it to debug any issue. Please use
> "sensors" instead.
>
>> >From sensors-detect:
>>
>> Probing for `Winbond W83627HF'
>> Trying address 0x0290... Success!
>> (confidence 8, driver `w83781d')
>>
>> What else?
>
>This is only one part of sensors-detect. I guess it then suggests the
>w83627hf driver instead. Which driver are you using, w83627hf or
>w83781d?
>
>Please provide:
>
>1* The complete output of sensors-detect.
>
>2* The output of "sensors" in 2.6.15-rc5.
>
>3* The output of "sensors" in 2.6.15-rc6.
>
>4* The diff of your 2.6.15-rc5 kernel config file and 2.6.15-rc6
>kernel config file.
>
>Thanks,
I've sent the above info, but there is a nilmreg here someplace. I'm
currently booted to 2.6.15-rc6, and both sensors, and gkrellm are
working fine.
And, FWIW, so apparently is ntpd......
One of those things that make you go 'Hummmm'.
Uptime now about 30 minutes, no messages in the log and the toolbar
clock is staying about 4 seconds behind my watch.
Anybody got any nilmerg spray? Looks like I need a gallon. :(
--
Cheers, Gene
People having trouble with vz bouncing email to me should add the word
'online' between the 'verizon', and the dot which bypasses vz's
stupid bounce rules. I do use spamassassin too. :-)
Yahoo.com and AOL/TW attorneys please note, additions to the above
message by Gene Heskett are:
Copyright 2005 by Maurice Eugene Heskett, all rights reserved.
Hi Gene,
> > Please keep this conversation on the LKML, where it started.
How many times must I tell you?
> Next adapter: SMBus nForce2 adapter at 5100
> Do you want to scan it? (YES/no/selectively):
> Client found at address 0x08
> Client found at address 0x4e
> Probing for `National Semiconductor LM75'... Failed!
> Probing for `Dallas Semiconductor DS1621'... Failed!
> Probing for `Analog Devices ADM1021'... Failed!
> Probing for `Analog Devices ADM1021A/ADM1023'... Failed!
> Probing for `Maxim MAX1617'... Failed!
> Probing for `Maxim MAX1617A'... Failed!
> Probing for `TI THMC10'... Failed!
> Probing for `National Semiconductor LM84'... Failed!
> Probing for `Genesys Logic GL523SM'... Failed!
> Probing for `Onsemi MC1066'... Failed!
> Probing for `Maxim MAX1619'... Failed!
> Probing for `National Semiconductor LM82'... Failed!
> Probing for `National Semiconductor LM83'... Failed!
> Probing for `Maxim MAX6659'... Failed!
> Probing for `Maxim MAX6633/MAX6634/MAX6635'... Failed!
Hmm, that could be a secondary temperature sensor. Please find out
which i2c bus number is "SMBus nForce2 adapter at 5100" (using
"i2cdetect -l") then dump the chips contents ("i2cdump N 0x4e b" where
N is the i2c bus number).
Please check "lsmod" and confirm that you are using the w83627hf driver
and not the older w83781d driver.
> > 2* The output of "sensors" in 2.6.15-rc5.
> [root@coyote root]# sensors
> (...)
> w83627hf-isa-0290
> Adapter: ISA adapter
> VCore 1: +1.66 V (min = +1.57 V, max = +1.73 V)
> VCore 2: +1.79 V (min = +1.57 V, max = +1.73 V) ALARM
> +3.3V: +3.26 V (min = +3.14 V, max = +3.47 V)
> +5V: +4.87 V (min = +4.76 V, max = +5.24 V)
> +12V: +11.80 V (min = +10.82 V, max = +13.19 V)
> -12V: -12.28 V (min = -13.18 V, max = -10.80 V)
> -5V: -5.05 V (min = -5.25 V, max = -4.75 V)
> V5SB: +5.59 V (min = +4.76 V, max = +5.24 V) ALARM
> VBat: +3.15 V (min = +2.40 V, max = +3.60 V)
> fan1: 1757 RPM (min = -1 RPM, div = 16) ALARM
> fan2: 2636 RPM (min = 659 RPM, div = 16)
> fan3: 0 RPM (min = 2636 RPM, div = 16) ALARM
> temp1: -48?C (high = +0?C, hyst = +11?C) sensor =
> thermistor
> temp2: +67.5?C (high = +120?C, hyst = +115?C) sensor =
> thermistor
> temp3: +127.5?C (high = +120?C, hyst = +115?C) sensor =
> PII/Celeron diode ALARM
> vid: +1.650 V
> alarms:
> beep_enable:
> Sound alarm enabled
>
> > 3* The output of "sensors" in 2.6.15-rc6.
> (...)
> w83627hf-isa-0290
> Adapter: ISA adapter
> VCore 1: +1.68 V (min = +1.57 V, max = +1.73 V)
> VCore 2: +1.79 V (min = +1.57 V, max = +1.73 V) ALARM
> +3.3V: +3.30 V (min = +3.14 V, max = +3.47 V)
> +5V: +4.87 V (min = +4.76 V, max = +5.24 V)
> +12V: +11.86 V (min = +10.82 V, max = +13.19 V)
> -12V: -12.28 V (min = -13.18 V, max = -10.80 V)
> -5V: -5.00 V (min = -5.25 V, max = -4.75 V)
> V5SB: +5.62 V (min = +4.76 V, max = +5.24 V) ALARM
> VBat: +3.14 V (min = +2.40 V, max = +3.60 V)
> fan1: 1721 RPM (min = -1 RPM, div = 16) ALARM
> fan2: 2636 RPM (min = 659 RPM, div = 16)
> fan3: 0 RPM (min = 2636 RPM, div = 16) ALARM
> temp1: -48?C (high = +0?C, hyst = +11?C) sensor =
> thermistor
> temp2: +63.0?C (high = +120?C, hyst = +115?C) sensor =
> thermistor
> temp3: +127.5?C (high = +120?C, hyst = +115?C) sensor =
> PII/Celeron diode ALARM
> vid: +1.650 V
> alarms:
> beep_enable:
> Sound alarm enabled
>
> Humm, not a heck of a lot of diff to the sensors output. temp1 is shut
> off in gkrellm anyway. Is temp3 the cpu? This is an Athon XP-2800
> stepping 00 cpu.
Obvsiouly not, else your computer would be on fire. The CPU temp would
be temp2, although it's quite high especially for a thermistor-based
measurement (which is usually taken from the socket rather than the CPU
itself). And it matches what gkrellm tells you in -rc5 (65 degrees C is
149 degrees F).
temp1 and temp3 are either nor wired, or use a different sensor type
than the one currently setup. You may try changing the sensor type and
see if it brings interesting readings (like built-in CPU diode or
motherboard sensor).
And actually there is very little difference between both outputs -
I expected this as the driver did not change between -rc5 and -rc6.
So the problem seems to be that gkrellm fails to pick the proper
temperature input in -rc6. Why, I have no idea. But as long as
"sensors" work, the bug has to be in gkrellm rather than the kernel
driver.
See if you have anything under /proc/acpi/thermal_zone. Maybe gkrellm
picks the temperature from ACPI in -rc6 for whatever reason.
--
Jean Delvare
On Wednesday 21 December 2005 18:00, Jean Delvare wrote:
>Hi Gene,
>
>> > Please keep this conversation on the LKML, where it started.
>
>How many times must I tell you?
Using reply all, it shows up in the inbox first?
And, running 2.6.15-rc6 for the third time, its all working!
And I asked for some nilmerg spray earlier, this thing has a few of
those. :(
>> Next adapter: SMBus nForce2 adapter at 5100
>> Do you want to scan it? (YES/no/selectively):
>> Client found at address 0x08
>> Client found at address 0x4e
>> Probing for `National Semiconductor LM75'... Failed!
>> Probing for `Dallas Semiconductor DS1621'... Failed!
>> Probing for `Analog Devices ADM1021'... Failed!
>> Probing for `Analog Devices ADM1021A/ADM1023'... Failed!
>> Probing for `Maxim MAX1617'... Failed!
>> Probing for `Maxim MAX1617A'... Failed!
>> Probing for `TI THMC10'... Failed!
>> Probing for `National Semiconductor LM84'... Failed!
>> Probing for `Genesys Logic GL523SM'... Failed!
>> Probing for `Onsemi MC1066'... Failed!
>> Probing for `Maxim MAX1619'... Failed!
>> Probing for `National Semiconductor LM82'... Failed!
>> Probing for `National Semiconductor LM83'... Failed!
>> Probing for `Maxim MAX6659'... Failed!
>> Probing for `Maxim MAX6633/MAX6634/MAX6635'... Failed!
>
>Hmm, that could be a secondary temperature sensor. Please find out
>which i2c bus number is "SMBus nForce2 adapter at 5100" (using
>"-i2cdetect l") then dump the chips contents ("i2cdump N 0x4e b"
> where N is the i2c bus number).
Next adapter: SMBus nForce2 adapter at 5100
Do you want to scan it? (YES/no/selectively):
Client found at address 0x08
Client found at address 0x4e
Probing for `National Semiconductor LM75'... Failed!
Probing for `Dallas Semiconductor DS1621'... Failed!
Probing for `Analog Devices ADM1021'... Failed!
Probing for `Analog Devices ADM1021A/ADM1023'... Failed!
Probing for `Maxim MAX1617'... Failed!
Probing for `Maxim MAX1617A'... Failed!
Probing for `TI THMC10'... Failed!
Probing for `National Semiconductor LM84'... Failed!
Probing for `Genesys Logic GL523SM'... Failed!
Probing for `Onsemi MC1066'... Failed!
Probing for `Maxim MAX1619'... Failed!
Probing for `National Semiconductor LM82'... Failed!
Probing for `National Semiconductor LM83'... Failed!
Probing for `Maxim MAX6659'... Failed!
Probing for `Maxim MAX6633/MAX6634/MAX6635'... Failed!
[root@coyote root]# i2cdump 1 0x4e b
WARNING! This program can confuse your I2C bus, cause data loss and
worse!
I will probe file /dev/i2c-1, address 0x4e, mode byte
Continue? [Y/n] y
0 1 2 3 4 5 6 7 8 9 a b c d e f 0123456789abcdef
00: 00 08 33 33 03 80 01 00 00 00 ff 00 00 00 00 00 .?33???.........
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
>
>Please check "lsmod" and confirm that you are using the w83627hf
> driver and not the older w83781d driver.
I am useing w83627hf
>
>> > 2* The output of "sensors" in 2.6.15-rc5.
>>
>> [root@coyote root]# sensors
>> (...)
>> w83627hf-isa-0290
>> Adapter: ISA adapter
>> VCore 1: +1.66 V (min = +1.57 V, max = +1.73 V)
>> VCore 2: +1.79 V (min = +1.57 V, max = +1.73 V) ALARM
>> +3.3V: +3.26 V (min = +3.14 V, max = +3.47 V)
>> +5V: +4.87 V (min = +4.76 V, max = +5.24 V)
>> +12V: +11.80 V (min = +10.82 V, max = +13.19 V)
>> -12V: -12.28 V (min = -13.18 V, max = -10.80 V)
>> -5V: -5.05 V (min = -5.25 V, max = -4.75 V)
>> V5SB: +5.59 V (min = +4.76 V, max = +5.24 V) ALARM
>> VBat: +3.15 V (min = +2.40 V, max = +3.60 V)
>> fan1: 1757 RPM (min = -1 RPM, div = 16) ALARM
>> fan2: 2636 RPM (min = 659 RPM, div = 16)
>> fan3: 0 RPM (min = 2636 RPM, div = 16) ALARM
>> temp1: -48?C (high = +0?C, hyst = +11?C) sensor =
>> thermistor
>> temp2: +67.5?C (high = +120?C, hyst = +115?C) sensor =
>> thermistor
>> temp3: +127.5?C (high = +120?C, hyst = +115?C) sensor =
>> PII/Celeron diode ALARM
>> vid: +1.650 V
>> alarms:
>> beep_enable:
>> Sound alarm enabled
>>
>> > 3* The output of "sensors" in 2.6.15-rc6.
>>
>> (...)
>> w83627hf-isa-0290
>> Adapter: ISA adapter
>> VCore 1: +1.68 V (min = +1.57 V, max = +1.73 V)
>> VCore 2: +1.79 V (min = +1.57 V, max = +1.73 V) ALARM
>> +3.3V: +3.30 V (min = +3.14 V, max = +3.47 V)
>> +5V: +4.87 V (min = +4.76 V, max = +5.24 V)
>> +12V: +11.86 V (min = +10.82 V, max = +13.19 V)
>> -12V: -12.28 V (min = -13.18 V, max = -10.80 V)
>> -5V: -5.00 V (min = -5.25 V, max = -4.75 V)
>> V5SB: +5.62 V (min = +4.76 V, max = +5.24 V) ALARM
>> VBat: +3.14 V (min = +2.40 V, max = +3.60 V)
>> fan1: 1721 RPM (min = -1 RPM, div = 16) ALARM
>> fan2: 2636 RPM (min = 659 RPM, div = 16)
>> fan3: 0 RPM (min = 2636 RPM, div = 16) ALARM
>> temp1: -48?C (high = +0?C, hyst = +11?C) sensor =
>> thermistor
>> temp2: +63.0?C (high = +120?C, hyst = +115?C) sensor =
>> thermistor
>> temp3: +127.5?C (high = +120?C, hyst = +115?C) sensor =
>> PII/Celeron diode ALARM
>> vid: +1.650 V
>> alarms:
>> beep_enable:
>> Sound alarm enabled
>>
>> Humm, not a heck of a lot of diff to the sensors output. temp1 is
>> shut off in gkrellm anyway. Is temp3 the cpu? This is an Athon
>> XP-2800 stepping 00 cpu.
>
>Obvsiouly not, else your computer would be on fire. The CPU temp
> would be temp2, although it's quite high especially for a
> thermistor-based measurement (which is usually taken from the socket
> rather than the CPU itself). And it matches what gkrellm tells you
> in -rc5 (65 degrees C is 149 degrees F).
>
>temp1 and temp3 are either nor wired, or use a different sensor type
>than the one currently setup. You may try changing the sensor type
> and see if it brings interesting readings (like built-in CPU diode
> or motherboard sensor).
>
THRM at default, and temp2, both result in only one reading, of about
156F in gkrellm, I guess I better truck this thing out to an air hose
& give it a litteral blow job.
>And actually there is very little difference between both outputs -
>I expected this as the driver did not change between -rc5 and -rc6.
>So the problem seems to be that gkrellm fails to pick the proper
>temperature input in -rc6. Why, I have no idea. But as long as
>"sensors" work, the bug has to be in gkrellm rather than the kernel
>driver.
>
>See if you have anything under /proc/acpi/thermal_zone. Maybe gkrellm
>picks the temperature from ACPI in -rc6 for whatever reason.
Several entries, in the THRM subdir, and tempertaure is 69C. Youch!
Later, after I blow this thing out.
--
Cheers, Gene
People having trouble with vz bouncing email to me should add the word
'online' between the 'verizon', and the dot which bypasses vz's
stupid bounce rules. I do use spamassassin too. :-)
Yahoo.com and AOL/TW attorneys please note, additions to the above
message by Gene Heskett are:
Copyright 2005 by Maurice Eugene Heskett, all rights reserved.
Hi Gene,
> [root@coyote root]# i2cdump 1 0x4e b
> WARNING! This program can confuse your I2C bus, cause data loss and
> worse!
> I will probe file /dev/i2c-1, address 0x4e, mode byte
> Continue? [Y/n] y
> 0 1 2 3 4 5 6 7 8 9 a b c d e f 0123456789abcdef
> 00: 00 08 33 33 03 80 01 00 00 00 ff 00 00 00 00 00 .?33???.........
> 10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
> 20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
> 30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
> 40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
> 50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
> 60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
> 70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
> 80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
> 90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
> a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
> b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
> c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
> d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
> e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
> f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
Don't know what it is, but most certainly not a temperature sensor.
> THRM at default, and temp2, both result in only one reading, of about
> 156F in gkrellm, I guess I better truck this thing out to an air hose
> & give it a litteral blow job.
If ACPI gets the temperature value from the W83627HF chip as the
w83627hf driver does, I would expect concurrent access issues. If you
are having temperature readings trouble again, try only using either of
the (ACPI) thermal or w83627hf drivers, not both, and see if things
improve.
I have no idea how such conflicts can be prevented in the big picture.
--
Jean Delvare
On Friday 23 December 2005 05:21, Jean Delvare wrote:
>Hi Gene,
>
>> [root@coyote root]# i2cdump 1 0x4e b
>> WARNING! This program can confuse your I2C bus, cause data loss and
>> worse!
>> I will probe file /dev/i2c-1, address 0x4e, mode byte
>> Continue? [Y/n] y
>> 0 1 2 3 4 5 6 7 8 9 a b c d e f
>> 0123456789abcdef 00: 00 08 33 33 03 80 01 00 00 00 ff 00 00 00 00
>> 00 .?33???......... 10: 00 00 00 00 00 00 00 00 00 00 00 00 00
>> 00 00 00 ................ 20: 00 00 00 00 00 00 00 00 00 00 00
>> 00 00 00 00 00 ................ 30: 00 00 00 00 00 00 00 00 00
>> 00 00 00 00 00 00 00 ................ 40: 00 00 00 00 00 00 00
>> 00 00 00 00 00 00 00 00 00 ................ 50: 00 00 00 00 00
>> 00 00 00 00 00 00 00 00 00 00 00 ................ 60: 00 00 00
>> 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 70: 00
>> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
>> 80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>> ................ 90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>> 00 ................ a0: 00 00 00 00 00 00 00 00 00 00 00 00 00
>> 00 00 00 ................ b0: 00 00 00 00 00 00 00 00 00 00 00
>> 00 00 00 00 00 ................ c0: 00 00 00 00 00 00 00 00 00
>> 00 00 00 00 00 00 00 ................ d0: 00 00 00 00 00 00 00
>> 00 00 00 00 00 00 00 00 00 ................ e0: 00 00 00 00 00
>> 00 00 00 00 00 00 00 00 00 00 00 ................ f0: 00 00 00
>> 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
>
>Don't know what it is, but most certainly not a temperature sensor.
>
>> THRM at default, and temp2, both result in only one reading, of
>> about 156F in gkrellm, I guess I better truck this thing out to an
>> air hose & give it a litteral blow job.
>
>If ACPI gets the temperature value from the W83627HF chip as the
>w83627hf driver does, I would expect concurrent access issues. If you
>are having temperature readings trouble again, try only using either
> of the (ACPI) thermal or w83627hf drivers, not both, and see if
> things improve.
>
>I have no idea how such conflicts can be prevented in the big
> picture.
Put it in the snilmerg category Jean.
I had first built the -rc6 kernel with the compiler optimizations
turned on as that was the default when my script ran the make
oldconfig. No squawks, but subtle things like this didn't work. So I
built it with that optimization turned off. Got lots of squawks,
something about the timer I think, and ntpd didn't work. Built it
with the size optimization turned on again. It worked. And -rc7 is
now working, built from the same .config, after a make oldconfig.
And this is from the full dl of -rc7, I was asleep when I did it last
night & didn't get the patch, but the whole thing.
Thats what 4 days away does, away at a nieces dairy farm in NY, 430
miles one way, for the Christmas days. And weather turned sour coming
back, not enough to bother me much, but at one point my wife turned to
me and said "if and when you sell this truck, you'll have to explain
to the new owner that those cuts and gouges in the passenger grab rail
above the glovebox were made by your wifes fingernails". I darned
near lost it laughing at her. Obviously, we went to different driving
schools, she to drivers ed, and me to Glare Ice University the year I
turned 16. 55 years ago now, but those lessons stick to you really
well. But they also allow one to safely go 10-40 mph faster than the
drivers ed rules. And kept me alive many times when idiots are
indestinguishable from common loose nuts behind the wheel.
I hope you had a merry Christmas too.
Whatever it was that got the tummy ache seems to have found the
pepto-bismol and is ok now. :-)
--
Cheers, Gene
People having trouble with vz bouncing email to me should add the word
'online' between the 'verizon', and the dot which bypasses vz's
stupid bounce rules. I do use spamassassin too. :-)
Yahoo.com and AOL/TW attorneys please note, additions to the above
message by Gene Heskett are:
Copyright 2005 by Maurice Eugene Heskett, all rights reserved.