Supermicro IPMI Fan control

Patrik Dufresne

New Member
Oct 19, 2016
16
1
3
35
Hello, I own 4 supermicro motherboard with IPMI. X8DTL-if

I'm trying to figure out how to reduce the fans speed. I've already change the Fan Control setting to "Optiomal". But, it's not enough. I want to lower the speed gain.

Do you know any tricks to do this ?
 

adgenet

Member
Apr 12, 2016
34
9
8
Try ES Energy Saver mode.
If that's not enough, I think there's a way to do it with ipmitool but I'm not familiar with the details.
Also not sure if the board throws an alarm if you set it too low.
 

PigLover

Moderator
Jan 26, 2011
2,967
1,278
113
You could try raw ipmi commands.

Some reference material from here: Reference Material - Supermicro X9/X10/X11 Fan Speed Control
I wrote that resource. I didn't respond before because I did not believe it will work with the X8 MB. But take a look and let us all know how it goes - perhaps we can update the resource.

One key thing to look for before you get too far: does your MB set the fan mode (Optimal, Heavy-IO, Full) in the BIOS or on the IPMI screens? If the fan speed is managed from the BIOS then the resource @i386 pointed out won't help you - but if you set via IPMI then there is hope that it might work.
 

Patrik Dufresne

New Member
Oct 19, 2016
16
1
3
35
Try ES Energy Saver mode.
If that's not enough, I think there's a way to do it with ipmitool but I'm not familiar with the details.
Also not sure if the board throws an alarm if you set it too low.
Yep, I've set the fan control speed to "Energy Saving/ES". The fan does down to 6500RPM.

I cannot change the Fan speed in IPMI. I need to change it in BIOS.

Code:
$ sudo ipmitool raw 0x30 0x70 0x66 0x01 0x00 0x32
[sudo] password for debian:
Unable to send RAW command (channel=0x0 netfn=0x30 lun=0x0 cmd=0x70 rsp=0xcc): Invalid data field in request
 

Terry Kennedy

Well-Known Member
Jun 25, 2015
1,067
506
113
New York City
www.glaver.org
Yep, I've set the fan control speed to "Energy Saving/ES". The fan does down to 6500RPM.
How close is the X8DTL-iF to the X8DTH-iF? I have the latter and the fans run between 1900 RPM and 3500RPM. This is with 2 * E5620, 96GB (12 * 8GB) and 16 * 8TB SAS drives:


I cannot change the Fan speed in IPMI. I need to change it in BIOS.

Code:
$ sudo ipmitool raw 0x30 0x70 0x66 0x01 0x00 0x32
[sudo] password for debian:
Unable to send RAW command (channel=0x0 netfn=0x30 lun=0x0 cmd=0x70 rsp=0xcc): Invalid data field in request
If I'm remembering right, the Supermicro knowledgebase article said that only applied to certain newer boards and doesn't work on the X8's.
 

Terry Kennedy

Well-Known Member
Jun 25, 2015
1,067
506
113
New York City
www.glaver.org
With Evergy Saving, the fan run at 6500RPM. Mine is installed in a 6016T-MTLF. It's a 1U server.
With 1RU, you almost certainly have passive CPU heatsinks. And the 1RU chassis fans don't move as much air as the ones in the taller chassis, so that probably explains the higher speeds. Do the various IPMI temperature sensors report consistent values, or does it think that one temperature is higher than the rest? The DIMMs in my X8DTH-iF systems report their temperatures, and I had one once that was reporting an incorrect (higher than normal) temperature and the system fans would ramp up trying to cool it.
 
  • Like
Reactions: AlphaG

Patrik Dufresne

