Re: [lm-sensors] PWMconfig problem with Asus P5B Deluxe / Winbond

Re: [lm-sensors] PWMconfig problem with Asus P5B Deluxe / Winbond

[David Hubbard]

Hi Alexander,

> I'm not in the kernel mailing list and I assume that you are the
> w83627ehf maintainer.

I am one of them. I have CC'ed your email to the lm-sensors mailing
list. Can you kindly include the CC in your future replies? That is
the correct mailing list to post this discussion on.

> I have a Asus P5B Deluxe running a fresh Ubuntu 7.10 with kernel
> 2.6.22-14-generic and all latest software. lm-sensors is at version
> 2.10.4, pwmconfig at v0.8.
>
> I run sensors-detect and can read all values without any problem.
> sensors:
>
> ----------------------------------------------------------------
> w83627dhg-isa-0290
> Adapter: ISA adapter
> VCore:     +1.57 V  (min =  +0.00 V, max =  +1.74 V)
> in1:      +12.14 V  (min =  +0.00 V, max =  +0.00 V) ALARM
> AVCC:      +3.33 V  (min =  +0.26 V, max =  +2.58 V) ALARM
> 3VCC:      +3.33 V  (min =  +0.51 V, max =  +1.41 V) ALARM
> in4:       +1.34 V  (min =  +0.00 V, max =  +0.10 V) ALARM
> in5:       +1.59 V  (min =  +0.13 V, max =  +0.13 V) ALARM
> in6:       +4.15 V  (min =  +0.61 V, max =  +0.00 V) ALARM
> VSB:       +3.31 V  (min =  +0.00 V, max =  +0.13 V) ALARM
> VBAT:      +1.28 V  (min =  +0.30 V, max =  +2.37 V)
> Case Fan:    0 RPM  (min = 10546 RPM, div = 128) ALARM
> CPU Fan:     0 RPM  (min =  104 RPM, div = 128) ALARM
> Aux Fan:  1318 RPM  (min = 10546 RPM, div = 8) ALARM
> fan4:        0 RPM  (min = 10546 RPM, div = 128) ALARM
> fan5:     2934 RPM  (min = 3515 RPM, div = 2) ALARM
> Sys Temp:    +38°C  (high =    +2°C, hyst =   +68°C)
> CPU Temp:  +33.5°C  (high = +80.0°C, hyst = +75.0°C)
> AUX Temp: +127.0°C  (high = +80.0°C, hyst = +75.0°C)   ALARM
>
> coretemp-isa-0000
> Adapter: ISA adapter
> Core 0:      +30°C  (high =   +85°C)
>
> coretemp-isa-0001
> Adapter: ISA adapter
> Core 1:      +31°C  (high =   +85°C)
> ---------------------------------------------------------------------------
>
> But if I run pwmconfig, I get the following:
>
> ----------------------------------------------------------------------------
> This program will search your sensors for pulse width modulation (pwm)
> controls, and test each one to see if it controls a fan on
> your motherboard. Note that many motherboards do not have pwm
> circuitry installed, even if your sensor chip supports pwm.
>
> We will attempt to briefly stop each fan using the pwm controls.
> The program will attempt to restore each fan to full speed
> after testing. However, it is ** very important ** that you
> physically verify that the fans have been to full speed
> after the program has completed.
>
> Found the following devices:
>    hwmon0/device is w83627dhg
>    hwmon1/device is coretemp
>    hwmon2/device is coretemp
>
> Found the following PWM controls:
>    hwmon0/device/pwm1
> hwmon0/device/pwm1_enable stuck to 1
> Failed to set pwmhwmon0/device/pwm1 to full speed
> Something's wrong, check your fans!
> --------------------------------------------------------------------------
>
> Direct sys access:
>
> -------------------------------------------------------------------------
> akiel@alex:~$ ll /sys/bus/i2c/devices/9191-0290/pwm1*
> -rw-r--r-- 1 root root    0 2007-11-14
> 17:00 /sys/bus/i2c/devices/9191-0290/pwm1
> -rw-r--r-- 1 root root    0 2007-11-14
> 17:00 /sys/bus/i2c/devices/9191-0290/pwm1_enable
> -rw-r--r-- 1 root root 4096 2007-11-14
> 17:03 /sys/bus/i2c/devices/9191-0290/pwm1_min_output
> -rw-r--r-- 1 root root 4096 2007-11-14
> 17:03 /sys/bus/i2c/devices/9191-0290/pwm1_mode
> -rw-r--r-- 1 root root 4096 2007-11-14
> 17:03 /sys/bus/i2c/devices/9191-0290/pwm1_stop_time
> -rw-r--r-- 1 root root 4096 2007-11-14
> 17:03 /sys/bus/i2c/devices/9191-0290/pwm1_target
> -rw-r--r-- 1 root root 4096 2007-11-14
> 17:03 /sys/bus/i2c/devices/9191-0290/pwm1_tolerance
> akiel@alex:~$ cat /sys/bus/i2c/devices/9191-0290/pwm1*
> 0
> 1
> 1
> 0
> 24000
> 0
> 0
> akiel@alex:~$ sudo echo 100 > /sys/bus/i2c/devices/9191-0290/pwm1
> bash: /sys/bus/i2c/devices/9191-0290/pwm1: Permission denied
> ---------------------------------------------------------------------
>
> Asus Q-Fan Control was off. I switched it on but does not make any
> difference.
>
> Best Regards
> Alexander Kiel
> http://alexk.homeip.net

I recall seeing this problem before. The list archives have a similar
problem for an MSI 975x board:
http://lists.lm-sensors.org/pipermail/lm-sensors/2007-April/019545.html
http://lists.lm-sensors.org/pipermail/lm-sensors/2007-April/019566.html

For that board, the solution was that the Intel ICH7 chip controlled
the fan using a GPIO pin. But he wasn't getting a "Permission denied"
error. Can you please double-check that you have permission to write
to the files? I'm not going to quiz you on your setup (SELinux? or a
problem in /etc/sudoers?) -- but I'll take your word for it that it's
a driver error and not a sysfs permissions error.

I'm going to check through the driver code and look for a possible
reason. I'll get back to you.

Cheers,
David

P.S. Don't forget to CC the lm-sensors list, as I have done.

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

Re: [lm-sensors] PWMconfig problem with Asus P5B Deluxe / Winbond

[Alexander Kiel]

Hi David,

> I am one of them. I have CC'ed your email to the lm-sensors mailing
> list. Can you kindly include the CC in your future replies? That is
> the correct mailing list to post this discussion on.

Ok. Thanks. I will CC.

> I recall seeing this problem before. The list archives have a similar
> problem for an MSI 975x board:
> http://lists.lm-sensors.org/pipermail/lm-sensors/2007-April/019545.html
> http://lists.lm-sensors.org/pipermail/lm-sensors/2007-April/019566.html
> 
> For that board, the solution was that the Intel ICH7 chip controlled
> the fan using a GPIO pin. 

No. This isn't the same problem I have. He uses the 4-pin connector. I
only use two case fans on normal 3-pin connectors which are controllable
by Speedfan under Windows.

> But he wasn't getting a "Permission denied"
> error. Can you please double-check that you have permission to write
> to the files? I'm not going to quiz you on your setup (SELinux? or a
> problem in /etc/sudoers?) -- but I'll take your word for it that it's
> a driver error and not a sysfs permissions error.

Good point. I'm so stupid. I do a sudo echo "0" > pwm1. So echo "0" is
executed as root but the file writing not. Ok as root it works. I can
write something into actually pwm4 and the fan stops.

But pwmconfig does not work either. It says:

------------------------------------------------------------
Found the following PWM controls:
   hwmon0/device/pwm1
hwmon0/device/pwm1_enable stuck to 1
Failed to set pwmhwmon0/device/pwm1 to full speed
Something's wrong, check your fans!
------------------------------------------------------------

And  if I try a echo "0" > pwm1_enable I get "bash: echo: write error:
Invalid argument". echo "2" works. So I think this is one for you. 


Best Regards and thanks for help
Alex


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

Re: [lm-sensors] PWMconfig problem with Asus P5B Deluxe / Winbond

[David Hubbard]

Hi Alex,

> > I recall seeing this problem before. The list archives have a similar
> > problem for an MSI 975x board:
> > http://lists.lm-sensors.org/pipermail/lm-sensors/2007-April/019545.html
> > http://lists.lm-sensors.org/pipermail/lm-sensors/2007-April/019566.html
> >
> > For that board, the solution was that the Intel ICH7 chip controlled
> > the fan using a GPIO pin.
>
> No. This isn't the same problem I have. He uses the 4-pin connector. I
> only use two case fans on normal 3-pin connectors which are controllable
> by Speedfan under Windows.
>
> > But he wasn't getting a "Permission denied"
> > error. Can you please double-check that you have permission to write
> > to the files? I'm not going to quiz you on your setup (SELinux? or a
> > problem in /etc/sudoers?) -- but I'll take your word for it that it's
> > a driver error and not a sysfs permissions error.
>
> Good point. I'm so stupid. I do a sudo echo "0" > pwm1. So echo "0" is
> executed as root but the file writing not. Ok as root it works. I can
> write something into actually pwm4 and the fan stops.
>
> But pwmconfig does not work either. It says:
>
> ------------------------------------------------------------
> Found the following PWM controls:
>    hwmon0/device/pwm1
> hwmon0/device/pwm1_enable stuck to 1
> Failed to set pwmhwmon0/device/pwm1 to full speed
> Something's wrong, check your fans!
> ------------------------------------------------------------
>
> And  if I try a echo "0" > pwm1_enable I get "bash: echo: write error:
> Invalid argument". echo "2" works. So I think this is one for you.
>
>
> Best Regards and thanks for help
> Alex

I understand the problem now. In the w83627ehf driver, there is this code:
static ssize_t
store_pwm_enable(struct device *dev, struct device_attribute *attr,
                        const char *buf, size_t count)

...

        if (!val || (val > 2))  /* only modes 1 and 2 are supported */
                return -EINVAL;

That is the "write error: invalid argument" error. The reason this
code rejects a write of 0 to pwm_enable is because the w83627ehf does
not have a true "disable" mode. Some other chips will set the pwm
output to 100% when they are disabled. The w83627ehf doesn't have a
disable mode. Of course, setting it to manual and storing 255 in the
pwm would do the same thing.

