aboutsummaryrefslogtreecommitdiff
path: root/drivers/scsi/scsi_scan.c
AgeCommit message (Collapse)Author
2007-03-21[SCSI] fix scsi_wait_scan build problemJames Bottomley
The #ifdef MODULE around the export of scsi_complete_async_scans() which is the API the scsi_wait_scan module uses is incorrect and causes the symbol to be undefined in certain circumstances leading to a build failure. Remove the defines. Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
2007-02-19Merge master.kernel.org:/pub/scm/linux/kernel/git/jejb/scsi-misc-2.6Linus Torvalds
* master.kernel.org:/pub/scm/linux/kernel/git/jejb/scsi-misc-2.6: [SCSI] SCSI core: better initialization for sdev->scsi_level [SCSI] scsi_proc.c: display sdev->scsi_level correctly [SCSI] megaraid_sas: update version and author info [SCSI] megaraid_sas: return sync cache call with success [SCSI] megaraid_sas: replace pci_alloc_consitent with dma_alloc_coherent in ioctl path [SCSI] megaraid_sas: add bios_param in scsi_host_template [SCSI] megaraid_sas: do not process cmds if hw_crit_error is set [SCSI] scsi_transport.h should include scsi_device.h [SCSI] aic79xx: remove extra newline from info message [SCSI] scsi_scan.c: handle bad inquiry responses [SCSI] aic94xx: tie driver to the major number of the sequencer firmware [SCSI] lpfc: add PCI error recovery support [SCSI] megaraid: pci_module_init to pci_register_driver [SCSI] tgt: fix the user/kernel ring buffer interface [SCSI] sgiwd93: interfacing to wd33c93 [SCSI] wd33c93: Fast SCSI with WD33C93B
2007-02-17Replace remaining references to "driverfs" with "sysfs".Robert P. J. Day
Globally, s/driverfs/sysfs/g. Signed-off-by: Robert P. J. Day <rpjday@mindspring.com> Signed-off-by: Adrian Bunk <bunk@stusta.de>
2007-02-16[SCSI] SCSI core: better initialization for sdev->scsi_levelAlan Stern
This patch will affect the CDB in INQUIRY commands sent to LUNs above 0 when LUN-0 reports a scsi_level of 0; the LUN bits will no longer be set in the second byte of the CDB. This is as it should be. Nevertheless, it's possible that some wacky device might be adversely affected. I doubt anyone will complain... Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
2007-02-16[SCSI] scsi_scan.c: handle bad inquiry responsesAlan Stern
A particular USB device has been reporting short inquiry lengths. The SCSI code cannot operate properly unless we get an inquiry length of 36 or above (because of the way we parse vendor and product), so assume at least 36 bytes are valid even if the device reports fewer. This is wrong, but it's no worse than what we're doing now (using the garbage beyond the last reported valid byte). Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
2007-02-10Merge branch 'linus'James Bottomley
Conflicts: drivers/scsi/ipr.c Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
2007-01-31Merge branch 'linus'James Bottomley
2007-01-27[SCSI] Fix scsi_add_device() for async scanningMatthew Wilcox
I had thought that all drivers which didn't call scsi_scan_host() called scsi_scan_target(). Some, such as sbp2, mptsas and libata-scsi, call scsi_add_device() or __scsi_add_device(). We just need to wait for the currently executing async scans to complete first. This is the same code that's in scsi_scan_target(), except that we have to return an error instead of void when we're declining to scan at all. Signed-off-by: Matthew Wilcox <matthew@wil.cx> Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
2007-01-13[SCSI] scsi_scan message cosmetic errorKurt Garloff
Hi, Minor typo ... In my first iteration of patches (that got merged), the BLIST_ATTACH_PQ3 actually had the value 0x800000, but that got changed later to avoid conflicts. This piece must have been overlooked. You could obviously do something like %x and then add the bitflags, but that looks overkill for something that does not tend to change. Please merge. (Patch applied against latest 2.6.20rc version that I tested.) From: Kurt Garloff <kurt@garloff.de> Subject: [SCSI SCAN] Fix logging message for PQ3 devices The blacklist flags BLIST_ATTACH_PQ3 has value 0x1000000, not 0x800000. Signed-off-by: Kurt Garloff <garloff@suse.de> Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
2007-01-06[SCSI] scsi_scan: fix report lun problems with CDROM or RBC devicesJames Bottomley
Apparently no ATAPI CD/DVD actually supports REPORT LUNS (in spite of claiming scsi-3 compliance, where it's mandatory) and worse, some crash or flake out on being sent the command. This may actually be due to a conflict between SPC and MMC with MMC not listing REPORT LUNS as mandatory. The same standards conflict exists for RBC as well. Fix all of this by reversing the blacklists for CDROM and RBC devices (i.e. now they have to have the BLIST_REPORTLUNS2 flag set even if the inquiry data returns scsi-3 compliance). Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
2007-01-03[SCSI] Add missing completion to scsi_complete_async_scans()Matthew Wilcox
If either scsi_complete_async_scans() is called a second time before the first call has finished, or a host scan is started while scsi_complete_async_scans() is still sleeping, it would fail to wake up the other task, which would sleep forever. I've changed the kernel-doc to make it clear that scsi_complete_async_scans() only guarantees that scans which started before it was called are guaranteed to have finished when it returns. I considered making it wait until all scans are completed, but it can't guarantee that no more scans will start before it returns anyway, and it runs the risk of confusing other callers of scsi_complete_async_scans() for hosts actually scanning. Signed-off-by: Matthew Wilcox <matthew@wil.cx> Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
2006-12-06Merge branch 'master' of ↵David Howells
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6 Conflicts: drivers/pcmcia/ds.c Fix up merge failures with Linus's head and fix new compile failures. Signed-Off-By: David Howells <dhowells@redhat.com>
2006-11-22[SCSI] Make scsi_scan_host work for drivers which find their own targetsMatthew Wilcox
If a driver can find its own targets, it can now fill in scan_finished and (optionally) scan_start in the scsi_host_template. Then, when it calls scsi_scan_host(), it will be called back (from a thread if asynchronous discovery is enabled), first to start the scan, and then at intervals to check if the scan is completed. Also make scsi_prep_async_scan and scsi_finish_async_scan static. Signed-off-by: Matthew Wilcox <matthew@wil.cx> Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
2006-11-22[SCSI] fix missing check for no scanningMatthew Wilcox
Drivers that called scsi_scan_target() instead of scsi_scan_host() were still adding devices; this needs to be under the control of userspace, not the driver. Signed-off-by: Matthew Wilcox <matthew@wil.cx> Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
2006-11-22[SCSI] Add Kconfig option for asynchronous SCSI scanningMatthew Wilcox
Without this patch, the user has to add a kernel command line parameter to get asynchronous SCSI scanning. Now they can select the default at compile time and still override it at boot time if they need to. Signed-off-by: Matthew Wilcox <matthew@wil.cx> Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
2006-11-22Merge ../scsi-rc-fixes-2.6James Bottomley
2006-11-22WorkStruct: Pass the work_struct pointer instead of context dataDavid Howells
Pass the work_struct pointer to the work function rather than context data. The work function can use container_of() to work out the data. For the cases where the container of the work_struct may go away the moment the pending bit is cleared, it is made possible to defer the release of the structure by deferring the clearing of the pending bit. To make this work, an extra flag is introduced into the management side of the work_struct. This governs auto-release of the structure upon execution. Ordinarily, the work queue executor would release the work_struct for further scheduling or deallocation by clearing the pending bit prior to jumping to the work function. This means that, unless the driver makes some guarantee itself that the work_struct won't go away, the work function may not access anything else in the work_struct or its container lest they be deallocated.. This is a problem if the auxiliary data is taken away (as done by the last patch). However, if the pending bit is *not* cleared before jumping to the work function, then the work function *may* access the work_struct and its container with no problems. But then the work function must itself release the work_struct by calling work_release(). In most cases, automatic release is fine, so this is the default. Special initiators exist for the non-auto-release case (ending in _NAR). Signed-Off-By: David Howells <dhowells@redhat.com>
2006-11-13[PATCH] SCSI core: always store >= 36 bytes of INQUIRY dataAlan Stern
This patch (as810c) copies a minimum of 36 bytes of INQUIRY data, even if the device claims that not all of them are valid. Often badly behaved devices put plausible data in the Vendor, Product, and Revision strings but set the Additional Length byte to a small value. Using potentially valid data is certainly better than allocating a short buffer and then reading beyond the end of it, which is what we do now. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Cc: James Bottomley <James.Bottomley@steeleye.com> Cc: Greg KH <greg@kroah.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-10-11[SCSI] Add ability to scan scsi busses asynchronouslyMatthew Wilcox
Since it often takes around 20-30 seconds to scan a scsi bus, it's highly advantageous to do this in parallel with other things. The bulk of this patch is ensuring that devices don't change numbering, and that all devices are discovered prior to trying to start init. For those who build SCSI as modules, there's a new scsi_wait_scan module that will ensure all bus scans are finished. This patch only handles drivers which call scsi_scan_host. Fibre Channel, SAS, SATA, USB and Firewire all need additional work. Signed-off-by: Matthew Wilcox <matthew@wil.cx> Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
2006-09-07[SCSI] Fix refcount breakage with 'echo "1" > scan' when target already presentJames Bottomley
Spotted by: Dan Aloni <da-xx@monatomic.org> The problem is there's inconsistent locking semantic usage of scsi_alloc_target(). Two callers assume the target comes back with reference unincremented and the third assumes its incremented. Fix by always making the reference incremented on return. Also fix path in target alloc that could consistently increment the parent lock. Finally document scsi_alloc_target() so its callers know what the expectations are. Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
2006-09-02[SCSI] SCSI: sanitize INQUIRY stringsAlan Stern
Sanitize the Vendor, Product, and Revision strings contained in an INQUIRY result by setting all non-graphic or non-ASCII characters to ' '. Since the standard disallows such characters, this will affect only non-compliant devices. To help maintain backward compatibility, NUL characters are treated specially. They are taken as string terminators; they and all the following characters are set to ' '. If some valid characters get erased as a result... well, we weren't seeing them before so we haven't lost anything. The primary purpose of this change is to allow blacklist entries to match devices with illegal Vendor or Product strings. In addition, the patch updates a couple of function prototypes, giving inq_result its correct type (unsigned char *). Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
2006-08-19[SCSI] Don't add scsi_device for devices that return PQ=1, PDT=0x1fdave wysochanski
Some targets may return slight variations of PQ and PDT to indicate no LUN mapped. USB UFI setting PDT=0x1f but having reserved bits for PQ is one example, and NetApp targets returning PQ=1 and PDT=0x1f is another. Both instances seem like reasonable responses according to SPC-3 and UFI specs. The current scsi_probe_and_add_lun() code adds a scsi_device for targets that return PQ=1 and PDT=0x1f. This causes LUNs of type "UNKNOWN" to show up in /proc/scsi/scsi when no LUNs are mapped. In addition, subsequent rescans fail to recognize LUNs that may be added on the target, unless preceded by a write to the delete attribute of the "UNKNOWN" LUN. This patch addresses this problem by skipping over the scsi_add_lun() when PQ=1,PDT=0x1f is encountered, and just returns SCSI_SCAN_TARGET_PRESENT. Signed-off-by: Dave Wysochanski <davidw@netapp.com> Signed-off-by: Christoph Hellwig <hch@lst.de> Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
2006-08-06[SCSI] fix up short inquiry printingJames Bottomley
A recent drivers base commit: 3e95637a48820ff8bedb33e6439def96ccff1de5 Caused the bus to be added to dev_printk, so now our SCSI inquiry short messages print like this: scsiscsi 2:0:0:0: Direct access IBM-ESXS ST973401SS B519 PQ: 0 ANSI: 5 Just remove the "scsi" from the sdev_printk to compensate. Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
2006-08-06[SCSI] Improve inquiry printingMatthew Wilcox
- Replace scsi_device_types array API with scsi_device_type function API. Gets rid of a lot of common code, as well as being easier to use. - Add the new device types in SPC4 r05a, and rename some of the older ones. - Reformat the printing of inquiry data; now fits on one line and includes PQ. I think I've addressed all the feedback from the previous versions. My current test box prints: scsi 2:0:1:0: Direct access HP 18.2G ATLAS10K3_18_SCA HP05 PQ: 0 ANSI: 2 Signed-off-by: Matthew Wilcox <matthew@wil.cx> Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
2006-07-03Merge ../scsi-misc-2.6James Bottomley
Conflicts: drivers/scsi/nsp32.c drivers/scsi/pcmcia/nsp_cs.c Removal of randomness flag conflicts with SA_ -> IRQF_ global replacement. Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
2006-06-30Remove obsolete #include <linux/config.h>Jörn Engel
Signed-off-by: Jörn Engel <joern@wohnheim.fh-wedel.de> Signed-off-by: Adrian Bunk <bunk@stusta.de>
2006-06-28[SCSI] scsi: Device scanning oops for offlined devices (resend)Brian King
If a device gets offlined as a result of the Inquiry sent during scanning, the following oops can occur. After the disk gets put into the SDEV_OFFLINE state, the error handler sends back the failed inquiry, which wakes the thread doing the scan. This starts a race between the scanning thread freeing the scsi device and the error handler calling scsi_run_host_queues to restart the host. Since the disk is in the SDEV_OFFLINE state, scsi_device_get will still work, which results in __scsi_iterate_devices getting a reference to the scsi disk when it shouldn't. The following execution thread causes the oops: CPU 0 (scan) CPU 1 (eh) --------------------------------------------------------- scsi_probe_and_add_lun .... scsi_eh_offline_sdevs scsi_eh_flush_done_q scsi_destroy_sdev scsi_device_dev_release scsi_restart_operations scsi_run_host_queues __scsi_iterate_devices get_device scsi_device_dev_release_usercontext scsi_run_queue <---OOPS---> The patch fixes this by changing the state of the sdev to SDEV_DEL before doing the final put_device, which should prevent the race from occurring. Original oops follows: Badness in kref_get at lib/kref.c:32 Call Trace: [C00000002F4476D0] [C00000000000EE20] .show_stack+0x68/0x1b0 (unreliable) [C00000002F447770] [C00000000037515C] .program_check_exception+0x1cc/0x5a8 [C00000002F447840] [C00000000000446C] program_check_common+0xec/0x100 Exception: 700 at .kref_get+0x10/0x28 LR = .kobject_get+0x20/0x3c [C00000002F447B30] [C00000002F447BC0] 0xc00000002f447bc0 (unreliable) [C00000002F447BB0] [C000000000254BDC] .get_device+0x20/0x3c [C00000002F447C30] [D000000000063188] .scsi_device_get+0x34/0xdc [scsi_mod] [C00000002F447CC0] [D0000000000633EC] .__scsi_iterate_devices+0x50/0xbc [scsi_mod] [C00000002F447D60] [D00000000006A910] .scsi_run_host_queues+0x34/0x5c [scsi_mod] [C00000002F447DF0] [D000000000069054] .scsi_error_handler+0xdb4/0xe44 [scsi_mod] [C00000002F447EE0] [C00000000007B4E0] .kthread+0x128/0x178 [C00000002F447F90] [C000000000025E84] .kernel_thread+0x4c/0x68 Unable to handle kernel paging request for <7>PCI: Enabling device: (0002:41:01.1), cmd 143 data at address 0x000001b8 Faulting instruction address: 0xd0000000000698e4 sym1: <1010-66> rev 0x1 at pci 0002:41:01.1 irq 216 sym1: No NVRAM, ID 7, Fast-80, LVD, parity checking sym1: SCSI BUS has been reset. scsi2 : sym-2.2.2 cpu 0x0: Vector: 300 (Data Access) at [c00000002f447a30] pc: d0000000000698e4: .scsi_run_queue+0x2c/0x218 [scsi_mod] lr: d00000000006a904: .scsi_run_host_queues+0x28/0x5c [scsi_mod] sp: c00000002f447cb0 msr: 9000000000009032 dar: 1b8 dsisr: 40000000 current = 0xc0000000045fecd0 paca = 0xc00000000048ee80 pid = 1123, comm = scsi_eh_1 enter ? for help [c00000002f447d60] d00000000006a904 .scsi_run_host_queues+0x28/0x5c [scsi_mod] [c00000002f447df0] d000000000069054 .scsi_error_handler+0xdb4/0xe44 [scsi_mod] [c00000002f447ee0] c00000000007b4e0 .kthread+0x128/0x178 [c00000002f447f90] c000000000025e84 .kernel_thread+0x4c/0x68 Signed-off-by: Brian King <brking@us.ibm.com> Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
2006-06-10[SCSI] remove scsi_request infrastructureChristoph Hellwig
With Achim patch the last user (gdth) is switched away from scsi_request so we an kill it now. Also disables some code in i2o_scsi that was broken since the sg driver stopped using scsi_requests. Signed-off-by: Christoph Hellwig <hch@lst.de> Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
2006-05-28[SCSI] Return -EINVAL when "id == max_id" in scsi_scan_host_selected()Amit Arora
The scsi_scan_host_selected() should return -EINVAL when the id is equal to the max_id. Currently it uses ">" when comparing with max_id, and hence leaves the border case when "id==max_id". The channel and lun have values valid from 0 up to, and including, max_channel or max_lun. But, the valid values for id range from 0 to max_id-1. This patch fixes the problem. Signed-off-by: Amit Arora <aarora@in.ibm.com> Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
2006-04-15[SCSI] scsi_scan.c: fix compile warningsakpm@osdl.org
drivers/scsi/scsi_scan.c: In function `scsi_probe_and_add_lun': drivers/scsi/scsi_scan.c:926: warning: unused variable `vend' drivers/scsi/scsi_scan.c:926: warning: unused variable `mod' drivers/scsi/scsi_scan.c: At top level: drivers/scsi/scsi_scan.c:829: warning: `scsi_inq_str' defined but not used Fix those, tighten up the (somewhat poorly-designed) logging macro and fix some coding-style warts. Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
2006-04-14Merge ../scsi-rc-fixes-2.6James Bottomley
Conflicts: include/scsi/scsi_devinfo.h Same number for two BLIST flags: BLIST_MAX_512 and BLIST_ATTACH_PQ3 Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
2006-04-14[SCSI] BLIST_ATTACH_PQ3 flagsKurt Garloff
Some devices report a peripheral qualifier of 3 for LUN 0; with the original code, we would still try a REPORT_LUNS scan (if SCSI level is >= 3 or if we have the BLIST_REPORTLUNS2 passed in), but NOT any sequential scan. Also, the device at LUN 0 (which is not connected according to the PQ) is not registered with the OS. Unfortunately, SANs exist that are SCSI-2 and do NOT support REPORT_LUNS, but report a unknown device with PQ 3 on LUN 0. We still need to scan them, and most probably we even need BLIST_SPARSELUN (and BLIST_LARGELUN). See the bug reference for an infamous example. This is patch 3/3: 3. Implement the blacklist flag BLIST_ATTACH_PQ3 that makes the scsi scanning code register PQ3 devices and continues scanning; only sg will attach thanks to scsi_bus_match(). Signed-off-by: Kurt Garloff <garloff@suse.de> Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
2006-04-14[SCSI] Better log messages for PQ3 devsKurt Garloff
Some devices report a peripheral qualifier of 3 for LUN 0; with the original code, we would still try a REPORT_LUNS scan (if SCSI level is >= 3 or if we have the BLIST_REPORTLUNS2 passed in), but NOT any sequential scan. Also, the device at LUN 0 (which is not connected according to the PQ) is not registered with the OS. Unfortunately, SANs exist that are SCSI-2 and do NOT support REPORT_LUNS, but report a unknown device with PQ 3 on LUN 0. We still need to scan them, and most probably we even need BLIST_SPARSELUN (and BLIST_LARGELUN). See the bug reference for an infamous example. This patch 2/3: If a PQ3 device is found, log a message that describes the device (INQUIRY DATA and C:B:T:U tuple) and make a suggestion for blacklisting it. Signed-off-by: Kurt Garloff <garloff@suse.de> Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
2006-04-14[SCSI] Try LUN 1 and use bflagsKurt Garloff
Some devices report a peripheral qualifier of 3 for LUN 0; with the original code, we would still try a REPORT_LUNS scan (if SCSI level is >= 3 or if we have the BLIST_REPORTLUNS2 passed in), but NOT any sequential scan. Also, the device at LUN 0 (which is not connected according to the PQ) is not registered with the OS. Unfortunately, SANs exist that are SCSI-2 and do NOT support REPORT_LUNS, but report a unknown device with PQ 3 on LUN 0. We still need to scan them, and most probably we even need BLIST_SPARSELUN (and BLIST_LARGELUN). See the bug reference for an infamous example. This is patch 1/3: If we end up in sequential scan, at least try LUN 1 for devices that reported a PQ of 3 for LUN 0. Also return blacklist flags, even for PQ3 devices. Signed-off-by: Kurt Garloff <garloff@suse.de> Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
2006-04-13[SCSI] add SCSI_UNKNOWN and LUN transfer limit restrictionsJames Bottomley
Original From: Ingo Flaschberger <if@xip.at> To support the RA4100 array from Compaq. This patch now correctly handles SCSI_UNKNOWN types with regard to BLIST_REPORTLUNS2 (allow it) and cdb[1] LUN inclusion (don't). It also allows a BLIST_MAX_512 flag to restrict the maximum transfer length to 512 blocks (apparently this is an RA4100 problem). Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
2006-03-14[SCSI] scsi: move target_destroy callMike Anderson
This patch moves the calling of target_destroy next to the list_del. This closed a race being seen while doing a device add on the aic7xxx. Signed-off-by: Mike Anderson <andmike@us.ibm.com> Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
2006-03-14Merge ../linux-2.6James Bottomley
2006-03-12[SCSI] fix two leaks in scsi_alloc_sdev failure pathsDave Jones
If the scsi_alloc_queue or the slave_alloc calls in scsi_alloc_device fail, we forget to release the locally allocated sdev on the failure path. Coverity #609 Signed-off-by: Dave Jones <davej@redhat.com> Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
2006-02-27[SCSI] scsi: Handle device_add failure in scsi_alloc_targetBrian King
Fixes scsi to handle device_add failure in scsi_alloc_target. Without this patch, if this call were to fail, we can oops when we free the target. Signed-off-by: Brian King <brking@us.ibm.com> Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
2006-02-27[SCSI] fix scsi process problems and clean up the target reap issuesJames Bottomley
In order to use the new execute_in_process_context() API, you have to provide it with the work storage, which I do in SCSI in scsi_device and scsi_target, but which also means that we can no longer queue up the target reaps, so instead I moved the target to a state model which allows target_alloc to detect if we've received a dying target and wait for it to be gone. Hopefully, this should also solve the target namespace race. Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
2006-02-27[SCSI] Recognize missing LUNs for non-standard devicesAlan Stern
Some non-standard SCSI targets or protocols, such as USB UFI, report "no LUN present" by setting the Peripheral Device Type to 0x1f and the Peripheral Qualifier to 0 (not 3 as the standard requires) in the INQUIRY response. This patch (as650b) adds a new target flag and code to accomodate such targets. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
2006-02-27[SCSI] fix uninitialized variable errorMatthew Wilcox
in __scsi_add_device, sdev may be uninitialised if scsi_host_scan_allowed() returns false. Fix by initialising at the top of the routine. Also rely on the fact that scsi_probe_and_add_lun() only actually fills in the sdev pointer if the SCSI_SCAN_LUN_PRESENT case (so no need to check the return value). Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
2006-02-27[SCSI] Remove devfs support from the SCSI subsystemGreg KH
As devfs has been disabled from the kernel tree for a number of months now (5 to be exact), here's a patch against 2.6.16-rc1-git1 that removes support for it from the SCSI subsystem. The patch also removes the scsi_disk devfs_name field as it's no longer needed. Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
2006-02-27[SCSI] SCSI core kmalloc2kzallocJes Sorensen
Change the core SCSI code to use kzalloc rather than kmalloc+memset where possible. Signed-off-by: Jes Sorensen <jes@sgi.com> Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
2006-02-27[SCSI] scsi: handle ->slave_configure return valueChristoph Hellwig
When ­>slave_configure fails the scsi midlayer should handle it. Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
2006-02-14[SCSI] fix wrong context bugs in SCSIJames Bottomley
There's a bug in releasing scsi_device where the release function actually frees the block queue. However, the block queue release calls flush_work(), which requires process context (the scsi_device structure may release from irq context). Update the release function to invoke via the execute_in_process_context() API. Also clean up the scsi_target structure releasing via this API. Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
2006-01-14[SCSI] remove target parent limitiationChristoph Hellwig
When James Smart fixed the issue of the userspace scan atributes crashing the system with the FC transport class he added a patch to let the transport class check if the parent is valid for a given transport class. When adding support for the integrated raid of fusion sas devices we ran into a problem with that, as it didn't allow adding virtual raid volumes without the transport class knowing about it. So this patch adds a user_scan attribute instead, that takes over from scsi_scan_host_selected if the transport class sets it and thus lets the transport class control the user-initiated scanning. As this plugs the hole about user-initiated scanning the target_parent hook goes away and we rely on callers of the scanning routines to do something sensible. For SAS this meant I had to switch from a spinlock to a mutex to synchronize the topology linked lists, in FC they were completely unsynchronized which seems wrong. Signed-off-by: Christoph Hellwig <hch@lst.de> Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
2006-01-12[SCSI] turn most scsi semaphores into mutexesArjan van de Ven
the scsi layer is using semaphores in a mutex way, this patch converts these into using mutexes instead Signed-off-by: Arjan van de Ven <arjan@infradead.org> Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
2006-01-04Merge git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi-misc-2.6Linus Torvalds
2005-12-26[PATCH] Fix Fibre Channel boot oopsJames Bottomley
The oops is characteristic of the underlying device being removed from visibility before the class device, and sure enough we do device_del() before transport_unregister() in the scsi_target_reap() routines. I've no idea why this is suddenly showing up, since the code has been in there since that function was first invented. However, I've confirmed this fixes Andrew Vasquez's boot oops. Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com> Signed-off-by: Linus Torvalds <torvalds@osdl.org>