New Member
Oct 19, 2016
16
1
3
35
FAN 1 | 6889.000 | RPM | ok | 1600.000 | 1681.000 | 1764.000 | 8100.000 | 8281.000 | 8464.000
FAN 2 | 6889.000 | RPM | ok | 1600.000 | 1681.000 | 1764.000 | 8100.000 | 8281.000 | 8464.000
FAN 3 | 6889.000 | RPM | ok | 1600.000 | 1681.000 | 1764.000 | 8100.000 | 8281.000 | 8464.000
FAN 4 | 6889.000 | RPM | ok | 1600.000 | 1681.000 | 1764.000 | 8100.000 | 8281.000 | 8464.000
FAN 5 | 6889.000 | RPM | ok | 1600.000 | 1681.000 | 1764.000 | 8100.000 | 8281.000 | 8464.000
FAN 6 | na | | na | na | na | na | na | na | na
CPU1 Vcore | 0.936 | Volts | ok | 0.776 | 0.800 | 0.824 | 1.352 | 1.376 | 1.400
CPU2 Vcore | 0.944 | Volts | ok | 0.776 | 0.800 | 0.824 | 1.352 | 1.376 | 1.400
CPU1 DIMM | 1.520 | Volts | ok | 1.288 | 1.312 | 1.336 | 1.656 | 1.680 | 1.704
CPU2 DIMM | 1.512 | Volts | ok | 1.288 | 1.312 | 1.336 | 1.656 | 1.680 | 1.704
+5 V | 5.088 | Volts | ok | 4.416 | 4.448 | 4.480 | 5.536 | 5.568 | 5.600
+5VSB | 5.056 | Volts | ok | 4.416 | 4.448 | 4.480 | 5.536 | 5.568 | 5.600
+12 V | 12.031 | Volts | ok | 10.600 | 10.653 | 10.706 | 13.250 | 13.303 | 13.356
-12 V | -12.292 | Volts | ok | -13.650 | -13.456 | -13.262 | -10.546 | -10.352 | -10.158
VTT | 1.120 | Volts | ok | 0.808 | 0.816 | 0.824 | 1.320 | 1.336 | 1.352
+3.3VCC | 3.312 | Volts | ok | 2.880 | 2.904 | 2.928 | 3.648 | 3.672 | 3.696
+3.3VSB | 3.264 | Volts | ok | 2.880 | 2.904 | 2.928 | 3.648 | 3.672 | 3.696
VBAT | 3.120 | Volts | ok | 2.880 | 2.904 | 2.928 | 3.648 | 3.672 | 3.696
CPU1 Temp | 0x0 | discrete | 0x0000| na | na | na | na | na | na
CPU2 Temp | 0x0 | discrete | 0x0000| na | na | na | na | na | na
System Temp | 36.000 | degrees C | ok | 2.000 | 3.000 | 4.000 | 90.000 | 91.000 | 92.000
P1-DIMM1A | 36.000 | degrees C | ok | -9.000 | -7.000 | -5.000 | 65.000 | 70.000 | 75.000
P1-DIMM2A | 37.000 | degrees C | ok | -9.000 | -7.000 | -5.000 | 65.000 | 70.000 | 75.000
P1-DIMM3A | 35.000 | degrees C | ok | -9.000 | -7.000 | -5.000 | 65.000 | 70.000 | 75.000
P2-DIMM1A | 35.000 | degrees C | ok | -9.000 | -7.000 | -5.000 | 65.000 | 70.000 | 75.000
P2-DIMM2A | 35.000 | degrees C | ok | -9.000 | -7.000 | -5.000 | 65.000 | 70.000 | 75.000
P2-DIMM3A | 36.000 | degrees C | ok | -9.000 | -7.000 | -5.000 | 65.000 | 70.000 | 75.000
Chassis Intru | 0x0 | discrete | 0x0000| na | na | na | na | na | na
PS Status | 0x0 | discrete | 0x00ff| na | na | na | na | na | na
The value reported by the DIMM seams to be in normal range.
IMO, the Winbound chipset W83627DHG-P is detected by the kernel and I loaded the proper driver w83627ehf. I tried to change the value directly using the sysfs (/sys/devices/platform/w83627ehf.2576) but whatever the value I set, it doesn't seam to affect the fan speed.
 

Patrik Dufresne

New Member
Oct 19, 2016
16
1
3
35
After some googling and digging. Linux is loading two driver for the BCM: w83627ehf and w83795g
dmesg has the following output.
[ 14.901486] w83627ehf: Found W83627DHG-P chip at 0xa10
...
[ 15.949971] i801_smbus 0000:00:1f.3: SMBus using PCI Interrupt
[ 15.965589] i2c i2c-0: Found w83795g rev. B at 0x2f
[ 15.966552] w83795 0-002f: Enabling monitoring operations
[ 15.971561] w83795 0-002f: PECI agent 1 Tbase temperature: 100
[ 15.972033] w83795 0-002f: PECI agent 2 Tbase temperature: 100
In sysfs, I previsouly found `/sys/devices/platform/w83627ehf.2576` but I also found another path `/sys/devices/pci0000:00/0000:00:1f.3/i2c-0/0-002f` provided by driver w83795g.

I've also came across this post:
Re: w83795 fan control not working — LM Sensors
Re: w83795 fan control not working — LM Sensors

