1. 14 Aug, 2006 1 commit
  2. 14 Jun, 2006 1 commit
    • Mike Hibler's avatar
      Pulled another fix from the anal repository... · 97066a92
      Mike Hibler authored
      No idea why rpc exchanges started failing after updating boss/ops to
      FreeBSD 6.1 or, for that matter, why this really fixes the problem.
      Monitoring the exchanges between client and the RPC serial line didn't
      show any rhyme or reason why some exchanges elicited "Input error" and
      others didn't.  But I noticed that every \r we send to the RPC gets
      echoed back as \r\r\n (and no, it isn't the serial line CR<->NL mapping).
      So I reduced the number of \r (actually \n) we send it and things got better.
      
      This "fix" has been running every 5 minutes for the last hour without
      failure, so I declare it: An Improvement.
      97066a92
  3. 09 Jun, 2006 1 commit
  4. 28 Mar, 2006 1 commit
    • Mike Hibler's avatar
      Attempt to make firewall experiment swapout more robust by addressing a · 69b90e79
      Mike Hibler authored
      couple of MFS booting problems:
       * in the RPC power controller, make sure that an "on" command succeeds
         by checking the status, retrying if it failed (we already did this for
         "off")
       * if nodes fail to boot up the MFS after a power on, try again with a
         power cycle.  I have seen "power on" leave pc600s hung, and a power
         cycle seems to cure it.
      69b90e79
  5. 19 Dec, 2005 1 commit
  6. 12 Dec, 2005 1 commit
  7. 01 Sep, 2005 1 commit
    • Mike Hibler's avatar
      Revamped the RPC syncandsend code yet again. · 931a8a5e
      Mike Hibler authored
      Now we keep reading after we send the command, til we get the next prompt.
      That way we will catch any "Input error" messages and can try again.
      
      The downside is that, for reboots, we wait through the whole 10 second
      countdown before returning to the caller.  Previously we would return
      immediately after issuing the command.
      931a8a5e
  8. 13 Aug, 2005 1 commit
  9. 12 Aug, 2005 1 commit
    • Mike Hibler's avatar
      Ugh! When reading a line, go ahead and return if the string we have · c1c24bfa
      Mike Hibler authored
      read matches the prompt, i.e., don't wait to get a newline.  With the
      new power controller on the rocketport muxes on a pc1500 tipserver,
      even though we send two newlines, we just get back a single prompt
      with no newline.  This would cause us to hang forever waiting for the
      newline.
      
      Note that it did not do this on the same RPCs with the same muxes on
      our ops node (a pc3000).  This could be a bad sign for things to come...
      c1c24bfa
  10. 01 Jul, 2005 1 commit
    • Mike Hibler's avatar
      Add "status" command that can be applied to power controllers · c946abb8
      Mike Hibler authored
      (eg. "power status rpc14-1" or "power status all").
      
      In rpc module, add a "status" function that is called to collect,
      well..status.  This is used by the generic power code, but more importantly,
      by the new "powermon" script (which could have just called "power status",
      but no point in parsing output twice).
      c946abb8
  11. 04 Apr, 2005 1 commit
  12. 15 Mar, 2005 1 commit
  13. 07 Jul, 2002 1 commit
  14. 21 May, 2002 1 commit
    • Robert Ricci's avatar
      Fix for a problem that Mike discovered. The RPC input buffer is · 5a3d2cee
      Robert Ricci authored
      limited to 31 characters, so we can't give commands with more than 8
      outlets. So, we split up the outlets into groups of 8, and issue
      multiple commands, if we are passed too many outlets.
      
      Took some minor re-structuring, since we now may need to sync up with
      the RPC prompt more than once.
      5a3d2cee
  15. 26 Nov, 2001 1 commit
    • Robert Ricci's avatar
      In order to improve experiment startup times, power now sorts nodes by · ebaac553
      Robert Ricci authored
      power controller, and controls all nodes on the same controller at
      once. This is particularly helpful when rebooting nodes connected to
      the RPCs, as you now longer have to wait through the RPCs 'rebooting'
      junk for each node.
      
      power_rpc27.pm and snmpit_apc.pm received some minor changes to
      support passing multiple outlets to one function call.
      ebaac553
  16. 13 Sep, 2001 1 commit
    • Leigh Stoller's avatar
      Be more forgiving of failed syswrite/sysread to the TIP socket during · 44ad0041
      Leigh Stoller authored
      the connection handshake. If the capture is active, it is going to
      write status and close the socket on its end, which may or may not be
      propogated back to the client side before/after/during the
      sysread/syswrite. I guess that a miserable way of saying there is a
      lot of asynchrony involved.
      44ad0041
  17. 29 Aug, 2001 1 commit
    • Leigh Stoller's avatar
      Fixup capture/tip/power_rpc27 so that capture returns a positive · ed55f418
      Leigh Stoller authored
      ack/nak for a connection so that the connecting process knows what the
      hell is going on. Turned out to be necessary for power control since
      we do that in parallel, and because it stays busy for 10 seconds on
      each power control. I think we will end up revisiting this at some
      point, adding blocking connections instead of connect/fail status.
      ed55f418
  18. 27 Aug, 2001 2 commits
    • Leigh Stoller's avatar
      Ug, forgot to turn off debug mode! · 966d8fa1
      Leigh Stoller authored
      966d8fa1
    • Leigh Stoller's avatar
      Changes to sync protocol. The RPC27 spits out a bunch of silly status · e335015b
      Leigh Stoller authored
      goo whenever it goes inactive for more than a couple of minutes. Also,
      require that we sync up so that we know for sure that the power
      control failed. Previously, I was blindly spitting out the command
      without being sure we had a command prompt.
      
      Note, that we still have a problem with an active tip session messing
      up power control since only one connection can be active at a time.
      At present, there is no positive way to know that the connection was
      refused since capture accepts the connection and then closes it if
      there is an active tip session. I need to change the little handshake
      so that there is a response Yes/Know response to the secret key
      exchange.
      e335015b
  19. 14 Aug, 2001 2 commits
  20. 09 Aug, 2001 1 commit