[lm-sensors] W83792D & Overtemperature LED on Supermicro

[lm-sensors] W83792D & Overtemperature LED on Supermicro

[Eric J. Bowersox]

Greetings to all.

We've got some compute nodes here that are using Supermicro X6DHR
motherboards (for the Intel Nocona processors), which use the Winbond
W83792D hardware monitor chip.  Since the OS installed on these is SuSE
Linux Enterprise Server 9 (kernel 2.6.5), I had to upgrade lm_sensors to
2.9.1 and apply a kernel patch (the one recently posted to this list) to
get the right chip driver into the system.  I'm able to get temperature,
fan, and voltage readings out of the chip, so it's all good there.

However, another strange issue has cropped up: during the system boot
process, as soon as the "sensors" service loads, the "overtemperature"
LED on the front panel begins flashing.  I've tried mucking around with
the "set tempN_over" and "set tempN_hyst" lines in sensors.conf, but to
no avail; the last settings I tried were 70 for over and 30 for hyst,
and the light still blinks.  Naturally, if we ship the nodes like this,
the customer might get worried, seeing all those blinking red lights.

So, anybody have any ideas, short of taking a pair of diagonal cutters
to the leads for the temperature light?  Is that light somehow connected
to one of the outputs of the W83792D, and if so, is there some kind of
"magic poke" I can make to the chip registers to get it to quit
flashing?  (Maybe this is a driver issue?)  Or have I just not been
aggressive enough in how I changed the temperature bounds in
sensors.conf?

Thanks in advance.

-- 
Eric J. Bowersox, Software Engineer     Aspen Systems, Inc.
<ericb@aspsys.com>                      3900 Youngfield Street
Tel: +01 303 431 4606 x113              Wheat Ridge, CO  80033, USA
Fax: +01 303 431 7196                   <http://www.aspsys.com>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.lm-sensors.org/pipermail/lm-sensors/attachments/20050630/c7ff3157/attachment.bin

[lm-sensors] W83792D & Overtemperature LED on Supermicro

[Eric J. Bowersox]

