Re: [PATCH] fix req->cmd == INT cases
On Wed, Jun 20 2007, Rene Herman wrote: > On 06/20/2007 02:24 PM, Jens Axboe wrote: > > >On Wed, Jun 20 2007, Christoph Hellwig wrote: > >>On Wed, Jun 20, 2007 at 01:53:32PM +0300, Boaz Harrosh wrote: > > >>> drivers/cdrom/aztcd.c > >>> drivers/cdrom/cm206.c > >>> drivers/cdrom/gscd.c > >>> drivers/cdrom/mcdx.c > >>> drivers/cdrom/optcd.c > >>> drivers/cdrom/sjcd.c > >>> > >>These are old cdrom drivers that are broken in various ways and > >>probably should be killed off aswell. > > > >I agree (with both sentiments), would anyone mind if I just killed them > >off? > > I wouldn't. As far as I'm concerned everything in drivers/cdrom except > viocd.c and cdrom.c itself can go, assuming I'll be allowed to bring back > support for the legacy cdrom types I'd still like to have supported -- in > the first place mitsumi (mcdx), panasonic (sbpcd) and sony (cdu31a) and > perhaps at some point other types if/when I happen across the hardware. Sure, a working clean driver would always be allowed in. I'll remove the legacy drivers in 2.6.23. > The old drivers serve as a source of hardware information but at least > mcdx was broken in so many ways that it only did so at the source > level. When I wanted to check throughput with the old driver I > actually had to go back as far as 2.0.34 to find a working driver (the > old mcd.c, already removed since 2.6.10). 2.0.34 sources are available > from kernel.org, and 2.6.22 sources even from my local machine... Heh, that's pretty scary! > >mitsumi support is being reworked, that can get reintroduced once the > >driver is in a stable state. > > ... which, by the way, is still waiting on comment from anyone with a clue > as to why it makes the machine go boom (easily repeatable when using CFQ, > not or not easily when using AS): > > http://lkml.org/lkml/2007/6/4/50 Yeah I know, I will get around to it eventually. -- 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
Re: [PATCH] aacraid: add cpu cache flush after kmapping and modifying a page
Salyzyn, Mark wrote: > Updated patch to address overlap with patches introduced by FUJITA > Tomonori <[EMAIL PROTECTED]>. Tejun, please inspect. I'm sorry but this patch is really out of my hand. James? -- tejun - 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 req->cmd == INT cases
On 06/20/2007 02:24 PM, Jens Axboe wrote: On Wed, Jun 20 2007, Christoph Hellwig wrote: On Wed, Jun 20, 2007 at 01:53:32PM +0300, Boaz Harrosh wrote: drivers/cdrom/aztcd.c drivers/cdrom/cm206.c drivers/cdrom/gscd.c drivers/cdrom/mcdx.c drivers/cdrom/optcd.c drivers/cdrom/sjcd.c These are old cdrom drivers that are broken in various ways and probably should be killed off aswell. I agree (with both sentiments), would anyone mind if I just killed them off? I wouldn't. As far as I'm concerned everything in drivers/cdrom except viocd.c and cdrom.c itself can go, assuming I'll be allowed to bring back support for the legacy cdrom types I'd still like to have supported -- in the first place mitsumi (mcdx), panasonic (sbpcd) and sony (cdu31a) and perhaps at some point other types if/when I happen across the hardware. The old drivers serve as a source of hardware information but at least mcdx was broken in so many ways that it only did so at the source level. When I wanted to check throughput with the old driver I actually had to go back as far as 2.0.34 to find a working driver (the old mcd.c, already removed since 2.6.10). 2.0.34 sources are available from kernel.org, and 2.6.22 sources even from my local machine... mitsumi support is being reworked, that can get reintroduced once the driver is in a stable state. ... which, by the way, is still waiting on comment from anyone with a clue as to why it makes the machine go boom (easily repeatable when using CFQ, not or not easily when using AS): http://lkml.org/lkml/2007/6/4/50 Rene. - 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] Enable Aggressive Link Power management for AHCI controllers.
Enable Aggressive Link Power management for AHCI controllers.
This patch will set the correct bits to turn on Aggressive
Link Power Management (ALPM) for the ahci driver. This
will cause the controller and disk to negotiate a lower
power state for the link when there is no activity (see
the AHCI 1.x spec for details). This feature is mutually
exclusive with Hot Plug, so when ALPM is enabled, Hot Plug
is disabled. ALPM will be enabled by default, but it is
settable via the scsi host syfs interface. Possible
settings for this feature are:
Setting Effect
--
min_power ALPM is enabled, and link set to enter
lowest power state (SLUMBER) when idle
Hot plug not allowed.
max_performance ALPM is disabled, Hot Plug is allowed
medium_powerALPM is enabled, and link set to enter
second lowest power state (PARTIAL) when
idle. Hot plug not allowed.
Signed-off-by: Kristen Carlson Accardi <[EMAIL PROTECTED]>
---
I've changed this patch to define "disable_pm", and to change
the behavior of ahci_disable_alpm() to not change the link
pm policy, and just turn off alpm.
this whole patch series can be found here:
http://www.kernel.org/pub/linux/kernel/people/kristen/patches/SATA/alpm/
Index: 2.6-git/drivers/ata/ahci.c
===
--- 2.6-git.orig/drivers/ata/ahci.c
+++ 2.6-git/drivers/ata/ahci.c
@@ -48,6 +48,9 @@
#define DRV_NAME "ahci"
#define DRV_VERSION"2.2"
+static int ahci_enable_alpm(struct ata_port *ap,
+ enum scsi_host_link_pm policy);
+static int ahci_disable_alpm(struct ata_port *ap);
enum {
AHCI_PCI_BAR= 5,
@@ -97,6 +100,7 @@ enum {
/* HOST_CAP bits */
HOST_CAP_SSC= (1 << 14), /* Slumber capable */
HOST_CAP_CLO= (1 << 24), /* Command List Override support */
+ HOST_CAP_ALPM = (1 << 26), /* Aggressive Link PM support */
HOST_CAP_SSS= (1 << 27), /* Staggered Spin-up */
HOST_CAP_NCQ= (1 << 30), /* Native Command Queueing */
HOST_CAP_64 = (1 << 31), /* PCI DAC (64-bit DMA) support */
@@ -151,6 +155,8 @@ enum {
PORT_IRQ_PIOS_FIS | PORT_IRQ_D2H_REG_FIS,
/* PORT_CMD bits */
+ PORT_CMD_ASP= (1 << 27), /* Aggressive Slumber/Partial */
+ PORT_CMD_ALPE = (1 << 26), /* Aggressive Link PM enable */
PORT_CMD_ATAPI = (1 << 24), /* Device is ATAPI */
PORT_CMD_LIST_ON= (1 << 15), /* cmd list DMA engine running */
PORT_CMD_FIS_ON = (1 << 14), /* FIS DMA engine running */
@@ -171,6 +177,7 @@ enum {
AHCI_FLAG_HONOR_PI = (1 << 26), /* honor PORTS_IMPL */
AHCI_FLAG_IGN_SERR_INTERNAL = (1 << 27), /* ignore SERR_INTERNAL */
AHCI_FLAG_32BIT_ONLY= (1 << 28), /* force 32bit */
+ AHCI_FLAG_NO_HOTPLUG= (1 << 29), /* ignore PxSERR.DIAG.N */
AHCI_FLAG_COMMON= ATA_FLAG_SATA | ATA_FLAG_NO_LEGACY |
ATA_FLAG_MMIO | ATA_FLAG_PIO_DMA |
@@ -253,6 +260,7 @@ static struct scsi_host_template ahci_sh
.slave_configure= ata_scsi_slave_config,
.slave_destroy = ata_scsi_slave_destroy,
.bios_param = ata_std_bios_param,
+ .set_link_pm_policy = ata_scsi_set_link_pm_policy,
};
static const struct ata_port_operations ahci_ops = {
@@ -284,6 +292,8 @@ static const struct ata_port_operations
.port_suspend = ahci_port_suspend,
.port_resume= ahci_port_resume,
#endif
+ .enable_pm = ahci_enable_alpm,
+ .disable_pm = ahci_disable_alpm,
.port_start = ahci_port_start,
.port_stop = ahci_port_stop,
@@ -719,6 +729,158 @@ static void ahci_power_up(struct ata_por
writel(cmd | PORT_CMD_ICC_ACTIVE, port_mmio + PORT_CMD);
}
+static int ahci_disable_alpm(struct ata_port *ap)
+{
+ void __iomem *port_mmio = ahci_port_base(ap);
+ u32 cmd, scontrol;
+ struct ahci_port_priv *pp = ap->private_data;
+
+ /*
+* disable Interface Power Management State Transitions
+* This is accomplished by setting bits 8:11 of the
+* SATA Control register
+*/
+ scontrol = readl(port_mmio + PORT_SCR_CTL);
+ scontrol |= (0x3 << 8);
+ writel(scontrol, port_mmio + PORT_SCR_CTL);
+
+ /* get the existing command bits */
+ cmd = readl(port_mmio + PORT_CMD);
+
+ /* disable ALPM and ASP */
+ cmd &= ~PORT_CMD_ASP;
+ cmd &= ~PORT_CMD_ALPE;
+
+ /* force the interface back to active */
+ cmd |= PORT_CMD_ICC_ACTIVE;
+
+ /* write out new cmd value */
+ writel(cmd, port_
Re: [patch 2b/3] Expose Power Management Policy option to users
Enable link power management for ata drivers
libata drivers can define a function (enable_pm) that will
perform hardware specific actions to enable whatever power
management policy the user set up from the scsi sysfs
interface if the driver supports it. This power management
policy will be activated after all disks have been
enumerated and initialized. Drivers should also define
disable_pm, which will turn off link power management, but
not change link power management policy.
Signed-off-by: Kristen Carlson Accardi <[EMAIL PROTECTED]>
---
I've updated this patch to fix a problem with suspend breaking when
alpm is enabled. To fix this, I've changed the patch to allow drivers
to have a disable_pm function which can be used by the host controller
to turn off link power managment before requesting an PM activity.
We will turn it back on after Resume.
This whole series can be found at:
http://www.kernel.org/pub/linux/kernel/people/kristen/patches/SATA/alpm/
Index: 2.6-git/drivers/ata/libata-scsi.c
===
--- 2.6-git.orig/drivers/ata/libata-scsi.c
+++ 2.6-git/drivers/ata/libata-scsi.c
@@ -2909,6 +2909,51 @@ void ata_scsi_simulate(struct ata_device
}
}
+int ata_scsi_set_link_pm_policy(struct Scsi_Host *shost,
+ enum scsi_host_link_pm policy)
+{
+ struct ata_port *ap = ata_shost_to_port(shost);
+ int rc = -EINVAL;
+ int i;
+
+ /*
+* make sure no broken devices are on this port,
+* and that all devices support interface power
+* management
+*/
+ for (i = 0; i < ATA_MAX_DEVICES; i++) {
+ struct ata_device *dev = &ap->device[i];
+
+ /* only check drives which exist */
+ if (!ata_dev_enabled(dev))
+ continue;
+
+ /*
+* do we need to handle the case where we've hotplugged
+* a broken drive (since hotplug and ALPM are mutually
+* exclusive) ?
+*
+* If so, if we detect a broken drive on a port with
+* alpm already enabled, then we should reset the policy
+* to off for the entire port.
+*/
+ if ((dev->horkage & ATA_HORKAGE_ALPM) ||
+ !(dev->flags & ATA_DFLAG_IPM)) {
+ ata_dev_printk(dev, KERN_ERR,
+ "Unable to set Link PM policy\n");
+ ap->pm_policy = SHOST_MAX_PERFORMANCE;
+ }
+ }
+
+ if (ap->ops->enable_pm)
+ rc = ap->ops->enable_pm(ap, policy);
+
+ if (!rc)
+ shost->shost_link_pm_policy = ap->pm_policy;
+ return rc;
+}
+EXPORT_SYMBOL_GPL(ata_scsi_set_link_pm_policy);
+
int ata_scsi_add_hosts(struct ata_host *host, struct scsi_host_template *sht)
{
int i, rc;
@@ -2931,7 +2976,7 @@ int ata_scsi_add_hosts(struct ata_host *
shost->max_lun = 1;
shost->max_channel = 1;
shost->max_cmd_len = 16;
-
+ shost->shost_link_pm_policy = ap->pm_policy;
rc = scsi_add_host(ap->scsi_host, ap->host->dev);
if (rc)
goto err_add;
Index: 2.6-git/include/linux/libata.h
===
--- 2.6-git.orig/include/linux/libata.h
+++ 2.6-git/include/linux/libata.h
@@ -136,6 +136,7 @@ enum {
ATA_DFLAG_CDB_INTR = (1 << 2), /* device asserts INTRQ when ready
for CDB */
ATA_DFLAG_NCQ = (1 << 3), /* device supports NCQ */
ATA_DFLAG_FLUSH_EXT = (1 << 4), /* do FLUSH_EXT instead of FLUSH */
+ ATA_DFLAG_IPM = (1 << 6), /* device supports interface PM */
ATA_DFLAG_CFG_MASK = (1 << 8) - 1,
ATA_DFLAG_PIO = (1 << 8), /* device limited to PIO mode */
@@ -299,6 +300,7 @@ enum {
ATA_HORKAGE_NONCQ = (1 << 2), /* Don't use NCQ */
ATA_HORKAGE_MAX_SEC_128 = (1 << 3), /* Limit max sects to 128 */
ATA_HORKAGE_DMA_RW_ONLY = (1 << 4), /* ATAPI DMA for RW only */
+ ATA_HORKAGE_ALPM= (1 << 5), /* ALPM problems */
};
enum hsm_task_states {
@@ -547,6 +549,7 @@ struct ata_port {
pm_message_tpm_mesg;
int *pm_result;
+ enum scsi_host_link_pm pm_policy;
void*private_data;
@@ -606,7 +609,8 @@ struct ata_port_operations {
int (*port_suspend) (struct ata_port *ap, pm_message_t mesg);
int (*port_resume) (struct ata_port *ap);
-
+ int (*enable_pm) (struct ata_port *ap, enum scsi_host_link_pm policy);
+ int (*disable_pm) (struct ata_port *ap);
int (*port_start) (struct ata_port *ap);
void (*port_stop) (struct ata_port *ap);
@@ -812,7 +816,7 @@ extern int ata_cable_40wire(struct ata_p
ex
Re: Very slow writes with mptsas
[EMAIL PROTECTED] wrote: > On Tue, 05 Jun 2007, [EMAIL PROTECTED] wrote: > >> Hello >> >> I'm seeing very slow writes on a Dell Precision 690 with the Dell SAS5 >> adapter, serving a RAID1 array of SATA-II disks. >> >> It's very similar to the problem in FreeBSD, described here: >> >> http://unix.derkeiler.com/Mailing-Lists/FreeBSD/stable/2007-03/msg00756.html >> >> I'm running FC6 with the latest kernel. >> >> Reads are quite fast, writes terribly slow. >> > > Thanks to all who replied to this query, especially the very detailed > response from Eric Moore at LSI. > > The first important facet is that we need to operate on the two hidden > physical disks, not the RAID device. lsscsi differentiates them: > > # lsscsi > [0:0:0:0]diskATA WDC WD5000KS-75M 2E08 - > [0:0:1:0]diskATA HDS725050KLA360 AB5A - > [0:1:0:0]diskDell VIRTUAL DISK 1028 /dev/sda > > sg_map gives the generic device numbers: Using 'lsscsi -g' would also give you the generic device numbers. It is interesting that the above "ATA" disks do not have corresponding /dev/sd* device names. > # sg_map -i -x > /dev/sg0 0 0 0 0 0 ATA WDC WD5000KS-75M 2E08 > /dev/sg1 0 0 1 0 0 ATA HDS725050KLA360 AB5A > > The write cache can then be enabled using sdparm: > > sdparm -s WCE=1 -S /dev/sg0 > > and the result checked with > > # sdparm -g WCE /dev/sg1 > /dev/sg1: ATA HDS725050KLA360 AB5A > WCE 1 [cha: y] > > This seems to make the write performance much better. Good. > The question for Dell is why their version of the BIOS doesn't set the > write cache in the first place or allow it to be altered by the user. The mechanism for doing this was only formalized recently with the SAT standard, so it may take a while for BIOSes and other infrastructure to catch up. 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
[PATCH] aacraid: add SCSI SYNCHONIZE_CACHE range checking (take 2)
There was some overlap with another patch (?) this one has not shown in scsi-pending-2.6. Modernized to apply cleanly and did some extra cleanup. This attached patch is against current scsi-misc-2.6 ObligatoryDisclaimer: Please accept my condolences regarding Outlook's handling of patch attachments. Signed-off-by: Mark Salyzyn <[EMAIL PROTECTED]> drivers/scsi/aacraid/aachba.c | 63 -- 1 file changed, 55 insertions(+), 8 deletions(-) Sincerely -- Mark Salyzyn > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Salyzyn, Mark > Sent: Thursday, June 07, 2007 1:21 PM > To: linux-scsi@vger.kernel.org > Subject: [PATCH] aacraid: add SCSI SYNCHONIZE_CACHE range checking. > > > Customer running an application that issues SYNCHRONIZE_CACHE calls > directly noticed the broad stroke of the current implementation in the > aacraid driver resulting in multiple applications feeding I/O to the > storage causing the issuing application to stall for long periods of > time. By only waiting for the current WRITE commands, rather than all > commands, to complete; and those that are in range of the > SYNCHRONIZE_CACHE call that would associate more tightly with the > issuing application before telling the Firmware to flush it's dirty > cache, we managed to reduce the stalling. The Firmware itself still > flushes all the dirty cache associated with the array ignoring the > range, it just does so in a more timely manner. > > This attached patch is against current scsi-misc-2.6 > > ObligatoryDisclaimer: Please accept my condolences regarding Outlook's > handling of patch attachments. > > Signed-off-by: Mark Salyzyn <[EMAIL PROTECTED]> > > Sincerely -- Mark Salyzyn > aacraid_synch_range2.patch Description: aacraid_synch_range2.patch
[PATCH] aacraid: add cpu cache flush after kmapping and modifying a page
Updated patch to address overlap with patches introduced by FUJITA
Tomonori <[EMAIL PROTECTED]>. Tejun, please inspect.
This attached aacraid specific portion of the patch is against current
scsi-misc-2.6.
ObligatoryDisclaimer: Please accept my condolences regarding Outlook's
handling of patch content.
Signed-off-by: Mark Salyzyn <[EMAIL PROTECTED]>
drivers/scsi/aacraid/aachba.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
Sincerely -- Mark Salyzyn
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Salyzyn, Mark
> Sent: Tuesday, May 29, 2007 12:54 PM
> To: James Bottomley; Tejun Heo
> Cc: linux-scsi@vger.kernel.org
> Subject: Re: [PATCH 4/5] SCSI: add cpu cache flushes after
> kmapping and modifying a page
>
>
> What ever became of the following patch? I have enclosed the
> incremental
> aacraid version of this patch to permit closure if the following was
> rejected because of another portion.
>
> This attached aacraid specific portion of the patch is against current
> scsi-misc-2.6.
>
> ObligatoryDisclaimer: Please accept my condolences regarding Outlook's
> handling of patch content.
>
> Signed-off-by: Mark Salyzyn <[EMAIL PROTECTED]>
>
> Sincerely -- Mark Salyzyn
>
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Tejun Heo
> Sent: Saturday, June 03, 2006 11:41 PM
> To: Jens Axboe; James Bottomley; Dave Miller; [EMAIL PROTECTED];
> [EMAIL PROTECTED]; [EMAIL PROTECTED];
> [EMAIL PROTECTED]; Guennadi Liakhovetski; [EMAIL PROTECTED];
> lkml; [EMAIL PROTECTED]; linux-scsi@vger.kernel.org;
> [EMAIL PROTECTED]
> Cc: Tejun Heo
> Subject: [PATCH 4/5] SCSI: add cpu cache flushes after kmapping and
> modifying a page
>
>
> Add calls to flush_kernel_dcache_page() after CPU has kmapped and
> modified a page. This fixes PIO cache coherency bugs on architectures
> with aliased caches.
>
> Signed-off-by: Tejun Heo <[EMAIL PROTECTED]>
>
> ---
>
> drivers/scsi/3w-9xxx.c|1 +
> drivers/scsi/3w-.c|1 +
> drivers/scsi/aacraid/aachba.c |4 +++-
> drivers/scsi/ide-scsi.c |1 +
> drivers/scsi/ips.c|2 ++
> drivers/scsi/iscsi_tcp.c |1 +
> drivers/scsi/megaraid.c |2 ++
> drivers/scsi/qlogicpti.c |1 +
> drivers/scsi/scsi_debug.c |1 +
> drivers/scsi/scsi_lib.c |1 +
> 10 files changed, 14 insertions(+), 1 deletions(-)
>
> 9b4bdd1409efb726d4a6561a4f7e2aff878ab4f4
> diff --git a/drivers/scsi/3w-9xxx.c b/drivers/scsi/3w-9xxx.c
> index caeb6d2..172f16b 100644
> --- a/drivers/scsi/3w-9xxx.c
> +++ b/drivers/scsi/3w-9xxx.c
> @@ -1948,6 +1948,7 @@ static void twa_scsiop_execute_scsi_comp
> local_irq_save(flags);
> buf = kmap_atomic(sg->page, KM_IRQ0) +
> sg->offset;
> memcpy(buf,
> tw_dev->generic_buffer_virt[request_id], sg->length);
> + flush_kernel_dcache_page(kmap_atomic_to_page(buf
> - sg->offset));
> kunmap_atomic(buf - sg->offset, KM_IRQ0);
> local_irq_restore(flags);
> }
> diff --git a/drivers/scsi/3w-.c b/drivers/scsi/3w-.c
> index e8e41e6..8449551 100644
> --- a/drivers/scsi/3w-.c
> +++ b/drivers/scsi/3w-.c
> @@ -1527,6 +1527,7 @@ static void tw_transfer_internal(TW_Devi
> struct scatterlist *sg;
>
> sg = (struct scatterlist *)cmd->request_buffer;
> + flush_kernel_dcache_page(kmap_atomic_to_page(buf -
> sg->offset));
> kunmap_atomic(buf - sg->offset, KM_IRQ0);
> local_irq_restore(flags);
> }
> diff --git a/drivers/scsi/aacraid/aachba.c
> b/drivers/scsi/aacraid/aachba.c
> index 642a3b4..b7c00b8 100644
> --- a/drivers/scsi/aacraid/aachba.c
> +++ b/drivers/scsi/aacraid/aachba.c
> @@ -376,8 +376,10 @@ static void aac_internal_transfer(struct
>
> memcpy(buf + offset, data, transfer_len - offset);
>
> - if (scsicmd->use_sg)
> + if (scsicmd->use_sg) {
> + flush_kernel_dcache_page(kmap_atomic_to_page(buf -
> sg->offset));
> kunmap_atomic(buf - sg->offset, KM_IRQ0);
> + }
>
> }
>
> diff --git a/drivers/scsi/ide-scsi.c b/drivers/scsi/ide-scsi.c
> index 39b760a..9c28b95 100644
> --- a/drivers/scsi/ide-scsi.c
> +++ b/drivers/scsi/ide-scsi.c
> @@ -189,6 +189,7 @@ static void idescsi_input_buffers (ide_d
> pc->sg->offset;
> drive->hwif->atapi_input_bytes(drive,
> buf + pc->b_count,
> count);
> + flush_kernel_dcache_page(kmap_atomic_to_page(buf
> - pc->sg->offset));
> kunmap_atomic(buf - pc->sg->offset, KM_IRQ0);
> local_irq_restore(flags);
> } else {
> diff --git a/drivers/scsi/ips.c b/drivers/scsi/ips.c
> index a4c0b04..29eb3f0 100644
> --- a
Re: [PATCH] bsg: fix the deadlock on discarding done commands
From: Jens Axboe <[EMAIL PROTECTED]> Subject: Re: [PATCH] bsg: fix the deadlock on discarding done commands Date: Fri, 8 Jun 2007 17:20:49 +0200 > On Sat, Jun 09 2007, FUJITA Tomonori wrote: > > I'll submit the bsg bidi patches shortly. > > Great - I see them, will review and integrate next week. Any progress on this? - 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 req->cmd == INT cases
On Wed, Jun 20, 2007 at 02:24:09PM +0200, Jens Axboe wrote: > > These are old cdrom drivers that are broken in various ways and probably > > should be killed off aswell. > > I agree (with both sentiments), would anyone mind if I just killed them > off? mitsumi support is being reworked, that can get reintroduced once > the driver is in a stable state. Yeah - the new mitsumi doesn't share anything with the old one anyway. - 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 req->cmd == INT cases
On Wed, Jun 20 2007, Christoph Hellwig wrote: > On Wed, Jun 20, 2007 at 01:53:32PM +0300, Boaz Harrosh wrote: > > Jens Axboe wrote: > > > > > > If you look at most of the code, it's inside ifdef debug statements or > > > comments most of them. So I don't think you can base any removal > > > suggestion on that. > > > > > > The patch itself looks fine though, if you send one that isn't mangled > > > I'll apply it to the 2.6.23 branch. > > > > > Sorry new Thunderbird Installation. I forgot it does that. > > > > - I have unearthed very old bugs in stale drivers that still > >used request->cmd as a READ|WRITE int > > - This patch is maybe a proof that these drivers have not been > >used for a long time. Should they be removed completely? > > > > Drivers that currently do not work for sure: > > drivers/acorn/block/fd1772.c > > drivers/acorn/block/mfmhd.c > > Afaik these are old arm26 driver, and that port is dead and should > probably be removed from the tree entirely. > > > drivers/cdrom/aztcd.c > > drivers/cdrom/cm206.c > > drivers/cdrom/gscd.c > > drivers/cdrom/mcdx.c > > drivers/cdrom/optcd.c > > drivers/cdrom/sjcd.c > > These are old cdrom drivers that are broken in various ways and probably > should be killed off aswell. I agree (with both sentiments), would anyone mind if I just killed them off? mitsumi support is being reworked, that can get reintroduced once the driver is in a stable state. -- 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
Re: [PATCH] fix req->cmd == INT cases
On Wed, Jun 20, 2007 at 01:53:32PM +0300, Boaz Harrosh wrote: > Jens Axboe wrote: > > > > If you look at most of the code, it's inside ifdef debug statements or > > comments most of them. So I don't think you can base any removal > > suggestion on that. > > > > The patch itself looks fine though, if you send one that isn't mangled > > I'll apply it to the 2.6.23 branch. > > > Sorry new Thunderbird Installation. I forgot it does that. > > - I have unearthed very old bugs in stale drivers that still >used request->cmd as a READ|WRITE int > - This patch is maybe a proof that these drivers have not been >used for a long time. Should they be removed completely? > > Drivers that currently do not work for sure: > drivers/acorn/block/fd1772.c > drivers/acorn/block/mfmhd.c Afaik these are old arm26 driver, and that port is dead and should probably be removed from the tree entirely. > drivers/cdrom/aztcd.c > drivers/cdrom/cm206.c > drivers/cdrom/gscd.c > drivers/cdrom/mcdx.c > drivers/cdrom/optcd.c > drivers/cdrom/sjcd.c These are old cdrom drivers that are broken in various ways and probably should be killed off aswell. - 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] fix request->cmd == INT cases
On Wed, Jun 20 2007, Boaz Harrosh wrote: > > - I have unearthed very old bugs in stale drivers that still >used request->cmd as a READ|WRITE int > - This patch is maybe a proof that these drivers have not been >used for a long time. Should they be removed completely? Applies fine now, thanks! -- 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 v2] fix request->cmd == INT cases
- I have unearthed very old bugs in stale drivers that still
used request->cmd as a READ|WRITE int
- This patch is maybe a proof that these drivers have not been
used for a long time. Should they be removed completely?
Drivers that currently do not work for sure:
drivers/acorn/block/fd1772.c |2 +-
drivers/acorn/block/mfmhd.c |8
drivers/cdrom/aztcd.c|2 +-
drivers/cdrom/cm206.c|2 +-
drivers/cdrom/gscd.c |2 +-
drivers/cdrom/mcdx.c |2 +-
drivers/cdrom/optcd.c|2 +-
drivers/cdrom/sjcd.c |2 +-
Drivers with cosmetic fixes only:
b/drivers/block/amiflop.c
b/drivers/block/nbd.c
b/drivers/ide/legacy/hd.c
Signed-off-by: Boaz Harrosh <[EMAIL PROTECTED]>
---
drivers/acorn/block/fd1772.c |2 +-
drivers/acorn/block/mfmhd.c | 13 +++--
drivers/block/amiflop.c |2 +-
drivers/block/nbd.c |2 +-
drivers/cdrom/aztcd.c|2 +-
drivers/cdrom/cm206.c|2 +-
drivers/cdrom/gscd.c |2 +-
drivers/cdrom/mcdx.c |2 +-
drivers/cdrom/optcd.c|2 +-
drivers/cdrom/sjcd.c |2 +-
drivers/ide/legacy/hd.c |3 ++-
11 files changed, 14 insertions(+), 20 deletions(-)
diff --git a/drivers/acorn/block/fd1772.c b/drivers/acorn/block/fd1772.c
index 674bf81..423ed08 100644
--- a/drivers/acorn/block/fd1772.c
+++ b/drivers/acorn/block/fd1772.c
@@ -1246,7 +1246,7 @@ repeat:
del_timer(&motor_off_timer);
ReqCnt = 0;
- ReqCmd = CURRENT->cmd;
+ ReqCmd = rq_data_dir(CURRENT);
ReqBlock = CURRENT->sector;
ReqBuffer = CURRENT->buffer;
setup_req_params(drive);
diff --git a/drivers/acorn/block/mfmhd.c b/drivers/acorn/block/mfmhd.c
index 689a4c3..d85520f 100644
--- a/drivers/acorn/block/mfmhd.c
+++ b/drivers/acorn/block/mfmhd.c
@@ -439,7 +439,7 @@ static void mfm_rw_intr(void)
a choice of command end or some data which is ready to be collected
*/
/* I think we have to transfer data while the interrupt line is on and
its
not any other type of interrupt */
- if (CURRENT->cmd == WRITE) {
+ if (rq_data_dir(CURRENT) == WRITE) {
extern void hdc63463_writedma(void);
if ((hdc63463_dataleft <= 0) && (!(mfm_status & STAT_CED))) {
printk("mfm_rw_intr: Apparent DMA write request when no
more to DMA\n");
@@ -799,7 +799,7 @@ static void issue_request(unsigned int block, unsigned int
nsect,
raw_cmd.head = start_head;
raw_cmd.cylinder = track / p->heads;
raw_cmd.cmdtype = CURRENT->cmd;
- raw_cmd.cmdcode = CURRENT->cmd == WRITE ? CMD_WD : CMD_RD;
+ raw_cmd.cmdcode = rq_data_dir(CURRENT) == WRITE ? CMD_WD : CMD_RD;
raw_cmd.cmddata[0] = dev + 1; /* DAG: +1 to get US */
raw_cmd.cmddata[1] = raw_cmd.head;
raw_cmd.cmddata[2] = raw_cmd.cylinder >> 8;
@@ -830,7 +830,7 @@ static void issue_request(unsigned int block, unsigned int
nsect,
hdc63463_dataleft = nsect * 256;/* Better way? */
DBG("mfm%c: %sing: CHS=%d/%d/%d, sectors=%d, buffer=0x%08lx (%p)\n",
-raw_cmd.dev + 'a', (CURRENT->cmd == READ) ? "read" : "writ",
+raw_cmd.dev + 'a', rq_data_dir(CURRENT) == READ ? "read" : "writ",
raw_cmd.cylinder,
raw_cmd.head,
raw_cmd.sector, nsect, (unsigned long) Copy_buffer, CURRENT);
@@ -917,13 +917,6 @@ static void mfm_request(void)
DBG("mfm_request: block after offset=%d\n", block);
- if (CURRENT->cmd != READ && CURRENT->cmd != WRITE) {
- printk("unknown mfm-command %d\n", CURRENT->cmd);
- end_request(CURRENT, 0);
- Busy = 0;
- printk("mfm: continue 4\n");
- continue;
- }
issue_request(block, nsect, CURRENT);
break;
diff --git a/drivers/block/amiflop.c b/drivers/block/amiflop.c
index 27a1390..6ce8b89 100644
--- a/drivers/block/amiflop.c
+++ b/drivers/block/amiflop.c
@@ -1363,7 +1363,7 @@ static void redo_fd_request(void)
#ifdef DEBUG
printk("fd: sector %ld + %d requested for %s\n",
CURRENT->sector,cnt,
- (CURRENT->cmd==READ)?"read":"write");
+ (rq_data_dir(CURRENT) == READ) ? "read" : "write");
#endif
block = CURRENT->sector + cnt;
if ((int)block > floppy->blocks) {
diff --git a/drivers/block/nbd.c b/drivers/block/nbd.c
index 069ae39..c575fb1 100644
--- a/drivers/block/nbd.c
+++ b/drivers/block/nbd.c
@@ -416,7 +416,7 @@ static void nbd_clear_que(struct nbd_device *lo)
/*
* We always wait for result of write, for now. It would be nice to make it
optional
* in future
- * if ((req->cmd == WRITE) && (lo->flags & NBD_WRITE_NOCHK))
+ * if ((rq_data_
Re: [PATCH] fix req->cmd == INT cases
Jens Axboe wrote: > On Wed, Jun 20 2007, Boaz Harrosh wrote: >> Jens Axboe wrote: >>> If you look at most of the code, it's inside ifdef debug statements or >>> comments most of them. So I don't think you can base any removal >>> suggestion on that. >>> >>> The patch itself looks fine though, if you send one that isn't mangled >>> I'll apply it to the 2.6.23 branch. >>> >> Sorry new Thunderbird Installation. I forgot it does that. > > The new patch applies cleanly, except on nbd where it fails. It suceeds > with -l to ignore white space, so perhaps your mail setup isn't 100% up > to standard yet :-) > Thanks, you are right again, it was set to wrap text at 85 chars and when so, it will eat spaces at end of lines. Setting wrap to 0 fixes it. - 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 req->cmd == INT cases
On Wed, Jun 20 2007, Boaz Harrosh wrote: > Jens Axboe wrote: > > > > If you look at most of the code, it's inside ifdef debug statements or > > comments most of them. So I don't think you can base any removal > > suggestion on that. > > > > The patch itself looks fine though, if you send one that isn't mangled > > I'll apply it to the 2.6.23 branch. > > > Sorry new Thunderbird Installation. I forgot it does that. The new patch applies cleanly, except on nbd where it fails. It suceeds with -l to ignore white space, so perhaps your mail setup isn't 100% up to standard yet :-) -- 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
Re: [PATCH] fix req->cmd == INT cases
Jens Axboe wrote:
>
> If you look at most of the code, it's inside ifdef debug statements or
> comments most of them. So I don't think you can base any removal
> suggestion on that.
>
> The patch itself looks fine though, if you send one that isn't mangled
> I'll apply it to the 2.6.23 branch.
>
Sorry new Thunderbird Installation. I forgot it does that.
- I have unearthed very old bugs in stale drivers that still
used request->cmd as a READ|WRITE int
- This patch is maybe a proof that these drivers have not been
used for a long time. Should they be removed completely?
Drivers that currently do not work for sure:
drivers/acorn/block/fd1772.c
drivers/acorn/block/mfmhd.c
drivers/cdrom/aztcd.c
drivers/cdrom/cm206.c
drivers/cdrom/gscd.c
drivers/cdrom/mcdx.c
drivers/cdrom/optcd.c
drivers/cdrom/sjcd.c
Drivers with cosmetic fixes only:
drivers/block/amiflop.c
drivers/block/nbd.c
drivers/ide/legacy/hd.c
Signed-off-by: Boaz Harrosh <[EMAIL PROTECTED]>
---
drivers/acorn/block/fd1772.c |2 +-
drivers/acorn/block/mfmhd.c | 13 +++--
drivers/block/amiflop.c |2 +-
drivers/block/nbd.c |2 +-
drivers/cdrom/aztcd.c|2 +-
drivers/cdrom/cm206.c|2 +-
drivers/cdrom/gscd.c |2 +-
drivers/cdrom/mcdx.c |2 +-
drivers/cdrom/optcd.c|2 +-
drivers/cdrom/sjcd.c |2 +-
drivers/ide/legacy/hd.c |3 ++-
11 files changed, 14 insertions(+), 20 deletions(-)
diff --git a/drivers/acorn/block/fd1772.c b/drivers/acorn/block/fd1772.c
index 674bf81..423ed08 100644
--- a/drivers/acorn/block/fd1772.c
+++ b/drivers/acorn/block/fd1772.c
@@ -1246,7 +1246,7 @@ repeat:
del_timer(&motor_off_timer);
ReqCnt = 0;
- ReqCmd = CURRENT->cmd;
+ ReqCmd = rq_data_dir(CURRENT);
ReqBlock = CURRENT->sector;
ReqBuffer = CURRENT->buffer;
setup_req_params(drive);
diff --git a/drivers/acorn/block/mfmhd.c b/drivers/acorn/block/mfmhd.c
index 689a4c3..d85520f 100644
--- a/drivers/acorn/block/mfmhd.c
+++ b/drivers/acorn/block/mfmhd.c
@@ -439,7 +439,7 @@ static void mfm_rw_intr(void)
a choice of command end or some data which is ready to be collected
*/
/* I think we have to transfer data while the interrupt line is on and
its
not any other type of interrupt */
- if (CURRENT->cmd == WRITE) {
+ if (rq_data_dir(CURRENT) == WRITE) {
extern void hdc63463_writedma(void);
if ((hdc63463_dataleft <= 0) && (!(mfm_status & STAT_CED))) {
printk("mfm_rw_intr: Apparent DMA write request when no
more to DMA\n");
@@ -799,7 +799,7 @@ static void issue_request(unsigned int block, unsigned int
nsect,
raw_cmd.head = start_head;
raw_cmd.cylinder = track / p->heads;
raw_cmd.cmdtype = CURRENT->cmd;
- raw_cmd.cmdcode = CURRENT->cmd == WRITE ? CMD_WD : CMD_RD;
+ raw_cmd.cmdcode = rq_data_dir(CURRENT) == WRITE ? CMD_WD : CMD_RD;
raw_cmd.cmddata[0] = dev + 1; /* DAG: +1 to get US */
raw_cmd.cmddata[1] = raw_cmd.head;
raw_cmd.cmddata[2] = raw_cmd.cylinder >> 8;
@@ -830,7 +830,7 @@ static void issue_request(unsigned int block, unsigned int
nsect,
hdc63463_dataleft = nsect * 256;/* Better way? */
DBG("mfm%c: %sing: CHS=%d/%d/%d, sectors=%d, buffer=0x%08lx (%p)\n",
-raw_cmd.dev + 'a', (CURRENT->cmd == READ) ? "read" : "writ",
+raw_cmd.dev + 'a', rq_data_dir(CURRENT) == READ ? "read" : "writ",
raw_cmd.cylinder,
raw_cmd.head,
raw_cmd.sector, nsect, (unsigned long) Copy_buffer, CURRENT);
@@ -917,13 +917,6 @@ static void mfm_request(void)
DBG("mfm_request: block after offset=%d\n", block);
- if (CURRENT->cmd != READ && CURRENT->cmd != WRITE) {
- printk("unknown mfm-command %d\n", CURRENT->cmd);
- end_request(CURRENT, 0);
- Busy = 0;
- printk("mfm: continue 4\n");
- continue;
- }
issue_request(block, nsect, CURRENT);
break;
diff --git a/drivers/block/amiflop.c b/drivers/block/amiflop.c
index 27a1390..6ce8b89 100644
--- a/drivers/block/amiflop.c
+++ b/drivers/block/amiflop.c
@@ -1363,7 +1363,7 @@ static void redo_fd_request(void)
#ifdef DEBUG
printk("fd: sector %ld + %d requested for %s\n",
CURRENT->sector,cnt,
- (CURRENT->cmd==READ)?"read":"write");
+ (rq_data_dir(CURRENT) == READ) ? "read" : "write");
#endif
block = CURRENT->sector + cnt;
if ((int)block > floppy->blocks) {
diff --git a/drivers/block/nbd.c b/drivers/block/nbd.c
index 069ae39..c575fb1 100644
--- a/drivers/block/nbd.c
+++ b/drivers/block/nbd.c
@@ -416,7 +416,7 @@ static void nbd_cl
