WG x750e - automatic speed adjustment: mbmon going crazy
-
Actually, from reading the data sheet, your approach seems correct. Didn't realize you were the original author. Also, after the chip got hosed, I tried getting the temp using writio/readio and got the same result. Don't know if that's significant.
I suggest you change get_w83627_addr_port() so it exits extended function mode. Let me know if you do and I'll test it here.
Cheers.
-
Hmm, you mean you got an invalid temperature value? What base address did you use?
I'll definitely look at that function, it shouldn't be left in extended mode.
Steve
-
after it was showing 020Bh I used 0290h directly and it gave me 255. For fan speed too.
I will confirm that again on Monday and let you know for sure. I don't have the equipment here.
-
I've confirmed the problem happens outside of WGXepc when the hardware address in 60 and 61 has been altered.
breakwinbond script sets 60 and 61 to a bad value just as I believe WGXepc is doing:
./writeio 0x2e 0x87 ./writeio 0x2e 0x87 ./writeio 0x2e 0x07 ./writeio 0x2f 0x0b ./writeio 0x2e 0x61 ./writeio 0x2f 0x0b ./writeio 0x2e 0xaafixwinbond script restores 60 and 61 to the correct value:
./writeio 0x2e 0x87 ./writeio 0x2e 0x87 ./writeio 0x2e 0x07 ./writeio 0x2f 0x0b ./writeio 0x2e 0x60 ./writeio 0x2f 0x02 ./writeio 0x2e 0x61 ./writeio 0x2f 0x90 ./writeio 0x2e 0xaagetwinbond returns the fan speed and cpu temp:
./writeio 0x0295 0x5a > /dev/null fan=`./readio 0x296 | cut -d: -f2 | tr '[:lower:]' '[:upper:]'` ./writeio 0x0295 0x4e > /dev/null ./writeio 0x0296 0x01 > /dev/null ./writeio 0x0295 0x50 > /dev/null cpu=`./readio 0x296 | cut -d: -f2 | tr '[:lower:]' '[:upper:]'` cpu=`echo "ibase=16; $cpu" | bc` ./writeio 0x0295 0x4e > /dev/null ./writeio 0x0296 0x00 > /dev/null echo "Fan Speed = $fan" echo "CPU Temp = $cpu"Test sequence:
[2.1.5-RELEASE]/tmp(81): WGXepc -f 40 Found Firebox X-E Fanspeed set to 40 [2.1.5-RELEASE]/tmp(81): WGXepc -f Found Firebox X-E Fanspeed is 40 [2.1.5-RELEASE]/tmp(81): WGXepc -t Found Firebox X-E SuperIO sensor 2 reads: 36 [2.1.5-RELEASE]/tmp(81): ./getwinbond Fan Speed = 40 CPU Temp = 37 [2.1.5-RELEASE]/tmp(81): ./breakwinbond Setting 2e to 87 Setting 2e to 87 Setting 2e to 7 Setting 2f to b Setting 2e to 61 Setting 2f to b Setting 2e to aa [2.1.5-RELEASE]/tmp(81): WGXepc -f Found Firebox X-E Fanspeed is ff [2.1.5-RELEASE]/tmp(81): WGXepc -t Found Firebox X-E SuperIO sensor 2 reads: 255 [2.1.5-RELEASE]/tmp(81): ./getwinbond Fan Speed = FF CPU Temp = 255 [2.1.5-RELEASE]/tmp(93): ./fixwinbond Setting 2e to 87 Setting 2e to 87 Setting 2e to 7 Setting 2f to b Setting 2e to 60 Setting 2f to 2 Setting 2e to 61 Setting 2f to 90 Setting 2e to aa [2.1.5-RELEASE]/tmp(81): WGXepc -f Found Firebox X-E Fanspeed is 40 [2.1.5-RELEASE]/tmp(81): WGXepc -t Found Firebox X-E SuperIO sensor 2 reads: 37 [2.1.5-RELEASE]/tmp(94): ./getwinbond Fan Speed = 40 CPU Temp = 36WGXepc uses registers 60 and 61 as the base address from which to build the port numbers for the Index and Data port of the hardware monitor. After register 61 is corrupted, WGXepc returns bad data because it is accessing the wrong ports.
The getwinbond script uses the 295h and 296h ports directly and still gets bad data. I'm guessing this is because changing the value in register 61 changes the circuit path in the LPC bus. The data sheet indicates the LAD pins of the LPC interface are used to control peripheral addressing so maybe this has something to do with it. Just as getting the temp from sensor 2 requires setting the bank before reading the output, 60 and 61 must be setting the correct location for port I/O to work as expected.
As I said, I'm guessing but this seems most likely.
-
Hmm, interesting. Having read back through the code (amazing what you forget ::)) I remember now I added the code to read in the base address correctly because the XTM5 uses a different address. However I think that was before I added the temperature code for the X-e. So the bug that left it in extended function mode may have always been there. However since it also happens in mbmon it's probably not the cause. Anyway it's easy enough to put in a check so I'll do that when I get a chance. Another solution would be to use the B8 bios and read the temperature exported by ACPI via the sysctl. I have this on my home box where the temperature is shown on the dashboard and it hasn't failed yet. It probably only polls the value while the dash is shown though.
Anyway some good progress. :)Steve
-
I've updated WGXepc to include code to check the SuperIO data base address when the X-e model is detected. I've also fixed the bug that left the chip in extended function mode and attempted to rationalise some of the code somewhat. It's still pretty awful though! ::)
Anyway the updated source and binaries are on my Google site as normal. I'd welcome some testing.https://sites.google.com/site/pfsensefirebox/home
One thing I did notice when testing here is that entering something unexpected for the fan speed can result in a setting of 0. I have never tried 0. It really does shut off the fans completely. Do you think that should be possible or should there be some check to make sure a minimum fan speed is maintained?
Steve
-
I will do some testing.
Something weird happened today. The router stopped passing traffic inbound or outbound. Fixed when I rebooted. I noticed the temp from WGXepc kept coming back as 0 and the fanspeed as well. Don't know if this is related to WGXepc. I will update if this happens again.
-
Steve, I tried to install superiotool with this:
pkg_add -r ftp://ftp.freebsd.org/pub/FreeBSD/ports/i386/packages/All/superiotool-20121019.tbzSame command I used before and it worked fine on the other box. Now when I try to use it I get this:
/libexec/ld-elf.so.1: Shared object "libz.so.6" not found, required by "superiotool"Any thoughts?
-
If you're doing this in pfSense 2.1.5 you need to use the FreeBSD 8.3 repo which has now been archived. It lloks like you're using a current repo. Try:
pkg_add -r http://ftp-archive.freebsd.org/pub/FreeBSD-Archive/ports/i386/packages-8.3-release/Latest/superiotool.tbzYou may have to remove whatever you previously installed first and it may have installed some depedencies. :-\
Steve
-
Hi guys,
I had not seen you had been investigating further before today.
Just downloaded the new WGXepc and restarted my auto-speed script.
Let"s see how it behaves now :)
