1. 17 Oct, 2005 4 commits
    • Ronald S. Bultje's avatar
      [PATCH] fix vpx3220 offset issue in SECAM · 9b3acc21
      Ronald S. Bultje authored
      Fix bug #5404 in kernel bugzilla.
      It basically updates the vpx3220 initialization tables with some newer
      values that we've had in CVS for a while (and that, for some reason, never
      ended up in the kernel...  must've gotten lost).  Those fix a ~16 pixels
      noise at the top of the picture in at least SECAM, although (now that I
      think about it) PAL was probably affected, also.
      Signed-off-by: default avatarRonald S. Bultje <rbultje@ronald.bitfreak.net>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
    • Samuel Thibault's avatar
      [PATCH] SVGATextMode fix · 0aec4867
      Samuel Thibault authored
      Fix bug 5441.
      I didn't know about messy programs like svgatextmode...  Couldn't this be
      integrated in some linux/drivers/video/console/svgacon.c ?...  So because
      of the existence of the svgatextmode program, the kernel is not supposed to
      Disabling the check in vgacon_resize() might help indeed, but I'm really
      not sure whether it will work for any chipset: in my patch, CRT registers
      are set at each console switch, since stty rows/cols apply to consoles
      The attached solution is to keep the test, but if it fails, we assume that
      the caller knows what it does (i.e.  it is svgatextmode) and then disable
      any further call to vgacon_doresize.  Svgatextmode is usually used to
      _expand_ the display, not to shrink it.  And it is harmless in the case of
      a too big stty rows/cols: the display will just be cropped.  I tested it on
      my laptop, and it works fine with svgatextmode.
      A better solution would be that svgatextmode explicitely tells the kernel
      not to care about video timing, but for this an interface needs be defined
      and svgatextmode be patched.
      Signed-off-by: default avatarSamuel Thibault <samuel.thibault@ens-lyon.org>
      Cc: "Antonino A. Daplas" <adaplas@pol.net>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
    • Herbert Xu's avatar
      [PATCH] list: add missing rcu_dereference on first element · b24d18aa
      Herbert Xu authored
      It seems that all the list_*_rcu primitives are missing a memory barrier
      on the very first dereference.  For example,
      #define list_for_each_rcu(pos, head) \
      	for (pos = (head)->next; prefetch(pos->next), pos != (head); \
      		pos = rcu_dereference(pos->next))
      It will go something like:
      	pos = (head)->next
      	pos != (head)
      	do stuff
      We're missing a barrier here.
      	pos = rcu_dereference(pos->next)
      		fetch pos->next
      		barrier given by rcu_dereference(pos->next)
      		store pos
      Without the missing barrier, the pos->next value may turn out to be stale.
      In fact, if "do stuff" were also dereferencing pos and relying on
      list_for_each_rcu to provide the barrier then it may also break.
      So here is a patch to make sure that we have a barrier for the first
      element in the list.
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      Acked-by: default avatar"Paul E. McKenney" <paulmck@us.ibm.com>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
    • Linus Torvalds's avatar
      Fix memory ordering bug in page reclaim · 3d80636a
      Linus Torvalds authored
      As noticed by Nick Piggin, we need to make sure that we check the page
      count before we check for PageDirty, since the dirty check is only valid
      if the count implies that we're the only possible ones holding the page.
      We always did do this, but the code needs a read-memory-barrier to make
      sure that the orderign is also honored by the CPU.
      (The writer side is ordered due to the atomic decrement and test on the
      page count, see the discussion on linux-kernel)
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
  2. 16 Oct, 2005 1 commit
    • Al Viro's avatar
      [PATCH]: highest_possible_processor_id() has to be a macro · 688ce17b
      Al Viro authored
      	... otherwise, things like alpha and sparc64 break and break
      badly.  They define cpu_possible_map to something else in smp.h
      *AFTER* having included cpumask.h.
      	If that puppy is a macro, expansion will happen at the actual
      caller, when we'd already seen #define cpu_possible_map ... and we will
      get the right thing used.
      	As an inline helper it will be tokenized before we get to that
      define and that's it; no matter what we define later, it won't affect
      anything.  We get modules with dependency on cpu_possible_map instead
      of the right symbol (phys_cpu_present_map in case of sparc64), or outright
      link errors if they are built-in.
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
  3. 15 Oct, 2005 20 commits
  4. 14 Oct, 2005 11 commits
  5. 13 Oct, 2005 4 commits