An error occurred fetching the project authors.
  1. 09 Jan, 2012 1 commit
  2. 21 Sep, 2011 1 commit
  3. 13 Jan, 2011 1 commit
    • Seiji Aguchi's avatar
      kmsg_dump: constrain mtdoops and ramoops to perform their actions only for KMSG_DUMP_PANIC · fc2d557c
      Seiji Aguchi authored
      This series aims to develop logging facility for enterprise use.
      
      It is important to save kernel messages reliably on enterprise system
      because they are helpful for diagnosing system.
      
      This series add kmsg_dump() to the paths loosing kernel messages.  The use
      case is the following.
      
      [Use case of reboot/poweroff/halt/emergency_restart]
      
       My company has often experienced the followings in our support service.
       - Customer's system suddenly reboots.
       - Customers ask us to investigate the reason of the reboot.
      
      We recognize the fact itself because boot messages remain in
      /var/log/messages.  However, we can't investigate the reason why the
      system rebooted, because the last messages don't remain.  And off course
      we can't explain the reason.
      
      We can solve above problem with this patch as follows.
      
       Case1: reboot with command
         - We can see "Restarting system with command:" or ""Restarting system.".
      
       Case2: halt with command
         - We can see "System halted.".
      
       Case3: poweroff with command
         - We can see " Power down.".
      
       Case4: emergency_restart with sysrq.
         - We can see "Sysrq:" outputted in __handle_sysrq().
      
       Case5: emergency_restart with softdog.
         - We can see "Initiating system reboot" in watchdog_fire().
      
      So, we can distinguish the reason of reboot, poweroff, halt and emergency_restart.
      
      If customer executed reboot command, you may think the customer should
      know the fact.  However, they often claim they don't execute the command
      when they rebooted system by mistake.
      
      No message remains on the current Linux kernel, so we can't show the proof
      to the customer.  This patch improves this situation.
      
      This patch:
      
      Alters mtdoops and ramoops to perform their actions only for
      KMSG_DUMP_PANIC, KMSG_DUMP_OOPS and KMSG_DUMP_KEXEC because they would
      like to log crashes only.
      Signed-off-by: default avatarSeiji Aguchi <seiji.aguchi@hds.com>
      Cc: David Woodhouse <dwmw2@infradead.org>
      Cc: Marco Stornelli <marco.stornelli@gmail.com>
      Reviewed-by: default avatarArtem Bityutskiy <Artem.Bityutskiy@nokia.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      fc2d557c
  4. 06 Jan, 2011 1 commit
  5. 08 Aug, 2010 1 commit
  6. 25 Feb, 2010 1 commit
  7. 31 Dec, 2009 1 commit
  8. 30 Nov, 2009 5 commits
  9. 20 Mar, 2009 2 commits
  10. 10 Dec, 2008 1 commit
    • Adrian Hunter's avatar
      [MTD] update internal API to support 64-bit device size · 69423d99
      Adrian Hunter authored
      MTD internal API presently uses 32-bit values to represent
      device size.  This patch updates them to 64-bits but leaves
      the external API unchanged.  Extending the external API
      is a separate issue for several reasons.  First, no one
      needs it at the moment.  Secondly, whether the implementation
      is done with IOCTLs, sysfs or both is still debated.  Thirdly
      external API changes require the internal API to be accepted
      first.
      
      Note that although the MTD API will be able to support 64-bit
      device sizes, existing drivers do not and are not required
      to do so, although NAND base has been updated.
      
      In general, changing from 32-bit to 64-bit values cause little
      or no changes to the majority of the code with the following
      exceptions:
          	- printk message formats
          	- division and modulus of 64-bit values
          	- NAND base support
      	- 32-bit local variables used by mtdpart and mtdconcat
      	- naughtily assuming one structure maps to another
      	in MEMERASE ioctl
      Signed-off-by: default avatarAdrian Hunter <ext-adrian.hunter@nokia.com>
      Signed-off-by: default avatarArtem Bityutskiy <Artem.Bityutskiy@nokia.com>
      Signed-off-by: default avatarDavid Woodhouse <David.Woodhouse@intel.com>
      69423d99
  11. 18 Oct, 2008 3 commits
  12. 22 Apr, 2008 1 commit
  13. 07 Feb, 2008 2 commits
  14. 03 Feb, 2008 4 commits
  15. 03 Dec, 2007 1 commit
  16. 22 Aug, 2007 1 commit
  17. 11 Jul, 2007 1 commit
  18. 28 Jun, 2007 1 commit
    • Richard Purdie's avatar
      [MTD] oops and panic message logging to MTD device · 4b23aff0
      Richard Purdie authored
      Kernel oops and panic messages are invaluable when debugging crashes.
      These messages often don't make it to flash based logging methods (say a
      syslog on jffs2) due to the overheads involved in writing to flash.
      
      This patch allows you to turn an MTD partition into a circular log
      buffer where kernel oops and panic messages are written to. The messages
      are obtained by registering a console driver and checking
      oops_in_progress. Erases are performed in advance to maximise the
      chances of a saving messages.
      
      To activate it, add console=ttyMTDx to the kernel commandline (where x
      is the mtd device number to use).
      Signed-off-by: default avatarRichard Purdie <rpurdie@openedhand.com>
      Signed-off-by: default avatarDavid Woodhouse <dwmw2@infradead.org>
      4b23aff0