{"action":"created","issue":{"url":"https://api.github.com/repos/davidker/unisys/issues/15","repository_url":"https://api.github.com/repos/davidker/unisys","labels_url":"https://api.github.com/repos/davidker/unisys/issues/15/labels{/name}","comments_url":"https://api.github.com/repos/davidker/unisys/issues/15/comments","events_url":"https://api.github.com/repos/davidker/unisys/issues/15/events","html_url":"https://github.com/davidker/unisys/issues/15","id":140663558,"number":15,"title":"clean up controlvm_periodic_work()","user":{"login":"selltc","id":12817577,"avatar_url":"https://avatars.githubusercontent.com/u/12817577?v=3","gravatar_id":"","url":"https://api.github.com/users/selltc","html_url":"https://github.com/selltc","followers_url":"https://api.github.com/users/selltc/followers","following_url":"https://api.github.com/users/selltc/following{/other_user}","gists_url":"https://api.github.com/users/selltc/gists{/gist_id}","starred_url":"https://api.github.com/users/selltc/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/selltc/subscriptions","organizations_url":"https://api.github.com/users/selltc/orgs","repos_url":"https://api.github.com/users/selltc/repos","events_url":"https://api.github.com/users/selltc/events{/privacy}","received_events_url":"https://api.github.com/users/selltc/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":{"login":"selltc","id":12817577,"avatar_url":"https://avatars.githubusercontent.com/u/12817577?v=3","gravatar_id":"","url":"https://api.github.com/users/selltc","html_url":"https://github.com/selltc","followers_url":"https://api.github.com/users/selltc/followers","following_url":"https://api.github.com/users/selltc/following{/other_user}","gists_url":"https://api.github.com/users/selltc/gists{/gist_id}","starred_url":"https://api.github.com/users/selltc/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/selltc/subscriptions","organizations_url":"https://api.github.com/users/selltc/orgs","repos_url":"https://api.github.com/users/selltc/repos","events_url":"https://api.github.com/users/selltc/events{/privacy}","received_events_url":"https://api.github.com/users/selltc/received_events","type":"User","site_admin":false},"milestone":null,"comments":4,"created_at":"2016-03-14T12:43:49Z","updated_at":"2016-03-26T02:46:19Z","closed_at":null,"body":"Creating this ticket as a result of some observations concerns pointed out by @davidker:\r\n\r\n> I’m trying to wrap my head around the function controlvm_periodic_work, specifically the variable\r\n> poll_count. Is it really just sleeping for the first 250 iterations of the function and then allows it to go\r\n> through?  Why 250? Why do we even need to sleep that long, to wait for other things to come\r\n> through, I thought that was what clientregwait was (right above it). Just the whole process of\r\n> poll_count is confusing me at the moment and I’m just waiting for the upstream to ask us about it. \r\n>\r\n> Also what does handle_command_failed do?  Are we supposed to error if it fails a second time?\r\n> Why are we retrying it and I’m not sure how we every respond with failure if we always fail\r\n> handle_command. Do we never actually fail it? \r\n>\r\n> Maybe I’ve been up to long today (had to get up an hour earlier than normal), but I think there is\r\n> improvement in this function. \r\n\r\nBased upon this excerpt in the https://ustr-svn-1.na.uis.unisys.com/trac/spar/changeset/6443 / r6443 (9 years ago!) log comment, the purpose of poll_count is solely to make testing scenarios work better, therefore I think we can safely remove it:\r\n\r\n> This changeset also changes the way in which controlvm messages are simulated (for testing\r\n> purposes) in the ApplianceOS environment. (The simulation applies when the visorchipset driver is\r\n> started with testvnic=1 and testmsg=1, which are currently the default settings.) Previously, the\r\n> simulated messages would not start until AFTER the controlvm channel was discovered. For CM2\r\n> testing, this meant that you actually needed to start the driver on the host side that was going to\r\n> send the controlvm messages. This behavior was changed so that the simulated messages start\r\n> automatically about 1 minute after the visorchipset driver is loaded, regardless of whether or not a\r\n> controlvm channel is discovered. This provides the added benefit that testing can also be\r\n> performed in non-CM2 environments.\r\n\r\nI believe `handle_command_failed` attempts to recover from the scenarios where the controlvm channel queue temporarily fills up, resulting in `signalinsert()` errors.  HOWEVER, we never hit this error condition until we started to use the controlvm channel for file transfer operations (`CONTROLVM_TRANSMIT_FILE`) in https://ustr-svn-1.na.uis.unisys.com/trac/spar/changeset/20223 / r20223.  Of course, these file transfer operations are never used in guest environments, so we could arguably simplify things by removing this retry logic.\r\n"},"comment":{"url":"https://api.github.com/repos/davidker/unisys/issues/comments/201687390","html_url":"https://github.com/davidker/unisys/issues/15#issuecomment-201687390","issue_url":"https://api.github.com/repos/davidker/unisys/issues/15","id":201687390,"user":{"login":"davidker","id":11467670,"avatar_url":"https://avatars.githubusercontent.com/u/11467670?v=3","gravatar_id":"","url":"https://api.github.com/users/davidker","html_url":"https://github.com/davidker","followers_url":"https://api.github.com/users/davidker/followers","following_url":"https://api.github.com/users/davidker/following{/other_user}","gists_url":"https://api.github.com/users/davidker/gists{/gist_id}","starred_url":"https://api.github.com/users/davidker/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/davidker/subscriptions","organizations_url":"https://api.github.com/users/davidker/orgs","repos_url":"https://api.github.com/users/davidker/repos","events_url":"https://api.github.com/users/davidker/events{/privacy}","received_events_url":"https://api.github.com/users/davidker/received_events","type":"User","site_admin":false},"created_at":"2016-03-26T02:46:19Z","updated_at":"2016-03-26T02:46:19Z","body":"Thanks Tim. \r\n\r\nI've cherry-picked the patch over to upstream-next. I'm in the process of submitting it and Alex's patches. I'm switching this issue to queued/[upstream-next]."}}