That's what pwmconfig (lm_sensors version 2.10.4) does:
                # Try pwmN_enable=0
                echo 0 > $ENABLE 2> /dev/null
                if [ "`cat $ENABLE`" -eq 0 ]
                then
                        # Success
                        return 0
                fi

                # It didn't work, try pwmN_enable=1 pwmN%5
                echo 1 > $ENABLE 2> /dev/null
                echo $MAX > $1
                if [ "`cat $ENABLE`" -eq 1 -a "`cat $1`" -ge 190 ]
                then
                        # Success
                        return 0
                fi

So I *think* the problem is in pwmconfig. But yes, manually writing 0
to pwm_enable will give you an -EINVAL.

To be completely honest, I haven't run pwmconfig in a while. I know it
generally works, but someone should probably post a patch to get it to
work smoothly with w83627ehf and w83627dhg chips. (I could do that...
given lots of time :-)

Hope that helps,
David

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

Re: [lm-sensors] PWMconfig problem with Asus P5B Deluxe / Winbond

[Alexander Kiel]

Hi David,

> I understand the problem now. In the w83627ehf driver, there is this code:
> static ssize_t
> store_pwm_enable(struct device *dev, struct device_attribute *attr,
>                         const char *buf, size_t count)
> 
> ...
> 
>         if (!val || (val > 2))  /* only modes 1 and 2 are supported */
>                 return -EINVAL;
> 
> That is the "write error: invalid argument" error. The reason this
> code rejects a write of 0 to pwm_enable is because the w83627ehf does
> not have a true "disable" mode. Some other chips will set the pwm
> output to 100% when they are disabled. The w83627ehf doesn't have a
> disable mode. Of course, setting it to manual and storing 255 in the
> pwm would do the same thing.
> 
> That's what pwmconfig (lm_sensors version 2.10.4) does:
>                 # Try pwmN_enable=0
>                 echo 0 > $ENABLE 2> /dev/null
>                 if [ "`cat $ENABLE`" -eq 0 ]
>                 then
>                         # Success
>                         return 0
>                 fi
> 
>                 # It didn't work, try pwmN_enable=1 pwmN%5
>                 echo 1 > $ENABLE 2> /dev/null
>                 echo $MAX > $1
>                 if [ "`cat $ENABLE`" -eq 1 -a "`cat $1`" -ge 190 ]
>                 then
>                         # Success
>                         return 0
>                 fi
> 
> So I *think* the problem is in pwmconfig. But yes, manually writing 0
> to pwm_enable will give you an -EINVAL.
> 
> To be completely honest, I haven't run pwmconfig in a while. I know it
> generally works, but someone should probably post a patch to get it to
> work smoothly with w83627ehf and w83627dhg chips. (I could do that...
> given lots of time :-)

Ok the problem with pwmconfig is the following:

echo 0 > $ENABLE 2> /dev/null outputs actually 0. This is the 0 from the
echo. echo 3 > $ENABLE 2> /dev/null would output 3. I have no clue why
this is the case.

This 0 causes the line echo $MAX > $1 to set pwm1 to 0 instead of 255.
If I add a > /dev/null to the line echo 0 > $ENABLE 2> /dev/null it
works as it should.

So the diff is:
----------------------------------------------------------------------
127c127
<               echo 0 > $ENABLE > /dev/null 2> /dev/null
---
>               echo 0 > $ENABLE 2> /dev/null
----------------------------------------------------------------------

Can you submit this patch? I don't have a reasonable access to the
lm-sensors community.

Second: Can you please tell me what echo 2 > pwm1_enable does on this
chip? Is it an chip automatic fan control? It works great for me. It
puts my fan currently to a 155.

Regards
Alex



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

Re: [lm-sensors] PWMconfig problem with Asus P5B Deluxe / Winbond

[David Hubbard]

Hi Alex,

> Ok the problem with pwmconfig is the following:
>
> echo 0 > $ENABLE 2> /dev/null outputs actually 0. This is the 0 from the
> echo. echo 3 > $ENABLE 2> /dev/null would output 3. I have no clue why
> this is the case.
>
> This 0 causes the line echo $MAX > $1 to set pwm1 to 0 instead of 255.
> If I add a > /dev/null to the line echo 0 > $ENABLE 2> /dev/null it
> works as it should.
>
> So the diff is:
> ----------------------------------------------------------------------
> 127c127
> <               echo 0 > $ENABLE > /dev/null 2> /dev/null
> ---
> >               echo 0 > $ENABLE 2> /dev/null
> ----------------------------------------------------------------------
>
> Can you submit this patch? I don't have a reasonable access to the
> lm-sensors community.

I'll take a look. I'm pushing out some patches for the kernel driver
right now, so if you can hang on to that patch for a few days, I'll
review it.

> Second: Can you please tell me what echo 2 > pwm1_enable does on this
> chip? Is it an chip automatic fan control? It works great for me. It
> puts my fan currently to a 155.

Yes, it's automatic. Take a look at
/usr/src/linux/Documentation/hwmon/w83627ehf:
pwm[1-4]_enable - this file controls mode of fan/temperature control:
        * 1 Manual Mode, write to pwm file any value 0-255 (full speed)
        * 2 Thermal Cruise

There are two more modes (RPM cruise and SmartFan III) which are not
supported by the driver yet. That's mainly because 2 (Thermal Cruise)
works so well, I've focused on other things.

Thanks,
David

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

Re: [lm-sensors] PWMconfig problem with Asus P5B Deluxe / Winbond

[Alexander Kiel]

Hi David,

> > Can you submit this patch? I don't have a reasonable access to the
> > lm-sensors community.
> 
> I'll take a look. I'm pushing out some patches for the kernel driver
> right now, so if you can hang on to that patch for a few days, I'll
> review it.

No problem. I will use Thermal Cruise anyway now. :-) But it would good
for the other people which get worried about this issue.

> > Second: Can you please tell me what echo 2 > pwm1_enable does on this
> > chip? Is it an chip automatic fan control? It works great for me. It
> > puts my fan currently to a 155.
> 
> Yes, it's automatic. Take a look at
> /usr/src/linux/Documentation/hwmon/w83627ehf:
> pwm[1-4]_enable - this file controls mode of fan/temperature control:
>         * 1 Manual Mode, write to pwm file any value 0-255 (full speed)
>         * 2 Thermal Cruise
> 
> There are two more modes (RPM cruise and SmartFan III) which are not
> supported by the driver yet. That's mainly because 2 (Thermal Cruise)
> works so well, I've focused on other things.

Oh. That's fine. This reminds me for the ASUS Q-Fan (BIOS setting)
modes. There you have Performance, Optimal and Silent.

It would be good if pwmconfig could tell one that ones chip have such a
automatic. Than I don't see any need for a software controller ala
fancontrol. In such a case pwmconfig should write a startup script which
sets the right enable mode and that's it.

Regards
Alex


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

Re: [lm-sensors] PWMconfig problem with Asus P5B Deluxe / Winbond

[David Hubbard]

Hi Alex,

> Oh. That's fine. This reminds me for the ASUS Q-Fan (BIOS setting)
> modes. There you have Performance, Optimal and Silent.
>
> It would be good if pwmconfig could tell one that ones chip have such a
> automatic. Than I don't see any need for a software controller ala
> fancontrol. In such a case pwmconfig should write a startup script which
> sets the right enable mode and that's it.

That is actually the default (BIOS supplied) setting for your
w83627dhg. Therefore, all you need to do is never load the w83627ehf
module. Or, if you do load the module, use sensors to read the values
but do not run pwmconfig. I suppose pwmconfig sort of assumes you know
about the modes on your chip and therefore, you're running the script
to configure it in depth, manually, etc.

Anyway, thanks for the feedback! I'll work on that patch at some point....

Cheers,
David

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

Re: [lm-sensors] PWMconfig problem with Asus P5B Deluxe / Winbond

[Jean Delvare]

Hi Alexander, David,

On Fri, 16 Nov 2007 00:15:21 +0100, Alexander Kiel wrote:
> Hi David,
> 
> > I understand the problem now. In the w83627ehf driver, there is this code:
> > static ssize_t
> > store_pwm_enable(struct device *dev, struct device_attribute *attr,
> >                         const char *buf, size_t count)
> > 
> > ...
> > 
> >         if (!val || (val > 2))  /* only modes 1 and 2 are supported */
> >                 return -EINVAL;
> > 
> > That is the "write error: invalid argument" error. The reason this
> > code rejects a write of 0 to pwm_enable is because the w83627ehf does
> > not have a true "disable" mode. Some other chips will set the pwm
> > output to 100% when they are disabled. The w83627ehf doesn't have a
> > disable mode. Of course, setting it to manual and storing 255 in the
> > pwm would do the same thing.
> > 
> > That's what pwmconfig (lm_sensors version 2.10.4) does:
> >                 # Try pwmN_enable=0
> >                 echo 0 > $ENABLE 2> /dev/null
> >                 if [ "`cat $ENABLE`" -eq 0 ]
> >                 then
> >                         # Success
> >                         return 0
> >                 fi
> > 
> >                 # It didn't work, try pwmN_enable=1 pwmN%5
> >                 echo 1 > $ENABLE 2> /dev/null
> >                 echo $MAX > $1
> >                 if [ "`cat $ENABLE`" -eq 1 -a "`cat $1`" -ge 190 ]
> >                 then
> >                         # Success
> >                         return 0
> >                 fi

Note that the failure can be triggered by two conditions: pwmN_enable
not set to 1, or pwmN less than 190. In Alexander's case, pwmN_enable
has the expected value:

> hwmon0/device/pwm1_enable stuck to 1

Which means that the problem is that writing 255 to pwm1 did not work.
No idea why... I agree that the error message could be made clearer,
I'll improve it now.

> > 
> > So I *think* the problem is in pwmconfig. But yes, manually writing 0
> > to pwm_enable will give you an -EINVAL.
> > 
> > To be completely honest, I haven't run pwmconfig in a while. I know it
> > generally works, but someone should probably post a patch to get it to
> > work smoothly with w83627ehf and w83627dhg chips. (I could do that...
> > given lots of time :-)

It already works just fine for me. I am unable to reproduce Alexander's
problem.

> 
> Ok the problem with pwmconfig is the following:
> 
> echo 0 > $ENABLE 2> /dev/null outputs actually 0. This is the 0 from the
> echo. echo 3 > $ENABLE 2> /dev/null would output 3. I have no clue why
> this is the case.

