> I'm struggling a bit to work out if this is a scsi bug, a USB bug, an MMC bug
> or whatever. But it's a bug.
>
> Michal, can you please track this as a post-2.6.22 regression?
>
> Others: can you please take a look at the dmesg output, see if we can work
> out which subsystem is (newly) failin
On Sun, 2006-02-19 at 08:30 -0600, James Bottomley wrote:
> Yes, thanks ... although I think there's still value to wrappering
> work_struct (a bit like kref wrappers atomic_t).
OK, so how about this?
James
[PATCH] add execute_in_process_context() API
We have several points in the
On Sat, 2006-02-18 at 15:16 -0500, Alan Stern wrote:
> The test should be in_atomic(), not in_interrupt().
There's a long prior discussion of why it has to be in_interrupt()
James
---
This SF.net email is sponsored by: Splunk Inc. Do you gre
On Sat, 2006-02-18 at 13:03 +0300, Sergey Vlasov wrote:
> After removing kfree(), which was here in the initial implementation,
> this function became a thunk which does nothing useful - we can just
> stick fn and data directly into work_struct.
Yes, thanks ... although I think there's still value
gets around the issue by executing the function directly if
the caller has process context, but scheduling a workqueue to execute
in process context if the caller doesn't have it.
Signed-off-by: James Bottomley <[EMAIL PROTECTED]>
Index: BUI
On Thu, 2006-02-16 at 17:12 +, Russell King wrote:
> This is probably an idiotic question, but if there's something in the
> scsi release handler can't be called in non-process context, why can't
> scsi queue up the release processing via the work API itself, rather
> than having to have this a
On Thu, 2006-02-16 at 18:09 +, Russell King wrote:
> where scsi_release() is the function called by the device model on the
> last put of a scsi device.
>
> I guess is more or less what you're trying to do invasively via the
> driver model.
Yes ... except I think more than just SCSI has the p
On Thu, 2006-02-16 at 18:18 +, Russell King wrote:
> Maybe implementing it as a helper function would be the best and
> simplest solution?
>
> static void scsi_release(struct device *dev)
> {
> schedule_release_process(dev, scsi_release_process);
> }
>
> where schedule_release_process()
On Tue, 2006-02-14 at 10:34 -0600, James Bottomley wrote:
> Well, I can't solve the problem that it requires memory allocation from
> IRQ context to operate. Based on that, it's an unsafe interface. I'm
> going to put it inside SCSI for 2.6.16, since it's better t
On Mon, 2006-02-13 at 12:38 -0800, Greg KH wrote:
> > - Nasty warnings from scsi about kobject-layer things being called
> from
> > irq context. James has a push-it-to-process-context patch which
> sadly
> > assumes kmalloc() is immortal, but no other fix seems to have
> offered
> > itself.
On Sun, 2006-02-12 at 19:05 -0800, Andrew Morton wrote:
> - The scsi_cmd leak, which I don't think is fixed.
Erm, you mean the leak caused by flush barriers? That was verified as
fixed (albeit accidentally) in 2.6.16-rc1.
James
---
This SF.
On Thu, 2006-01-12 at 18:36 -0500, Dave Jones wrote:
> > SCSI device sdb: 321672960 512-byte hdwr sectors (164697 MB)
> > slab error in cache_free_debugcheck(): cache `sgpool-8': double free, or
> > memory outside object was overwritten
> > [] cache_free_debugcheck+0x1ab/0x22f []
> >
On Tue, 2005-11-08 at 13:33 -0800, Patrick Mansfield wrote:
> I mean we get a ref to the sdev in the upper level driver opens, scan, and
> sd flush. So where are we not getting a ref?
>
> Shouldn't the get be done at a higher level?
Actually, no, because of the way we run the queues for the next
On Tue, 2005-11-08 at 15:02 -0500, goggin, edward wrote:
> Thanks! Here's a better one.
It's line wrapped, but I fixed that up.
James
---
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Down
On Tue, 2005-11-08 at 11:24 -0500, goggin, edward wrote:
> ! struct scsi_device *sdev = cmd->device;
> ! struct request_queue *q = sdev->request_queue;
> !
> ! // need to hold a reference on the device before we let go of the
> cmd
> ! if (scsi_device_get(sdev)) {
> ! s
On Sun, 2005-09-18 at 15:01 -0700, Greg KH wrote:
> Should I apply any additional patches too? Or just this one will
> suffice?
Just to make assurances doubly sure, could you remove all the scsi
patches and just pull the scsi git tree at
master.kernel.org:/pub/scm/linux/kernel/git/jejb/scsi-rc-f
On Sat, 2005-09-17 at 19:35 -0500, James Bottomley wrote:
> The attached should be that patch with the race window closed.
There's a big oops in this one (and there was when greg tested it). The
state checker is reversed (it's checking !scsi_host_set_state() for
indicating a p
On Sat, 2005-09-17 at 22:33 -0400, Alan Stern wrote:
> > OK, I looked at making this work while reaping the target correctly, but
> > I couldn't (basic problem is that the target list keeps the target until
> > it has no more devices, a condition that could be made untrue by
> > something as simple
On Thu, 2005-09-15 at 21:52 -0400, Alan Stern wrote:
> In short, those iterations must be carried out as in my patch.
OK, I looked at making this work while reaping the target correctly, but
I couldn't (basic problem is that the target list keeps the target until
it has no more devices, a conditio
On Thu, 2005-09-15 at 18:38 -0400, James Bottomley wrote:
> On Thu, 2005-09-15 at 15:19 -0700, Mike Anderson wrote:
> > In looking at the state model introduced by your patch I believe there may
> > still be a state model race issue if the recovery completes just af
On Thu, 2005-09-15 at 21:52 -0400, Alan Stern wrote:
> You're forgetting something: Devices can be removed at any time, no matter
> what state the host is in. It's even possible for thread A to be removing
> a device while thread B is removing the host. The A thread will interfere
> with the B th
On Thu, 2005-09-15 at 16:55 -0700, Mike Anderson wrote:
> James Bottomley <[EMAIL PROTECTED]> wrote:
> > On Thu, 2005-09-15 at 15:19 -0700, Mike Anderson wrote:
> > > A side effect of not applying Alan's previous patch that added
> > > SHOST_RECOVERY to the S
On Thu, 2005-09-15 at 15:19 -0700, Mike Anderson wrote:
> A side effect of not applying Alan's previous patch that added
> SHOST_RECOVERY to the SHOST_CANCEL: state is that we will not move to the
> SHOST_CANCEL and subsequently not to SHOST_DEL state if the eh is active
> during the start of scsi_
On Thu, 2005-09-15 at 15:57 -0400, James Bottomley wrote:
> I haven't had time to review the eh changes, but I was going to reply to
> the other one (basically there's a better way to try to close the device
> add/host remove race using the host state model).
>
> Let me
On Thu, 2005-09-15 at 12:29 -0700, Greg KH wrote:
> Ah, thanks for the pointer. SCSI developers, any objections to these
> patches being merged?
I haven't had time to review the eh changes, but I was going to reply to
the other one (basically there's a better way to try to close the device
add/ho
On Tue, 2005-08-16 at 21:20 +0200, Marko Macek wrote:
> EIP is at sysfs_hash_and_remove+0x13/0xeb
This is suspiciously similar to the oops when trying to add new class
links in the devices. Could you try the fix reported there:
http://marc.theaimsgroup.com/?l=linux-scsi&m=112398346008284
And se
On Wed, 2005-01-05 at 00:14 -0800, Andrew Morton wrote:
> Looks like the scsi-vs-usb-storage bunfight isn't yet settled...
Actually, this one looks pretty clear cut:
According to the trace, we get into error handling for a removed device.
This:
> RIP {:usb_storage:bus_reset+66} RSP <01002f9a
On Mon, 2004-11-29 at 18:32, Andrew Morton wrote:
> Pete Zaitcev <[EMAIL PROTECTED]> wrote:
> >
> > On Fri, 19 Nov 2004 00:42:40 +0100, Fabio Coatti <[EMAIL PROTECTED]> wrote:
> >
> > > Nov 18 20:33:05 kefk kernel: sdb: assuming drive cache: write through
> > > Nov 18 20:33:05 kefk kernel: sdb: s
On Mon, 2004-11-15 at 23:28, Andrew Morton wrote:
> So I made the mistake of forgetting to unmount the fat filesytem before
> unplugging the USB cable from the digital camera. I then tried to unmount
> the old mountpoint. khubd is sitting there chewing 100% CPU and I have a
> reboot in my near fu
On Wed, 2004-10-27 at 01:02, Douglas Gilbert wrote:
> I have been seeing an oops (or badness) since about the lk 2.5
> series if I left my USB Sandisk CF (ImageMate) plug in with a
> mounted file system open when I halted the machine. As the logs
> had already been closed down there was nothing cap
On Tue, 2004-10-26 at 14:08, Mike Christie wrote:
> > The null state and and oops are becuase of this
> > http://marc.theaimsgroup.com/?l=linux-scsi&m=109733573729283&w=2
>
> Oh yeah. that patch is not correct, but if you correctly modify it to
> use device_for_each_child per Christoph's suggestio
On Mon, 2004-10-11 at 04:50, Jens Axboe wrote:
> It's not, it clearly looks like SCSI trying to kill off the queue
> with pending commands.
That's what it looks like to me too ... there should be a fix for this
in the scsi-misc-2.6 tree.
James
-
On Thu, 2004-09-30 at 00:02, Andrew Morton wrote:
> Is anyone else getting a bit bored of this bug?
The fix should be in the scsi-misc-2.6 tree (although I still haven't
had confirmation from anyone):
[EMAIL PROTECTED], 2004-09-29 11:22:30-04:00, [EMAIL PROTECTED](none)
Add refcounting to scsi
On Sun, 2004-09-26 at 18:05, James Bottomley wrote:
> There's not enough information to say why it happened. However, all the
> SCSI code checks out (it's dated ... open coded reference counting
> instead of kref, but it looks sound). The scenario described could be
> see
On Fri, 2004-05-14 at 14:33, Alan Stern wrote:
> usb-storage checks the state of its kernel thread after calling
> scsi_remove_host(), while preparing to kill the thread. This can only
> be done while the thread is idle, not processing any queued commands or
> error handler requests. The BUG in A
On Thu, 2004-04-08 at 18:06, Greg KH wrote:
> Why not just use a kref for this? That's what they were created for?
> :)
Heh, I was waiting for you to say that. Took you five days to notice,
though
I'll convert both sr and sd to use krefs.
James
On Tue, 2004-04-06 at 11:55, Alan Stern wrote:
> In principle, yes. However... The kernel still has to process requests
> correctly while the stack is partially deconstructed. It also has to
> protect against userland helpers trying to pull things apart in the wrong
> order.
This I agree wit
On Tue, 2004-04-06 at 10:10, David Brownell wrote:
> James Bottomley wrote:
> > that's intra subsystem synchronisation, not inter subsystem
>
> I'd say that device_driver.remove() calls from the bus management
> code to a given device driver are inter-subsystem...
s
On Tue, 2004-04-06 at 09:04, Jens Axboe wrote:
> Only change is the err -> error, correct?
Not quite; there was a cleanup goto issue as well (don't want to goto
the release if you couldn't get the object).
> > The attached (hopefully) is what I compiled and tested with. The test,
> > incidentall
-04-05 at 20:19, James Bottomley wrote:
> Now, if the subsystem is going to garbage collect its own object as a
> result of the other object disconnect, then it is responsible for
> synchronising that with reference gets on its own object. However, that
> is easily achievable
On Tue, 2004-04-06 at 04:22, Jens Axboe wrote:
> Really? It doesn't even compile :-)
Heh, I really must learn that I have to copy the file from the test
machine to the email machine *before* attaching it. You got a stale
copy of an older incarnation, I think.
The attached (hopefully) is what I c
On Mon, 2004-04-05 at 18:23, David Brownell wrote:
> "Irrelevant" is pointlessly strong, even for what I'm guessing
> you really mean to be saying.
No, it's the very point.
If we have to enforce ordering on the event propagation across
subsystems, that can't be done without inter subsystem synchr
On Sun, 2004-04-04 at 22:54, David Brownell wrote:
> Which directly follows from what I said ... USB propagates
> that knowledge in carefully defined ways. Other layers can
> do the same, although clearly state associated with open file
> descriptors needs to use a slightly different strategy. A
On Sun, 2004-04-04 at 22:17, Alan Stern wrote:
> On 4 Apr 2004, James Bottomley wrote:
> > On Sun, 2004-04-04 at 12:46, Alan Stern wrote:
> > > Ah, you have left out the third, bad alternative: open succeeds, user gets
> > > an fd that points to a deallocated
On Sun, 2004-04-04 at 23:33, Patrick Mansfield wrote:
> How is unregister_cdrom(&cd->cdi) called if the device is not open?
OK, the attached does everything correctly (as I should have done at
first) by using a kobject to hold the compound references.
I've stressed this one nicely. Unfortunately
On Mon, 2004-04-05 at 09:03, Jens Axboe wrote:
> Doesn't quite work, how about something like this as a work-around?
I'm not sure we want to be introducing yet another refcount. What was
the problem?
James
---
This SF.Net email is sponsored
On Sun, 2004-04-04 at 23:33, Patrick Mansfield wrote:
> How is unregister_cdrom(&cd->cdi) called if the device is not open?
Yes, I need to pull the same kobject trick that sd does for the same
reason.
James
---
This SF.Net email is sponsored
re to prevent that
> raciness from making trouble ... closing windows from the bottom up.
So you dispute this assertion in the email you quoted above:
On Sun, 2004-04-04 at 14:16, David Brownell wrote:
> James Bottomley wrote:
> > Since we cannot solve that
> > race, there's
On Sun, 2004-04-04 at 12:46, Alan Stern wrote:
> Ah, you have left out the third, bad alternative: open succeeds, user gets
> an fd that points to a deallocated device. More details below...
No, that would be a bug. I'm looking for evidence that such a bug exists
in sd.
> Let's consider a simpl
On Sat, 2004-04-03 at 20:40, Alan Stern wrote:
> Without having looked recently in any detail at the specific code in sd.c
> or sr.c, I want to comment in general terms on the nature of the
> open/disconnect race.
>
> It's a generic problem that affects every driver whose devices can be
> opened t
On Fri, 2004-04-02 at 18:40, Mike Anderson wrote:
> Greg stopped by and after talking this over I think I see why sd is
> racing in its current form. The race happens when sd_remove and do_open
> race. Even though I do not like adding a lock_kernel it would appear
> adding on to sd_remove would ser
On Fri, 2004-04-02 at 19:11, Mike Anderson wrote:
> It looks like cdrom_release always returns 0? Is there some other patch
> outstanding that changes this.
Yes, not that I know of.
However, while it apparently has a return code indicating success or
failure, we should respect it [unless Jens wan
On Thu, 2004-04-01 at 18:32, James Bottomley wrote:
> Now, the questions are, whose issue is this and how do we fix it? I can
> see that a driver needs early notification of unplugs so it can deny all
> access to a gone device. On the other hand, for a user land open where
> we s
On Fri, 2004-04-02 at 12:44, Mike Anderson wrote:
> Where does the last put come from? How do you close the open race or
> know when the final put_disk has been called? SCSI cannot do this alone
> as we have created and registered an object in another subsystem
> (alloc_disk and add_disk) and we ha
On Fri, 2004-04-02 at 11:45, Mike Anderson wrote:
> Maybe some clarification here as I am unsure if we both think there
> needs to be a notification (a put call) from outside SCSI. We have
> release functions available on most objects in SCSI now. The issue is
> that when we register (add_disk, dev
On Fri, 2004-04-02 at 03:43, Mike Anderson wrote:
> I have looked at the sd issue off and on due to the previous open race
> reported by Alan Stern. While the window can be narrowed inside SCSI you
> need help for the calling subsystem to know when it is OK to cleanup and
> your routine will not be
On Thu, 2004-04-01 at 16:15, Andrew Morton wrote:
> Apparently there is some controversy over whether this:
> http://bugme.osdl.org/show_bug.cgi?id=2400 is a usb-storage problem or a
> SCSI problem.
Well, I know why this happens, but I'm not entirely clear how to fix it.
The problem comes because
On Thu, 2004-04-01 at 16:52, Matt Gulick wrote:
> Where you will get into trouble is that SCSI is not considered to be a
> 'Dynamic' bus. Devices do not normally come and go, while USB and 1394
> devices are 'Hot Plugable'.
It isn't? considering all the refcounting work that's gone into the SCSI
On Mon, 2004-02-09 at 11:40, Alan Stern wrote:
> In the absence of anything better, we're forced to assume "bad" status
> corresponds to Check Condition...
>
> What do you think, Matt? Should we remove the auto-sense for short
> transfers when we get "good" status? Bearing in mind that it's
>
On Fri, 2004-02-06 at 09:59, Alan Stern wrote:
> Who says it's wrong to retrieve sense information when there is an
> underrun but not Check Condition? Can you provide a reference to a
> published (or draft) document that states this?
It's not wrong according to the SCSI standards, a REQUEST SENS
On Mon, 2004-01-05 at 16:58, Alan Stern wrote:
> = st.c 1.45 vs edited =
> --- 1.45/drivers/scsi/st.cFri Sep 5 12:16:40 2003
> +++ edited/drivers/scsi/st.c Fri Nov 21 12:30:34 2003
> @@ -1267,7 +1267,8 @@
> i = STp->try_dio && try_rdio;
> else
> i = S
On Fri, 2004-01-16 at 16:27, Mike Anderson wrote:
> This matches what I thought should be added to sd, but I did not hear an
> answer from James / others if this is the way we should handle it.
Actually, perhaps we should treat it *exactly* the same as
RECOVERED_ERROR (i.e. do the print_sense) so
I've been thinking some more about this. Although the driver is
apparently at fault here by issuing a reset without telling the
mid-layer, it might be useful to filter out other common ASC/ASCQ codes
in scsi_io_completion() we retry on "in the process of becoming ready",
then for any other UNIT_AT
On Mon, 2003-12-15 at 15:49, Alan Stern wrote:
> Cornelius Claussen reported the following problem with error recovery in
> 2.6.0-test11. His device is one of those problem-prone Genesys Logic
> units, a USB DVD drive. The complete message and log can be found at
It looks like the driver sent a
On Wed, 2003-11-19 at 08:39, Jens Axboe wrote:
> > but, regardless, the queue is already set up (for all devices, including
> > st) in either slave_alloc, or slave_configure, so you could call the
> > alignment setting routine there.
>
> That was my point, yes.
I know, just driving it home. I'll
On Wed, 2003-11-19 at 07:04, Jens Axboe wrote:
> On Wed, Nov 19 2003, Oliver Neukum wrote:
> >
> > > > You could add a scsi_host fields or bits specifying alignment
> > > > restrictions, and enforce them as needed in upper level drivers.
> > >
> > > The queue already has such a restriction embedd
On Wed, 2003-10-29 at 09:24, Alan Stern wrote:
> > no matter which USB-storage-device I attach (tried CD-ROM,
> > Flash Card Reader and memory stick) I get a new scsi host
> > every time i plug a device in.
> >
> > so when changing devices for several times I finally end up
> > with /dev/scsi/hos
On Fri, 2003-10-03 at 09:18, Alan Stern wrote:
> There haven't been any replies to my suggestion from a week ago
>
> http://marc.theaimsgroup.com/?l=linux-scsi&m=106462295800726&w=2
>
> for a way to resolve the mode-sense page 8 problem. One way or another, I
> wish somebody would do _something
On Tue, 2003-09-23 at 10:23, Alan Stern wrote:
> Is there any way to notify the system that you are about to unplug a
> drive? It seems to me that the best approach is to flush the cache on an
> unmount. People naturally assume that it's safe to unplug a device once
> it has been unmounted, a
On Tue, 2003-09-23 at 09:37, [EMAIL PROTECTED] wrote:
> No, the design goal of "hot-pluggable" is that it indicates that
> the device can disappear any moment. Nothing at all about SCSI
> compliance.
Actually, then, these are two issues...hotplug is being worked on
separately at the moment.
I tho
On Mon, 2003-09-22 at 14:56, [EMAIL PROTECTED] wrote:
> I have seen proposals around here for flags that are far too specific
> (like "do not ask for mode page 8"). If we go to that level of detail
> then we'll soon have fifty flags.
> Black lists, and flags that describe various ways of being brok
On Mon, 2003-09-22 at 13:55, [EMAIL PROTECTED] wrote:
> if (sdkp->media_present) {
> sd_read_capacity(sdkp, disk->disk_name, sreq, buffer);
> if (sdp->removable)
> sd_read_write_protect_flag(sdkp, disk->disk_name,
>
On Mon, 2003-09-22 at 12:41, Linus Torvalds wrote:
> Ok, thanks. In particular, it seems to be pointless to read anything past
> byte 20 - nothing past there is even defined.
>
> What's the general sense of things - for a random SCSI device with bugs
> (and they all have _some_ sort of bugs, let
On Sun, 2003-06-22 at 16:06, Matthew Dharm wrote:
> The problem as I see it is ATAPI devices. That means that sbp2, ide-scsi,
> and usb-storage (all of which bridge ATAPI devices to the SCSI layer) will
> be affected. These devices don't include the DBD bit in their command
> specification -- the
On Sun, 2003-06-22 at 14:56, Matthew Dharm wrote:
> > But (as I read it -- remember I'm not an expert), the old sr.c code didn't
> > set the DBD bit, just like the new code. So whatever formula applied to
> > the old code should apply to the new code, yes?
Hmm, the diff I sent was an older one wh
On Sat, 2003-06-21 at 23:24, Matthew Dharm wrote:
> On Sat, Jun 21, 2003 at 09:54:46PM -0500, James Bottomley wrote:
> > }
> > - n = buffer[3] + 4;
> > + n = rc;
> > cd->cdi.speed = ((buffer[n + 8] << 8) + buffer[n + 9]) / 176;
>
> This bit i
On Sat, 2003-06-21 at 19:46, Matthew Dharm wrote:
> Since you seem to have a handle on this, can you fix it?
OK, try the attached. I abstracted out the mode_sense routines into the
SCSI function library. It now employs the correct retry policy and
sweeps up several bugs in the sd.c and sr.c use
In general, you would have been a bit better off just doing a
if(cd->device->use_10_for_ms) {
cgc.cmd[0] = MODE_SENSE_10;
cgc.cmd[8] = 128;
} else {
cdc.cmd[0] = MODE_SENSE;
cgc.cmd[4] = 128;
}
Rather than dup
On Sat, 2003-04-05 at 13:55, Matthew Dharm wrote:
>
> My big complaint about that is that it's ugly. I would like to keep the
> device type as part of the filter command structure, so I can keep the call
> to scsi_filter_cmd() simple and easy to maintain. Maybe it's just me, but
> I think that e
On Sat, 2003-04-05 at 13:27, Matthew Dharm wrote:
> I don't think this will work. I see two problems:
>
> (1) You can't filter TEST_UNIT_READY (opcode 0). Not a big deal, but a
> theoretical problem.
Yes, TUR has been mandatory since SCSI-1, so I didn't think this would
be a problem. Any end s
On Mon, 2003-03-24 at 11:30, Matthew Dharm wrote:
> On Mon, Mar 24, 2003 at 09:15:57AM -0600, James Bottomley wrote:
> > OK, I can do this: A simple one with either a blacklist (reject these
> > commands) or whitelist (only accept these commands) going by the first
> > comma
On Mon, 2003-03-24 at 10:29, Linus Torvalds wrote:
> Really? The code was _supposed_ to always start off with READ/WRITE_10's,
> and then fall back to the old READ/WRITE_6 if it gets errors from that. Do
> we really have some broken random-number generator semantic still in teh
> SCSI layer? That
On Mon, 2003-03-24 at 10:52, Jens Axboe wrote:
> It's not true, ->ten is set unconditionally and we only fall back to 6
> byte cdb's if we see an ILLEGAL_REQUEST on a READ_10/WRITE_10.
>
> So the logic is, always assume 10-byte commands. If an incoming request
> cannot be addressed with 10-byte co
On Mon, 2003-03-24 at 01:04, Matthew Dharm wrote:
> Well, here's my list of what the 'popular OS' uses for all devices:
>
> INQUIRY (for only 36 bytes -- nothing else!)
> TEST_UNIT_READY
> REQUEST_SENSE
> ALLOW_MEDIUM_REMOVAL (mostly for eject purposes)
>
> For disk-like media:
>
> READ_10
> WRI
On Sun, 2003-03-23 at 01:31, Matthew Dharm wrote:
> The problem is this: usb-storage interfaces via SCSI, but not just for
> disks. Tape, CD, etc. are all handled with the same protocol. Heck, ATAPI
> disk/cd/tape are handled with these code paths.
ATAPI isn't really "emulated" in the sense tha
[EMAIL PROTECTED] said:
> Providing you refcount objects and defer freeing of resources its not
> normally too terrible
We already have a struct device, which is a ref counted object precisely for
this purpose, embedded inside Scsi_Device.
One of the issues doing this is fast reattachment: the
[EMAIL PROTECTED] said:
> Will look a bit more at the details later. For now a question: this
> call does a MODE_SENSE with the DBD (disable block descriptors) bit
> set. Is there a reason for that? Wouldn't the same code work in the
> same way without that bit?
The reason was just least line of
[EMAIL PROTECTED] said:
> bytes_got = max(bytes_requested - cmd->resid, 0);
[...]
> /* let's rely on the transport to have correctly set */
> /* cmd->resid and report a broken device server */
>
I'm afraid that for a large number of HBAs in the tree SCpnt->resid just isn
Since we already have a huge long list of different ways to identify different
devices, I don't think coding any one or even a set of such methods into the
kernel would satisfy everyone.
What about a different approach:
We already (nearly) have the scsimon patches to do hot plug events on SCSI
89 matches
Mail list logo
