1. 19 10月, 2010 1 次提交
    • Y
      x86: ioapic: Call free_irte only if interrupt remapping enabled · 9717967c
      Yinghai Lu 提交于
      On a system that support intr-rempping when booting with "intremap=off"
      
      [  177.895501] BUG: unable to handle kernel NULL pointer dereference at 00000000000000f8
      [  177.913316] IP: [<ffffffff8145fc18>] free_irte+0x47/0xc0
      ...
      [  178.173326] Call Trace:
      [  178.173574]  [<ffffffff810515b4>] destroy_irq+0x3a/0x75
      [  178.192934]  [<ffffffff81051834>] arch_teardown_msi_irq+0xe/0x10
      [  178.193418]  [<ffffffff81458dc3>] arch_teardown_msi_irqs+0x56/0x7f
      [  178.213021]  [<ffffffff81458e79>] free_msi_irqs+0x8d/0xeb
      
      Call free_irte only when interrupt remapping is enabled.
      Signed-off-by: NYinghai Lu <yinghai@kernel.org>
      LKML-Reference: <4CBCB274.7010108@kernel.org>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      9717967c
  2. 17 10月, 2010 2 次提交
    • T
      arm: Use ARCH_IRQ_INIT_FLAGS · 032fa360
      Thomas Gleixner 提交于
      The core code now initializes the requested number of interrupts and
      sets the flags in irq_desc.status which are requested by the
      architecture via ARCH_IRQ_INIT_FLAGS.
      
      Add ARCH_IRQ_INIT_FLAGS and remove the loop which sets those flags
      after the irq descriptors are allocated.
      
      [ This patch should have been in the original irq rework and got
        dropped accidentaly ]
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Cc: Russell King <linux@arm.linux.org.uk>
      Cc: Linus Walleij <linus.walleij@stericsson.com>
      Cc: Anand Gadiyar <gadiyar@ti.com>
      032fa360
    • A
      genirq, ARM: Fix boot on ARM platforms · 05d0ca85
      Anand Gadiyar 提交于
      Commit b683de2b in linux-next as of 20101014 (genirq: Query
      arch for number of early descriptors) seems to have broken
      bootup on several ARM boards - my beagleboard gives the
      following dump with earlyprintk:
      
       NR_IRQS:402
       Unable to handle kernel NULL pointer dereference at virtual
       address 00000028 pgd = c0004000
       [00000028] *pgd=00000000
       Internal error: Oops: 5 [#1]
       last sysfs file:
       Modules linked in:
       CPU: 0    Not tainted
       (2.6.36-rc7-next-20101014-linux-next-20101012+ #40) PC is at
       init_IRQ+0x14/0x48 LR is at start_kernel+0x150/0x2c0
       [...]
      
      We seem to be using desc->status without assigning desc to
      anything. Fix this by adding back the code that was originally
      there.
      Signed-off-by: NAnand Gadiyar <gadiyar@ti.com>
      Tested-by: NLinus Walleij <linus.walleij@stericsson.com>
      Cc: Russell King <linux@arm.linux.org.uk>
      Cc: linux-arm-kernel@lists.infradead.org
      LKML-Reference: <1287077397-21781-1-git-send-email-gadiyar@ti.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      05d0ca85
  3. 16 10月, 2010 5 次提交
  4. 15 10月, 2010 2 次提交
    • T
      ubd: fix incorrect sector handling during request restart · 47526903
      Tejun Heo 提交于
      Commit f81f2f7c (ubd: drop unnecessary rq->sector manipulation)
      dropped request->sector manipulation in preparation for global request
      handling cleanup; unfortunately, it incorrectly assumed that the
      updated sector wasn't being used.
      
      ubd tries to issue as many requests as possible to io_thread.  When
      issuing fails due to memory pressure or other reasons, the device is
      put on the restart list and issuing stops.  On IO completion, devices
      on the restart list are scanned and IO issuing is restarted.
      
      ubd issues IOs sg-by-sg and issuing can be stopped in the middle of a
      request, so each device on the restart queue needs to remember where
      to restart in its current request.  ubd needs to keep track of the
      issue position itself because,
      
      * blk_rq_pos(req) is now updated by the block layer to keep track of
        _completion_ position.
      
      * Multiple io_req's for the current request may be in flight, so it's
        difficult to tell where blk_rq_pos(req) currently is.
      
      Add ubd->rq_pos to keep track of the issue position and use it to
      correctly restart io_req issue.
      Signed-off-by: NTejun Heo <tj@kernel.org>
      Reported-by: NRichard Weinberger <richard@nod.at>
      Tested-by: NRichard Weinberger <richard@nod.at>
      Tested-by: NChris Frey <cdfrey@foursquare.net>
      Cc: stable@kernel.org
      Signed-off-by: NJens Axboe <jaxboe@fusionio.com>
      47526903
    • L
      Don't dump task struct in a.out core-dumps · 0eead9ab
      Linus Torvalds 提交于
      akiphie points out that a.out core-dumps have that odd task struct
      dumping that was never used and was never really a good idea (it goes
      back into the mists of history, probably the original core-dumping
      code).  Just remove it.
      
      Also do the access_ok() check on dump_write().  It probably doesn't
      matter (since normal filesystems all seem to do it anyway), but he
      points out that it's normally done by the VFS layer, so ...
      
      [ I suspect that we should possibly do "vfs_write()" instead of
        calling ->write directly.  That also does the whole fsnotify and write
        statistics thing, which may or may not be a good idea. ]
      
      And just to be anal, do this all for the x86-64 32-bit a.out emulation
      code too, even though it's not enabled (and won't currently even
      compile)
      Reported-by: Nakiphie <akiphie@lavabit.com>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      0eead9ab
  5. 13 10月, 2010 2 次提交
  6. 12 10月, 2010 28 次提交