How did you try that, on the command line? $ENABLE is a variable in the
pwmconfig script, on the command line it's undefined, so that can't
work. Your original report doesn't show any "0" printed on the screen.

> 
> This 0 causes the line echo $MAX > $1 to set pwm1 to 0 instead of 255.

I very much doubt it. Both statements are separate, I fail to see how
whatever the first one does could have any influence on the second.

> If I add a > /dev/null to the line echo 0 > $ENABLE 2> /dev/null it
> works as it should.
> 
> So the diff is:
> ----------------------------------------------------------------------
> 127c127
> <               echo 0 > $ENABLE > /dev/null 2> /dev/null
> ---
> >               echo 0 > $ENABLE 2> /dev/null
> ----------------------------------------------------------------------
> 
> Can you submit this patch? I don't have a reasonable access to the
> lm-sensors community.

This patch is not correct, it breaks pwmconfig more than it fixes it.

As explained above, the problem you have is not with setting
pwm1_enable to 1 (that works) but presumably with setting pwm1 to 255.
So you're trying to fix the wrong line of the script.

-- 
Jean Delvare

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

Re: [lm-sensors] PWMconfig problem with Asus P5B Deluxe / Winbond

[Alexander Kiel]

[-- Attachment #1.1: Type: text/plain, Size: 2931 bytes --]

Hi Jean,

> > Ok the problem with pwmconfig is the following:
> > 
> > echo 0 > $ENABLE 2> /dev/null outputs actually 0. This is the 0 from the
> > echo. echo 3 > $ENABLE 2> /dev/null would output 3. I have no clue why
> > this is the case.
> 
> How did you try that, on the command line? $ENABLE is a variable in the
> pwmconfig script, on the command line it's undefined, so that can't
> work. Your original report doesn't show any "0" printed on the screen.

Yes I did this on the command line (bash). Of course, I replaced the
$ENABLE variable through pwm1_enable. Try the following command
in /sys/class/hwmon/hwmon0/device as root:

echo 255 > pwm1; echo 0 > pwm1_enable 2>/dev/null; echo 1 > pwm1_enable
2>/dev/null; echo 255 > pwm1; cat pwm1

This gives me a 0 on the stdout. But this:

echo 255 > pwm1; echo 0 > pwm1_enable >/dev/null 2>/dev/null; echo 1 >
pwm1_enable 2>/dev/null; echo 255 > pwm1; cat pwm1

gives me 255 on stdout. 

PWM1 has no fan attached in my configuration. It may be the CPU fan
controller, but I don't have a CPU fan, I have water cooling. I don't
know if this makes a difference. Currently I have pwm4 working by BIOS
(ASUS Q-fan control). 

> > This 0 causes the line echo $MAX > $1 to set pwm1 to 0 instead of 255.
> 
> I very much doubt it. Both statements are separate, I fail to see how
> whatever the first one does could have any influence on the second.

I don't have much experience in shell programming. But is it possible
that the 0 at stdout stays there until the next command? And than the
cat 255 > pwm1 would be a echo 0 255 > pwm1.

> > If I add a > /dev/null to the line echo 0 > $ENABLE 2> /dev/null it
> > works as it should.
> > 
> > So the diff is:
> > ----------------------------------------------------------------------
> > 127c127
> > <               echo 0 > $ENABLE > /dev/null 2> /dev/null
> > ---
> > >               echo 0 > $ENABLE 2> /dev/null
> > ----------------------------------------------------------------------
> > 
> > Can you submit this patch? I don't have a reasonable access to the
> > lm-sensors community.
> 
> This patch is not correct, it breaks pwmconfig more than it fixes it.

I have pwmconfig v0.8. Maybe the line numbers are not correct in your
version. I think you will find the right position per hand. a additional
> /dev/null should not hurt.

> As explained above, the problem you have is not with setting
> pwm1_enable to 1 (that works) but presumably with setting pwm1 to 255.
> So you're trying to fix the wrong line of the script.

Yes the problem is setting pwm1 to 255. But it is set to 0 by pwmconfig
v0.8. And after my investigation I find out that the 0 comes from this
echo 0 statement. I than fixed pwmconfig with this additional
> /dev/null and it worked for me. It worked completely. It found my fan
attached to pwm4 and all this stuff.

Regards
Alex

[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[-- Attachment #2: Type: text/plain, Size: 153 bytes --]

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

Re: [lm-sensors] PWMconfig problem with Asus P5B Deluxe / Winbond

[Jean Delvare]

On Sun, 18 Nov 2007 16:57:22 +0100, Alexander Kiel wrote:
> Hi Jean,
> 
> > > Ok the problem with pwmconfig is the following:
> > > 
> > > echo 0 > $ENABLE 2> /dev/null outputs actually 0. This is the 0 from the
> > > echo. echo 3 > $ENABLE 2> /dev/null would output 3. I have no clue why
> > > this is the case.
> > 
> > How did you try that, on the command line? $ENABLE is a variable in the
> > pwmconfig script, on the command line it's undefined, so that can't
> > work. Your original report doesn't show any "0" printed on the screen.
> 
> Yes I did this on the command line (bash). Of course, I replaced the
> $ENABLE variable through pwm1_enable. Try the following command
> in /sys/class/hwmon/hwmon0/device as root:
> 
> echo 255 > pwm1; echo 0 > pwm1_enable 2>/dev/null; echo 1 > pwm1_enable
> 2>/dev/null; echo 255 > pwm1; cat pwm1
> 
> This gives me a 0 on the stdout. But this:
> 
> echo 255 > pwm1; echo 0 > pwm1_enable >/dev/null 2>/dev/null; echo 1 >
> pwm1_enable 2>/dev/null; echo 255 > pwm1; cat pwm1
> 
> gives me 255 on stdout. 

May I ask what shell (and version) you're using? Both sequences above
return 255 here.

> 
> PWM1 has no fan attached in my configuration. It may be the CPU fan
> controller, but I don't have a CPU fan, I have water cooling. I don't
> know if this makes a difference. Currently I have pwm4 working by BIOS
> (ASUS Q-fan control). 

PWM1 has no fan attached on my system either.

> 
> > > This 0 causes the line echo $MAX > $1 to set pwm1 to 0 instead of 255.
> > 
> > I very much doubt it. Both statements are separate, I fail to see how
> > whatever the first one does could have any influence on the second.
> 
> I don't have much experience in shell programming. But is it possible
> that the 0 at stdout stays there until the next command? And than the
> cat 255 > pwm1 would be a echo 0 255 > pwm1.

It would take a broken shell to do what you describe, if that's
possible at all. The following command should answer your question:

echo 0 > /sys/class/hwmon/hwmon0/device/pwm1_enable ; echo 255 > /tmp/pwm1 ; cat /tmp/pwm1

Here, it prints the expected error message, then 255.

> 
> > > If I add a > /dev/null to the line echo 0 > $ENABLE 2> /dev/null it
> > > works as it should.
> > > 
> > > So the diff is:
> > > ----------------------------------------------------------------------
> > > 127c127
> > > <               echo 0 > $ENABLE > /dev/null 2> /dev/null
> > > ---
> > > >               echo 0 > $ENABLE 2> /dev/null
> > > ----------------------------------------------------------------------
> > > 
> > > Can you submit this patch? I don't have a reasonable access to the
> > > lm-sensors community.
> > 
> > This patch is not correct, it breaks pwmconfig more than it fixes it.
> 
> I have pwmconfig v0.8. Maybe the line numbers are not correct in your
> version. I think you will find the right position per hand. a additional
> > /dev/null should not hurt.

I meant that the patch is functionally incorrect, not that I was not
able to apply it (although it is, indeed, technically incorrect, for
it's reverted and not in unified format.)

An additional > /dev/null can certainly hurt, as it overwrites the
previous > $ENABLE, meaning that you do NOT write the value to the
sysfs file at all. It doesn't make a difference for you because writing
0 to pwm1_enable doesn't actually work with the w83627ehf driver, but
your change breaks drivers for which it works.

> 
> > As explained above, the problem you have is not with setting
> > pwm1_enable to 1 (that works) but presumably with setting pwm1 to 255.
> > So you're trying to fix the wrong line of the script.
> 
> Yes the problem is setting pwm1 to 255. But it is set to 0 by pwmconfig
> v0.8. And after my investigation I find out that the 0 comes from this
> echo 0 statement. I than fixed pwmconfig with this additional
> > /dev/null and it worked for me. It worked completely. It found my fan
> attached to pwm4 and all this stuff.

-- 
Jean Delvare

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

Re: [lm-sensors] PWMconfig problem with Asus P5B Deluxe / Winbond

[Alexander Kiel]

[-- Attachment #1.1: Type: text/plain, Size: 2737 bytes --]

Hi Jean,

> May I ask what shell (and version) you're using? Both sequences above
> return 255 here.

bash -version says:

GNU bash, version 3.2.25(1)-release (i486-pc-linux-gnu)
Copyright (C) 2005 Free Software Foundation, Inc.

I have a fresh and totaly normal installed Ubuntu 7.10 32-bit without
any modifications. My user account and its homedir is also new. The bad
is that this is likely the most used distributation is the next year.

> It would take a broken shell to do what you describe, if that's
> possible at all. The following command should answer your question:
> 
> echo 0 > /sys/class/hwmon/hwmon0/device/pwm1_enable ; echo 255 > /tmp/pwm1 ; cat /tmp/pwm1
> 
> Here, it prints the expected error message, then 255.

--------------------------------------------------------------------------
root@alex:~# echo 0 > /sys/class/hwmon/hwmon0/device/pwm1_enable ; echo
255 > /tmp/pwm1 ; cat /tmp/pwm1
bash: echo: write error: Invalid argument
0
255
root@alex:~# cat /tmp/pwm1
0
255
--------------------------------------------------------------------------

As you can see it prints the error message, the 0 and the 255. And you
can see both go into /temp/pwm1.

--------------------------------------------------------------------------
root@alex:~# echo 0 > /sys/class/hwmon/hwmon0/device/pwm1_enable
2>/dev/null ; echo 255 > /tmp/pwm1 ; cat /tmp/pwm1
0
255
--------------------------------------------------------------------------

Here the error goes to /dev/null.

--------------------------------------------------------------------------
root@alex:~# echo 0 > /sys/class/hwmon/hwmon0/device/pwm1_enable
>/dev/null 2>/dev/null ; echo 255 > /tmp/pwm1 ; cat /tmp/pwm1
255
--------------------------------------------------------------------------

And so the 0.

> I meant that the patch is functionally incorrect, not that I was not
> able to apply it (although it is, indeed, technically incorrect, for
> it's reverted and not in unified format.)

Ok. Excuse me. This was a simple diff between the two files. I have no
experiences in creating a real patch.

> An additional > /dev/null can certainly hurt, as it overwrites the
> previous > $ENABLE, meaning that you do NOT write the value to the
> sysfs file at all. It doesn't make a difference for you because writing
> 0 to pwm1_enable doesn't actually work with the w83627ehf driver, but
> your change breaks drivers for which it works.

Ok. Thats a good point. I thought that it redirects the hanging zero
to /dev/null. But I see echo 0 is the command and > $ENABLE is the
regirection of the stdout. But why does pwm1_enable not consume the 0
and throws the error afterwards?

Regards
Alex

[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[-- Attachment #2: Type: text/plain, Size: 153 bytes --]

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

Re: [lm-sensors] PWMconfig problem with Asus P5B Deluxe / Winbond

[Jean Delvare]

On Sun, 18 Nov 2007 18:10:24 +0100, Alexander Kiel wrote:
> Hi Jean,
> 
> > May I ask what shell (and version) you're using? Both sequences above
> > return 255 here.
> 
> bash -version says:
> 
> GNU bash, version 3.2.25(1)-release (i486-pc-linux-gnu)
> Copyright (C) 2005 Free Software Foundation, Inc.

That's fairly recent. I'm running 3.1.17(1)-release, and something even
older on my w83627ehf test machine.

> 
> I have a fresh and totaly normal installed Ubuntu 7.10 32-bit without
> any modifications. My user account and its homedir is also new. The bad
> is that this is likely the most used distributation is the next year.

Ubuntu's marketing appears to be very efficient ;) Ubuntu may be very
popular, but it's still only one Linux distribution amongst a dozen
successful one.

> 
> > It would take a broken shell to do what you describe, if that's
> > possible at all. The following command should answer your question:
> > 
> > echo 0 > /sys/class/hwmon/hwmon0/device/pwm1_enable ; echo 255 > /tmp/pwm1 ; cat /tmp/pwm1
> > 
> > Here, it prints the expected error message, then 255.
> 
> --------------------------------------------------------------------------
> root@alex:~# echo 0 > /sys/class/hwmon/hwmon0/device/pwm1_enable ; echo
> 255 > /tmp/pwm1 ; cat /tmp/pwm1
> bash: echo: write error: Invalid argument
> 0
> 255
> root@alex:~# cat /tmp/pwm1
> 0
> 255
> --------------------------------------------------------------------------
> 
> As you can see it prints the error message, the 0 and the 255. And you
> can see both go into /temp/pwm1.
> 

Bummer. That's your shell keeping the initial output (which it failed
to write to pwm1_enable) in some internal buffer and writing it to pwm1
later. I'd say shell bug, and a big one at that. And security-related,
too. I tested on my openSuse 10.3 laptop which has bash version
3.2.25(1) as your system does, and couldn't reproduce the problem
there. Thus I would suspect a Ubuntu-specific patch.

> --------------------------------------------------------------------------
> root@alex:~# echo 0 > /sys/class/hwmon/hwmon0/device/pwm1_enable
> 2>/dev/null ; echo 255 > /tmp/pwm1 ; cat /tmp/pwm1
> 0
> 255
> --------------------------------------------------------------------------
> 
> Here the error goes to /dev/null.
> 
> --------------------------------------------------------------------------
> root@alex:~# echo 0 > /sys/class/hwmon/hwmon0/device/pwm1_enable
> >/dev/null 2>/dev/null ; echo 255 > /tmp/pwm1 ; cat /tmp/pwm1
> 255
> --------------------------------------------------------------------------
> 
> And so the 0.

But then there's no error anymore (you never write
to /sys/class/hwmon/hwmon0/device/pwm1_enable) so it's hardly relevant.

> 
> > I meant that the patch is functionally incorrect, not that I was not
> > able to apply it (although it is, indeed, technically incorrect, for
> > it's reverted and not in unified format.)
> 
> Ok. Excuse me. This was a simple diff between the two files. I have no
> experiences in creating a real patch.

OK. Basic rules are:
* Use -u (for unified diff format).
* Original version goes first on the command line, new version goes
  last.

E.g.: diff -u pwmconfig.orig pwmconfig

> > An additional > /dev/null can certainly hurt, as it overwrites the
> > previous > $ENABLE, meaning that you do NOT write the value to the
> > sysfs file at all. It doesn't make a difference for you because writing
> > 0 to pwm1_enable doesn't actually work with the w83627ehf driver, but
> > your change breaks drivers for which it works.
> 
> Ok. Thats a good point. I thought that it redirects the hanging zero
> to /dev/null. But I see echo 0 is the command and > $ENABLE is the
> regirection of the stdout. But why does pwm1_enable not consume the 0
> and throws the error afterwards?

pwm1_enable returns an error, so it can't consume anything. It's up to
the shell to blast the unused data before going on, but in your case it
doesn't.

-- 
Jean Delvare

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

Re: [lm-sensors] PWMconfig problem with Asus P5B Deluxe / Winbond

[David Hubbard]

Hi Alex, Jean,

> > > It would take a broken shell to do what you describe, if that's
> > > possible at all. The following command should answer your question:
> > >
> > > echo 0 > /sys/class/hwmon/hwmon0/device/pwm1_enable ; echo 255 > /tmp/pwm1 ; cat /tmp/pwm1
> > >
> > > Here, it prints the expected error message, then 255.
> >
> > --------------------------------------------------------------------------
> > root@alex:~# echo 0 > /sys/class/hwmon/hwmon0/device/pwm1_enable ; echo
> > 255 > /tmp/pwm1 ; cat /tmp/pwm1
> > bash: echo: write error: Invalid argument
> > 0
> > 255
> > root@alex:~# cat /tmp/pwm1
> > 0
> > 255
> > --------------------------------------------------------------------------
> >
> > As you can see it prints the error message, the 0 and the 255. And you
> > can see both go into /temp/pwm1.
> >
>
> Bummer. That's your shell keeping the initial output (which it failed
> to write to pwm1_enable) in some internal buffer and writing it to pwm1
> later. I'd say shell bug, and a big one at that. And security-related,
> too. I tested on my openSuse 10.3 laptop which has bash version
> 3.2.25(1) as your system does, and couldn't reproduce the problem
> there. Thus I would suspect a Ubuntu-specific patch.

I just thought I'd throw in another test point. I was curious if the
w83627ehf driver was somehow storing "0\n255" or some similar wrong
behavior:

# echo 1 > pwm3_enable
# echo 175 > pwm3
# echo "0
> 175" > pwm3
# cat pwm3
175
# echo -e "0\n175"
0
175
# echo -e "0\n175" > pwm3
# cat pwm3
175
# dmesg | tail
[  291.436322] allocating slot 0, addr 2e for device 8860
[  291.436323] found devid:8860 port:2e users:1
[  291.436331] w83627ehf: Found W83627EHG chip at 0x290
[  291.436536] releasing last user of superio-port 2e
[  301.088199] w83627ehf w83627ehf.656: Increasing fan3 clock divider
from 2 to 4
[  301.088233] w83627ehf w83627ehf.656: Increasing fan5 clock divider
from 1 to 2
[  302.644499] w83627ehf w83627ehf.656: Increasing fan5 clock divider
from 2 to 4
[  304.884458] w83627ehf w83627ehf.656: Increasing fan5 clock divider
from 4 to 8
[  309.069573] w83627ehf w83627ehf.656: Increasing fan5 clock divider
from 8 to 16
[  313.797610] w83627ehf w83627ehf.656: Increasing fan5 clock divider
from 16 to 32


Alex, I wonder if your bash is creating a file with "0\n255" in it?
Because I would feel fairly confident in saying the driver will not be
able to store a string for later retrieval in pwm3, or pwm1.

Hope that helps,
David

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

Re: [lm-sensors] PWMconfig problem with Asus P5B Deluxe / Winbond

[Jean Delvare]

Hi David,

On Sun, 18 Nov 2007 23:32:12 -0700, David Hubbard wrote:
> I just thought I'd throw in another test point. I was curious if the
> w83627ehf driver was somehow storing "0\n255" or some similar wrong
> behavior:
> 
> # echo 1 > pwm3_enable
> # echo 175 > pwm3
> # echo "0
> > 175" > pwm3
> # cat pwm3
> 175
> # echo -e "0\n175"
> 0
> 175
> # echo -e "0\n175" > pwm3
> # cat pwm3
> 175
> # dmesg | tail
> [  291.436322] allocating slot 0, addr 2e for device 8860
> [  291.436323] found devid:8860 port:2e users:1
> [  291.436331] w83627ehf: Found W83627EHG chip at 0x290
> [  291.436536] releasing last user of superio-port 2e
> [  301.088199] w83627ehf w83627ehf.656: Increasing fan3 clock divider
> from 2 to 4
> [  301.088233] w83627ehf w83627ehf.656: Increasing fan5 clock divider
> from 1 to 2
> [  302.644499] w83627ehf w83627ehf.656: Increasing fan5 clock divider
> from 2 to 4
> [  304.884458] w83627ehf w83627ehf.656: Increasing fan5 clock divider
> from 4 to 8
> [  309.069573] w83627ehf w83627ehf.656: Increasing fan5 clock divider
> from 8 to 16
> [  313.797610] w83627ehf w83627ehf.656: Increasing fan5 clock divider
> from 16 to 32
> 
> 
> Alex, I wonder if your bash is creating a file with "0\n255" in it?
> Because I would feel fairly confident in saying the driver will not be
> able to store a string for later retrieval in pwm3, or pwm1.

The driver doesn't store the input. It parses it and does something out
of the result, and later it prints a value from a register. So it's
strictly impossible for the driver to return something else than a
single integer value when you read from pwm3.

I've added some debugging to the driver and came to the following
conclusion: sysfs splits multi-line writes, and the driver's callback
is called for each line separately. This matches your experience above:
the value written last is returned on the following read.

This however doesn't completely explain Alexander's experience, as for
him, only the _first_ value (the struck 0) appears to be considered by
the driver. But as it seems to be a bash bug specific to Ubuntu (at
least that's what the currently available evidences suggest), there's
little point in spending more time on this. The bug should be reported
to the maintainer of the Ubuntu bash package.

-- 
Jean Delvare

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