With some trial and error, I manage to have some control over the FAN Speed as follow:

/sys/devices/pci0000:00/0000:00:1f.3/i2c-0/0-002f
echo 1 | sudo tee pwm1_enable
echo 25 | sudo tee pwm1

But it doesnt always work. The behaviour is unpredictable. Maybe I will need to write directly into the registry.
 

PigLover

Moderator
Jan 26, 2011
2,967
1,278
113
...But it doesnt always work. The behaviour is unpredictable. Maybe I will need to write directly into the registry.
The problem you are having is that the BMC and the BIOS are competing for control.

Its great that you've found a route to set the speeds - but the reason it is "unpredictable" is because the code in the BIOS is still running, monitoring speeds and temps, and attempting to make adjustments. Sometimes your settings will work (because they happen after the BIOS has set things) and sometimes they won't (because the BIOS code will come in and re-set the fan speeds after you do). Other times it will appear to work and you'll come back later and find them changed (because the BIOS code decided that the temps triggered a fan speed change).

Try this: in the BIOS, set the fan speeds to "FULL". This should cause the fans to be set to full speed and then the BIOS monitoring code won't run again because it thinks the fans are running full speed. Then do your magic incantations to set the speed via the BMC...they should work reliably and should stick.

Only problem is that you'll have to arrange to have this done on reboot, and between the time that the BIOS POSTs and your settings get set up you'll have loud fans.
 

Patrik Dufresne

New Member
Oct 19, 2016
16
1
3
35
Well, after reading the code. It seams the driver is buggy when used with IPMI. The driver tries to override the chipset registry (erasing value set by BIOS). So I disable both driver: w83627ehf and w83795g. Now I attempt to directly write into the registry based on w83795g implementation and http://www.nuvoton.com/resource-files/Nuvoton_W83795G_W83795ADG_Datasheet_V1.43.pdf

I manage to increase the FAN Speed by updating the Smart FAN IV Temperature and DC/PWM Register (SFIV). But lowering the value in this table doesn't have any effect.

I still need to read all the datasheet to understand in details how the PWM is computed. Maybe there is a register with a minimal pwm value...
 

thekingmen

New Member
Mar 20, 2017
3
4
3
35
Hey Patrick, and other people searching to control W83795G chipset.
Just wanted to tell that I am enhancing your python script to view more information and change more settings. I have no release yet, but currently it looks like this :

Code:
Fan1
  Mode : Smart Fan mode
  Fan Output Value (FOV): 29.8%
  Temperature to Fan mapping Relationships Register (TFMR): fan linked to
  Smart Fan Control Table (SFIV)
   21C   21C   21C   21C   21C   31C
   29%   29%   29%   29%   29%   50%

  Fan Output Nonstop Value (FONV): 6%
  Fan Output Stop Time (FOST): never stop
  Critical Temperature to Full Speed all fan (CTFS): 74
  Hystersis of critical temperature: 0C
  hystersis of operation temperature: 0C

Fan2
  Mode : Smart Fan mode
  Fan Output Value (FOV): 29.8%
  Temperature to Fan mapping Relationships Register (TFMR): fan linked to 
 
  Smart Fan Control Table (SFIV)
   21C   21C   21C   21C   21C   31C
   29%   29%   29%   29%   29%   50%

  Fan Output Nonstop Value (FONV): 6%
  Fan Output Stop Time (FOST): never stop
  Critical Temperature to Full Speed all fan (CTFS): 74
  Hystersis of critical temperature: 0C
  hystersis of operation temperature: 0C

Fan3
  Mode : Manual mode
  Fan Output Value (FOV): 30.2%

Fan4
  Mode : Manual mode
  Fan Output Value (FOV): 30.2%

Fan5
  Mode : Manual mode
  Fan Output Value (FOV): 30.2%

Fan6
  Mode : Manual mode
  Fan Output Value (FOV): 30.2%

Default Fan Speed at Power-on (DFSP): 25%
Fan output step up time: 0.1 sec
Fan output step down time: 0.1 sec
Basically, I have made some research on how to properly set the fan speed reliably on this chipset for an supermicro X8 motherboard (X8DTi-F), and there was not a lot of options. As I have put a lot of time for that research and looking for the best solution and tools I would like to note it somewhere. It should be useful for other people than me.

