View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0002388||SpeedFan||Hardware support||public||2015-05-03 02:49||2019-04-09 14:04|
|Platform||Intel||OS||Windows||OS Version||Vista SP2|
|Target Version||Fixed in Version|
|Summary||0002388: (4.51!) SMbus communication fails after returning from standby/sleep|
|Description||(This is for 4.51 but can only choose 4.50 in form)|
After returning from Standby, Speedfan fails to communicate with the SMbus and uses "100%" (single threaded so in actuality 50%) CPU. The log window shows lots of:
SMBus msg: 01:45:24.565 Unsuccessful SELB $2A to$[...]
SMBus Timeout waiting IDLE SMBus $2E (STS=$F[...]
- unfortunately the UI is so unresponsive that I can't copy text out of the log window so I don't see the whole lines
During this time, right-clicking the notification icon does not produce a menu and instead freezes the log window spam for a second or so.
The UI is not wholly unresponsive, the config can be opened and navigated but each action takes a second or so to happen.
See: debug-for-standby-and-repower.txt (01:38 is where the fun starts)
RESTARTING SPEEDFAN AFTER PROBLEMS:
If I shut speedfan down at this point and start a second copy, it complains about not finding several temperature sensors and fan controllers, and does not load my fan control curves.
However, the UI seems to show everything it should be showing (except with the CPU reading at the bottom of the list instead of at the top where it usually sits.. odd). And Manually fiddling Pwm3 in the UI speeds my fan up and down. (I do not have anything controllable on Pwm1/2, so can't test those).
CPU does not go wild in this scenario.
|Steps To Reproduce||Method 1:|
Start computer. Start Speedfan. Standby the computer (wait for full standby). Resume.
Start computer. Standby the computer (wait). Resume. Start Speedfan.
This causes the same behavior as in "RESTARTING SPEEDFAN AFTER PROBLEMS" above.
|Additional Information||The computer is very clean, just reinstalled, fully updated, installed drivers, installed Chrome. No other fan management or hardware watching/tweaking software.|
"Method 2" COULD suggest that the root of this is a BIOS/firmware problem that you can't really fix - except it's still funny that I can see readings and control my fans.
Either way I thought I should report it - you might want to slow down the timer when errors like these happen so Speedfan doesn't eat 100% CPU and cause an overheating problem itself.
My temp fix for now is to disable standby instead of risking frying the computer.
All logs and information from the speedfan folder I could find are attached in the zip file.
|Motherboard Model||Intel D945PSN|
|Video Card Model||Fanless ASUS "NVIDIA GeForce 6600 LE" (as identified by nvidia's drivers)|
speedfan 4.51 smbus standby bug 2015-05-03.zip (192,263 bytes)
||Randomly tried /NONVIDIAI2C - no change.|
smbdebugs.zip (8,692 bytes)
||Interesting. /SMBDEBUG shows that SpeedFan decides to scan two entirely different addresses before ($2000) and after standby ($EFA0).|
||Tried upgrading from ancient BIOS (2005) to newest available (2008) since I saw stuff about SMB in Intel's release notes. No change.|
For testing purposes, I now did:
- Wipe all speedfan*.cfg files
- Reboot computer
- Start speedfan
- works (uses $efa0 bus)
- Restart speedfan
- still works (still uses $efa0 bus)
Huh? So $EFA0 works just fine after resume, but $2000 is gone.
- Rename my Fan[1-4] to Fan[1-4]-efa0 so I know which address they are associated with
- Reboot computer
- Start speedfan
- Speedfan only scans the $2000 bus
- No Fan[1-4]-efa0 in the UI any more, only Fan[1-4]
What's going on here? Is the SMBus moving during standby permitted by the spec? Or is the SMBus simply accessible BOTH via 2000 and $EFA0 after startup but not after standby? (assumes SpeedFan cleverly skips duplicates during scanning somehow - I have no idea if it does or not)
Sorry for spam - I'm a novice to i2c and smbus specs. Yes, ARP-capable SMbus devices are allowed to change their BUS address when "unplugged and reconnected". I guess standby+resume fulfills that requirement?
Is this related to the "address" that you show in SpeedFan or is it another class of address?
"Assigned Slave Address: The address assigned to a slave device by the ARP Master. This address is then used for accesses to the device’s core function. Legal values are in the range 0010 000 to 1111 110 with some exceptions (associated with reserved addresses and those consumed by Fixed Slave Address devices)."
Either way -- could this $2000->$EAF0 change explain other standby/sleep issues in the bug db?
speedfan-cfgs-that-work-after-resume.zip (1,682 bytes)
||Changed my workaround: changed BIOS settings to use ACPI S1 standby instead of S3. More devices remain powered so the SMbus stays in place. Unfortunately, fans etc are still spinning so not really the best solution.|
|2015-05-03 02:49||mikeclueby4||New Issue|
|2015-05-03 02:49||mikeclueby4||Status||new => assigned|
|2015-05-03 02:49||mikeclueby4||Assigned To||=> alfredo|
|2015-05-03 02:49||mikeclueby4||File Added: speedfan 4.51 smbus standby bug 2015-05-03.zip|
|2015-05-03 03:07||mikeclueby4||Note Added: 0007803|
|2015-05-03 03:18||mikeclueby4||File Added: smbdebugs.zip|
|2015-05-03 03:20||mikeclueby4||Note Added: 0007804|
|2015-05-03 04:02||mikeclueby4||Note Added: 0007805|
|2015-05-03 04:32||mikeclueby4||Note Added: 0007806|
|2015-05-03 04:44||mikeclueby4||Note Added: 0007807|
|2015-05-03 04:54||mikeclueby4||Note Edited: 0007807||View Revisions|
|2015-05-03 04:57||mikeclueby4||File Added: speedfan-cfgs-that-work-after-resume.zip|
|2015-05-03 04:57||mikeclueby4||Note Edited: 0007806||View Revisions|
|2015-05-03 05:39||mikeclueby4||Note Added: 0007808|
|2015-05-03 05:44||mikeclueby4||Tag Attached: standby|
|2015-05-03 05:44||mikeclueby4||Tag Attached: smbus|
|2015-05-04 01:05||mikeclueby4||Note Edited: 0007807||View Revisions|