AMU10 has gone zombie about one hour in to a 3.8.2 run.
Hot-swap did not fix it, but Q and a restart did. (Win7 64 zipped version).
I believe I've finally found out why they weren't hotplugging again, and it would affect any operating system, not just windows. I have committed a fix for it into master git, and here's a binary to try out:
http://ck.kolivas.org/apps/cgminer/temp/cgminer-undead.exeOK, thanks - I'll switch to "undead" now. My present run of 3.8.2 has gone 23 hours error-free - these zombies sure know how to hide.
Edit: "undead" version is going well,
7 12 24 hours into the run. Somewhere along the way AMU 4 and 11 got reallocated to 13 and 14 - I'm guessing these were zombie wannabes that got "cured". Best version yet, it seems.
Edit: after about 31 hours,
"undead" got its first zombie, but it hot-plugged and resumed hashing with no other intervention. The naming seemed a bit odd. The zombie was flagged as AMU4 (but see edit line above). It was reallocated to 16 when it restarted. Names are presently AMU0 1 2 3 5 7 8 10 12-16, with BAL1 (never 0?) between AMU12 and 13.
Edit: over
48 75 hours into the run now. No new incidents. I switched another machine to "undead" about
12 36 hours ago - it has had a couple of zombies but they could be hot-plugged with no other problems. Best version yet, for my purposes.
Edit: One hour later, AMUs 4,6,7 and 8 were flagged as zombies. Great excitement - none of them would hot swap. Windows gave never-before-seen error messages about hardware errors on USB devices and tried unsuccessfully to install drivers. Disconnecting the hubs and replugging them brought everything back to normal, with the AMUs now allocated as 17-29. The (undead) run continues.