1. 01 6月, 2015 1 次提交
  2. 10 10月, 2012 1 次提交
  3. 02 11月, 2011 1 次提交
  4. 23 10月, 2008 1 次提交
  5. 17 10月, 2007 2 次提交
  6. 29 3月, 2007 1 次提交
  7. 25 10月, 2006 1 次提交
    • A
      [PATCH] uml: mconsole fixes · 3a51237d
      Al Viro 提交于
       * when we have stop/sysrq/go, we get pt_regs of whatever executes
         mc_work_proc().  Would be better to see what we had at the time of
         interrupt that got us stop.
      
       * stop/stop/stop.....  will give stack overflow.  Shouldn't allow stop
         from mconsole_stop().
      
       * stop/stop/go leaves us inside mconsole_stop() with
      	os_set_fd_block(req->originating_fd, 0);
      	reactivate_fd(req->originating_fd, MCONSOLE_IRQ);
         just done by nested mconsole_stop().  Ditto.
      
       * once we'd seen stop, there's a period when INTR commands are executed
         out of order (as they should; we might have the things stuck badly
         enough to never reach mconsole_stop(), but still not badly enough to
         block mconsole_interrupt(); in that situation we _want_ things like
         "cad" to be executed immediately).  Once we enter monsole_stop(), all
         INTR commands will be executed in order, mixed with PROC ones.  We'd
         better let user see that such change of behaviour has happened.
         (Suggested by lennert).
      
       * stack footprint of monsole_interrupt() is an atrocity; AFAICS we can
         safely make struct mc_request req; static in function there.
      Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      Acked-by: NJeff Dike <jdike@addtoit.com>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      3a51237d
  8. 07 1月, 2006 1 次提交
  9. 18 9月, 2005 1 次提交
    • J
      [PATCH] uml: breakpoint an arbitrary thread · 3eddddcf
      Jeff Dike 提交于
      This patch implements a stack trace for a thread, not unlike sysrq-t does.
      The advantage to this is that a break point can be placed on showreqs, so that
      upon showing the stack, you jump immediately into the debugger.  While sysrq-t
      does the same thing, sysrq-t shows *all* threads stacks.  It also doesn't work
      right now.  In the future, I thought it might be acceptable to make this show
      all pids stacks, but perhaps leaving well enough alone and just using sysrq-t
      would be okay.  For now, upon receiving the stack command, UML switches
      context to that thread, dumps its registers, and then switches context back to
      the original thread.  Since UML compacts all threads into one of 4 host
      threads, this sort of mechanism could be expanded in the future to include
      other debugging helpers that sysrq does not cover.
      
      Note by jdike - The main benefit to this is that it brings an arbitrary thread
      back into context, where it can be examined by gdb.  The fact that it dumps it
      stack is secondary.  This provides the capability to examine a sleeping
      thread, which has existed in tt mode, but not in skas mode until now.
      
      Also, the other threads, that sysrq doesn't cover, can be gdb-ed directly
      anyway.
      
      Signed-off-by: Allan Graves<allan.graves@gmail.com>
      Signed-off-by: NJeff Dike <jdike@addtoit.com>
      Cc: Paolo Giarrusso <blaisorblade@yahoo.it>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      3eddddcf
  10. 09 6月, 2005 1 次提交
  11. 17 4月, 2005 1 次提交
    • L
      Linux-2.6.12-rc2 · 1da177e4
      Linus Torvalds 提交于
      Initial git repository build. I'm not bothering with the full history,
      even though we have it. We can create a separate "historical" git
      archive of that later if we want to, and in the meantime it's about
      3.2GB when imported into git - space that would just make the early
      git days unnecessarily complicated, when we don't have a lot of good
      infrastructure for it.
      
      Let it rip!
      1da177e4