The various solutions are
1. Changing the fan profile in the bios. This solution don't work. Bios should do their job and configure the chipset properly, but they don't. I have two computer with this chipset. The server allow to set the fan "duty", which basically correspond to a fixed fan speed of 30%, 40%, 70% and 100% for low, perfomance and so on. The other motherboard is basically the same thing but with a lower duty starting point. In both cases, the fans will dynamically scale based on the temperature, they will stay at their lowest duty at all times. On the server board, 30% is too loud and overkill, on the desktop board it's usually not enough, but it not good when the cpu gest to 100% for long perios of time with inadequate cooling.
2. changing the fans to more quiet and less efficient fans. As this board have an BMC, it also requires to use ipmitool to change the fan treshold to lower rpm, or the bmc will kick all fans to maximum speed as it thinks they are falling. This solution does work, but it needs more investisment, and probably case modding and time to search for compatible fans.
3. There are raw ipmi command that can be used to change the fan duty of Supermicro X9 and X10 motherboard. These don't work with X8.
3. Linux FanControl/pwmconfig/linux perl script/freenas script that control fans based on hdd and cpu/any other driver or userspace fan monitoring software : they all suffer from the same issue. As PigLover told above, and as documented here :
w83795 fan control not working
the BMU (board management unit, the thing that allow to control the computer from ipmi) will ping the fan control chipset from time to time to get information about the fan speed. At the same time, to use any of those programs, the computer must load a driver that will ping the same chip with the same interface. As two system use the chip at the same time, there will be conflict. When modifying the configuration of the driver, I can see ipmitool returning wrong data from the sensor. This conflict makes any of these programs unreliable and thus they should not be used. If the linux driver stop working completly because of the conflict, the computer lose it's thermal solution and might overheat if the last fan speed was set low and the cpu now work at 100%. The same could happen if the operating system stall and the thermal functions handled by fancontrol stop working.
To prevent these issue, one would have to disable ipmi, which is too useful to be done in most cases, or simply skip that solution.


4. One could use the base of the fancontrol, the os driver, to set a fixed fan speed to a low value. Instead of having 2 system pooling regularely the chipset and conflicting, the bmu would retain control most of the time, and the user would set the fan speed once per boot, which should work reliably (and does according to statistics here).
Downside is that we lost the ability to increase and decrease depending on temperature. If the goal is to set to a low noise, and the computer get in a loop which uses 100%, hardware could be damaged because of lack of thermal control.

5. Based on this idea, One could use the linux driver w83795 to control the speed. The driver will directly poke the hardware to get information and configure it's fan mode.
w83795 has an experimental fan mode. It will stay experimental forever, as it has been for the last 5 years. From what I looked at the code, it is incomplete and undocumented. It may or may not work based on your bios configuration.

This bring us to Patrik Dufresne solution, and the solution that I also choose.

6. The w83795 chipset already contains functionnality to modify fan speed to adjust temperature based on the cpu heat. A good way to fix the noise issue would be to reconfigure the chipset to a sane configuration. This would be done one time, so would have less probability to conflict with the bmu board querying at the same time. This solution would be managed completly by the chipset at the hardware level, continuing to protect the system when the OS stall. It's a hacky solution, but right now the best solution that I have in mind.

At this point I read the w83795 specification available here
Hardware Monitor,Desktop,Server,Notebook, Networking,Storage,NCT7,W83 - Desktop & Server Series
to find what it does allow and how it can be configured. As Patrick point out, the chipset is capable of a lot of things, and the bios are just too shitty to expose all of these functionnality to the user. The Thermal Cruise and Smart Fan allow the bios to either set a target temperature for the cpu and will handle the fan speed to be near that temperature, or multiple steps to define a fan curve. Too bad the bios set the minimum step "too loud" and all steps to the same speed, disabling all speed control,.

What if we could reconfigure it ? Well we can!

One could expose all the chipset parameter and configured in the w83795 linux driver. The driver already exposes a lot of sensor data like fan speed, temperature and so on. It allow to set the fan speed manually. An experimental flag allow to change the configuration of the automatic fan mode, but it's incomplete. This could could be improved to expose more fan configuration setting in the thermal cruise and smart fan to configure it in user space using shell scripts, the same way one can set the fan speed to manual mode and set a speed.
I tried to read the code in C and understand it but it was just too confused. The code is mostly undocumented, any functionnality of speed control in the experimental flag is undocumented, it's full of macro where it seem you need to look through a lot of base class to get the code that are executed, sysfs flags are created and I can't find where they were setup. The best solution would be to improve the driver, but personally this seems too hard for me.

