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)

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).

- 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?

From http://smbus.org/specs/smbus20.pdf:
"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?

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.