1. 09 9月, 2008 17 次提交
    • L
      Merge master.kernel.org:/home/rmk/linux-2.6-arm · 4ced08b8
      Linus Torvalds 提交于
      * master.kernel.org:/home/rmk/linux-2.6-arm:
        [ARM] 5241/1: provide ioremap_wc()
        [ARM] omap: fix virtual vs physical address space confusions
        [ARM] remove unused #include <version.h>
        [ARM] omap: fix build error in ohci-omap.c
        [ARM] omap: fix gpio.c build error
      4ced08b8
    • L
      Merge branch 'sched-fixes-for-linus' of... · e1d7bf14
      Linus Torvalds 提交于
      Merge branch 'sched-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip
      
      * 'sched-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip:
        sched: arch_reinit_sched_domains() must destroy domains to force rebuild
        sched, cpuset: rework sched domains and CPU hotplug handling (v4)
      e1d7bf14
    • L
      Merge branch 'upstream-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jgarzik/libata-dev · e228c1b5
      Linus Torvalds 提交于
      * 'upstream-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jgarzik/libata-dev:
        ahci: RAID mode SATA patch for Intel Ibex Peak DeviceIDs
        pata_sil680: remove duplicate pcim_enable_device
        libata-sff: kill spurious WARN_ON() in ata_hsm_move()
        sata_nv: disable hardreset for generic
        ahci: disable PMP for marvell ahcis
        sata_mv: add RocketRaid 1720 PCI ID to driver
        ahci, pata_marvell: play nicely together
      e228c1b5
    • U
      Fix format of MAINTAINERS · a46add72
      Uwe Kleine-König 提交于
      ... one entry lacked a colon which broke one of my scripts.
      Signed-off-by: NUwe Kleine-König <ukleinek@informatik.uni-freiburg.de>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      a46add72
    • L
      Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-2.6 · bcbc7134
      Linus Torvalds 提交于
      * git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-2.6:
        bridge: don't allow setting hello time to zero
        netns : fix kernel panic in timewait socket destruction
        pkt_sched: Fix qdisc state in net_tx_action()
        netfilter: nf_conntrack_irc: make sure string is terminated before calling simple_strtoul
        netfilter: nf_conntrack_gre: nf_ct_gre_keymap_flush() fixlet
        netfilter: nf_conntrack_gre: more locking around keymap list
        netfilter: nf_conntrack_sip: de-static helper pointers
      bcbc7134
    • L
      Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/sparc-2.6 · b364e2f5
      Linus Torvalds 提交于
      * git://git.kernel.org/pub/scm/linux/kernel/git/davem/sparc-2.6:
        sparc64: Prevent sparc64 from invoking irq handlers on offline CPUs
        sparc64: Fix IPI call locking.
      b364e2f5
    • J
      usb: fix null deferences in low level usb serial · 06dd881f
      Jason Wessel 提交于
      The hw interface drivers for the usb serial devices deference the tty
      structure to set up the parameters for the initial console.  The tty
      structure should be passed as a parameter to the set_termios() call.
      Signed-off-by: NJason Wessel <jason.wessel@windriver.com>
      Signed-off-by: NAlan Cox <alan@redhat.com>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      06dd881f
    • C
      NFS: Restore missing hunk in NFS mount option parser · af904dea
      Chuck Lever 提交于
      Automounter maps can contain mount options valid for other NFS
      implementations but not for Linux.  The Linux automounter uses the
      mount command's "-s" command line option ("s" for "sloppy") so that
      mount requests containing such options are not rejected.
      
      Commit f45663ce attempted to address a
      known regression with text-based NFS mount option parsing.  Unrecognized
      mount options would cause mount requests to fail, even if the "-s"
      option was used on the mount command line.
      
      Unfortunately, this commit was not complete as submitted.  It adds a
      new mount option, "sloppy".  But it is missing a hunk, so it now allows
      NFS mounts with unrecognized mount options, even if the "sloppy" option
      is not present.  This could be a problem if a required critical mount
      option such as "sync" is misspelled, for example, and is considered a
      regression from 2.6.26.
      
      This patch restores the missing hunk.  Now, the default behavior of
      text-based NFS mount options is as before: any unrecognized mount option
      will cause the mount to fail.
      
      Please include this in 2.6.27-rc.
      
      Thanks to Neil Brown for reporting this.
      Signed-off-by: NChuck Lever <chuck.lever@oracle.com>
      Acked-by: NJ. Bruce Fields <bfields@citi.umich.edu>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      af904dea
    • S
      bridge: don't allow setting hello time to zero · 8d4698f7
      Stephen Hemminger 提交于
      Dushan Tcholich reports that on his system ksoftirqd can consume
      between %6 to %10 of cpu time, and cause ~200 context switches per
      second.
      
      He then correlated this with a report by bdupree@techfinesse.com:
      
      	http://marc.info/?l=linux-kernel&m=119613299024398&w=2
      
      and the culprit cause seems to be starting the bridge interface.
      In particular, when starting the bridge interface, his scripts
      are specifying a hello timer interval of "0".
      
      The bridge hello time can't be safely set to values less than 1
      second, otherwise it is possible to end up with a runaway timer.
      Signed-off-by: NStephen Hemminger <shemminger@vyatta.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      8d4698f7
    • D
      netns : fix kernel panic in timewait socket destruction · d315492b
      Daniel Lezcano 提交于
      How to reproduce ?
       - create a network namespace
       - use tcp protocol and get timewait socket
       - exit the network namespace
       - after a moment (when the timewait socket is destroyed), the kernel
         panics.
      
      # BUG: unable to handle kernel NULL pointer dereference at
      0000000000000007
      IP: [<ffffffff821e394d>] inet_twdr_do_twkill_work+0x6e/0xb8
      PGD 119985067 PUD 11c5c0067 PMD 0
      Oops: 0000 [1] SMP
      CPU 1
      Modules linked in: ipv6 button battery ac loop dm_mod tg3 libphy ext3 jbd
      edd fan thermal processor thermal_sys sg sata_svw libata dock serverworks
      sd_mod scsi_mod ide_disk ide_core [last unloaded: freq_table]
      Pid: 0, comm: swapper Not tainted 2.6.27-rc2 #3
      RIP: 0010:[<ffffffff821e394d>] [<ffffffff821e394d>]
      inet_twdr_do_twkill_work+0x6e/0xb8
      RSP: 0018:ffff88011ff7fed0 EFLAGS: 00010246
      RAX: ffffffffffffffff RBX: ffffffff82339420 RCX: ffff88011ff7ff30
      RDX: 0000000000000001 RSI: ffff88011a4d03c0 RDI: ffff88011ac2fc00
      RBP: ffffffff823392e0 R08: 0000000000000000 R09: ffff88002802a200
      R10: ffff8800a5c4b000 R11: ffffffff823e4080 R12: ffff88011ac2fc00
      R13: 0000000000000001 R14: 0000000000000001 R15: 0000000000000000
      FS: 0000000041cbd940(0000) GS:ffff8800bff839c0(0000)
      knlGS:0000000000000000
      CS: 0010 DS: 0018 ES: 0018 CR0: 000000008005003b
      CR2: 0000000000000007 CR3: 00000000bd87c000 CR4: 00000000000006e0
      DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
      Process swapper (pid: 0, threadinfo ffff8800bff9e000, task
      ffff88011ff76690)
      Stack: ffffffff823392e0 0000000000000100 ffffffff821e3a3a
      0000000000000008
      0000000000000000 ffffffff821e3a61 ffff8800bff7c000 ffffffff8203c7e7
      ffff88011ff7ff10 ffff88011ff7ff10 0000000000000021 ffffffff82351108
      Call Trace:
      <IRQ> [<ffffffff821e3a3a>] ? inet_twdr_hangman+0x0/0x9e
      [<ffffffff821e3a61>] ? inet_twdr_hangman+0x27/0x9e
      [<ffffffff8203c7e7>] ? run_timer_softirq+0x12c/0x193
      [<ffffffff820390d1>] ? __do_softirq+0x5e/0xcd
      [<ffffffff8200d08c>] ? call_softirq+0x1c/0x28
      [<ffffffff8200e611>] ? do_softirq+0x2c/0x68
      [<ffffffff8201a055>] ? smp_apic_timer_interrupt+0x8e/0xa9
      [<ffffffff8200cad6>] ? apic_timer_interrupt+0x66/0x70
      <EOI> [<ffffffff82011f4c>] ? default_idle+0x27/0x3b
      [<ffffffff8200abbd>] ? cpu_idle+0x5f/0x7d
      
      
      Code: e8 01 00 00 4c 89 e7 41 ff c5 e8 8d fd ff ff 49 8b 44 24 38 4c 89 e7
      65 8b 14 25 24 00 00 00 89 d2 48 8b 80 e8 00 00 00 48 f7 d0 <48> 8b 04 d0
      48 ff 40 58 e8 fc fc ff ff 48 89 df e8 c0 5f 04 00
      RIP [<ffffffff821e394d>] inet_twdr_do_twkill_work+0x6e/0xb8
      RSP <ffff88011ff7fed0>
      CR2: 0000000000000007
      
      This patch provides a function to purge all timewait sockets related
      to a network namespace. The timewait sockets life cycle is not tied with
      the network namespace, that means the timewait sockets stay alive while
      the network namespace dies. The timewait sockets are for avoiding to
      receive a duplicate packet from the network, if the network namespace is
      freed, the network stack is removed, so no chance to receive any packets
      from the outside world. Furthermore, having a pending destruction timer
      on these sockets with a network namespace freed is not safe and will lead
      to an oops if the timer callback which try to access data belonging to 
      the namespace like for example in:
      	inet_twdr_do_twkill_work
      		-> NET_INC_STATS_BH(twsk_net(tw), LINUX_MIB_TIMEWAITED);
      
      Purging the timewait sockets at the network namespace destruction will:
       1) speed up memory freeing for the namespace
       2) fix kernel panic on asynchronous timewait destruction
      Signed-off-by: NDaniel Lezcano <dlezcano@fr.ibm.com>
      Acked-by: NDenis V. Lunev <den@openvz.org>
      Acked-by: NEric W. Biederman <ebiederm@xmission.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      d315492b
    • S
      ahci: RAID mode SATA patch for Intel Ibex Peak DeviceIDs · 8e48b6b3
      Seth Heasley 提交于
      Add the Intel Ibex Peak (PCH) SATA RAID Controller DeviceIDs.
      Signed-off-by: NSeth Heasley <seth.heasley@intel.com>
      Signed-off-by: NJeff Garzik <jgarzik@redhat.com>
      8e48b6b3
    • D
      pata_sil680: remove duplicate pcim_enable_device · de058cde
      David Milburn 提交于
      Remove duplicate call to pcim_enable_device in sil680_init_one.
      Signed-off-by: NDavid Milburn <dmilburn@redhat.com>
      Signed-off-by: NJeff Garzik <jgarzik@redhat.com>
      de058cde
    • T
      libata-sff: kill spurious WARN_ON() in ata_hsm_move() · 9c2676b6
      Tejun Heo 提交于
      On HSM_ST_ERR, ata_hsm_move() triggers WARN_ON() if AC_ERR_DEV or
      AC_ERR_HSM is not set.  PHY events may trigger HSM_ST_ERR with other
      error codes and, with or without it, there just isn't much reason to
      do WARN_ON() on it.  Even if error code is not set there, core EH
      logic won't have any problem dealing with the error condition.
      
      OSDL bz#11065 reports this problem.
      Signed-off-by: NTejun Heo <tj@kernel.org>
      Signed-off-by: NJeff Garzik <jgarzik@redhat.com>
      9c2676b6
    • T
      sata_nv: disable hardreset for generic · 2fd673ec
      Tejun Heo 提交于
      of them being unifying probing, hotplug and EH reset paths uniform.
      Previously, broken hardreset could go unnoticed as it wasn't used
      during probing but when something goes wrong or after hotplug the
      problem will surface and bite hard.
      
      OSDL bug 11195 reports that sata_nv generic flavor falls into this
      category.  Hardreset itself succeeds but PHY stays offline after
      hardreset.  I tried longer debounce timing but the result was the
      same.
      
        http://bugzilla.kernel.org/show_bug.cgi?id=11195
      
      So, it seems we'll have to drop hardreset from the generic flavor.
      Signed-off-by: NTejun Heo <tj@kernel.org>
      Cc: Peer Chen <pchen@nvidia.com>
      Signed-off-by: NJeff Garzik <jgarzik@redhat.com>
      2fd673ec
    • T
      ahci: disable PMP for marvell ahcis · 17248461
      Tejun Heo 提交于
      Marvell ahcis don't play nicely with PMPs.  Disable it.
      
      Reported by KueiHuan Chen in the following thread.
      
        http://thread.gmane.org/gmane.linux.ide/33296Signed-off-by: NTejun Heo <tj@kernel.org>
      Cc: KueiHuan Chen <kueihuan.chen@gmail.com>
      Cc: Mark Lord <mlord@pobox.com>
      Signed-off-by: NJeff Garzik <jgarzik@redhat.com>
      17248461
    • M
      sata_mv: add RocketRaid 1720 PCI ID to driver · 46c5784c
      Mark Lord 提交于
      Signed-off-by: NPetr Jelen <petr.jelen@gmail.com>
      Signed-off-by: NMark Lord <mlord@pobox.com>
      Signed-off-by: NJeff Garzik <jgarzik@redhat.com>
      46c5784c
    • A
      ahci, pata_marvell: play nicely together · 5b66c829
      Alan Cox 提交于
      I've been chasing Jeff about this for months.  Jeff added the Marvell
      device identifiers to the ahci driver without making the AHCI driver
      handle the PATA port. This means a lot of users can't use current
      kernels and in most distro cases can't even install.
      
      This has been going on since March 2008 for the 6121 Marvell, and late 2007
      for the 6145!!!
      
      This was all pointed out at the time and repeatedly ignored. Bugs assigned
      to Jeff about this are ignored also.
      
      To quote Jeff in email
      
      > "Just switch the order of 'ahci' and 'pata_marvell' in
      > /etc/modprobe.conf, then use Fedora's tools regenerate the initrd.
      
      > See?  It's not rocket science, and the current configuration can be
      > easily made to work for Fedora users."
      
      (Which isn't trivial, isn't end user, shouldn't be needed, and as it usually
      breaks at install time is in fact impossible)
      
      To quote Jeff in August 2007
      
      > "   mv-ahci-pata
      > Marvell 6121/6141 PATA support.  Needs fixing in the 'PATA controller
      > command' area before it is usable, and can go upstream."
      
      Only he add the ids anyway later and caused regressions, adding a further
      id in March causing more regresions.
      
      The actual fix for the moment is very simple. If the user has included
      the pata_marvell driver let it drive the ports. If they've only selected
      for SATA support give them the AHCI driver which will run the port a fraction
      faster. Allow the user to control this decision via ahci.marvell_enable as
      a module parameter so that distributions can ship 'it works' defaults and
      smarter users (or config tools) can then flip it over it desired.
      Signed-off-by: NAlan Cox <alan@redhat.com>
      Signed-off-by: NJeff Garzik <jgarzik@redhat.com>
      5b66c829
  2. 08 9月, 2008 5 次提交
  3. 07 9月, 2008 10 次提交
  4. 06 9月, 2008 8 次提交
    • Y
      x86: move mtrr cpu cap setting early in early_init_xxxx · dd786dd1
      Yinghai Lu 提交于
      Krzysztof Helt found MTRR is not detected on k6-2
      
      root cause:
      	we moved mtrr_bp_init() early for mtrr trimming,
      and in early_detect we only read the CPU capability from cpuid,
      so some cpu doesn't have that bit in cpuid.
      
      So we need to add early_init_xxxx to preset those bit before mtrr_bp_init
      for those earlier cpus.
      
      this patch is for v2.6.27
      Reported-by: NKrzysztof Helt <krzysztof.h1@wp.pl>
      Signed-off-by: NYinghai Lu <yhlu.kernel@gmail.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      dd786dd1
    • K
      x86: delay early cpu initialization until cpuid is done · 12cf105c
      Krzysztof Helt 提交于
      Move early cpu initialization after cpu early get cap so the
      early cpu initialization can fix up cpu caps.
      Signed-off-by: NKrzysztof Helt <krzysztof.h1@wp.pl>
      Signed-off-by: NYinghai Lu <yhlu.kernel@gmail.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      12cf105c
    • D
      clocksource, acpi_pm.c: check for monotonicity · 4ab6a219
      Dominik Brodowski 提交于
      The current check for monotonicity is way too weak: Andreas Mohr reports (
      http://lkml.org/lkml/2008/8/10/77 ) that on one of his test systems the
      current check only triggers in 50% of all cases, leading to catastrophic
      timer behaviour.  To fix this issue, expand the check for monotonicity by
      doing ten consecutive tests instead of one.
      Signed-off-by: NDominik Brodowski <linux@dominikbrodowski.net>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      4ab6a219
    • D
      clocksource, acpi_pm.c: use proper read function also in errata mode · dfdf748a
      Dominik Brodowski 提交于
      On all hardware (some Intel ICH4, PIIX4 and PIIX4E chipsets) affected by a
      hardware errata there's about a 4.2% chance that initialization of the
      ACPI PMTMR fails.  On those chipsets, we need to read out the timer value
      at least three times to get a correct result, for every once in a while
      (i.e.  within a 3 ns window every 69.8 ns) the read returns a bogus
      result.  During normal operation we work around this issue, but during
      initialization reading a bogus value may lead to -EINVAL even though the
      hardware is usable.
      
      Thanks to Andreas Mohr for spotting this issue.
      Signed-off-by: NDominik Brodowski <linux@dominikbrodowski.net>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      dfdf748a
    • M
      ntp: fix calculation of the next jiffie to trigger RTC sync · 4ff4b9e1
      Maciej W. Rozycki 提交于
      We have a bug in the calculation of the next jiffie to trigger the RTC
      synchronisation.  The aim here is to run sync_cmos_clock() as close as
      possible to the middle of a second.  Which means we want this function to
      be called less than or equal to half a jiffie away from when now.tv_nsec
      equals 5e8 (500000000).
      
      If this is not the case for a given call to the function, for this purpose
      instead of updating the RTC we calculate the offset in nanoseconds to the
      next point in time where now.tv_nsec will be equal 5e8.  The calculated
      offset is then converted to jiffies as these are the unit used by the
      timer.
      
      Hovewer timespec_to_jiffies() used here uses a ceil()-type rounding mode,
      where the resulting value is rounded up.  As a result the range of
      now.tv_nsec when the timer will trigger is from 5e8 to 5e8 + TICK_NSEC
      rather than the desired 5e8 - TICK_NSEC / 2 to 5e8 + TICK_NSEC / 2.
      
      As a result if for example sync_cmos_clock() happens to be called at the
      time when now.tv_nsec is between 5e8 + TICK_NSEC / 2 and 5e8 to 5e8 +
      TICK_NSEC, it will simply be rescheduled HZ jiffies later, falling in the
      same range of now.tv_nsec again.  Similarly for cases offsetted by an
      integer multiple of TICK_NSEC.
      
      This change addresses the problem by subtracting TICK_NSEC / 2 from the
      nanosecond offset to the next point in time where now.tv_nsec will be
      equal 5e8, effectively shifting the following rounding in
      timespec_to_jiffies() so that it produces a rounded-to-nearest result.
      Signed-off-by: NMaciej W. Rozycki <macro@linux-mips.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      4ff4b9e1
    • L
      [ARM] 5241/1: provide ioremap_wc() · 1ad77a87
      Lennert Buytenhek 提交于
      This patch provides an ARM implementation of ioremap_wc().
      
      We use different page table attributes depending on which CPU we
      are running on:
      
      - Non-XScale ARMv5 and earlier systems: The ARMv5 ARM documents four
        possible mapping types (CB=00/01/10/11).  We can't use any of the
        cached memory types (CB=10/11), since that breaks coherency with
        peripheral devices.  Both CB=00 and CB=01 are suitable for _wc, and
        CB=01 (Uncached/Buffered) allows the hardware more freedom than
        CB=00, so we'll use that.
      
        (The ARMv5 ARM seems to suggest that CB=01 is allowed to delay stores
        but isn't allowed to merge them, but there is no other mapping type
        we can use that allows the hardware to delay and merge stores, so
        we'll go with CB=01.)
      
      - XScale v1/v2 (ARMv5): same as the ARMv5 case above, with the slight
        difference that on these platforms, CB=01 actually _does_ allow
        merging stores.  (If you want noncoalescing bufferable behavior
        on Xscale v1/v2, you need to use XCB=101.)
      
      - Xscale v3 (ARMv5) and ARMv6+: on these systems, we use TEXCB=00100
        mappings (Inner/Outer Uncacheable in xsc3 parlance, Uncached Normal
        in ARMv6 parlance).
      
        The ARMv6 ARM explicitly says that any accesses to Normal memory can
        be merged, which makes Normal memory more suitable for _wc mappings
        than Device or Strongly Ordered memory, as the latter two mapping
        types are guaranteed to maintain transaction number, size and order.
        We use the Uncached variety of Normal mappings for the same reason
        that we can't use C=1 mappings on ARMv5.
      
        The xsc3 Architecture Specification documents TEXCB=00100 as being
        Uncacheable and allowing coalescing of writes, which is also just
        what we need.
      Signed-off-by: NLennert Buytenhek <buytenh@marvell.com>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      1ad77a87
    • T
      Fix CONFIG_AC97_BUS dependency · 8a656496
      Takashi Iwai 提交于
      CONFIG_AC97_BUS is used from both sound and ucb1400 drivers.
      The recent change in Kconfig introduced the exclusive dependency on
      CONFIG_SOUND, and disabled the ucb1400 build without sound.
      This patch makes CONFIG_AC97_BUS independent.
      Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      Tested-by: NRandy Dunlap <randy.dunlap@oracle.com>
      8a656496
    • T
      x86: HPET: read back compare register before reading counter · 72d43d9b
      Thomas Gleixner 提交于
      After fixing the u32 thinko I sill had occasional hickups on ATI chipsets
      with small deltas. There seems to be a delay between writing the compare
      register and the transffer to the internal register which triggers the
      interrupt. Reading back the value makes sure, that it hit the internal
      match register befor we compare against the counter value.
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      72d43d9b