1. 22 8月, 2009 1 次提交
  2. 10 8月, 2009 1 次提交
  3. 09 8月, 2009 1 次提交
  4. 08 8月, 2009 2 次提交
    • I
      x86: Introduce GDT_ENTRY_INIT(), fix APM · 72c4d853
      Ingo Molnar 提交于
      This crash:
      
      [    0.891983] calling  cache_sysfs_init+0x0/0x1ee @ 1
      [    0.897251] initcall cache_sysfs_init+0x0/0x1ee returned 0 after 405 usecs
      [    0.904019] calling  mce_init_device+0x0/0x242 @ 1
      [    0.909124] initcall mce_init_device+0x0/0x242 returned 0 after 347 usecs
      [    0.915815] calling  apm_init+0x0/0x38d @ 1
      [    0.919967] apm: BIOS version 1.2 Flags 0x07 (Driver version 1.16ac)
      [    0.926813] general protection fault: 0000 [#1]
      [    0.927269] last sysfs file:
      [    0.927269] Modules linked in:
      [    0.927269]
      [    0.927269] Pid: 271, comm: kapmd Not tainted (2.6.31-rc3-00100-gd520da1-dirty #311) System Product Name
      [    0.927269] EIP: 00c0:[<000082b2>] EFLAGS: 00010002 CPU: 0
      [    0.927269] EIP is at 0x82b2
      [    0.927269] EAX: 0000530e EBX: 00000000 ECX: 00000102 EDX: 00000000
      [    0.927269] ESI: 00000000 EDI: f6a4bf44 EBP: 67890000 ESP: f6a4beec
      [    0.927269]  DS: 00c8 ES: 0000 FS: 0000 GS: 0000 SS: 0068
      [    0.927269] Process kapmd (pid: 271, ti=f6a4a000 task=f7142280 task.ti=f6a4a000)
      [    0.927269] Stack:
      [    0.927269]  0000828d 02160000 00b88092 f6a4bf3c c102a63d 00000060 f6a4bf3c f6a4bf44
      [    0.927269] <0> 0000007b 0000007b 00000000 00000000 00000000 00000000 560aae9e 00000000
      [    0.927269] <0> 00000200 f705fd74 00000000 c102af70 f6a4bf60 c102a6ec 0000530e 00000000
      [    0.927269] Call Trace:
      [    0.927269]  [<c102a63d>] ? __apm_bios_call_simple+0x7d/0x110
      [    0.927269]  [<c102af70>] ? apm+0x0/0x6a0
      [    0.927269]  [<c102a6ec>] ? apm_bios_call_simple+0x1c/0x50
      [    0.927269]  [<c102b3f5>] ? apm+0x485/0x6a0
      [    0.927269]  [<c1038e7a>] ? finish_task_switch+0x2a/0xb0
      [    0.927269]  [<c164a69e>] ? schedule+0x31e/0x480
      [    0.927269]  [<c102af70>] ? apm+0x0/0x6a0
      [    0.927269]  [<c102af70>] ? apm+0x0/0x6a0
      [    0.927269]  [<c1052654>] ? kthread+0x74/0x80
      [    0.927269]  [<c10525e0>] ? kthread+0x0/0x80
      [    0.927269]  [<c101d627>] ? kernel_thread_helper+0x7/0x10
      [    0.927269] Code:  Bad EIP value.
      [    0.927269] EIP: [<000082b2>] 0x82b2 SS:ESP 0068:f6a4beec
      [    0.927269] ---[ end trace a7919e7f17c0a725 ]---
      [    0.927269] Kernel panic - not syncing: Fatal exception
      [    0.927269] Pid: 271, comm: kapmd Tainted: G      D    2.6.31-rc3-00100-gd520da1-dirty #311
      
      Is caused by an incorrect GDT_ENTRY_INIT() conversion in the apm
      code, as noticed by hpa.
      Reported-by: NIngo Molnar <mingo@elte.hu>
      Noticed-by: N"H. Peter Anvin" <hpa@zytor.com>
      Signed-off-by: NAkinobu Mita <akinobu.mita@gmail.com>
      LKML-Reference: <20090808094905.GA2954@localhost.localdomain>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      72c4d853
    • A
      x86: Introduce GDT_ENTRY_INIT() · 1e5de182
      Akinobu Mita 提交于
      GDT_ENTRY_INIT is static initializer of desc_struct.
      
      We already have similar macro GDT_ENTRY() but it's static
      initializer for u64 and it cannot be used for desc_struct.
      Signed-off-by: NAkinobu Mita <akinobu.mita@gmail.com>
      LKML-Reference: <20090718151219.GD11294@localhost.localdomain>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      1e5de182
  5. 20 7月, 2009 3 次提交
  6. 17 7月, 2009 5 次提交
  7. 15 7月, 2009 2 次提交
  8. 14 7月, 2009 2 次提交
  9. 13 7月, 2009 4 次提交
  10. 11 7月, 2009 4 次提交
    • R
      x86: Remove spurious printk level from segfault message · a1a08d1c
      Roland Dreier 提交于
      Since commit 5fd29d6c ("printk: clean up handling of log-levels
      and newlines"), the kernel logs segfaults like:
      
          <6>gnome-power-man[24509]: segfault at 20 ip 00007f9d4950465a sp 00007fffbb50fc70 error 4 in libgobject-2.0.so.0.2103.0[7f9d494f7000+45000]
      
      with the extra "<6>" being KERN_INFO.  This happens because the
      printk in show_signal_msg() started with KERN_CONT and then
      used "%s" to pass in the real level; and KERN_CONT is no longer
      an empty string, and printk only pays attention to the level at
      the very beginning of the format string.
      
      Therefore, remove the KERN_CONT from this printk, since it is
      now actively causing problems (and never really made any
      sense).
      Signed-off-by: NRoland Dreier <roland@digitalvampire.org>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      LKML-Reference: <874otjitkj.fsf@shaolin.home.digitalvampire.org>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      a1a08d1c
    • P
      sched: INIT_PREEMPT_COUNT · c99e6efe
      Peter Zijlstra 提交于
      Pull the initial preempt_count value into a single
      definition site.
      
      Maintainers for: alpha, ia64 and m68k, please have a look,
      your arch code is funny.
      
      The header magic is a bit odd, but similar to the KERNEL_DS
      one, CPP waits with expanding these macros until the
      INIT_THREAD_INFO macro itself is expanded, which is in
      arch/*/kernel/init_task.c where we've already included
      sched.h so we're good.
      
      Cc: tony.luck@intel.com
      Cc: rth@twiddle.net
      Cc: geert@linux-m68k.org
      Signed-off-by: NPeter Zijlstra <a.p.zijlstra@chello.nl>
      Acked-by: NMatt Mackall <mpm@selenic.com>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      c99e6efe
    • Y
      x86/pci: insert ioapic resource before assigning unassigned resources · 857fdc53
      Yinghai Lu 提交于
      Stephen reported that his DL585 G2 needed noapic after 2.6.22 (?)
      
      Dann bisected it down to:
        commit 30a18d6c
        Date:   Tue Feb 19 03:21:20 2008 -0800
      
            x86: multi pci root bus with different io resource range, on
            64-bit
      
      It turns out that:
        1. that AMD-based systems have two HT chains.
        2. BIOS doesn't allocate resources for BAR 6 of devices under 8132 etc
        3. that multi-peer-root patch will try to split root resources to peer
           root resources according to PCI conf of NB
        4. PCI core assigns unassigned resources, but they overlap with BARs
           that are used by ioapic addr of io4 and 8132.
      
      The reason: at that point ioapic address are not inserted yet.  Solution
      is to insert ioapic resources into the tree a bit earlier.
      Reported-by: NStephen Frost <sfrost@snowman.net>
      Reported-and-Tested-by: Ndann frazier <dannf@hp.com>
      Signed-off-by: NYinghai Lu <yinghai@kernel.org>
      Cc: stable@kernel.org
      Signed-off-by: NJesse Barnes <jbarnes@jbarnes-g45.(none)>
      857fdc53
    • J
      Fix congestion_wait() sync/async vs read/write confusion · 8aa7e847
      Jens Axboe 提交于
      Commit 1faa16d2 accidentally broke
      the bdi congestion wait queue logic, causing us to wait on congestion
      for WRITE (== 1) when we really wanted BLK_RW_ASYNC (== 0) instead.
      Signed-off-by: NJens Axboe <jens.axboe@oracle.com>
      8aa7e847
  11. 10 7月, 2009 2 次提交
  12. 09 7月, 2009 2 次提交
  13. 08 7月, 2009 11 次提交