1. 05 1月, 2006 3 次提交
  2. 22 12月, 2005 1 次提交
    • P
      [PATCH] USB Storage: Force starget->scsi_level in usb-storage scsiglue.c · 28120be5
      Paul Walmsley 提交于
      When the usb-storage module forces sdev->scsi_level to SCSI_2, it should
      also force starget->scsi_level to the same value.  Otherwise, the SCSI
      layer may attempt to issue SCSI-3 commands to the device, such as REPORT
      LUNS, which it cannot handle.  This can prevent the device from working
      with Linux.
      
      The AMS Venus DS3 DS2316SU2S SATA-to-SATA+USB enclosure, based on the
      Oxford Semiconductor OXU921S chip, requires this patch to function
      correctly on Linux.  The enclosure reports a SCSI-3 SPC-2 command set
      level, but does not correctly handle the REPORT LUNS SCSI command -
      probably due to a bug in its firmware.
      
      It seems likely that other USB storage enclosures with similar bugs will
      also benefit from this patch.
      
      Tony Lindgren <tony@atomide.com> collaborated in the development of this
      patch.
      Signed-off-by: NPaul Walmsley <paul@booyaka.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      28120be5
  3. 24 11月, 2005 1 次提交
    • D
      [PATCH] USB: fix USB key generates ioctl_internal_command errors issue · 63dc3ff3
      David Hrdeman 提交于
      On Wed, Nov 16, 2005 at 06:34:24PM -0800, Pete Zaitcev wrote:
      >On Wed, 16 Nov 2005 23:52:32 +0100, David Hrdeman <david@2gen.com> wrote:
      >> usb-storage: waiting for device to settle before scanning
      >>   Vendor: I0MEGA    Model: UMni1GB*IOM2K4    Rev: 1.01
      >>   Type:   Direct-Access                      ANSI SCSI revision: 02
      >> SCSI device sda: 2048000 512-byte hdwr sectors (1049 MB)
      >> sda: Write Protect is off
      >> sda: Mode Sense: 00 00 00 00
      >> sda: assuming drive cache: write through
      >> ioctl_internal_command: <8 0 0 0> return code = 8000002
      >>    : Current: sense key=0x0
      >>     ASC=0x0 ASCQ=0x0
      >> SCSI device sda: 2048000 512-byte hdwr sectors (1049 MB)
      >
      >I think it's harmless. I saw things like that, and initially I plugged
      >them with workarounds like this:
      
      Thanks for the pointer, and yes, it is harmless, but it floods the
      console with the messages which hides other (potentially important)
      messages...following your example I've made a patch which fixes the
      problem.
      Signed-off-by: NDavid Hrdeman <david@2gen.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      63dc3ff3
  4. 18 11月, 2005 4 次提交
  5. 29 10月, 2005 13 次提交
  6. 13 9月, 2005 4 次提交
  7. 09 9月, 2005 9 次提交
  8. 13 7月, 2005 1 次提交
  9. 28 6月, 2005 3 次提交
  10. 26 6月, 2005 1 次提交
    • C
      [PATCH] Cleanup patch for process freezing · 3e1d1d28
      Christoph Lameter 提交于
      1. Establish a simple API for process freezing defined in linux/include/sched.h:
      
         frozen(process)		Check for frozen process
         freezing(process)		Check if a process is being frozen
         freeze(process)		Tell a process to freeze (go to refrigerator)
         thaw_process(process)	Restart process
         frozen_process(process)	Process is frozen now
      
      2. Remove all references to PF_FREEZE and PF_FROZEN from all
         kernel sources except sched.h
      
      3. Fix numerous locations where try_to_freeze is manually done by a driver
      
      4. Remove the argument that is no longer necessary from two function calls.
      
      5. Some whitespace cleanup
      
      6. Clear potential race in refrigerator (provides an open window of PF_FREEZE
         cleared before setting PF_FROZEN, recalc_sigpending does not check
         PF_FROZEN).
      
      This patch does not address the problem of freeze_processes() violating the rule
      that a task may only modify its own flags by setting PF_FREEZE. This is not clean
      in an SMP environment. freeze(process) is therefore not SMP safe!
      Signed-off-by: NChristoph Lameter <christoph@lameter.com>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      3e1d1d28