(Sorry about the blank message, let's try it again...)

Greetings to all.

We've got some compute nodes here that are using Supermicro X6DHR
motherboards (for the Intel Nocona processors), which use the Winbond
W83792D hardware monitor chip.  Since the OS installed on these is SuSE
Linux Enterprise Server 9 (kernel 2.6.5), I had to upgrade lm_sensors to
2.9.1 and apply a kernel patch (the one recently posted to this list) to
get the right chip driver into the system.  I'm able to get temperature,
fan, and voltage readings out of the chip, so it's all good there.

However, another strange issue has cropped up: during the system boot
process, as soon as the "sensors" service loads, the "overtemperature"
LED on the front panel begins flashing.  I've tried mucking around with
the "set tempN_over" and "set tempN_hyst" lines in sensors.conf, but to
no avail; the last settings I tried were 70 for over and 30 for hyst,
and the light still blinks.  Naturally, if we ship the nodes like this,
the customer might get worried, seeing all those blinking red lights.

So, anybody have any ideas, short of taking a pair of diagonal cutters
to the leads for the temperature light?  Is that light somehow connected
to one of the outputs of the W83792D, and if so, is there some kind of
"magic poke" I can make to the chip registers to get it to quit
flashing?  (Maybe this is a driver issue?)  Or have I just not been
aggressive enough in how I changed the temperature bounds in
sensors.conf?

Thanks in advance.

-- 
Eric J. Bowersox, Software Engineer     Aspen Systems, Inc.
<ericb@aspsys.com>                      3900 Youngfield Street
Tel: +01 303 431 4606 x113              Wheat Ridge, CO  80033, USA
Fax: +01 303 431 7196                   <http://www.aspsys.com>

[lm-sensors] W83792D & Overtemperature LED on Supermicro

[Mark Studebaker]

you want hyst (hysteresis) to be high, like 68.
The alarm isn't cleared until the temperature goes below the hysteresis value.


Eric J. Bowersox wrote:
> (Sorry about the blank message, let's try it again...)
> 
> Greetings to all.
> 
> We've got some compute nodes here that are using Supermicro X6DHR
> motherboards (for the Intel Nocona processors), which use the Winbond
> W83792D hardware monitor chip.  Since the OS installed on these is SuSE
> Linux Enterprise Server 9 (kernel 2.6.5), I had to upgrade lm_sensors to
> 2.9.1 and apply a kernel patch (the one recently posted to this list) to
> get the right chip driver into the system.  I'm able to get temperature,
> fan, and voltage readings out of the chip, so it's all good there.
> 
> However, another strange issue has cropped up: during the system boot
> process, as soon as the "sensors" service loads, the "overtemperature"
> LED on the front panel begins flashing.  I've tried mucking around with
> the "set tempN_over" and "set tempN_hyst" lines in sensors.conf, but to
> no avail; the last settings I tried were 70 for over and 30 for hyst,
> and the light still blinks.  Naturally, if we ship the nodes like this,
> the customer might get worried, seeing all those blinking red lights.
> 
> So, anybody have any ideas, short of taking a pair of diagonal cutters
> to the leads for the temperature light?  Is that light somehow connected
> to one of the outputs of the W83792D, and if so, is there some kind of
> "magic poke" I can make to the chip registers to get it to quit
> flashing?  (Maybe this is a driver issue?)  Or have I just not been
> aggressive enough in how I changed the temperature bounds in
> sensors.conf?
> 
> Thanks in advance.
> 

[lm-sensors] W83792D & Overtemperature LED on Supermicro

[Eric J. Bowersox]

On Thu, 2005-06-30 at 18:33, Mark Studebaker wrote:
> you want hyst (hysteresis) to be high, like 68.
> The alarm isn't cleared until the temperature goes below the hysteresis value.

I just tried that on one of the nodes in question.  Didn't help.  Even
with all tempN_over values set to 80 and all tempN_hyst values set to
75, the output of "sensors" still displays "ALARM" by the two CPU
temperatures (which currently read 46 and 49 respectively), and the
front-panel temperature light still blinks.  (The output of "sensors"
did show that the two limits were set correctly by "sensors -s" though.)

					Eric

-- 
Eric J. Bowersox, Software Engineer     Aspen Systems, Inc.
<ericb@aspsys.com>                      3900 Youngfield Street
Tel: +01 303 431 4606 x113              Wheat Ridge, CO  80033, USA
Fax: +01 303 431 7196                   <http://www.aspsys.com>

[lm-sensors] W83792D & Overtemperature LED on Supermicro

[Rudolf Marek]

Eric J. Bowersox wrote:
> On Thu, 2005-06-30 at 18:33, Mark Studebaker wrote:
> 
>>you want hyst (hysteresis) to be high, like 68.
>>The alarm isn't cleared until the temperature goes below the hysteresis value.
> 
> 
> I just tried that on one of the nodes in question.  Didn't help.  Even
> with all tempN_over values set to 80 and all tempN_hyst values set to
> 75, the output of "sensors" still displays "ALARM" by the two CPU
> temperatures (which currently read 46 and 49 respectively), and the
> front-panel temperature light still blinks.  (The output of "sensors"
> did show that the two limits were set correctly by "sensors -s" though.)

Hello,

Please can you dump content of the chip before you will load the driver and after you will load?
(no sensors -s running)

You can do that like this:

1) run sensors command
2) get the bus and chip address, i will use 0 and 0x2f as example
3) reboot
4) load only i2c bus driver and i2c-dev module (you must somehow disable the automatic loading during startup)
5) i2cdump -y 0 0x2f >firstdump
6) modprobe w83792d
7) i2cdump -y 0 0x2f >seconddump

Also I would like to know which version of the driver did you used.
Was it http://lists.lm-sensors.org/pipermail/lm-sensors/attachments/20050621/8dfe2e28/patch_w83792d-2.6.12-0001.gz ?
(note you can patch your kernel even if this is called 2.6.12)

Thanks

Regards
Rudolf

[lm-sensors] W83792D & Overtemperature LED on Supermicro

[Eric J. Bowersox]

Hello, Rudolf, sorry it's taken so long for a reply.

On Sat, 2005-07-02 at 10:37, Rudolf Marek wrote:
> Please can you dump content of the chip before you will load the driver and after you will load?
> (no sensors -s running)

Done.  Here's the results.

First dump:

     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f    0123456789abcdef