Patrick made a python script. This script interract with the same hardware register than the driver, and is way easier to read and understand. It is incompleate because it was done for his needs, but it gave me a good base to continue hacking this chipset. By reading the manual, register configuration I was able to extract relevant configuration/sensor like the linux kernel using this program.
I plan to improve it to allow to change the configuration either the smart fan or thermal cruise mode to better value.
This has been a fun ride because I did not know how to interract with i2c devices, but I learn.

The 2 board that I have both have 2 configuration issue
1. the first one is that both are in smart fan mode, but the steps are incorrectly configured. If the cpu is idle/low power, it may be below the first step most of the time, but will still be cooled at the speed defined at the first step. On my server, I cannot even get past the first step at 30% of fan speed when maxing the cpu. The server have also too much high step. A difference of 5 degree between both step change the fan from 40% to 100%. A better configuration would be a very quiet mode at position 1 for when idle, less quiet a position 2 when used lightly and more loud configuration at position 3 to 6.
2. The temperature reported/calculated by the chipset are off when compared with the configured temperature point.
I have intel cpu, and this chip is configured by the bios to query the temperature using PECI protocol. This peci never report the temperature of the cpu as a degree, but report the temperature of the cpu compared to it's critical temperature. Instead of reporting 27 celcius, it will report in my case -42. The cpu maximum temperature before thermal throttle start is 79 celcius (which represent 0 peci), and at 27 degree is it as (79-27) = -42 PECI UNIT. I repeat, these are peci units, and not degree, because at low temperature they are not reliable and might show as -127. This interface as been done this way to improve understanding of what is a safe temperature. Absolute temperature like 60 degree would be very hot for old cpu, but newer cpu handle these temperature very well. This way to present the temperature allow fan control units to work better for a broad variety of cpu as the cpu will basically give the maximum temperature it handle.

However Chipset like the w83795 does not support the peci unit in negative, to work around this limitation, they add a base value to the value reported by the cpu so that at all times the reported value would be positive. In my case, the chipset was configured to add 100 to the cpu value, so 100+ (-42) = 58. The problem is, that value is then compared to the celcius degree configured in the thermal cruise and smart fan table. My cpu is at 27 celcius, but the system handle the fan as if it was at 58 celcius, which is totally wrong.

I am unsure yet which of the solution that I will take, either allow to configure the base unit (100 in this example to a better one so that the resulting calculation is more near the real temperature. Then keeping real celcius temperature in the fan configuration tables. The selected value must be high enough to never fall into negative.

or I could convert the temperature shown and configured to and from related peci value by running a program to map each peci value to a degree for a specific cpu.

or I could say that these configuration are stupid and instead of trying to show false number, I would simply input temperature as peci value to the critical point, like the cpu report.
if done like this, it would look like
Smart Fan Control Table (SFIV)
-40 -30 -20 -15 0 0
8% 15% 40% 80% 100% 100%
Currently I am thinking more about the third option. It is harder to understand and less user friendly, but is more accurate as it exactly like the real hardware control.


Hope I could help some people understand the different solution, this solution, understand how to hack the chip. I hope I have time to finish this software and be done with it soon enough, reading the peci documentation and the chipset and programming a software to hack the thermal control unit of my board because the bios sucks takes just too much time :)
 

sfbayzfs

Active Member
May 6, 2015
247
104
43
SF Bay area
FWIW, I was playing with IPMI control of fan speeds with a local friend on different Supermicro mobos a few months ago - X9SCL-F/X9SCM-F only let you set the duty mode like in the BIOS, but X10SLH-F/X10SL7-F took IPMI raw commands to set thresholds and 1% granularity duty cycles - x9 either took the same commands but did nothing or said they were invalid.
 
  • Like
Reactions: nthu9280

StevenDTX

Active Member
Aug 17, 2016
421
140
43
FWIW, I was playing with IPMI control of fan speeds with a local friend on different Supermicro mobos a few months ago - X9SCL-F/X9SCM-F only let you set the duty mode like in the BIOS, but X10SLH-F/X10SL7-F took IPMI raw commands to set thresholds and 1% granularity duty cycles - x9 either took the same commands but did nothing or said they were invalid.
I havent been able to get the raw commands to work on any X9 board either.
 
  • Like
Reactions: nthu9280

thekingmen

