1. 30 9月, 2007 4 次提交
    • I
      V4L/DVB (6052): ivtv: fix udma yuv bug · cb50f548
      Ian Armstrong 提交于
      Using udma yuv causes the driver becomes locked into that mode. This prevents
      use of the mpeg decoder & non-udma yuv output. This patch clears the
      operating mode when the device is closed.
      Signed-off-by: NIan Armstrong <ian@iarmst.demon.co.uk>
      Signed-off-by: NHans Verkuil <hverkuil@xs4all.nl>
      Signed-off-by: NMauro Carvalho Chehab <mchehab@infradead.org>
      cb50f548
    • J
      fix console change race exposed by CFS · a64314e6
      Jan Lübbe 提交于
      The new behaviour of CFS exposes a race which occurs if a switch is
      requested when vt_mode.mode is VT_PROCESS.
      
      The process with vc->vt_pid is signaled before vc->vt_newvt is set.
      This causes the switch to fail when triggered by the monitoing process
      because the target is still -1.
      
      [ If the signal sending fails, the subsequent "reset_vc(vc)" will then
        reset vt_newvt to -1, so this works for that case too.   - Linus ]
      Signed-off-by: NJan Lübbe <jluebbe@lasnet.de>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      a64314e6
    • L
      Merge branch 'upstream-linus' of master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/netdev-2.6 · ed7fdff5
      Linus Torvalds 提交于
      * 'upstream-linus' of master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/netdev-2.6:
        mv643xx_eth: Check ETH_INT_CAUSE_STATE bit
      ed7fdff5
    • N
      i386: remove bogus comment about memory barrier · 4827bbb0
      Nick Piggin 提交于
      The comment being removed by this patch is incorrect and misleading.
      
      In the following situation:
      
      	1. load  ...
      	2. store 1 -> X
      	3. wmb
      	4. rmb
      	5. load  a <- Y
      	6. store ...
      
      4 will only ensure ordering of 1 with 5.
      3 will only ensure ordering of 2 with 6.
      
      Further, a CPU with strictly in-order stores will still only provide that
      2 and 6 are ordered (effectively, it is the same as a weakly ordered CPU
      with wmb after every store).
      
      In all cases, 5 may still be executed before 2 is visible to other CPUs!
      
      The additional piece of the puzzle that mb() provides is the store/load
      ordering, which fundamentally cannot be achieved with any combination of
      rmb()s and wmb()s.
      
      This can be an unexpected result if one expected any sort of global ordering
      guarantee to barriers (eg. that the barriers themselves are sequentially
      consistent with other types of barriers).  However sfence or lfence barriers
      need only provide an ordering partial ordering of memory operations -- Consider
      that wmb may be implemented as nothing more than inserting a special barrier
      entry in the store queue, or, in the case of x86, it can be a noop as the store
      queue is in order. And an rmb may be implemented as a directive to prevent
      subsequent loads only so long as their are no previous outstanding loads (while
      there could be stores still in store queues).
      
      I can actually see the occasional load/store being reordered around lfence on
      my core2. That doesn't prove my above assertions, but it does show the comment
      is wrong (unless my program is -- can send it out by request).
      
      So:
         mb() and smp_mb() always have and always will require a full mfence
         or lock prefixed instruction on x86.  And we should remove this comment.
      Signed-off-by: NNick Piggin <npiggin@suse.de>
      Cc: Paul McKenney <paulmck@us.ibm.com>
      Cc: David Howells <dhowells@redhat.com>
      Cc: Andi Kleen <ak@suse.de>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      4827bbb0
  2. 29 9月, 2007 14 次提交
  3. 28 9月, 2007 14 次提交
  4. 27 9月, 2007 8 次提交
    • L
      Revert "[PATCH] x86-64: fix x86_64-mm-sched-clock-share" · ff0ce684
      Linus Torvalds 提交于
      This reverts commit 184c44d2.
      
      As noted by Dave Jones:
         "Linus, please revert the above cset.  It doesn't seem to be
          necessary (it was added to fix a miscompile in 'make allnoconfig'
          which doesn't seem to be repeatable with it reverted) and actively
         breaks the ARM SA1100 framebuffer driver."
      Requested-by: NDave Jones <davej@redhat.com>
      Cc: Russell King <rmk+lkml@arm.linux.org.uk>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Andi Kleen <ak@suse.de>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      ff0ce684
    • L
      Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/hpa/linux-2.6-x86setup · a07921bc
      Linus Torvalds 提交于
      * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/hpa/linux-2.6-x86setup:
        [x86 setup] Handle case of improperly terminated E820 chain
      a07921bc
    • L
      Revert "x86-64: Disable local APIC timer use on AMD systems with C1E" · f7f847b0
      Linus Torvalds 提交于
      This reverts commit e66485d7, since
      Rafael Wysocki noticed that the change only works for his in -mm, not in
      mainline (and that both "noapictimer" _and_ "apicmaintimer" are broken
      on his hardware, but that's apparently not a regression, just a symptom
      of the same issue that causes the automatic apic timer disable to not
      work).
      
      It turns out that it really doesn't work correctly on x86-64, since
      x86-64 doesn't use the generic clock events for timers yet.
      
      Thanks to Rafal for testing, and here's the ugly details on x86-64 as
      per Thomas:
      
        "I just looked into the code and the logic vs.  noapictimer on SMP is
         completely broken.
      
         On i386 the noapictimer option not only disables the local APIC
         timer, it also registers the CPUs for broadcasting via IPI on SMP
         systems.
      
         The x86-64 code uses the broadcast only when the local apic timer is
         active, i.e.  "noapictimer" is not on the command line.  This defeats
         the whole purpose of "noapictimer".  It should be there to make boxen
         work, where the local APIC timer actually has a hardware problem,
         e.g.  the nx6325.
      
         The current implementation of x86_64 only fixes the ACPI c-states
         related problem where the APIC timer stops in C3(2), nothing else.
      
         On nx6325 and other AMD X2 equipped systems which have the C1E
         enabled we run into the following:
      
         PIT keeps jiffies (and the system) running, but the local APIC timer
         interrupts can get out of sync due to this C1E effect.
      
         I don't think this is a critical problem, but it is wrong
         nevertheless.
      
         I think it's safe to revert the C1E patch and postpone the fix to the
         clock events conversion."
      
      On further reflection, Thomas noted:
      
         "It's even worse than I thought on the first check:
      
          "noapictimer" on the command line of an SMP box prevents _ONLY_ the
          boot CPU apic timer from being used.  But the secondary CPU is still
          unconditionally setting up the APIC timer and uses the non
          calibrated variable calibration_result, which is of course 0, to
          setup the APIC timer.  Wreckage guaranteed."
      
      so we'll just have to wait for the x86 merge to hopefully fix this up
      for x86-64.
      Tested-and-requested-by: NRafael J. Wysocki <rjw@sisk.pl>
      Acked-by: NThomas Gleixner <tglx@linutronix.de>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      f7f847b0
    • H
      [x86 setup] Handle case of improperly terminated E820 chain · 2efa33f8
      H. Peter Anvin 提交于
      At least one system (a Geode system with a Digital Logic BIOS) has
      been found which suddenly stops reporting the SMAP signature when
      reading the E820 memory chain.  We can't know what, exactly, broke in
      the BIOS, so if we detect this situation, declare the E820 data
      unusable and fall back to E801.
      
      Also, revert to original behavior of always probing all memory
      methods; that way all the memory information is available to the
      kernel.
      Signed-off-by: NH. Peter Anvin <hpa@zytor.com>
      Cc: Jordan Crouse <jordan.crouse@amd.com>
      Cc: Joerg Pommnitz <pommnitz@yahoo.com>
      2efa33f8
    • J
      xen: execve's error paths don't pin the mm before unpinning · df912ea4
      Jeremy Fitzhardinge 提交于
      execve's error paths don't activate (and therefore pin) the mm before
      calling exit_mmap to free it up, so don't try to unpin unless it is
      actually pinned.  This prevents a BUG_ON from triggering.
      Signed-off-by: NJeremy Fitzhardinge <jeremy@xensource.com>
      Cc: Christian Ostheimer <osth@freesurf.ch>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      df912ea4
    • T
      x86-64: Disable local APIC timer use on AMD systems with C1E · e66485d7
      Thomas Gleixner 提交于
      commit 3556ddfa titled
      
       [PATCH] x86-64: Disable local APIC timer use on AMD systems with C1E
      
      solves a problem with AMD dual core laptops e.g. HP nx6325 (Turion 64
      X2) with C1E enabled:
      
      When both cores go into idle at the same time, then the system switches
      into C1E state, which is basically the same as C3. This stops the local
      apic timer.
      
      This was debugged right after the dyntick merge on i386 and despite the
      patch title it fixes only the 32 bit path.
      
      x86_64 is still missing this fix. It seems that mainline is not really
      affected by this issue, as the PIT is running and keeps jiffies
      incrementing, but that's just waiting for trouble.
      
      -mm suffers from this problem due to the x86_64 high resolution timer
      patches.
      
      This is a quick and dirty port of the i386 code to x86_64.
      
      I spent quite a time with Rafael to debug the -mm / hrt wreckage until
      someone pointed us to this. I really had forgotten that we debugged this
      half a year ago already.
      
      Sigh, is it just me or is there something yelling arch/x86 into my ear?
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Tested-by: NRafael J. Wysocki <rjw@sisk.pl>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      e66485d7
    • S
      Silent drivers/char/hpet.c build warnings on i386 · 3dffec45
      S.Çağlar Onur 提交于
      Following patch silents;
      
      ...
      drivers/char/hpet.c:72: warning: 'clocksource_hpet' defined but not used
      drivers/char/hpet.c:81: warning: 'hpet_clocksource' defined but not used
      ...
      
      build warnings on i386, they appeared after commit 3b2b64fdSigned-off-by: NS.Çağlar Onur <caglar@pardus.org.tr>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      --
       drivers/char/hpet.c |    3 +++
       1 files changed, 3 insertions(+), 0 deletions(-)
      3dffec45
    • T
      NLM: Fix a circular lock dependency in lockd · 255129d1
      Trond Myklebust 提交于
      The problem is that the garbage collector for the 'host' structures
      nlm_gc_hosts(), holds nlm_host_mutex while calling down to
      nlmsvc_mark_resources, which, eventually takes the file->f_mutex.
      
      We cannot therefore call nlmsvc_lookup_host() from within
      nlmsvc_create_block, since the caller will already hold file->f_mutex, so
      the attempt to grab nlm_host_mutex may deadlock.
      
      Fix the problem by calling nlmsvc_lookup_host() outside the file->f_mutex.
      Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      255129d1