1. 13 Dec, 2004 3 commits
    • David Brownell's avatar
      [PATCH] reduce ext3 log spamming (blank lines) · 09775c85
      David Brownell authored
      When drives go offline, e.g.  usb-storage disconnect, the upper layers
      don't behave very intelligently yet: ext3 over scsi keeps retrying reads,
      logging three lines for each error:
      
      10:58:31  scsi0 (0:0): rejecting I/O to dead device
      10:58:31  EXT3-fs error (device sda1): ext3_find_entry: reading directory #18089296 offset 0
      10:58:31 
      10:59:47  EXT3-fs error (device sda1): ext3_find_entry: reading directory #18089296 offset 0
      
      This patch shrinks that log spam by the trivial third, getting rid of those
      needless blank lines.  It's not clear to me why the "no such device" errors
      don't immediately make ext3 (or is it the block layer?) give up ...  maybe
      someone else can make Linux not retry after those errors.
      Signed-off-by: default avatarDavid Brownell <dbrownell@users.sourceforge.net>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      09775c85
    • Andrew Morton's avatar
      [PATCH] direct-io: set PF_SYNCWRITE · 9f5354ec
      Andrew Morton authored
      We need to set the PF_SYNCWRITE when performing direct-io writes.  Otherwise
      the anticipatory scheduler exhibits bad read-starves-write problems.
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      9f5354ec
    • Paul Mackerras's avatar
      [PATCH] ppc64: make UP kernel run on POWER4 logical partition · 6e27d936
      Paul Mackerras authored
      Recently I tried booting a UP kernel on a 1-processor logical partition on
      a POWER4 system.  It failed because the CPU we happened to be running on
      was CPU 2, but hard_smp_processor_id() is defined to 0 for !CONFIG_SMP. 
      (Note that this code runs quite early, as part of init_IRQ, so
      hard_smp_processor_id() should be the physical ID of the boot cpu.)
      
      This patch does a minimal fix to make it work.  I think this patch should
      go in 2.6.10.  Ultimately I think the hard_smp_processor_id() definition
      should be removed from include/linux/smp.h, but that carries a risk of
      breaking other architectures and probably shouldn't be done pre 2.6.10.
      Signed-off-by: default avatarPaul Mackerras <paulus@samba.org>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      6e27d936
  2. 12 Dec, 2004 9 commits
  3. 11 Dec, 2004 3 commits
  4. 10 Dec, 2004 14 commits
  5. 09 Dec, 2004 11 commits