15 Dec, 2011

1 commit


31 Aug, 2011

2 commits


27 Jul, 2011

1 commit

  • This allows us to move duplicated code in
    (atomic_inc_not_zero() for now) to

    Signed-off-by: Arun Sharma
    Reviewed-by: Eric Dumazet
    Cc: Ingo Molnar
    Cc: David Miller
    Cc: Eric Dumazet
    Acked-by: Mike Frysinger
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Arun Sharma
     

17 May, 2011

1 commit

  • Commit c21e6beb removed our queue request_fn re-enter
    protection, and defaulted to always running the queues from
    kblockd to be safe. This was a known potential slow down,
    but should be safe.

    Unfortunately this is causing big performance regressions for
    some, so we need to improve this logic. Looking into the details
    of the re-enter, the real issue is on requeue of requests.

    Requeue of requests upon seeing a BUSY condition from the device
    ends up re-running the queue, causing traces like this:

    scsi_request_fn()
    scsi_dispatch_cmd()
    scsi_queue_insert()
    __scsi_queue_insert()
    scsi_run_queue()
    scsi_request_fn()
    ...

    potentially causing the issue we want to avoid. So special
    case the requeue re-run of the queue, but improve it to offload
    the entire run of local queue and starved queue from a single
    workqueue callback. This is a lot better than potentially
    kicking off a workqueue run for each device seen.

    This also fixes the issue of the local device going into recursion,
    since the above mentioned commit never moved that queue run out
    of line.

    Signed-off-by: Jens Axboe

    Jens Axboe
     

24 Mar, 2011

1 commit

  • During device discovery, scsi mid layer sends INQUIRY command to LUN
    0. If the LUN 0 is not mapped to host, it creates a temporary
    scsi_device with LUN id 0 and sends REPORT_LUNS command to it. After
    the REPORT_LUNS succeeds, it walks through the LUN table and adds each
    LUN found to sysfs. At the end of REPORT_LUNS lun table scan, it will
    delete the temporary scsi_device of LUN 0.

    When scsi devices are added to sysfs, it calls add_dev function of all
    the registered class interfaces. If ses driver has been registered,
    ses_intf_add() of ses module will be called. This function calls
    scsi_device_enclosure() to check the inquiry data for EncServ
    bit. Since inquiry was not allocated for temporary LUN 0 scsi_device,
    it will cause NULL pointer exception.

    To fix the problem, sdev->inquiry is checked for NULL before reading it.

    Signed-off-by: Somasundaram Krishnasamy
    Signed-off-by: Babu Moger
    Cc: stable@kernel.org
    Signed-off-by: James Bottomley

    Krishnasamy, Somasundaram
     

25 Jan, 2011

1 commit


23 Oct, 2010

2 commits

  • I seem to have a knack for digging up buggy usb devices which don't work
    with Linux, and I'm crazy enough to try to make them work. So this time a
    friend of mine asked me to get an mp4 player (an mp3 player which can play
    videos on a small screen) to work with Linux.

    It is based on the well known rockbox chipset for which we already have an
    unusual devs entries to work around some of its bugs. But this model
    comes with an additional twist.

    This model chokes on read_capacity_16 calls. Now normally we don't make
    those calls, but this model comes with an sdcard slot and when there is no
    card in there (and shipped from the factory there is none), it reports a
    size of 0. However this time the programmers actually got the
    read_capacity_10 response right! So they substract one from the size as
    stored internally in the mp3 player before reporting it back, resulting in
    an answer of ... 0xffffffff sectors, causing sd.c to try a
    read_capacity_16, on which the device crashes.

    This patch adds a flag to scsi_device to indicate that a a device cannot
    handle read_capacity_16, and when this flag is set if a device reports an
    lba of 0xffffffff as answer to a read_capacity_10, assumes it tries to
    report a size of 0.

    Signed-off-by: Hans de Goede
    Cc: James Bottomley
    Cc: Alan Stern
    Cc: Matthew Dharm
    Signed-off-by: Andrew Morton
    Signed-off-by: Greg Kroah-Hartman

    Hans de Goede
     
  • Some USB devices emulate a usb-mass-storage attached (scsi) cdrom device,
    usually this fake cdrom contains the windows software for the device.
    While working on supporting Appotech ax3003 based photoframes, which do
    this I discovered that they will go of into lala land when ever they see a
    READ_DISC_INFO scsi command.

    Thus this patch adds a scsi_device flag (which can then be set by the
    usb-storage driver through an unsual-devs entry), to indicate this, and
    makes the sr driver honor this flag.

    I know this sucks, but as discussed on linux-scsi list there is no other
    way to make this device work properly.

    Looking at usb traces made under windows, windows never sends a
    READ_DISC_INFO during normal interactions with a usb cdrom device. So as
    this cdrom emulation thingie becomes more common we might see more of this
    problem.

    Signed-off-by: Hans de Goede
    Cc: James Bottomley
    Cc: Alan Stern
    Cc: Matthew Dharm
    Signed-off-by: Andrew Morton
    Signed-off-by: Greg Kroah-Hartman

    Hans de Goede
     

