1. 20 Sep, 2007 7 commits
    • Mark Fasheh's avatar
      ocfs2: Don't double set write parameters · 5c26a7b7
      Mark Fasheh authored
      The target page offsets were being incorrectly set a second time in
      ocfs2_prepare_page_for_write(), which was causing problems on a 16k page
      size kernel. Additionally, ocfs2_write_failure() was incorrectly using those
      parameters instead of the parameters for the individual page being cleaned
      up.
      Signed-off-by: default avatarMark Fasheh <mark.fasheh@oracle.com>
      5c26a7b7
    • Mark Fasheh's avatar
      ocfs2: Fix pos/len passed to ocfs2_write_cluster · db56246c
      Mark Fasheh authored
      This was broken for file systems whose cluster size is greater than page
      size. Pos needs to be incremented as we loop through the descriptors, and
      len needs to be capped to the size of a single cluster.
      Signed-off-by: default avatarMark Fasheh <mark.fasheh@oracle.com>
      db56246c
    • Mark Fasheh's avatar
      ocfs2: Allow smaller allocations during large writes · 415cb800
      Mark Fasheh authored
      The ocfs2 write code loops through a page much like the block code, except
      that ocfs2 allocation units can be any size, including larger than page
      size. Typically it's equal to or larger than page size - most kernels run 4k
      pages, the minimum ocfs2 allocation (cluster) size.
      
      Some changes introduced during 2.6.23 changed the way writes to pages are
      handled, and inadvertantly broke support for > 4k page size. Instead of just
      writing one cluster at a time, we now handle the whole page in one pass.
      
      This means that multiple (small) seperate allocations might happen in the
      same pass. The allocation code howver typically optimizes by getting the
      maximum which was reserved. This triggered a BUG_ON in the extend code where
      it'd ask for a single bit (for one part of a > 4k page) and get back more
      than it asked for.
      
      Fix this by providing a variant of the high level allocation function which
      allows the caller to specify a maximum. The traditional function remains and
      just calls the new one with a maximum determined from the initial
      reservation.
      Signed-off-by: default avatarMark Fasheh <mark.fasheh@oracle.com>
      415cb800
    • Linus Torvalds's avatar
      Fix CRLF line endings in Documentation/input/iforce-protocol.txt · 6d0b842d
      Linus Torvalds authored
      Emil Medve points out that this documentation file uses CRLF line
      endings, which means that if you use
      
      	[core]
      		autocrlf=input
      
      (which makes sense if you ever develop under Windows, for example, or if
      you use other broken tools) in your git config, git will always complain
      about the file being dirty.
      
      This removes the bogus DOS line endings, and removes whitespace at the
      end of line.
      
      Cc: Emil Medve <Emilian.Medve@Freescale.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      6d0b842d
    • Paul Bolle's avatar
      [x86 setup] Fix typo in arch/i386/boot/header.S · bbc15f46
      Paul Bolle authored
      There's an obvious typo in arch/i386/boot/header.S (in your
      linux-2.6-x86setup.git) that I noticed by just studying the code.
      Signed-off-by: default avatarPaul Bolle <pebolle@tiscali.nl>
      Signed-off-by: default avatarH. Peter Anvin <hpa@zytor.com>
      bbc15f46
    • H. Peter Anvin's avatar
      [acpi] Correct the decoding of video mode numbers in wakeup.S · 91c4b8cb
      H. Peter Anvin authored
      wakeup.S looks at the video mode number from the setup header and
      looks to see if it is a VESA mode.  Unfortunately, the decoding is
      done incorrectly and it will attempt to frob the VESA BIOS for any
      mode number 0x0200 or larger.  Correct this, and remove a bunch of #if
      0'd code.
      
      Massive thanks to Jeff Chua for reporting the bug, and suffering
      though a large number of experiments in order to track this problem
      down.
      
      Cc: Pavel Machek <pavel@ucw.cz>
      Signed-off-by: default avatarH. Peter Anvin <hpa@zytor.com>
      91c4b8cb
    • H. Peter Anvin's avatar
      [x86 setup] Present the canonical video mode number to the kernel · 3f662b3f
      H. Peter Anvin authored
      Canonicalize the video mode number as presented to the kernel.  The
      video mode number may be user-entered (e.g. ASK_VGA), an alias
      (e.g. NORMAL_VGA), or a size specification, and that confuses the
      suspend wakeup code.
      Signed-off-by: default avatarH. Peter Anvin <hpa@zytor.com>
      3f662b3f
  2. 19 Sep, 2007 33 commits