1. 01 Oct, 2007 8 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 1 commit