1. 04 6月, 2008 3 次提交
    • S
      x86: enable preemption in delay · 5c1ea082
      Steven Rostedt 提交于
      The RT team has been searching for a nasty latency. This latency shows
      up out of the blue and has been seen to be as big as 5ms!
      
      Using ftrace I found the cause of the latency.
      
         pcscd-2995  3dNh1 52360300us : irq_exit (smp_apic_timer_interrupt)
         pcscd-2995  3dN.2 52360301us : idle_cpu (irq_exit)
         pcscd-2995  3dN.2 52360301us : rcu_irq_exit (irq_exit)
         pcscd-2995  3dN.1 52360771us : smp_apic_timer_interrupt (apic_timer_interrupt
      )
         pcscd-2995  3dN.1 52360771us : exit_idle (smp_apic_timer_interrupt)
      
      Here's an example of a 400 us latency. pcscd took a timer interrupt and
      returned with "need resched" enabled, but did not reschedule until after
      the next interrupt came in at 52360771us 400us later!
      
      At first I thought we somehow missed a preemption check in entry.S. But
      I also noticed that this always seemed to happen during a __delay call.
      
         pcscd-2995  3dN.2 52360836us : rcu_irq_exit (irq_exit)
         pcscd-2995  3.N.. 52361265us : preempt_schedule (__delay)
      
      Looking at the x86 delay, I found my problem.
      
      In git commit 35d5d08a, Andrew Morton
      placed preempt_disable around the entire delay due to TSC's not working
      nicely on SMP.  Unfortunately for those that care about latencies this
      is devastating! Especially when we have callers to mdelay(8).
      
      Here I enable preemption during the loop and account for anytime the task
      migrates to a new CPU. The delay asked for may be extended a bit by
      the migration, but delay only guarantees that it will delay for that minimum
      time. Delaying longer should not be an issue.
      
      [
        Thanks to Thomas Gleixner for spotting that cpu wasn't updated,
          and to place the rep_nop between preempt_enabled/disable.
      ]
      Signed-off-by: NSteven Rostedt <srostedt@redhat.com>
      Cc: akpm@osdl.org
      Cc: Clark Williams <clark.williams@gmail.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: "Luis Claudio R. Goncalves" <lclaudio@uudg.org>
      Cc: Gregory Haskins <ghaskins@novell.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Andi Kleen <andi-suse@firstfloor.org>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      5c1ea082
    • I
      x86: disable preemption in native_smp_prepare_cpus · deef3250
      Ingo Molnar 提交于
      Priit Laes reported the following warning:
      
      Call Trace:
       [<ffffffff8022f1e1>] warn_on_slowpath+0x51/0x63
       [<ffffffff80282e48>] sys_ioctl+0x2d/0x5d
       [<ffffffff805185ff>] _spin_lock+0xe/0x24
       [<ffffffff80227459>] task_rq_lock+0x3d/0x73
       [<ffffffff805133c3>] set_cpu_sibling_map+0x336/0x350
       [<ffffffff8021c1b8>] read_apic_id+0x30/0x62
       [<ffffffff806d921d>] verify_local_APIC+0x90/0x138
       [<ffffffff806d84b5>] native_smp_prepare_cpus+0x1f9/0x305
       [<ffffffff806ce7b1>] kernel_init+0x59/0x2d9
       [<ffffffff80518a26>] _spin_unlock_irq+0x11/0x2b
       [<ffffffff8020bf48>] child_rip+0xa/0x12
       [<ffffffff806ce758>] kernel_init+0x0/0x2d9
       [<ffffffff8020bf3e>] child_rip+0x0/0x12
      
      fix this by generally disabling preemption in native_smp_prepare_cpus().
      Reported-and-bisected-by: NPriit Laes <plaes@plaes.org>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      deef3250
    • Y
      x86: fix APIC warning on 32bit v2 · fb3bbd6a
      Yinghai Lu 提交于
      for http://bugzilla.kernel.org/show_bug.cgi?id=10613
      
      BIOS bug, APIC version is 0 for CPU#0! fixing up to 0x10. (tell your hw vendor)
      
      v2: fix 64 bit compilation
      Signed-off-by: NYinghai Lu <yhlu.kernel@gmail.com>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: "Rafael J. Wysocki" <rjw@sisk.pl>
      Cc: Gabriel C <nix.or.die@googlemail.com>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      fb3bbd6a
  2. 03 6月, 2008 6 次提交
  3. 02 6月, 2008 1 次提交
    • A
      [CRYPTO] cts: Init SG tables · c4913c7b
      Alexey Dobriyan 提交于
      Steps to reproduce:
      
      	modprobe tcrypt		# with CONFIG_DEBUG_SG=y
      
      testing cts(cbc(aes)) encryption
      test 1 (128 bit key):
      ------------[ cut here ]------------
      kernel BUG at include/linux/scatterlist.h:65!
      invalid opcode: 0000 [1] PREEMPT SMP DEBUG_PAGEALLOC
      CPU 0 
      Modules linked in: tea xts twofish twofish_common tcrypt(+) [maaaany]
      Pid: 16151, comm: modprobe Not tainted 2.6.26-rc4-fat #7
      RIP: 0010:[<ffffffffa0bf032e>]  [<ffffffffa0bf032e>] :cts:cts_cbc_encrypt+0x151/0x355
      RSP: 0018:ffff81016f497a88  EFLAGS: 00010286
      RAX: ffffe20009535d58 RBX: ffff81016f497af0 RCX: 0000000087654321
      RDX: ffff8100010d4f28 RSI: ffff81016f497ee8 RDI: ffff81016f497ac0
      RBP: ffff81016f497c38 R08: 0000000000000000 R09: 0000000000000011
      R10: ffffffff00000008 R11: ffff8100010d4f28 R12: ffff81016f497ac0
      R13: ffff81016f497b30 R14: 0000000000000010 R15: 0000000000000010
      FS:  00007fac6fa276f0(0000) GS:ffffffff8060e000(0000) knlGS:0000000000000000
      CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
      CR2: 00007f12ca7cc000 CR3: 000000016f441000 CR4: 00000000000026e0
      DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      DR3: 0000000000000000 DR6: 00000000ffff4ff0 DR7: 0000000000000400
      Process modprobe (pid: 16151, threadinfo ffff81016f496000, task ffff8101755b4ae0)
      Stack:  0000000000000001 ffff81016f496000 ffffffff80719f78 0000000000000001
       0000000000000001 ffffffff8020c87c ffff81016f99c918 20646c756f772049
       65687420656b696c 0000000000000020 0000000000000000 0000000033341102
      Call Trace:
       [<ffffffff8020c87c>] ? restore_args+0x0/0x30
       [<ffffffffa04aa311>] ? :aes_generic:crypto_aes_expand_key+0x311/0x369
       [<ffffffff802ab453>] ? check_object+0x15a/0x213
       [<ffffffff802aad22>] ? init_object+0x6e/0x76
       [<ffffffff802ac3ae>] ? __slab_free+0xfc/0x371
       [<ffffffffa0bf05ed>] :cts:crypto_cts_encrypt+0xbb/0xca
       [<ffffffffa07108de>] ? :crypto_blkcipher:setkey+0xc7/0xec
       [<ffffffffa07110b8>] :crypto_blkcipher:async_encrypt+0x38/0x3a
       [<ffffffffa2ce9341>] :tcrypt:test_cipher+0x261/0x7c6
       [<ffffffffa2cfd9df>] :tcrypt:tcrypt_mod_init+0x9df/0x1b30
       [<ffffffff80261e35>] sys_init_module+0x9e/0x1b2
       [<ffffffff8020c15a>] system_call_after_swapgs+0x8a/0x8f
      Code: 45 c0 e8 aa 24 63 df 48 c1 e8 0c 48 b9 00 00 00 00 00 e2 ff ff 48 8b 55 88 48 6b c0 68 48 01 c8 b9 21 43 65 87 48 39 4d 80 74 04 <0f> 0b eb fe f6 c2 01 74 04 0f 0b eb fe 83 e2 03 4c 89 ef 44 89 
      RIP  [<ffffffffa0bf032e>] :cts:cts_cbc_encrypt+0x151/0x355
       RSP <ffff81016f497a88>
      ---[ end trace e8bahiarjand37fd ]---
      Signed-off-by: NAlexey Dobriyan <adobriyan@gmail.com>
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      c4913c7b
  4. 01 6月, 2008 1 次提交
    • S
      kbuild: fix $(src) assignmnet with external modules · 96d97f26
      Sam Ravnborg 提交于
      When we introduced support for KBUILD_EXTRA_SYMBOLS
      we started to include the externam module's kbuild
      file when doing the final modpost step.
      
      As external modules often do:
      ccflags-y := -I$(src)
      
      We had problems because $(src) was unassinged and
      gcc then used the next parameter for -I resulting in
      strange build failures.
      
      Fix is to assign $(src) and $(obj) when building
      external modules.
      
      This fixes: http://bugzilla.kernel.org/show_bug.cgi?id=10798Signed-off-by: NSam Ravnborg <sam@ravnborg.org>
      Cc: Tvrtko <tvrtko.ursulin@sophos.com>
      Cc: Andrea Arcangeli <andrea@qumranet.com>
      Cc: "Rafael J. Wysocki" <rjw@sisk.pl>
      96d97f26
  5. 31 5月, 2008 29 次提交