Re: [patch 02/25] drivers/scsi/advansys.c: cleanups
On Wed, May 23, 2007 at 08:22:07PM -0500, James Bottomley wrote: On Wed, 2007-05-23 at 16:33 -0700, Andrew Morton wrote: On Wed, 23 May 2007 18:21:31 -0500 James Bottomley [EMAIL PROTECTED] wrote: On Wed, 2007-05-23 at 14:41 -0700, [EMAIL PROTECTED] wrote: From: Adrian Bunk [EMAIL PROTECTED] - remove the unneeded advansys.h - remove the unused advansys_setup() This isn't quite right, though, is it? advansys_setup() should be used. It looks like there was a bogus conversion away from init/main.c which left the function dangling. Isn't the correct thing to do to wire it up in advansys_detect() which is where it should have been in the first place. Even going back to linux-2.4.2 I can find no caller to advansys_setup(). Or was its call buried in the magical template macros? If I remember rightly, the bootsetups[] array was a 2.0 thing it became kernel_param in 2.1.75. It was gone by 2.4.0, so this removal thing must have been in the 2.3 timeframe. Still ... it can be put back .. it looks basically sound. I don't think we should put it back, obviously no ones has missed it for te last 10 years. If we really want boot paramaters for advansys it should be using module_param, not a 10 year old legacy interface. - 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] [scsi] Remove __GFP_DMA
That didn't used to work right on the AMD boards when I tried it last as we ended up with a buffer that was mapped by the IOMMU for some reason and that was not below 2GB. The physical address you mean? If that is still happening then it needs to get fixed. The allocation should not succeed if it can't provide memory that's inside the DMA mask for the device.. But the allocation can succeed - using GFP_DMA at least you can do it as you get memory below 2^24 you don't need to map via the IOMMU - 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: SMART support for SATA drives in SAS enclosures
Doug, /dev/sdc is indeed a physical SATA disk. sg_sat_identify says: ATA PASS-THROUGH (16) not supported I'll look into a firmware update. Thanks, Pim Douglas Gilbert wrote: Pim Zandbergen wrote: Is SMART support available for SATA drives in SAS enclosures? I'm testing this setup LSI Logic SAS3800X PCI-X SAS controller (mptsas driver) Promise V-Trak J300S SAS/SATA enclosure/expander 12x Seagate ST3500630NS Linux kernel 2.6.21.1 x86_64 smartmontools-5.37-1.1.fc6 from Fedora Core 6 smartctl -i -d sat /dev/sdc gives me Smartctl: Device Read Identity Failed I presume /dev/sdc is an actual disk rather than a RAID device made up of several disks. The SAT standard (and smartmontools) don't have a general way of addressing individual disks behind RAID infrastructure. For recent versions of smartmontools version 5.37 and MPT Fusion SAS HBAs this should work if /dev/sdc is a SATA disk. Your HBA may need a firmware upgrade. You might fetch sg3_utils version 1.24 and try: sg_sat_identify /dev/sdc That needs to work before smartctl has a hope. Same with -d ata. If I treat the disk as SCSI (-d scsi), the command will not fail, but wil only retrieve the serial number. With MPT Fusion SAS hardware (that I have seen) the SAT layer is in the HBA firmware. Only later versions of the firmware support the SCSI ATA PASS-THROUGH command. Doug Gilbert - 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 14/25] SCSI: use irq_handler_t where appropriate
On Wed, 23 May 2007, [EMAIL PROTECTED] wrote: Subject: [patch 14/25] SCSI: use irq_handler_t where appropriate Message-Id: [EMAIL PROTECTED] From: Jeff Garzik [EMAIL PROTECTED] Signed-off-by: Jeff Garzik [EMAIL PROTECTED] Signed-off-by: Andrew Morton [EMAIL PROTECTED] --- drivers/scsi/aacraid/aacraid.h |2 +- drivers/scsi/qla2xxx/qla_isr.c |2 +- ACK -- the qla2xxx changes. - 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 16/25] drivers/scsi/ips.c: remove kernel 2.4 code
Looks fine, totally inert. Inspected, could see no flaws. Disclaimer: Resisting application to Adaptec version of the sources since we still have to support legacy distributions, will keep synchronized none-the-less. Sincerely -- Mark Salyzyn -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Wednesday, May 23, 2007 5:42 PM To: [EMAIL PROTECTED] Cc: linux-scsi@vger.kernel.org; [EMAIL PROTECTED]; [EMAIL PROTECTED]; AACRAID; IpsLinux Subject: [patch 16/25] drivers/scsi/ips.c: remove kernel 2.4 code From: Adrian Bunk [EMAIL PROTECTED] Signed-off-by: Adrian Bunk [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Signed-off-by: Andrew Morton [EMAIL PROTECTED] --- drivers/scsi/ips.c | 145 +-- drivers/scsi/ips.h | 44 - 2 files changed, 20 insertions(+), 169 deletions(-) - 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] [scsi] Remove __GFP_DMA
So, is the sequence:
p = kmalloc(upsg-sg[i].count,GFP_KERNEL);
. . .
addr = pci_map_single(dev-pdev, p, upsg-sg[i].count,
data_dir);
Going to ensure that we have a 31 bit (not 32 bit) physical address?
If not, then I reject this patch. We can not consider replacement with
pci_alloc_consistent until it works on AMD respecting the DMA masks.
Sincerely -- Mark Salyzyn
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Aubrey Li
Sent: Tuesday, May 22, 2007 10:41 PM
To: Christoph Lameter
Cc: Bernhard Walle; linux-scsi@vger.kernel.org; Andrew
Morton; [EMAIL PROTECTED]; James Bottomley
Subject: Re: [PATCH] [scsi] Remove __GFP_DMA
On 5/23/07, Christoph Lameter [EMAIL PROTECTED] wrote:
On Mon, 21 May 2007, Bernhard Walle wrote:
[PATCH] [scsi] Remove __GFP_DMA
After 821de3a27bf33f11ec878562577c586cd5f83c64, it's not
necessary to alloate a
DMA buffer any more in sd.c.
Signed-off-by: Bernhard Walle [EMAIL PROTECTED]
Great that avoids a DMA kmalloc slab. Any other GFP_DMAs
left in the scsi
layer?
Acked-by: Christoph Lameter [EMAIL PROTECTED]
Yes, here is another patch
Signed-off-by: Aubrey.Li [EMAIL PROTECTED]
---
drivers/scsi/aacraid/commctrl.c | 12 ++--
1 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/scsi/aacraid/commctrl.c
b/drivers/scsi/aacraid/commctrl.c
index 72b0393..405722d 100644
--- a/drivers/scsi/aacraid/commctrl.c
+++ b/drivers/scsi/aacraid/commctrl.c
@@ -580,8 +580,8 @@ static int aac_send_raw_srb(struct aac_dev* dev,
void __user * arg)
for (i = 0; i upsg-count; i++) {
u64 addr;
void* p;
- /* Does this really need to be
GFP_DMA? */
- p =
kmalloc(upsg-sg[i].count,GFP_KERNEL|__GFP_DMA);
+
+ p =
kmalloc(upsg-sg[i].count,GFP_KERNEL);
if(p == 0) {
dprintk((KERN_DEBUGaacraid: Could not allocate SG buffer - size
= %d buffer number %d of %d\n,
upsg-sg[i].count,i,upsg-count));
@@ -624,8 +624,8 @@ static int aac_send_raw_srb(struct aac_dev* dev,
void __user * arg)
for (i = 0; i usg-count; i++) {
u64 addr;
void* p;
- /* Does this really need to be
GFP_DMA? */
- p =
kmalloc(usg-sg[i].count,GFP_KERNEL|__GFP_DMA);
+
+ p =
kmalloc(usg-sg[i].count,GFP_KERNEL);
if(p == 0) {
kfree (usg);
dprintk((KERN_DEBUGaacraid: Could not allocate SG buffer - size
= %d buffer number %d of %d\n,
@@ -666,8 +666,8 @@ static int aac_send_raw_srb(struct aac_dev* dev,
void __user * arg)
for (i = 0; i upsg-count; i++) {
u64 addr;
void* p;
- /* Does this really need to be
GFP_DMA? */
- p =
kmalloc(usg-sg[i].count,GFP_KERNEL|__GFP_DMA);
+
+ p =
kmalloc(usg-sg[i].count,GFP_KERNEL);
if(p == 0) {
dprintk((KERN_DEBUGaacraid: Could not allocate SG buffer - size
= %d buffer number %d of %d\n,
usg-sg[i].count,i,usg-count));
--
1.5.1.1
-
To unsubscribe from this list: send the line unsubscribe
linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
-
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 14/25] SCSI: use irq_handler_t where appropriate
I ACK the portion that resides in aacraid.h, and will track and push it in the future if it does not stick ;- I will comment for any dpt_i2o, ips or aacraid patches posted to the SCSI list from submissions from folks not working at Adaptec once unit tested, accepted into the Adaptec upstreamed source or code inspected; as a matter of form. There will be no *requirement* to cc my maintainer address. Sincerely -- Mark Salyzyn -Original Message- From: James Bottomley [mailto:[EMAIL PROTECTED] Sent: Wednesday, May 23, 2007 6:55 PM To: Jeff Garzik Cc: [EMAIL PROTECTED]; linux-scsi@vger.kernel.org; Salyzyn, Mark; Andrew Vasquez Subject: Re: [patch 14/25] SCSI: use irq_handler_t where appropriate On Wed, 2007-05-23 at 18:07 -0400, Jeff Garzik wrote: [EMAIL PROTECTED] wrote: From: Jeff Garzik [EMAIL PROTECTED] Signed-off-by: Jeff Garzik [EMAIL PROTECTED] Signed-off-by: Andrew Morton [EMAIL PROTECTED] --- drivers/scsi/aacraid/aacraid.h |2 +- drivers/scsi/qla2xxx/qla_isr.c |2 +- 2 files changed, 2 insertions(+), 2 deletions(-) hrm. This appears to have been sent to linux-scsi at least three times. If it doesn't stick, I'll go ahead and send it up myself. It's not a bug fix or even an enhancement. Historically, it is quite difficult to get maintainers to ack these ... particularly if you don't cc them. 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: [patch 14/25] SCSI: use irq_handler_t where appropriate
On Thu, 2007-05-24 at 01:51 -0400, Jeff Garzik wrote: James Bottomley wrote: It's not a bug fix or even an enhancement. Historically, it is quite difficult to get maintainers to ack these ... particularly if you don't cc them. If neither you nor the maintainers are reading and responding to patches sent to linux-scsi, I don't think the problem is sitting in my chair. Oh come off it ... You've been around long enough to know that maintainers are not always watching everything ... it would be nice if they were, but to give a patch the best shot at review, you try to attract their attention. Specifically, in this case, you should cc the maintainers and you should have a subject line explaining that you are modifying their driver. It is very easy to ignore a patch that's simply waved at the SCSI list with a generic subject line. If others have SCSI patches that have been sitting in limbo for weeks or months, send them to me, and I'll queue them in misc-2.6.git#scsi. 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: [patch 14/25] SCSI: use irq_handler_t where appropriate
Not being defensive. This is not just a maintainer's issue. We see the silent ACK treatment all the time from all avenues of inspection whether they be maintainers, illuminati, interested parties or JAFO. There is a little bit of a volunteer in every one of us. Requiring the maintainer to be cc'd is a burden on the submitter, I do not want to spank someone that comes up with a useful patch that fails some bureaucratic litmus test. It is still a good idea, but lets try a different tactic? James, you are a volunteer, so I can not require an increase in your burden. But it would be 'nice' if you had a git tree that reported pending approval (so that makes three persistent trees if I am correct, scsi-misc-2.6, scsi-rc-fixes-2.6 and scsi-pending-2.6?). This way we can tell that you saw it, and as a maintainer we can see a change even if we missed the patch email. It does make it hard for the maintainer to report *which* patch to approve, but he could do a blanket approval of what he sees in the pending tree? AndrewM can tell that he no longer needs to track the patch, as it is now the SCSI list's responsibility once it is in the pending tree. Sincerely -- Mark Salyzyn -Original Message- From: James Bottomley [mailto:[EMAIL PROTECTED] Sent: Thursday, May 24, 2007 10:04 AM To: Jeff Garzik Cc: [EMAIL PROTECTED]; linux-scsi@vger.kernel.org; Salyzyn, Mark; Andrew Vasquez Subject: Re: [patch 14/25] SCSI: use irq_handler_t where appropriate On Thu, 2007-05-24 at 01:51 -0400, Jeff Garzik wrote: James Bottomley wrote: It's not a bug fix or even an enhancement. Historically, it is quite difficult to get maintainers to ack these ... particularly if you don't cc them. If neither you nor the maintainers are reading and responding to patches sent to linux-scsi, I don't think the problem is sitting in my chair. Oh come off it ... You've been around long enough to know that maintainers are not always watching everything ... it would be nice if they were, but to give a patch the best shot at review, you try to attract their attention. Specifically, in this case, you should cc the maintainers and you should have a subject line explaining that you are modifying their driver. It is very easy to ignore a patch that's simply waved at the SCSI list with a generic subject line. If others have SCSI patches that have been sitting in limbo for weeks or months, send them to me, and I'll queue them in misc-2.6.git#scsi. 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: [PATCH] [scsi] Remove __GFP_DMA
On Thu, 2007-05-24 at 09:24 -0400, Salyzyn, Mark wrote: So, is the sequence: p = kmalloc(upsg-sg[i].count,GFP_KERNEL); . . . addr = pci_map_single(dev-pdev, p, upsg-sg[i].count, data_dir); Going to ensure that we have a 31 bit (not 32 bit) physical address? No, unfortunately. Implementing kmalloc_mask() and kmalloc_dev() was something I said I'd do ... about two years ago. If not, then I reject this patch. We can not consider replacement with pci_alloc_consistent until it works on AMD respecting the DMA masks. It should, I believe ... x86_64 has a complex allocation scheme where for masks 32 bit it first tries in GFP_DMA32 and sees if it gets lucky before falling back to GFP_DMA. i386 just goes straight to GFP_DMA. 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: [patch 14/25] SCSI: use irq_handler_t where appropriate
On Thu, 24 May 2007 09:04:06 -0500 James Bottomley wrote: On Thu, 2007-05-24 at 01:51 -0400, Jeff Garzik wrote: James Bottomley wrote: It's not a bug fix or even an enhancement. Historically, it is quite difficult to get maintainers to ack these ... particularly if you don't cc them. If neither you nor the maintainers are reading and responding to patches sent to linux-scsi, I don't think the problem is sitting in my chair. Oh come off it ... You've been around long enough to know that maintainers are not always watching everything ... it would be nice if they were, but to give a patch the best shot at review, you try to attract their attention. Specifically, in this case, you should cc the maintainers and you should have a subject line explaining that you are modifying their driver. It is very easy to ignore a patch that's simply waved at the SCSI list with a generic subject line. I can understand subsystem maintainers ignoring lkml, but ignoring the subsystem mailing list makes no sense to me, especially if the subject contains [PATCH]. If others have SCSI patches that have been sitting in limbo for weeks or months, send them to me, and I'll queue them in misc-2.6.git#scsi. --- ~Randy *** Remember to use Documentation/SubmitChecklist when testing your code *** - 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 14/25] SCSI: use irq_handler_t where appropriate
On Thu, 2007-05-24 at 10:28 -0400, Salyzyn, Mark wrote: This is not just a maintainer's issue. We see the silent ACK treatment all the time from all avenues of inspection whether they be maintainers, illuminati, interested parties or JAFO. There is a little bit of a volunteer in every one of us. Requiring the maintainer to be cc'd is a burden on the submitter, I do not want to spank someone that comes up with a useful patch that fails some bureaucratic litmus test. It is still a good idea, but lets try a different tactic? James, you are a volunteer, so I can not require an increase in your burden. But it would be 'nice' if you had a git tree that reported pending approval (so that makes three persistent trees if I am correct, scsi-misc-2.6, scsi-rc-fixes-2.6 and scsi-pending-2.6?). This way we can tell that you saw it, and as a maintainer we can see a change even if we missed the patch email. It does make it hard for the maintainer to report *which* patch to approve, but he could do a blanket approval of what he sees in the pending tree? AndrewM can tell that he no longer needs to track the patch, as it is now the SCSI list's responsibility once it is in the pending tree. We can certainly try that approach. Please note that scsi-pending-2.6 will essentially be a quilt like tree (i.e. constantly rebasing) so it will be impossible to pull incrementally from it ... but you will be able to fetch from it and just check it out to give the patches an inspection/try out. 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: [patch 14/25] SCSI: use irq_handler_t where appropriate
On Thu, 2007-05-24 at 08:17 -0700, Randy Dunlap wrote: On Thu, 24 May 2007 09:04:06 -0500 James Bottomley wrote: On Thu, 2007-05-24 at 01:51 -0400, Jeff Garzik wrote: James Bottomley wrote: It's not a bug fix or even an enhancement. Historically, it is quite difficult to get maintainers to ack these ... particularly if you don't cc them. If neither you nor the maintainers are reading and responding to patches sent to linux-scsi, I don't think the problem is sitting in my chair. Oh come off it ... You've been around long enough to know that maintainers are not always watching everything ... it would be nice if they were, but to give a patch the best shot at review, you try to attract their attention. Specifically, in this case, you should cc the maintainers and you should have a subject line explaining that you are modifying their driver. It is very easy to ignore a patch that's simply waved at the SCSI list with a generic subject line. I can understand subsystem maintainers ignoring lkml, but ignoring the subsystem mailing list makes no sense to me, especially if the subject contains [PATCH]. SCSI is a slightly different subsystem from almost any other in the kernel. It has something like 15 active driver maintainers plus at least another 15-25 periodically active ones. Most (but not all) driver maintainers are employed by the company who produces the board/chip and tend to be overloaded with a lot of non-linux work. Requiring acks for maintained drivers is a courtesy to make sure we don't get maintainers spending time trying to resolve conflicts. I'm not mandating any particular method of getting acks, just noting that cc'ing maintainers and having specific subject lines mentioning the driver is a reasonable way of getting them to notice. 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: [PATCH 0/8] qla4xxx: Resubmission of patches to add IPv6 support etc
On Wed, 2007-05-23 at 17:45 -0700, David C Somayajulu wrote: This series of patches is a resubmission of the previous patch under the title [RFC] [PATCH] qla4xxx: Updated add IPv6 and misc support bugfixes cleanup as set of smaller patches per Mike Christie's advice/feedback. They contain the following: 1. Support for IPv6 and QLA4032. 2. Bug fixes and clean up to confirm to linux coding style. Just so you know ... I consider a patch labelled [RFC] for discussion only ... i.e. it's not submitted for inclusion into a branch. Additionally, if you have to add the Resubmission: piece to the subject, do it in the initial square brackets like [PATCH 6/8, RESUBMISSION (for the fifteenth time)] qla4xxx: ql4_isr.c support for new mbx cmds That way I don't have to edit the subject line of everything. Thanks, 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: [PATCH v2] add bidi support for block pc requests
FUJITA Tomonori wrote:
FUJITA Tomonori wrote:
One thing that I found is:
+#define scsi_resid(cmd) ((cmd)-sg_table-resid)
This doesn't work for some drivers (at least ipr) since they set
cmd-resid even with commands without data transfer.
James, Tomo.
the last accessor:
+#define scsi_resid(cmd) ((cmd)-resid)
used as an l-value in drivers does not serve our purpose, as seen by the test
implementation of scsi_sg_table. Now clearly this needs an accessor and it is a
bidi parameter (need 2 of them).
I would suggest doing a set_ inline accessor and using that in drivers:
+static inline void scsi_set_resid(struct scsi_cmnd *cmd, resid)
+{
+ cmd-resid = resid;
+}
I would even suggest to make all accessors inlines and not macros just to make
sure
they are not used as l-value and modified. Though I have not seen such use in
Tomo's patchset.
example:
+static inline unsigned scsi_bufflen(struct scsi_cmnd *cmd)
+{
+ return cmd-request_bufflen;
+}
Boaz
-
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
From: Boaz Harrosh [EMAIL PROTECTED] Subject: Re: [PATCH v2] add bidi support for block pc requests Date: Thu, 24 May 2007 19:37:06 +0300 FUJITA Tomonori wrote: FUJITA Tomonori wrote: One thing that I found is: +#define scsi_resid(cmd) ((cmd)-sg_table-resid) This doesn't work for some drivers (at least ipr) since they set cmd-resid even with commands without data transfer. James, Tomo. the last accessor: +#define scsi_resid(cmd) ((cmd)-resid) used as an l-value in drivers does not serve our purpose, as seen by the test implementation of scsi_sg_table. Now clearly this needs an accessor and it is a bidi parameter (need 2 of them). I thought that it would be better to fix several drivers (less than 10). - 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] [scsi] Remove __GFP_DMA
On Thu, 24 May 2007, Salyzyn, Mark wrote: So, is the sequence: p = kmalloc(upsg-sg[i].count,GFP_KERNEL); . . . addr = pci_map_single(dev-pdev, p, upsg-sg[i].count, data_dir); Going to ensure that we have a 31 bit (not 32 bit) physical address? Only if you have less than 2G of memory. So no. - 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
FUJITA Tomonori wrote: From: Boaz Harrosh [EMAIL PROTECTED] Subject: Re: [PATCH v2] add bidi support for block pc requests Date: Thu, 24 May 2007 19:37:06 +0300 FUJITA Tomonori wrote: FUJITA Tomonori wrote: One thing that I found is: +#define scsi_resid(cmd) ((cmd)-sg_table-resid) This doesn't work for some drivers (at least ipr) since they set cmd-resid even with commands without data transfer. James, Tomo. the last accessor: +#define scsi_resid(cmd) ((cmd)-resid) used as an l-value in drivers does not serve our purpose, as seen by the test implementation of scsi_sg_table. Now clearly this needs an accessor and it is a bidi parameter (need 2 of them). I thought that it would be better to fix several drivers (less than 10). I prefer inlines. One - Programmer cannot make mistakes. Why give him the freedom to something he must not do? two - if all/most drivers are doing: if (scsi_sgl(cmd)) scsi_resid(cmd) = 0; Than will it not be better to do the if() inside the API? Boaz - 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] [scsi] Remove __GFP_DMA
On Thu, 24 May 2007, James Bottomley wrote: Going to ensure that we have a 31 bit (not 32 bit) physical address? No, unfortunately. Implementing kmalloc_mask() and kmalloc_dev() was something I said I'd do ... about two years ago. Tell me more about these ideas. - 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] [scsi] Remove __GFP_DMA
On Thu, 2007-05-24 at 10:00 -0700, Christoph Lameter wrote: On Thu, 24 May 2007, James Bottomley wrote: Going to ensure that we have a 31 bit (not 32 bit) physical address? No, unfortunately. Implementing kmalloc_mask() and kmalloc_dev() was something I said I'd do ... about two years ago. Tell me more about these ideas. Oh, it was this Kernel Summit presentation which discussed it http://licensing.steeleye.com/support/papers/kernel_summit_iommu.pdf The writeup of the session is here: http://lwn.net/Articles/144100/ The idea was basically to match an allocation to a device mask. I was going to do a generic implementation (which would probably kmalloc, check the physaddr and fall back to GFP_DMA if we were unlucky) but allow the architectures to override. However, the majority of need (except for the aacraid like devices) was solved by GFP_DMA32 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: [PATCH] [scsi] Remove __GFP_DMA
On Thu, 24 May 2007, James Bottomley wrote: The idea was basically to match an allocation to a device mask. I was going to do a generic implementation (which would probably kmalloc, check the physaddr and fall back to GFP_DMA if we were unlucky) but allow the architectures to override. H... We could actually implement something like it in the slab allocators. The mask parameter would lead the allocator to check if the objects are in a satisfactory range. If not it could examine its partial lists for slabs that satisfy the range. If that does not work then it would eventually go to the page allocator to ask for a page in a fitting range. That wont be fast though. How performance sensitive are the allocations? - 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] [scsi] Remove __GFP_DMA
On Thu, 2007-05-24 at 10:22 -0700, Christoph Lameter wrote: On Thu, 24 May 2007, James Bottomley wrote: The idea was basically to match an allocation to a device mask. I was going to do a generic implementation (which would probably kmalloc, check the physaddr and fall back to GFP_DMA if we were unlucky) but allow the architectures to override. H... We could actually implement something like it in the slab allocators. The mask parameter would lead the allocator to check if the objects are in a satisfactory range. If not it could examine its partial lists for slabs that satisfy the range. If that does not work then it would eventually go to the page allocator to ask for a page in a fitting range. That wont be fast though. How performance sensitive are the allocations? Most of them aren't very. They're usually things that are set at driver intialisation time (shared mailbox memory etc). If the allocation is performance sensitive and has to be done at command or ioctl submission time, we tend to feed the consistent or mapped memory into a dma pool which pre allocates and solves the performance issue. In the aacraid case, the mbox is done at ioctl time, but isn't incredibly performance sensitive. 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 ([EMAIL PROTECTED]) wrote: Robert Jennings wrote: What I meant that is that the kernel tgt code (scsi_tgt*) receives SCSI commands from one lld and send them to another lld instead of sending them to user space. Although the approach of passing SCSI commands from a target LLD to an initiator one without any significant interventions from the target software looks to be nice and simple, you should realize how limited, unsafe and illegal it is, since it badly violates SCSI specs. I think that 'implemented cleanly' means that one scsi_host is assigned to only one initiator. Vladislav listed a number of issues that are inherent in an implementation that does not have a 1:1 relationship of initiators to targets. The vscsi architecture defines the 1:1 relationship; it's imposible to have more than one initiator per target. Just few small notes: 1. As I already wrote, complete 1:1 relationship isn't practically possible, because there is always a local access on the target (i.e. one more initiator) and you can't disable it on practice. I was proposing a 1:1 relationship of initiator to target within the target framework for in-kernel pass-through. We would still have the case that local access on the target is possible; an administrator with privileges neccessary to create a target would have the responsibility to not then access the device locally. This is no different than if I create my root file system on /dev/sda1, I should not also 'dd' data to /dev/sda1 while the system is running. It's a bad idea, but nothing stops me; however this is something that only a root level user can do. This would be the same, these targets in pass-through have permissions by default that do not allow local access by non-root users. 2. 1:1 relationship is a serious limitation for usage cases like an SPI tape library serving backup for several servers on an FC net. Restricting the relationship to 1:1 would be for pass-through devices only, this would not necessarily dictate other target types which could be used for such cases. --Rob - 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 14/25] SCSI: use irq_handler_t where appropriate
James Bottomley wrote: SCSI is a slightly different subsystem from almost any other in the kernel. It has something like 15 active driver maintainers plus at least another 15-25 periodically active ones. Most (but not all) driver maintainers are employed by the company who produces the board/chip and tend to be overloaded with a lot of non-linux work. Requiring acks for maintained drivers is a courtesy to make sure we don't get maintainers spending time trying to resolve conflicts. I'm not mandating any particular method of getting acks, just noting that cc'ing maintainers and having specific subject lines mentioning the driver is a reasonable way of getting them to notice. Linux has never worked that way. We always have a stream of patches that are multi-subsystem cleanups and the like. Blocking these patches for months at a time because individual driver maintainers are off doing non-Linux work is just not realistic. The system is broken, from where I sit. In pretty much every other subsystem in the kernel, the subsystem maintainer makes sure patches don't get stuck in limbo for months. 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: [AIC7xxx] tree things to report
Hello, While trying to obtain scsi log to debug a driver problem, I tried to use netconsole on an old smp system with a 10Mbits pcnet32 ethernet device. But few seconds after enabling netconsole, before launching my scsi test, but after a few console activity the computer freeze hard. Is it a know or expected problem ? (2.6.21 kernel, pcnet32: PCnet/PCI 79C970) Have you some solutions or patch to try ? Will get back my soldering iron to do a serial cable for now. Thanks, Emmanuel. Hi Emmanuel, Emmanuel Fusté wrote: Hello, After one year of rest, I resurrect my old computer, install a 2.6.21 kernel and updated my Debian distro. Tree things to repport: First, a cosmetic thing: I have two scsi sync devices and two async devices. For the first ones, domain validation return the negociated speed and mode. For the second ones, domain validation return nothing. I expect it is just a 'missing feature' but that all went ok. I am right ? scsi0 : Adaptec AIC7XXX EISA/VLB/PCI SCSI HBA DRIVER, Rev 7.0 Adaptec 2940 Ultra2 SCSI adapter aic7890/91: Ultra2 Wide Channel A, SCSI Id=7, 32/253 SCBs scsi 0:0:0:0: Direct-Access IBM DMVS18V 02B0 PQ: 0 ANSI: 3 scsi0:A:0:0: Tagged Queuing enabled. Depth 8 target0:0:0: Beginning Domain Validation target0:0:0: wide asynchronous target0:0:0: FAST-40 WIDE SCSI 80.0 MB/s ST (25ns, offset 31) target0:0:0: Domain Validation skipping write tests target0:0:0: Ending Domain Validation scsi 0:0:3:0: CD-ROMYAMAHA CRW6416S 1.0d PQ: 0 ANSI: 2 target0:0:3: Beginning Domain Validation target0:0:3: FAST-10 SCSI 10.0 MB/s ST (100 ns,offset 15) target0:0:3: Domain Validation skipping write tests target0:0:3: Ending Domain Validation scsi 0:0:4:0: CD-ROMTOSHIBA CD-ROM XM-3501TA 1875 PQ: 0 ANSI: 2 target0:0:4: Beginning Domain Validation target0:0:4: Domain Validation skipping write tests target0:0:4: Ending Domain Validation scsi 0:0:6:0: Sequential-Access WANGTEK 5525ES SCSI REV7 0W PQ: 0 ANSI: 1 target0:0:6: Beginning Domain Validation target0:0:6: Ending Domain Validation Hmm. Have to have a look at it. It should at least report the result ... Secondly, It seems that something is doing weird things with my old CD-ROM reader (XM-3501TA). At some point in time (not really regular), I get this in my logs: May 23 00:45:44 rafale kernel: (scsi0:A:4:0): No or incomplete CDB sent to device. May 23 00:45:44 rafale kernel: (scsi0:A:4:0): Protocol violation in Message-in phase. Attempting to abort. May 23 00:45:44 rafale kernel: (scsi0:A:4:0): Abort Message Sent May 23 00:45:44 rafale kernel: (scsi0:A:4:0): SCB 11 - Abort Completed. And sometimes (but seem related to problems with my cable): May 23 04:32:49 rafale kernel: (scsi0:A:4:0): parity error detected in Status phase. SEQADDR(0xad) SCSIRATE(0x0) May 23 05:13:03 rafale kernel: (scsi0:A:4:0): parity error detected in Status phase. SEQADDR(0xac) SCSIRATE(0x0) Yes, this looks like a cable probrlem. There is no scsi bus freeze, and the device work perfectly without generating other errors. DV problem ? Bad hal daemon interaction ? Defect in the driver trigged by bad hal daemon behavior ? Ach, yes, it could at least be triggered by hal. Not all devices like to be polled by hal, especially if they're in a middle of an operation. CD-RW eg. Kay claimed to have it solved, but I still end up disabling hal :-) Last thing, a now two years problem: cdrwtools -d /dev/sr0 -q still instantly crash the scsibus/cdwriter and the driver never recover. I did not have a new log because of the complete bus crash. Have you new ideas about this problem ?? No, not yet. But it looks as if I finally got some time to look deeper in this problem. Bugzilla's still assigned to me, to it's a constant remainder that something's amiss ... I will try: - to get a log on a usb key - to port patch from Bugzilla Bug 5921 to current kernel. With the previous ones, the driver recover. (but i was experiencing FS corruption but it seems it was not related). - to identify exactly what cdrwtools send to the kernel/driver which cause the crash. What you should do here is: - hook up a serial cable and re-route console messages to that - Switch off syslog (as this might block if the SCSI bus frozen) - Enable scsi debugging (Error, Timeout, Scan, and Midlayer is sufficient) and start cdrwtools. - Send me the log from the serial console. This will give me at least a starting point what's going wrong. Thanks for your patience. Cheers, Hannes -- Dr. Hannes Reinecke zSeries Storage [EMAIL PROTECTED] +49 911 74053 688 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: Markus Rex, HRB 16746 (AG Nürnberg) --- Créez votre adresse électronique [EMAIL PROTECTED] 1
[PATCH] [REPOST] fc_transport: fix sysfs deadlock on vport delete
Repost, patch cut against latest scsi-misc-2.6 When the vport attribute delete is used to delete the vport, sysfs deadlocks waiting for the write to complete, which is waiting for the sysfs teardown to complete. Moved this effort to a work_q element. Took the opportunity to make some other cosmetic changes: - removed tabs in Doc file - replaced with expanded spaces - minor copyright text and author text updates - removed a bunch of trailing whitespace -- james s Signed-off-by: James Smart [EMAIL PROTECTED] diff -upNr a/Documentation/scsi/scsi_fc_transport.txt b/Documentation/scsi/scsi_fc_transport.txt --- a/Documentation/scsi/scsi_fc_transport.txt 2007-05-24 13:18:10.0 -0400 +++ b/Documentation/scsi/scsi_fc_transport.txt 2007-05-24 18:54:09.0 -0400 @@ -31,14 +31,14 @@ Overview: --- New FC standards have defined mechanisms which allows for a single physical - port to appear on as multiple communication ports. Using the N_Port Id + port to appear on as multiple communication ports. Using the N_Port Id Virtualization (NPIV) mechanism, a point-to-point connection to a Fabric can be assigned more than 1 N_Port_ID. Each N_Port_ID appears as a separate port to other endpoints on the fabric, even though it shares one physical link to the switch for communication. Each N_Port_ID can have a unique view of the fabric based on fabric zoning and array lun-masking (just like a normal non-NPIV adapter). Using the Virtual Fabric (VF) - mechanism, adding a fabric header to each frame allows the port to + mechanism, adding a fabric header to each frame allows the port to interact with the Fabric Port to join multiple fabrics. The port will obtain an N_Port_ID on each fabric it joins. Each fabric will have its own unique view of endpoints and configuration parameters. NPIV may be @@ -112,74 +112,74 @@ Device Trees and Vport Objects: fc_rports: /sys/class/fc_remote_ports/rport-17:0-0rport on the physical port /sys/class/fc_remote_ports/rport-18:0-0rport on the vport - + Vport Attributes: --- The new fc_vport class object has the following attributes - node_name: Read_Only + node_name: Read_Only The WWNN of the vport - port_name: Read_Only + port_name: Read_Only The WWPN of the vport - roles:Read_Only + roles: Read_Only Indicates the FC4 roles enabled on the vport. - symbolic_name:Read_Write + symbolic_name: Read_Write A string, appended to the driver's symbolic port name string, which is registered with the switch to identify the vport. For example, a hypervisor could set this string to Xen Domain 2 VM 5 Vport 2, and this set of identifiers can be seen on switch management screens to identify the port. - vport_delete: Write_Only + vport_delete: Write_Only When written with a 1, will tear down the vport. - vport_disable:Write_Only + vport_disable: Write_Only When written with a 1, will transition the vport to a disabled. state. The vport will still be instantiated with the Linux kernel, but it will not be active on the FC link. When written with a 0, will enable the vport. - vport_last_state: Read_Only + vport_last_state: Read_Only Indicates the previous state of the vport. See the section below on Vport States. - vport_state: Read_Only + vport_state: Read_Only Indicates the state of the vport. See the section below on Vport States. - vport_type: Read_Only + vport_type:Read_Only Reflects the FC mechanism used to create the virtual port. Only NPIV is supported currently. For the fc_host class object, the following attributes are added for vports: - max_npiv_vports: Read_Only + max_npiv_vports: Read_Only Indicates the maximum number of NPIV-based vports that the driver/adapter can
Re: [patch 0/7] Asynchronous Notification for ATAPI devices (resend)
Kristen Carlson Accardi wrote: Hi Jeff, Here are the AN patches again, they have not changed with the exception of patch #1, which does set the host flag in board_ahci and board_ahci_pi now (thanks Tejun). This patch series implements Asynchronous Notification (AN) for SATA ATAPI devices as defined in SATA 2.5 and AHCI 1.1 and higher. Drives which support this feature will send a notification when new media is inserted and removed, preventing the need for user space to poll for new media. This support is exposed to user space via a flag that will be set in /sys/block/sr*/capability_flags. If the flag is set, user space can disable polling for the new media, and the genhd driver will send a KOBJ_CHANGE event with the envp set to MEDIA_CHANGE_EVENT=1. Note that this patch only implements support for directly attached drives - AN with drives attached to a port multiplier requires additional changes. Patches look OK to me... it will take some coordination for the non-libata bits. I think Andrew mentioned some of this. And if the SCSI bits get stuck in the SCSI maintainer's bit bucket, let me know. 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: [patch 1/7] libata: check for AN support
Kristen Carlson Accardi wrote: Check to see if an ATAPI device supports Asynchronous Notification. If so, enable it. Signed-off-by: Kristen Carlson Accardi [EMAIL PROTECTED] --- Andrew, I cleaned up the function header to properly comply with kernel doc requirements. Other than that, this patch is the same. I would ask for a simple revision: update ata_dev_set_AN() such that it takes a second argument 'enable'. This boolean indicates to the function whether SETFEATURES_SATA_ENABLE or SETFEATURES_SATA_DISABLE should be passed to the device. Otherwise than that, it's ready to merge I would say. - 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
