From: Christoph Hellwig <[EMAIL PROTECTED]>
Date: Tue, 19 Jun 2007 07:56:29 +0200
> A SCSI pass through is of course perfectly fine. If you have a separate
> block passthrough that has additional magic a separate block driver is
> the way to go because it actually is simpler than a scsi driver de
From: Christoph Hellwig <[EMAIL PROTECTED]>
Date: Tue, 19 Jun 2007 07:53:58 +0200
> On Fri, Jun 15, 2007 at 02:19:17PM -0700, David Miller wrote:
> > Another quirk I have to deal with is that under LDOMs you
> > can export full disks and also just slices. So I'll have
> > to get down into the par
On Fri, Jun 15, 2007 at 04:08:58PM -0700, David Miller wrote:
> That's not gonna work, it's a totally different model.
>
> I have a predefined protocol over hypervisor provided "channels" and
> page flipping also done by the hypervisor for the bulk data transfer.
> For the client side I cannot cha
On Fri, Jun 15, 2007 at 02:19:17PM -0700, David Miller wrote:
> Another quirk I have to deal with is that under LDOMs you
> can export full disks and also just slices. So I'll have
> to get down into the partition machinery to support that
> somehow.
What's the problem with that? Partition machi
Looks pretty nice.
Some more comments:
- no need for the BLK_DEV_SR dependency, it should depend on SCSI
instead (which might be implied by beeing in the scsi menu, don't
remember that detail)
- ps3rom_priv should probably be an inline
- the cmd field in struct ps3rom_private should pro
On Fri, Jun 15, 2007 at 01:39:23PM +0200, Geert Uytterhoeven wrote:
> From: Geert Uytterhoeven <[EMAIL PROTECTED]>
>
> Add a Disk Storage Driver for the PS3:
> - Implemented as a block device driver with a dynamic major
> - Disk names (and partitions) are of the format ps3d%c(%u)
> - Uses so
From: Mike Christie <[EMAIL PROTECTED]>
Subject: Re: [PATCH 2/2] iscsi_iser: convert to use the data buffer accessors
Date: Mon, 18 Jun 2007 13:07:19 -0500
> FUJITA Tomonori wrote:
> > From: Erez Zilber <[EMAIL PROTECTED]>
> > Subject: Re: [PATCH 2/2] iscsi_iser: convert to use the data buffer
>
Kristian Høgsberg wrote:
> You're doing the multi-LU work?
I expect to do it at next weekend.
--
Stefan Richter
-=-=-=== -==- =--=-
http://arcgraph.de/sr/
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
More majordomo info
Kristian Høgsberg wrote:
> On 6/18/07, Stefan Richter <[EMAIL PROTECTED]> wrote:
...
>> + scsi_remove_host(host);
>> sbp2_send_management_orb(sd->unit, sd->node_id, sd->generation,
>> SBP2_LOGOUT_REQUEST, sd->login_id, NULL);
>> -
>> - scsi_remov
FUJITA Tomonori wrote:
> From: Erez Zilber <[EMAIL PROTECTED]>
> Subject: Re: [PATCH 2/2] iscsi_iser: convert to use the data buffer accessors
> Date: Sun, 03 Jun 2007 16:56:47 +0300
>
>> FUJITA Tomonori wrote:
>>
>>> iscsi_iser: convert to use the data buffer accessors
>>>
>>> - remove the unnece
On 6/18/07, Stefan Richter <[EMAIL PROTECTED]> wrote:
I wrote:
...
> - retval = scsi_add_device(host, 0, 0, lun);
> - if (retval < 0) {
> + sdev = __scsi_add_device(host, 0, 0, lun, sd);
> + if (IS_ERR(sdev)) {
We could also stick with scsi_add_device here, omit also the rest of
I wrote:
...
> - retval = scsi_add_device(host, 0, 0, lun);
> - if (retval < 0) {
> + sdev = __scsi_add_device(host, 0, 0, lun, sd);
> + if (IS_ERR(sdev)) {
We could also stick with scsi_add_device here, omit also the rest of
thechanges to sbp2_login(), and set sdev->hostdata later
to simplify a few pointer expressions.
Signed-off-by: Stefan Richter <[EMAIL PROTECTED]>
---
Update: adapt to changes in preceding patch
drivers/firewire/fw-sbp2.c | 25 +
1 file changed, 13 insertions(+), 12 deletions(-)
Index: linux/drivers/firewire/fw-sbp2.c
=
This affects of course only the "soft shutdown" case, e.g. "modprobe -r
firewire-sbp2", while it doesn't matter for hot unplug.
Signed-off-by: Stefan Richter <[EMAIL PROTECTED]>
---
Update:
- Do it much simpler without scsi_remove_device.
- Omit the unrelated sbp2_sysfs_ieee1394_id_show hunks
Vivek wrote:
>
> I think this is not the right usage of reset_devices
> parameter. This parameter instructs the driver to reset the
> device before going ahead with rest of the initialization
> before as underlying device might not be in a sane state.
> kexec/kdump is one of the usages and t
Kristian Høgsberg wrote:
> On Sun, 2007-06-17 at 23:52 +0200, Stefan Richter wrote:
>> This affects of course only the "soft shutdown" case, e.g. "modprobe
>> -r
>> firewire-sbp2", while it doesn't matter for hot unplug.
>
> Isn't this done when we remove the host?
Yes, we only need to defer the
On Sun, 2007-06-17 at 23:55 +0200, Stefan Richter wrote:
> Signed-off-by: Stefan Richter <[EMAIL PROTECTED]>
> ---
> drivers/firewire/fw-sbp2.c | 22 +++---
> 1 file changed, 15 insertions(+), 7 deletions(-)
Looks good to me.
Signed-off-by: Kristian Høgsberg <[EMAIL PROTECTED]>
On Sun, 2007-06-17 at 23:52 +0200, Stefan Richter wrote:
> This affects of course only the "soft shutdown" case, e.g. "modprobe
> -r
> firewire-sbp2", while it doesn't matter for hot unplug.
Isn't this done when we remove the host?
Kristian
-
To unsubscribe from this list: send the line "unsubs
FUJITA Tomonori wrote:
>> Boaz Harrosh wrote:
>> Hi Tomo.
>>
>> I do not understand.
>> - Do you not accept my first patch. This is to go in now for 2.6.23.
>> It is for protection against out-of-tree and the rest of the not
>> converted drivers. To not use new accessors as l-value.
>>
>> -
On Mon, 2007-06-18 at 15:56 +0200, Heiko Carstens wrote:
> One of my current disks has an FCP LUN of 0x401040ba... That's just
That's correct and coped with ... SCSI LUNs are BE ... this is still
only a four byte lun ... it actually says Flat Space addressing, 2 level
LUN: 16-168
> the li
From: Boaz Harrosh <[EMAIL PROTECTED]>
Subject: Re: [PATCH 0/0] scsi_cmnd accessors issues
Date: Sun, 17 Jun 2007 12:45:17 +0300
> Boaz Harrosh wrote:
> > FUJITA Tomonori wrote:
> >> There are just two llds. I suspect that we can fix them. Or they can
> >> access to the data directly (without the
Now that we're stabilising, this is a simple push of two (fairly
critical) bug fixes. You can get it from:
master.kernel.org:/pub/scm/linux/kernel/git/jejb/scsi-rc-fixes-2.6.git
The changelog is:
commit 204abf28679cd55a8e254b18965583bb1c8bc739
Author: Thomas Bogendoerfer <[EMAIL PROTECTED]>
Dat
On Mon, Jun 18, 2007 at 10:47:28AM +0200, Hannes Reinecke wrote:
> James Bottomley wrote:
> > On Tue, 2007-05-29 at 15:29 +0200, Swen Schillig wrote:
> >> From: Christof Schmitt <[EMAIL PROTECTED]>
> >>
> >> zfcp reported units to the SCSI stack starting
> >> with number 0. LUN 0 reported to the S
On Monday 18 June 2007 10:47, Hannes Reinecke wrote:
> James Bottomley wrote:
> > On Tue, 2007-05-29 at 15:29 +0200, Swen Schillig wrote:
> >> From: Christof Schmitt <[EMAIL PROTECTED]>
> >>
> >> zfcp reported units to the SCSI stack starting
> >> with number 0. LUN 0 reported to the SCSI stack is
From: Erez Zilber <[EMAIL PROTECTED]>
Subject: Re: [PATCH 2/2] iscsi_iser: convert to use the data buffer accessors
Date: Sun, 03 Jun 2007 16:56:47 +0300
> FUJITA Tomonori wrote:
>
> >
> > iscsi_iser: convert to use the data buffer accessors
> >
> > - remove the unnecessary map_single path.
> >
>
Hi
I wonder if somebody could advice me. I am a SCSI LLDD developer.
I have a question about an implementation of eh_abort_handler()
for SCSI hosts when SCSI command timer is fired. I may check out
the queue and look for a command given as an argument to abort.
But, what I should do when the com
scsi_sysfs_add_sdev() should not modify the sdev state as it doesn't
require any hardware access. And we should take care to retrace our
steps on failure.
Signed-off-by: Hannes Reinecke <[EMAIL PROTECTED]>
---
drivers/scsi/scsi_sysfs.c | 25 +++--
1 files changed, 11 insert
sdev state SDEV_DEL should only be entered from SDEV_CANCEL. This way
we'll have a better check if all error paths are covered.
And we should always call scsi_destroy_device() after
scsi_sysfs_remove_sdev().
Signed-off-by: Hannes Reinecke <[EMAIL PROTECTED]>
---
drivers/scsi/scsi_scan.c | 11 +
scsi_destroy_sdev() is now obsolete. Delete it.
Signed-off-by: Hannes Reinecke <[EMAIL PROTECTED]>
---
drivers/scsi/scsi_scan.c |8
1 files changed, 0 insertions(+), 8 deletions(-)
diff --git a/drivers/scsi/scsi_scan.c b/drivers/scsi/scsi_scan.c
index d1bca80..bf62089 100644
--- a/
This patch implements a function scsi_resurrect_device()
which elevates a sdev from state SDEV_CANCEL back into
SDEV_RUNNING.
So during a scan any sdev in SDEV_DEL is put into
SDEV_CANCEL and then scsi_resurrect_device() is called.
This will put the device into SDEV_RUNNING and the scan
can procee
This patch implements scsi_configure_device(). This function
elevates an sdev into SDEV_RUNNING and configures it properly so that
I/O is possible on the device.
Signed-off-by: Hannes Reinecke <[EMAIL PROTECTED]>
---
drivers/scsi/scsi_scan.c | 67 +
For a clean teardown of a sdev the class device should
really be freed from the sdev's release function.
This way we don't have to worry about refcounting the
class device structures itself.
And the functions are now better aligned with the sdev
state model; _scsi_remove_device() transitions the s
__scsi_remove_device() is actually the counterpart to
scsi_sysfs_add_sdev(). So we'd better rename it to avoid
confusion.
Signed-off-by: Hannes Reinecke <[EMAIL PROTECTED]>
---
drivers/scsi/scsi_priv.h |2 +-
drivers/scsi/scsi_scan.c |4 ++--
drivers/scsi/scsi_sysfs.c | 10 +-
In one obscure error path someone decided to do a put_device()
on the sdev parent.
As this is the only reference to it I don't thing it makes much sense.
Remove it.
Signed-off-by: Hannes Reinecke <[EMAIL PROTECTED]>
---
drivers/scsi/scsi_sysfs.c |1 -
1 files changed, 0 insertions(+), 1 dele
When a scsi_device is allocated it's state is set to SDEV_CREATED.
However, we don't have any chance to detect if slave_alloc() has
run successfully or not.
This patch introduces a state SDEV_NEW which is used instead of
SDEV_CREATED upon initial sdev creation. After slave_alloc() has
run successf
This patchs adds a new helper scsi_destroy_device(). It will transition
and sdev into the 'SDEV_DEL' state.
Signed-off-by: Hannes Reinecke <[EMAIL PROTECTED]>
---
drivers/scsi/scsi_scan.c |3 +--
include/scsi/scsi_device.h |6 ++
2 files changed, 7 insertions(+), 2 deletions(-)
di
When we fail to add a device to the driver core, only the very
helpful message 'error X' is displayed.
Print out some meaningful messages.
Signed-off-by: Hannes Reinecke <[EMAIL PROTECTED]>
---
drivers/scsi/scsi_sysfs.c |6 --
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git
Hi James,
this is a rework of my earlier patchset to address the outstanding 'sdev
oops during scanning' issue. Problem is that any sdev in state
'SDEV_DEL' is still visible to the host until the refcount drops to
zero. When a scan occurs during this time we access a half-initialized
sdev and all
James Bottomley wrote:
> On Tue, 2007-05-29 at 15:29 +0200, Swen Schillig wrote:
>> From: Christof Schmitt <[EMAIL PROTECTED]>
>>
>> zfcp reported units to the SCSI stack starting
>> with number 0. LUN 0 reported to the SCSI stack is usually
>> not the FCP LUN 0. When scanning for devices,
>> th
39 matches
Mail list logo
