1. 18 4月, 2008 3 次提交
  2. 25 3月, 2008 5 次提交
  3. 23 3月, 2008 2 次提交
  4. 22 3月, 2008 7 次提交
    • D
      [SPARC64]: Remove most limitations to kernel image size. · 64658743
      David S. Miller 提交于
      Currently kernel images are limited to 8MB in size, and this causes
      problems especially when enabling features that take up a lot of
      kernel image space such as lockdep.
      
      The code now will align the kernel image size up to 4MB and map that
      many locked TLB entries.  So, the only practical limitation is the
      number of available locked TLB entries which is 16 on Cheetah and 64
      on pre-Cheetah sparc64 cpus.  Niagara cpus don't actually have hw
      locked TLB entry support.  Rather, the hypervisor transparently
      provides support for "locked" TLB entries since it runs with physical
      addressing and does the initial TLB miss processing.
      
      Fully utilizing this change requires some help from SILO, a patch for
      which will be submitted to the maintainer.  Essentially, SILO will
      only currently map up to 8MB for the kernel image and that needs to be
      increased.
      
      Note that neither this patch nor the SILO bits will help with network
      booting.  The openfirmware code will only map up to a certain amount
      of kernel image during a network boot and there isn't much we can to
      about that other than to implemented a layered network booting
      facility.  Solaris has this, and calls it "wanboot" and we may
      implement something similar at some point.
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      64658743
    • D
      [SCTP]: Fix build warnings with IPV6 disabled. · 1233823b
      David S. Miller 提交于
      Introduced by 270637ab
      ("[SCTP]: Fix a race between module load and protosw access")
      
      Reported by Gabriel C:
      
      In file included from net/sctp/sm_statetable.c:50:
      include/net/sctp/sctp.h: In function 'sctp_v6_pf_init':
      include/net/sctp/sctp.h:392: warning: 'return' with a value, in function returning void
      In file included from net/sctp/sm_statefuns.c:62:
      include/net/sctp/sctp.h: In function 'sctp_v6_pf_init':
      include/net/sctp/sctp.h:392: warning: 'return' with a value, in function returning void
       ...
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      1233823b
    • M
      sync_bitops: fix wrong comments [Bug 10247] · 7800c0c3
      Matti Linnanvuori 提交于
      Fix wrong function name and references to non-x86 architectures.
      
      Signed-off-by: Matti Linnanvuori mattilinnanvuori@yahoo.com
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      7800c0c3
    • Y
      x86: trim mtrr don't close gap for resource allocation. · 5dca6a1b
      Yinghai Lu 提交于
      fix the bug reported here:
      
      	http://bugzilla.kernel.org/show_bug.cgi?id=10232
      
      use update_memory_range() instead of add_memory_range() directly
      to avoid closing the gap.
      
      ( the new code only affects and runs on systems where the MTRR
        workaround triggers. )
      Signed-off-by: NYinghai Lu <yhlu.kernel@gmail.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      5dca6a1b
    • Y
      x86: reserve dma32 early for gart · f62f1fc9
      Yinghai Lu 提交于
      a system with 256 GB of RAM, when NUMA is disabled crashes the
      following way:
      
      Your BIOS doesn't leave a aperture memory hole
      Please enable the IOMMU option in the BIOS setup
      This costs you 64 MB of RAM
      Cannot allocate aperture memory hole (ffff8101c0000000,65536K)
      Kernel panic - not syncing: Not enough memory for aperture
      Pid: 0, comm: swapper Not tainted 2.6.25-rc4-x86-latest.git #33
      
      Call Trace:
       [<ffffffff84037c62>] panic+0xb2/0x190
       [<ffffffff840381fc>] ? release_console_sem+0x7c/0x250
       [<ffffffff847b1628>] ? __alloc_bootmem_nopanic+0x48/0x90
       [<ffffffff847b0ac9>] ? free_bootmem+0x29/0x50
       [<ffffffff847ac1f7>] gart_iommu_hole_init+0x5e7/0x680
       [<ffffffff847b255b>] ? alloc_large_system_hash+0x16b/0x310
       [<ffffffff84506a2f>] ? _etext+0x0/0x1
       [<ffffffff847a2e8c>] pci_iommu_alloc+0x1c/0x40
       [<ffffffff847ac795>] mem_init+0x45/0x1a0
       [<ffffffff8479ff35>] start_kernel+0x295/0x380
       [<ffffffff8479f1c2>] _sinittext+0x1c2/0x230
      
      the root cause is : memmap PMD is too big,
      [ffffe200e0600000-ffffe200e07fffff] PMD ->ffff81383c000000 on node 0
      almost near 4G..., and vmemmap_alloc_block will use up the ram under 4G.
      
      solution will be:
      1. make memmap allocation get memory above 4G...
      2. reserve some dma32 range early before we try to set up memmap for all.
      and release that before pci_iommu_alloc, so gart or swiotlb could get some
      range under 4g limit for sure.
      
      the patch is using method 2.
      because method1 may need more code to handle SPARSEMEM and SPASEMEM_VMEMMAP
      
      will get
      Your BIOS doesn't leave a aperture memory hole
      Please enable the IOMMU option in the BIOS setup
      This costs you 64 MB of RAM
      Mapping aperture over 65536 KB of RAM @ 4000000
      Memory: 264245736k/268959744k available (8484k kernel code, 4187464k reserved, 4004k data, 724k init)
      Signed-off-by: NYinghai Lu <yhlu.kernel@gmail.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      f62f1fc9
    • C
      x86: fix {clear,copy}_user_page() declarations in page.h · f2f7abcb
      Chuck Lever 提交于
      Clean up: eliminate some compiler noise on x86 when building with strict
      warnings enabled, introduced by commit 345b904c.
      
      In file included from include2/asm/thread_info_64.h:12,
                       from include2/asm/thread_info.h:4,
                       from
      /home/cel/src/linux/nfs-2.6/include/linux/thread_info.h:35,
                       from
      /home/cel/src/linux/nfs-2.6/include/linux/preempt.h:9,
                       from
      /home/cel/src/linux/nfs-2.6/include/linux/spinlock.h:49,
                       from /home/cel/src/linux/nfs-2.6/include/linux/mmzone.h:7,
                       from /home/cel/src/linux/nfs-2.6/include/linux/gfp.h:4,
                       from /home/cel/src/linux/nfs-2.6/include/linux/slab.h:14,
                       from /home/cel/src/linux/nfs-2.6/fs/nfsd/nfs4acl.c:40:
      include2/asm/page.h:55: warning: `inline' is not at beginning of
      declaration
      include2/asm/page.h:61: warning: `inline' is not at beginning of
      declaration
      Signed-off-by: NChuck Lever <chuck.lever@oracle.com>
      Cc: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      f2f7abcb
    • M
      x86: cast cmpxchg and cmpxchg_local result for 386 and 486 · 3078b79d
      Mathieu Desnoyers 提交于
      mm/slub.c: In function 'slab_alloc':
      mm/slub.c:1637: warning: assignment makes pointer from integer without a cast
      mm/slub.c:1637: warning: assignment makes pointer from integer without a cast
      mm/slub.c: In function 'slab_free':
      mm/slub.c:1796: warning: assignment makes pointer from integer without a cast
      mm/slub.c:1796: warning: assignment makes pointer from integer without a cast
      
      A cast is needed in the 386 and 486 code because the type is a pointer.  In
      every other integer case the original cmpxchg code (and the cmpxchg_local
      which has been copied from it) worked fine, but since we touch a pointer,
      the type needs to be casted in the cmpxchg_local and cmpxchg macros.
      
      The more recent code (586+) does not have this problem (the cast is already
      there).
      Signed-off-by: NMathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Reviewed-by: NChristoph Lameter <clameter@sgi.com>
      Cc: Vegard Nossum <vegard.nossum@gmail.com>
      Cc: Pekka Enberg <penberg@cs.helsinki.fi>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      3078b79d
  5. 21 3月, 2008 4 次提交
  6. 20 3月, 2008 6 次提交
  7. 19 3月, 2008 3 次提交
    • D
      [SPARC64]: Fix atomic backoff limit. · 4cfea5a7
      David S. Miller 提交于
      4096 will not fit into the immediate field of a compare instruction,
      in fact it will end up being -4096 causing the check to fail every
      time and thus disabling backoff.
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      4cfea5a7
    • I
      sched: tune multi-core idle balancing · 33b0c421
      Ingo Molnar 提交于
      WAKE_IDLE is too agressive on multi-core CPUs with the new
      wake-affine code, keep it on for SMT/HT balancing alone
      (where there's no cache affinity at all between logical CPUs).
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      33b0c421
    • I
      sched: improve affine wakeups · 4ae7d5ce
      Ingo Molnar 提交于
      improve affine wakeups. Maintain the 'overlap' metric based on CFS's
      sum_exec_runtime - which means the amount of time a task executes
      after it wakes up some other task.
      
      Use the 'overlap' for the wakeup decisions: if the 'overlap' is short,
      it means there's strong workload coupling between this task and the
      woken up task. If the 'overlap' is large then the workload is decoupled
      and the scheduler will move them to separate CPUs more easily.
      
      ( Also slightly move the preempt_check within try_to_wake_up() - this has
        no effect on functionality but allows 'early wakeups' (for still-on-rq
        tasks) to be correctly accounted as well.)
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      4ae7d5ce
  8. 18 3月, 2008 3 次提交
  9. 17 3月, 2008 3 次提交
    • T
      devres: implement pcim_iomap_regions_request_all() · 916fbfb7
      Tejun Heo 提交于
      Some drivers need to reserve all PCI BARs to prevent other drivers
      misusing unoccupied BARs.  pcim_iomap_regions_request_all() requests
      all BARs and iomap specified BARs.
      Signed-off-by: NTejun Heo <htejun@gmail.com>
      Cc: Greg Kroah-Hartman <gregkh@suse.de>
      Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
      Cc: Jeff Garzik <jeff@garzik.org>
      Signed-off-by: NJeff Garzik <jeff@garzik.org>
      916fbfb7
    • C
      virtio: fix race in enable_cb · 4265f161
      Christian Borntraeger 提交于
      There is a race in virtio_net, dealing with disabling/enabling the callback.
      I saw the following oops:
      
      kernel BUG at /space/kvm/drivers/virtio/virtio_ring.c:218!
      illegal operation: 0001 [#1] SMP
      Modules linked in: sunrpc dm_mod
      CPU: 2 Not tainted 2.6.25-rc1zlive-host-10623-gd358142-dirty #99
      Process swapper (pid: 0, task: 000000000f85a610, ksp: 000000000f873c60)
      Krnl PSW : 0404300180000000 00000000002b81a6 (vring_disable_cb+0x16/0x20)
                 R:0 T:1 IO:0 EX:0 Key:0 M:1 W:0 P:0 AS:0 CC:3 PM:0 EA:3
      Krnl GPRS: 0000000000000001 0000000000000001 0000000010005800 0000000000000001
                 000000000f3a0900 000000000f85a610 0000000000000000 0000000000000000
                 0000000000000000 000000000f870000 0000000000000000 0000000000001237
                 000000000f3a0920 000000000010ff74 00000000002846f6 000000000fa0bcd8
      Krnl Code: 00000000002b819a: a7110001           tmll    %r1,1
                 00000000002b819e: a7840004           brc     8,2b81a6
                 00000000002b81a2: a7f40001           brc     15,2b81a4
                >00000000002b81a6: a51b0001           oill    %r1,1
                 00000000002b81aa: 40102000           sth     %r1,0(%r2)
                 00000000002b81ae: 07fe               bcr     15,%r14
                 00000000002b81b0: eb7ff0380024       stmg    %r7,%r15,56(%r15)
                 00000000002b81b6: a7f13e00           tmll    %r15,15872
      Call Trace:
      ([<000000000fa0bcd0>] 0xfa0bcd0)
       [<00000000002b8350>] vring_interrupt+0x5c/0x6c
       [<000000000010ab08>] do_extint+0xb8/0xf0
       [<0000000000110716>] ext_no_vtime+0x16/0x1a
       [<0000000000107e72>] cpu_idle+0x1c2/0x1e0
      
      The problem can be triggered with a high amount of host->guest traffic.
      I think its the following race:
      
      poll says netif_rx_complete
      poll calls enable_cb
      enable_cb opens the interrupt mask
      a new packet comes, an interrupt is triggered----\
      enable_cb sees that there is more work           |
      enable_cb disables the interrupt                 |
             .                                         V
             .                            interrupt is delivered
             .                            skb_recv_done does atomic napi test, ok
       some waiting                       disable_cb is called->check fails->bang!
             .
      poll would do napi check
      poll would do disable_cb
      
      The fix is to let enable_cb not disable the interrupt again, but expect the
      caller to do the cleanup if it returns false. In that case, the interrupt is
      only disabled, if the napi test_set_bit was successful.
      Signed-off-by: NChristian Borntraeger <borntraeger@de.ibm.com>
      Signed-off-by: Rusty Russell <rusty@rustcorp.com.au> (cleaned up doco)
      4265f161
    • A
      The ps2esdi driver was marked as BROKEN more than two years ago due to being · 2af3e601
      Adrian Bunk 提交于
      no longer working for some time.
      
      A driver that had been marked as BROKEN for such a long time seems to be
      unlikely to be revived in the forseeable future.
      
      But if anyone wants to ever revive this driver, the code is still present in
      the older kernel releases.
      Signed-off-by: NAdrian Bunk <bunk@kernel.org>
      Acked-by: NAlan Cox <alan@redhat.com>
      Cc: Jens Axboe <jens.axboe@oracle.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NJens Axboe <jens.axboe@oracle.com>
      2af3e601
  10. 16 3月, 2008 4 次提交