“69961a26b82931601e07c9e3656bd90c598f2395”上不存在“README.md”
  1. 15 9月, 2009 2 次提交
    • H
      [IA64] kexec: Make INIT safe while transition to · 07a6a4ae
      Hidetoshi Seto 提交于
      kdump/kexec kernel
      
      Summary:
      
        Asserting INIT on the beginning of kdump/kexec kernel will result
        in unexpected behavior because INIT handler for previous kernel is
        invoked on new kernel.
      
      Description:
      
        In panic situation, we can receive INIT while kernel transition,
        i.e. from beginning of panic to bootstrap of kdump kernel.
        Since we initialize registers on leave from current kernel, no
        longer monarch/slave handlers of current kernel in virtual mode are
        called safely.  (In fact system goes hang as far as I confirmed)
      
      How to Reproduce:
      
        Start kdump
          # echo c > /proc/sysrq-trigger
        Then assert INIT while kdump kernel is booting, before new INIT
        handler for kdump kernel is registered.
      
      Expected(Desirable) result:
      
        kdump kernel boots without any problem, crashdump retrieved
      
      Actual result:
      
        INIT handler for previous kernel is invoked on kdump kernel
        => panic, hang etc. (unexpected)
      
      Proposed fix:
      
        We can unregister these init handlers from SAL before jumping into
        new kernel, however then the INIT will fallback to default behavior,
        result in warmboot by SAL (according to the SAL specification) and
        we cannot retrieve the crashdump.
      
        Therefore this patch introduces a NOP init handler and register it
        to SAL before leave from current kernel, to start kdump safely by
        preventing INITs from entering virtual mode and resulting in warmboot.
      
        On the other hand, in case of kexec that not for kdump, it also
        has same problem with INIT while kernel transition.
        This patch handles this case differently, because for kexec
        unregistering handlers will be preferred than registering NOP
        handler, since the situation "no handlers registered" is usual
        state for kernel's entry.
      Signed-off-by: NHidetoshi Seto <seto.hidetoshi@jp.fujitsu.com>
      Cc: Vivek Goyal <vgoyal@redhat.com>
      Cc: Haren Myneni <hbabu@us.ibm.com>
      Cc: kexec@lists.infradead.org
      Acked-by: NFenghua Yu <fenghua.yu@intel.com>
      Signed-off-by: NTony Luck <tony.luck@intel.com>
      07a6a4ae
    • H
      [IA64] kdump: Mask MCA/INIT on frozen cpus · 4295ab34
      Hidetoshi Seto 提交于
      Summary:
      
        INIT asserted on kdump kernel invokes INIT handler not only on a
        cpu that running on the kdump kernel, but also BSP of the panicked
        kernel, because the (badly) frozen BSP can be thawed by INIT.
      
      Description:
      
        The kdump_cpu_freeze() is called on cpus except one that initiates
        panic and/or kdump, to stop/offline the cpu (on ia64, it means we
        pass control of cpus to SAL, or put them in spinloop).  Note that
        CPU0(BSP) always go to spinloop, so if panic was happened on an AP,
        there are at least 2cpus (= the AP and BSP) which not back to SAL.
      
        On the spinning cpus, interrupts are disabled (rsm psr.i), but INIT
        is still interruptible because psr.mc for mask them is not set unless
        kdump_cpu_freeze() is not called from MCA/INIT context.
      
        Therefore, assume that a panic was happened on an AP, kdump was
        invoked, new INIT handlers for kdump kernel was registered and then
        an INIT is asserted.  From the viewpoint of SAL, there are 2 online
        cpus, so INIT will be delivered to both of them.  It likely means
        that not only the AP (= a cpu executing kdump) enters INIT handler
        which is newly registered, but also BSP (= another cpu spinning in
        panicked kernel) enters the same INIT handler.  Of course setting of
        registers in BSP are still old (for panicked kernel), so what happen
        with running handler with wrong setting will be extremely unexpected.
        I believe this is not desirable behavior.
      
      How to Reproduce:
      
        Start kdump on one of APs (e.g. cpu1)
          # taskset 0x2 echo c > /proc/sysrq-trigger
        Then assert INIT after kdump kernel is booted, after new INIT handler
        for kdump kernel is registered.
      
      Expected results:
      
        An INIT handler is invoked only on the AP.
      
      Actual results:
      
        An INIT handler is invoked on the AP and BSP.
      
      Sample of results:
      
        I got following console log by asserting INIT after prompt "root:/>".
        It seems that two monarchs appeared by one INIT, and one panicked at
        last.  And it also seems that the panicked one supposed there were
        4 online cpus and no one did rendezvous:
      
          :
          [  0 %]dropping to initramfs shell
          exiting this shell will reboot your system
          root:/> Entered OS INIT handler. PSP=fff301a0 cpu=0 monarch=0
          ia64_init_handler: Promoting cpu 0 to monarch.
          Delaying for 5 seconds...
          All OS INIT slaves have reached rendezvous
          Processes interrupted by INIT - 0 (cpu 0 task 0xa000000100af0000)
          :
          <<snip>>
          :
          Entered OS INIT handler. PSP=fff301a0 cpu=0 monarch=1
          Delaying for 5 seconds...
          mlogbuf_finish: printing switched to urgent mode, MCA/INIT might be dodgy or fail.
          OS INIT slave did not rendezvous on cpu 1 2 3
          INIT swapper 0[0]: bugcheck! 0 [1]
          :
          <<snip>>
          :
          Kernel panic - not syncing: Attempted to kill the idle task!
      
      Proposed fix:
      
        To avoid this problem, this patch inserts ia64_set_psr_mc() to mask
        INIT on cpus going to be frozen.  This masking have no effect if the
        kdump_cpu_freeze() is called from INIT handler when kdump_on_init == 1,
        because psr.mc is already turned on to 1 before entering OS_INIT.
        I confirmed that weird log like above are disappeared after applying
        this patch.
      Signed-off-by: NHidetoshi Seto <seto.hidetoshi@jp.fujitsu.com>
      Cc: Vivek Goyal <vgoyal@redhat.com>
      Cc: Haren Myneni <hbabu@us.ibm.com>
      Cc: kexec@lists.infradead.org
      Acked-by: NFenghua Yu <fenghua.yu@intel.com>
      Signed-off-by: NTony Luck <tony.luck@intel.com>
      4295ab34
  2. 10 9月, 2009 1 次提交
  3. 09 9月, 2009 3 次提交
    • E
      aoe: allocate unused request_queue for sysfs · 7135a71b
      Ed Cashin 提交于
      Andy Whitcroft reported an oops in aoe triggered by use of an
      incorrectly initialised request_queue object:
      
        [ 2645.959090] kobject '<NULL>' (ffff880059ca22c0): tried to add
      		an uninitialized object, something is seriously wrong.
        [ 2645.959104] Pid: 6, comm: events/0 Not tainted 2.6.31-5-generic #24-Ubuntu
        [ 2645.959107] Call Trace:
        [ 2645.959139] [<ffffffff8126ca2f>] kobject_add+0x5f/0x70
        [ 2645.959151] [<ffffffff8125b4ab>] blk_register_queue+0x8b/0xf0
        [ 2645.959155] [<ffffffff8126043f>] add_disk+0x8f/0x160
        [ 2645.959161] [<ffffffffa01673c4>] aoeblk_gdalloc+0x164/0x1c0 [aoe]
      
      The request queue of an aoe device is not used but can be allocated in
      code that does not sleep.
      
      Bruno bisected this regression down to
      
        cd43e26f
      
        block: Expose stacked device queues in sysfs
      
      "This seems to generate /sys/block/$device/queue and its contents for
       everyone who is using queues, not just for those queues that have a
       non-NULL queue->request_fn."
      
      Addresses http://bugs.launchpad.net/bugs/410198
      Addresses http://bugzilla.kernel.org/show_bug.cgi?id=13942
      
      Note that embedding a queue inside another object has always been
      an illegal construct, since the queues are reference counted and
      must persist until the last reference is dropped. So aoe was
      always buggy in this respect (Jens).
      Signed-off-by: NEd Cashin <ecashin@coraid.com>
      Cc: Andy Whitcroft <apw@canonical.com>
      Cc: "Rafael J. Wysocki" <rjw@sisk.pl>
      Cc: Bruno Premont <bonbons@linux-vserver.org>
      Cc: Martin K. Petersen <martin.petersen@oracle.com>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NJens Axboe <jens.axboe@oracle.com>
      7135a71b
    • L
      i915: disable interrupts before tearing down GEM state · e6890f6f
      Linus Torvalds 提交于
      Reinette Chatre reports a frozen system (with blinking keyboard LEDs)
      when switching from graphics mode to the text console, or when
      suspending (which does the same thing). With netconsole, the oops
      turned out to be
      
      	BUG: unable to handle kernel NULL pointer dereference at 0000000000000084
      	IP: [<ffffffffa03ecaab>] i915_driver_irq_handler+0x26b/0xd20 [i915]
      
      and it's due to the i915_gem.c code doing drm_irq_uninstall() after
      having done i915_gem_idle(). And the i915_gem_idle() path will do
      
        i915_gem_idle() ->
          i915_gem_cleanup_ringbuffer() ->
            i915_gem_cleanup_hws() ->
              dev_priv->hw_status_page = NULL;
      
      but if an i915 interrupt comes in after this stage, it may want to
      access that hw_status_page, and gets the above NULL pointer dereference.
      
      And since the NULL pointer dereference happens from within an interrupt,
      and with the screen still in graphics mode, the common end result is
      simply a silently hung machine.
      
      Fix it by simply uninstalling the irq handler before idling rather than
      after. Fixes
      
          http://bugzilla.kernel.org/show_bug.cgi?id=13819Reported-and-tested-by: NReinette Chatre <reinette.chatre@intel.com>
      Acked-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      e6890f6f
    • Z
      drm/i915: fix mask bits setting · 7c8460db
      Zhenyu Wang 提交于
      eDP is exclusive connector too, and add missing crtc_mask
      setting for TV.
      
      This fixes
      
      	http://bugzilla.kernel.org/show_bug.cgi?id=14139Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>
      Reported-and-tested-by: NCarlos R. Mafra <crmafra2@gmail.com>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      7c8460db
  4. 08 9月, 2009 5 次提交
  5. 07 9月, 2009 2 次提交
  6. 06 9月, 2009 27 次提交
新手
引导
客服 返回
顶部