28 Jul, 2010

1 commit

  • This patch (as1398b) adds runtime PM support to the SCSI layer. Only
    the machanism is provided; use of it is up to the various high-level
    drivers, and the patch doesn't change any of them. Except for sg --
    the patch expicitly prevents a device from being runtime-suspended
    while its sg device file is open.

    The implementation is simplistic. In general, hosts and targets are
    automatically suspended when all their children are asleep, but for
    them the runtime-suspend code doesn't actually do anything. (A host's
    runtime PM status is propagated up the device tree, though, so a
    runtime-PM-aware lower-level driver could power down the host adapter
    hardware at the appropriate times.) There are comments indicating
    where a transport class might be notified or some other hooks added.

    LUNs are runtime-suspended by calling the drivers' existing suspend
    handlers (and likewise for runtime-resume). Somewhat arbitrarily, the
    implementation delays for 100 ms before suspending an eligible LUN.
    This is because there typically are occasions during bootup when the
    same device file is opened and closed several times in quick
    succession.

    The way this all works is that the SCSI core increments a device's
    PM-usage count when it is registered. If a high-level driver does
    nothing then the device will not be eligible for runtime-suspend
    because of the elevated usage count. If a high-level driver wants to
    use runtime PM then it can call scsi_autopm_put_device() in its probe
    routine to decrement the usage count and scsi_autopm_get_device() in
    its remove routine to restore the original count.

    Hosts, targets, and LUNs are not suspended while they are being probed
    or removed, or while the error handler is running. In fact, a fairly
    large part of the patch consists of code to make sure that things
    aren't suspended at such times.

    [jejb: fix up compile issues in PM config variations]
    Signed-off-by: Alan Stern
    Signed-off-by: James Bottomley

    Alan Stern
     

19 Jan, 2010

1 commit


10 Dec, 2009

1 commit

  • * git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi-misc-2.6: (222 commits)
    [SCSI] zfcp: Remove flag ZFCP_STATUS_FSFREQ_TMFUNCNOTSUPP
    [SCSI] zfcp: Activate fc4s attributes for zfcp in FC transport class
    [SCSI] zfcp: Block scsi_eh thread for rport state BLOCKED
    [SCSI] zfcp: Update FSF error reporting
    [SCSI] zfcp: Improve ELS ADISC handling
    [SCSI] zfcp: Simplify handling of ct and els requests
    [SCSI] zfcp: Remove ZFCP_DID_MASK
    [SCSI] zfcp: Move WKA port to zfcp FC code
    [SCSI] zfcp: Use common code definitions for FC CT structs
    [SCSI] zfcp: Use common code definitions for FC ELS structs
    [SCSI] zfcp: Update FCP protocol related code
    [SCSI] zfcp: Dont fail SCSI commands when transitioning to blocked fc_rport
    [SCSI] zfcp: Assign scheduled work to driver queue
    [SCSI] zfcp: Remove STATUS_COMMON_REMOVE flag as it is not required anymore
    [SCSI] zfcp: Implement module unloading
    [SCSI] zfcp: Merge trace code for fsf requests in one function
    [SCSI] zfcp: Access ports and units with container_of in sysfs code
    [SCSI] zfcp: Remove suspend callback
    [SCSI] zfcp: Remove global config_mutex
    [SCSI] zfcp: Replace local reference counting with common kref
    ...

    Linus Torvalds
     

