1. 21 Mar, 2008 14 commits
    • Zbigniew Luszpinski's avatar
      x86: hpet clock enable quirk on nVidia nForce 430 · 96bcf458
      Zbigniew Luszpinski authored
      this patch allows hpet=force on nVidia nForce 430 southbridge.
      This patch was tested by me on my old Asus A8N-VM CSM (where bios does not
      support hpet and does not advertise it via acpi entry). My nForce430 version:
      lspci -nn | grep LPC
      00:0a.0 ISA bridge [0601]: nVidia Corporation MCP51 LPC Bridge [10de:0260]
      (rev a2)
      
      Kernel 2.6.24.3 after patching and using hpet=force reports this:
      dmesg | grep -i hpet
      Kernel command line: root=/dev/sda8 ro vga=773 video=vesafb:mtrr:4,ywrap
      vt.default_utf8=0 hpet=force
      Force enabled HPET at base address 0xfed00000
      hpet clockevent registered
      Time: hpet clocksource has been installed.
      
      grep -i hpet /proc/timer_list
      Clock Event Device: hpet
       set_next_event: hpet_legacy_next_event
       set_mode:       hpet_legacy_set_mode
      
      grep Clock /proc/timer_list (before patching)
      Clock Event Device: pit
      Clock Event Device: lapic
      
      grep Clock /proc/timer_list (after patching)
      Clock Event Device: hpet
      Clock Event Device: lapic
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      96bcf458
    • Yinghai Lu's avatar
      x86: reserve dma32 early for gart · f62f1fc9
      Yinghai Lu authored
      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: default avatarYinghai Lu <yhlu.kernel@gmail.com>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      f62f1fc9
    • Coleman Kane's avatar
      x86: add the DFF (Desktop Form Factor) Dell Optiplex 745 to the reboot errata list · fc115bf1
      Coleman Kane authored
      We recently got some of the "Desktop Form Factor" Optiplex 745's in.  I
      noticed that there's an entry for the SFF one's, but the BIOS model number
      of the DFF differs from that of the SFF.  We have been reliably
      experiencing the same (as far as I can tell) reboot bug as the SFF boxes.
      
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      fc115bf1
    • Randy Dunlap's avatar
      x86/visws: fix printk format warnings · 31780715
      Randy Dunlap authored
      Fix visws printk format warnings:
      
      /local/linsrc/linux-2.6.24-git15/arch/x86/mach-visws/traps.c:50: warning: format '%#lx' expects type 'long unsigned int', but argument 2 has type 'u32'
      /local/linsrc/linux-2.6.24-git15/arch/x86/mach-visws/traps.c:50: warning: format '%#lx' expects type 'long unsigned int', but argument 3 has type 'u32'
      Signed-off-by: default avatarRandy Dunlap <randy.dunlap@oracle.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      31780715
    • Chuck Lever's avatar
      x86: fix {clear,copy}_user_page() declarations in page.h · f2f7abcb
      Chuck Lever authored
      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: default avatarChuck Lever <chuck.lever@oracle.com>
      Cc: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      f2f7abcb
    • Mathieu Desnoyers's avatar
      x86: cast cmpxchg and cmpxchg_local result for 386 and 486 · 3078b79d
      Mathieu Desnoyers authored
      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: default avatarMathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Reviewed-by: default avatarChristoph Lameter <clameter@sgi.com>
      Cc: Vegard Nossum <vegard.nossum@gmail.com>
      Cc: Pekka Enberg <penberg@cs.helsinki.fi>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      3078b79d
    • Yinghai Lu's avatar
      x86: tight online check in setup_per_cpu_areas · 7d2de137
      Yinghai Lu authored
      when numa disabled I got this compile warning:
      
      arch/x86/kernel/setup64.c: In function setup_per_cpu_areas:
      arch/x86/kernel/setup64.c:147: warning: the address of
                            contig_page_data will always evaluate as true
      
      it seems we missed checking if the node is online before we try to refer
      NODE_DATA. Fix it.
      Signed-off-by: default avatarYinghai Lu <yhlu.kernel@gmail.com>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      7d2de137
    • Yinghai Lu's avatar
      x86: fix dma_alloc_pages · 6721fc0a
      Yinghai Lu authored
      memory-less node support:
      
      this patch uses updated dev_to_node, because dev_to_node already makes sure
      it returns an online node.
      Signed-off-by: default avatarYinghai Lu <yinghai.lu@sun.com>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      6721fc0a
    • Linus Torvalds's avatar
    • Linus Torvalds's avatar
      Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-2.6 · 7d3628b2
      Linus Torvalds authored
      * git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-2.6: (46 commits)
        [NET] ifb: set separate lockdep classes for queue locks
        [IPV6] KCONFIG: Fix description about IPV6_TUNNEL.
        [TCP]: Fix shrinking windows with window scaling
        netpoll: zap_completion_queue: adjust skb->users counter
        bridge: use time_before() in br_fdb_cleanup()
        [TG3]: Fix build warning on sparc32.
        MAINTAINERS: bluez-devel is subscribers-only
        audit: netlink socket can be auto-bound to pid other than current->pid (v2)
        [NET]: Fix permissions of /proc/net
        [SCTP]: Fix a race between module load and protosw access
        [NETFILTER]: ipt_recent: sanity check hit count
        [NETFILTER]: nf_conntrack_h323: logical-bitwise & confusion in process_setup()
        [RT2X00] drivers/net/wireless/rt2x00/rt2x00dev.c: remove dead code, fix warning
        [IPV4]: esp_output() misannotations
        [8021Q]: vlan_dev misannotations
        xfrm: ->eth_proto is __be16
        [IPV4]: ipv4_is_lbcast() misannotations
        [SUNRPC]: net/* NULL noise
        [SCTP]: fix misannotated __sctp_rcv_asconf_lookup()
        [PKT_SCHED]: annotate cls_u32
        ...
      7d3628b2
    • Linus Torvalds's avatar
      Merge git://git.kernel.org/pub/scm/linux/kernel/git/lethal/sh-2.6.25 · 2c787198
      Linus Torvalds authored
      * git://git.kernel.org/pub/scm/linux/kernel/git/lethal/sh-2.6.25:
        sh: Use relative paths for mach/cpu symlinks.
        SH: Use newer, non-deprecated __SPIN_LOCK_UNLOCKED macro.
        sh: Fix more user header breakage from sh64 integration.
        sh: Fix uImage build error.
        sh: Fix up the timer IRQ definition for SH7203.
        sh: Fix up the address error exception handler for SH-2.
        serial: sh-sci: Fix fifo stall on SH7760/SH7780/SH7785 SCIF.
      2c787198
    • Franck Bui-Huu's avatar
      sh: Use relative paths for mach/cpu symlinks. · 49a5ba46
      Franck Bui-Huu authored
      When building the kernel without passing the O= command line parameter
      there's no point to use absolute paths for them.
      
      Usually relative paths are preferred because they survive directory
      moves, work across networked file systems and chrooted environments.
      
      Absolute paths are still used if an output directory is given.
      Signed-off-by: default avatarFranck Bui-Huu <fbuihuu@gmail.com>
      Signed-off-by: default avatarPaul Mundt <lethal@linux-sh.org>
      49a5ba46
    • Robert P. J. Day's avatar
    • Jarek Poplawski's avatar
      [NET] ifb: set separate lockdep classes for queue locks · 94833dfb
      Jarek Poplawski authored
      [   10.536424] =======================================================
      [   10.536424] [ INFO: possible circular locking dependency detected ]
      [   10.536424] 2.6.25-rc3-devel #3
      [   10.536424] -------------------------------------------------------
      [   10.536424] swapper/0 is trying to acquire lock:
      [   10.536424]  (&dev->queue_lock){-+..}, at: [<c0299b4a>] 
      dev_queue_xmit+0x175/0x2f3
      [   10.536424]
      [   10.536424] but task is already holding lock:
      [   10.536424]  (&p->tcfc_lock){-+..}, at: [<f8a67154>] tcf_mirred+0x20/0x178 
      [act_mirred]
      [   10.536424]
      [   10.536424] which lock already depends on the new lock.
      
      lockdep warns of locking order while using ifb with sch_ingress and
      act_mirred: ingress_lock, tcfc_lock, queue_lock (usually queue_lock
      is at the beginning). This patch is only to tell lockdep that ifb is
      a different device (e.g. from eth) and has its own pair of queue
      locks. (This warning is a false-positive in common scenario of using
      ifb; yet there are possible situations, when this order could be
      dangerous; lockdep should warn in such a case.) (With suggestions by
      David S. Miller)
      Reported-and-tested-by: default avatarDenys Fedoryshchenko <denys@visp.net.lb>
      Signed-off-by: default avatarJarek Poplawski <jarkao2@gmail.com>
      Acked-by: default avatarJamal Hadi Salim <hadi@cyberus.ca>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      94833dfb
  2. 20 Mar, 2008 26 commits