Running chchp --vary 0 and chccwdev -d on a FCP device with scsi
devices attached can lead to this thread hanging:
================================================================
STACK TRACE FOR TASK: 0x2fbfcc00 (kslowcrw)
STACK:
0 schedule+1136 [0x45f99c]
1 schedule_timeout+534 [0x46054e]
2 wait_for_common+374 [0x45f442]
3 blk_execute_rq+160 [0x217a2c]
4 scsi_execute+278 [0x26daf2]
5 scsi_execute_req+150 [0x26dc86]
6 sd_sync_cache+138 [0x28460a]
7 sd_shutdown+130 [0x28486a]
8 sd_remove+104 [0x284c84]
9 __device_release_driver+152 [0x257430]
10 device_release_driver+56 [0x2575c8]
11 bus_remove_device+214 [0x25672a]
12 device_del+352 [0x25456c]
13 __scsi_remove_device+108 [0x272630]
14 scsi_remove_device+66 [0x2726ba]
15 zfcp_ccw_remove+824 [0x335558]
16 ccw_device_remove+62 [0x2b3f2a]
17 __device_release_driver+152 [0x257430]
18 device_release_driver+56 [0x2575c8]
19 bus_remove_device+214 [0x25672a]
20 device_del+352 [0x25456c]
21 ccw_device_unregister+92 [0x2b48c4]
22 io_subchannel_remove+108 [0x2b4950]
23 css_remove+62 [0x2af7ee]
24 __device_release_driver+152 [0x257430]
25 device_release_driver+56 [0x2575c8]
26 bus_remove_device+214 [0x25672a]
27 device_del+352 [0x25456c]
28 device_unregister+38 [0x25464a]
29 css_sch_device_unregister+68 [0x2af97c]
30 ccw_device_call_sch_unregister+78 [0x2b581e]
31 worker_thread+604 [0x69eb0]
32 kthread+154 [0x6ff42]
33 kernel_thread_starter+6 [0x1c952]
================================================================
The problem is that the chchp --vary 0 leads to zfcp first calling
fc_remote_port_delete which blocks all scsi devices on the remote
port. Calling scsi_remove_device later lets the sd driver issue a
SYNCHRONIZE_CACHE command. This command stays on the "stopped" request
requeue because the SCSI device is blocked. Fix this by first removing
the scsi and fc hosts which removes all scsi devices and do not use
scsi_remove_device.
Reviewed-by: Felix Beck <felix.beck@de.ibm.com>
Signed-off-by: Christof Schmitt <christof.schmitt@de.ibm.com>
Signed-off-by: James Bottomley <James.Bottomley@suse.de>
=======================================================
[ INFO: possible circular locking dependency detected ]
2.6.31-39.x.20090917-s390xdefault #1
-------------------------------------------------------
kslowcrw/83 is trying to acquire lock:
(&adapter->scan_work){+.+.+.}, at: [<0000000000169c5c>] __cancel_work_timer+0x64/0x3d4
but task is already holding lock:
(&zfcp_data.config_mutex){+.+.+.}, at: [<00000000004671ea>] zfcp_ccw_remove+0x66/0x384
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #1 (&zfcp_data.config_mutex){+.+.+.}:
[<0000000000189962>] __lock_acquire+0xe26/0x1834
[<000000000018a4b6>] lock_acquire+0x146/0x178
[<000000000058cb5a>] mutex_lock_nested+0x82/0x3ec
[<0000000000477170>] zfcp_fc_scan_ports+0x3ec/0x728
[<0000000000168e34>] worker_thread+0x278/0x3a8
[<000000000016ff08>] kthread+0x9c/0xa4
[<0000000000109ebe>] kernel_thread_starter+0x6/0xc
[<0000000000109eb8>] kernel_thread_starter+0x0/0xc
-> #0 (&adapter->scan_work){+.+.+.}:
[<0000000000189e60>] __lock_acquire+0x1324/0x1834
[<000000000018a4b6>] lock_acquire+0x146/0x178
[<0000000000169c9a>] __cancel_work_timer+0xa2/0x3d4
[<0000000000465cb2>] zfcp_adapter_dequeue+0x32/0x14c
[<00000000004673e4>] zfcp_ccw_remove+0x260/0x384
[<00000000004250f6>] ccw_device_remove+0x42/0x1ac
[<00000000003cb6be>] __device_release_driver+0x9a/0x10c
[<00000000003cb856>] device_release_driver+0x3a/0x4c
[<00000000003ca94c>] bus_remove_device+0xcc/0x114
[<00000000003c8506>] device_del+0x162/0x21c
[<0000000000425ff2>] ccw_device_unregister+0x5e/0x7c
[<000000000042607e>] io_subchannel_remove+0x6e/0x9c
[<000000000041ff9a>] css_remove+0x3e/0x7c
[<00000000003cb6be>] __device_release_driver+0x9a/0x10c
[<00000000003cb856>] device_release_driver+0x3a/0x4c
[<00000000003ca94c>] bus_remove_device+0xcc/0x114
[<00000000003c8506>] device_del+0x162/0x21c
[<00000000003c85e8>] device_unregister+0x28/0x38
[<0000000000420152>] css_sch_device_unregister+0x46/0x58
[<00000000004276a6>] io_subchannel_sch_event+0x28e/0x794
[<0000000000420442>] css_evaluate_known_subchannel+0x46/0xd0
[<0000000000420ebc>] slow_eval_known_fn+0x88/0xa0
[<00000000003caffa>] bus_for_each_dev+0x7e/0xd0
[<000000000042188c>] for_each_subchannel_staged+0x6c/0xd4
[<0000000000421a00>] css_slow_path_func+0x54/0xd8
[<0000000000168e34>] worker_thread+0x278/0x3a8
[<000000000016ff08>] kthread+0x9c/0xa4
[<0000000000109ebe>] kernel_thread_starter+0x6/0xc
[<0000000000109eb8>] kernel_thread_starter+0x0/0xc
cancel_work_sync is called while holding the config_mutex. But the
work that is being cancelled or flushed also uses the config_mutex.
Fix the resulting deadlock possibility by calling cancel_work_sync
earlier without holding the mutex. The best place to do is is after
offlining the device. No new port scan work will be scheduled for the
offline device, so this is a safe place to call cancel_work_sync.
Reviewed-by: Felix Beck <felix.beck@de.ibm.com>
Signed-off-by: Christof Schmitt <christof.schmitt@de.ibm.com>
Signed-off-by: James Bottomley <James.Bottomley@suse.de>
With the change that the zfcp_adapter struct is only allocated when
the device is set online, the shutdown handler has to check for a
non-existing zfcp_adapter struct. On the other hand, this check is not
necessary in the offline callback, since an online device has the
zfcp_adapter allocated and we go through the offline callback before
removing the ccw device.
Reviewed-by: Felix Beck <felix.beck@de.ibm.com>
Signed-off-by: Christof Schmitt <christof.schmitt@de.ibm.com>
Signed-off-by: James Bottomley <James.Bottomley@suse.de>
With the change for delaying the allocation of zfcp_adapter, the
initial device parameter function has to first call
ccw_device_set_online which allocates the zfcp_adapter structure.
Change this and adapt the cfdc part accordingly.
Reviewed-by: Felix Beck <felix.beck@de.ibm.com>
Signed-off-by: Christof Schmitt <christof.schmitt@de.ibm.com>
Signed-off-by: James Bottomley <James.Bottomley@suse.de>
The config semaphore is only used as a mutex, so replace it with a
simple mutex.
Reviewed-by: Swen Schillig <swen@vnet.ibm.com>
Signed-off-by: Christof Schmitt <christof.schmitt@de.ibm.com>
Signed-off-by: James Bottomley <James.Bottomley@suse.de>
So far, zfcp allocated all resources required for FCP
adapters/subchannels when the device was discovered in the ccw_probe
callback. If there are lots of unused FCP subchannels attached to a
system, this is a waste of resources. To alleviate this, defer the
resource allocation to the first call to ccw_set_online. To avoid
disruptions during possible following calls to ccw_set_offline and
then ccw_set_online, keep the adapter resources until the device is
finally being removed via ccw_remove. While doing this, also manage
the zfcp erp thread together with all other adapter resources in
zfcp_adapter_enqueue/dequeue.
Reviewed-by: Swen Schillig <swen@vnet.ibm.com>
Signed-off-by: Christof Schmitt <christof.schmitt@de.ibm.com>
Signed-off-by: James Bottomley <James.Bottomley@suse.de>
Keep the information about the device and model id in zfcp_ccw. This
requires an additional helper function to check for the privileged
cfdc subchannel, but it allows the removal of the redundant defines
from the zfcp_def header file.
Reviewed-by: Swen Schillig <swen@vnet.ibm.com>
Signed-off-by: Christof Schmitt <christof.schmitt@de.ibm.com>
Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com>
Update the newly introduced message for the boxed status to conform to
match the style of s390 and zfcp messages.
Reviewed-by: Swen Schillig <swen@vnet.ibm.com>
Signed-off-by: Christof Schmitt <christof.schmitt@de.ibm.com>
Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com>
The nameserver port might be in state online when the adapter is
offlined. On adapter reactivation the nameserver port is not
re-opened due to the PORT_ONLINE status. This results in an
unsuccessful recovery. In forcing the nameserver port status
to offline on all adapter offline events this issue is prevented.
Waiting for the reference count to drop to zero in
zfcp_wka_port_offline is not required, so remove it.
Signed-off-by: Swen Schillig <swen@vnet.ibm.com>
Signed-off-by: Christof Schmitt <christof.schmitt@de.ibm.com>
Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com>
If a ccw device did not respond in time during internal io, we set it
into boxed state. With this patch we have the following behaviour:
* the ccw driver will get a notification if the device was online and
goes into the boxed state
* if the device was disconnected and got boxed nothing special is to be
done (it will be handled in reprobing later)
* if the device got boxed while initial sensing it will be unregistered
Signed-off-by: Sebastian Ott <sebott@linux.vnet.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
A scheduled work might still be pending, running while the adapter is
in progress to get dequeued from the system. This can lead to an
invalid pointer dereference (Oops). Once the adpater is set online
again, ensure the nameserver environment is initialized to the
appropriate values again.
Signed-off-by: Swen Schillig <swen@vnet.ibm.com>
Signed-off-by: Christof Schmitt <christof.schmitt@de.ibm.com>
Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com>
The current number based id ERP logging is replaced by a string
based tag version. The benefit is an easier location of the code in
question and the removal of the lengthy array referencing the
individual messages.
The string (7 bytes) based version does not use more space since those
bytes were "used" anyway due to the alignment of the structure.
The encoding of the 7 byte string is as follows
[0-1] = filename
[2-5] = task/function
[6] = section
Due to the character of this string (fixed length) a string
termination is not required here.
Signed-off-by: Swen Schillig <swen@vnet.ibm.com>
Signed-off-by: Christof Schmitt <christof.schmitt@de.ibm.com>
Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com>
Use the device pointer in zfcp_unit for tracking if we have a
registered SCSI device. With this approach, the flag
ZFCP_STATUS_UNIT_REGISTERED is only redundant and can be removed.
Acked-by: Swen Schillig <swen@vnet.ibm.com>
Signed-off-by: Christof Schmitt <christof.schmitt@de.ibm.com>
Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com>
Synchronize the registration and de-registration with the SCSI layer
at CCW registration, de-registration. Before we registered with the
SCSI layer on adapter activation. This way the reg and de-reg process
is in balance.
Signed-off-by: Swen Schillig <swen@vnet.ibm.com>
Signed-off-by: Christof Schmitt <christof.schmitt@de.ibm.com>
Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com>
Attaching a unit immediately after setting the adapter online should
be possible. The problem right now is that the port_scan runs from a
workqueue and has not finished when the set_online call returns and
the sysfs structures for the ports are not available yet. Fix that by
waiting for the port scan to complete.
Signed-off-by: Christof Schmitt <christof.schmitt@de.ibm.com>
Signed-off-by: Swen Schillig <swen@vnet.ibm.com>
Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com>
Reduce the size of zfcp data structures by removing unused and
redundant members. scsi_lun is only the mangled version of the
fcp_lun. So, remove the redundant field and use the fcp_lun instead.
Since the queue lock and the pci_batch indicator are only used in the
request queue, move them from the common queue struct to the adapter
struct.
Signed-off-by: Christof Schmitt <christof.schmitt@de.ibm.com>
Signed-off-by: Swen Schillig <swen@vnet.ibm.com>
Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com>
Call the helper function from cio instead looping through all zfcp
adapters.
Signed-off-by: Swen Schillig <swen@vnet.ibm.com>
Signed-off-by: Christof Schmitt <christof.schmitt@de.ibm.com>
Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com>
- Remove unused references and declarations, including one instance
of the FC ls_adisc struct that has been defined twice.
- Also remove the flags COMMON_OPENING, COMMON_CLOSING,
ADAPTER_REGISTERED and XPORT_OK that are only set and cleared, but
not checked anywhere.
- Remove the zfcp specific atomic_test_mask makro. Simply use
atomic_read directly instead.
- Remove the zfcp internal sg helper functions and switch the places
where it is still used to call sg_virt directly.
- With the update of the QDIO code, the QDIO data structures no
longer use the volatile type qualifier. Now we can also remove the
volatile qualifiers from the zfcp code.
Signed-off-by: Swen Schillig <swen@vnet.ibm.com>
Signed-off-by: Christof Schmitt <christof.schmitt@de.ibm.com>
Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com>
Update the kernel messages in zfcp with input from the message review
and remove some messages that have been identified as redundant.
Signed-off-by: Christof Schmitt <christof.schmitt@de.ibm.com>
Signed-off-by: Swen Schillig <swen@vnet.ibm.com>
Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com>
The notify handler does not change the list of adapters, it only
triggers erp actions to open or shutdown the adapter. We don't
need to hold the config semaphore and wait for the erp to complete.
This is a prerequisite for a fix in the s390 common i/o code.
Signed-off-by: Christof Schmitt <christof.schmitt@de.ibm.com>
Signed-off-by: Martin Petermann <martin@linux.vnet.ibm.com>
Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com>
drivers/s390/scsi/zfcp_aux.c: In function ‘zfcp_fsf_incoming_els_rscn’:
drivers/s390/scsi/zfcp_aux.c:1379: warning: cast from pointer to integer of
different size
drivers/s390/scsi/zfcp_aux.c: In function ‘zfcp_fsf_incoming_els_plogi’:
drivers/s390/scsi/zfcp_aux.c:1432: warning: cast from pointer to integer of
different size
drivers/s390/scsi/zfcp_aux.c: In function ‘zfcp_fsf_incoming_els_logo’:
drivers/s390/scsi/zfcp_aux.c:1457: warning: cast from pointer to integer of
different size
..
Just passing pointers rids us of these warnings and improves readability.
Signed-off-by: Martin Peschke <mp3@de.ibm.com>
Signed-off-by: Christof Schmitt <christof.schmitt@de.ibm.com>
Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com>
This patch removes the now obsolete erp_dbf trace.
Signed-off-by: Martin Peschke <mp3@de.ibm.com>
Signed-off-by: Christof Schmitt <christof.schmitt@de.ibm.com>
Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com>
This patch allows any recovery event to be traced back to an exact
cause, e.g. a particular request identified by an id (address).
Signed-off-by: Martin Peschke <mp3@de.ibm.com>
Signed-off-by: Christof Schmitt <christof.schmitt@de.ibm.com>
Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com>
This patch writes a trace record which provides information about state
changes for adapters, ports and units, e.g. target failure, targets becoming
online, targets being temporarily blocked due to pending recovery, targets
which have been recovered successfully etc.
Signed-off-by: Martin Peschke <mp3@de.ibm.com>
Signed-off-by: Christof Schmitt <christof.schmitt@de.ibm.com>
Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com>
* git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi-misc-2.6: (200 commits)
[SCSI] usbstorage: use last_sector_bug flag universally
[SCSI] libsas: abstract STP task status into a function
[SCSI] ultrastor: clean up inline asm warnings
[SCSI] aic7xxx: fix firmware build
[SCSI] aacraid: fib context lock for management ioctls
[SCSI] ch: remove forward declarations
[SCSI] ch: fix device minor number management bug
[SCSI] ch: handle class_device_create failure properly
[SCSI] NCR5380: fix section mismatch
[SCSI] sg: fix /proc/scsi/sg/devices when no SCSI devices
[SCSI] IB/iSER: add logical unit reset support
[SCSI] don't use __GFP_DMA for sense buffers if not required
[SCSI] use dynamically allocated sense buffer
[SCSI] scsi.h: add macro for enclosure bit of inquiry data
[SCSI] sd: add fix for devices with last sector access problems
[SCSI] fix pcmcia compile problem
[SCSI] aacraid: add Voodoo Lite class of cards.
[SCSI] aacraid: add new driver features flags
[SCSI] qla2xxx: Update version number to 8.02.00-k7.
[SCSI] qla2xxx: Issue correct MBC_INITIALIZE_FIRMWARE command.
...
The common I/O layer can call remove a handler to inform zfcp
that a device disappeared. The handler zfcp_ccw_remove then
removes all unit, port and the adapter data structures. Removing
the units requires that the SCSI devices are removed first.
Signed-off-by: Christof Schmitt <christof.schmitt@de.ibm.com>
Signed-off-by: Swen Schillig <swen@vnet.ibm.com>
Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com>
Already register the debug feature before the zfcp adapter is
set online. This allows to use the debug feature to investigate
the online/offline sequence.
Signed-off-by: Christof Schmitt <christof.schmitt@de.ibm.com>
Signed-off-by: Swen Schillig <swen@vnet.ibm.com>
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
Introduce a shutdown method for the ccw bus that calls the driver
specific shutdown method in struct ccw_driver.
Switch zfcp to the new ccw_driver shutdown method.
Signed-off-by: Cornelia Huck <cornelia.huck@de.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
IO stall after deleting and path checker changes after reenabling zfcp device
Setting one zfcp device offline using chccwdev in a multipath
environment and waiting will lead to IO stall on all paths.
After setting the zfcp device back online using chccwdev,
the devices with io stall will have a different path checker.
Devices corresponding to the deleted units are never freed.
This has the effect that 'slave_destroy' is never called and zfcp
still thinks that this unit is registered
(ZFCP_STATUS_UNIT_REGISTERED is still set). Hence the erp
routine is not called correctly and the unit is not enabled properly.
Do not delete rport and the sdev. Just set the host to block on
'offline'. Setting host online again will then remove the blocked status
and everything is fine again.
Signed-off-by: Michael Loehr <mloehr2@linux.vnet.ibm.com>
Signed-off-by: Swen Schillig <swen@vnet.ibm.com>
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
Improve request handling. Use hash table to manage request IDs.
Signed-off-by: Volker Sameske <sameske@de.ibm.com>
Signed-off-by: Andreas Herrmann <aherrman@de.ibm.com>
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
- Remove all CVS generated information like e.g. revision IDs from
drivers/s390 and include/asm-s390 (none present in arch/s390).
- Add newline at end of arch/s390/lib/Makefile to avoid diff message.
Acked-by: Andreas Herrmann <aherrman@de.ibm.com>
Acked-by: Frank Pavlic <pavlic@de.ibm.com>
Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
this patch adds some fc host attributes and removes its equivalents
from the zfcp_adapter structure and zfcp specific sysfs subtree.
Furthermore it removes superfluous calls to fc_remort_port_delete when
an adapter is set offline because rports will be removed by
fc_remove_host anyway.
Signed-off-by: Andreas Herrmann <aherrman@de.ibm.com>
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
Bugfix (usage of uninitialized pointer in zfcp_port_dequeue) and compile
fixes for the zfcp device driver.
Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
Acked-by: James Bottomley <James.Bottomley@steeleye.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
This patch fixes a severe problem with 2.6.13-rc7.
Due to recent SCSI changes it is not possible to add any LUNs to the zfcp
device driver anymore. With registration of remote ports this is fixed.
Signed-off-by: Andreas Herrmann <aherrman@de.ibm.com>
Acked-by: James Bottomley <jejb@steeleye.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Initial git repository build. I'm not bothering with the full history,
even though we have it. We can create a separate "historical" git
archive of that later if we want to, and in the meantime it's about
3.2GB when imported into git - space that would just make the early
git days unnecessarily complicated, when we don't have a lot of good
infrastructure for it.
Let it rip!
Christof Schmitt