05 Dec, 2009

2 commits

  • Make scsi_dh_activate() function asynchronous, by taking in two additional
    parameters, one is the callback function and the other is the data to call
    the callback function with.

    Signed-off-by: Chandra Seetharaman
    Signed-off-by: James Bottomley

    Chandra Seetharaman
     
  • Current FC HBA queue_depth ramp up code depends on last queue
    full time. The sdev already has last_queue_full_time field to
    track last queue full time but stored value is truncated by
    last four bits.

    So this patch updates last_queue_full_time without truncating
    last 4 bits to store full value and then updates its only
    current usages in scsi_track_queue_full to ignore last four bits
    to keep current usages same while also use this field
    in added ramp up code.

    Adds scsi_handle_queue_ramp_up to ramp up queue_depth on
    successful completion of IO. The scsi_handle_queue_ramp_up will
    do ramp up on all luns of a target, just same as ramp down done
    on all luns on a target.

    The ramp up is skipped in case the change_queue_depth is not
    supported by LLD or already reached to added max_queue_depth.

    Updates added max_queue_depth on every new update to default
    queue_depth value.

    The ramp up is also skipped if lapsed time since either last
    queue ramp up or down is less than LLD specified
    queue_ramp_up_period.

    Adds queue_ramp_up_period to sysfs but only if change_queue_depth
    is supported since ramp up and queue_ramp_up_period is needed only
    in case change_queue_depth is supported first.

    Initializes queue_ramp_up_period to 120HZ jiffies as initial
    default value, it is same as used in existing lpfc and qla2xxx.

    -v2
    Combined all ramp code into this single patch.

    -v3
    Moves max_queue_depth initialization after slave_configure is
    called from after slave_alloc calling done. Also adjusted
    max_queue_depth check to skip ramp up if current queue_depth
    is >= max_queue_depth.

    -v4
    Changes sdev->queue_ramp_up_period unit to ms when using sysfs i/f
    to store or show its value.

    Signed-off-by: Vasu Dev
    Tested-by: Christof Schmitt
    Tested-by: Giridhar Malavali
    Signed-off-by: James Bottomley

    Vasu Dev
     

26 Nov, 2009

1 commit

  • Async scanning introduced a very wide window where the SCSI device is
    up and running but has not yet been added to sysfs. We delay the
    adding until all scans have completed to retain the same ordering as
    sync scanning.

    This delay in visibility causes an oops if a device is removed before
    we make it visible because the SCSI removal routines have an inbuilt
    assumption that if a device is in SDEV_RUNNING state, it must be
    visible (which is not necessarily true in the async scanning case).

    Fix this by introducing an additional is_visible flag which we can use
    to condition the tear down so we do the right thing for running but
    not yet made visible.

    Reported-by: Alexey Kuznetsov
    Signed-off-by: James Bottomley

    James Bottomley
     

23 Aug, 2009

