Closed VanessaE closed 5 years ago
Sounds like an issue with the driver. Since the scrypt maintained disappeared, you may need to submit a patch to fix it to make any progress on it.
I can confirm this issue exists on my drivers as well...I don't think its driver related, but ungraceful exit of vcom driver/way bfgminer deals with USB disconnects. Ill dig deeper.
In the meantime, @luke-jr can you at least fix the problem of bfgminer not honoring patterns in device strings? One ought to be able to do something like -S gridseed@/dev/gridseed*
, but nothing I've tried in that regard works (see https://github.com/luke-jr/bfgminer/issues/610#issuecomment-301312616 for details). That would at least work around the problem of requiring one to cycle all of the miners' USB connections to bring back ones that briefly drop out.
Can something please be done about these issues? This 100% CPU problem is quite old and very infuriating.
Considering there have been no commits for well over a year, should bfgminer be considered an abandoned project?
Guess this has been abandoned (and gridseeds are unprofitable most of the year now, anyways)
This is bfgminer compiled from source, at commit 9f781b872db9a91f741bb8d08d1e60383a84a0b2, running on Debian 9.1, controlling several gridseed "orbs" and blades. CPU and GPU mining are not enabled (at least not intentionally).
If one of my devices disappears, for example if its USB cable gets unplugged (or stepped on by my cat :stuck_out_tongue_closed_eyes: ), the kernel recognizes the disconnect event and reports it via
dmesg
, but this causes bfgminer to immediately start spinning at least one CPU core at 100%.If I were to then simply shut off the USB hub, or unplug its main USB cable from the computer, that of course would cause several devices to disappear all at once. bfgminer seems to hog one CPU core per device that goes away, so it'll spin all six of my cores at 100% on such an event.
bfgminer does indicate that the disconnected devices are failing to return work, but it does not mark them as "sick" or "dead" or otherwise gracefully disconnect from them.
Since bfgminer is trying to keep its in-use device names "open", reconnecting a missing device causes the kernel/udev/whatever to give it a new name. bfgminer won't be looking for that new name (it'll usually be out of range as implied by the script below), so it doesn't react to the reconnect event.
bfgminer will continue to eat CPU indefinitely, until I exit. I can simply press 'q' or Ctrl-C when it gets into this state, so it's not hard-locked. My keepalive script restarts bfgminer after a couple of seconds, though I usually have to kill the script, reset my devices, and restart it to get them all numbered right so bfgminer will see them.
I only explicitly enabled scrypt and gridseed drivers at compile time, but of course a bunch of other stuff got compiled in by default, so here is config.h: