1. 01 Oct, 2007 3 commits
  2. 29 Sep, 2007 4 commits
    • Jan Lübbe's avatar
      fix console change race exposed by CFS · a64314e6
      Jan Lübbe authored
      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: default avatarJan Lübbe <jluebbe@lasnet.de>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      a64314e6
    • Linus Torvalds's avatar
      Merge branch 'upstream-linus' of master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/netdev-2.6 · ed7fdff5
      Linus Torvalds authored
      * 'upstream-linus' of master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/netdev-2.6:
        mv643xx_eth: Check ETH_INT_CAUSE_STATE bit
      ed7fdff5
    • Nick Piggin's avatar
      i386: remove bogus comment about memory barrier · 4827bbb0
      Nick Piggin authored
      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: default avatarNick 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: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      4827bbb0
    • Dale Farnsworth's avatar
      mv643xx_eth: Check ETH_INT_CAUSE_STATE bit · 2bcff60f
      Dale Farnsworth authored
      Commit 468d09f8 masked the "state"
      interrupt (bit 20 of the cause register). This results in Radstone's
      PPC7D repeatedly re-entering the interrupt routine, locking up the
      board. The following patch returns the required handling for this
      interrupt.
      Signed-off-by: default avatarMartyn Welch <martyn.welch@radstone.co.uk>
      Signed-off-by: default avatarDale Farnsworth <dale@farnsworth.org>
      Signed-off-by: default avatarJeff Garzik <jeff@garzik.org>
      2bcff60f
  3. 28 Sep, 2007 24 commits
  4. 27 Sep, 2007 3 commits
  5. 26 Sep, 2007 6 commits
    • Linus Torvalds's avatar
      Revert "[PATCH] x86-64: fix x86_64-mm-sched-clock-share" · ff0ce684
      Linus Torvalds authored
      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: default avatarDave 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: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      ff0ce684
    • Linus Torvalds's avatar
      a07921bc
    • Linus Torvalds's avatar
      Revert "x86-64: Disable local APIC timer use on AMD systems with C1E" · f7f847b0
      Linus Torvalds authored
      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: default avatarRafael J. Wysocki <rjw@sisk.pl>
      Acked-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      f7f847b0
    • H. Peter Anvin's avatar
      [x86 setup] Handle case of improperly terminated E820 chain · 2efa33f8
      H. Peter Anvin authored
      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: default avatarH. Peter Anvin <hpa@zytor.com>
      Cc: Jordan Crouse <jordan.crouse@amd.com>
      Cc: Joerg Pommnitz <pommnitz@yahoo.com>
      2efa33f8
    • Jeremy Fitzhardinge's avatar
      xen: execve's error paths don't pin the mm before unpinning · df912ea4
      Jeremy Fitzhardinge authored
      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: default avatarJeremy Fitzhardinge <jeremy@xensource.com>
      Cc: Christian Ostheimer <osth@freesurf.ch>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      df912ea4
    • Thomas Gleixner's avatar
      x86-64: Disable local APIC timer use on AMD systems with C1E · e66485d7
      Thomas Gleixner authored
      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: default avatarThomas Gleixner <tglx@linutronix.de>
      Tested-by: default avatarRafael J. Wysocki <rjw@sisk.pl>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      e66485d7