2 commits

  • When we moved the device handler functionality from dm layer to SCSI layer
    we dropped the parameter functionality.

    This path adds an interface to scsi dh layer to set device handler
    parameters.

    Basically, multipath layer need to create a string with all the parameters
    and call scsi_dh_set_params() after it called scsi_dh_attach() on a
    device.

    If a device handler provides such an interface it will handle the parameters
    as it expects them.

    Reported-by: Eddie Williams
    Signed-off-by: Chandra Seetharaman
    Tested-by: Eddie Williams
    Signed-off-by: James Bottomley
    Signed-off-by: James Bottomley

    Chandra Seetharaman
     
  • Problem reported: http://marc.info/?l=dm-devel&m=124585978305866&w=2

    scsi_dh does not do a refernce count for attach/detach, and this affects
    the way it is supposed to work with multipath when a device is not
    in the dev_list of the hardware handler.

    This patch adds a reference count that counts each attach.

    Signed-off-by: Chandra Seetharaman
    Signed-off-by: James Bottomley
    Signed-off-by: James Bottomley

    Chandra Seetharaman
     

13 Mar, 2009

3 commits


30 Dec, 2008

2 commits


13 Oct, 2008

1 commit

  • SCSI-ml manages the queueing limits for the device and host, but
    does not do so at the target level. However something something similar
    can come in userful when a driver is transitioning a transport object to
    the the blocked state, becuase at that time we do not want to queue
    io and we do not want the queuecommand to be called again.

    The patch adds code similar to the exisiting SCSI_ML_*BUSY handlers.
    You can now return SCSI_MLQUEUE_TARGET_BUSY when we hit
    a transport level queueing issue like the hw cannot allocate some
    resource at the iscsi session/connection level, or the target has temporarily
    closed or shrunk the queueing window, or if we are transitioning
    to the blocked state.

    bnx2i, when they rework their firmware according to netdev
    developers requests, will also need to be able to limit queueing at this
    level. bnx2i will hook into libiscsi, but will allocate a scsi host per
    netdevice/hba, so unlike pure software iscsi/iser which is allocating
    a host per session, it cannot set the scsi_host->can_queue and return
    SCSI_MLQUEUE_HOST_BUSY to reflect queueing limits on the transport.

    The iscsi class/driver can also set a scsi_target->can_queue value which
    reflects the max commands the driver/class can support. For iscsi this
    reflects the number of commands we can support for each session due to
    session/connection hw limits, driver limits, and to also reflect the
    session/targets's queueing window.

    Changes:
    v1 - initial patch.
    v2 - Fix scsi_run_queue handling of multiple blocked targets.
    Previously we would break from the main loop if a device was added back on
    the starved list. We now run over the list and check if any target is
    blocked.
    v3 - Rediff for scsi-misc.

    Signed-off-by: Mike Christie
    Signed-off-by: James Bottomley

    Mike Christie
     

04 Oct, 2008

2 commits


07 Aug, 2008

1 commit

  • Some USB devices set the protect bit in the INQUIRY data which
    currently causes the DIF code in sd to assume (incorrectly) that they
    support READ_CAPACITY(16). Fix this (only for the time being) by
    making sure we only believe the protect bit in the inquiry data if the
    device claims conformance to SCSI-3 or above.

    Acked-by: Martin K. Petersen
    Signed-off-by: James Bottomley

    Hugh Dickins
     

06 Aug, 2008