New Member
Mar 20, 2017
3
4
3
35
Hello,
I am very lazy so that script never got finished.
But I figured out what's the issue with my server. Basically, when you set the bios fan to whisper, it configure the fan controller to the smart fan mode (auto fan speed based on temperature, with levels to define the step up/down), with the mode you selected as the minimum mode. On my X8DTI-F board, setting it to whisper will set the min fan speed to 30% which is still quite loud. It's easy to poke and change value of the fan controller minimum level to a smaller value (Nuvoton W83795ADG in this case) and have it automatically scale to the next level, but it still take a shitload of time to make a comprehensive program to define whole new fan speed levels in smart fan mode, fixed mode, based on peci temperature (impossible to understand) which I never finished because I am very lazy. However, if you request it, I will share the code and write documentation on how to hack that chip with all the research I've made.

If you with to hack it yourself, you can read this pdf (found online) to learn the different mode of action.
Nuvoton_W83795G_W83795ADG_Datasheet_V1.43.pdf
 
  • Like
Reactions: Mattias Jonsson

Mattias Jonsson

New Member
Oct 31, 2017
3
0
1
36
Hello,
I am very lazy so that script never got finished.
But I figured out what's the issue with my server. Basically, when you set the bios fan to whisper, it configure the fan controller to the smart fan mode (auto fan speed based on temperature, with levels to define the step up/down), with the mode you selected as the minimum mode. On my X8DTI-F board, setting it to whisper will set the min fan speed to 30% which is still quite loud. It's easy to poke and change value of the fan controller minimum level to a smaller value (Nuvoton W83795ADG in this case) and have it automatically scale to the next level, but it still take a shitload of time to make a comprehensive program to define whole new fan speed levels in smart fan mode, fixed mode, based on peci temperature (impossible to understand) which I never finished because I am very lazy. However, if you request it, I will share the code and write documentation on how to hack that chip with all the research I've made.

If you with to hack it yourself, you can read this pdf (found online) to learn the different mode of action.
Nuvoton_W83795G_W83795ADG_Datasheet_V1.43.pdf
If you're willing to I'd be most interested in that documentation. I have the X8DTL-3f board with the same chip and I've been trying to figure this out myself for a while.
 
Last edited:

thekingmen

New Member
Mar 20, 2017
3
4
3
35
sorry for the late reply
You need to know that this script is still unfinished, and I don't plan to really work on it since the loudness of the fan problem is fixed (server in another room). However I will answer your questions. This script cannot be used for a simple user, but can be improved by a developper.
Python script to edit the X8DTL-iF Registry to control fan speed. · GitHub

I am soo impressed with my previous post explaining everything. I was kind of down having to write all of this in today post but hehe it's already done.
First,you have to unload the module used by sensors so that you don't conflict with it
#modprobe -r w83795
after, load i2c-dev, provided by libi2c-dev on debian. this one allow this python script to interract with th i2c interface of the thermal control chip.
#modprobe i2c-dev

then as written above, you will need the "Nuvoton_W83795G_W83795ADG_Datasheet_V1.43" to understand the register and their definitions. I have written more register at the top of the file with the array and names, but to understand the definition, you need the guide (and then again, it's not that clear).
One of the issue that was confusing me a lot is that it's clearly written that there is only support for 8 fan and 6 temp. However sometimes when looking at the register, it will show 8 temp. those are wrong, and you need to remember what's written at page 8.
I have converted most of patric hexedecimal to binary as I handle those better (not good yet to memoryze my hexa).
To do the development of this software, I used i2c-dump to dump one table of the ranked i2c table and also i2cset to set individual value. i2cset to set the page index at pos 0 0 (but you can use i2cdump for that - just keep in mind that you will erase the interternal data (bit 7 to 3).
here are some example :
how to dump (it will ask the i2c device number - these can change from pc to pc. the address 0x2f will probable not change).

#i2cdump 0 0x2f

my chip show at position 00x00 "02". this means that it's 0000 0010 - so accortind to the doc, bank 2 is selected. to change the bank, I can.

#i2cset 0 0x2f 0x00 00
I switched to bank 0. If I do a i2cdump, I will see totally different data. only the register 0x00 will always be present.
Note that, as said above, because you are playing with the i2c bank register, this is single application, other program cannot know that you have changed it and it will cause error. ipmitools sensors will report the fans in a different order and there might be more, and the linux driver might not work correctly. that's why I ask to unload it first. Also note that the linux driver seems to clean on load the reserved field of byte 0x00 by default - while this program preserve it.

hey... reading the code I am thinking that w83795_set_bank will not work because it does a binary or on the bank field, but and this will allow only to switch from bank 0 to x, but not x back to 0. up to you to verify that.

I don't know about you, but I had lot of fun to play with this chip in binary in an unknown language. Hope it will be the same for you.
have fun.