| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
This patch fixes scenario where driver removal should be possible
only when driver is in READY state. Also it removes redundant
invocation of routine disabling SCU interrupts - this method is
called somewhere else in driver deinitialization path.
Signed-off-by: Andrzej Jakowski <[email protected]>
Signed-off-by: Dan Williams <[email protected]>
Signed-off-by: James Bottomley <[email protected]>
|
|
isci occasionally spews messages like:
isci 0000:03:00.0: sci_phy_event_handler: PHY starting substate machine received unexpected event_code b3940000
...which is not very helpful, since we don't know which controller,
which phy, the exact state, or a decode of the event.
Signed-off-by: Dan Williams <[email protected]>
Signed-off-by: James Bottomley <[email protected]>
|
|
Debugging the driver requires tracing the state transtions and tracing
state names is less work than decoding numbers.
Signed-off-by: Dan Williams <[email protected]>
Signed-off-by: James Bottomley <[email protected]>
|
|
If userspace requests a phy reset, treat that as a request for the phy
to be enabled since that is the effect on hardware.
Signed-off-by: Dan Williams <[email protected]>
Signed-off-by: James Bottomley <[email protected]>
|
|
If userspace has decided to disable a phy the kernel should honor that
and not inadvertantly re-enable the phy via error recovery. This is
more straightforward in the sata case where link recovery (via
libata-eh) is separate from sas_task cancelling in libsas-eh. Teach
libsas to accept -ENODEV as a successful response from I_T_nexus_reset
('successful' in terms of not escalating further).
This is a more comprehensive fix then "libsas: don't recover 'gone'
devices in sas_ata_hard_reset()", as it is no longer sata-specific.
aic94xx does check the return value from sas_phy_reset() so if the phy
is disabled we proceed with clearing the I_T_nexus.
Signed-off-by: Dan Williams <[email protected]>
Signed-off-by: James Bottomley <[email protected]>
|
|
If discovery returns 0 for target_port_protocols but shows an attached
sata device, just report SAS_PROTOCOL_SATA in the identify data so
userspace can reliably search for sata devices in the domain.
Signed-off-by: Dan Williams <[email protected]>
Signed-off-by: James Bottomley <[email protected]>
|
|
Before:
$ cat /sys/class/sas_phy/phy-6\:3/device_type
none
$ cat /sys/class/sas_phy/phy-6\:3/target_port_protocols
none
After:
$ cat /sys/class/sas_phy/phy-6\:3/device_type
end device
$ cat /sys/class/sas_phy/phy-6\:3/target_port_protocols
sata
Also downgrade the phy_list_lock to _irq instead of _irqsave since
libsas will never call sas_get_port_device with interrupts disbled.
Signed-off-by: Dan Williams <[email protected]>
Signed-off-by: James Bottomley <[email protected]>
|
|
libata issues follow up srsts when the controller has a hard time
recording the signature-fis after a reset, or if the link supports port
multipliers. libsas does not support port multipliers and no current
libsas lldds appear to need help retrieving the signature fis. Revert
it for now to remove confusion.
Signed-off-by: Dan Williams <[email protected]>
Signed-off-by: James Bottomley <[email protected]>
|
|
Until all sas_tasks are known to no longer be in-flight this flag gates late
completions from colliding with error handling. However, it must be cleared
prior to the submission of scsi_send_eh_cmnd() requests, otherwise those
commands will never be completed correctly.
This was spotted by slub debug:
=============================================================================
BUG sas_task: Objects remaining on kmem_cache_close()
-----------------------------------------------------------------------------
INFO: Slab 0xffffea001f0eba00 objects=34 used=1 fp=0xffff8807c3aecb00 flags=0x8000000000004080
Pid: 22919, comm: modprobe Not tainted 3.2.0-isci+ #2
Call Trace:
[<ffffffff810fcdcd>] slab_err+0xb0/0xd2
[<ffffffff810e1c50>] ? free_percpu+0x31/0x117
[<ffffffff81100122>] ? kzalloc+0x14/0x16
[<ffffffff81100122>] ? kzalloc+0x14/0x16
[<ffffffff81100486>] kmem_cache_destroy+0x11d/0x270
[<ffffffffa0112bdc>] sas_class_exit+0x10/0x12 [libsas]
[<ffffffff81078fba>] sys_delete_module+0x1c4/0x23c
[<ffffffff814797ba>] ? sysret_check+0x2e/0x69
[<ffffffff8126479e>] ? trace_hardirqs_on_thunk+0x3a/0x3f
[<ffffffff81479782>] system_call_fastpath+0x16/0x1b
INFO: Object 0xffff8807c3aed280 @offset=21120
INFO: Allocated in sas_alloc_task+0x22/0x90 [libsas] age=4615311 cpu=2 pid=12966
__slab_alloc.clone.3+0x1d1/0x234
kmem_cache_alloc+0x52/0x10d
sas_alloc_task+0x22/0x90 [libsas]
sas_queuecommand+0x20e/0x230 [libsas]
scsi_send_eh_cmnd+0xd1/0x30c
scsi_eh_try_stu+0x4f/0x6b
scsi_eh_ready_devs+0xba/0x6ef
sas_scsi_recover_host+0xa35/0xab1 [libsas]
scsi_error_handler+0x14b/0x5fa
kthread+0x9d/0xa5
kernel_thread_helper+0x4/0x10
Signed-off-by: Dan Williams <[email protected]>
Signed-off-by: James Bottomley <[email protected]>
|
|
libsas ata error handling is already async but this does not help the
scan case. Move initial link recovery out from under host->scan_mutex,
and delay synchronization with eh until after all port probe/recovery
work has been queued.
Device ordering is maintained with scan order by still calling
sas_rphy_add() in order of domain discovery.
Since we now scan the domain list when invoking libata-eh we need to be
careful to check for fully initialized ata ports.
Acked-by: Jack Wang <[email protected]>
Acked-by: Jeff Garzik <[email protected]>
Signed-off-by: Dan Williams <[email protected]>
Signed-off-by: James Bottomley <[email protected]>
|
|
ata devices are always scanned after ssp. Prior to the ata error
handling reworks libsas would tend to scan devices in ascending expander
phy order. Restore this ordering by deferring ssp discovery to a
DISCE_PROBE event, and keep the probe order consistent with the
discovery order, not the placement of sata devices.
Signed-off-by: Dan Williams <[email protected]>
Signed-off-by: James Bottomley <[email protected]>
|
|
If the phy is attached to a new sas address unregister the first address
before processing the new attachment.
Signed-off-by: Dan Williams <[email protected]>
Signed-off-by: James Bottomley <[email protected]>
|
|
libsas fails to discover all sata devices in the domain. If a device fails
negotiation and does not transmit a signature fis the link needs recovery.
libata already understands how to manage slow to come up links, so treat these
conditions as ata device attach events for the purposes of creating an
ata_port. This allows libata to manage retrying link bring up.
Rediscovery is modified to be careful about checking changes in dev_type. It
looks like libsas leaks old devices if the sas address changes, but that's a
fix for another patch.
Acked-by: Jack Wang <[email protected]>
Signed-off-by: Dan Williams <[email protected]>
Signed-off-by: James Bottomley <[email protected]>
|
|
Make sas-port naming consistent with the expander-attached case whereby
the phy-id is the last digit in the port name. Otherwise we get the
random behavior of the allocation order.
Reported-by: Patrick Thomson <[email protected]>
Signed-off-by: Dan Williams <[email protected]>
Signed-off-by: James Bottomley <[email protected]>
|
|
It's difficult to determine which domain_device is triggering error recovery,
so convert messages like:
sas: ex 5001b4da000e703f phy08:T attached: 5001b4da000e7028
sas: ex 5001b4da000e703f phy09:T attached: 5001b4da000e7029
...
ata7: sas eh calling libata port error handler
ata8: sas eh calling libata port error handler
...into:
sas: ex 5001517e85cfefff phy05:T:9 attached: 5001517e85cfefe5 (stp)
sas: ex 5001517e3b0af0bf phy11:T:8 attached: 5001517e3b0af0ab (stp)
...
sas: ata7: end_device-21:1: dev error handler
sas: ata8: end_device-20:0:5: dev error handler
which shows attached link rate, device type, and associates a
domain_device with its ata_port id to correlate messages emitted from
libata-eh.
As Doug notes, we can also take the opportunity to clarify expander phy
routing capabilities.
[[email protected]: clarify table2table with 'U']
Signed-off-by: Dan Williams <[email protected]>
Signed-off-by: James Bottomley <[email protected]>
|
|
Holdover from a patch rework, prior to the addition of SAS_DEV_DESTROY
we were holding a reference while the destruct was pending in case the
domain was torn down before the desctruct event ran. That case is
covered by SAS_DEV_DESTROY, and the sas_put_device() just corrupts freed
memory, or worse frees the memory while another agent holds a reference.
Signed-off-by: Maciej Trela <[email protected]>
Signed-off-by: Dan Williams <[email protected]>
Signed-off-by: James Bottomley <[email protected]>
|
|
We need to hold drain_mutex across the unregistration as port down events
queue device removal as chained events, so we need to make sure no other
drainers are active.
[ 1118.673968] WARNING: at kernel/workqueue.c:996 __queue_work+0x11a/0x326()
[ 1118.681982] Hardware name: S2600CP
[ 1118.686193] Modules linked in: isci(-) libsas scsi_transport_sas nls_utf8
ipv6 uinput sg iTCO_wdt iTCO_vendor_support i2c_i801 i2c_core ioatdma dca
sd_mod sr_mod cdrom ahci libahci libata [last unloaded: scsi_transport_sas]
[ 1118.709893] Pid: 6831, comm: rmmod Not tainted 3.2.0-isci+ #1
[ 1118.716727] Call Trace:
[ 1118.719867] [<ffffffff8103e9f5>] warn_slowpath_common+0x85/0x9d
[ 1118.727000] [<ffffffff8103ea27>] warn_slowpath_null+0x1a/0x1c
[ 1118.733942] [<ffffffff81056d44>] __queue_work+0x11a/0x326
[ 1118.740481] [<ffffffff81056f99>] queue_work_on+0x1b/0x22
[ 1118.746925] [<ffffffff81057106>] queue_work+0x37/0x3e
[ 1118.753105] [<ffffffffa0120e05>] ? sas_discover_event+0x55/0x82 [libsas]
[ 1118.761094] [<ffffffff813217c3>] scsi_queue_work+0x42/0x44
[ 1118.767717] [<ffffffffa0120e19>] sas_discover_event+0x69/0x82 [libsas]
[ 1118.775509] [<ffffffffa0120f5b>] sas_unregister_dev+0xc3/0xcc [libsas]
[ 1118.783319] [<ffffffffa0120fae>] sas_unregister_domain_devices+0x4a/0xc8 [libsas]
[ 1118.792731] [<ffffffffa0120071>] sas_deform_port+0x60/0x1a6 [libsas]
[ 1118.800339] [<ffffffffa01201ea>] sas_unregister_ports+0x33/0x44 [libsas]
[ 1118.808342] [<ffffffffa011f7e5>] sas_unregister_ha+0x41/0x6b [libsas]
[ 1118.816055] [<ffffffffa0134055>] isci_unregister+0x22/0x4d [isci]
[ 1118.823384] [<ffffffffa0143040>] isci_pci_remove+0x2e/0x60 [isci]
Reported-by: Jacek Danecki <[email protected]>
Signed-off-by: Dan Williams <[email protected]>
Signed-off-by: James Bottomley <[email protected]>
|
|
Similar to the conversion of the transport-class reset we want bsg
initiated resets to be managed by libata.
Reported-by: Jacek Danecki <[email protected]>
Signed-off-by: Dan Williams <[email protected]>
Signed-off-by: James Bottomley <[email protected]>
|
|
If we have a domain with sas and sata devices there may still be sas
recovery actions to take after peeling off the commands to send to
libata.
Reported-by: Andrzej Jakowski <[email protected]>
Signed-off-by: Dan Williams <[email protected]>
Signed-off-by: James Bottomley <[email protected]>
|
|
ata_port lifetime in libata follows the host. In libsas it follows the
scsi_target. Once scsi_remove_device() has caused all commands to be
completed it allows scsi_remove_target() to immediately proceed to
freeing the ata_port causing bug reports like:
[ 848.393333] BUG: spinlock bad magic on CPU#4, kworker/u:2/5107
[ 848.400262] general protection fault: 0000 [#1] SMP
[ 848.406244] CPU 4
[ 848.408310] Modules linked in: nls_utf8 ipv6 uinput i2c_i801 i2c_core iTCO_wdt iTCO_vendor_support ioatdma dca sg sd_mod sr_mod cdrom ahci libahci isci libsas libata scsi_transport_sas [last unloaded: scsi_wait_scan]
[ 848.432060]
[ 848.434137] Pid: 5107, comm: kworker/u:2 Not tainted 3.2.0-isci+ #8 Intel Corporation S2600CP/S2600CP
[ 848.445310] RIP: 0010:[<ffffffff8126a68c>] [<ffffffff8126a68c>] spin_dump+0x5e/0x8c
[ 848.454787] RSP: 0018:ffff8807f868dca0 EFLAGS: 00010002
[ 848.461137] RAX: 0000000000000048 RBX: ffff8807fe86a630 RCX: ffffffff817d0be0
[ 848.469520] RDX: 0000000000000000 RSI: ffffffff814af1cf RDI: 0000000000000002
[ 848.477959] RBP: ffff8807f868dcb0 R08: 00000000ffffffff R09: 000000006b6b6b6b
[ 848.486327] R10: 000000000003fb8c R11: ffffffff81a19448 R12: 6b6b6b6b6b6b6b6b
[ 848.494699] R13: ffff8808027dc520 R14: 0000000000000000 R15: 000000000000001e
[ 848.503067] FS: 0000000000000000(0000) GS:ffff88083fd00000(0000) knlGS:0000000000000000
[ 848.512899] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
[ 848.519710] CR2: 00007ff77d001000 CR3: 00000007f7a5d000 CR4: 00000000000406e0
[ 848.528072] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 848.536446] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[ 848.544831] Process kworker/u:2 (pid: 5107, threadinfo ffff8807f868c000, task ffff8807ff348000)
[ 848.555327] Stack:
[ 848.557959] ffff8807fe86a630 ffff8807fe86a630 ffff8807f868dcd0 ffffffff8126a6e0
[ 848.567072] ffffffff817c142f ffff8807fe86a630 ffff8807f868dcf0 ffffffff8126a703
[ 848.576190] ffff8808027dc520 0000000000000286 ffff8807f868dd10 ffffffff814af1bb
[ 848.585281] Call Trace:
[ 848.588409] [<ffffffff8126a6e0>] spin_bug+0x26/0x28
[ 848.594357] [<ffffffff8126a703>] do_raw_spin_unlock+0x21/0x88
[ 848.601283] [<ffffffff814af1bb>] _raw_spin_unlock_irqrestore+0x2c/0x65
[ 848.609089] [<ffffffffa001c103>] ata_scsi_port_error_handler+0x548/0x557 [libata]
[ 848.618331] [<ffffffff81061813>] ? async_schedule+0x17/0x17
[ 848.625060] [<ffffffffa004f30f>] async_sas_ata_eh+0x45/0x69 [libsas]
[ 848.632655] [<ffffffff810618aa>] async_run_entry_fn+0x97/0x125
[ 848.639670] [<ffffffff81057439>] process_one_work+0x207/0x38d
[ 848.646577] [<ffffffff8105738c>] ? process_one_work+0x15a/0x38d
[ 848.653681] [<ffffffff810576f7>] worker_thread+0x138/0x21c
[ 848.660305] [<ffffffff810575bf>] ? process_one_work+0x38d/0x38d
[ 848.667493] [<ffffffff8105b098>] kthread+0x9d/0xa5
[ 848.673382] [<ffffffff8106e1bd>] ? trace_hardirqs_on_caller+0x12f/0x166
[ 848.681304] [<ffffffff814b7704>] kernel_thread_helper+0x4/0x10
[ 848.688324] [<ffffffff814af534>] ? retint_restore_args+0x13/0x13
[ 848.695530] [<ffffffff8105affb>] ? __init_kthread_worker+0x5b/0x5b
[ 848.702929] [<ffffffff814b7700>] ? gs_change+0x13/0x13
[ 848.709155] Code: 00 00 48 8d 88 38 04 00 00 44 8b 80 84 02 00 00 31 c0 e8 cf 1b 24 00 41 83 c8 ff 44 8b 4b 08 48 c7 c1 e0 0b 7d 81 4d 85 e4 74 10 <45> 8b 84 24 84 02 00 00 49 8d 8c 24 38 04 00 00 8b 53 04 48 89
[ 848.732467] RIP [<ffffffff8126a68c>] spin_dump+0x5e/0x8c
[ 848.738905] RSP <ffff8807f868dca0>
[ 848.743743] ---[ end trace 143161646eee8caa ]---
...so arrange for the ata_port to have the same end of life as the domain
device.
Reported-by: Marcin Tomczak <[email protected]>
Acked-by: Jeff Garzik <[email protected]>
Signed-off-by: Dan Williams <[email protected]>
Signed-off-by: James Bottomley <[email protected]>
|
|
If the top level expander is hot removed, mark all child devices as gone
before unregistration to short circuit futile recovery.
Signed-off-by: Dan Williams <[email protected]>
Signed-off-by: James Bottomley <[email protected]>
|
|
When scrolling forward through the eh list (in a clear_q scenario) it is
possible to encounter commands that won the completion vs eh race. Rather
than sprinkle more "if (!task)" throughout the handler just make a pass
through the list and delete the race winners before handling the rest.
Signed-off-by: Dan Williams <[email protected]>
Signed-off-by: James Bottomley <[email protected]>
|
|
Prior to commit 61aaff49 "isci: filter broadcast change notifications
during SMP phy resets" we borrowed the MVS_DEV_EH approach from the
mvsas driver for preventing ->lldd_I_T_nexus_reset() events during ata
discovery. This hack was protecting against the old ->phy_reset() in
ata_bus_probe(), but since the conversion to the new error handling this
hack is preventing resets from reaching ata devices.
Signed-off-by: Dan Williams <[email protected]>
Signed-off-by: James Bottomley <[email protected]>
|
|
Remove ->eh_device_reset_handler() and ->eh_bus_reset_handler() for the
same reason they are not implemented for libata hosts, they cannot be
implemented reliably with ata-eh. ATA error recovery wants to divert
all resets to the eh thread and wait for completion, these handlers may
be invoked from a non-blocking ioctl.
The other path they are called from is libsas-eh, and if we escalate
past I_T_nexus reset we have larger problems i.e. tear down all
in-flight commands in the domain potentially without notification to the
lldd if it has chosen not to implement ->lldd_clear_nexus_port() /
->lldd_clear_nexus_ha().
Signed-off-by: Dan Williams <[email protected]>
Signed-off-by: James Bottomley <[email protected]>
|
|
Report to libata whether the link to the given domain_device is up and the
signature fis has been received.
Signed-off-by: Dan Williams <[email protected]>
Signed-off-by: James Bottomley <[email protected]>
|
|
Driving resets from libsas-eh is pre-mature as libata will make a
decision about performing a softreset. Currently libata determines
whether to perform a softreset based on ata_eh_followup_srst_needed(),
and none of those conditions apply to isci.
Remove the srst implementation and translate ->lldd_lu_reset() for ata
devices as a request to drive a reset via libata-eh.
Signed-off-by: Dan Williams <[email protected]>
Signed-off-by: James Bottomley <[email protected]>
|
|
A hard reset to isci in the direct-attached case is one where the driver
internally manages debouncing the link. In the sas-expander-attached
case a hard reset is one that clears affiliations. The driver should
not be prematurely dropping affiliations at run time, that decision (to
force expander hard resets to ata devices) is left to userspace to
manage. So, arrange for I_T_nexus resets to be sas-link-resets in the
expander-attached case and isci-hard-resets in the direct-attached case.
Signed-off-by: Dan Williams <[email protected]>
Signed-off-by: James Bottomley <[email protected]>
|
|
It only tracks whether the port is stopping in order to gate new devices
being discovered while the port is stopping. However, since the check
and subsequent handling is unlocked there is nothing to stop the port
from going down immediately after the check.
Driver is already prepared to handle devices arriving on stale ports,
and those will be cleaned up by an eventual ->lldd_dev_gone()
notification.
Signed-off-by: Dan Williams <[email protected]>
Signed-off-by: James Bottomley <[email protected]>
|
|
This field is a holdover from the OS abstraction conversion. The stable
phy to port lookups are done via iphy->ownining_port under scic_lock.
After this conversion to use port->lldd_port the only volatile lookup is
the initial lookup in isci_port_formed(). After that point any lookup
via a successfully notified domain_device is guaranteed to be valid
until the domain_device is destroyed.
Delete ->start_complete as it is only set once and is set as a
consequence of the port going link up, by definition of getting a port
formed event the port is "ready".
While we are correcting port lookups also move the asd_sas_port table
out from under the isci_port. This is to preclude any temptation to use
container_of() to convert an asd_sas_port to an isci_port, the
association is dynamic and under libsas control.
Tested-by: Maciej Trela <[email protected]>
[[email protected]: fix i686 compile error]
Signed-off-by: Dan Williams <[email protected]>
Signed-off-by: James Bottomley <[email protected]>
|
|
The commands that timeout when a disk is forcibly removed may trigger
libata to attempt recovery of the device. If libsas has decided to
remove the device don't permit ata to continue to issue resets to its
last known phy.
The primary motivation for this patch is hotplug testing by writing 0 to
/sys/class/sas_phy/phyX/enable. Without this check this test leads to
libata issuing a reset and re-enabling the device that wants to be torn
down.
Signed-off-by: Dan Williams <[email protected]>
Signed-off-by: James Bottomley <[email protected]>
|
|
In the direct-attached case this routine returns the phy on which this
device was first discovered. Which is broken if we want to support
wide-targets, as this phy reference can become stale even though the
port is still active.
In the expander-attached case this routine tries to lookup the phy by
scanning the attached sas addresses of the parent expander, and BUG_ONs
if it can't find it. However since eh and the libsas workqueue run
independently we can still be attempting device recovery via eh after
libsas has recorded the device as detached. This is even easier to hit
now that eh is blocked while device domain rediscovery takes place, and
that libata is fed more timed out commands increasing the chances that
it will try to recover the ata device.
Arrange for dev->phy to always point to a last known good phy, it may be
stale after the port is torn down, but it will catch up for wide port
reconfigurations, and never be NULL.
Signed-off-by: Dan Williams <[email protected]>
Signed-off-by: James Bottomley <[email protected]>
|
|
No sense in issuing or retrying commands to an expander that has been
removed.
Signed-off-by: Dan Williams <[email protected]>
Signed-off-by: James Bottomley <[email protected]>
|
|
Commit 56dd2c06 "[SCSI] libsas: Don't issue commands to devices that
have been hot-removed" marked the parent device of an end-device as gone
when all the phys to the end device have been deleted.
The expander device is still present until its parent is removed. This
is a benign change until the smp_execute_task() path is taught to check
->gone.
Signed-off-by: Dan Williams <[email protected]>
Signed-off-by: James Bottomley <[email protected]>
|
|
Use ata_wait_after_reset() to poll for link recovery after a reset.
This combined with sas_ha->eh_mutex prevents expander rediscovery from
probing phys in an intermediate state. Local discovery does not have a
mechanism to filter link status changes during this timeout, so it
remains the responsibility of lldds to prevent premature port teardown.
Although once all lldd's support ->lldd_ata_check_ready() that could be
used as a gate to local port teardown.
The signature fis is re-transmitted when the link comes back so we
should be revalidating the ata device class, but that is left to a future
patch.
Signed-off-by: Dan Williams <[email protected]>
Signed-off-by: James Bottomley <[email protected]>
|
|
Signed-off-by: Petr Uzel <[email protected]>
Acked-by: Vikas Chaudhary <[email protected]>
Signed-off-by: Jiri Kosina <[email protected]>
|
|
The old pci_remove_bus_device actually did stop and remove.
Make the name reflect that to reduce confusion.
This patch is done by sed scripts and changes back some incorrect
__pci_remove_bus_device changes.
Suggested-by: Jesse Barnes <[email protected]>
Signed-off-by: Yinghai Lu <[email protected]>
Signed-off-by: Jesse Barnes <[email protected]>
|
|
Conflicts:
drivers/net/ethernet/sfc/rx.c
Overlapping changes in drivers/net/ethernet/sfc/rx.c, one to change
the rx_buf->is_page boolean into a set of u16 flags, and another to
adjust how ->ip_summed is initialized.
Signed-off-by: David S. Miller <[email protected]>
|
|
This allows us to use scsilun_to_int without an ugly cast.
Fix up places that use scsilun_to_int on fcp->fc_lun accordingly.
In fc target, this leaves ft_cmd.lun unused, so remove it.
Signed-off-by: Andy Grover <[email protected]>
Cc: Christoph Hellwig <[email protected]>
Cc: Kiran Patil <[email protected]>
Cc: James Bottomley <[email protected]>
Signed-off-by: Nicholas Bellinger <[email protected]>
|
|
It used to be that minors where 8 bit. But now they
are actually 20 bit. So the fix is simplicity itself.
I've tested with 300 devices and all user-mode utils
work just fine. I have also mechanically added 10,000
to the ida (so devices are /dev/osd10000, /dev/osd10001 ...)
and was able to mkfs an exofs filesystem and access osds
from user-mode.
All the open-osd user-mode code uses the same library
to access devices through their symbolic names in
/dev/osdX so I'd say it's pretty safe. (Well tested)
This patch is very important because some of the systems
that will be deploying the 3.2 pnfs-objects code are larger
than 64 OSDs and will stop to work properly when reaching
that number.
CC: Stable <[email protected]>
Signed-off-by: Boaz Harrosh <[email protected]>
Signed-off-by: James Bottomley <[email protected]>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi-rc-fixes-2.6
SCSI fixes on 20120224:
"This is a set of assorted bug fixes for power management, mpt2sas,
ipr, the rdac device handler and quite a big chunk for qla2xxx (plus a
use after free of scsi_host in scsi_scan.c). "
* tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi-rc-fixes-2.6:
[SCSI] scsi_dh_rdac: Fix for unbalanced reference count
[SCSI] scsi_pm: Fix bug in the SCSI power management handler
[SCSI] scsi_scan: Fix 'Poison overwritten' warning caused by using freed 'shost'
[SCSI] qla2xxx: Update version number to 8.03.07.13-k.
[SCSI] qla2xxx: Proper detection of firmware abort error code for ISP82xx.
[SCSI] qla2xxx: Remove resetting memory during device initialization for ISP82xx.
[SCSI] qla2xxx: Complete mailbox command timedout to avoid initialization failures during next reset cycle.
[SCSI] qla2xxx: Remove check for null fcport from host reset handler.
[SCSI] qla2xxx: Correct out of bounds read of ISP2200 mailbox registers.
[SCSI] qla2xxx: Remove errant clearing of MBX_INTERRUPT flag during CT-IOCB processing.
[SCSI] qla2xxx: Clear options-flags while issuing stop-firmware mbx command.
[SCSI] qla2xxx: Add an "is reset active" helper.
[SCSI] qla2xxx: Add check for null fcport references in qla2xxx_queuecommand.
[SCSI] qla2xxx: Propagate up abort failures.
[SCSI] isci: Fix NULL ptr dereference when no firmware is being loaded
[SCSI] ipr: fix eeh recovery for 64-bit adapters
[SCSI] mpt2sas: Fix mismatch in mpt2sas_base_hard_reset_handler() mutex lock-unlock
|
|
This is to pull in the xhci changes and the other fixes and device id
updates that were done in Linus's tree.
Signed-off-by: Greg Kroah-Hartman <[email protected]>
|
|
This patch fixes an unbalanced refcount issue.
Elevating the lock for both kref_put and also for controller node deletion.
Previously, controller deletion was protected but the not the kref_put. This
was causing the other thread to pick up the controller structure which was
already kref'd zero.
This was causing the following WARN_ON and also sometimes panic.
WARNING: at lib/kref.c:43 kref_get+0x2d/0x30() (Not tainted)
Hardware name: IBM System x3655 -[7985AC1]-
Modules linked in: fuse scsi_dh_rdac autofs4 nfs lockd fscache nfs_acl
auth_rpcgss sunrpc 8021q garp stp llc ipv6 ib_srp(U) scsi_transport_srp
scsi_tgt ib_cm(U) ib_sa(U) ib_uverbs(U) ib_umad(U) mlx4_ib(U) mlx4_core(U)
ib_mthca(U) ib_mad(U) ib_core(U) dm_mirror dm_region_hash dm_log dm_round_robin
dm_multipath uinput bnx2 ses enclosure sg ibmpex ibmaem ipmi_msghandler
serio_raw k8temp hwmon amd64_edac_mod edac_core edac_mce_amd shpchp i2c_piix4
ext4 mbcache jbd2 sr_mod cdrom sd_mod crc_t10dif sata_svw pata_acpi ata_generic
pata_serverworks aacraid radeon ttm drm_kms_helper drm i2c_algo_bit i2c_core
dm_mod [last unloaded: freq_table]
Pid: 13735, comm: srp_daemon Not tainted 2.6.32-71.el6.x86_64 #1
Call Trace:
[<ffffffff8106b857>] warn_slowpath_common+0x87/0xc0
[<ffffffff8106b8aa>] warn_slowpath_null+0x1a/0x20
[<ffffffff8125c39d>] kref_get+0x2d/0x30
[<ffffffffa01b4029>] rdac_bus_attach+0x459/0x580 [scsi_dh_rdac]
[<ffffffff8135232a>] scsi_dh_handler_attach+0x2a/0x80
[<ffffffff81352c7b>] scsi_dh_notifier+0x9b/0xa0
[<ffffffff814cd7a5>] notifier_call_chain+0x55/0x80
[<ffffffff8109711a>] __blocking_notifier_call_chain+0x5a/0x80
[<ffffffff81097156>] blocking_notifier_call_chain+0x16/0x20
[<ffffffff8132bec5>] device_add+0x515/0x640
[<ffffffff813329e4>] ? attribute_container_device_trigger+0xc4/0xe0
[<ffffffff8134f659>] scsi_sysfs_add_sdev+0x89/0x2c0
[<ffffffff8134d096>] scsi_probe_and_add_lun+0xea6/0xed0
[<ffffffff8134beb2>] ? scsi_alloc_target+0x292/0x2d0
[<ffffffff8134d1e1>] __scsi_scan_target+0x121/0x750
[<ffffffff811df806>] ? sysfs_create_file+0x26/0x30
[<ffffffff8132b759>] ? device_create_file+0x19/0x20
[<ffffffff81332838>] ? attribute_container_add_attrs+0x78/0x90
[<ffffffff814b008c>] ? klist_next+0x4c/0xf0
[<ffffffff81332e30>] ? transport_configure+0x0/0x20
[<ffffffff813329e4>] ? attribute_container_device_trigger+0xc4/0xe0
[<ffffffff8134df40>] scsi_scan_target+0xd0/0xe0
[<ffffffffa02f053a>] srp_create_target+0x75a/0x890 [ib_srp]
[<ffffffff8132a130>] dev_attr_store+0x20/0x30
[<ffffffff811df145>] sysfs_write_file+0xe5/0x170
[<ffffffff8116c818>] vfs_write+0xb8/0x1a0
[<ffffffff810d40a2>] ? audit_syscall_entry+0x272/0x2a0
[<ffffffff8116d251>] sys_write+0x51/0x90
[<ffffffff81013172>] system_call_fastpath+0x16/0x1b
Signed-off-by: Babu Moger <[email protected]>
Acked-by: Mike Snitzer <[email protected]>
Signed-off-by: James Bottomley <[email protected]>
|
|
This provides unified readq()/writeq() helper functions for 32-bit
drivers.
For some cases, readq/writeq without atomicity is harmful, and order of
io access has to be specified explicitly. So in this patch, new two
header files which contain non-atomic readq/writeq are added.
- <asm-generic/io-64-nonatomic-lo-hi.h> provides non-atomic readq/
writeq with the order of lower address -> higher address
- <asm-generic/io-64-nonatomic-hi-lo.h> provides non-atomic readq/
writeq with reversed order
This allows us to remove some readq()s that were added drivers when the
default non-atomic ones were removed in commit dbee8a0affd5 ("x86:
remove 32-bit versions of readq()/writeq()")
The drivers which need readq/writeq but can do with the non-atomic ones
must add the line:
#include <asm-generic/io-64-nonatomic-lo-hi.h> /* or hi-lo.h */
But this will be nop in 64-bit environments, and no other #ifdefs are
required. So I believe that this patch can solve the problem of
1. driver-specific readq/writeq
2. atomicity and order of io access
This patch is tested with building allyesconfig and allmodconfig as
ARCH=x86 and ARCH=i386 on top of tip/master.
Cc: Kashyap Desai <[email protected]>
Cc: Len Brown <[email protected]>
Cc: Ravi Anand <[email protected]>
Cc: Vikas Chaudhary <[email protected]>
Cc: Matthew Garrett <[email protected]>
Cc: Jason Uhlenkott <[email protected]>
Cc: James Bottomley <[email protected]>
Cc: Thomas Gleixner <[email protected]>
Cc: "H. Peter Anvin" <[email protected]>
Cc: Roland Dreier <[email protected]>
Cc: James Bottomley <[email protected]>
Cc: Alan Cox <[email protected]>
Cc: Matthew Wilcox <[email protected]>
Cc: Andrew Morton <[email protected]>
Signed-off-by: Hitoshi Mitake <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
|
|
Correct spelling "thresold" to "threshold" in
drivers/scsi/pmraid.h
Signed-off-by: Masanari Iida <[email protected]>
Signed-off-by: Jiri Kosina <[email protected]>
|
|
with Tx only section for single cached SGEs.
Signed-off-by: Bhanu Prakash Gollapudi <[email protected]>
Signed-off-by: Dmitry Kravkov <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
|
|
Once sas_ata_hard_reset() starts honoring the 'deadline' parameter a
pathological configuration could take 25 seconds per ata device
(serialized) to recover. Run per-port recoveries in parallel.
Signed-off-by: Dan Williams <[email protected]>
Signed-off-by: James Bottomley <[email protected]>
|
|
SAS does not tag SMP requests, and at least one lldd (isci) does not permit
more than one in-flight request at a time.
[jejb: fix sas_init_dev tab issues while we're at it]
Signed-off-by: Jeff Skirvin <[email protected]>
Signed-off-by: Dan Williams <[email protected]>
Signed-off-by: James Bottomley <[email protected]>
|
|
In the case of an explicit sas_phy_enable call to disable a phy,
the LLDD provides the calls to sas_phy_disconnected and the
PHYE_LOSS_OF_SIGNAL event.
NOTE: This assumes that the lldd(s) generate the notification, which
appears to be the case, but only verfied on isci.
Signed-off-by: Jeff Skirvin <[email protected]>
Signed-off-by: Dan Williams <[email protected]>
Signed-off-by: James Bottomley <[email protected]>
|
|
Execute the link-reset triggered by sas_phy_enable via
transport_sas_phy_reset so that it can be managed by libata.
Signed-off-by: Dan Williams <[email protected]>
Signed-off-by: James Bottomley <[email protected]>
|
|
Link resets leave ata affiliations intact, so arrange for libsas to make
an effort to avoid dropping the device due to a slow-to-recover link.
Towards this end carry out reset in the host workqueue so that it can
check for ata devices and kick the reset request to libata. Hard
resets, in contrast, bypass libata since they are meant for associating
an ata device with another initiator in the domain (tears down
affiliations).
Need to add a new transport_sas_phy_reset() since the current
sas_phy_reset() is a utility function to libsas lldds. They are not
prepared for it to loop back into eh.
Signed-off-by: Dan Williams <[email protected]>
Signed-off-by: James Bottomley <[email protected]>
|