- 14 12月, 2005 1 次提交
-
-
由 James Bottomley 提交于
This follows on from Jens' patch and consolidates all of the ULD separate handlers for REQ_BLOCK_PC into a single call which has his fix for our direction bug. Signed-off-by: NJames Bottomley <James.Bottomley@SteelEye.com>
-
- 13 12月, 2005 1 次提交
-
-
由 Linus Torvalds 提交于
This reverts commit 1b0997f5, which in turn reverted 34ea80ec (which is thus re-instated). Quoth James Bottomley: "All it's doing is deferring the device_put() from the scsi_put_command() to after the scsi_run_queue(), which doesn't fix the sleep while atomic problem of the device release method. In both cases we still get the semaphore in atomic context problem which is caused by scsi_reap_target() doing a device_del(), which I assumed (wrongly) was valid from atomic context." who also promised to fix scsi_reap_target(). Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
-
- 10 12月, 2005 1 次提交
-
-
由 Jens Axboe 提交于
The scsi_library routines don't correctly set DMA_NONE when req->data_len is zero (instead they check the command type first, so if it's write, we end up with req->data_len == 0 and direction as DMA_TO_DEVICE which confuses some drivers) Signed-off-by: NJames Bottomley <James.Bottomley@SteelEye.com>
-
- 03 12月, 2005 1 次提交
-
-
由 Linus Torvalds 提交于
This reverts commit 34ea80ec. It does a put_device() from softirq context, which is bad since it gets a semaphore for reading. Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
-
- 09 11月, 2005 1 次提交
-
-
由 goggin, edward 提交于
The problem is that scsi_run_queue is called from scsi_next_command() after doing a scsi_put_command. If the command was the only thing holding the reference on the scsi_device then the resulting device put will tear down the block queue. Fix this by taking a reference to the device and holding it around scsi_run_queue() Signed-off-by: NJames Bottomley <James.Bottomley@SteelEye.com>
-
- 07 11月, 2005 1 次提交
-
-
由 Christoph Hellwig 提交于
This function has been superceeded by the block request based interfaces and is unused (except for the uncompilable cpqfc driver). Signed-off-by: NChristoph Hellwig <hch@lst.de> Signed-off-by: NJames Bottomley <James.Bottomley@SteelEye.com>
-
- 29 10月, 2005 2 次提交
-
-
由 Jeff Garzik 提交于
rejections fixed and Signed-off-by: NJames Bottomley <James.Bottomley@SteelEye.com>
-
由 James Bottomley 提交于
This should eliminate (at least in the mid layer) to make numeric assumptions about any of the enumeration variables. As a side effect, it will also make all the messages consistent and line us up nicely for the error logging strategy (if it ever shows itself again). Signed-off-by: NJames Bottomley <James.Bottomley@SteelEye.com>
-
- 28 10月, 2005 1 次提交
-
-
由 Al Viro 提交于
Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk> Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
-
- 17 10月, 2005 1 次提交
-
-
由 Alan Stern 提交于
When a request is deferred in scsi_init_io because the sg table could not be allocated, the associated scsi_cmnd is not released and the request is not marked with REQ_DONTPREP. When the command is retried, if scsi_prep_fn decides to kill it then the scsi_cmnd will never be released. This patch (as573) changes scsi_init_io so that it calls scsi_put_command before deferring a request. Signed-off-by: NAlan Stern <stern@rowland.harvard.edu> Signed-off-by: NJames Bottomley <James.Bottomley@SteelEye.com>
-
- 19 9月, 2005 1 次提交
-
-
由 James Bottomley 提交于
We fix the oops by enforcing the host state model. There have also been two extra states added: SHOST_CANCEL_RECOVERY and SHOST_DEL_RECOVERY so we can take the model through host removal while the recovery thread is active. Signed-off-by: NJames Bottomley <James.Bottomley@SteelEye.com>
-
- 18 9月, 2005 1 次提交
-
-
由 Alan Stern 提交于
I found one other thing that needs to be fixed. The call to scsi_release_buffers in scsi_unprep_request causes an oops, because the sgtable has already been freed in scsi_io_completion. The following patch is needed. Signed-off-by: NAlan Stern <stern@rowland.harvard.edu> Signed-off-by: NJames Bottomley <James.Bottomley@SteelEye.com>
-
- 15 9月, 2005 2 次提交
-
-
由 James Bottomley 提交于
On Wed, 2005-09-14 at 18:06 +1000, Anton Blanchard wrote: > And in particular it looks like the scsi_unprep_request in > scsi_queue_insert is causing it. The following patch fixes the boot > problems on the vscsi machine: OK, my fault. Your fix is almost correct .. I was going to do this eventually, honest, because there's no need to unprep and reprep a command that comes in through scsi_queue_insert(). However, I decided to leave it in to exercise the scsi_unprep_request() path just to make sure it was working. What's happening, I think, is that we also use this path for retries. Since we kill and reget the command each time, the retries decrement is never seen, so we're retrying forever. Signed-off-by: NJames Bottomley <James.Bottomley@SteelEye.com>
-
由 Timothy Thelin 提交于
This fixes an issue in scsi command initialization from a request where sd, sr, st, and scsi_lib all fail to copy the request's cmd_len to the scsi command's cmd_len field. Signed-off-by: NTimothy Thelin <timothy.thelin@wdc.com> Signed-off-by: NJames Bottomley <James.Bottomley@SteelEye.com>
-
- 11 9月, 2005 1 次提交
-
-
由 Mike Christie 提交于
set DID_NO_CONNECT for the BLKPREP_KILL case and correct a few BLKPREP_DEFER cases that weren't checking for the need to plug the queue. Signed-Off-By: NMike Christie <michaelc@cs.wisc.edu> Signed-off-by: NJames Bottomley <James.Bottomley@SteelEye.com>
-
- 10 9月, 2005 1 次提交
-
-
由 James Bottomley 提交于
Actually, just one problem and one cosmetic fix: 1) We need to dequeue for the loop and kill case (it seems easiest simply to dequeue in the scsi_kill_request() routine) 2) There's no real need to drop the queue lock. __scsi_done() is lock agnostic, so since there's no requirement, let's just leave it in to avoid any locking issues. Signed-off-by: NJames Bottomley <James.Bottomley@SteelEye.com>
-
- 09 9月, 2005 2 次提交
-
-
由 James Bottomley 提交于
From: Alan Stern <stern@rowland.harvard.edu> This patch (as559b) adds a new routine, scsi_unprep_request, which gets called every place a request is requeued. (That includes scsi_queue_insert as well as scsi_requeue_command.) It also changes scsi_kill_requests to make it call __scsi_done with result equal to DID_NO_CONNECT << 16. (I'm not sure if it's necessary to call scsi_init_cmd_errh here; maybe you can check on that.) Finally, the patch changes the return value from scsi_end_request, to avoid returning a stale pointer in the case where the request was requeued. Fortunately the return value is used in only place, and the change actually simplified it. Signed-off-by: NAlan Stern <stern@rowland.harvard.edu> Rejections fixed up and Signed-off-by: NJames Bottomley <James.Bottomley@SteelEye.com>
-
由 Neil Brown 提交于
If a filesystem, while writing out data, decides that it is good to issue a cache flush on a SCSI drive (or other 'sd' device), it will call blkdev_issue_flush which calls ->issue_flush_fn which is scsi_issue_flush_fn. This calls sd_issue_flush which calls sd_sync_cache, which calls scsi_execute_request. This will (as sshdr != NULL) call kmalloc(SCSI_SENSE_BUFFERSIZE, GFP_KERNEL) If memory is tight, the presence of GFP_KERNEL may cause write requests to be sent to some filesystem to free up memory, however if that filesystem is waiting for the issue_flush_fn to complete, you could get a deadlock. I wonder if it might be more appropriate to use GFP_NOIO as in the following patch. I wonder if it might be even more appropriate to cope better with a kmalloc failure, especially as in this use, sd_sync_cache only will use the sense information to print out a more informative error message. Signed-off-by: NNeil Brown <neilb@suse.de> Signed-off-by: NJames Bottomley <James.Bottomley@SteelEye.com>
-
- 07 9月, 2005 1 次提交
-
-
由 James Bottomley 提交于
scsi_io_completion() can be a bit noisy about certain conditions. Previously this wasn't a problem for internally generated commands, since they never hit it. However, since we do all SCSI commands via bios, now they do. user CD testers like magicdev are now getting not ready messages every time they touch the CD to see if there's anything in it. Fix this by making all scsi_execute commands REQ_QUIET and making scsi_finish_io() not say anything for REQ_QUIET. Signed-off-by: NJames Bottomley <James.Bottomley@SteelEye.com>
-
- 29 8月, 2005 5 次提交
-
-
由 James Bottomley 提交于
The new bio code was incorrectly converted from stack allocated to kmalloc'd buffer handling. There are two places where it incorrectly uses sizeof(*sense) to get the size of the sense buffer. This actually produces one, so no sense data was ever getting back, causing failure in things like disk spin up. Signed-off-by: NJames Bottomley <James.Bottomley@SteelEye.com>
-
由 akpm@osdl.org 提交于
Older gcc's require variable definitions at the beginning of a block. Signed-off-by: NAndrew Morton <akpm@osdl.org> Signed-off-by: NJames Bottomley <James.Bottomley@SteelEye.com>
-
由 James Bottomley 提交于
This one removes struct scsi_request entirely from sd. In the process, I noticed we have no callers of scsi_wait_req who don't immediately normalise the sense, so I updated the API to make it take a struct scsi_sense_hdr instead of simply a big sense buffer. Signed-off-by: NJames Bottomley <James.Bottomley@SteelEye.com>
-
由 James Bottomley 提交于
This one's slightly more difficult. The transport class uses REQ_FAILFAST, so another interface (scsi_execute) had to be invented to take the extra flag. Also, the sense functions are shifted around to allow spi_execute to place data directly into a struct scsi_sense_hdr. With this change, there's probably a lot of unnecessary sense buffer allocation going on which we can fix later. Signed-off-by: NJames Bottomley <James.Bottomley@SteelEye.com>
-
由 James Bottomley 提交于
After this, we just have some drivers, all the ULDs and the SPI transport class using scsi_wait_req(). Signed-off-by: NJames Bottomley <James.Bottomley@SteelEye.com>
-
- 28 8月, 2005 3 次提交
-
-
由 James Bottomley 提交于
Original From: Mike Christie <michaelc@cs.wisc.edu> Add scsi_execute_req() as a replacement for scsi_wait_req() Fixed up various pieces (added REQ_SPECIAL and caught req use after free) Signed-off-by: NJames Bottomley <James.Bottomley@SteelEye.com>
-
由 James Bottomley 提交于
Signed-off-by: NJames Bottomley <James.Bottomley@SteelEye.com>
-
由 James Bottomley 提交于
Here's the proof of concept for this one. It converts scsi_wait_req to do correct REQ_BLOCK_PC submission (and works nicely in my setup). The final goal should be to eliminate struct scsi_request, but that can't be done until the character submission paths of sg and st are also modified. There's some loss of functionality to this: retries are no longer controllable (except by setting REQ_FASTFAIL) and the wait_req API needs to be altered, but it looks very nice. Signed-off-by: NJames Bottomley <James.Bottomley@SteelEye.com>
-
- 31 7月, 2005 1 次提交
-
-
由 Mike Anderson 提交于
Migrate the current SCSI host state model to a model like SCSI device is using. Signed-off-by: NMike Anderson <andmike@us.ibm.com> Rejections fixed up and Signed-off-by: NJames Bottomley <James.Bottomley@SteelEye.com>
-
- 14 7月, 2005 1 次提交
-
-
由 Chen, Kenneth W 提交于
scsi_init_io calls scsi_alloc_sgtable and then calls blk_rq_map_sg to initialize the scatterlist structure. blk_rq_map_sg() already memset the structure for every new segment. That makes the memset in scsi_alloc_sgtable unnecessary. Patch to delete the extra memset in scsi_alloc_sgtable. Tested on a x86_64 machine. Looks stable to me. Signed-off-by: NKen Chen <kenneth.w.chen@intel.com> Signed-off-by: NJames Bottomley <James.Bottomley@SteelEye.com>
-
- 29 6月, 2005 1 次提交
-
-
由 KAMBAROV, ZAUR 提交于
The check in 627 BUG_ON(index > SG_MEMPOOL_NR); with SG_MEMPOOL_NR defined in 32 #define SG_MEMPOOL_NR (sizeof(scsi_sg_pools)/sizeof(struct scsi_host_sg_pool)) was not sufficient. sgp, set in 629 sgp = scsi_sg_pools + index; is dereferenced in 630 mempool_free(sgl, sgp->pool); Signed-off-by: NZaur Kambarov <zkambarov@coverity.com> Cc: <linux-scsi@vger.kernel.org> Cc: James Bottomley <James.Bottomley@steeleye.com> Signed-off-by: NAndrew Morton <akpm@osdl.org> Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
-
- 27 6月, 2005 3 次提交
-
-
由 Christoph Hellwig 提交于
We never look at it except for the old megaraid driver that abuses it for sending internal commands. That usage can be fixed easily because those internal commands are single-threaded by a mutex and we can easily use a completion there. Signed-off-by: NJames Bottomley <James.Bottomley@SteelEye.com>
-
由 Christoph Hellwig 提交于
never checked anywhere Signed-off-by: NJames Bottomley <James.Bottomley@SteelEye.com>
-
由 Christoph Hellwig 提交于
Never used for anything but printing it out in debug routines. Signed-off-by: NJames Bottomley <James.Bottomley@SteelEye.com>
-
- 24 6月, 2005 1 次提交
-
-
由 Adrian Bunk 提交于
Another rollup of patches which give various symbols static scope Signed-off-by: NAdrian Bunk <bunk@stusta.de> Signed-off-by: NAndrew Morton <akpm@osdl.org> Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
-
- 21 5月, 2005 5 次提交
-
-
由 Tejun Heo 提交于
scsi_queue_insert() has four callers. Three callers call with timer disabled and one (the second invocation in scsi_dispatch_cmd()) calls with timer activated. scsi_queue_insert() used to always call scsi_delete_timer() and ignore the return value. This results in race with timer expiration. Remove scsi_delete_timer() call from scsi_queue_insert() and make the caller delete timer and check the return value. Signed-off-by: NTejun Heo <htejun@gmail.com> Signed-off-by: NJames Bottomley <James.Bottomley@SteelEye.com>
-
由 Tejun Heo 提交于
scsi_queue_insert() used to use blk_insert_request() for requeueing requests. This depends on the unobvious behavior of blk_insert_request() setting REQ_SPECIAL and REQ_SOFTBARRIER when requeueing. This patch makes scsi_queue_insert() use blk_requeue_request(). As REQ_SPECIAL means special requests and REQ_SOFTBARRIER is automatically handled by blk layer now, no flag needs to be set. Note that scsi_queue_insert() now calls scsi_run_queue() itself, and the prototype of the function is added right above scsi_queue_insert(). This is temporary, as later requeue path consolidation patchset removes scsi_queue_insert(). By adding temporary prototype, we can do away with unnecessarily moving functions. Signed-off-by: NTejun Heo <htejun@gmail.com> Signed-off-by: NJames Bottomley <James.Bottomley@SteelEye.com>
-
由 Tejun Heo 提交于
scsi_requeue_request() used to use blk_insert_request() for requeueing requests. This depends on the unobvious behavior of blk_insert_request() setting REQ_SPECIAL and REQ_SOFTBARRIER when requeueing. This patch makes scsi_queue_insert() use blk_requeue_request(). As REQ_SPECIAL means special requests and REQ_SOFTBARRIER is automatically handled by blk layer now, no flag needs to be set. Signed-off-by: NTejun Heo <htejun@gmail.com> Signed-off-by: NJames Bottomley <James.Bottomley@SteelEye.com>
-
由 Tejun Heo 提交于
blk_insert_request() has a unobivous feature of requeuing a request setting REQ_SPECIAL|REQ_SOFTBARRIER. SCSI midlayer was the only user and as previous patches removed the usage, remove the feature from blk_insert_request(). Only special requests should be queued with blk_insert_request(). All requeueing should go through blk_requeue_request(). Signed-off-by: NTejun Heo <htejun@gmail.com> Signed-off-by: NJames Bottomley <James.Bottomley@SteelEye.com>
-
由 Tejun Heo 提交于
scsi_init_io() used to set REQ_SPECIAL when it fails sg allocation before requeueing the request by returning BLKPREP_DEFER. REQ_SPECIAL is being updated to mean special requests. So, remove REQ_SPECIAL setting. Signed-off-by: NTejun Heo <htejun@gmail.com> Signed-off-by: NJames Bottomley <James.Bottomley@SteelEye.com>
-
- 19 4月, 2005 1 次提交
-
-
scsi_cmnd->serial_number_at_timeout doesn't serve any purpose anymore. All serial_number == serial_number_at_timeout tests are always true in abort callbacks. Kill the field. Also, as ->pid always equals ->serial_number and ->serial_number doesn't have any special meaning anymore, update comments above ->serial_number accordingly. Once we remove all uses of this field from all lldd's, this field should go. Signed-off-by: NTejun Heo <htejun@gmail.com> Signed-off-by: NJames Bottomley <James.Bottomley@SteelEye.com>
-