00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
10: 00 00 64 64 93 00 00 13 00 ff 00 00 05 00 00 b3    ..dd?..?....?..?
20: a8 a9 d1 bd 1e c7 d3 24 25 26 ff af 96 af 96 e2    ???????$%&.?????
30: b9 ce a8 2f 13 d9 b1 cc a7 50 4b ed ed ed 2e 93    ???/?????PK???.?
40: 03 00 20 9f 7f ff ff 33 2f 13 88 80 07 ff 80 5c    ?. ??..3/????.?\
50: ff ff ff ff ff ff ff ff 7a 30 ff 33 33 01 05 7f    ........z0.33???
60: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff    ................
70: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff    ................
80: ff 88 ff 88 0a 1e 1e 55 88 88 ff ff 00 00 0a 0a    .?.????U??....??
90: 36 36 00 01 8f ff 00 00 11 ff 3c 00 ff 01 01 ff    66.??...?.<..??.
a0: 01 01 01 8f 8f 8f 8f ff 3c 80 30 68 ff ff 00 00    ???????.<?0h....
b0: cf cc ff ff cc a7 e2 b9 ff ff ff ed ed ff ff ff    ??..????...??...
c0: 26 00 00 4b 00 50 00 ff 25 00 00 28 00 3c 00 ff    &..K.P..%..(.<..
d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff    ................
e0: af af 8b 3c 46 7f 3c 46 7f 28 3c 50 ff ff ff ff    ???<F?<F?(<P....
f0: ff ff 00 ff 00 01 00 00 ff 02 ff 00 00 00 00 ff    .....?...?......

Second dump:

     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f    0123456789abcdef
00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
10: 00 00 64 64 93 00 00 13 00 ff 00 00 05 00 00 b3    ..dd?..?....?..?
20: a9 a9 d2 be 1e c8 d3 2f 78 84 ff af 96 af 96 e2    ???????/x?.?????
30: b9 ce a8 2f 13 d9 b1 cc a7 50 4b ed ed ed 7e b6    ???/?????PK???~?
40: 01 80 30 00 00 ff ff 11 2f 13 03 80 07 ff 80 5c    ??0....?/????.?\
50: ff ff ff ff ff ff ff ff 7a 60 ff 11 11 01 05 7f    ........z`.?????
60: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff    ................
70: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff    ................
80: 01 8f 01 8f 00 00 00 00 11 11 ff ff 3c 3c 0a 0a    ????....??..<<??
90: 00 00 00 01 8f ff 00 00 11 ff 3c 20 00 01 01 ff    ...??...?.< .??.
a0: 01 01 01 8f 8f 8f 8f ff 3c 80 30 68 ff ff 00 00    ???????.<?0h....
b0: cf cc ff ff cc a7 e2 b9 ff ff ff ed ed ff ff ff    ??..????...??...
c0: 2f 80 00 4b 00 50 00 ff e1 80 00 28 00 3c 00 ff    /?.K.P..??.(.<..
d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff    ................
e0: 8b 8b 8b 28 3c 50 28 3c 50 28 3c 50 ff ff ff ff    ???(<P(<P(<P....
f0: ff ff 80 ff 00 01 00 00 ff 02 ff 00 00 00 00 ff    ..?..?...?......

> Also I would like to know which version of the driver did you used.
> Was it http://lists.lm-sensors.org/pipermail/lm-sensors/attachments/20050621/8dfe2e28/patch_w83792d-2.6.12-0001.gz ?

Yes, that was it, except I had to make a few minor adjustments to the
driver file to get it to compile against the 2.6.5 kernel.  (Before you
ask, yes, we *have* to use that kernel version; the customer wants SuSE
Enterprise 9, and that's the most recent kernel version we have from
SuSE with all their patches and whatnot.)  In addition, I made a teeny
patch to the driver to change the dev_info() message that is logged
every time the driver polls the chip to a dev_dbg() message, since our
production engineer was concerned about the excessive log messages.  I
am attaching the patch as I modified it for 2.6.5, and the second patch
for the log messages (that works against either the 2.6.5 or 2.6.12
patches).

Thanks in advance for any help you can give here.

					Eric

-- 
Eric J. Bowersox, Software Engineer     Aspen Systems, Inc.
<ericb@aspsys.com>                      3900 Youngfield Street
Tel: +01 303 431 4606 x113              Wheat Ridge, CO  80033, USA
Fax: +01 303 431 7196                   <http://www.aspsys.com>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: w83792d-driver-2.6.5.patch.gz
Type: application/x-gzip
Size: 14369 bytes
Desc: not available
Url : http://lists.lm-sensors.org/pipermail/lm-sensors/attachments/20050706/3a674472/w83792d-driver-2.6.5.patch-0001.gz
-------------- next part --------------
A non-text attachment was scrubbed...
Name: w83792d-driver-QUIET-2.6.x.patch.gz
Type: application/x-gzip
Size: 383 bytes
Desc: not available
Url : http://lists.lm-sensors.org/pipermail/lm-sensors/attachments/20050706/3a674472/w83792d-driver-QUIET-2.6.x.patch-0001.gz

[lm-sensors] W83792D & Overtemperature LED on Supermicro

[Jean Delvare]

Hi Eric,

> Second dump:

This suggests that some voltages and fan readings are out of range
(namely fan3, 5vcc and fan4). So maybe your overtemperature LED is
reacting to more than just overtemperatures but also to other out of
range conditions. Please try fixing all voltages and fans, and see if it
helps.

Remember that adding "ignore" lines in sensors.conf does NOT disable the
associated channel and alarm, it merely hides it to you. So please
remove all ignore statements and make sure they were not hiding alarms.

-- 
Jean Delvare

[lm-sensors] W83792D & Overtemperature LED on Supermicro

[Jean Delvare]

Hi again Eric,

> Yes, that was it, except I had to make a few minor adjustments to the
> driver file to get it to compile against the 2.6.5 kernel.  (Before
> you ask, yes, we *have* to use that kernel version; the customer wants
> SuSE Enterprise 9, and that's the most recent kernel version we have
> from SuSE with all their patches and whatnot.)  In addition, I made a
> teeny patch to the driver to change the dev_info() message that is
> logged every time the driver polls the chip to a dev_dbg() message,
> since our production engineer was concerned about the excessive log
> messages.  I am attaching the patch as I modified it for 2.6.5, and
> the second patch for the log messages (that works against either the
> 2.6.5 or 2.6.12 patches).

Another thing here, see these lines in the patch:

+	/* Start monitoring */
+	w83792d_write_value(client, W83792D_REG_CONFIG,
+			    (w83792d_read_value(client,
+						W83792D_REG_CONFIG) & 0xf7)
+			    | 0x01);

I believe that the mask should be 0x7e, rather than 0xf7. Could you
please change that and see if it helps?

Thanks,
-- 
Jean Delvare

[lm-sensors] W83792D & Overtemperature LED on Supermicro

[Rudolf Marek]

Hello,

It seems the chip was reset. If the first dump is really after reboot and second is really when the driver loads I must admit it is strange.
Please can you change

static int init;
to
static int init=0;

Maybe your kernel is not cleaning global data area...

Thanks

regards

Rudolf

[lm-sensors] W83792D & Overtemperature LED on Supermicro

[Eric J. Bowersox]

Gentlemen, thank you for your responses.  Unfortunately, none of them
seem to have made a difference.

On Thu, 2005-07-07 at 13:19, Jean Delvare wrote: 
> This suggests that some voltages and fan readings are out of range
> (namely fan3, 5vcc and fan4). So maybe your overtemperature LED is
> reacting to more than just overtemperatures but also to other out of
> range conditions. Please try fixing all voltages and fans, and see if it
> helps.
> 
> Remember that adding "ignore" lines in sensors.conf does NOT disable the
> associated channel and alarm, it merely hides it to you. So please
> remove all ignore statements and make sure they were not hiding alarms.

I set all unused "fan" channels to a minimum RPM of 0 and all three
temperature channels to a high of 70 and hysteresis of 60 (highest
actual reading of the three was 54).  Still blinking.


On Thu, 2005-07-07 at 13:26, Jean Delvare wrote: 
> Another thing here, see these lines in the patch:
> 
> +	/* Start monitoring */
> +	w83792d_write_value(client, W83792D_REG_CONFIG,
> +			    (w83792d_read_value(client,
> +						W83792D_REG_CONFIG) & 0xf7)
> +			    | 0x01);
> 
> I believe that the mask should be 0x7e, rather than 0xf7. Could you
> please change that and see if it helps?
> 
> Thanks,

Changed that line, tried the new module.  Still blinking.

On Thu, 2005-07-07 at 14:10, Rudolf Marek wrote: 
> It seems the chip was reset. If the first dump is really after reboot and second is really when the driver loads I must admit it is strange.
> Please can you change
> 
> static int init;
> to
> static int init=0;
> 
> Maybe your kernel is not cleaning global data area...

Tried that too.  Still blinking.

FYI, I can confirm that, at system reset time, the light is NOT blinking, and
that it is the action of loading the w83972d driver that causes the light to
start blinking (i.e. "modprobe w83792d" and blinks happen right then).

These dumps were taken with the driver with both patches loaded.  Before:

     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f    0123456789abcdef
00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
10: 00 00 64 64 93 00 00 13 00 ff 00 00 05 00 00 b3    ..dd?..?....?..?
20: a8 a9 d1 bd 1e c8 d3 2b 25 26 ff af 96 af 96 e2    ???????+%&.?????
30: b9 ce a8 2f 13 d9 b1 cc a7 50 4b ed ed ed 1f a6    ???/?????PK?????
40: 03 00 20 9f 7f ff ff 33 2f 13 88 80 07 ff 80 5c    ?. ??..3/????.?\
50: ff ff ff ff ff ff ff ff 7a 30 ff 33 33 01 05 7f    ........z0.33???
60: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff    ................
70: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff    ................
80: ff 88 ff 88 0a 1e 1e 55 88 88 ff ff 00 00 0a 0a    .?.????U??....??
90: 36 36 00 01 8f ff 00 00 11 ff 3c 00 ff 01 01 ff    66.??...?.<..??.
a0: 01 01 01 8f 8f 8f 8f ff 3c 80 30 68 ff ff 00 00    ???????.<?0h....
b0: cf cd ff ff cc a7 e2 b9 ff ff ff ed ed ff ff ff    ??..????...??...
c0: 2c 00 00 4b 00 50 00 ff 2b 80 00 28 00 3c 00 ff    ,..K.P..+?.(.<..
d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff    ................
e0: af af 8b 3c 46 7f 3c 46 7f 28 3c 50 ff ff ff ff    ???<F?<F?(<P....
f0: ff ff 80 ff 00 01 00 00 ff 02 ff 00 00 00 00 ff    ..?..?...?......

After:

     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f    0123456789abcdef
00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
10: 00 00 64 64 93 00 00 13 00 ff 00 00 05 00 00 b3    ..dd?..?....?..?
20: a8 a9 d2 be 1e c8 d4 2f 78 81 ff af 96 af 96 e2    ???????/x?.?????
30: b9 ce a8 2f 13 d9 b1 cc a7 50 4b ed ed ed 33 ba    ???/?????PK???3?
40: 01 80 30 00 00 ff ff 11 2f 13 03 80 07 ff 80 5c    ??0....?/????.?\
50: ff ff ff ff ff ff ff ff 7a 60 ff 11 11 01 05 7f    ........z`.?????
60: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff    ................
70: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff    ................
80: 01 8f 01 8f 00 00 00 00 11 11 ff ff 3c 3c 0a 0a    ????....??..<<??
90: 00 00 00 01 8f ff 00 00 11 ff 3c 00 00 01 01 ff    ...??...?.<..??.
a0: 01 01 01 8f 8f 8f 8f ff 3c 80 30 68 ff ff 00 00    ???????.<?0h....
b0: cf cd ff ff cc a7 e2 b9 ff ff ff ed ed ff ff ff    ??..????...??...
c0: 36 00 00 4b 00 50 00 ff 10 80 00 28 00 3c 00 ff    6..K.P..??.(.<..
d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff    ................
e0: 8b 8b 8b 28 3c 50 28 3c 50 28 3c 50 ff ff ff ff    ???(<P(<P(<P....
f0: ff ff 00 ff 00 01 00 00 ff 02 ff 00 00 00 00 ff    .....?...?......

Any more ideas?  Our production engineer is happy for any assistance
you may have to offer in this matter.

					Eric

-- 
Eric J. Bowersox, Software Engineer     Aspen Systems, Inc.
<ericb@aspsys.com>                      3900 Youngfield Street
Tel: +01 303 431 4606 x113              Wheat Ridge, CO  80033, USA
Fax: +01 303 431 7196                   <http://www.aspsys.com>

[lm-sensors] W83792D & Overtemperature LED on Supermicro

[Rudolf Marek]

Hello,

Something in our driver triggers the whole chip reset. We are not touching the reset bit so it must be
something else. You have revision 13 of the chip and we have datasheet of 12 revision.

I would suggest following:

static int
w83792d_write_value(struct i2c_client *client, u8 reg, u8 value)
{
        i2c_smbus_write_byte_data(client, reg,  value);
        return 0;
}

remove this funcs and replace with this one:

static int
wrt(struct i2c_client *client, u8 reg, u8 value)
{
        i2c_smbus_write_byte_data(client, reg,  value);
	if (i2c_smbus_read_byte_data(client, 0x40)!=3) {
	printk("Chip RESET occured when written %x to %x reg\n",value,reg);
	}

        return 0;
}

And add to top of this file:

#define w83792d_write_value(a,b,c)  { printk("write called from line %d\n",__LINE__); wrt(a,b,c) }

So we can track what call it was.

Proposed funcs were not tested but I think you get the idea. Register 0x40 is master config reg. After reset it defaults to value 0x1 and it is before 0x3.
Lets hope the chip will reset when writing into it and not reading by some odd reason.

Regards

Rudolf

[lm-sensors] W83792D & Overtemperature LED on Supermicro

[Rudolf Marek]

Hi again.

> 
>      0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f    0123456789abcdef
> 00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
> 10: 00 00 64 64 93 00 00 13 00 ff 00 00 05 00 00 b3    ..dd?..?....?..?
> 20: a8 a9 d1 bd 1e c8 d3 2b 25 26 ff af 96 af 96 e2    ???????+%&.?????
> 30: b9 ce a8 2f 13 d9 b1 cc a7 50 4b ed ed ed 1f a6    ???/?????PK?????
> 40: 03 00 20 9f 7f ff ff 33 2f 13 88 80 07 ff 80 5c    ?. ??..3/????.?\
                                   ^^^^
Both subclients are disabled.
It seems our driver

          val = w83792d_read_value(new_client, W83792D_REG_I2C_SUBADDR);
                data->lm75[0]->addr = 0x48 + (val & 0x07);
                data->lm75[1]->addr = 0x48 + ((val >> 4) & 0x07);
        }

Does not expect this.  You must be using force_subclients parameter to get around this?!
Maybe setting the subclients reset the chip.

  if (data->lm75[0]->addr = data->lm75[1]->addr) {
                dev_err(&new_client->dev, "duplicate addresses 0x%x "
                                "for subclients\n", data->lm75[0]->addr);
                err = -ENODEV;
                goto ERROR_SC_2;
        }


Please make sure you are not using force_subclients param,
To allow driver load comment out calling of w83792d_detect_subclients.

Regards

Rudolf

[lm-sensors] W83792D & Overtemperature LED on Supermicro

[Eric J. Bowersox]

On Fri, 2005-07-08 at 04:27, Rudolf Marek wrote:
> Both subclients are disabled.
> It seems our driver
> 
>           val = w83792d_read_value(new_client, W83792D_REG_I2C_SUBADDR);
>                 data->lm75[0]->addr = 0x48 + (val & 0x07);
>                 data->lm75[1]->addr = 0x48 + ((val >> 4) & 0x07);
>         }
> 
> Does not expect this.  You must be using force_subclients parameter to get around this?!
> Maybe setting the subclients reset the chip.
> 
>   if (data->lm75[0]->addr = data->lm75[1]->addr) {
>                 dev_err(&new_client->dev, "duplicate addresses 0x%x "
>                                 "for subclients\n", data->lm75[0]->addr);
>                 err = -ENODEV;
>                 goto ERROR_SC_2;
>         }
> 
> 
> Please make sure you are not using force_subclients param,
> To allow driver load comment out calling of w83792d_detect_subclients.

Rudolf, it seems you were right about the use of an extra parameter
causing the problem...but it wasn't force_subclients.  One of the
configuration files had an extra "init=1" parameter setting which must
have been causing the reset.  Removing that parameter, while leaving the
force_subclients parameter and the subclient initialization code intact,
caused the driver to load *without* starting the overtemperature light
blinking!

(Incidentally, just commenting out the call to w83792d_detect_subclients
caused the module to utterly fail to load, emitting an error saying that
the module "falsely claims to have parameter force_subclients."  I tried
commenting out bits of the w83792d_detect_subclients function code
instead; that worked better.  But I removed those comment delimiters,
leaving the code as it was before, before I tried again without the
init=1 parameter.)

And you were right that I *did* have to use force_subclients to get the
driver to load in the first place.  I also had to use "ignore=0,0x2d"
because there appears to be another chip (possibly a W83627HF?) at
address 0x2d that was causing the w83792d driver to stop there, try to
load, and fail.  The chip at address 0x2d does load with the w83781d
driver, but its sensor inputs don't appear to be connected to anything.

Looks like we've found a solution.  Thanks for being patient with me and
for all your assistance.

					Eric

-- 
Eric J. Bowersox, Software Engineer     Aspen Systems, Inc.
<ericb@aspsys.com>                      3900 Youngfield Street
Tel: +01 303 431 4606 x113              Wheat Ridge, CO  80033, USA
Fax: +01 303 431 7196                   <http://www.aspsys.com>