1 commit

  • This re-introduces commit 2b142900784c6e38c8d39fa57d5f95ef08e735d8,
    which was reverted due to the regression it caused by commit
    fca082c9f1e11ec07efa8d2f9f13688521253f36.

    That regression was not root-caused by the original commit, it was just
    uncovered by it, and the real fix was done by Alan Stern in commit
    580da34847488b404218d1d7f53b156f245f5555 ("Fix USB storage hang on
    command abort").

    We can thus re-introduce the change that was confirmed by Alan Jenkins
    to be still required by his odd card reader.

    Cc: Alan Jenkins
    Cc: Alan Stern
    Cc: James Bottomley
    Signed-off-by: Linus Torvalds

    Linus Torvalds
     

05 Aug, 2008

1 commit

  • This reverts commit 2b142900784c6e38c8d39fa57d5f95ef08e735d8, since it
    seems to break some other USB storage devices (at least a JMicron USB to
    ATA bridge). As such, while it apparently fixes some cardreaders, it
    would need to be made conditional on the exact reader it fixes in order
    to avoid causing regressions.

    Cc: Alan Jenkins
    Cc: James Bottomley
    Signed-off-by: Linus Torvalds

    Linus Torvalds
     

27 Jul, 2008

3 commits

  • The last_sector_bug flag was added to work around a bug in certain usb
    cardreaders, where they would crash if a multiple sector read included the
    last sector. The original implementation avoids this by e.g. splitting an 8
    sector read which includes the last sector into a 7 sector read, and a single
    sector read for the last sector. The flag is enabled for all USB devices.

    This revealed a second bug in other usb cardreaders, which crash when they
    get a multiple sector read which stops 1 sector short of the last sector.
    Affected hardware includes the Kingston "MobileLite" external USB cardreader
    and the internal USB cardreader on the Asus EeePC.

    Extend the last_sector_bug workaround to ensure that any access which touches
    the last 8 hardware sectors of the device is a single sector long. Requests
    are shrunk as necessary to meet this constraint.

    This gives us a safety margin against potential unknown or future bugs
    affecting multi-sector access to the end of the device. The two known bugs
    only affect the last 2 sectors. However, they suggest that these devices
    are prone to fencepost errors and that multi-sector access to the end of the
    device is not well tested. Popular OS's use multi-sector accesses, but they
    rarely read the last few sectors. Linux (with udev & vol_id) automatically
    reads sectors from the end of the device on insertion. It is assumed that
    single sector accesses are more thoroughly tested during development.

    Signed-off-by: Alan Jenkins
    Tested-by: Alan Jenkins
    Signed-off-by: James Bottomley

    Alan Jenkins
     
  • Implement support for DMA of protection information for devices that
    are data integrity capable.

    - Add support for mapping an extra scatter-gather list containing
    the protection information.

    - Allocate protection scsi_data_buffer if host is DIX (integrity DMA)
    capable.

    - Accessor function for checking whether a device has protection
    enabled.

    Signed-off-by: Martin K. Petersen
    Signed-off-by: James Bottomley

    Martin K. Petersen
     
  • Instead of having each and every driver implement its own
    device table scanning code we should rather implement a common
    routine and scan the device tables there.
    This allows us also to implement a general notifier chain
    callback for all device handler instead for one per handler.

    [sekharan: Fix rejections caused by conflicting bug fix]
    Signed-off-by: Hannes Reinecke
    Signed-off-by: Chandra Seetharaman
    Signed-off-by: James Bottomley

    Hannes Reinecke
     

16 Jul, 2008

1 commit

  • * git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi-misc-2.6: (102 commits)
    [SCSI] scsi_dh: fix kconfig related build errors
    [SCSI] sym53c8xx: Fix bogus sym_que_entry re-implementation of container_of
    [SCSI] scsi_cmnd.h: remove double inclusion of linux/blkdev.h
    [SCSI] make struct scsi_{host,target}_type static
    [SCSI] fix locking in host use of blk_plug_device()
    [SCSI] zfcp: Cleanup external header file
    [SCSI] zfcp: Cleanup code in zfcp_erp.c
    [SCSI] zfcp: zfcp_fsf cleanup.
    [SCSI] zfcp: consolidate sysfs things into one file.
    [SCSI] zfcp: Cleanup of code in zfcp_aux.c
    [SCSI] zfcp: Cleanup of code in zfcp_scsi.c
    [SCSI] zfcp: Move status accessors from zfcp to SCSI include file.
    [SCSI] zfcp: Small QDIO cleanups
    [SCSI] zfcp: Adapter reopen for large number of unsolicited status
    [SCSI] zfcp: Fix error checking for ELS ADISC requests
    [SCSI] zfcp: wait until adapter is finished with ERP during auto-port
    [SCSI] ibmvfc: IBM Power Virtual Fibre Channel Adapter Client Driver
    [SCSI] sg: Add target reset support
    [SCSI] lib: Add support for the T10 (SCSI) Data Integrity Field CRC
    [SCSI] sd: Move scsi_disk() accessor function to sd.h
    ...

    Linus Torvalds
     

14 Jul, 2008

1 commit

  • Adds a new scsi_device flag, start_stop_pwr_cond: If enabled, the sd
    driver will not send plain START STOP UNIT commands but ones with the
    power condition field set to 3 (standby) or 1 (active) respectively.

    Some FireWire disk firmwares do not stop the motor if power condition is
    zero. Or worse, they become unresponsive after a START STOP UNIT with
    power condition = 0 and start = 0.

    http://lkml.org/lkml/2008/4/29/704

    This patch only adds the necessary code to sd_mod but doesn't activate
    it. Follow-up patches to the FireWire drivers will add detection of
    affected devices and enable the code for them.

    I did not add power condition values to scsi_error.c::scsi_eh_try_stu()
    for now. The three firmwares which suffer from above mentioned problems
    do not need START STOP UNIT in the error handler, and they are not
    adversely affected by START STOP UNIT with power condition = 0 and start
    = 1 (like scsi_eh_try_stu() sends it if scsi_device.allow_restart is
    enabled).

    Signed-off-by: Stefan Richter
    Tested-by: Tino Keitel

    Stefan Richter
     

05 Jun, 2008

1 commit

  • Some of the storage devices (that can be accessed through multiple paths),
    do need some special handling for
    1. Activating the passive path of the storage access.
    2. Decode and handle the special sense codes returned by the devices.
    3. Handle the I/Os being sent to the passive path, especially
    during the device probe time.
    when accessed through multiple paths.

    As of today this special device handling is done at the dm-multipath
    layer using dm-handlers. That works well for (1); for (2) to be handled
    at dm layer, scsi sense information need to be exported from SCSI to dm-layer,
    which is not very attractive; (3) cannot be done at all at the dm layer.

    Device handler has been moved to SCSI mainly to handle (2) and (3) properly.

    Signed-off-by: Chandra Seetharaman
    Signed-off-by: Mike Anderson
    Signed-off-by: Mike Christie
    Signed-off-by: James Bottomley

    Chandra Seetharaman
     

23 Apr, 2008

1 commit

  • The current target allocation code registeres each possible target
    with sysfs; it will be deleted again if no useable LUN on this target
    was found. This results in a string of 'target add/target remove' uevents.

    Based on a patch by Hannes Reinecke this patch reworks
    the target allocation code so that only uevents for existing targets
    are sent. The sysfs registration is split off from the existing
    scsi_target_alloc() into a in a new scsi_add_target() function, which
    should be called whenever an existing target is found. Only then a
    uevent is sent, so we'll be generating events for existing targets
    only.

    Signed-off-by: James Bottomley

    James Bottomley
     

20 Apr, 2008

1 commit


24 Jan, 2008

2 commits


12 Jan, 2008

2 commits

  • The current scsi_test_unit_ready() is updated to return sense code
    information (in struct scsi_sense_hdr). The sd and sr drivers are
    changed to interpret the sense code return asc 0x3a as no media and
    adjust the device status accordingly.

    Signed-off-by: James Bottomley

    James Bottomley
     
  • Some SCSI tape medium changers that need the BLIST_SINGLELUN flag have
    the medium changer at one LUN and the tape drive at a different LUN.
    The inquiry string of the tape drive may be different from that of the
    medium changer. In order for single_lun to be effective, every
    scsi_device under a given scsi_target must have it set. This means that
    there needs to be a blacklist entry for BOTH the medium changer AND the
    tape drive, which is impractical because some medium changers may be
    paired with a variety of different tape drive models. It makes more
    sense to put the single_lun flag in scsi_target instead of scsi_device,
    which causes every device at a given target ID to inherit the single_lun
    flag from one LUN. This makes it possible to blacklist just the medium
    changer and not the tape drive.

    Signed-off-by: Tony Battersby
    Signed-off-by: James Bottomley

    Tony Battersby