This represents all the pieces of SCSI which were depending on the
already merged block tree.
The patch is available at:
master.kernel.org:/pub/scm/linux/kernel/git/jejb/scsi-misc-2.6.git
The short changelog is:
James Bottomley (1):
scsi_error: fix target reset handling
James Smart (12):
lpfc 8.2.8 v2 : Add statistical reporting control and additional fc vendor
lpfc 8.2.8 v2 : Add sysfs control of target queue depth handling
lpfc 8.2.8 v2 : Revert target busy in favor of transport disrupted
lpfc 8.2.8 : update driver version to 8.2.8
lpfc 8.2.8 : Add MSI-X support
lpfc 8.2.8 : Update driver to use new Host byte error code DID_TRANSPORT_D
lpfc 8.2.8 : Add support for PCI-EEH permanent disabling
lpfc 8.2.8 : Add new FCOE hardware support
lpfc 8.2.8 : Miscellaneous Bug Fixes
lpfc 8.2.8 : Update driver for new SLI-3 features
lpfc 8.2.8 : Miscellaneous Discovery Fixes
lpfc 8.2.8 : Add kernel-doc function headers
Martin K. Petersen (4):
sd: Switch kernel printing level for DIF messages
sd: Correctly handle all combinations of DIF and DIX
sd: Always print actual protection_type
sd: Issue correct protection operation
Mike Christie (21):
libiscsi: fix locking in iscsi_eh_device_reset
libiscsi: check reason why we are stopping iscsi session to determine erro
iscsi_tcp: return a descriptive error value during connection errors
libiscsi: rename host reset to target reset
iscsi class: fix endpoint id handling
libiscsi: Support drivers initiating session removal
libiscsi: fix data corruption when target has to resend data-in packets
scsi_dh_alua: remove REQ_NOMERGE
modify scsi to handle new fail fast flags.
block: separate failfast into multiple bits.
qla2xxx: use new host byte transport errors.
fc class: Add support for new transport errors
iscsi class, libiscsi and qla4xxx: convert to new transport host byte valu
scsi: add transport host byte errors (v3)
ibmvfc, qla2xxx, lpfc: remove scsi_target_unblock calls in terminate callb
fc class: unblock target after calling terminate callback (take 2)
lpfc: use SCSI_MLQUEUE_TARGET_BUSY when catching the rport transition race
libiscsi: Use SCSI_MLQUEUE_TARGET_BUSY
qla2xxx: return SCSI_MLQUEUE_TARGET_BUSY when driver has detected rport er
qla4xxx: return SCSI_MLQUEUE_TARGET_BUSY when driver has detected session
Add helper code so transport classes/driver can control queueing (v3)
and the diffstat:
block/blk-core.c | 11
drivers/infiniband/ulp/iser/iscsi_iser.c | 3
drivers/md/dm-mpath.c | 2
drivers/md/multipath.c | 4
drivers/s390/block/dasd_diag.c | 2
drivers/s390/block/dasd_eckd.c | 2
drivers/s390/block/dasd_fba.c | 2
drivers/scsi/constants.c | 3
drivers/scsi/device_handler/scsi_dh_alua.c | 3
drivers/scsi/device_handler/scsi_dh_emc.c | 3
drivers/scsi/device_handler/scsi_dh_hp_sw.c | 6
drivers/scsi/device_handler/scsi_dh_rdac.c | 3
drivers/scsi/ibmvscsi/ibmvfc.c | 2
drivers/scsi/iscsi_tcp.c | 44
drivers/scsi/libiscsi.c | 183 ++
drivers/scsi/lpfc/lpfc.h | 96 +
drivers/scsi/lpfc/lpfc_attr.c | 1375 +++++++++++++++++++++-
drivers/scsi/lpfc/lpfc_crtn.h | 51
drivers/scsi/lpfc/lpfc_ct.c | 20
drivers/scsi/lpfc/lpfc_debugfs.c | 400 +++++-
drivers/scsi/lpfc/lpfc_disc.h | 23
drivers/scsi/lpfc/lpfc_els.c | 1712 +++++++++++++++++++++++++--
drivers/scsi/lpfc/lpfc_hbadisc.c | 241 +++
drivers/scsi/lpfc/lpfc_hw.h | 183 ++
drivers/scsi/lpfc/lpfc_init.c | 924 +++++++++++----
drivers/scsi/lpfc/lpfc_mbox.c | 624 ++++++++--
drivers/scsi/lpfc/lpfc_mem.c | 116 +
drivers/scsi/lpfc/lpfc_nl.h | 163 ++
drivers/scsi/lpfc/lpfc_nportdisc.c | 24
drivers/scsi/lpfc/lpfc_scsi.c | 514 +++++++-
drivers/scsi/lpfc/lpfc_scsi.h | 5
drivers/scsi/lpfc/lpfc_sli.c | 1715 ++++++++++++++++++++++++----
drivers/scsi/lpfc/lpfc_sli.h | 1
drivers/scsi/lpfc/lpfc_version.h | 6
drivers/scsi/lpfc/lpfc_vport.c | 168 ++
drivers/scsi/lpfc/lpfc_vport.h | 4
drivers/scsi/qla2xxx/qla_attr.c | 1
drivers/scsi/qla2xxx/qla_isr.c | 14
drivers/scsi/qla2xxx/qla_os.c | 26
drivers/scsi/qla4xxx/ql4_isr.c | 4
drivers/scsi/qla4xxx/ql4_os.c | 4
drivers/scsi/scsi.c | 10
drivers/scsi/scsi_error.c | 72 +
drivers/scsi/scsi_lib.c | 106 +
drivers/scsi/scsi_priv.h | 1
drivers/scsi/scsi_scan.c | 1
drivers/scsi/scsi_transport_fc.c | 47
drivers/scsi/scsi_transport_iscsi.c | 19
drivers/scsi/scsi_transport_spi.c | 4
drivers/scsi/sd.c | 17
drivers/scsi/sd.h | 2
drivers/scsi/sd_dif.c | 42
include/linux/bio.h | 26
include/linux/blkdev.h | 15
include/scsi/iscsi_if.h | 2
include/scsi/libiscsi.h | 15
include/scsi/scsi.h | 6
include/scsi/scsi_device.h | 10
include/scsi/scsi_transport_fc.h | 8
include/scsi/scsi_transport_iscsi.h | 5
60 files changed, 7989 insertions(+), 1106 deletions(-)
James
On Mon, 13 Oct 2008, James Bottomley wrote:
>
> This represents all the pieces of SCSI which were depending on the
> already merged block tree.
Grr. And it doesn't actually compile.
drivers/scsi/sd.c:579:27: error: macro "sd_dif_op" passed 4 arguments, but takes just 3
drivers/scsi/sd.c: In function ?sd_prep_fn?:
drivers/scsi/sd.c:578: error: ?sd_dif_op? undeclared (first use in this function)
drivers/scsi/sd.c:578: error: (Each undeclared identifier is reported only once
drivers/scsi/sd.c:578: error: for each function it appears in.)
Hmm? Was this testedt AT ALL? It can never compile unless that idiotic
CONFIG_BLK_DEV_INTEGRITY option is set that no sane person would set right
now, and which is even documented to not be enabled by default:
If in doubt, say N.
yet it looks like it has not compiled since a commit that was put in in
the middle of September!
What part of "This is total untested crap" are we missing here?
Yeah, I'm grumpy. I expect to not be fed shit like this. It has apparently
been rebased several times, and all apparently with no testing
what-so-ever!
Linus
On Mon, 2008-10-13 at 10:22 -0700, Linus Torvalds wrote:
>
> On Mon, 13 Oct 2008, James Bottomley wrote:
> >
> > This represents all the pieces of SCSI which were depending on the
> > already merged block tree.
>
> Grr. And it doesn't actually compile.
>
> drivers/scsi/sd.c:579:27: error: macro "sd_dif_op" passed 4 arguments, but takes just 3
> drivers/scsi/sd.c: In function ‘sd_prep_fn’:
> drivers/scsi/sd.c:578: error: ‘sd_dif_op’ undeclared (first use in this function)
> drivers/scsi/sd.c:578: error: (Each undeclared identifier is reported only once
> drivers/scsi/sd.c:578: error: for each function it appears in.)
>
> Hmm? Was this testedt AT ALL? It can never compile unless that idiotic
> CONFIG_BLK_DEV_INTEGRITY option is set that no sane person would set right
> now, and which is even documented to not be enabled by default:
>
> If in doubt, say N.
>
> yet it looks like it has not compiled since a commit that was put in in
> the middle of September!
>
> What part of "This is total untested crap" are we missing here?
OK, you caught me; I'm relying on linux-next to test randomly built
configs because I don't have a compile farm available to me where I can
test every permutation of the options (and obviously, I usually compile
with them all on to test the actual feature code).
> Yeah, I'm grumpy. I expect to not be fed shit like this. It has apparently
> been rebased several times, and all apparently with no testing
> what-so-ever!
Not exactly. It has to be rebased to run as a postmerge tree, but it
does get tested by me (admittedly on my limited set of machines, which
don't include any actual devices that do block integrity) every time I
rebase.
However, does this work for you? It fixes the problem for me.
James
---
diff --git a/drivers/scsi/sd.h b/drivers/scsi/sd.h
index a92b991..75638e7 100644
--- a/drivers/scsi/sd.h
+++ b/drivers/scsi/sd.h
@@ -97,7 +97,7 @@ struct sd_dif_tuple {
__be32 ref_tag; /* Target LBA or indirect LBA */
};
-#if defined(CONFIG_BLK_DEV_INTEGRITY)
+#ifdef CONFIG_BLK_DEV_INTEGRITY
extern void sd_dif_op(struct scsi_cmnd *, unsigned int, unsigned int, unsigned int);
extern void sd_dif_config_host(struct scsi_disk *);
@@ -106,10 +106,19 @@ extern void sd_dif_complete(struct scsi_cmnd *, unsigned int);
#else /* CONFIG_BLK_DEV_INTEGRITY */
-#define sd_dif_op(a, b, c) do { } while (0)
-#define sd_dif_config_host(a) do { } while (0)
-#define sd_dif_prepare(a, b, c) (0)
-#define sd_dif_complete(a, b) (0)
+static inline void sd_dif_op(struct scsi_cmnd *cmd, unsigned int a, unsigned int b, unsigned int c)
+{
+}
+static inline void sd_dif_config_host(struct scsi_disk *disk)
+{
+}
+static inline int sd_dif_prepare(struct request *rq, sector_t s, unsigned int a)
+{
+ return 0;
+}
+static inline void sd_dif_complete(struct scsi_cmnd *cmd, unsigned int a)
+{
+}
#endif /* CONFIG_BLK_DEV_INTEGRITY */
On Mon, 13 Oct 2008, James Bottomley wrote:
>
> Not exactly. It has to be rebased to run as a postmerge tree, but it
> does get tested by me (admittedly on my limited set of machines, which
> don't include any actual devices that do block integrity) every time I
> rebase.
What I'm upset about is that this has apparently gotten not even some
trivial testing of the _default_ build. I'm not talking about any odd
config options here. I'm literally talking about the only _sane_ config
option case.
You yourself admit that even you don't have any actual devices that can
support the block integrity stuff, yet you have apparently only compile-
tested the insane case of still enabling that thing and apparently nobody
else has bothered either.
Was this in linux-next?
Is linux-next coverage REALLY so weak that it doesn't even test the
default config options, much less any random options? What's the point of
linux-next then?
Again, the date on that thing is claimed to be September 19th, although it
was obviously committed later.
> However, does this work for you? It fixes the problem for me.
I could trivially have fixed the compile issue. That's not what upsets me.
What upsets me is that this set of patches apparently had almost nobody
looking at them at all before they got sent to me.
If it was some odd and unusual config option, I'd be less upset. hey,
stuff happens. But it sure as heck was nothing of the sort!
Linus
Linus Torvalds writes:
> Is linux-next coverage REALLY so weak that it doesn't even test the
> default config options, much less any random options? What's the point of
> linux-next then?
Stephen has been on vacation since the kernel summit, so linux-next
hasn't been happening for the past few weeks.
Paul.
>>>>> "Linus" == Linus Torvalds <[email protected]> writes:
Linus> What I'm upset about is that this has apparently gotten not
Linus> even some trivial testing of the _default_ build. I'm not
Linus> talking about any odd config options here. I'm literally
Linus> talking about the only _sane_ config option case.
This one initially slipped through my testing, sorry about that. I
always compile with the integrity both on and off in my devel tree but
I messed up while rebasing the patches against James' tree. These
mutually dependent block and SCSI merges are always tricky to deal
with.
However, I wonder why the obvious build fix wasn't merged? Mike
Anderson sent out a patch for this right after my patch appeared in
the SCSI tree...
--
Martin K. Petersen Oracle Linux Engineering
Hi Linus,
On Mon, 13 Oct 2008 14:22:13 -0700 (PDT) Linus Torvalds <[email protected]> wrote:
>
> Is linux-next coverage REALLY so weak that it doesn't even test the
> default config options, much less any random options? What's the point of
> linux-next then?
Check the results page of the automated builds I do
(http://kisskb.ellerman.id.au/linux-next) - I don't think that the
compile coverage is weak ... Of course, if people don't read the
results ...
Those automated builds are done after the release. Before the release,
the tree is built for ppc64_defconfig, powerpc allnoconfig, 44x_defconfig
for powerpc, allmodconfig for x86_64 and defconfig for i386, sparc and
sparc64.
All this is mentioned in my release notes every day.
> Again, the date on that thing is claimed to be September 19th, although it
> was obviously committed later.
September 19 (Australian time) was the last linux-next release. I don't
know off the top of my head if the particular patch in question was in
next-20080919, but it did contain a version of James' post merge patches.
--
Cheers,
Stephen Rothwell [email protected]
http://www.canb.auug.org.au/~sfr/
On Mon, 2008-10-13 at 14:22 -0700, Linus Torvalds wrote:
>
> On Mon, 13 Oct 2008, James Bottomley wrote:
> >
> > Not exactly. It has to be rebased to run as a postmerge tree, but it
> > does get tested by me (admittedly on my limited set of machines, which
> > don't include any actual devices that do block integrity) every time I
> > rebase.
>
> What I'm upset about is that this has apparently gotten not even some
> trivial testing of the _default_ build. I'm not talking about any odd
> config options here. I'm literally talking about the only _sane_ config
> option case.
>
> You yourself admit that even you don't have any actual devices that can
> support the block integrity stuff, yet you have apparently only compile-
> tested the insane case of still enabling that thing and apparently nobody
> else has bothered either.
Um, well, I wanted to compile the code to make sure it actually did
compile and that it didn't interfere with the normal operation of sd, so
for me it's a justifiable option.
> Was this in linux-next?
Yes ... all my trees feed into linux-next. We just seem to have been
having a few teething problems with it recently. Usually this type of
thing gets picked up by Ingo's random config checker which feeds from
linux-next. However, I don't think linux-next has been built for a
while (Since 19 September according to the logs)
> Is linux-next coverage REALLY so weak that it doesn't even test the
> default config options, much less any random options? What's the point of
> linux-next then?
>
> Again, the date on that thing is claimed to be September 19th, although it
> was obviously committed later.
Right, which is, unfortunately, how it managed to avoid being in
anyone's test bed.
> > However, does this work for you? It fixes the problem for me.
>
> I could trivially have fixed the compile issue. That's not what upsets me.
> What upsets me is that this set of patches apparently had almost nobody
> looking at them at all before they got sent to me.
I agree, but unfortunately our infrastructure is all wrapped around
linux-next now ... even Andrew doesn't pull my trees directly, he gets
them from linux-next. I can and do publish them on kernel.org, but it
takes a fairly superhuman effort to pull in all the kernel.org trees and
compile them.
> If it was some odd and unusual config option, I'd be less upset. hey,
> stuff happens. But it sure as heck was nothing of the sort!
So I do test the trees, but I'm looking for unusual breakage, so my
three configs are ia64 (3hr build) parisc (6hr build) and x86 dual core
(about 40min) with all the options enabled. However, my testing is
mostly runtime rather than compile/config time. Sorry. Once I get this
terrasoft box integrated (i.e. when benh gets remote power working) I
might be able to build faster and try different config options.
James
OK, lets try again, this time with a tree that's got the compile failure
fixed and been through linux-next randconfig testing for a couple of
days (yes, I verified it has this time). This represents all the pieces
of SCSI which were depending on the already merged block tree.
The patch is available at:
master.kernel.org:/pub/scm/linux/kernel/git/jejb/scsi-misc-2.6.git
The short changelog is:
James Bottomley (2):
sd: fix compile failure with CONFIG_BLK_DEV_INTEGRITY=n
scsi_error: fix target reset handling
James Smart (12):
lpfc 8.2.8 v2 : Add statistical reporting control and additional fc vendor
lpfc 8.2.8 v2 : Add sysfs control of target queue depth handling
lpfc 8.2.8 v2 : Revert target busy in favor of transport disrupted
lpfc 8.2.8 : update driver version to 8.2.8
lpfc 8.2.8 : Add MSI-X support
lpfc 8.2.8 : Update driver to use new Host byte error code DID_TRANSPORT_D
lpfc 8.2.8 : Add support for PCI-EEH permanent disabling
lpfc 8.2.8 : Add new FCOE hardware support
lpfc 8.2.8 : Miscellaneous Bug Fixes
lpfc 8.2.8 : Update driver for new SLI-3 features
lpfc 8.2.8 : Miscellaneous Discovery Fixes
lpfc 8.2.8 : Add kernel-doc function headers
Martin K. Petersen (4):
sd: Switch kernel printing level for DIF messages
sd: Correctly handle all combinations of DIF and DIX
sd: Always print actual protection_type
sd: Issue correct protection operation
Mike Christie (21):
libiscsi: fix locking in iscsi_eh_device_reset
libiscsi: check reason why we are stopping iscsi session to determine erro
iscsi_tcp: return a descriptive error value during connection errors
libiscsi: rename host reset to target reset
iscsi class: fix endpoint id handling
libiscsi: Support drivers initiating session removal
libiscsi: fix data corruption when target has to resend data-in packets
scsi_dh_alua: remove REQ_NOMERGE
modify scsi to handle new fail fast flags.
block: separate failfast into multiple bits.
qla2xxx: use new host byte transport errors.
fc class: Add support for new transport errors
iscsi class, libiscsi and qla4xxx: convert to new transport host byte valu
scsi: add transport host byte errors (v3)
ibmvfc, qla2xxx, lpfc: remove scsi_target_unblock calls in terminate callb
fc class: unblock target after calling terminate callback (take 2)
lpfc: use SCSI_MLQUEUE_TARGET_BUSY when catching the rport transition race
libiscsi: Use SCSI_MLQUEUE_TARGET_BUSY
qla2xxx: return SCSI_MLQUEUE_TARGET_BUSY when driver has detected rport er
qla4xxx: return SCSI_MLQUEUE_TARGET_BUSY when driver has detected session
Add helper code so transport classes/driver can control queueing (v3)
The diffstat is:
block/blk-core.c | 11
drivers/infiniband/ulp/iser/iscsi_iser.c | 3
drivers/md/dm-mpath.c | 2
drivers/md/multipath.c | 4
drivers/s390/block/dasd_diag.c | 2
drivers/s390/block/dasd_eckd.c | 2
drivers/s390/block/dasd_fba.c | 2
drivers/scsi/constants.c | 3
drivers/scsi/device_handler/scsi_dh_alua.c | 3
drivers/scsi/device_handler/scsi_dh_emc.c | 3
drivers/scsi/device_handler/scsi_dh_hp_sw.c | 6
drivers/scsi/device_handler/scsi_dh_rdac.c | 3
drivers/scsi/ibmvscsi/ibmvfc.c | 2
drivers/scsi/iscsi_tcp.c | 44
drivers/scsi/libiscsi.c | 183 ++
drivers/scsi/lpfc/lpfc.h | 96 +
drivers/scsi/lpfc/lpfc_attr.c | 1375 +++++++++++++++++++++-
drivers/scsi/lpfc/lpfc_crtn.h | 51
drivers/scsi/lpfc/lpfc_ct.c | 20
drivers/scsi/lpfc/lpfc_debugfs.c | 400 +++++-
drivers/scsi/lpfc/lpfc_disc.h | 23
drivers/scsi/lpfc/lpfc_els.c | 1712 +++++++++++++++++++++++++--
drivers/scsi/lpfc/lpfc_hbadisc.c | 241 +++
drivers/scsi/lpfc/lpfc_hw.h | 183 ++
drivers/scsi/lpfc/lpfc_init.c | 924 +++++++++++----
drivers/scsi/lpfc/lpfc_mbox.c | 624 ++++++++--
drivers/scsi/lpfc/lpfc_mem.c | 116 +
drivers/scsi/lpfc/lpfc_nl.h | 163 ++
drivers/scsi/lpfc/lpfc_nportdisc.c | 24
drivers/scsi/lpfc/lpfc_scsi.c | 514 +++++++-
drivers/scsi/lpfc/lpfc_scsi.h | 5
drivers/scsi/lpfc/lpfc_sli.c | 1715 ++++++++++++++++++++++++----
drivers/scsi/lpfc/lpfc_sli.h | 1
drivers/scsi/lpfc/lpfc_version.h | 6
drivers/scsi/lpfc/lpfc_vport.c | 168 ++
drivers/scsi/lpfc/lpfc_vport.h | 4
drivers/scsi/qla2xxx/qla_attr.c | 1
drivers/scsi/qla2xxx/qla_isr.c | 14
drivers/scsi/qla2xxx/qla_os.c | 26
drivers/scsi/qla4xxx/ql4_isr.c | 4
drivers/scsi/qla4xxx/ql4_os.c | 4
drivers/scsi/scsi.c | 10
drivers/scsi/scsi_error.c | 72 +
drivers/scsi/scsi_lib.c | 106 +
drivers/scsi/scsi_priv.h | 1
drivers/scsi/scsi_scan.c | 1
drivers/scsi/scsi_transport_fc.c | 47
drivers/scsi/scsi_transport_iscsi.c | 19
drivers/scsi/scsi_transport_spi.c | 4
drivers/scsi/sd.c | 17
drivers/scsi/sd.h | 21
drivers/scsi/sd_dif.c | 42
include/linux/bio.h | 26
include/linux/blkdev.h | 15
include/scsi/iscsi_if.h | 2
include/scsi/libiscsi.h | 15
include/scsi/scsi.h | 6
include/scsi/scsi_device.h | 10
include/scsi/scsi_transport_fc.h | 8
include/scsi/scsi_transport_iscsi.h | 5
60 files changed, 8003 insertions(+), 1111 deletions(-)
James