1. 15 Nov, 2012 1 commit
    • Matthieu CASTET's avatar
      mtdoops: don't erase flash at each boot · cd409c61
      Matthieu CASTET authored
      The current version on mtdoops erase first block of mtdoops partition at each
      boot if there is no oops stored in flash. This can wear the flash.
      When mtdoops start, find_next_position is called to find the next free entry in
      the circular buffer. But if the flash is erased, find_next_position don't find
      anything (maxcount == 0xffffffff) and start with the first entry after erasing it.
      The scanning that is done in find_next_position already track free/used entries.
      So if at the end of the scanning we don't find anything, we can start at the
      first entry and erased the entry only if it is marked as used.
      Most of this is implemented in mtdoops_inc_counter, so to avoid duplicating
      code, if we don't find anything we set position to -1. mtdoops_inc_counter with
      increment it, erase the entry if needed and start as before with nextpage = 0
      and nextcount = 1).
      Also during the scan phase, we use the MTDOOPS_KERNMSG_MAGIC to detect corruped
      Signed-off-by: Matthieu Castet <matthieu.castet@parrot@com>
      Signed-off-by: default avatarArtem Bityutskiy <artem.bityutskiy@linux.intel.com>
  2. 20 Aug, 2012 1 commit
    • Tejun Heo's avatar
      workqueue: deprecate flush[_delayed]_work_sync() · 43829731
      Tejun Heo authored
      flush[_delayed]_work_sync() are now spurious.  Mark them deprecated
      and convert all users to flush[_delayed]_work().
      If you're cc'd and wondering what's going on: Now all workqueues are
      non-reentrant and the regular flushes guarantee that the work item is
      not pending or running on any CPU on return, so there's no reason to
      use the sync flushes at all and they're going away.
      This patch doesn't make any functional difference.
      Signed-off-by: default avatarTejun Heo <tj@kernel.org>
      Cc: Russell King <linux@arm.linux.org.uk>
      Cc: Paul Mundt <lethal@linux-sh.org>
      Cc: Ian Campbell <ian.campbell@citrix.com>
      Cc: Jens Axboe <axboe@kernel.dk>
      Cc: Mattia Dongili <malattia@linux.it>
      Cc: Kent Yoder <key@linux.vnet.ibm.com>
      Cc: David Airlie <airlied@linux.ie>
      Cc: Jiri Kosina <jkosina@suse.cz>
      Cc: Karsten Keil <isdn@linux-pingi.de>
      Cc: Bryan Wu <bryan.wu@canonical.com>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Alasdair Kergon <agk@redhat.com>
      Cc: Mauro Carvalho Chehab <mchehab@infradead.org>
      Cc: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
      Cc: David Woodhouse <dwmw2@infradead.org>
      Cc: "David S. Miller" <davem@davemloft.net>
      Cc: linux-wireless@vger.kernel.org
      Cc: Anton Vorontsov <cbou@mail.ru>
      Cc: Sangbeom Kim <sbkim73@samsung.com>
      Cc: "James E.J. Bottomley" <James.Bottomley@HansenPartnership.com>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Cc: Eric Van Hensbergen <ericvh@gmail.com>
      Cc: Takashi Iwai <tiwai@suse.de>
      Cc: Steven Whitehouse <swhiteho@redhat.com>
      Cc: Petr Vandrovec <petr@vandrovec.name>
      Cc: Mark Fasheh <mfasheh@suse.com>
      Cc: Christoph Hellwig <hch@infradead.org>
      Cc: Avi Kivity <avi@redhat.com> 
  3. 06 Jul, 2012 1 commit
  4. 15 Jun, 2012 1 commit
  5. 26 Mar, 2012 1 commit
  6. 12 Jan, 2012 1 commit
  7. 09 Jan, 2012 11 commits
  8. 21 Sep, 2011 1 commit
  9. 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>
  10. 06 Jan, 2011 1 commit
  11. 08 Aug, 2010 1 commit
  12. 25 Feb, 2010 1 commit
  13. 31 Dec, 2009 1 commit
  14. 30 Nov, 2009 5 commits
  15. 20 Mar, 2009 2 commits
  16. 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
      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
          	- 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>
  17. 18 Oct, 2008 3 commits
  18. 22 Apr, 2008 1 commit
  19. 07 Feb, 2008 2 commits
  20. 03 Feb, 2008 3 commits