Almico's Bug Tracker - SpeedFan
View Issue Details
0002388SpeedFanHardware supportpublic2015-05-03 02:492019-04-09 14:04
IntelWindowsVista SP2
Intel D945PSN
Fanless ASUS "NVIDIA GeForce 6600 LE" (as identified by nvidia's drivers)
0002388: (4.51!) SMbus communication fails after returning from standby/sleep
(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: screenshot-after-repower.png
See: debug-for-standby-and-repower.txt (01:38 is where the fun starts)


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.

See: debug-for-restarted-speedfan.txt
See: logwindow-after-restarting-speedfan.txt
Method 1:
Start computer. Start Speedfan. Standby the computer (wait for full standby). Resume.

Method 2:
Start computer. Standby the computer (wait). Resume. Start Speedfan.
This causes the same behavior as in "RESTARTING SPEEDFAN AFTER PROBLEMS" above.
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.
smbus, standby
zip speedfan 4.51 smbus standby bug (192,263) 2015-05-03 02:49
zip (8,692) 2015-05-03 03:18
zip (1,682) 2015-05-03 04:57
Issue History
2015-05-03 02:49mikeclueby4New Issue
2015-05-03 02:49mikeclueby4Statusnew => assigned
2015-05-03 02:49mikeclueby4Assigned To => alfredo
2015-05-03 02:49mikeclueby4File Added: speedfan 4.51 smbus standby bug
2015-05-03 03:07mikeclueby4Note Added: 0007803
2015-05-03 03:18mikeclueby4File Added:
2015-05-03 03:20mikeclueby4Note Added: 0007804
2015-05-03 04:02mikeclueby4Note Added: 0007805
2015-05-03 04:32mikeclueby4Note Added: 0007806
2015-05-03 04:44mikeclueby4Note Added: 0007807
2015-05-03 04:54mikeclueby4Note Edited: 0007807bug_revision_view_page.php?bugnote_id=7807#r741
2015-05-03 04:57mikeclueby4File Added:
2015-05-03 04:57mikeclueby4Note Edited: 0007806bug_revision_view_page.php?bugnote_id=7806#r743
2015-05-03 05:39mikeclueby4Note Added: 0007808
2015-05-03 05:44mikeclueby4Tag Attached: standby
2015-05-03 05:44mikeclueby4Tag Attached: smbus
2015-05-04 01:05mikeclueby4Note Edited: 0007807bug_revision_view_page.php?bugnote_id=7807#r744
2019-02-26 12:07user5535Note Added: 0008938
2019-03-11 11:53user5734Note Added: 0008990
2019-03-11 17:16user5736Note Added: 0008996
2019-03-15 08:34user5734Note Added: 0009024
2019-04-09 14:04user5891Note Added: 0009193
2019-04-09 15:48almicoNote Deleted: 0008938
2019-04-09 15:48almicoNote Deleted: 0009193
2019-04-09 15:49almicoNote Deleted: 0008996
2019-04-09 15:49almicoNote Deleted: 0008990
2019-04-09 15:49almicoNote Deleted: 0009024

2015-05-03 03:07   
Randomly tried /NONVIDIAI2C - no change.
2015-05-03 03:20   
Interesting. /SMBDEBUG shows that SpeedFan decides to scan two entirely different addresses before ($2000) and after standby ($EFA0).
2015-05-03 04:02   
Tried upgrading from ancient BIOS (2005) to newest available (2008) since I saw stuff about SMB in Intel's release notes. No change.
2015-05-03 04:32   
(edited on: 2015-05-03 04:57)
For testing purposes, I now did:
- Wipe all speedfan*.cfg files
- Reboot computer
- Standby
- Resume
- 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)

2015-05-03 04:44   
(edited on: 2015-05-04 01:05)
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?

From [^]
"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?

2015-05-03 05:39   
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.