Re: /dev/sda with 8 byte offset
Al Viro wrote: > On Wed, Sep 26, 2007 at 10:55:11PM +0200, Stefan Richter wrote: >> Strange. I haven't heard of this before. From which vendor and model >> is the device, and do you know which chip is on its IDE bridge board? > > I've seen it, all right. 8 bytes stuck in FIFO, pl3507 IDE bridge, > and judging by google search that turd is b0rken regardless of the > OS (along the lines of "works under Windows if you power-cycle it > once in about half an hour"). > > Suggested fix: use as a barf-bag; the authors of that thing certainly had > done that. Sounds plausible. I wasn't aware of the particular 8-byte-garbage symptom (or heard of it and forgot it). Some people (regardless if Windows, OS X, or Linux users) were able to make their PL3507 work with new firmware: http://wiki.linux1394.org/FirmwareDownload Very old revisions of the chip don't support firmware upload. And some boards with newer revisions apparently prevent firmware upload with a resistor: http://club.cdfreaks.com/showthread.php?p=957178 -- Stefan Richter -=-=-=== =--= ==-== http://arcgraph.de/sr/ - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/5] add dma_max_segment_size option to scsi_host_template
FUJITA Tomonori wrote:
You are right. scsi_debug's pseudo-bus works.
But probabaly, scsi_debug doesn't need to call
blk_queue_max_segment_size now.
Either way works for me. :)
Maybe dev_set_max_seg() is a better name, if people get really picky (I
don't care).
How about dma_set_max_seg_size()?
diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
index a417a6f..7adadfb 100644
--- a/drivers/scsi/scsi_lib.c
+++ b/drivers/scsi/scsi_lib.c
@@ -1554,6 +1554,7 @@ struct request_queue *__scsi_alloc_queue(struct Scsi_Host
*shost,
request_fn_proc *request_fn)
{
struct request_queue *q;
+ struct device *dev = shost->shost_gendev.parent;
q = blk_init_queue(request_fn, NULL);
if (!q)
@@ -1565,6 +1566,9 @@ struct request_queue *__scsi_alloc_queue(struct Scsi_Host
*shost,
blk_queue_bounce_limit(q, scsi_calculate_bounce_limit(shost));
blk_queue_segment_boundary(q, shost->dma_boundary);
+ if (dev->max_segment_size)
+ blk_queue_max_segment_size(q, dev->max_segment_size);
+
if (!shost->use_clustering)
clear_bit(QUEUE_FLAG_CLUSTER, &q->queue_flags);
return q;
diff --git a/include/linux/device.h b/include/linux/device.h
index 3a38d1f..8046b60 100644
--- a/include/linux/device.h
+++ b/include/linux/device.h
@@ -443,6 +443,13 @@ struct device {
struct dma_coherent_mem *dma_mem; /* internal for coherent mem
override */
+
+ /*
+* a low level driver may set these to teach IOMMU code about
+* sg limitations.
+*/
+ unsigned int max_segment_size;
+
/* arch specific additions */
struct dev_archdata archdata;
diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h
index 2dc21cb..30404b8 100644
--- a/include/linux/dma-mapping.h
+++ b/include/linux/dma-mapping.h
@@ -31,6 +31,11 @@ static inline int valid_dma_direction(int dma_direction)
(dma_direction == DMA_FROM_DEVICE));
}
+static inline void dma_set_max_seg_size(struct device *dev, unsigned int size)
+{
+ dev->max_segment_size = size;
+}
+
Definitely moving in the right direction, IMO. I would suggest a few
minor changes to dma_set_max_seg_size(), to permit platforms to override
the default behavior, and to get people into the habit of checking the
return value (since it might matter in the future):
1) surround with #ifndef ARCH_HAS_DMA_MAX_SEG
2) change return value to 'int'
3) unconditionally return zero, for now.
Otherwise, approach and code look good to me.
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 3/5] add sg segment limitation info to device structure
On Wed, 26 Sep 2007 09:05:58 -0700
Greg KH <[EMAIL PROTECTED]> wrote:
> On Wed, Sep 26, 2007 at 05:58:01PM +0900, FUJITA Tomonori wrote:
> > iommu code merges sg segments without considering lld's sg segment
> > restrictions. iommu code can't access to the limitations because they
> > are in request_queue. This patch adds max_segment_size to device
> > structure. seg_boundary_mask will be added too later.
> >
> > Signed-off-by: FUJITA Tomonori <[EMAIL PROTECTED]>
> > ---
> > include/linux/device.h |7 +++
> > 1 files changed, 7 insertions(+), 0 deletions(-)
> >
> > diff --git a/include/linux/device.h b/include/linux/device.h
> > index 3a38d1f..8046b60 100644
> > --- a/include/linux/device.h
> > +++ b/include/linux/device.h
> > @@ -443,6 +443,13 @@ struct device {
> >
> > struct dma_coherent_mem *dma_mem; /* internal for coherent mem
> > override */
> > +
> > + /*
> > +* a low level driver may set these to teach IOMMU code about
> > +* sg limitations.
> > +*/
> > + unsigned int max_segment_size;
>
> Does this really need to be here? Can't it go into the bus specific
> device that needs this?
dma_map_sg() is bus specific? I think that this really need to
be. It needs to work like dma_mask in device structure.
-
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/5] add dma_max_segment_size option to scsi_host_template
On Wed, 26 Sep 2007 10:42:06 -0400
Jeff Garzik <[EMAIL PROTECTED]> wrote:
> FUJITA Tomonori wrote:
> > On Wed, 26 Sep 2007 06:11:45 -0400
> > Jeff Garzik <[EMAIL PROTECTED]> wrote:
> >
> >> FUJITA Tomonori wrote:
> >>> This patch moves blk_queue_max_segment_size to scsi_alloc_queue from
> >>> llds. It enables scsi_add_host to tells iommu lld's
> >>> dma_max_segment_size. If a low-level driver doesn't specify
> >>> dma_max_segment_size, scsi-ml uses 65536 (MAX_SEGMENT_SIZE). So there
> >>> are not any functional changes.
> >>>
> >>> Signed-off-by: FUJITA Tomonori <[EMAIL PROTECTED]>
> >>> ---
> >>> drivers/scsi/hosts.c |5 +
> >>> drivers/scsi/scsi_lib.c |1 +
> >>> include/scsi/scsi_host.h |6 ++
> >>> 3 files changed, 12 insertions(+), 0 deletions(-)
> >> hm... All the patches look technically correct, but IMO this really
> >> should behave more the the dma_mask interface: platform sets a sane
> >> dma_mask (usually 0x), and LLDD calls dma_set_mask() or
> >> pci_set_dma_mask().
> >>
> >> Thus, IMO an LLDD should call dma_set_max_seg(), and then SCSI midlayer
> >> can obtain that value from struct device.
> >
> > Yeah, I agreed that max_segment_size should work like dma_mask (that's
> > why I simply put max_segment_size to device structure).
>
> Yep!
>
>
> > scsi_debug doesn't use dma but calls blk_queue_max_segment_size (I
> > guess that it wants large I/Os). If we can remove it (thanks to
> > chaining sg), scsi-ml gets that value that llds set via
> > dma_set_max_seg and calls blk_queue_max_segment_size.
>
> [/me checks the code] Actually scsi_debug has its own pseudo-bus and
> struct device, so it sounds like scsi_debug can call dma_set_max_seg()
> just like any other LLDD?
You are right. scsi_debug's pseudo-bus works.
But probabaly, scsi_debug doesn't need to call
blk_queue_max_segment_size now.
> Maybe dev_set_max_seg() is a better name, if people get really picky (I
> don't care).
How about dma_set_max_seg_size()?
diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
index a417a6f..7adadfb 100644
--- a/drivers/scsi/scsi_lib.c
+++ b/drivers/scsi/scsi_lib.c
@@ -1554,6 +1554,7 @@ struct request_queue *__scsi_alloc_queue(struct Scsi_Host
*shost,
request_fn_proc *request_fn)
{
struct request_queue *q;
+ struct device *dev = shost->shost_gendev.parent;
q = blk_init_queue(request_fn, NULL);
if (!q)
@@ -1565,6 +1566,9 @@ struct request_queue *__scsi_alloc_queue(struct Scsi_Host
*shost,
blk_queue_bounce_limit(q, scsi_calculate_bounce_limit(shost));
blk_queue_segment_boundary(q, shost->dma_boundary);
+ if (dev->max_segment_size)
+ blk_queue_max_segment_size(q, dev->max_segment_size);
+
if (!shost->use_clustering)
clear_bit(QUEUE_FLAG_CLUSTER, &q->queue_flags);
return q;
diff --git a/include/linux/device.h b/include/linux/device.h
index 3a38d1f..8046b60 100644
--- a/include/linux/device.h
+++ b/include/linux/device.h
@@ -443,6 +443,13 @@ struct device {
struct dma_coherent_mem *dma_mem; /* internal for coherent mem
override */
+
+ /*
+* a low level driver may set these to teach IOMMU code about
+* sg limitations.
+*/
+ unsigned int max_segment_size;
+
/* arch specific additions */
struct dev_archdata archdata;
diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h
index 2dc21cb..30404b8 100644
--- a/include/linux/dma-mapping.h
+++ b/include/linux/dma-mapping.h
@@ -31,6 +31,11 @@ static inline int valid_dma_direction(int dma_direction)
(dma_direction == DMA_FROM_DEVICE));
}
+static inline void dma_set_max_seg_size(struct device *dev, unsigned int size)
+{
+ dev->max_segment_size = size;
+}
+
#ifdef CONFIG_HAS_DMA
#include
#else
-
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 3/3] NCR53C8XX: Remove deprecated IRQ flags (SA_*)
Hi Matthew, A patch to stop using deprecated IRQ flags in ncr53c8xx documentaion. The new IRQF_* macros are used instead. Signed-off-by: Ahmed S. Darwish <[EMAIL PROTECTED]> --- diff --git a/Documentation/scsi/ChangeLog.ncr53c8xx b/Documentation/scsi/ChangeLog.ncr53c8xx index 7d03e9d..a9f721a 100644 --- a/Documentation/scsi/ChangeLog.ncr53c8xx +++ b/Documentation/scsi/ChangeLog.ncr53c8xx @@ -195,9 +195,9 @@ Sun Feb 14:00 1999 Gerard Roudier ([EMAIL PROTECTED]) Pointed out by Leonard Zubkoff. - Allow to tune request_irq() flags from the boot command line using ncr53c8xx=irqm:??, as follows: - a) If bit 0x10 is set in irqm, SA_SHIRQ flag is not used. - b) If bit 0x20 is set in irqm, SA_INTERRUPT flag is not used. - By default the driver uses both SA_SHIRQ and SA_INTERRUPT. + a) If bit 0x10 is set in irqm, IRQF_SHARED flag is not used. + b) If bit 0x20 is set in irqm, IRQF_DISABLED flag is not used. + By default the driver uses both IRQF_SHARED and IRQF_DISABLED. Option 'ncr53c8xx=irqm:0x20' may be used when an IRQ is shared by a 53C8XX adapter and a network board. - Tiny mispelling fixed (ABORT instead of ABRT). Was fortunately diff --git a/Documentation/scsi/ncr53c8xx.txt b/Documentation/scsi/ncr53c8xx.txt index 39d409a..a65cea9 100644 --- a/Documentation/scsi/ncr53c8xx.txt +++ b/Documentation/scsi/ncr53c8xx.txt @@ -785,8 +785,8 @@ port address 0x1400. irqm:0 always open drain irqm:1 same as initial settings (assumed BIOS settings) irqm:2 always totem pole -irqm:0x10 driver will not use SA_SHIRQ flag when requesting irq -irqm:0x20 driver will not use SA_INTERRUPT flag when requesting irq +irqm:0x10 driver will not use IRQF_SHARED flag when requesting irq +irqm:0x20 driver will not use IRQF_DISABLED flag when requesting irq (Bits 0x10 and 0x20 can be combined with hardware irq mode option) @@ -1236,15 +1236,15 @@ when the SCSI DATA IN phase is reentered after a phase mismatch. When an IRQ is shared by devices that are handled by different drivers, it may happen that one driver complains about the request of the IRQ having failed. Inder Linux-2.0, this may be due to one driver having requested the -IRQ using the SA_INTERRUPT flag but some other having requested the same IRQ +IRQ using the IRQF_DISABLED flag but some other having requested the same IRQ without this flag. Under both Linux-2.0 and linux-2.2, this may be caused by -one driver not having requested the IRQ with the SA_SHIRQ flag. +one driver not having requested the IRQ with the IRQF_SHARED flag. By default, the ncr53c8xx and sym53c8xx drivers request IRQs with both the -SA_INTERRUPT and the SA_SHIRQ flag under Linux-2.0 and with only the SA_SHIRQ +IRQF_DISABLED and the IRQF_SHARED flag under Linux-2.0 and with only the IRQF_SHARED flag under Linux-2.2. -Under Linux-2.0, you can disable use of SA_INTERRUPT flag from the boot +Under Linux-2.0, you can disable use of IRQF_DISABLED flag from the boot command line by using the following option: ncr53c8xx=irqm:0x20 (for the generic ncr53c8xx driver) @@ -1252,7 +1252,7 @@ command line by using the following option: If this does not fix the problem, then you may want to check how all other drivers are requesting the IRQ and report the problem. Note that if at least -a single driver does not request the IRQ with the SA_SHIRQ flag (share IRQ), +a single driver does not request the IRQ with the IRQF_SHARED flag (share IRQ), then the request of the IRQ obviously will not succeed for all the drivers. 15. SCSI problem troubleshooting -- Ahmed S. Darwish HomePage: http://darwish.07.googlepages.com Blog: http://darwish-07.blogspot.com - 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: /dev/sda with 8 byte offset
On Wed, Sep 26, 2007 at 10:55:11PM +0200, Stefan Richter wrote: > Strange. I haven't heard of this before. From which vendor and model > is the device, and do you know which chip is on its IDE bridge board? I've seen it, all right. 8 bytes stuck in FIFO, pl3507 IDE bridge, and judging by google search that turd is b0rken regardless of the OS (along the lines of "works under Windows if you power-cycle it once in about half an hour"). Suggested fix: use as a barf-bag; the authors of that thing certainly had done that. - 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: /dev/sda with 8 byte offset
(Adding Cc: linux-scsi) Stefan Rutzinger wrote: > I experience a very weird offset in the data from my FW disk. It worked > well last time i used it, which is about half a year ago. Unfortunately i > can't tell what exactly changed in the meanwhile, i continued updating > debian testing an think (but am not sure) changed the kernel. However, > this seems to be a real bug which should not be there anyway. > > So, the disk is a USB / firewire disk. It still works fine with USB in > linux and with USB + firewire in Win XP. So the hardware is certainly > still fine. > > But with firewire and linux, there is this problem: > > It't still detected with correct disk geometry and /dev/sda and /dev/sda1 > are recognised. But fdisk -l /dev/sda fails: "Disk /dev/sda doesn't > contain a valid partition table" > > I dd'ed the mbr to a file, once when connected by USB and once when > connected to Firewire and found out with cmp: > > The data in /dev/sda and /dev/sda1 are shifted by an offset of 8 byte in > the firewire case. I.e. there are some additional 8 byte at the beginning > of /dev/sda and /dev/sda1 which should not be there. Have a look at the > cmp output below. Of course fdisk fails then. Strange. I haven't heard of this before. From which vendor and model is the device, and do you know which chip is on its IDE bridge board? Did you ever install new firmware on the device? > Who can help out? > > > Here' some debugging data: > > I tried debian pre-compiled kernel 2.6.15-1-686-smp and 2.6.21-2-686. > > stefaniello:~# cmp -bln16 usb-sda1 ieee-sda1 > 1 353 M-k 40 - > 2 130 X123 S | > 3 220 M-^P 131 Y | > 4 115 M123 S | > 5 123 S 0 ^@ | > 6 127 W 0 ^@ | > 7 111 I125 U | > 8 116 N252 M-*| > 9 64 4353 M-k -- -> 8 byte offset ! > 10 56 .130 X > 11 61 1220 M-^P > 12 0 ^@ 115 M > 13 2 ^B 123 S > 14 100 @127 W > 15 46 &111 I > 16 0 ^@ 116 N > > USB connected: > stefaniello:~# tail /var/log/messages > Sep 20 19:30:47 stefaniello kernel: usb 1-1: new full speed USB device using > uhci_hcd and address 2 > Sep 20 19:30:47 stefaniello kernel: scsi0 : SCSI emulation for USB Mass > Storage devices > Sep 20 19:30:52 stefaniello kernel: Vendor: WDC WD20 Model: 00JB-00GVA0 > Rev: 08.0 > Sep 20 19:30:52 stefaniello kernel: Type: Direct-Access ANSI SCSI > revision: 00 > Sep 20 19:30:52 stefaniello kernel: SCSI device sda: 390721969 512-byte hdwr > sectors (200050 MB) > Sep 20 19:30:52 stefaniello kernel: SCSI device sda: 390721969 512-byte hdwr > sectors (200050 MB) > Sep 20 19:30:52 stefaniello kernel: sda: sda1 > Sep 20 19:30:52 stefaniello kernel: sd 0:0:0:0: Attached scsi disk sda > Sep 20 19:30:53 stefaniello kernel: sda: Current: sense key: No Sense > Sep 20 19:30:53 stefaniello kernel: Additional sense: No additional sense > information > > stefaniello:~# fdisk -l /dev/sda > Disk /dev/sda: 200.0 GB, 200049648128 bytes > 255 heads, 63 sectors/track, 24321 cylinders > Units = cylinders of 16065 * 512 = 8225280 bytes > > Device Boot Start End Blocks Id System > /dev/sda1 1 24321 195358401b W95 FAT32 > > > ieee1394 connected: > > stefaniello:~# tail -f /var/log/messages > Sep 20 19:42:04 stefaniello kernel: scsi1 : SCSI emulation for IEEE-1394 > SBP-2 Devices (This was obviously obtained from Debian's 2.6.15.) > Sep 20 19:42:05 stefaniello kernel: ieee1394: sbp2: Logged into SBP-2 device > Sep 20 19:42:05 stefaniello kernel: Vendor: WDC WD20 Model: 00JB-00GVA0 > Rev: > Sep 20 19:42:05 stefaniello kernel: Type: Direct-Access-RBC ANSI SCSI > revision: 04 > Sep 20 19:42:05 stefaniello kernel: SCSI device sda: 390721968 512-byte hdwr > sectors (200050 MB) > Sep 20 19:42:05 stefaniello kernel: SCSI device sda: 390721968 512-byte hdwr > sectors (200050 MB) > Sep 20 19:42:05 stefaniello kernel: sda: sda1 > Sep 20 19:42:05 stefaniello kernel: sd 1:0:0:0: Attached scsi disk sda > > stefaniello:~# fdisk -l /dev/sda > Disk /dev/sda: 200.0 GB, 200049647616 bytes > 255 heads, 63 sectors/track, 24321 cylinders > Units = cylinders of 16065 * 512 = 8225280 bytes > > Disk /dev/sda doesn't contain a valid partition table I don't know what could cause this. The sbp2 driver did a lot of SCSI command conversions between the RBC and SBC command sets in older kernels, and this was gradually pulled out of sbp2 because the sd driver already handled RBC properly at some point. In Linux 2.6.15, sbp2 had still all this conversion code but it was AFAIK already deadwood. However I don't know if there could really be differences in how very old kernels sent SCSI commands which could cause the device to return data with an offset. Perhaps the problem is not in what data the device returns when sd reads from it, but in where the data is written into buffers. I.e. if going through sbp2, the data might be written 8 bytes
Re: [PATCH] fix leftover from default sdev attribute switch
On Wed, 2007-09-26 at 15:08 -0500, James Bottomley wrote:
> On Wed, 2007-09-26 at 20:32 +0200, Kay Sievers wrote:
> > On Wed, 2007-09-26 at 13:23 -0500, James Bottomley wrote:
> > > On Wed, 2007-09-26 at 19:54 +0200, Kay Sievers wrote:
> > > > Hi James,
> > > > seems we miss the following fix in the current tree.
> > > >
> > > > From: Kay Sievers <[EMAIL PROTECTED]>
> > > > Subject: [SCSI] fix scsi_is_sdev_device() after switch to default sdev
> > > > attributes
> > > >
> > > > Signed-off-by: Kay Sievers <[EMAIL PROTECTED]>
> > > > ---
> > > > diff --git a/drivers/scsi/scsi_sysfs.c b/drivers/scsi/scsi_sysfs.c
> > > > index 0088c4d..8e880ef 100644
> > > > --- a/drivers/scsi/scsi_sysfs.c
> > > > +++ b/drivers/scsi/scsi_sysfs.c
> > > > @@ -995,7 +995,7 @@ void scsi_sysfs_device_initialize(struct
> > > > scsi_device *sdev)
> > > >
> > > > int scsi_is_sdev_device(const struct device *dev)
> > > > {
> > > > - return dev->release == scsi_device_dev_release;
> > > > + return dev->type == &scsi_dev_type;
> > >
> > > This will make the check different from all the others in the
> > > mid-layer ... is there any reason to change it?
> >
> > The release function moved to device_type, so the "hack" with checking
> > for the release pointer at the device doesn't work anymore. With Hannes'
> > patches here on the list, the target and host will get device_type too,
> > and the same way of matching.
>
> So all the other ones are incorrect and need fixing? That's
>
> hosts.c:int scsi_is_host_device(const struct device *dev)
> scsi_scan.c:int scsi_is_target_device(const struct device *dev)
> scsi_transport_fc.c:int scsi_is_fc_rport(const struct device *dev)
> scsi_transport_fc.c:int scsi_is_fc_vport(const struct device *dev)
> scsi_transport_iscsi.c:static int iscsi_is_session_dev(const struct
> device *dev)
> scsi_transport_iscsi.c:static int iscsi_is_conn_dev(const struct device
> *dev)
> scsi_transport_sas.c:int scsi_is_sas_phy(const struct device *dev)
> scsi_transport_sas.c:int scsi_is_sas_port(const struct device *dev)
> scsi_transport_sas.c:int scsi_is_sas_rphy(const struct device *dev)
>
>
> Checking the release function is the way each of these passes the test.
Oh no, they are all correct.
It's just sdev after the conversion from open-coded attribute creation
to "default attributes" created by the core. Sdev uses device_type now,
and device_type has the release function for all devices of that type,
instead of the individually assigned ones.
Hannes' patches convert host and target to device_type so they can join
the scsi-bus in sysfs. They will have the same logic based on device
type instead of the release pointer trick. But that's not in your tree
now.
Kay
-
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] fix leftover from default sdev attribute switch
On Wed, 2007-09-26 at 20:32 +0200, Kay Sievers wrote:
> On Wed, 2007-09-26 at 13:23 -0500, James Bottomley wrote:
> > On Wed, 2007-09-26 at 19:54 +0200, Kay Sievers wrote:
> > > Hi James,
> > > seems we miss the following fix in the current tree.
> > >
> > > From: Kay Sievers <[EMAIL PROTECTED]>
> > > Subject: [SCSI] fix scsi_is_sdev_device() after switch to default sdev
> > > attributes
> > >
> > > Signed-off-by: Kay Sievers <[EMAIL PROTECTED]>
> > > ---
> > > diff --git a/drivers/scsi/scsi_sysfs.c b/drivers/scsi/scsi_sysfs.c
> > > index 0088c4d..8e880ef 100644
> > > --- a/drivers/scsi/scsi_sysfs.c
> > > +++ b/drivers/scsi/scsi_sysfs.c
> > > @@ -995,7 +995,7 @@ void scsi_sysfs_device_initialize(struct scsi_device
> > > *sdev)
> > >
> > > int scsi_is_sdev_device(const struct device *dev)
> > > {
> > > - return dev->release == scsi_device_dev_release;
> > > + return dev->type == &scsi_dev_type;
> >
> > This will make the check different from all the others in the
> > mid-layer ... is there any reason to change it?
>
> The release function moved to device_type, so the "hack" with checking
> for the release pointer at the device doesn't work anymore. With Hannes'
> patches here on the list, the target and host will get device_type too,
> and the same way of matching.
So all the other ones are incorrect and need fixing? That's
hosts.c:int scsi_is_host_device(const struct device *dev)
scsi_scan.c:int scsi_is_target_device(const struct device *dev)
scsi_transport_fc.c:int scsi_is_fc_rport(const struct device *dev)
scsi_transport_fc.c:int scsi_is_fc_vport(const struct device *dev)
scsi_transport_iscsi.c:static int iscsi_is_session_dev(const struct
device *dev)
scsi_transport_iscsi.c:static int iscsi_is_conn_dev(const struct device
*dev)
scsi_transport_sas.c:int scsi_is_sas_phy(const struct device *dev)
scsi_transport_sas.c:int scsi_is_sas_port(const struct device *dev)
scsi_transport_sas.c:int scsi_is_sas_rphy(const struct device *dev)
Checking the release function is the way each of these passes the test.
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: Remove ->done from scsi_cmnd
This whole patch series looks very nice. - 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] fix leftover from default sdev attribute switch
On Wed, 2007-09-26 at 13:23 -0500, James Bottomley wrote:
> On Wed, 2007-09-26 at 19:54 +0200, Kay Sievers wrote:
> > Hi James,
> > seems we miss the following fix in the current tree.
> >
> > From: Kay Sievers <[EMAIL PROTECTED]>
> > Subject: [SCSI] fix scsi_is_sdev_device() after switch to default sdev
> > attributes
> >
> > Signed-off-by: Kay Sievers <[EMAIL PROTECTED]>
> > ---
> > diff --git a/drivers/scsi/scsi_sysfs.c b/drivers/scsi/scsi_sysfs.c
> > index 0088c4d..8e880ef 100644
> > --- a/drivers/scsi/scsi_sysfs.c
> > +++ b/drivers/scsi/scsi_sysfs.c
> > @@ -995,7 +995,7 @@ void scsi_sysfs_device_initialize(struct scsi_device
> > *sdev)
> >
> > int scsi_is_sdev_device(const struct device *dev)
> > {
> > - return dev->release == scsi_device_dev_release;
> > + return dev->type == &scsi_dev_type;
>
> This will make the check different from all the others in the
> mid-layer ... is there any reason to change it?
The release function moved to device_type, so the "hack" with checking
for the release pointer at the device doesn't work anymore. With Hannes'
patches here on the list, the target and host will get device_type too,
and the same way of matching.
Kay
-
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] fix leftover from default sdev attribute switch
On Wed, 2007-09-26 at 19:54 +0200, Kay Sievers wrote:
> Hi James,
> seems we miss the following fix in the current tree.
>
> Thanks,
> Kay
>
>
> From: Kay Sievers <[EMAIL PROTECTED]>
> Subject: [SCSI] fix scsi_is_sdev_device() after switch to default sdev
> attributes
>
> Signed-off-by: Kay Sievers <[EMAIL PROTECTED]>
> ---
> diff --git a/drivers/scsi/scsi_sysfs.c b/drivers/scsi/scsi_sysfs.c
> index 0088c4d..8e880ef 100644
> --- a/drivers/scsi/scsi_sysfs.c
> +++ b/drivers/scsi/scsi_sysfs.c
> @@ -995,7 +995,7 @@ void scsi_sysfs_device_initialize(struct scsi_device
> *sdev)
>
> int scsi_is_sdev_device(const struct device *dev)
> {
> - return dev->release == scsi_device_dev_release;
> + return dev->type == &scsi_dev_type;
This will make the check different from all the others in the
mid-layer ... is there any reason to change it?
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
[PATCH] fix leftover from default sdev attribute switch
Hi James,
seems we miss the following fix in the current tree.
Thanks,
Kay
From: Kay Sievers <[EMAIL PROTECTED]>
Subject: [SCSI] fix scsi_is_sdev_device() after switch to default sdev
attributes
Signed-off-by: Kay Sievers <[EMAIL PROTECTED]>
---
diff --git a/drivers/scsi/scsi_sysfs.c b/drivers/scsi/scsi_sysfs.c
index 0088c4d..8e880ef 100644
--- a/drivers/scsi/scsi_sysfs.c
+++ b/drivers/scsi/scsi_sysfs.c
@@ -995,7 +995,7 @@ void scsi_sysfs_device_initialize(struct scsi_device *sdev)
int scsi_is_sdev_device(const struct device *dev)
{
- return dev->release == scsi_device_dev_release;
+ return dev->type == &scsi_dev_type;
}
EXPORT_SYMBOL(scsi_is_sdev_device);
-
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 3/5] add sg segment limitation info to device structure
On Wed, Sep 26, 2007 at 05:58:01PM +0900, FUJITA Tomonori wrote:
> iommu code merges sg segments without considering lld's sg segment
> restrictions. iommu code can't access to the limitations because they
> are in request_queue. This patch adds max_segment_size to device
> structure. seg_boundary_mask will be added too later.
>
> Signed-off-by: FUJITA Tomonori <[EMAIL PROTECTED]>
> ---
> include/linux/device.h |7 +++
> 1 files changed, 7 insertions(+), 0 deletions(-)
>
> diff --git a/include/linux/device.h b/include/linux/device.h
> index 3a38d1f..8046b60 100644
> --- a/include/linux/device.h
> +++ b/include/linux/device.h
> @@ -443,6 +443,13 @@ struct device {
>
> struct dma_coherent_mem *dma_mem; /* internal for coherent mem
>override */
> +
> + /*
> + * a low level driver may set these to teach IOMMU code about
> + * sg limitations.
> + */
> + unsigned int max_segment_size;
Does this really need to be here? Can't it go into the bus specific
device that needs this?
thanks,
greg k-h
-
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 2/2]: PCI Error Recovery: Symbios SCSI First Failure
On Fri, Apr 20, 2007 at 03:47:20PM -0500, Linas Vepstas wrote: > Implement the so-called "first failure data capture" (FFDC) for the > symbios PCI error recovery. After a PCI error event is reported, > the driver requests that MMIO be enabled. Once enabled, it > then reads and dumps assorted status registers, and concludes > by requesting the usual reset sequence. > + /* Request that MMIO be enabled, so register dump can be taken. */ > + return PCI_ERS_RESULT_CAN_RECOVER; > +} I'm a little concerned by the mention of MMIO. It's entirely possible for the sym2 driver to be using ioports to access the card rather than MMIO. Is it simply that it can't on the platform you test on? -- Intel are signing my paycheques ... these opinions are still mine "Bill, look, we understand that you're interested in selling us this operating system, but compare it to ours. We can't possibly take such a retrograde step." - 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/5] fix iommu sg list merge problem
On Wed, 26 Sep 2007 09:38:32 -0500 James Bottomley <[EMAIL PROTECTED]> wrote: > On Wed, 2007-09-26 at 23:34 +0900, FUJITA Tomonori wrote: > > Yeah, I thought about it and it's possible (but not so easy). parisc > > has IOMMU merging helper code and two parisc IOMMUs use it. ia64 > > sba_iommu is almost identical to parisc code. x86_64 gart, power, and > > alpha do in their own way. But I think that we can merging helper code > > useful for all. > > Er ... it should be identical ... the SBA iommu is the same ... I > thought we moved the common code out to a shared file. 2.6.23-rc8-mm1 has two iommu_coalesce_chunks in drivers/iommu-helpers.h and arch/ioa64/hp/common/sb_iommu.c iommu_coalesce_chunks are almost same. parisc's iommu_coalesce_chunks is simpler a bit. - 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/5] add dma_max_segment_size option to scsi_host_template
FUJITA Tomonori wrote: On Wed, 26 Sep 2007 06:11:45 -0400 Jeff Garzik <[EMAIL PROTECTED]> wrote: FUJITA Tomonori wrote: This patch moves blk_queue_max_segment_size to scsi_alloc_queue from llds. It enables scsi_add_host to tells iommu lld's dma_max_segment_size. If a low-level driver doesn't specify dma_max_segment_size, scsi-ml uses 65536 (MAX_SEGMENT_SIZE). So there are not any functional changes. Signed-off-by: FUJITA Tomonori <[EMAIL PROTECTED]> --- drivers/scsi/hosts.c |5 + drivers/scsi/scsi_lib.c |1 + include/scsi/scsi_host.h |6 ++ 3 files changed, 12 insertions(+), 0 deletions(-) hm... All the patches look technically correct, but IMO this really should behave more the the dma_mask interface: platform sets a sane dma_mask (usually 0x), and LLDD calls dma_set_mask() or pci_set_dma_mask(). Thus, IMO an LLDD should call dma_set_max_seg(), and then SCSI midlayer can obtain that value from struct device. Yeah, I agreed that max_segment_size should work like dma_mask (that's why I simply put max_segment_size to device structure). Yep! scsi_debug doesn't use dma but calls blk_queue_max_segment_size (I guess that it wants large I/Os). If we can remove it (thanks to chaining sg), scsi-ml gets that value that llds set via dma_set_max_seg and calls blk_queue_max_segment_size. [/me checks the code] Actually scsi_debug has its own pseudo-bus and struct device, so it sounds like scsi_debug can call dma_set_max_seg() just like any other LLDD? Maybe dev_set_max_seg() is a better name, if people get really picky (I don't care). 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 0/5] fix iommu sg list merge problem
On Wed, 26 Sep 2007 12:02:21 +0200 Muli Ben-Yehuda <[EMAIL PROTECTED]> wrote: > On Wed, Sep 26, 2007 at 05:57:57PM +0900, FUJITA Tomonori wrote: > > > iommu code merges sg lists without considering lld's restrictions so > > some llds need a workaround to split sg lists again. This patchset > > fixes iommu to handle lld's max segment size limit properly. > > The patches look reasonable to me. > > > This patchset includes only the x86_64 iommu patch > > There are multiple x86-64 IOMMUs, but only GART is in-tree and > supports merging. > > > but my git tree includes x86_64, ppc, ia64, parisc, and alpha > > patches. As far as I know, thye are all the iommu code that merges > > sg lists. The iommu patchse are only compile tested. > > > > > > git://git.kernel.org/pub/scm/linux/kernel/git/tomo/linux-2.6-bidi.git iommu > > Do you think it will be possible to abstract the merging code into > common code, rather than duplicating it for every IOMMU? Yeah, I thought about it and it's possible (but not so easy). parisc has IOMMU merging helper code and two parisc IOMMUs use it. ia64 sba_iommu is almost identical to parisc code. x86_64 gart, power, and alpha do in their own way. But I think that we can merging helper code useful for all. I'll see what we can have after fixing the mering problem. - 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/5] fix iommu sg list merge problem
On Wed, 2007-09-26 at 23:34 +0900, FUJITA Tomonori wrote: > Yeah, I thought about it and it's possible (but not so easy). parisc > has IOMMU merging helper code and two parisc IOMMUs use it. ia64 > sba_iommu is almost identical to parisc code. x86_64 gart, power, and > alpha do in their own way. But I think that we can merging helper code > useful for all. Er ... it should be identical ... the SBA iommu is the same ... I thought we moved the common code out to a shared file. 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 1/5] add dma_max_segment_size option to scsi_host_template
On Wed, 26 Sep 2007 06:11:45 -0400 Jeff Garzik <[EMAIL PROTECTED]> wrote: > FUJITA Tomonori wrote: > > This patch moves blk_queue_max_segment_size to scsi_alloc_queue from > > llds. It enables scsi_add_host to tells iommu lld's > > dma_max_segment_size. If a low-level driver doesn't specify > > dma_max_segment_size, scsi-ml uses 65536 (MAX_SEGMENT_SIZE). So there > > are not any functional changes. > > > > Signed-off-by: FUJITA Tomonori <[EMAIL PROTECTED]> > > --- > > drivers/scsi/hosts.c |5 + > > drivers/scsi/scsi_lib.c |1 + > > include/scsi/scsi_host.h |6 ++ > > 3 files changed, 12 insertions(+), 0 deletions(-) > > hm... All the patches look technically correct, but IMO this really > should behave more the the dma_mask interface: platform sets a sane > dma_mask (usually 0x), and LLDD calls dma_set_mask() or > pci_set_dma_mask(). > > Thus, IMO an LLDD should call dma_set_max_seg(), and then SCSI midlayer > can obtain that value from struct device. Yeah, I agreed that max_segment_size should work like dma_mask (that's why I simply put max_segment_size to device structure). scsi_debug doesn't use dma but calls blk_queue_max_segment_size (I guess that it wants large I/Os). If we can remove it (thanks to chaining sg), scsi-ml gets that value that llds set via dma_set_max_seg and calls blk_queue_max_segment_size. - 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: scsi-misc build breakage
On Wed, 2007-09-26 at 00:36 -0400, Jeff Garzik wrote:
> current scsi-misc on i386 says:
>
> drivers/scsi/arcmsr/arcmsr_hba.c:129: error: ‘arcmsr_pci_error_detected’
> undeclared here (not in a function)
> drivers/scsi/arcmsr/arcmsr_hba.c:130: error: ‘arcmsr_pci_slot_reset’
> undeclared here (not in a function)
> make[2]: *** [drivers/scsi/arcmsr/arcmsr_hba.o] Error 1
> make[1]: *** [drivers/scsi/arcmsr] Error 2
That's my fault ... I took the templates out of the code because it was
giving warnings about static defined but unused functions. I must be
compiling without CONFIG_SCSI_ARCMSR_AER.
This should fix it.
James
diff --git a/drivers/scsi/arcmsr/arcmsr_hba.c b/drivers/scsi/arcmsr/arcmsr_hba.c
index f4d2d52..449bceb 100644
--- a/drivers/scsi/arcmsr/arcmsr_hba.c
+++ b/drivers/scsi/arcmsr/arcmsr_hba.c
@@ -125,6 +125,10 @@ static struct scsi_host_template arcmsr_scsi_host_template
= {
.shost_attrs= arcmsr_host_attrs,
};
#ifdef CONFIG_SCSI_ARCMSR_AER
+static pci_ers_result_t arcmsr_pci_error_detected(struct pci_dev *pdev,
+ pci_channel_state_t state);
+static pci_ers_result_t arcmsr_pci_slot_reset(struct pci_dev *pdev);
+
static struct pci_error_handlers arcmsr_pci_error_handlers = {
.error_detected = arcmsr_pci_error_detected,
.slot_reset = arcmsr_pci_slot_reset,
-
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: queued patches for SCSI for 2.6.24
On Wed, 2007-09-26 at 13:56 +0900, FUJITA Tomonori wrote:
> On Tue, 25 Sep 2007 22:45:53 -0500
> James Bottomley <[EMAIL PROTECTED]> wrote:
>
> > On Tue, 2007-09-25 at 23:34 -0400, Jeff Garzik wrote:
> > > Matthew Wilcox wrote:
> > > > On Tue, Sep 25, 2007 at 10:37:33PM -0400, Jeff Garzik wrote:
> > > >> Are there any const-ness worries for scsi_host_template, or plans for
> > > >> the future? I do not see any other examples of the host template
> > > >> members getting modified.
> > > >
> > > > Goodness, Jeff, you haven't looked too hard. There's dozens of examples
> > > > I've come across trawling the horrible unmaintained drivers. I'd love
> > > > to see scsi_host_template become const, but it's not happening any time
> > > > soon, and we can address this little piece when the time comes.
> > >
> > > Well, sure, the driver is the owner of that memory.
> > >
> > > We're talking about common code.
> > >
> > > If everybody agrees SHT is R/W in the core, Fujita-san's patch is fine.
> >
> > Well, I don't like mucking with the template either.
> >
> > This whole mess is generated basically because the zero default of the
> > template should be treated as initiator. How about this, which makes
> > that manifest?
> >
> > James
> >
> > diff --git a/drivers/scsi/hosts.c b/drivers/scsi/hosts.c
> > index adc9559..7e26440 100644
> > --- a/drivers/scsi/hosts.c
> > +++ b/drivers/scsi/hosts.c
> > @@ -342,7 +342,11 @@ struct Scsi_Host *scsi_host_alloc(struct
> > scsi_host_template *sht, int privsize)
> > shost->unchecked_isa_dma = sht->unchecked_isa_dma;
> > shost->use_clustering = sht->use_clustering;
> > shost->ordered_tag = sht->ordered_tag;
> > - shost->active_mode = sht->supported_mode;
> > + if (sht->supported_mode == MODE_UNKNOWN)
> > + /* means we didn't set it ... default to INITIATOR */
> > + shost->active_mode = MODE_INITIATOR;
> > + else
> > + shost->active_mode = sht->supported_mode;
> >
> > if (sht->max_host_blocked)
> > shost->max_host_blocked = sht->max_host_blocked;
> > diff --git a/drivers/scsi/scsi_sysfs.c b/drivers/scsi/scsi_sysfs.c
> > index 0088c4d..4965e9e 100644
> > --- a/drivers/scsi/scsi_sysfs.c
> > +++ b/drivers/scsi/scsi_sysfs.c
> > @@ -209,11 +209,13 @@ show_shost_mode(unsigned int mode, char *buf)
> > static ssize_t show_shost_supported_mode(struct class_device *class_dev,
> > char *buf)
> > {
> > struct Scsi_Host *shost = class_to_shost(class_dev);
> > + unsigned int supported_mode = shost->hostt->supported_mode;
> >
> > - if (shost->hostt->supported_mode == MODE_UNKNOWN)
> > - return snprintf(buf, 20, "unknown\n");
> > - else
> > - return show_shost_mode(shost->hostt->supported_mode, buf);
> > + if (supported_mode == MODE_UNKNOWN)
> > + /* by default this should be initiator */
> > + supported_mode = MODE_INITIATOR;
> > +
> > + return show_shost_mode(shost->hostt->supported_mode, buf);
>
> should be:
>
> return show_shost_mode(supported_mode, buf);
Yes, sorry ... code in haste etc.
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: queued patches for SCSI for 2.6.24
On Wed, Sep 26, 2007 at 10:50:20AM +0200, Stefan Boresch wrote: > Just curious: Is the patch for scsi_transport_spi.c you sent me for my > hardware problem going to make it into an official kernel? That patch has been requested to go into 2.6.23, so isn't in this list. -- Intel are signing my paycheques ... these opinions are still mine "Bill, look, we understand that you're interested in selling us this operating system, but compare it to ours. We can't possibly take such a retrograde step." - 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/5] add dma_max_segment_size option to scsi_host_template
FUJITA Tomonori wrote: This patch moves blk_queue_max_segment_size to scsi_alloc_queue from llds. It enables scsi_add_host to tells iommu lld's dma_max_segment_size. If a low-level driver doesn't specify dma_max_segment_size, scsi-ml uses 65536 (MAX_SEGMENT_SIZE). So there are not any functional changes. Signed-off-by: FUJITA Tomonori <[EMAIL PROTECTED]> --- drivers/scsi/hosts.c |5 + drivers/scsi/scsi_lib.c |1 + include/scsi/scsi_host.h |6 ++ 3 files changed, 12 insertions(+), 0 deletions(-) hm... All the patches look technically correct, but IMO this really should behave more the the dma_mask interface: platform sets a sane dma_mask (usually 0x), and LLDD calls dma_set_mask() or pci_set_dma_mask(). Thus, IMO an LLDD should call dma_set_max_seg(), and then SCSI midlayer can obtain that value from struct device. Just like dma_mask, I think we can avoid a scsi_host_template addition. I echo Jens sentiment, though, in closing: thanks for doing this work, it's been needed for quite a while. 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 0/5] fix iommu sg list merge problem
On Wed, Sep 26, 2007 at 05:57:57PM +0900, FUJITA Tomonori wrote: > iommu code merges sg lists without considering lld's restrictions so > some llds need a workaround to split sg lists again. This patchset > fixes iommu to handle lld's max segment size limit properly. The patches look reasonable to me. > This patchset includes only the x86_64 iommu patch There are multiple x86-64 IOMMUs, but only GART is in-tree and supports merging. > but my git tree includes x86_64, ppc, ia64, parisc, and alpha > patches. As far as I know, thye are all the iommu code that merges > sg lists. The iommu patchse are only compile tested. > > > git://git.kernel.org/pub/scm/linux/kernel/git/tomo/linux-2.6-bidi.git iommu Do you think it will be possible to abstract the merging code into common code, rather than duplicating it for every IOMMU? Cheers, Muli - 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
reversing quiescing from user space
Hi, I am getting an oops with a scsi disk put into quiesced state. Is there an easy way to reverse this from user space so I can cleanly reboot? Regards Oliver - 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/5] add dma_max_segment_size option to scsi_host_template
On Wed, Sep 26 2007, FUJITA Tomonori wrote: > This patch moves blk_queue_max_segment_size to scsi_alloc_queue from > llds. It enables scsi_add_host to tells iommu lld's > dma_max_segment_size. If a low-level driver doesn't specify > dma_max_segment_size, scsi-ml uses 65536 (MAX_SEGMENT_SIZE). So there > are not any functional changes. > > Signed-off-by: FUJITA Tomonori <[EMAIL PROTECTED]> > --- > drivers/scsi/hosts.c |5 + > drivers/scsi/scsi_lib.c |1 + > include/scsi/scsi_host.h |6 ++ > 3 files changed, 12 insertions(+), 0 deletions(-) > > diff --git a/drivers/scsi/hosts.c b/drivers/scsi/hosts.c > index 96bc312..22877d3 100644 > --- a/drivers/scsi/hosts.c > +++ b/drivers/scsi/hosts.c > @@ -365,6 +365,11 @@ struct Scsi_Host *scsi_host_alloc(struct > scsi_host_template *sht, int privsize) > else > shost->dma_boundary = 0x; > > + if (sht->dma_max_segment_size) > + shost->dma_max_segment_size = sht->dma_max_segment_size; > + else > + shost->dma_max_segment_size = 65536; Use MAX_SEGMENT_SIZE here, instead of manually entering 64k? Otherwise everything looks good from a quick look, it's definitely missing functionality that we have wanted for quite some time! -- Jens Axboe - 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/5] add dma_max_segment_size option to scsi_host_template
This patch moves blk_queue_max_segment_size to scsi_alloc_queue from
llds. It enables scsi_add_host to tells iommu lld's
dma_max_segment_size. If a low-level driver doesn't specify
dma_max_segment_size, scsi-ml uses 65536 (MAX_SEGMENT_SIZE). So there
are not any functional changes.
Signed-off-by: FUJITA Tomonori <[EMAIL PROTECTED]>
---
drivers/scsi/hosts.c |5 +
drivers/scsi/scsi_lib.c |1 +
include/scsi/scsi_host.h |6 ++
3 files changed, 12 insertions(+), 0 deletions(-)
diff --git a/drivers/scsi/hosts.c b/drivers/scsi/hosts.c
index 96bc312..22877d3 100644
--- a/drivers/scsi/hosts.c
+++ b/drivers/scsi/hosts.c
@@ -365,6 +365,11 @@ struct Scsi_Host *scsi_host_alloc(struct
scsi_host_template *sht, int privsize)
else
shost->dma_boundary = 0x;
+ if (sht->dma_max_segment_size)
+ shost->dma_max_segment_size = sht->dma_max_segment_size;
+ else
+ shost->dma_max_segment_size = 65536;
+
rval = scsi_setup_command_freelist(shost);
if (rval)
goto fail_kfree;
diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
index a417a6f..2ec77a9 100644
--- a/drivers/scsi/scsi_lib.c
+++ b/drivers/scsi/scsi_lib.c
@@ -1564,6 +1564,7 @@ struct request_queue *__scsi_alloc_queue(struct Scsi_Host
*shost,
blk_queue_max_sectors(q, shost->max_sectors);
blk_queue_bounce_limit(q, scsi_calculate_bounce_limit(shost));
blk_queue_segment_boundary(q, shost->dma_boundary);
+ blk_queue_max_segment_size(q, shost->dma_max_segment_size);
if (!shost->use_clustering)
clear_bit(QUEUE_FLAG_CLUSTER, &q->queue_flags);
diff --git a/include/scsi/scsi_host.h b/include/scsi/scsi_host.h
index 3b8a6a8..1eb8435 100644
--- a/include/scsi/scsi_host.h
+++ b/include/scsi/scsi_host.h
@@ -383,6 +383,11 @@ struct scsi_host_template {
unsigned long dma_boundary;
/*
+* dma scatter gather segment size limit.
+*/
+ unsigned int dma_max_segment_size;
+
+ /*
* This specifies "machine infinity" for host templates which don't
* limit the transfer size. Note this limit represents an absolute
* maximum, and may be over the transfer limits allowed for
@@ -571,6 +576,7 @@ struct Scsi_Host {
short unsigned int sg_tablesize;
short unsigned int max_sectors;
unsigned long dma_boundary;
+ unsigned int dma_max_segment_size;
/*
* Used to assign serial numbers to the cmds.
* Protected by the host lock.
--
1.5.2.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 4/5] scsi_add_host sets device max_segment_size
scsi_add_host sets shost_gendev.parent->max_segment_size to enables iommu code to merge sg lists properly about lld's max segment size limit. Signed-off-by: FUJITA Tomonori <[EMAIL PROTECTED]> --- drivers/scsi/hosts.c |3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/drivers/scsi/hosts.c b/drivers/scsi/hosts.c index 22877d3..a71a836 100644 --- a/drivers/scsi/hosts.c +++ b/drivers/scsi/hosts.c @@ -206,6 +206,9 @@ int scsi_add_host(struct Scsi_Host *shost, struct device *dev) if (!shost->shost_gendev.parent) shost->shost_gendev.parent = dev ? dev : &platform_bus; + if (dev) + dev->max_segment_size = shost->dma_max_segment_size; + error = device_add(&shost->shost_gendev); if (error) goto out; -- 1.5.2.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/5] fix iommu sg list merge problem
iommu code merges sg lists without considering lld's restrictions so some llds need a workaround to split sg lists again. This patchset fixes iommu to handle lld's max segment size limit properly. The problem is that iommu code can't access to the restrictions because they are in request_queue. iommu code can access to only device structure. I chose the simplest approach, adding max_segment_size to device structure. We could remove the lld restrictions in request_queue strucutre and have a new strucutre (something like struct io_restrictions). Then somehow we could link the new structure with request_queue and device strucutres. But iommu needs only max_segment_size and seg_boundary_mask, so the simplest approach is not so bad, I think. scsi_add_host sets shost_gendev.parent->max_segment_size for iommu code (copied form shost->dma_max_segment_size). This patchset includes only the x86_64 iommu patch but my git tree includes x86_64, ppc, ia64, parisc, and alpha patches. As far as I know, thye are all the iommu code that merges sg lists. The iommu patchse are only compile tested. git://git.kernel.org/pub/scm/linux/kernel/git/tomo/linux-2.6-bidi.git iommu 3 llds, aacraid, scsi_debug, and sata_inic162x sets shost->dma_max_segment_size in slave_configure hook. But dma_max_segment_size is a lld restriction. I adds dma_max_segment_size to scsi_host_template and scsi_host. llds specify dma_max_segment_size in scsi_host_template, scsi-ml sets dma_max_segment_size in devices and call blk_queue_max_segment_size. This patchset includes only the sata_inic162x patch but all the patches for llds, aacraid and scsi_debug are in the git tree. - 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 3/5] add sg segment limitation info to device structure
iommu code merges sg segments without considering lld's sg segment
restrictions. iommu code can't access to the limitations because they
are in request_queue. This patch adds max_segment_size to device
structure. seg_boundary_mask will be added too later.
Signed-off-by: FUJITA Tomonori <[EMAIL PROTECTED]>
---
include/linux/device.h |7 +++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/include/linux/device.h b/include/linux/device.h
index 3a38d1f..8046b60 100644
--- a/include/linux/device.h
+++ b/include/linux/device.h
@@ -443,6 +443,13 @@ struct device {
struct dma_coherent_mem *dma_mem; /* internal for coherent mem
override */
+
+ /*
+* a low level driver may set these to teach IOMMU code about
+* sg limitations.
+*/
+ unsigned int max_segment_size;
+
/* arch specific additions */
struct dev_archdata archdata;
--
1.5.2.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 5/5] x86-64: pci-gart iommu uses max_segment_size
This enables pci-gart iommu to merge sg lists properly about lld's max
segment size limit.
Signed-off-by: FUJITA Tomonori <[EMAIL PROTECTED]>
---
arch/x86_64/kernel/pci-gart.c |6 ++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/arch/x86_64/kernel/pci-gart.c b/arch/x86_64/kernel/pci-gart.c
index 4918c57..be98341 100644
--- a/arch/x86_64/kernel/pci-gart.c
+++ b/arch/x86_64/kernel/pci-gart.c
@@ -381,6 +381,7 @@ int gart_map_sg(struct device *dev, struct scatterlist *sg,
int nents, int dir)
int start;
unsigned long pages = 0;
int need = 0, nextneed;
+ unsigned len;
if (nents == 0)
return 0;
@@ -390,6 +391,7 @@ int gart_map_sg(struct device *dev, struct scatterlist *sg,
int nents, int dir)
out = 0;
start = 0;
+ len = 0;
for (i = 0; i < nents; i++) {
struct scatterlist *s = &sg[i];
dma_addr_t addr = page_to_phys(s->page) + s->offset;
@@ -404,16 +406,20 @@ int gart_map_sg(struct device *dev, struct scatterlist
*sg, int nents, int dir)
/* Can only merge when the last chunk ends on a page
boundary and the new one doesn't have an offset. */
if (!iommu_merge || !nextneed || !need || s->offset ||
+ (dev->max_segment_size &&
+dev->max_segment_size < s->length + len) ||
(ps->offset + ps->length) % PAGE_SIZE) {
if (dma_map_cont(sg, start, i, sg+out, pages,
need) < 0)
goto error;
out++;
+ len = 0;
pages = 0;
start = i;
}
}
+ len += s->length;
need = nextneed;
pages += to_pages(s->offset, s->length);
}
--
1.5.2.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 2/5] sata_inic162x: use dma_max_segment_size in scsi_host_template
This removes blk_queue_max_segment_size and uses dma_max_segment_size
in scsi_host_template.
Signed-off-by: FUJITA Tomonori <[EMAIL PROTECTED]>
---
drivers/ata/sata_inic162x.c | 19 +++
1 files changed, 7 insertions(+), 12 deletions(-)
diff --git a/drivers/ata/sata_inic162x.c b/drivers/ata/sata_inic162x.c
index fdbed8e..ae3590f 100644
--- a/drivers/ata/sata_inic162x.c
+++ b/drivers/ata/sata_inic162x.c
@@ -108,17 +108,11 @@ struct inic_port_priv {
u8 cached_pirq_mask;
};
-static int inic_slave_config(struct scsi_device *sdev)
-{
- /* This controller is braindamaged. dma_boundary is 0x
-* like others but it will lock up the whole machine HARD if
-* 65536 byte PRD entry is fed. Reduce maximum segment size.
-*/
- blk_queue_max_segment_size(sdev->request_queue, 65536 - 512);
-
- return ata_scsi_slave_config(sdev);
-}
-
+/*
+ * This controller is braindamaged. dma_boundary is 0x
+ * like others but it will lock up the whole machine HARD if
+ * 65536 byte PRD entry is fed. Reduce maximum segment size.
+ */
static struct scsi_host_template inic_sht = {
.module = THIS_MODULE,
.name = DRV_NAME,
@@ -132,7 +126,8 @@ static struct scsi_host_template inic_sht = {
.use_clustering = ATA_SHT_USE_CLUSTERING,
.proc_name = DRV_NAME,
.dma_boundary = ATA_DMA_BOUNDARY,
- .slave_configure= inic_slave_config,
+ .dma_max_segment_size = 65536 - 512,
+ .slave_configure= ata_scsi_slave_config,
.slave_destroy = ata_scsi_slave_destroy,
.bios_param = ata_std_bios_param,
};
--
1.5.2.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
Re: queued patches for SCSI for 2.6.24
On Tue, Sep 25, 2007 at 08:00:02PM -0500, James Bottomley wrote: > Andrew asked that I provide a status report of pending updates. The > list is attached below. It's pretty much driver updates and minor bug > fixes. The main functionality changes are Kay's sysfs updates and the > shift of the ULD attachement towards the block prep function. > [snip] Just curious: Is the patch for scsi_transport_spi.c you sent me for my hardware problem going to make it into an official kernel? (Referring to your patch which you posted under: [PATCH] scsi_transport_spi: fix domain validation failure from incorrect width setting ) Arguably, it works around a hardware problem of mine, but it could make also for others the differences of a machine not booting at all and one that at least comes up and is usable ... Sincerely, Stefan Boresch -- Stefan Boresch Institute for Computational Biological Chemistry University of Vienna, Waehringerstr. 17 A-1090 Vienna, Austria Phone: -43-1-427752715Fax: -43-1-427752790 - 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] SCSI: export sas_hash_addr()
sas_hash_addr() is the spec-defined standard hashing function. Make it available to drivers that need it. Signed-off-by: Jeff Garzik <[EMAIL PROTECTED]> diff --git a/drivers/scsi/libsas/sas_init.c b/drivers/scsi/libsas/sas_init.c index 9cd5abe..13c3d21 100644 --- a/drivers/scsi/libsas/sas_init.c +++ b/drivers/scsi/libsas/sas_init.c @@ -314,3 +314,4 @@ module_exit(sas_class_exit); EXPORT_SYMBOL_GPL(sas_register_ha); EXPORT_SYMBOL_GPL(sas_unregister_ha); +EXPORT_SYMBOL_GPL(sas_hash_addr); - 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
