1. 26 1月, 2008 1 次提交
  2. 25 1月, 2008 1 次提交
  3. 12 10月, 2007 2 次提交
  4. 21 5月, 2007 1 次提交
  5. 09 5月, 2007 1 次提交
  6. 27 4月, 2007 2 次提交
  7. 06 2月, 2007 1 次提交
  8. 08 12月, 2006 1 次提交
  9. 04 12月, 2006 1 次提交
  10. 30 11月, 2006 1 次提交
  11. 19 10月, 2006 1 次提交
  12. 04 10月, 2006 11 次提交
  13. 24 3月, 2006 1 次提交
  14. 09 11月, 2005 1 次提交
  15. 07 11月, 2005 1 次提交
  16. 11 9月, 2005 1 次提交
  17. 26 6月, 2005 1 次提交
    • M
      [PATCH] s390: debug feature changes · 66a464db
      Michael Holzheu 提交于
      This patch changes the memory allocation method for the s390 debug feature.
      Trace buffers had been allocated using the get_free_pages() function before.
      Therefore it was not possible to get big memory areas in a running system due
      to memory fragmentation.  Now the trace buffers are subdivided into several
      subbuffers with pagesize.  Therefore it is now possible to allocate more
      memory for the trace buffers and more trace records can be written.
      
      In addition to that, dynamic specification of the size of the trace buffers is
      implemented.  It is now possible to change the size of a trace buffer using a
      new debugfs file instance.  When writing a number into this file, the trace
      buffer size is changed to 'number * pagesize'.
      
      In the past all the traces could be obtained from userspace by accessing files
      in the "proc" filesystem.  Now with debugfs we have a new filesystem which
      should be used for debugging purposes.  This patch moves the debug feature
      from procfs to debugfs.
      
      Since the interface of debug_register() changed, all device drivers, which use
      the debug feature had to be adjusted.
      Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      66a464db
  18. 22 6月, 2005 1 次提交
  19. 01 5月, 2005 1 次提交
  20. 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