1. 26 5月, 2005 12 次提交
  2. 25 5月, 2005 7 次提交
  3. 24 5月, 2005 15 次提交
  4. 23 5月, 2005 1 次提交
    • B
      [PATCH] ppc64: Fix booting on latest G5 models · 1263cc67
      Benjamin Herrenschmidt 提交于
      The latest speedbumped Apple G5 models have a "bug" in the Open Firmware
      device tree that lacks the proper interrupt routing information for the
      northbridge i2c controller.  Apple's driver silently falls back into a
      sub-optimal "polled" mode (heh, maybe they didn't even notice the bug
      because of that :), our driver didn't properly check and crashes :(
      
      This patch fixes our driver to not crash, and adds code to the
      prom_init() OF trampoline code that detects the "bug" and adds the
      missing information back for this chipset revision.  This fixes booting
      and thermal control on these models.
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      1263cc67
  5. 22 5月, 2005 5 次提交
    • S
      [PATCH] fix for __generic_file_aio_read() to return 0 on EOF · b5c44c21
      Suparna Bhattacharya 提交于
      I came across the following problem while running ltp-aiodio testcases from
      ltp-full-20050405 on linux-2.6.12-rc3-mm3.  I tried running the tests with
      EXT3 as well as JFS filesystems.
      
      One or two fsx-linux testcases were hung after some time.  These testcases
      were hanging at wait_for_all_aios().
      
      Debugging shows that there were some iocbs which were not getting completed
      eventhough the last retry for those returned -EIOCBQUEUED.  Also all such
      pending iocbs represented READ operation.
      
      Further debugging revealed that all such iocbs hit EOF in the DIO layer.
      To be more precise, the "pos" from which they were trying to read was
      greater than the "size" of the file.  So the generic_file_direct_IO
      returned 0.
      
      This happens rarely as there is already a check in
      __generic_file_aio_read(), for whether "pos" < "size" before calling direct
      IO routine.
      
      >size = i_size_read(inode);
      >if (pos < size) {
      >	  retval = generic_file_direct_IO(READ, iocb,
      >                               iov, pos, nr_segs);
      
      But for READ, we are taking the inode->i_sem only in the DIO layer.  So it
      is possible that some other process can change the size of the file before
      we take the i_sem.  In such a case ( when "pos" > "size"), the
      __generic_file_aio_read() would return -EIOCBQUEUED even though there were
      no I/O requests submitted by the DIO layer.  This would cause the AIO layer
      to expect aio_complete() for THE iocb, which doesnot happen.  And thus the
      test hangs forever, waiting for an I/O completion, where there are no
      requests submitted at all.
      
      The following patch makes __generic_file_aio_read() return 0 (instead of
      returning -EIOCBQUEUED), on getting 0 from generic_file_direct_IO(), so
      that the AIO layer does the aio_complete().
      
      Testing:
      
      I have tested the patch on a SMP machine(with 2 Pentium 4 (HT)) running
      linux-2.6.12-rc3-mm3.  I ran the ltp-aiodio testcases and none of the
      fsx-linux tests hung.  Also the aio-stress tests ran without any problem.
      Signed-off-by: NSuzuki K P <suzuki@in.ibm.com>
      Signed-off-by: NSuparna Bhattacharya <suparna@in.ibm.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      b5c44c21
    • V
      [PATCH] reiserfs: max_key fix · f359b74c
      Vladimir Saveliev 提交于
      This patch fixes a bug introduced by Al Viro's patch: [patch 136/174]
      reiserfs endianness: clone struct reiserfs_key
      
      The problem is MAX_KEY and MAX_IN_CORE_KEY defined in this patch do not
      look equal from reiserfs comp_key's point of view.  This caused reiserfs'
      sanity check to complain.
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      f359b74c
    • L
      1808caff
    • L
      3d15e4a3
    • S
      [PATCH] spin_unlock_bh() and preempt_check_resched() · 10f02d1c
      Samuel Thibault 提交于
      In _spin_unlock_bh(lock):
      	do { \
      		_raw_spin_unlock(lock); \
      		preempt_enable(); \
      		local_bh_enable(); \
      		__release(lock); \
      	} while (0)
      
      there is no reason for using preempt_enable() instead of a simple
      preempt_enable_no_resched()
      
      Since we know bottom halves are disabled, preempt_schedule() will always
      return at once (preempt_count!=0), and hence preempt_check_resched() is
      useless here...
      
      This fixes it by using "preempt_enable_no_resched()" instead of the
      "preempt_enable()", and thus avoids the useless preempt_check_resched()
      just before re-enabling bottom halves.
      Signed-off-by: NSamuel Thibault <samuel.thibault@ens-lyon.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      10f02d1c