1. 06 Apr, 2007 36 commits
  2. 23 Mar, 2007 4 commits
    • Greg Kroah-Hartman's avatar
      Linux 2.6.20.4 · e947fa65
      Greg Kroah-Hartman authored
      e947fa65
    • David Miller's avatar
      Fix niagara memory corruption · 9c062782
      David Miller authored
      [SPARC64]: store-init needs trailing membar.
      
      The manual says that it is required and we actually have crash reports
      where loads see stale data due to not having membars here.
      
      In one case the networking does:
      
      	memset(skb, 0, offsetof(struct sk_buff, truesize));
      
      and then some code later checks skb->nohdr for zero, but it's still
      the value that was there before the memset().
      
      Note that arch/sparc64/lib/xor.S already got this right.
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      9c062782
    • Kai Makisara's avatar
      st: fix Tape dies if wrong block size used, bug 7919 · ad23c76c
      Kai Makisara authored
      [SCSI] st: fix Tape dies if wrong block size used, bug 7919
      
      On Thu, 1 Feb 2007, Andrew Morton wrote:
      > On Thu, 1 Feb 2007 15:34:29 -0800
      > bugme-daemon@bugzilla.kernel.org wrote:
      >
      > > http://bugzilla.kernel.org/show_bug.cgi?id=7919
      > >
      > >            Summary: Tape dies if wrong block size used
      > >     Kernel Version: 2.6.20-rc5
      > >             Status: NEW
      > >           Severity: normal
      > >              Owner: scsi_drivers-other@kernel-bugs.osdl.org
      > >          Submitter: dmartin@sccd.ctc.edu
      > >
      > >
      > > Most recent kernel where this bug did *NOT* occur: 2.6.17.14
      > >
      > > Other Kernels Tested and Results:
      > >
      > >     OK 2.6.15.7
      > >     OK 2.6.16.37
      > >     OK 2.6.17.14
      > >     BAD 2.6.18.6
      > >     BAD 2.6.18-1.2869.fc6
      > >     BAD 2.6.19.2 +
      > >     BAD 2.6.20-rc5
      > >
      > > NOTE: 2.6.18-1.2869.fc6 is a Fedora modified kernel, all others are from kernel.org
      > >
      ...
      > > Steps to reproduce:
      > > Get a Adaptec AHA-2940U/UW/D / AIC-7881U card and a tape drive,
      > > install a recent kernel
      > > set the tape block size - mt setblk 4096
      > > read from or write to tape using wrong block size - tar -b 7 -cvf /dev/tape foo
      > >
      Write does not trigger this bug because the driver refuses in fixed block
      mode writes that are not a multiple of the block size. Read does trigger
      it in my system.
      
      The bug is not associated with any specific HBA. st tries to do direct i/o
      in fixed block mode with reads that are not a multiple of tape block size.
      
      The patch in this message fixes the st problem by switching to using the
      driver buffer up to the next close of the device file in fixed block mode
      if the user asks for a read like this.
      
      I don't know why the bug has surfaced only after 2.6.17 although the st
      problem is old. There may be another bug in the block subsystem and this
      patch works around it. However, the patch fixes a problem in st and in
      this way it is a valid fix.
      
      This patch may also fix the bug 7900.
      
      The patch compiles and is lightly tested.
      Signed-off-by: default avatarKai Makisara <kai.makisara@kolumbus.fi>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarJames Bottomley <James.Bottomley@SteelEye.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      ad23c76c
    • Dmitry Torokhov's avatar
      Input: i8042 - another attempt to fix AUX delivery checks · 0036a32b
      Dmitry Torokhov authored
      Do not assume that AUX_LOOP command is broken unless it
      completes successfully but returns wrong (unexpected) data.
      
      Cc: Chuck Ebbert <cebbert@redhat.com>
      Signed-off-by: default avatarDmitry Torokhov <dtor@mail.ru>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      0036a32b