Re: 2.6.22-rc3-mm1
On Thu, 31 May 2007 15:10:05 -0700, Andrew Morton [EMAIL PROTECTED] wrote: Cornelia, afaict your patch has no actual delendency upon Dan's dma-mapping-prevent-dma-dependent-code-from-linking-on.patch, correct? If so, I can merge it via James and then merge Dan's patch once James has merged. AFAICS there's no dependency in that direction. diff -puN include/scsi/scsi_cmnd.h~scsi-dont-build-scsi_dma_mapunmap-for-has_dma include/scsi/scsi_cmnd.h --- a/include/scsi/scsi_cmnd.h~scsi-dont-build-scsi_dma_mapunmap-for-has_dma +++ a/include/scsi/scsi_cmnd.h @@ -135,8 +135,10 @@ extern void scsi_kunmap_atomic_sg(void * extern struct scatterlist *scsi_alloc_sgtable(struct scsi_cmnd *, gfp_t); extern void scsi_free_sgtable(struct scatterlist *, int); +#ifdef CONFIG_SCSI_DMA extern int scsi_dma_map(struct scsi_cmnd *cmd); extern void scsi_dma_unmap(struct scsi_cmnd *cmd); +#endif #define scsi_sg_count(cmd) ((cmd)-use_sg) #define scsi_sglist(cmd) ((struct scatterlist *)(cmd)-request_buffer) We don't really need the ifdefs here. If someone incorrectly calls these functions then they'll get a link-time failure anyway. The downside of removing these ifdefs is that they won't get a compile-time warning, but I tend to think that this small cost is worth it. OK, fine with me. - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] iscsi_tcp: convert to use the data buffer accessors
iscsi_tcp: convert to use the data buffer accessors
- remove the unnecessary map_single path.
- convert to use the new accessors for the sg lists and the
parameters.
TODO: use scsi_for_each_sg().
Signed-off-by: FUJITA Tomonori [EMAIL PROTECTED]
---
drivers/scsi/iscsi_tcp.c | 117 +++---
drivers/scsi/libiscsi.c | 20
2 files changed, 48 insertions(+), 89 deletions(-)
diff --git a/drivers/scsi/iscsi_tcp.c b/drivers/scsi/iscsi_tcp.c
index d5a6527..aee2b60 100644
--- a/drivers/scsi/iscsi_tcp.c
+++ b/drivers/scsi/iscsi_tcp.c
@@ -237,10 +237,10 @@ iscsi_data_rsp(struct iscsi_conn *conn, struct
iscsi_cmd_task *ctask)
tcp_ctask-exp_datasn++;
tcp_ctask-data_offset = be32_to_cpu(rhdr-offset);
- if (tcp_ctask-data_offset + tcp_conn-in.datalen
sc-request_bufflen) {
+ if (tcp_ctask-data_offset + tcp_conn-in.datalen scsi_bufflen(sc)) {
debug_tcp(%s: data_offset(%d) + data_len(%d)
total_length_in(%d)\n,
__FUNCTION__, tcp_ctask-data_offset,
- tcp_conn-in.datalen, sc-request_bufflen);
+ tcp_conn-in.datalen, scsi_buffle(sc));
return ISCSI_ERR_DATA_OFFSET;
}
@@ -250,14 +250,14 @@ iscsi_data_rsp(struct iscsi_conn *conn, struct
iscsi_cmd_task *ctask)
int res_count = be32_to_cpu(rhdr-residual_count);
if (res_count 0
- res_count = sc-request_bufflen) {
- sc-resid = res_count;
+ res_count = scsi_bufflen(sc)) {
+ scsi_set_resid(sc, res_count);
sc-result = (DID_OK 16) | rhdr-cmd_status;
} else
sc-result = (DID_BAD_TARGET 16) |
rhdr-cmd_status;
} else if (rhdr-flags ISCSI_FLAG_DATA_OVERFLOW) {
- sc-resid = be32_to_cpu(rhdr-residual_count);
+ scsi_set_resid(sc, be32_to_cpu(rhdr-residual_count));
sc-result = (DID_OK 16) | rhdr-cmd_status;
} else
sc-result = (DID_OK 16) | rhdr-cmd_status;
@@ -285,6 +285,8 @@ iscsi_solicit_data_init(struct iscsi_conn *conn, struct
iscsi_cmd_task *ctask,
{
struct iscsi_data *hdr;
struct scsi_cmnd *sc = ctask-sc;
+ int i, sg_count = 0;
+ struct scatterlist *sg;
hdr = r2t-dtask.hdr;
memset(hdr, 0, sizeof(struct iscsi_data));
@@ -312,39 +314,30 @@ iscsi_solicit_data_init(struct iscsi_conn *conn, struct
iscsi_cmd_task *ctask,
iscsi_buf_init_iov(r2t-headbuf, (char*)hdr,
sizeof(struct iscsi_hdr));
- if (sc-use_sg) {
- int i, sg_count = 0;
- struct scatterlist *sg = sc-request_buffer;
-
- r2t-sg = NULL;
- for (i = 0; i sc-use_sg; i++, sg += 1) {
- /* FIXME: prefetch ? */
- if (sg_count + sg-length r2t-data_offset) {
- int page_offset;
+ sg = scsi_sglist(sc);
+ r2t-sg = NULL;
+ for (i = 0; i scsi_sg_count(sc); i++, sg += 1) {
+ /* FIXME: prefetch ? */
+ if (sg_count + sg-length r2t-data_offset) {
+ int page_offset;
- /* sg page found! */
+ /* sg page found! */
- /* offset within this page */
- page_offset = r2t-data_offset - sg_count;
+ /* offset within this page */
+ page_offset = r2t-data_offset - sg_count;
- /* fill in this buffer */
- iscsi_buf_init_sg(r2t-sendbuf, sg);
- r2t-sendbuf.sg.offset += page_offset;
- r2t-sendbuf.sg.length -= page_offset;
+ /* fill in this buffer */
+ iscsi_buf_init_sg(r2t-sendbuf, sg);
+ r2t-sendbuf.sg.offset += page_offset;
+ r2t-sendbuf.sg.length -= page_offset;
- /* xmit logic will continue with next one */
- r2t-sg = sg + 1;
- break;
- }
- sg_count += sg-length;
+ /* xmit logic will continue with next one */
+ r2t-sg = sg + 1;
+ break;
}
- BUG_ON(r2t-sg == NULL);
- } else {
- iscsi_buf_init_iov(r2t-sendbuf,
- (char*)sc-request_buffer + r2t-data_offset,
- r2t-data_count);
- r2t-sg = NULL;
+
[PATCH 2/2] iscsi_iser: convert to use the data buffer accessors
iscsi_iser: convert to use the data buffer accessors
- remove the unnecessary map_single path.
- convert to use the new accessors for the sg lists and the
parameters.
TODO: use scsi_for_each_sg().
Signed-off-by: FUJITA Tomonori [EMAIL PROTECTED]
---
drivers/infiniband/ulp/iser/iscsi_iser.c |4 ++--
drivers/infiniband/ulp/iser/iser_initiator.c | 14 --
2 files changed, 6 insertions(+), 12 deletions(-)
diff --git a/drivers/infiniband/ulp/iser/iscsi_iser.c
b/drivers/infiniband/ulp/iser/iscsi_iser.c
index 1bf173d..effdee2 100644
--- a/drivers/infiniband/ulp/iser/iscsi_iser.c
+++ b/drivers/infiniband/ulp/iser/iscsi_iser.c
@@ -210,10 +210,10 @@ iscsi_iser_ctask_xmit(struct iscsi_conn *conn,
int error = 0;
if (ctask-sc-sc_data_direction == DMA_TO_DEVICE) {
- BUG_ON(ctask-sc-request_bufflen == 0);
+ BUG_ON(scsi_bufflen(ctask-sc) == 0);
debug_scsi(cmd [itt %x total %d imm %d unsol_data %d\n,
- ctask-itt, ctask-sc-request_bufflen,
+ ctask-itt, scsi_bufflen(ctask-sc),
ctask-imm_count, ctask-unsol_count);
}
diff --git a/drivers/infiniband/ulp/iser/iser_initiator.c
b/drivers/infiniband/ulp/iser/iser_initiator.c
index 3651072..9ea5b9a 100644
--- a/drivers/infiniband/ulp/iser/iser_initiator.c
+++ b/drivers/infiniband/ulp/iser/iser_initiator.c
@@ -351,18 +351,12 @@ int iser_send_command(struct iscsi_conn *conn,
else
data_buf = iser_ctask-data[ISER_DIR_OUT];
- if (sc-use_sg) { /* using a scatter list */
- data_buf-buf = sc-request_buffer;
- data_buf-size = sc-use_sg;
- } else if (sc-request_bufflen) {
- /* using a single buffer - convert it into one entry SG */
- sg_init_one(data_buf-sg_single,
- sc-request_buffer, sc-request_bufflen);
- data_buf-buf = data_buf-sg_single;
- data_buf-size = 1;
+ if (scsi_sg_count(sc)) { /* using a scatter list */
+ data_buf-buf = scsi_sglist(sc);
+ data_buf-size = scsi_sg_count(sc);
}
- data_buf-data_len = sc-request_bufflen;
+ data_buf-data_len = scsi_bufflen(sc);
if (hdr-flags ISCSI_FLAG_CMD_READ) {
err = iser_prepare_read_cmd(ctask, edtl);
--
1.4.4.4
-
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/2] iscsi: convert to use the data buffer accessors
This patchset converts libiscsi, iscsi_tcp, and iscsi_iser to use the data buffer accessors. This is dependent on the patchset that Mike posted the day before yesterday (which is on the top of the latest scsi-misc-2.6): http://marc.info/?l=linux-scsim=118054788406095w=2 This can be also cleanly applied to Mike's iscsi git tree. iscsi_tcp and iscsi_iser needs some modifications to use scsi_for_each_sg macro so I've not done that. It would be easier to use the chaining sg macros like next_sg directly when they are ready. - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [2/3] 2.6.22-rc3: known regressions v2
Hi all, Here is a list of some known regressions in 2.6.22-rc3. Feel free to add new regressions/remove fixed etc. http://kernelnewbies.org/known_regressions PCMCIA Subject: libata and legacy ide pcmcia failure References : http://lkml.org/lkml/2007/5/17/305 Submitter : Robert de Rooy [EMAIL PROTECTED] Status : Unknown SATA/PATA Subject: 22-rc3 broke the CDROM in Dell notebook References : http://lkml.org/lkml/2007/5/27/63 Submitter : Gregor Jasny [EMAIL PROTECTED] Handled-By : Tejun Heo [EMAIL PROTECTED] Jeff Garzik [EMAIL PROTECTED] Caused-By : Tejun Heo [EMAIL PROTECTED] commit d4b2bab4f26345ea1803feb23ea92fbe3f6b77bc Status : problem is being debugged SCSI Subject: aacraid: adapter kernel panic'd fffd (kexec) References : http://lkml.org/lkml/2007/5/29/491 Submitter : Yinghai Lu [EMAIL PROTECTED] Handled-By : Salyzyn, Mark [EMAIL PROTECTED] Vivek Goyal [EMAIL PROTECTED] Status : problem is being debugged Sparc64 Subject: 2.6.22-rc broke X on Ultra5 References : http://lkml.org/lkml/2007/5/22/78 Submitter : Mikael Pettersson [EMAIL PROTECTED] Handled-By : David Miller [EMAIL PROTECTED] Status : problem is being debugged Regards, Michal -- Najbardziej brakowało mi twojego milczenia. -- Andrzej Sapkowski Coś więcej - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [AIC7xxx] tree things to report
Please try the attached patch and see if it helps. James, I know that the aic7xxx has some 'next_queued_hscb' pointer which might be utilized for this sort of thing. But I didn't really figure out how this thing is supposed to work nor how we could utilize it. So I figured that the added complexity is not really worth it. Did you have time to look at the new logs this the patch applied ? Do you need something else ? Cheers, Emmanuel. --- Créez votre adresse électronique [EMAIL PROTECTED] 1 Go d'espace de stockage, anti-spam et anti-virus intégrés. - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: linux-2.6.22-rc3-g3f0a6766 build #287 failed in drivers/scsi/aic7xxx/aic7xxx.ko
On Thu, 2007-05-31 at 16:56 -0700, Randy Dunlap wrote: On Thu, 31 May 2007 18:22:55 -0400 James Bottomley wrote: On Thu, 2007-05-31 at 18:35 +0200, Toralf Förster wrote: Hello, the build with the attached .config failed, make ends with: ... CC arch/i386/boot/compresse HOSTCC arch/i386/boot/tools/build BUILD arch/i386/boot/bzImage Root device is (3, 8) Boot sector 512 bytes. Setup is 7178 bytes. System is 2513 kB Kernel: arch/i386/boot/bzImage is ready (#1) Building modules, stage 2. MODPOST 363 modules ERROR: spi_dv_device [drivers/scsi/aic7xxx/aic7xxx.ko] undefined! ERROR: spi_attach_transport [drivers/scsi/aic7xxx/aic7xxx.ko] undefined! ERROR: spi_populate_ppr_msg [drivers/scsi/aic7xxx/aic7xxx.ko] undefined! ERROR: spi_populate_width_msg [drivers/scsi/aic7xxx/aic7xxx.ko] undefined! ERROR: spi_release_transport [drivers/scsi/aic7xxx/aic7xxx.ko] undefined! ERROR: spi_display_xfer_agreement [drivers/scsi/aic7xxx/aic7xxx.ko] undefined! ERROR: spi_populate_sync_msg [drivers/scsi/aic7xxx/aic7xxx.ko] undefined! ERROR: spi_dv_device [drivers/scsi/53c700.ko] undefined! ERROR: spi_attach_transport [drivers/scsi/53c700.ko] undefined! ERROR: spi_schedule_dv_device [drivers/scsi/53c700.ko] undefined! ERROR: spi_release_transport [drivers/scsi/53c700.ko] undefined! ERROR: spi_display_xfer_agreement [drivers/scsi/53c700.ko] undefined! ERROR: spi_populate_sync_msg [drivers/scsi/53c700.ko] undefined! ERROR: spi_print_msg [drivers/scsi/53c700.ko] undefined! ERROR: ROOT_DEV [drivers/mtd/maps/nettel.ko] undefined! make[1]: *** [__modpost] Error 1 make: *** [modules] Error 2 This looks like some build issue. The symbols (except the last ROOT_DEV) are defined in scsi_transport_spi.o which should have been compiled in your build log because your .config has CONFIG_SCSI_SPI_ATTRS=y which should build it. Easily reproducible. and scsi_transport_spi.o is compiled. but apparently not linked. I suppose that it's due to CONFIG_SCSI=m, but we still have: # # SCSI Transports # CONFIG_SCSI_SPI_ATTRS=y CONFIG_SCSI_FC_ATTRS=m CONFIG_SCSI_ISCSI_ATTRS=m CONFIG_SCSI_SAS_ATTRS=m CONFIG_SCSI_SAS_LIBSAS=m Should these modules be constrained to =m when CONFIG_SCSI=m ? Yes, they should. If there's no SCSI module there's nothing to link them into. I thought the depends SCSI directive enforced this requirement (as in you can't make SCSI_SPI_ATTRS y if SCSI is m and we depend on it) ... is this incorrect? James - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: linux-2.6.22-rc3-g3f0a6766 build #287 failed in drivers/scsi/aic7xxx/aic7xxx.ko
On Fri, 2007-06-01 at 09:07 -0400, James Bottomley wrote: On Thu, 2007-05-31 at 16:56 -0700, Randy Dunlap wrote: On Thu, 31 May 2007 18:22:55 -0400 James Bottomley wrote: On Thu, 2007-05-31 at 18:35 +0200, Toralf Förster wrote: Hello, the build with the attached .config failed, make ends with: ... CC arch/i386/boot/compresse HOSTCC arch/i386/boot/tools/build BUILD arch/i386/boot/bzImage Root device is (3, 8) Boot sector 512 bytes. Setup is 7178 bytes. System is 2513 kB Kernel: arch/i386/boot/bzImage is ready (#1) Building modules, stage 2. MODPOST 363 modules ERROR: spi_dv_device [drivers/scsi/aic7xxx/aic7xxx.ko] undefined! ERROR: spi_attach_transport [drivers/scsi/aic7xxx/aic7xxx.ko] undefined! ERROR: spi_populate_ppr_msg [drivers/scsi/aic7xxx/aic7xxx.ko] undefined! ERROR: spi_populate_width_msg [drivers/scsi/aic7xxx/aic7xxx.ko] undefined! ERROR: spi_release_transport [drivers/scsi/aic7xxx/aic7xxx.ko] undefined! ERROR: spi_display_xfer_agreement [drivers/scsi/aic7xxx/aic7xxx.ko] undefined! ERROR: spi_populate_sync_msg [drivers/scsi/aic7xxx/aic7xxx.ko] undefined! ERROR: spi_dv_device [drivers/scsi/53c700.ko] undefined! ERROR: spi_attach_transport [drivers/scsi/53c700.ko] undefined! ERROR: spi_schedule_dv_device [drivers/scsi/53c700.ko] undefined! ERROR: spi_release_transport [drivers/scsi/53c700.ko] undefined! ERROR: spi_display_xfer_agreement [drivers/scsi/53c700.ko] undefined! ERROR: spi_populate_sync_msg [drivers/scsi/53c700.ko] undefined! ERROR: spi_print_msg [drivers/scsi/53c700.ko] undefined! ERROR: ROOT_DEV [drivers/mtd/maps/nettel.ko] undefined! make[1]: *** [__modpost] Error 1 make: *** [modules] Error 2 This looks like some build issue. The symbols (except the last ROOT_DEV) are defined in scsi_transport_spi.o which should have been compiled in your build log because your .config has CONFIG_SCSI_SPI_ATTRS=y which should build it. Easily reproducible. and scsi_transport_spi.o is compiled. but apparently not linked. I suppose that it's due to CONFIG_SCSI=m, but we still have: # # SCSI Transports # CONFIG_SCSI_SPI_ATTRS=y CONFIG_SCSI_FC_ATTRS=m CONFIG_SCSI_ISCSI_ATTRS=m CONFIG_SCSI_SAS_ATTRS=m CONFIG_SCSI_SAS_LIBSAS=m Should these modules be constrained to =m when CONFIG_SCSI=m ? Yes, they should. If there's no SCSI module there's nothing to link them into. I thought the depends SCSI directive enforced this requirement (as in you can't make SCSI_SPI_ATTRS y if SCSI is m and we depend on it) ... is this incorrect? I just tried it on my setup. When SCSI=m this is what I get: * * SCSI Transports * Parallel SCSI (SPI) Transport Attributes (SCSI_SPI_ATTRS) [M/y/?] (NEW) Also, all the SCSI dependent device drivers are doing this too ... I'm sure this didn't used to be the case, so I suspect we have a bug in Kconfig somewhere. James - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Stgt-devel] Question for pass-through target design
Vladislav Bolkhovitin wrote: So, if you need in-kernel pass-through I would suggest you to look at SCST project (http://scst.sf.net), which is currently stable and mature, although also not fully finished yet. It was historically from the very beginning designed for full feature in-kernel pass-through for not only stateless SCSI devices, like disks, but also for stateful SCSI devices (like SSC ones a.k.a. tapes), where the correct handling of all above is essential. In additional to considerably better performance, the complete in-kernel approach makes the code simpler, smaller and cleaner as well as allows such things as zero-copy buffered file IO, i.e. when data are sent to remote initiators or received from them directly from/to the page cache (currently under development). For those who need implementing SCSI devices in the user space scst_user module is about to be added. Since the SCSI state machine is in kernel the interface provided by scst_user is very simple, it essentially consists from only a single IOCTL and allows to have overhead as low as a single syscall per SCSI command without any additional context switches. It is already implemented and works. For some legal reasons I can't at the moment publish it, but you can see its full description in the project's SVN docs (you can get them using command svn co https://svn.sourceforge.net/svnroot/scst/trunk/doc;). Now I released scst_user module and it is available from the SCST SVN, so you can check how simply it allows to write SCSI devices, like a VTL, in the user space. Vlad - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] aacraid: fix shutdown handler to also disable interrupts.
Yes, this patch makes sure that the Adapter is shut down correctly, and thus when the kexec driver loads, it does not automatically reset the adapter during initialization. This regression was a result of adding code to the driver to detect if the adapter needed a reset as a result of an unclean shutdown in order to deal with an issue that came up with kdump. Kdump does not issue a clean shutdown. As you see, it was the process of making the driver smarter to find out if it needed to reset the adaptec fw that triggered the problem. As noted before, please be advised to go through SUN channels. Upgrade your Drive(s), SES, Motherboard and Card Firmware to the latest versions; and make sure you are using compatible drives and drive bays to see if this problem dealing with the superfluous reset on your pre-release system goes away. You will be able to trigger this by trying to perform a kdump on the system, OR by reverting this patch and running your kexec test. The superfluous reset has yet to cause an issue with a released card beyond noticing a superfluous Firmware reset as Vivek has pointed out. Sincerely -- Mark Salyzyn From: Yinghai Lu [mailto:[EMAIL PROTECTED] sez: On 6/1/07, Vivek Goyal [EMAIL PROTECTED] wrote: Thanks Mark. This does fix the issue of unnecessary reset of aacraid adapter over kexec on my machine. i'm little confused about that. this patch is some clear shutdown, so even next start will have tight condition will not try to reset the adapter fw. right Mark? Maybe the driver could be smart to find out if it need to reset adaptec fw. YH - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [2/3] 2.6.22-rc3: known regressions v2
On Fri, Jun 01, 2007 at 09:01:15AM -0700, Andrew Morton wrote: On Fri, 01 Jun 2007 14:20:55 +0200 Michal Piotrowski [EMAIL PROTECTED] wrote: SCSI Subject: aacraid: adapter kernel panic'd fffd (kexec) References : http://lkml.org/lkml/2007/5/29/491 Submitter : Yinghai Lu [EMAIL PROTECTED] Handled-By : Salyzyn, Mark [EMAIL PROTECTED] Vivek Goyal [EMAIL PROTECTED] Status : problem is being debugged Mark's aacraid-fix-shutdown-handler-to-also-disable-interrupts.patch is known to fix this, so we can move this to known regressions with patches Hi Andrew, aacraid-fix-shutdown-handler-to-also-disable-interrupts.patch is meant to ensure that we don't perform an unnecessary reset of the device during a kexec boot. During kexec, we perform the device_shutdown() which should bring the device to a known sane state and a reset is not required while next kernel is coming up. I think this fix just masks Yinghai's problem and as such does not fix the root cause of the problem. In his case a software reset of the card is not successful and this is a problem. This problem will become visible during kdump. So I would think that this regression is still there just that got shifted from kexec to kdump. But we do need above patch to make sure kexec boot is fast and does not perform any unrequired device reset. Thanks Vivek - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] iscsi_tcp: convert to use the data buffer accessors
FUJITA Tomonori wrote: iscsi_tcp: convert to use the data buffer accessors - remove the unnecessary map_single path. - convert to use the new accessors for the sg lists and the parameters. I put this in the iscsi git tree with Olaf's recv path rewrite and I converted his patch to use the new accessors. We can test all this together. Have fun Boaz :) At least you did not have to rediff the patches for once :) - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [2/3] 2.6.22-rc3: known regressions v2
On 6/1/07, Salyzyn, Mark [EMAIL PROTECTED] wrote: Agree, but overstated somewhat. The card in question that the regression is reported against is not a released card and as such could have a flawed environment, Hardware, Firmware or other Incompatibility. The fix for the root cause will likely not touch the driver or the kernel So aacraid.reset_devices=1 works with Vivek's test system? YH - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
IOs stuck in SG
I am seeing a problem where IOs get stuck in SG for a _long_ time. The initiator driver is our own, and we dont see any IOs in there that are pending. We are running 2.4.30. This is what I see in the proc file for SG. The act: acc to documentation means: act: mid level (adapter driver or device) has command. Has anyone seen this problem? If yes, is there a patch for this problem? device=sg97 scsi4 chan=0 id=17 lun=0 em=0 sg_tablesize=64 excl=0 FD(1): timeout=6ms bufflen=4096 (res)sgat=0 low_dma=0 cmd_q=1 f_packid=1 k_orphan=0 closed=0 act: id=1856404224 blen=8 t_o/elap=15000/54615000ms sgat=0 op=0x25 device=sg98 scsi4 chan=0 id=18 lun=0 em=0 sg_tablesize=64 excl=0 FD(1): timeout=6ms bufflen=4096 (res)sgat=0 low_dma=0 cmd_q=1 f_packid=1 k_orphan=0 closed=0 act: id=1883362756 blen=255 t_o/elap=15000/54474000ms sgat=0 op=0x1c -- Mark Need Mail bonding? Go to the Yahoo! Mail QA for great tips from Yahoo! Answers users. http://answers.yahoo.com/dir/?link=listsid=396546091 - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] add bidi support for block pc requests
Boaz Harrosh wrote: FUJITA Tomonori wrote: From: Boaz Harrosh [EMAIL PROTECTED] Subject: Re: [PATCH v2] add bidi support for block pc requests Date: Thu, 17 May 2007 17:00:21 +0300 Yes Tomo found it at ata_scsi_slave_config(). Attached below the way I fixed it. Now it works with 127. I think that we can just remove blk_queue_max_phys_segments since the ata drivers seem to set sg_tablesize to LIBATA_MAX_PRD. Who should send a patch upstream? (I cc'ed Jeff Garzik) Boaz diff --git a/drivers/ata/libata-scsi.c b/drivers/ata/libata-scsi.c index dd81fa7..3660f3e 100644 --- a/drivers/ata/libata-scsi.c +++ b/drivers/ata/libata-scsi.c @@ -800,8 +800,6 @@ int ata_scsi_slave_config(struct scsi_device *sdev) ata_scsi_sdev_config(sdev); - blk_queue_max_phys_segments(sdev-request_queue, LIBATA_MAX_PRD); - sdev-manage_start_stop = 1; I don't mind the patch, but could someone refresh me as to the context? Is there something wrong with the above code, or is it simply redundant to the scsi_host_template settings in each LLDD? Jeff - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: LSI MegaRAID problems
On Wed, 30 May 2007 12:59:37 +0200 Jules Colding [EMAIL PROTECTED] wrote: Hi, I have a LSI Logic MegaRAID SCSI 320-4x adapter with an external raid5 array of 5 Seagate ST336754LW and XFS as fs on it. The device in question is /dev/sdb and the box is a dual Opteron 252. I've recently started to see this in the log almost whenever I touch the filesystem: May 30 12:22:56 omc-2 [ 1120.991356] megaraid: aborting-109150 cmd=28 c=4 t=1 l=0 May 30 12:22:56 omc-2 [ 1120.991366] megaraid abort: 109150:68[255:129], fw owner May 30 12:22:56 omc-2 [ 1120.991371] megaraid: aborting-109151 cmd=28 c=4 t=1 l=0 May 30 12:22:56 omc-2 [ 1120.991374] megaraid abort: 109151:64[255:129], fw owner May 30 12:22:56 omc-2 [ 1120.991379] megaraid: 2 outstanding commands. Max wait 300 sec May 30 12:22:56 omc-2 [ 1120.991382] megaraid mbox: Wait for 2 commands to complete:300 May 30 12:23:01 omc-2 [ 1126.006002] megaraid mbox: Wait for 2 commands to complete:295 May 30 12:23:06 omc-2 [ 1131.020774] megaraid mbox: Wait for 2 commands to complete:290 May 30 12:23:11 omc-2 [ 1136.035548] megaraid mbox: Wait for 2 commands to complete:285 May 30 12:23:16 omc-2 [ 1141.050325] megaraid mbox: Wait for 2 commands to complete:280 May 30 12:23:21 omc-2 [ 1146.065098] megaraid mbox: Wait for 2 commands to complete:275 May 30 12:23:26 omc-2 [ 1151.083870] megaraid mbox: Wait for 0 commands to complete:270 May 30 12:23:26 omc-2 [ 1151.083874] megaraid mbox: reset sequence completed sucessfully May 30 12:23:26 omc-2 [ 1151.083979] sd 0:4:1:0: SCSI error: return code = 0x00040001 May 30 12:23:26 omc-2 [ 1151.083983] end_request: I/O error, dev sdb, sector 95601663 May 30 12:23:26 omc-2 [ 1151.084124] sd 0:4:1:0: SCSI error: return code = 0x00040001 May 30 12:23:26 omc-2 [ 1151.084128] end_request: I/O error, dev sdb, sector 95601535 May 30 12:23:26 omc-2 [ 1151.084332] sd 0:4:1:0: SCSI error: return code = 0x00040001 May 30 12:23:26 omc-2 [ 1151.084334] end_request: I/O error, dev sdb, sector 95601535 May 30 12:23:27 omc-2 [ 1152.725763] sd 0:4:1:0: SCSI error: return code = 0x00040001 May 30 12:23:27 omc-2 [ 1152.725768] end_request: I/O error, dev sdb, sector 71411967 May 30 12:23:27 omc-2 [ 1152.725816] sd 0:4:1:0: SCSI error: return code = 0x00040001 May 30 12:23:27 omc-2 [ 1152.725818] end_request: I/O error, dev sdb, sector 71411967 May 30 12:23:31 omc-2 [ 1156.578149] sd 0:4:1:0: SCSI error: return code = 0x00040001 May 30 12:23:31 omc-2 [ 1156.578156] end_request: I/O error, dev sdb, sector 143351464 May 30 12:23:31 omc-2 [ 1156.578173] I/O error in filesystem (sdb1) meta-data dev sdb1 block 0x88b5e69 (xlog_iodone) error 5 buf count 10752 May 30 12:23:31 omc-2 [ 1156.578178] xfs_force_shutdown(sdb1,0x2) called from line 960 of file fs/xfs/xfs_log.c. Return address = 0x80398b56 May 30 12:23:31 omc-2 [ 1156.578204] Filesystem sdb1: Log I/O Error Detected. Shutting down filesystem: sdb1 May 30 12:23:31 omc-2 [ 1156.578207] Please umount the filesystem, and rectify the problem(s) May 30 12:23:31 omc-2 [ 1156.578251] sd 0:4:1:0: SCSI error: return code = 0x00040001 May 30 12:23:31 omc-2 [ 1156.578253] end_request: I/O error, dev sdb, sector 63 May 30 12:24:13 omc-2 [ 1198.747915] xfs_force_shutdown(sdb1,0x1) called from line 424 of file fs/xfs/xfs_rw.c. Return address = 0x803afc2a One of the drives in the array has been put offline after having seen media errors. I'm waiting for a replacement but the recurring errors worry me... Any help/advises would be greatly appreciated. Thanks a lot in advance, jules PS: I'm running a distribution kernel, but having seen zero responses on the gentoo list I dared to write here. The kernel is gentoo-sources 2.6.20-r8. Is there actually a problem here? It looks like you have a dud disk and the kernel reported it and then took appropriate action? - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: megaraid.c, all kernel versions, problem with multi-luns
On Wed, 30 May 2007 20:09:44 -0300 Reinaldo Carvalho [EMAIL PROTECTED] wrote: Hi, (cc's added) (CONFIG_SCSI_MULTI_LUN is set) I have a Dell PowerEdge Expandable RAID controller, with a hardware Raid-5 at Channel 01 running perfectly, and a nCipher Crypter at Channel 02. This controller doesn't correctly detect devices (e.g. nCipher Crypter) with multiples LUNs. Only one LUN is detected. At another controller (e.g. Adaptec 79xx) two LUNs were detect. I compiled 2.6.8, 2.6.18 and 2.6.21.3 to test megaraid driver and all failed detecting two LUNs. I think that this is a firmware problem, but i'd like have some opinions. I read some docs (http://www.suse.de/~garloff/linux/scsi-scan/scsi-scanning.html, http://www.ictp.trieste.it/~radionet/nuc1996/ref/howto-html/scsi-howto-2.html) and this problem doesn't seem to be simple. Best regards, More information with Dell PowerEdge Expandable RAID controller (LSI Logic MegaRaid): Attached devices: Host: scsi0 Channel: 00 Id: 06 Lun: 00 Vendor: PE/PVModel: 1x5 SCSI BP Rev: 1.0 Type: ProcessorANSI SCSI revision: 02 Host: scsi0 Channel: 01 Id: 00 Lun: 00 Vendor: nCipher Model: Fastness Crypto Rev: 2*00 Type: ProcessorANSI SCSI revision: 02 Host: scsi0 Channel: 02 Id: 00 Lun: 00 Vendor: MegaRAID Model: LD 0 RAID5 279G Rev: 522A Type: Direct-AccessANSI SCSI revision: 02 14:0e.0 RAID bus controller: Dell PowerEdge Expandable RAID controller 4 (rev 06) Subsystem: Dell PowerEdge Expandable RAID Controller 4e/Di Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping+ SERR+ FastB2B- Status: Cap+ 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium TAbort- TAbort- MAbort- SERR- PERR- Latency: 64 (32000ns min), Cache Line Size: 64 bytes Interrupt: pin A routed to IRQ 22 Region 0: Memory at d7ff (32-bit, prefetchable) [size=64K] Region 2: Memory at defc (32-bit, non-prefetchable) [size=256K] Expansion ROM at df00 [disabled] [size=128K] Capabilities: access denied 14:0e.0 0104: 1028:0013 (rev 06) Information with Adaptec 79xx or others SCSI controllers: Host: scsi0 Channel: 01 Id: 00 Lun: 00 Vendor: nCipher Model: Fastness Crypto Rev: 2*00 Type: ProcessorANSI SCSI revision: 02 Host: scsi0 Channel: 01 Id: 00 Lun: 01 Vendor: nCipher Model: Fastness Crypto Rev: 2*00 Type: ProcessorANSI SCSI revision: 02 - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
