are off.
If there is sufficient interest in this, I could look at putting together a
patch to 2.4.x which would implement the scheme.
James Bottomley
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
[EMAIL PROTECTED] said:
James mentioned there might be a patch problem with reservations; has
this been sorted?
I believe so. A problem still shows up on an IA-64 system with an AHA2944UW
SCSI card but cannot be duplicated on an x86 system with the same
configuration. All of the tests on
the reset (to prevent heavy I/O starving
the command allocation when a reset is requested) and also corrects a locking
problem in the old mid-layer issuing the reset.
James Bottomley
Index: linux/2.4/drivers/scsi/scsi.c
diff -c linux/2.4/drivers/scsi/scsi.c:1.1.1.5 linux/2.4/drivers/scsi/scsi.c
a reasonable convention for drivers
like yours and requires no modifications to the current SCSI subsystem.
James Bottomley
-
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to [EMAIL PROTECTED]
controller OS. To get this to work, they'd essentially have to have done what you're
proposing.
James Bottomley
-
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to [EMAIL PROTECTED]
On Tue, 2005-01-18 at 09:56 -0500, Alan Stern wrote:
When I posted a patch last week to fix a reference to deallocated memory
in sd.c, I forgot to check whether the same problem exists in sr.c. It
does, and here's the patch to fix it.
Yes, I already caught that in the scsi-rc-fixes-2.6 tree
On Tue, 2005-01-18 at 12:03 +0100, Andi Kleen wrote:
Add a call vector for 32bit compat ioctls to the SCSI host
structure. This is needed for some followon patches.
Signed-off-by: Andi Kleen [EMAIL PROTECTED]
Shouldn't this also be surrounded by #ifdef CONFIG_COMPAT (on the
grounds that you
On Wed, 2005-01-19 at 00:27 +0100, Andi Kleen wrote:
On Tue, Jan 18, 2005 at 07:35:36AM -0800, James Bottomley wrote:
Shouldn't this also be surrounded by #ifdef CONFIG_COMPAT (on the
grounds that you never fill it in unless CONFIG_COMPAT is defined)?
At least the standard file_operations
On Fri, 2005-01-21 at 17:11 -0500, Mukker, Atul wrote:
All right! The implementation is complete for this and the driver has
thoroughly gone through testing. Everything looks good except for a minor
glitch.
That's good news.
After the new logical drives are created with - - - written to the
On Mon, 2005-01-24 at 15:48 +0100, Heiko Carstens wrote:
I thought that having release methods that just called kfree() were
also verboten?
We do a kmalloc(sizeof(struce device),...) somewhere and this
is how we get rid of it again.
How are we supposed to free this object otherwise? The
On Mon, 2005-01-24 at 02:39 -0800, Mike Christie wrote:
The attached patch built against scsi-misc-2.6 moves the
target iSCSI attributes to a new structure representing
a iSCSI session. The reason for doing this is to
create a interface that allows the Sourceforge iSCSI driver
to create and
On Tue, 2005-01-25 at 07:08 +0100, Heiko Carstens wrote:
Originally this generic device was part of your adapter structure. Now
you're trying to separate it and causing these problems. What it's
Could you please elaborate where this patch does cause a problem?
You're look to be breaking
On Tue, 2005-01-25 at 19:10 +0100, Martin Peschke3 wrote:
Actually, you will find the adapter structure be an anchor for several
other objects, or lists of them respectively. We tried to organize
all the driver private data in a sane way. That means there is a tree
of objects representing the
On Tue, 2005-01-25 at 12:37 -0800, Mike Christie wrote:
Will do. One question though. If a function like
transport_add_device or transport_setup_device fails,
how does the caller detect this?
It doesn't; the system runs degraded.
James
-
To unsubscribe from this list: send the line
o streamline block SG_IO error processing in sd
o streamline block SG_IO error processing
o sense data helpers lk 2.6.11-rc1-bk1
o sg descriptor sense cleanup lk 2.6.11-rc1-bk1
o scsi_debug dsense
Geert Uytterhoeven:
o SCSI NCR53C9x.c: some cleanups
James Bottomley:
o SCSI: Fix
On Fri, 2005-01-28 at 10:38 +0100, Jens Axboe wrote:
+/*
+ * snoop succesfull completion of mode select commands that update the
+ * write back cache state
+ */
+#define MS_CACHE_PAGE0x08
+static void sd_snoop_cmd(struct scsi_cmnd *cmd)
+{
+ struct scsi_disk *sdpk;
+ char
On Fri, 2005-01-28 at 10:38 +0100, Jens Axboe wrote:
+/*
+ * snoop succesfull completion of mode select commands that update the
+ * write back cache state
+ */
+#define MS_CACHE_PAGE0x08
+static void sd_snoop_cmd(struct scsi_cmnd *cmd)
+{
+ struct scsi_disk *sdpk;
+ char
I wouldn't have noticed this at all since you didn't send it to the scsi
list, but fortunately, Al Viro drew it politely to my attention as
another example of SCSI refcounting problems.
The issue seems to be that we have a spurious scsi_cd_put() on the error
path of sr_open(). The sr_block_..()
On Fri, 2005-01-28 at 21:46 -0800, Andrew Vasquez wrote:
Returning back DID_IMM_RETRY for these 'transport' related conditions
would of course help in this issue -- but at the same time bring with it
several side-effects which may not be desirable.
So, beyond this particular circumstance,
All of the transport class patches contain a thinko in device matching
(and, unfortunately, one I exhorted everyone not to make in the generic
transport class comments): The match matches every container in the
class instead of the specific container belonging to the HBA. This
causes a oops when
On Sat, 2005-01-29 at 11:34 -0800, Patrick Mansfield wrote:
But the transport hit a failure, not the storage device.
I thought Andrew hit this sequence:
- pull / replace cable
- IO resumes but gets NOT_READY (the device could be logging back
into the fibre or such)
On Wed, 2005-01-26 at 15:59 -0800, Mike Christie wrote:
It appears there is a missing class_device_del.
The comments for transport_remove_device indicate
that transport_remove_classdev should call it
(which the attached patch does), but the comment in
attribute_container_remove_device:
OK,
James Smart pointed out that if you insert and remove a HBA driver a few
times, eventually the system oopses.
The reason is that the transport classes all kfree their attribute
containers, but don't actually unregister them first (so we have freed
memory on the container list). The attached
I just got around to applying and testing this. I needed the attached
to get around the compile warnings it gave me on ia64
I've got to say, it doesn't look pretty to have the block layer
compat_ioctl returning long but the scsi one returning int; likewise
with the void __user *arg vs unsigned
On Sat, 2005-01-29 at 09:03 -0500, [EMAIL PROTECTED] wrote:
Adds io statistics (requests, completions, error count) as generic
attributes for scsi devices.
I needed the attached to make this compile without warnings on ia64
James
= drivers/scsi/scsi_sysfs.c 1.65 vs edited =
---
On Wed, 2005-02-02 at 20:51 -0800, Andrew Morton wrote:
Well that's a decision which the scsi maintainers will need to make. Lots
of current drivers use LINUX_VERSION_CODE, even though we'd prefer they not
do so. I don't know what the scsi policy is for new submissions.
Hey ... I have to
On Sat, 2005-01-29 at 09:03 -0500, [EMAIL PROTECTED] wrote:
This patch extends scsi_target support:
- Allows for driver-specific data to be allocated along with the
target structure and accessible via the starget-hostdata pointer.
- Adds scsi target alloc/configure/destory callbacks
On Tue, 2005-02-01 at 00:22 +0100, Jesper Juhl wrote:
audio
Could you try the attached?
James
---BeginMessage---
Jens Axboe wrote:
On Mon, Jan 31 2005, Douglas Gilbert wrote:
Jens Axboe wrote:
On Mon, Jan 31 2005, Fabio Coatti wrote:
Alle 09:00, lunedì 31 gennaio 2005, Jens Axboe ha scritto:
On Wed, 2005-02-02 at 10:56 -0500, Ju, Seokmann wrote:
+ .sdev_attrs = megaraid_device_attrs,
+ .shost_attrs= megaraid_class_device_attrs,
These are, perhaps, slightly confusing names. The terms device and
class_device have well defined meanings
: fix BUG's for smp_processor_id() on interrupt
Christoph Hellwig:
o cciss: handle scsi_add_host failure
James Bottomley:
o SCSI: fix HBA removal problem with transport classes
Seokmann Ju:
o megaraid_mbox 2.20.4.3 patch
and the diffstat is:
Documentation/scsi/ChangeLog.megaraid | 104
On Tue, 2005-02-15 at 14:09 +, Matthew Wilcox wrote:
Actually, for 53c700, I think this *is* the right fix. Unless we want to
move it away from using host-base (which is marked as legacy crap, so
maybe we do). I guess pushing it into hostdata is the preferred way?
Well, no it's not
On Tue, 2005-02-15 at 16:54 -0800, Joe Scsi wrote:
OK (and sorry if I'm being dense) but does this mean that a network
SCSI transport should make up an id for each target port it connects
to and then call scsi_scan_target()?
Currently yes ... now that we allow unscanned hosts, it's not
On Fri, 2005-02-18 at 12:05 -0800, Greg KH wrote:
For a device? It seems a huge overkill to add this attribute for
_every_ device in the system, when only a small minority can actually
use it. Just put it as a default scsi or transport class attribute
instead.
Actually, we might be able to
On Tue, 2005-02-22 at 16:11 +0900, Yokota Hiroshi wrote:
+ if (data-CurrentSC != NULL) {
+ nsp_msg(KERN_WARNING, CurrentSC!=NULL this can't be happen);
SCpnt-result = DID_BAD_TARGET 16;
nsp_scsi_done(SCpnt);
- return 0;
+
On Sun, 2005-02-20 at 22:44 -0500, Alan Stern wrote:
James, please withdraw the patch above.
Actually, I already have this in the tree. Could you just do an
incremental to remove the blacklist line since I think the IBM people
still want their shark fix?
Thanks,
James
-
To unsubscribe from
Looking through this, the only things I really noticed that need work
are:
ch_do_scsi(): It looks like this has an effective reimplementation of
scsi_wait_req. We're trying to deprecate the usage of scsi_do_req so we
can make it private eventually. What's the reason you can't use
On Mon, 2005-03-07 at 02:32 +, Matthew Wilcox wrote:
Thanks for reminding me; still the only person who cares about the Q720
also follows the parisc-linux-cvs list ;-)
Hey, I have more than one user!
Also, I don't really follow the parisc CVS tree on the voyagers;
primarily because I
On Sat, 2005-03-12 at 19:04 +0200, Kai Makisara wrote:
This is an updated version of the patch I sent March 7. The sense descriptor
initialization has been made lighter.
The patch at the end of this message applies to 2.6.11-bk7 + st descriptor
sense
patch + st auto eof patch (i.e., st
On Wed, 2005-03-16 at 08:58 +0100, Jens Axboe wrote:
Guys, who reviewed this? It looks completely bogus, using kmap() for tha
entire sg list is just wrong and can deadlock easily. The proper way is
of course to skip the virtual address requirement and dma map the sg
array properly.
I suppose
On Wed, 2005-03-16 at 13:35 -0500, Jeff Garzik wrote:
Are my 3ware bugfixes in the queue? Currently 3ware claims it handled
the interrupt, even the interrupt is a shared one and the event was
meant for another driver.
Not in my queue ... you could try Adam Radford directly ...
James
-
To
On Wed, 2005-03-16 at 15:31 -0500, Jeff Garzik wrote:
More info? Were they dropped on purpose, or just never arrived?
If dropped on purpose, what was the reason?
You posted substantive updates to a maintained driver. Adam Radford is
the maintainer, but I haven't heard anything from him
On Wed, 2005-03-16 at 14:45 -0800, Patrick Mansfield wrote:
Any comments on this? Should I resend these patches?
Well, the basic comment is that there are a lot of features that SCSI
has that the driver core lacks:
1) Attribute overrides. This is actually part of the published API for
SCSI
2)
On Mon, 2005-03-21 at 14:26 +0100, Jens Axboe wrote:
scsi_allocate_request() doesn't hold a reference to the device that it
points to, that is not good. This patch fixes that up.
Actually, I don't think this is correct. The reference is taken when
the command is attached to a request in the
On Mon, 2005-03-21 at 15:59 +0100, Jens Axboe wrote:
This is not even enough, since the queue lock is embedded in sdev
structure. Guys, this is a serious issue. Oopsing a kernel is trivial
with a hotplug device like a usb stick.
Do you have the instructions to reproduce and a trace ... I've
On Tue, 2005-03-22 at 12:17 +0100, Jens Axboe wrote:
You need to have io in progress. The one ref problem with
scsi_allocate_request() is easy to trigger, if you just open/close the
device repeatedly while inserting and removing it.
OK, this is the python program I've been using:
while 1:
On Tue, 2005-03-22 at 13:35 -0700, Moore, Eric Dean wrote:
I still wonder if the SPI transport layer will work for RAID volumes.
Do you know if the spi transport layer supports dv on hidden devices in a
raid volume?
Meaning these hidden physical disks will not been seen by the block layer,
On Wed, 2005-03-23 at 11:14 +0900, Tejun Heo wrote:
When hot-unplugging using scsi_remove_host() function (as usb
does), scsi_forget_host() used to be called before
scsi_host_cancel(). So, the device gets removed first without
request cleanup and scsi_host_cancel()
On Wed, 2005-03-23 at 11:14 +0900, Tejun Heo wrote:
scsi_device-device_busy, Scsi_Host-host_busy and
-host_failed have volatile qualifiers, but the qualifiers
don't serve any purpose. Kill them. While at it, protect
-host_failed update in scsi_error for consistency
On Wed, 2005-03-23 at 13:50 +0900, Tejun Heo wrote:
Well, but it's because scsi midlayer calls back into usb-storage eh
after the detaching process is complete.
Yes, but that's legitimate. It's always been explicitly stated that we
can't ensure absolute synchronisation in the stack:
On Tue, 2005-03-22 at 23:22 -0500, Jeff Garzik wrote:
volatile is almost always (a) buggy, or (b) hiding bugs. At the very
least, barriers are usually needed.
The choice is either barrier or volatile usually. volatile is nasty
primarily because it causes compiler pessimism in variable
On Wed, 2005-03-23 at 08:19 +0100, Jens Axboe wrote:
It is not the oops I am getting. When I get a few minutes today, I'll
reproduce with vanilla and post it here.
Well, I have news too. Unfortunately, the python script I posted is
hanging in D wait. When I tested all of this out (with a
On Tue, 2005-03-22 at 11:05 +0800, Zhao, Forrest wrote:
Let me tell you the testing experience in our lab:
1 we install kernel 2.6.11.2 on a Tiger4 platform,
2 there're two SCSI disks, one is sda for root fs, the other is sdb for
/mnt
3 execute cp -r /usr/src/linux-2.6.11.2 /mnt
4 during
On Mon, 2005-03-21 at 19:38 -0800, adam radford wrote:
This patch updates the driver for the 3ware 5/6/7/8000 series to do
the following:
This one got mangled by your mailer ... (looks like it broke long
lines). Could you resend?
Thanks,
James
-
To unsubscribe from this list: send the line
On Fri, 2005-03-25 at 12:15 +0900, Tejun Heo wrote:
I think I found the cause. Special requests submitted using
scsi_do_req() never initializes -end_io(). Normally, SCSI midlayer
terminates special requests inside the SCSI midlayer without passing
through the blkdev layer. However, if a
On Thu, 2005-03-24 at 16:56 -0700, Moore, Eric Dean wrote:
+
config FUSION_FC
- tristate Fusion MPT (base + ScsiHost) drivers for FC
- depends on PCI SCSI
+ tristate Fusion MPT (ScsiHost) drivers for FC
This rejects completely in Kconfig. Could you check your base for
On Thu, 2005-03-24 at 16:57 -0700, Moore, Eric Dean wrote:
+static struct device_attribute mptscsih_queue_depth_attr = {
+ .attr = {
+ .name = queue_depth,
+ .mode = S_IWUSR,
+ },
+ .store = mpt_core_store_queue_depth,
+};
But
On Sat, 2005-03-26 at 09:27 +0200, Kai Makisara wrote:
I fully agree that doing done() correctly _is_ a problem, especially when
the SCSI subsystem evolves and the high-level driver writers do not follow
the development closely enough.
One solution to these problems would be to let the
On Sun, 2005-03-27 at 01:16 -0800, Jeremy Higdon wrote:
James, actually this queue depth code predates your change_queue_depth
API. I don't think it was ever converted to the new API.
Erk, you're right. My todo list says I'm only waiting on 3ware patches
for all the conversions to be
On Mon, 2005-03-28 at 07:33 -0300, Marcelo Tosatti wrote:
You probably already know about this, but just in case:
v2.6.12-rc1 yields
program scsi_unique_id is using a deprecated SCSI ioctl, please convert it to
SG_IO
Actually, a lot of programs do this. Since about 2.6.11 (I think,
On Mon, 2005-03-28 at 09:34 -0300, Marcelo Tosatti wrote:
I'm using FC2 - FC3 probably has it updated.
Sorry for the noise.
Heh, not necessarily ... the reason for making the SCSI subsystem print
these messages is that no-one was updating any user level programs to
move to the new API ... now
On Mon, 2005-03-28 at 14:04 -0800, Mark Haverkamp wrote:
On Mon, 2005-03-28 at 15:58 -0600, James Bottomley wrote:
What exactly is this for? I know of no platforms that implement readl
and friends incorrectly, so all of this should be unnecessary.
I wondered about this. Mark S. thought
:
o drivers/scsi/osst.c: remove unused code
o drivers/scsi/osst.c: make code static
Alan Cox:
o atp870u DMA mask fix
o atp870u: Re-merge cleanups
Alan Stern:
o Add a scsi_device flag for RETRY_HWERROR
Eric Moore:
o Make Fusion-MPT much faster as module
James Bottomley:
o Fix SCSI
On Thu, 2005-03-31 at 18:07 +0900, Tejun Heo wrote:
01_scsi_no_REQ_SPECIAL_on_requeue.patch
blk_insert_request() has 'reinsert' argument, which, when set,
turns on REQ_SPECIAL and REQ_SOFTBARRIER and requeues the
request. SCSI midlayer was the only user of this feature and
On Thu, 2005-03-31 at 18:08 +0900, Tejun Heo wrote:
Move request preparations scattered in scsi_request_fn() and
scsi_dispatch_cmd() into scsi_prep_fn().
* CDB_SIZE check in scsi_dispatch_cmd()
* SCSI-2 LUN preparation in scsi_dispatch_cmd()
*
On Fri, 2005-04-01 at 14:01 +0900, Tejun Heo wrote:
Well, REQ_SPECIAL is the signal to the mid-layer that we've allocated
the resources necessary to process the command, so in practice it will
be turned on for every requeue request (because we set it when the
command is prepared),
On Fri, 2005-04-01 at 09:47 -0800, Bryan Henderson wrote:
If you and Linux could identify the host in common terms, you wouldn't
have to do this. But the question is open as to in what terms you
personally identify the host to which you attached the device. Is it the
controller to the
On Sun, 2005-03-27 at 16:34 +0200, Adrian Bunk wrote:
This patch removes #if's for kernel 2.2 .
this one looks like it's not quite complete:
-#ifndef LINUX_VERSION_CODE
#include linux/version.h
-#endif
Once there are no more KERNEL_VERSION dependencies in a file, it's
inclusion of
This driver has had it's own different infrastructure for doing this for
ages, but it's time it used the common one.
James
= drivers/scsi/53c700.c 1.64 vs edited =
--- 1.64/drivers/scsi/53c700.c 2005-03-20 21:04:31 -06:00
+++ edited/drivers/scsi/53c700.c2005-04-02 14:15:04
On Mon, 2005-04-04 at 17:50 +1000, Benjamin Herrenschmidt wrote:
I disagree. The driver will never know ...
? the driver has to know. Look at the 53c700 to see exactly how awful
it is. This beast has byte and word registers. When used BE, all the
byte registers alter their position (to both
On Fri, 2005-04-01 at 14:25 +0900, Tejun Heo wrote:
Ah.. with later requeue path consolidation patches, all requests get
their sense buffer cleared during requeueing, which, IMHO, is more
logical. Moving scsi_init_cmd_errh() should come after the patch.
Sorry. :-)
I'll make another take
OK, I sent the patch off to Andrew. To complete the original problem,
the attached is the patch that uses it in the parisc lasi driver
(although, actually, it sets up 53c700 to work everywhere including BE
on a LE system).
I changed some of the flags around to reflect the fact that we now have
On Tue, 2005-04-05 at 19:25 +0200, |TEcHNO| wrote:
This is my second attemp to make anyone notice the bug that is in the
2.6.x tree. While many people tried to put blame on nvidia, here's a log
that shows that it's purely kernel fault not to work.
At the end of this mail you can
On Tue, 2005-03-29 at 14:03 +0200, Jens Axboe wrote:
It is quite a serious problem, not just for CFQ. SCSI referencing is
badly broken there.
OK ... I accept that with regard to the queue lock.
However, rather than trying to work out a way to tie all the refcounted
objects together, what about
On Wed, 2005-04-06 at 12:00 -0400, Salyzyn, Mark wrote:
For some reason, sd_read_capacity (in sd.c) in the 2.6.9-5.EL (RHEL4)
kernel is not issuing the SERVICE_REQUEST_IN+SAI_READ_CAPACITY_16
command to the queuecommand handler (the handler is not even called),
even though it instruments up
On Wed, 2005-04-06 at 19:58 +0200, Jens Axboe wrote:
I rather like the queue lock being a pointer, so you can share at
whatever level you want. Lets not grow the request_queue a full lock
just to work around a bug elsewhere.
I'm not proposing that it not be a pointer, merely that it could be
On Wed, 2005-04-06 at 21:08 +0200, Jens Axboe wrote:
I think the correct model for all of this is that the block driver
shouldn't care (or be tied to) the scsi one. Thus, as long as SCSI can
reject requests from a queue whose device has been released (without
checking the device) then
On Thu, 2005-04-07 at 08:49 +0200, Jens Axboe wrote:
On Wed, Apr 06 2005, James Bottomley wrote:
My proposal is to correct this by moving the data back to the correct
object, and make any object using it hold a reference, so this would
make the provider of the block request_fn hold
On Thu, 2005-04-07 at 14:22 +0100, Christoph Hellwig wrote:
Do we really need the sdev_lock pointer? There's just a single place
where we're using it and the code would be much more clear if it had just
one name.
Humour me for a while. I don't believe we have any way the lock can be
used
On Thu, 2005-04-07 at 16:45 +0200, Jens Axboe wrote:
So clear -request_queue instead.
Will do. Did you want me to look after your patch and add this, or do
you want to send it to Linus (after the purdah is over)?
James
-
To unsubscribe from this list: send the line unsubscribe linux-scsi in
This patch is the beginning of the long process to see if we can make
this driver play better.
The first step is simply to attach it to the transport class so you can
view and set the transfer parameters.
Next, I intend to plug it into the generic domain validation routines
(thus killing the
On Mon, 2005-04-11 at 12:52 +0100, Christoph Hellwig wrote:
James once had a proposal where the scsi_host can link to the module in
sysfs, which is the right thing and needed for other things like mkinitrd
aswell.
The code is actually in. Taking advantage of it is slightly more
complex than I
The patch is pretty boring ... just removing heaps of unused stuff. The
diffstat is pretty interesting, though:
aic7xxx_osm.c | 1681 --
aic7xxx_osm.h | 40 -
2 files changed, 10 insertions(+), 1711 deletions(-)
James
=
We have a DID_IMM_RETRY to require a retry at once, but we could do with
a DID_REQUEUE to instruct the mid-layer to treat this command in the
same manner as QUEUE_FULL or BUSY (i.e. halt the submission until
another command returns ... or the queue pressure builds if there are no
outstanding
On Tue, 2005-04-05 at 14:30 -0600, Moore, Eric Dean wrote:
Ok fine - This fix is already there in the series of patches
I provided a week ago for splitting the mpt fusion drivers
into seperate bus type drivers.
James any word on whether those series of patches will get
approved?
The
On Wed, 2005-04-13 at 13:50 -0700, Andrew Vasquez wrote:
-#define QLA2XXX_VERSION 8.00.02b4-k
+#define QLA2XXX_VERSION 8.00.02b5-k
so, erm, removing about 4,000 lines of code and embracing a new
transport infrastructure doesn't even warrant a minor minor number
change in the driver
kernel-test.git) is here
rsync://www.parisc-linux.org/~jejb/scsi-rc-fixes-2.6.git
So let's see if you can apply it ;-)
The shortlog (ok, generated by BK) is
Andreas Herrmann:
o zfcp: convert to compat_ioctl
Douglas Gilbert:
o sg.c: update
James Bottomley:
o updates for CFQ oops fix
o
On Fri, 2005-04-15 at 19:13 +0900, Masao Fukuchi wrote:
The sequence is:
1.Host issues SCSI command to fusion MPT driver.
2.Mid layer detects command timeout and then performs
error recovery sequence.
But the sequence fails and it causes device offline.
(fusion MPT driver still hold
On Fri, 2005-04-15 at 10:11 -0600, Moore, Eric Dean wrote:
Thus I think its safe to say, we can remove the
scsi_device_online from mptscsih_flush_running_cmds.
Right??
Yes, as long as you now tear down all the outstanding commands while the
error handler is executing, you should be safe from
On Thu, 2005-04-14 at 08:39 -0400, [EMAIL PROTECTED] wrote:
We have been working with Christoph over the last few weeks to address
some last comments, and believe that this release is ready for
inclusion with the upstream kernel.
As Christoph said, you could have made my job quite a bit easier
On Sun, 2005-04-17 at 23:17 -0700, sai narasimhamurthy wrote:
I tried working on scsi_malloc to increase burst size
, but to no avail ..all I got was hanged system every
time I started data transfers!
Has anyone worked on scsi_malloc , I am still trying
to figure out what changes were made
On Mon, 2005-04-11 at 03:45 +0900, Tejun Heo wrote:
scmd-eh_timeout is used to resolve the race between command
completion and timeout. However, during error handling,
scsi_send_eh_cmnd uses scmd-eh_timeout. This creates a race
condition between eh and normal
On Tue, 2005-04-19 at 07:31 +0900, Tejun Heo wrote:
The original code also uses timer pending status as a signal that
command completed normally in scsi_eh_done() function, and the same
race also exists in the original code, no matter what we do, unless we
make timer expiration and removal of
On Mon, 2005-04-18 at 14:39 -0700, Linus Torvalds wrote:
Linus, the rc-fixes repo is ready for applying ... it's the same one I
announced on linux-scsi and lkml a while ago just with the git date
information updated to be correct (the misc one should wait until after
2.6.12 is final).
On Mon, 2005-04-18 at 17:03 -0700, Linus Torvalds wrote:
The patches from you I have in my tree are:
scsi: add DID_REQUEUE to the error handling
zfcp: add point-2-point support
[PATCH] Convert i2o to compat_ioctl
[PATCH] kill old EH constants
[PATCH] scsi:
On Mon, 2005-04-18 at 17:29 -0700, Linus Torvalds wrote:
2.6.12 is some time away, if for no other reason than the fact that this
SCM thing has obviously eaten two weeks of my time. So I'd be inclined to
chalk this up as a learning experience with git, and just go forward.
Fair enough. If
On Tue, 2005-04-19 at 10:29 +0100, Christoph Hellwig wrote:
Good question actually. I know XFS does passed vmalloc'ed memory down
the block I/O path, but that's as a scatter/gather request. All non-s/g
request should be contingous I think.
We really need to write down the rules about what
On Tue, 2005-04-19 at 14:34 +0200, Jens Axboe wrote:
On Mon, Apr 18 2005, Tejun Heo wrote:
And, James, regarding REQ_SOFTBARRIER, if the REQ_SOFTBARRIER thing can
be removed from SCSI midlayer, do you agree to change REQ_SPECIAL to
mean special requests? If so, I have three proposals.
On Wed, 2005-04-20 at 08:15 +0900, Tejun Heo wrote:
- * Insert this command at the head of the queue for it's device.
- * It will go before all other commands that are already in the queue.
- *
- * NOTE: there is magic here about the way the queue is plugged if
- * we
On Thu, 2005-04-21 at 09:20 +0900, Tejun Heo wrote:
Hello, James.
James Bottomley wrote:
On Wed, 2005-04-20 at 08:15 +0900, Tejun Heo wrote:
-* Insert this command at the head of the queue for it's device.
-* It will go before all other commands that are already in the queue
On Thu, 2005-04-21 at 08:10 +0200, Jens Axboe wrote:
I wondered about this action recently myself. What is the point in
requeueing this request, only to call scsi_run_queue() -
blk_run_queue() - issue same request. If the point really is to reissue
the request immediately, I can think of many
1 - 100 of 2722 matches
Mail list logo
