Re: [usb-storage] Re: usb3 fails to write when using usb3 hub in usb3 port

2012-09-27 Thread Adrian Sandu 
>
> Adrian,
>
> I think that the suggestion about checking the power supply, the cabling,
> the grounding screws, and anything of like nature that has been omitted
> from this list is a very good idea. If successful it would eliminate
> the problem for you, as well as resolving the mystery. Unresolved
> mysteries are unpleasant for the user, and at least equally unpleasant
> for a developer.
>
> I have seen hardware do really weird things, myself. As a trivial example,
> once a local computer shop gave me a motherboard which had been returned
> because of booting problems. I was told that it had been brought in twice
> by the customer. No problem had been detected in the shop; they had
> replaced it to make a customer happy. I brought the board home. It was a
> hot summer day. I put it on the floor, hooked up a spare power supply, and
> it booted. No problem. I left it sitting there overnight. The next
> morning, I tried it again. Dead. But in the evening it came to life again.
> Guessing, I looked at the solder joints under the power connector on the
> board. One of them looked suspicious. So I fired up the soldering iron and
> put a dab of fresh solder on it. After that, the board was in use for
> years and never had the booting problem again. The reason that the problem
> was not detected was that it was the middle of the summer in Alabama, and
> when the computer was brought to the shop it was put in a car for the
> trip. The board got warm enough for the solder in that joint to expand
> enough for startup, while en route to the shop.
>
> Thus, I definitely do encourage you to check for hardware or cabling
> problems before deciding to buy additional equipment as a workaround.
>
>
> Good luck,
>
> Theodore Kilgore
>
>
> On Thu, 27 Sep 2012, Adrian Sandu wrote:
>
>> > They're the same chipset.  There's minor differences in the PCI
>> > capabilities, but not much else.  It could be something electrically
>> > wrong with the AsRock system, I suppose.  That's possible if you see
>> > the errors popping up erratically.
>> >
>> > Any chance you can exchange the AsRock system?
>>
>> Nope... I have it for more than 1 year and I kinda' need it even if
>> the usb3 won't work... at least I can use the 2 ports to dirrectly
>> connect 2 drives...nothing else is wrong and I wouldn't of known if I
>> wouldn't of got these hubs...
>>
>> My only solution if no more debugging can be done is to get a nas a
>> put the drives in it...
>>
>> Maybe it's the drives fault somehow ? maybe we should mail wd ?
>> manhattan's fault ? via ? :) There must be someone/someway/somehow
>> that can analyze it in someway and say what is wrong ..
>>
>> Still weird..I'll try on another laptop tomorrow or so ( a dell
>> inspiron with an usb3 port .. dunno what usb3 root chipset it has )

The only thing I can do is buy other usb3 cables :| It's weird to
think that 5 drives ( 2 bought last week or so from 2 different stores
( 1 wd and 1 seagate ), the other 3 are 2 WDs and 1 verbatim bought
from different shops each (I am a "backup nazzi") ) are all having
problems !
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 3/3] libata: Change transport topology layout

2012-09-27 Thread Aaron Lu 
On Thu, Sep 27, 2012 at 12:04:04PM -0700, Gwendal Grignou wrote:
> Integrate ata objects [port, link, device] with scsi objects.
> 
> 
> The path of a scsi device is:
> .../:00:1f.2/host0/ata1/link1/dev1.0/target0:0:0/0:0:0:0

After test, I noticed that this will break the current ata acpi binding
code, but can be fixed with the following changes:

diff --git a/drivers/ata/libata-acpi.c b/drivers/ata/libata-acpi.c
index 30eb7177..459c5b4 100644
--- a/drivers/ata/libata-acpi.c
+++ b/drivers/ata/libata-acpi.c
@@ -978,7 +978,7 @@ void ata_acpi_on_disable(struct ata_device *dev)
 
 static int compat_pci_ata(struct ata_port *ap)
 {
-   struct device *dev = ap->tdev.parent;
+   struct device *dev = ap->host->dev;
struct pci_dev *pdev;
 
if (!is_pci_dev(dev))
@@ -998,7 +998,7 @@ static int ata_acpi_bind_host(struct ata_port *ap, 
acpi_handle *handle)
if (ap->flags & ATA_FLAG_ACPI_SATA)
return -ENODEV;
 
-   *handle = acpi_get_child(DEVICE_ACPI_HANDLE(ap->tdev.parent),
+   *handle = acpi_get_child(DEVICE_ACPI_HANDLE(ap->host->dev),
ap->port_no);
 
if (!*handle)
@@ -1061,7 +1061,12 @@ static struct ata_port *dev_to_ata_port(struct device 
*dev)
 
 static int ata_acpi_find_device(struct device *dev, acpi_handle *handle)
 {
-   struct ata_port *ap = dev_to_ata_port(dev);
+   struct ata_port *ap;
+
+   if (scsi_is_host_device(dev))
+   ap = ata_shost_to_port(dev_to_shost(dev));
+   else
+   ap = dev_to_ata_port(dev);
 
if (!ap)
return -ENODEV;


And to make zero power ODD function, the following changes to enable
runtime pm with no callbacks for the ata_link/ata_device transport
devices are necessary.

diff --git a/drivers/ata/libata-transport.c b/drivers/ata/libata-transport.c
index c04d393..ce91bd2 100644
--- a/drivers/ata/libata-transport.c
+++ b/drivers/ata/libata-transport.c
@@ -421,6 +421,10 @@ int ata_tlink_add(struct ata_link *link)
goto tlink_err;
}
 
+   pm_runtime_no_callbacks(dev);
+   pm_runtime_set_active(dev);
+   pm_runtime_enable(dev);
+
transport_add_device(dev);
transport_configure_device(dev);
 
@@ -649,6 +653,10 @@ static int ata_tdev_add(struct ata_device *ata_dev)
return error;
}
 
+   pm_runtime_no_callbacks(dev);
+   pm_runtime_set_active(dev);
+   pm_runtime_enable(dev);
+
transport_add_device(dev);
transport_configure_device(dev);
return 0;

There is no other problems I can see.
Should I prepare a patch to addess the 2 issues?

Thanks,
Aaron

> 
> or when a port multiplier is present: for instance the device in port 4 of the
> port multiplier:
> .../:00:06.0/:09:00.0/host5/ata6/link6.4/dev6.4.0/target5:4:0/5:4:0:0
> 
> 
> Change-Id: I202e089208e8746ccdaf2053d43da831a0c0976d
> 
> Signed-off-by: Gwendal Grignou 
> ---
>  drivers/ata/libata-core.c  |   13 ++---
>  drivers/ata/libata-scsi.c  |4 ++--
>  drivers/ata/libata-transport.c |2 +-
>  3 files changed, 9 insertions(+), 10 deletions(-)
> 
> diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c
> index 611050d..c83590b 100644
> --- a/drivers/ata/libata-core.c
> +++ b/drivers/ata/libata-core.c
> @@ -6063,19 +6063,18 @@ int ata_host_register(struct ata_host *host, struct 
> scsi_host_template *sht)
>   for (i = 0; i < host->n_ports; i++)
>   host->ports[i]->print_id = atomic_inc_return(&ata_print_id);
>  
> + rc = ata_scsi_add_hosts(host, sht);
> + if (rc)
> + return rc;
>  
>   /* Create associated sysfs transport objects  */
>   for (i = 0; i < host->n_ports; i++) {
> - rc = ata_tport_add(host->dev,host->ports[i]);
> - if (rc) {
> + struct ata_port *ap = host->ports[i];
> + rc = ata_tport_add(&ap->scsi_host->shost_gendev, ap);
> + if (rc)
>   goto err_tadd;
> - }
>   }
>  
> - rc = ata_scsi_add_hosts(host, sht);
> - if (rc)
> - goto err_tadd;
> -
>   /* set cable, sata_spd_limit and report */
>   for (i = 0; i < host->n_ports; i++) {
>   struct ata_port *ap = host->ports[i];
> diff --git a/drivers/ata/libata-scsi.c b/drivers/ata/libata-scsi.c
> index bfda61f..9023bb1 100644
> --- a/drivers/ata/libata-scsi.c
> +++ b/drivers/ata/libata-scsi.c
> @@ -3649,8 +3649,8 @@ void ata_scsi_scan_host(struct ata_port *ap, int sync)
>   else
>   channel = link->pmp;
>  
> - sdev = __scsi_add_device(&ap->scsi_host->shost_gendev,
> -  channel, id, 0, NULL);
> + sdev = __scsi_add_device(&dev->tdev, channel, id, 0,
> +  NULL);
>   if (!IS_ERR(sdev)) {
>   d

Re: [PATCH 0/3] Insert ATA transport objects in SCSI syfs topology.

2012-09-27 Thread Aaron Lu 
On Thu, Sep 27, 2012 at 12:04:01PM -0700, Gwendal Grignou wrote:
> This set of patches improve ATA transport classes integration with SCSI
> objects.
> 
> Before [2.6.x]
> 
> Ata and scsi transport class where separated:
> `--:09:00.0
> |  `--ata1
> |  |  `--port_port
> |  |  `--link1
> |  |  |  `--dev1.0
> |  |  |  `--dev1.1
> |  `--ata2
> |  ...
> |  `--host0
> |  |  `--scsi_host
> |  |  |  `--host0
> |  |  `--target0:0:0
> |  |  |  `--0:0:0:0
> |  |  |  |  `--block
> |  |  |  |  |  `--sda
> |  |  |  |  |  |  `--sda1
> 
> In 3.2, Lin - in commit 9a6d6a2ddabbd32c07f6a38b659e5f3db319fa5a - addressed
> the issue of linking the ata port with the scsi host object by placing the
> scsi_host object under ata port objects.
> 
> However to be more consistent with other transport, this patch does the 
> opposite:
> 
> For instance, with SAS transport, We have
> `--:0b:00.0
> |  `--host6
> |  |  `--phy-6:0
> |  |  `--phy-6:1
> ...
> |  |  `--port-6:0
> |  |  |  `--end_device-6:0
> |  |  |  |  `--sas_device
> |  |  |  |  |  `--end_device-6:0
> |  |  |  |  `--sas_end_device
> |  |  |  |  |  `--end_device-6:0
> |  |  |  |  `--target6:0:0
> |  |  |  |  |  `--6:0:0:0
> |  |  |  |  |  |  `--block
> |  |  |  |  |  |  |  `--sdb
> ...
> |  |  `--port-6:1
> |  |  |  `--end_device-6:1
> ...
> phy and port have to be separated, sas_port are created dynamically.
> 
> For ata, all objects are created at initialization time, so the layout is:
> `--:09:00.0
> |  `--host0
> |  |  `--port1
> |  |  |  `--link1
> |  |  |  |  `--dev1.0
> |  |  |  |  |  `--target0:0:0
> |  |  |  |  |  |  `--0:0:0:0
> |  |  |  |  |  |  |  `--block
> |  |  |  |  |  |  |  |  `--sda
> 
> If we have a port multiplier, more links are created.
> `--:09:00.0
> ...
> |  `--host4
> |  |  `--port5
> |  |  |  `--link5
> |  |  |  |  `--dev5.0
> [device for the port multiplier]
> |  |  |  `--link5.0
> |  |  |  |  `--dev5.0.0
> |  |  |  |  |  `--target4:0:0
> |  |  |  |  |  |  `--4:0:0:0
> |  |  |  |  |  |  |  `--block
> |  |  |  |  |  |  |  |  `--sdc
> [disk in port 0 of the port multiplier]
> ...
> |  |  |  `--link5.2
> |  |  |  |  `--dev5.2.0
> |  |  |  |  |  `--target4:2:0
> |  |  |  |  |  |  `--4:2:0:0
> |  |  |  |  |  |  |  `--block
> |  |  |  |  |  |  |  |  `--sde
> [disk in port 2 of the port multiplier]
> 
> In consequence, the path of a scsi device becomes:
> .../:00:1f.2/host0/ata1/link1/dev1.0/target0:0:0/0:0:0:0
 
Should be port1 :-)

> dev1.0 indicates the master device [0] in ata port 1.
> ata1 being under host0, we know the reliationships between the scsi_host id 
> and
> ata port id.
> 
> or when a port multiplier is present: for instance the device in port 4 of the
> port multiplier:
> .../:00:06.0/:09:00.0/host5/ata6/link6.4/dev6.4.0/target5:4:0/5:4:0:0

Same here.

Thanks,
Aaron

> 
> Gwendal Grignou (3):
>   Revert "ata: make ata port as parent device of scsi host"
>   scsi: Allow devices to have arbitrary parent
>   libata: Change transport topology layout
> 
>  drivers/ata/libata-core.c  |   13 ++---
>  drivers/ata/libata-scsi.c  |4 ++--
>  drivers/ata/libata-transport.c |2 +-
>  drivers/firewire/sbp2.c|3 ++-
>  drivers/message/i2o/i2o_scsi.c |4 ++--
>  drivers/scsi/scsi_scan.c   |9 +
>  include/scsi/scsi_device.h |2 +-
>  7 files changed, 19 insertions(+), 18 deletions(-)
> 
> -- 
> 1.7.7.3
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [usb-storage] Re: usb3 fails to write when using usb3 hub in usb3 port

2012-09-27 Thread Theodore Kilgore 

Adrian,

I think that the suggestion about checking the power supply, the cabling, 
the grounding screws, and anything of like nature that has been omitted 
from this list is a very good idea. If successful it would eliminate 
the problem for you, as well as resolving the mystery. Unresolved 
mysteries are unpleasant for the user, and at least equally unpleasant 
for a developer. 

I have seen hardware do really weird things, myself. As a trivial example, 
once a local computer shop gave me a motherboard which had been returned 
because of booting problems. I was told that it had been brought in twice 
by the customer. No problem had been detected in the shop; they had 
replaced it to make a customer happy. I brought the board home. It was a 
hot summer day. I put it on the floor, hooked up a spare power supply, and 
it booted. No problem. I left it sitting there overnight. The next 
morning, I tried it again. Dead. But in the evening it came to life again. 
Guessing, I looked at the solder joints under the power connector on the 
board. One of them looked suspicious. So I fired up the soldering iron and 
put a dab of fresh solder on it. After that, the board was in use for 
years and never had the booting problem again. The reason that the problem 
was not detected was that it was the middle of the summer in Alabama, and 
when the computer was brought to the shop it was put in a car for the 
trip. The board got warm enough for the solder in that joint to expand 
enough for startup, while en route to the shop.

Thus, I definitely do encourage you to check for hardware or cabling 
problems before deciding to buy additional equipment as a workaround. 


Good luck,

Theodore Kilgore


On Thu, 27 Sep 2012, Adrian Sandu wrote:

> > They're the same chipset.  There's minor differences in the PCI
> > capabilities, but not much else.  It could be something electrically
> > wrong with the AsRock system, I suppose.  That's possible if you see
> > the errors popping up erratically.
> >
> > Any chance you can exchange the AsRock system?
> 
> Nope... I have it for more than 1 year and I kinda' need it even if
> the usb3 won't work... at least I can use the 2 ports to dirrectly
> connect 2 drives...nothing else is wrong and I wouldn't of known if I
> wouldn't of got these hubs...
> 
> My only solution if no more debugging can be done is to get a nas a
> put the drives in it...
> 
> Maybe it's the drives fault somehow ? maybe we should mail wd ?
> manhattan's fault ? via ? :) There must be someone/someway/somehow
> that can analyze it in someway and say what is wrong ..
> 
> Still weird..I'll try on another laptop tomorrow or so ( a dell
> inspiron with an usb3 port .. dunno what usb3 root chipset it has )
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "USB Mass Storage on Linux" group.
> To post to this group, send email to usb-stor...@lists.one-eyed-alien.net.
> To unsubscribe from this group, send email to 
> usb-storage+unsubscr...@lists.one-eyed-alien.net.
> For more options, visit this group at 
> http://groups.google.com/a/lists.one-eyed-alien.net/group/usb-storage/?hl=en.
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v7 3/6] scsi: sr: support zero power ODD(ZPODD)

2012-09-27 Thread Rafael J. Wysocki 
On Thursday, September 27, 2012, Aaron Lu wrote:
> On 09/27/2012 10:42 PM, Alan Stern wrote:
> > On Thu, 27 Sep 2012, Aaron Lu wrote:
> > 
> >>> Moreover, I'd like to migrate SCSI drivers to the PM handling based on 
> >>> struct
> >>> dev_pm_ops eventually and your change is kind of going in the opposite
> >>> direction.  I don't know how much effort the migration is going to take,
> >>> though, so perhaps we can just make this change first.
> >>
> >> Does the following change look OK?
> >>
> >> diff --git a/drivers/scsi/scsi_pm.c b/drivers/scsi/scsi_pm.c
> >> index dc0ad85..1fb7ccc 100644
> >> --- a/drivers/scsi/scsi_pm.c
> >> +++ b/drivers/scsi/scsi_pm.c
> >> @@ -143,7 +143,15 @@ static int scsi_runtime_suspend(struct device *dev)
> >>  
> >>dev_dbg(dev, "scsi_runtime_suspend\n");
> >>if (scsi_is_sdev_device(dev)) {
> >> -  err = scsi_dev_type_suspend(dev, PMSG_AUTO_SUSPEND);
> >> +  err = scsi_device_quiesce(to_scsi_device(dev));
> >> +  if (err)
> >> +  goto out;
> >> +
> >> +  err = pm_generic_runtime_suspend(dev);
> >> +  if (!err)
> >> +  goto out;
> >> +
> >> +  scsi_device_resume(to_scsi_device(dev));
> >>if (err == -EAGAIN)
> >>pm_schedule_suspend(dev, jiffies_to_msecs(
> >>round_jiffies_up_relative(HZ/10)));
> > 
> > Maybe in the end it will be better, but for now this looks like 
> > unnecessary code duplication.  Basically you are copying 
> > scsi_dev_type_suspend() into scsi_runtime_suspend(), except that you 
> > omitted the debugging statement.
> 
> And I've used pm_generic_runtime_suspend :-)
> That would allow me to write runtime callbacks of dev_pm_ops for
> indivisual scsi drivers, like sr.

Well, actually, I meant something different.

The above patch would make it possible for drivers to provide runtime PM
callbacks through dev->driver.pm, but drv->suspend and drv->resume would
still be used for system suspend/resume (and hibernation).

The transition to struct dev_pm_ops I meant, however, would be to start using
callbacks from dev->driver.pm for _all_ device PM operations by default and
fall back to drv->suspend and drv->resume for the drivers whose dev->driver.pm
is NULL (along the lines of what PCI does).  The next step would be to
convert all drivers to use dev->driver.pm only.

So I wouldn't like any drivers to use dev->driver.pm callbacks for some
operations and drv->suspend and drv->resume for the remaining ones at the
same time.

Thanks,
Rafael
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [usb-storage] Re: usb3 fails to write when using usb3 hub in usb3 port

2012-09-27 Thread Adrian Sandu 
> They're the same chipset.  There's minor differences in the PCI
> capabilities, but not much else.  It could be something electrically
> wrong with the AsRock system, I suppose.  That's possible if you see
> the errors popping up erratically.
>
> Any chance you can exchange the AsRock system?

Nope... I have it for more than 1 year and I kinda' need it even if
the usb3 won't work... at least I can use the 2 ports to dirrectly
connect 2 drives...nothing else is wrong and I wouldn't of known if I
wouldn't of got these hubs...

My only solution if no more debugging can be done is to get a nas a
put the drives in it...

Maybe it's the drives fault somehow ? maybe we should mail wd ?
manhattan's fault ? via ? :) There must be someone/someway/somehow
that can analyze it in someway and say what is wrong ..

Still weird..I'll try on another laptop tomorrow or so ( a dell
inspiron with an usb3 port .. dunno what usb3 root chipset it has )
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [usb-storage] Re: usb3 fails to write when using usb3 hub in usb3 port

2012-09-27 Thread Sarah Sharp 
On Thu, Sep 27, 2012 at 10:02:22PM +0300, Adrian Sandu wrote:
> > Since you are using the same live CD on both computers, this has to be
> > caused by a difference in the hardware.  What do "lspci -vvv" and
> > "lspci -vvv -n" show on the two computers?
> 
> http://d3xt3r01.tk/~dexter/usbmon/asrock_lspci
> http://d3xt3r01.tk/~dexter/usbmon/vaio_lspci

They're the same chipset.  There's minor differences in the PCI
capabilities, but not much else.  It could be something electrically
wrong with the AsRock system, I suppose.  That's possible if you see
the errors popping up erratically.

Any chance you can exchange the AsRock system?

Sarah Sharp
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 1/3] Revert "ata: make ata port as parent device of scsi host"

2012-09-27 Thread Gwendal Grignou 
This reverts commit 9a6d6a2ddabbd32c07f6a38b659e5f3db319fa5a.

Instead, melt libata transport sysfs object in scsi objects.

Change-Id: I8c709f63ddf7ba97b9e6f449d5c0b8b85e44e818

Signed-off-by: Gwendal Grignou 
---
 drivers/ata/libata-scsi.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/ata/libata-scsi.c b/drivers/ata/libata-scsi.c
index e3bda07..be38930 100644
--- a/drivers/ata/libata-scsi.c
+++ b/drivers/ata/libata-scsi.c
@@ -3609,7 +3609,7 @@ int ata_scsi_add_hosts(struct ata_host *host, struct 
scsi_host_template *sht)
shost->max_host_blocked = 1;
 
rc = scsi_add_host_with_dma(ap->scsi_host,
-   &ap->tdev, ap->host->dev);
+   host->dev, host->dev);
if (rc)
goto err_add;
}
-- 
1.7.7.3

--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 2/3] scsi: Allow devices to have arbitrary parent

2012-09-27 Thread Gwendal Grignou 
Allow driver who calls __scsi_add_device directly to create the scsi
device on any parent, not just scsi_host directly.
This is alreay done for transport with their own class [SAS, iSCSI, FC, ...]

Change-Id: Ibcf132a8959fbf732dcd0b34a7f4a570d7cf394d

Signed-off-by: Gwendal Grignou 
---
 drivers/ata/libata-scsi.c  |4 ++--
 drivers/firewire/sbp2.c|3 ++-
 drivers/message/i2o/i2o_scsi.c |4 ++--
 drivers/scsi/scsi_scan.c   |9 +
 include/scsi/scsi_device.h |2 +-
 5 files changed, 12 insertions(+), 10 deletions(-)

diff --git a/drivers/ata/libata-scsi.c b/drivers/ata/libata-scsi.c
index be38930..bfda61f 100644
--- a/drivers/ata/libata-scsi.c
+++ b/drivers/ata/libata-scsi.c
@@ -3649,8 +3649,8 @@ void ata_scsi_scan_host(struct ata_port *ap, int sync)
else
channel = link->pmp;
 
-   sdev = __scsi_add_device(ap->scsi_host, channel, id, 0,
-NULL);
+   sdev = __scsi_add_device(&ap->scsi_host->shost_gendev,
+channel, id, 0, NULL);
if (!IS_ERR(sdev)) {
dev->sdev = sdev;
scsi_device_put(sdev);
diff --git a/drivers/firewire/sbp2.c b/drivers/firewire/sbp2.c
index 1162d6b..839afa5 100644
--- a/drivers/firewire/sbp2.c
+++ b/drivers/firewire/sbp2.c
@@ -879,7 +879,8 @@ static void sbp2_login(struct work_struct *work)
ssleep(SBP2_INQUIRY_DELAY);
 
shost = container_of((void *)tgt, struct Scsi_Host, hostdata[0]);
-   sdev = __scsi_add_device(shost, 0, 0, sbp2_lun2int(lu->lun), lu);
+   sdev = __scsi_add_device(&shost->shost_gendev, 0, 0,
+sbp2_lun2int(lu->lun), lu);
/*
 * FIXME:  We are unable to perform reconnects while in sbp2_login().
 * Therefore __scsi_add_device() will get into trouble if a bus reset
diff --git a/drivers/message/i2o/i2o_scsi.c b/drivers/message/i2o/i2o_scsi.c
index 1d31d72..ee1353c 100644
--- a/drivers/message/i2o/i2o_scsi.c
+++ b/drivers/message/i2o/i2o_scsi.c
@@ -294,8 +294,8 @@ static int i2o_scsi_probe(struct device *dev)
}
 
scsi_dev =
-   __scsi_add_device(i2o_shost->scsi_host, channel, le32_to_cpu(id),
- le64_to_cpu(lun), i2o_dev);
+   __scsi_add_device(&i2o_shost->scsi_host->shost_gendev, channel,
+ le32_to_cpu(id), le64_to_cpu(lun), i2o_dev);
 
if (IS_ERR(scsi_dev)) {
osm_warn("can not add SCSI device %03x\n",
diff --git a/drivers/scsi/scsi_scan.c b/drivers/scsi/scsi_scan.c
index 56a9379..105123c 100644
--- a/drivers/scsi/scsi_scan.c
+++ b/drivers/scsi/scsi_scan.c
@@ -1489,11 +1489,11 @@ static int scsi_report_lun_scan(struct scsi_target 
*starget, int bflags,
return ret;
 }
 
-struct scsi_device *__scsi_add_device(struct Scsi_Host *shost, uint channel,
+struct scsi_device *__scsi_add_device(struct device *parent, uint channel,
  uint id, uint lun, void *hostdata)
 {
+   struct Scsi_Host *shost = dev_to_shost(parent);
struct scsi_device *sdev = ERR_PTR(-ENODEV);
-   struct device *parent = &shost->shost_gendev;
struct scsi_target *starget;
 
if (strncmp(scsi_scan_type, "none", 4) == 0)
@@ -1524,8 +1524,9 @@ EXPORT_SYMBOL(__scsi_add_device);
 int scsi_add_device(struct Scsi_Host *host, uint channel,
uint target, uint lun)
 {
-   struct scsi_device *sdev = 
-   __scsi_add_device(host, channel, target, lun, NULL);
+   struct scsi_device *sdev =
+   __scsi_add_device(&host->shost_gendev, channel, target,
+ lun, NULL);
if (IS_ERR(sdev))
return PTR_ERR(sdev);
 
diff --git a/include/scsi/scsi_device.h b/include/scsi/scsi_device.h
index 9895f69..9646a1d 100644
--- a/include/scsi/scsi_device.h
+++ b/include/scsi/scsi_device.h
@@ -285,7 +285,7 @@ static inline struct scsi_target *scsi_target(struct 
scsi_device *sdev)
 #define starget_printk(prefix, starget, fmt, a...) \
dev_printk(prefix, &(starget)->dev, fmt, ##a)
 
-extern struct scsi_device *__scsi_add_device(struct Scsi_Host *,
+extern struct scsi_device *__scsi_add_device(struct device *,
uint, uint, uint, void *hostdata);
 extern int scsi_add_device(struct Scsi_Host *host, uint channel,
   uint target, uint lun);
-- 
1.7.7.3

--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 0/3] Insert ATA transport objects in SCSI syfs topology.

2012-09-27 Thread Gwendal Grignou 
This set of patches improve ATA transport classes integration with SCSI
objects.

Before [2.6.x]

Ata and scsi transport class where separated:
`--:09:00.0
|  `--ata1
|  |  `--port_port
|  |  `--link1
|  |  |  `--dev1.0
|  |  |  `--dev1.1
|  `--ata2
|  ...
|  `--host0
|  |  `--scsi_host
|  |  |  `--host0
|  |  `--target0:0:0
|  |  |  `--0:0:0:0
|  |  |  |  `--block
|  |  |  |  |  `--sda
|  |  |  |  |  |  `--sda1

In 3.2, Lin - in commit 9a6d6a2ddabbd32c07f6a38b659e5f3db319fa5a - addressed
the issue of linking the ata port with the scsi host object by placing the
scsi_host object under ata port objects.

However to be more consistent with other transport, this patch does the 
opposite:

For instance, with SAS transport, We have
`--:0b:00.0
|  `--host6
|  |  `--phy-6:0
|  |  `--phy-6:1
...
|  |  `--port-6:0
|  |  |  `--end_device-6:0
|  |  |  |  `--sas_device
|  |  |  |  |  `--end_device-6:0
|  |  |  |  `--sas_end_device
|  |  |  |  |  `--end_device-6:0
|  |  |  |  `--target6:0:0
|  |  |  |  |  `--6:0:0:0
|  |  |  |  |  |  `--block
|  |  |  |  |  |  |  `--sdb
...
|  |  `--port-6:1
|  |  |  `--end_device-6:1
...
phy and port have to be separated, sas_port are created dynamically.

For ata, all objects are created at initialization time, so the layout is:
`--:09:00.0
|  `--host0
|  |  `--port1
|  |  |  `--link1
|  |  |  |  `--dev1.0
|  |  |  |  |  `--target0:0:0
|  |  |  |  |  |  `--0:0:0:0
|  |  |  |  |  |  |  `--block
|  |  |  |  |  |  |  |  `--sda

If we have a port multiplier, more links are created.
`--:09:00.0
...
|  `--host4
|  |  `--port5
|  |  |  `--link5
|  |  |  |  `--dev5.0
[device for the port multiplier]
|  |  |  `--link5.0
|  |  |  |  `--dev5.0.0
|  |  |  |  |  `--target4:0:0
|  |  |  |  |  |  `--4:0:0:0
|  |  |  |  |  |  |  `--block
|  |  |  |  |  |  |  |  `--sdc
[disk in port 0 of the port multiplier]
...
|  |  |  `--link5.2
|  |  |  |  `--dev5.2.0
|  |  |  |  |  `--target4:2:0
|  |  |  |  |  |  `--4:2:0:0
|  |  |  |  |  |  |  `--block
|  |  |  |  |  |  |  |  `--sde
[disk in port 2 of the port multiplier]

In consequence, the path of a scsi device becomes:
.../:00:1f.2/host0/ata1/link1/dev1.0/target0:0:0/0:0:0:0
dev1.0 indicates the master device [0] in ata port 1.
ata1 being under host0, we know the reliationships between the scsi_host id and
ata port id.

or when a port multiplier is present: for instance the device in port 4 of the
port multiplier:
.../:00:06.0/:09:00.0/host5/ata6/link6.4/dev6.4.0/target5:4:0/5:4:0:0

Gwendal Grignou (3):
  Revert "ata: make ata port as parent device of scsi host"
  scsi: Allow devices to have arbitrary parent
  libata: Change transport topology layout

 drivers/ata/libata-core.c  |   13 ++---
 drivers/ata/libata-scsi.c  |4 ++--
 drivers/ata/libata-transport.c |2 +-
 drivers/firewire/sbp2.c|3 ++-
 drivers/message/i2o/i2o_scsi.c |4 ++--
 drivers/scsi/scsi_scan.c   |9 +
 include/scsi/scsi_device.h |2 +-
 7 files changed, 19 insertions(+), 18 deletions(-)

-- 
1.7.7.3

--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 3/3] libata: Change transport topology layout

2012-09-27 Thread Gwendal Grignou 
Integrate ata objects [port, link, device] with scsi objects.


The path of a scsi device is:
.../:00:1f.2/host0/ata1/link1/dev1.0/target0:0:0/0:0:0:0

or when a port multiplier is present: for instance the device in port 4 of the
port multiplier:
.../:00:06.0/:09:00.0/host5/ata6/link6.4/dev6.4.0/target5:4:0/5:4:0:0


Change-Id: I202e089208e8746ccdaf2053d43da831a0c0976d

Signed-off-by: Gwendal Grignou 
---
 drivers/ata/libata-core.c  |   13 ++---
 drivers/ata/libata-scsi.c  |4 ++--
 drivers/ata/libata-transport.c |2 +-
 3 files changed, 9 insertions(+), 10 deletions(-)

diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c
index 611050d..c83590b 100644
--- a/drivers/ata/libata-core.c
+++ b/drivers/ata/libata-core.c
@@ -6063,19 +6063,18 @@ int ata_host_register(struct ata_host *host, struct 
scsi_host_template *sht)
for (i = 0; i < host->n_ports; i++)
host->ports[i]->print_id = atomic_inc_return(&ata_print_id);
 
+   rc = ata_scsi_add_hosts(host, sht);
+   if (rc)
+   return rc;
 
/* Create associated sysfs transport objects  */
for (i = 0; i < host->n_ports; i++) {
-   rc = ata_tport_add(host->dev,host->ports[i]);
-   if (rc) {
+   struct ata_port *ap = host->ports[i];
+   rc = ata_tport_add(&ap->scsi_host->shost_gendev, ap);
+   if (rc)
goto err_tadd;
-   }
}
 
-   rc = ata_scsi_add_hosts(host, sht);
-   if (rc)
-   goto err_tadd;
-
/* set cable, sata_spd_limit and report */
for (i = 0; i < host->n_ports; i++) {
struct ata_port *ap = host->ports[i];
diff --git a/drivers/ata/libata-scsi.c b/drivers/ata/libata-scsi.c
index bfda61f..9023bb1 100644
--- a/drivers/ata/libata-scsi.c
+++ b/drivers/ata/libata-scsi.c
@@ -3649,8 +3649,8 @@ void ata_scsi_scan_host(struct ata_port *ap, int sync)
else
channel = link->pmp;
 
-   sdev = __scsi_add_device(&ap->scsi_host->shost_gendev,
-channel, id, 0, NULL);
+   sdev = __scsi_add_device(&dev->tdev, channel, id, 0,
+NULL);
if (!IS_ERR(sdev)) {
dev->sdev = sdev;
scsi_device_put(sdev);
diff --git a/drivers/ata/libata-transport.c b/drivers/ata/libata-transport.c
index c04d393..6829be6 100644
--- a/drivers/ata/libata-transport.c
+++ b/drivers/ata/libata-transport.c
@@ -284,7 +284,7 @@ int ata_tport_add(struct device *parent,
 
dev->parent = get_device(parent);
dev->release = ata_tport_release;
-   dev_set_name(dev, "ata%d", ap->print_id);
+   dev_set_name(dev, "port%d", ap->print_id);
transport_setup_device(dev);
error = device_add(dev);
if (error) {
-- 
1.7.7.3

--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [usb-storage] Re: usb3 fails to write when using usb3 hub in usb3 port

2012-09-27 Thread Adrian Sandu 
> Since you are using the same live CD on both computers, this has to be
> caused by a difference in the hardware.  What do "lspci -vvv" and
> "lspci -vvv -n" show on the two computers?

http://d3xt3r01.tk/~dexter/usbmon/asrock_lspci
http://d3xt3r01.tk/~dexter/usbmon/vaio_lspci
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [usb-storage] Re: usb3 fails to write when using usb3 hub in usb3 port

2012-09-27 Thread Alan Stern 
On Thu, 27 Sep 2012, Adrian Sandu wrote:

> >> Adrian Sandu wrote:
> >>> I tried with a 3.3.8 , same thing happened. I don't understand why my
> >>> gentoo (asrock) fails and fedora(laptop) didn't ! :|
> 
> Tried to use the live cd on my laptop, can't reproduce it in any way
> on my computer ..
> Using the same live cd I can reproduce the problem on the asrock :|
> 
> Tried with 3.3.8, 3.4.11, 3.5.4. I don't get what's causing the drive
> to die from a simple hdparm -tT .. :|
> The even more weird thing is that it's not dying every time ..
> sometimes a hdparm runs successfully once or a few times before dying
> .. :|
> Guess I just have a bad luck .. ( altough .. I don't believe in "luck"
> when it comes to hardware/software/science .. :) )

Since you are using the same live CD on both computers, this has to be
caused by a difference in the hardware.  What do "lspci -vvv" and
"lspci -vvv -n" show on the two computers?

Alan Stern

--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [usb-storage] Re: usb3 fails to write when using usb3 hub in usb3 port

2012-09-27 Thread Adrian Sandu 
>> Adrian Sandu wrote:
>>> I tried with a 3.3.8 , same thing happened. I don't understand why my
>>> gentoo (asrock) fails and fedora(laptop) didn't ! :|

Tried to use the live cd on my laptop, can't reproduce it in any way
on my computer ..
Using the same live cd I can reproduce the problem on the asrock :|

Tried with 3.3.8, 3.4.11, 3.5.4. I don't get what's causing the drive
to die from a simple hdparm -tT .. :|
The even more weird thing is that it's not dying every time ..
sometimes a hdparm runs successfully once or a few times before dying
.. :|
Guess I just have a bad luck .. ( altough .. I don't believe in "luck"
when it comes to hardware/software/science .. :) )
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH scsi] Short the path length of scsi_cmd_to_driver()

2012-09-27 Thread Martin K. Petersen 
> "Li" == Li Zhong  writes:

> @@ -845,8 +844,11 @@ static int scsi_send_eh_cmnd(struct scsi_cmnd *scmd, 
> unsigned char *cmnd,
> 
>   scsi_eh_restore_cmnd(scmd, &ses);
> 
>-  if (sdrv && sdrv->eh_action)
>-  rtn = sdrv->eh_action(scmd, cmnd, cmnd_size, rtn);
>+  if (scmd->request->cmd_type == REQ_TYPE_FS) {
>+  struct scsi_driver *sdrv = scsi_cmd_to_driver(scmd);
>+  if (sdrv->eh_action)
>+  rtn = sdrv->eh_action(scmd, cmnd, cmnd_size, rtn);
>+  }
> 
>   return rtn;
> }

My only concern is whether our device lifetime rules guarantee that the
ULD is always attached when we service an error handling command?

-- 
Martin K. Petersen  Oracle Linux Engineering
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH scsi] Add NULL checking of return value from scsi_cmd_to_driver()

2012-09-27 Thread Martin K. Petersen 
> "James" == James Bottomley  writes:

>> I'm fine with having the eh action be triggered for FS requests only,
>> if that's what you're asking?

James> Sort of ... I was thinking do it for all non REQ_TYPE_BLOCK_PC
James> commands (which includes flush and other strange types), but if
James> you think it should only be for REQ_TYPE_FS, that's fine too.

I'm ok either way.

-- 
Martin K. Petersen  Oracle Linux Engineering
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [usb-storage] Re: usb3 fails to write when using usb3 hub in usb3 port

2012-09-27 Thread Adrian Sandu 
> Adrian Sandu wrote:
>> I tried with a 3.3.8 , same thing happened. I don't understand why my
>> gentoo (asrock) fails and fedora(laptop) didn't ! :|
>
> Try what Alan suggested, start the Gentoo userland with the Fedora
> kernel.

I tried booting a Fedora-17-x86_64-Live-Desktop.iso .. same thing
happened on the asrock, will try and see if it happens on my laptop
too ..

> Do you have some crazy USE flags for your toolchain?
>
> If the Fedora kernel works, I would suggest to re-emerge binutils and
> gcc with USE=vanilla, and then build a fresh kernel.

[ebuild   R] sys-devel/binutils-2.22-r1  USE="cxx nls zlib
-multislot -multitarget -static-libs -test -vanilla" 37 kB
[ebuild   R] sys-devel/gcc-4.5.4  USE="cxx fortran mudflap
(multilib) nls nptl openmp (-altivec) -bootstrap -build -doc
(-fixed-point) -gcj -graphite -gtk (-hardened) (-libssp) -lto
-multislot -nocxx -nopie -nossp -objc -objc++ -objc-gc -test -vanilla"
0 k
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 3/3] Make blk_cleanup_queue() wait until request_fn finished

2012-09-27 Thread Bart Van Assche 
Some request_fn implementations, e.g. scsi_request_fn(), unlock
the queue lock. Make sure that blk_cleanup_queue() waits until all
active request_fn invocations have finished. This fixes a potential
use-after-free at the end of scsi_request_fn().

Reported-by: Chanho Min 
Cc: James Bottomley 
Cc: Mike Christie 
Cc: Jens Axboe 
Cc: Tejun Heo 
Signed-off-by: Bart Van Assche 
---
 block/blk-core.c|7 +--
 drivers/scsi/scsi_lib.c |   10 +-
 include/linux/blkdev.h  |5 +
 3 files changed, 11 insertions(+), 11 deletions(-)

diff --git a/block/blk-core.c b/block/blk-core.c
index b5436b6..e41b291 100644
--- a/block/blk-core.c
+++ b/block/blk-core.c
@@ -308,7 +308,9 @@ void __blk_run_queue_uncond(struct request_queue *q)
if (unlikely(blk_queue_dead(q)))
return;
 
+   q->request_fn_active++;
q->request_fn(q);
+   q->request_fn_active--;
 }
 
 /**
@@ -407,6 +409,7 @@ void blk_drain_queue(struct request_queue *q, bool 
drain_all)
__blk_run_queue(q);
 
drain |= q->nr_rqs_elvpriv;
+   drain |= q->request_fn_active;
 
/*
 * Unfortunately, requests are queued at and tracked from
@@ -494,8 +497,8 @@ EXPORT_SYMBOL_GPL(blk_queue_bypass_end);
  * blk_cleanup_queue - shutdown a request queue
  * @q: request queue to shutdown
  *
- * Mark @q DEAD, drain all pending requests, destroy and put it.  All
- * future requests will be failed immediately with -ENODEV.
+ * Mark @q as dying, drain all pending requests, mark @q as dead, destroy and
+ * put it.  All future requests will be failed immediately with -ENODEV.
  */
 void blk_cleanup_queue(struct request_queue *q)
 {
diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
index 593fc71..03571a3 100644
--- a/drivers/scsi/scsi_lib.c
+++ b/drivers/scsi/scsi_lib.c
@@ -1517,10 +1517,6 @@ static void scsi_request_fn(struct request_queue *q)
struct scsi_cmnd *cmd;
struct request *req;
 
-   if(!get_device(&sdev->sdev_gendev))
-   /* We must be tearing the block queue down already */
-   return;
-
/*
 * To start with, we keep looping until the queue is empty, or until
 * the host is no longer able to accept any more requests.
@@ -1629,11 +1625,7 @@ out_delay:
if (sdev->device_busy == 0)
blk_delay_queue(q, SCSI_QUEUE_DELAY);
 out:
-   /* must be careful here...if we trigger the ->remove() function
-* we cannot be holding the q lock */
-   spin_unlock_irq(q->queue_lock);
-   put_device(&sdev->sdev_gendev);
-   spin_lock_irq(q->queue_lock);
+   ;
 }
 
 u64 scsi_calculate_bounce_limit(struct Scsi_Host *shost)
diff --git a/include/linux/blkdev.h b/include/linux/blkdev.h
index 9b9855f..ef5b80a 100644
--- a/include/linux/blkdev.h
+++ b/include/linux/blkdev.h
@@ -377,6 +377,11 @@ struct request_queue {
 
unsigned intnr_sorted;
unsigned intin_flight[2];
+   /*
+* Number of active request_fn() calls for those request_fn()
+* implementations that unlock the queue_lock, e.g. scsi_request_fn().
+*/
+   unsigned intrequest_fn_active;
 
unsigned intrq_timeout;
struct timer_list   timeout;
-- 
1.7.10.4

--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 2/3] block: Avoid that request_fn is invoked on a dead queue

2012-09-27 Thread Bart Van Assche 
Avoid that request_fn gets invoked after queue draining finished.
blk_cleanup_queue() callers expect that request handling has
finished once this function has returned so request_fn must not
get invoked after blk_cleanup_queue() finished.

Cc: James Bottomley 
Cc: Mike Christie 
Cc: Jens Axboe 
Cc: Tejun Heo 
Cc: Chanho Min 
Signed-off-by: Bart Van Assche 
---
 block/blk-core.c   |   25 -
 block/blk-exec.c   |2 +-
 block/blk.h|2 ++
 include/linux/blkdev.h |2 ++
 4 files changed, 29 insertions(+), 2 deletions(-)

diff --git a/block/blk-core.c b/block/blk-core.c
index b37ac03..b5436b6 100644
--- a/block/blk-core.c
+++ b/block/blk-core.c
@@ -293,6 +293,25 @@ void blk_sync_queue(struct request_queue *q)
 EXPORT_SYMBOL(blk_sync_queue);
 
 /**
+ * __blk_run_queue_uncond - run a queue whether or not it has been stopped
+ * @q: The queue to run
+ *
+ * Description:
+ *Invoke request handling on a queue if there are any pending requests.
+ *May be used to restart request handling after a request has completed.
+ *This variant runs the queue whether or not the queue has been
+ *stopped. Must be called with the queue lock held and interrupts
+ *disabled. See also @blk_run_queue.
+ */
+void __blk_run_queue_uncond(struct request_queue *q)
+{
+   if (unlikely(blk_queue_dead(q)))
+   return;
+
+   q->request_fn(q);
+}
+
+/**
  * __blk_run_queue - run a single device queue
  * @q: The queue to run
  *
@@ -305,7 +324,7 @@ void __blk_run_queue(struct request_queue *q)
if (unlikely(blk_queue_stopped(q)))
return;
 
-   q->request_fn(q);
+   __blk_run_queue_uncond(q);
 }
 EXPORT_SYMBOL(__blk_run_queue);
 
@@ -508,6 +527,10 @@ void blk_cleanup_queue(struct request_queue *q)
/* drain all requests queued before DEAD marking */
blk_drain_queue(q, true);
 
+   spin_lock_irq(lock);
+   queue_flag_set(QUEUE_FLAG_DEAD, q);
+   spin_unlock_irq(lock);
+
/* @q won't process any more request, flush async actions */
del_timer_sync(&q->backing_dev_info.laptop_mode_wb_timer);
blk_sync_queue(q);
diff --git a/block/blk-exec.c b/block/blk-exec.c
index 4aec98d..1320e74 100644
--- a/block/blk-exec.c
+++ b/block/blk-exec.c
@@ -72,7 +72,7 @@ void blk_execute_rq_nowait(struct request_queue *q, struct 
gendisk *bd_disk,
__blk_run_queue(q);
/* the queue is stopped so it won't be run */
if (rq->cmd_type == REQ_TYPE_PM_RESUME)
-   q->request_fn(q);
+   __blk_run_queue_uncond(q);
spin_unlock_irq(q->queue_lock);
 }
 EXPORT_SYMBOL_GPL(blk_execute_rq_nowait);
diff --git a/block/blk.h b/block/blk.h
index a066ceb..3e94c14 100644
--- a/block/blk.h
+++ b/block/blk.h
@@ -145,6 +145,8 @@ int blk_try_merge(struct request *rq, struct bio *bio);
 
 void blk_queue_congestion_threshold(struct request_queue *q);
 
+void __blk_run_queue_uncond(struct request_queue *q);
+
 int blk_dev_init(void);
 
 
diff --git a/include/linux/blkdev.h b/include/linux/blkdev.h
index c6ab0db..9b9855f 100644
--- a/include/linux/blkdev.h
+++ b/include/linux/blkdev.h
@@ -451,6 +451,7 @@ struct request_queue {
 #define QUEUE_FLAG_ADD_RANDOM  16  /* Contributes to random pool */
 #define QUEUE_FLAG_SECDISCARD  17  /* supports SECDISCARD */
 #define QUEUE_FLAG_SAME_FORCE  18  /* force complete on same CPU */
+#define QUEUE_FLAG_DEAD19  /* queue tear-down finished */
 
 #define QUEUE_FLAG_DEFAULT ((1 << QUEUE_FLAG_IO_STAT) |\
 (1 << QUEUE_FLAG_STACKABLE)|   \
@@ -521,6 +522,7 @@ static inline void queue_flag_clear(unsigned int flag, 
struct request_queue *q)
 #define blk_queue_tagged(q)test_bit(QUEUE_FLAG_QUEUED, &(q)->queue_flags)
 #define blk_queue_stopped(q)   test_bit(QUEUE_FLAG_STOPPED, &(q)->queue_flags)
 #define blk_queue_dying(q) test_bit(QUEUE_FLAG_DYING, &(q)->queue_flags)
+#define blk_queue_dead(q)  test_bit(QUEUE_FLAG_DEAD, &(q)->queue_flags)
 #define blk_queue_bypass(q)test_bit(QUEUE_FLAG_BYPASS, &(q)->queue_flags)
 #define blk_queue_nomerges(q)  test_bit(QUEUE_FLAG_NOMERGES, &(q)->queue_flags)
 #define blk_queue_noxmerges(q) \
-- 
1.7.10.4

--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 1/3] block: Rename queue dead flag

2012-09-27 Thread Bart Van Assche 
This flag is used to indicate that queuing new requests must stop.
After this flag has been set queue draining starts. However, during
the queue draining phase it is still safe to invoke the queue's
request_fn, so "dying" is a better name than "dead".

This patch is the result of running the command below and manually
fixing up indentation:

git grep -lE 'blk_queue_dead|QUEUE_FLAG_DEAD' |
  xargs sed -i .tmp -e 's/blk_queue_dead/blk_queue_dying/g' \
-e 's/QUEUE_FLAG_DEAD/QUEUE_FLAG_DYING/g'

Cc: James Bottomley 
Cc: Mike Christie 
Cc: Jens Axboe 
Cc: Tejun Heo 
Cc: Chanho Min 
Signed-off-by: Bart Van Assche 
---
 block/blk-cgroup.c  |2 +-
 block/blk-core.c|   16 
 block/blk-exec.c|2 +-
 block/blk-sysfs.c   |4 ++--
 block/blk-throttle.c|2 +-
 block/blk.h |2 +-
 drivers/block/ub.c  |2 +-
 drivers/scsi/scsi_lib.c |2 +-
 include/linux/blkdev.h  |4 ++--
 9 files changed, 18 insertions(+), 18 deletions(-)

diff --git a/block/blk-cgroup.c b/block/blk-cgroup.c
index f3b44a6..5cbdad5 100644
--- a/block/blk-cgroup.c
+++ b/block/blk-cgroup.c
@@ -231,7 +231,7 @@ struct blkcg_gq *blkg_lookup_create(struct blkcg *blkcg,
 * we shouldn't allow anything to go through for a bypassing queue.
 */
if (unlikely(blk_queue_bypass(q)))
-   return ERR_PTR(blk_queue_dead(q) ? -EINVAL : -EBUSY);
+   return ERR_PTR(blk_queue_dying(q) ? -EINVAL : -EBUSY);
return __blkg_lookup_create(blkcg, q, NULL);
 }
 EXPORT_SYMBOL_GPL(blkg_lookup_create);
diff --git a/block/blk-core.c b/block/blk-core.c
index ee3cb3a..b37ac03 100644
--- a/block/blk-core.c
+++ b/block/blk-core.c
@@ -484,7 +484,7 @@ void blk_cleanup_queue(struct request_queue *q)
 
/* mark @q DEAD, no new request or merges will be allowed afterwards */
mutex_lock(&q->sysfs_lock);
-   queue_flag_set_unlocked(QUEUE_FLAG_DEAD, q);
+   queue_flag_set_unlocked(QUEUE_FLAG_DYING, q);
spin_lock_irq(lock);
 
/*
@@ -501,7 +501,7 @@ void blk_cleanup_queue(struct request_queue *q)
 
queue_flag_set(QUEUE_FLAG_NOMERGES, q);
queue_flag_set(QUEUE_FLAG_NOXMERGES, q);
-   queue_flag_set(QUEUE_FLAG_DEAD, q);
+   queue_flag_set(QUEUE_FLAG_DYING, q);
spin_unlock_irq(lock);
mutex_unlock(&q->sysfs_lock);
 
@@ -723,7 +723,7 @@ EXPORT_SYMBOL(blk_init_allocated_queue);
 
 bool blk_get_queue(struct request_queue *q)
 {
-   if (likely(!blk_queue_dead(q))) {
+   if (likely(!blk_queue_dying(q))) {
__blk_get_queue(q);
return true;
}
@@ -877,7 +877,7 @@ static struct request *__get_request(struct request_list 
*rl, int rw_flags,
const bool is_sync = rw_is_sync(rw_flags) != 0;
int may_queue;
 
-   if (unlikely(blk_queue_dead(q)))
+   if (unlikely(blk_queue_dying(q)))
return NULL;
 
may_queue = elv_may_queue(q, rw_flags);
@@ -1057,7 +1057,7 @@ retry:
if (rq)
return rq;
 
-   if (!(gfp_mask & __GFP_WAIT) || unlikely(blk_queue_dead(q))) {
+   if (!(gfp_mask & __GFP_WAIT) || unlikely(blk_queue_dying(q))) {
blk_put_rl(rl);
return NULL;
}
@@ -1909,7 +1909,7 @@ int blk_insert_cloned_request(struct request_queue *q, 
struct request *rq)
return -EIO;
 
spin_lock_irqsave(q->queue_lock, flags);
-   if (unlikely(blk_queue_dead(q))) {
+   if (unlikely(blk_queue_dying(q))) {
spin_unlock_irqrestore(q->queue_lock, flags);
return -ENODEV;
}
@@ -2891,7 +2891,7 @@ static void queue_unplugged(struct request_queue *q, 
unsigned int depth,
/*
 * Don't mess with dead queue.
 */
-   if (unlikely(blk_queue_dead(q))) {
+   if (unlikely(blk_queue_dying(q))) {
spin_unlock(q->queue_lock);
return;
}
@@ -3000,7 +3000,7 @@ void blk_flush_plug_list(struct blk_plug *plug, bool 
from_schedule)
/*
 * Short-circuit if @q is dead
 */
-   if (unlikely(blk_queue_dead(q))) {
+   if (unlikely(blk_queue_dying(q))) {
__blk_end_request_all(rq, -ENODEV);
continue;
}
diff --git a/block/blk-exec.c b/block/blk-exec.c
index 8b6dc5b..4aec98d 100644
--- a/block/blk-exec.c
+++ b/block/blk-exec.c
@@ -60,7 +60,7 @@ void blk_execute_rq_nowait(struct request_queue *q, struct 
gendisk *bd_disk,
 
spin_lock_irq(q->queue_lock);
 
-   if (unlikely(blk_queue_dead(q))) {
+   if (unlikely(blk_queue_dying(q))) {
rq->errors = -ENXIO;
if (rq->end_io)
rq->end_io(rq, rq->errors);
diff --git a/block/blk-sysfs.c b/block/blk-sysfs.c
index 9628b29..6898f17 100644
--- a/block/blk-sysfs.c
+++ b/block/blk-sysfs.c
@@ -432,7 +432,7 @@ queue_attr_show(s

[PATCH 0/3 v3] blk_cleanup_queue() versus request_fn order fix

2012-09-27 Thread Bart Van Assche 

At device removal time request processing functions like
scsi_request_fn() that unlock the queue lock internally may cause
blk_cleanup_queue() to finish while request_fn is in progress.
This three-patch series makes sure that blk_cleanup_queue() can't
finish before all active request_fn calls have finished and also
that request_fn isn't invoked anymore after queue draining finished.

Changes compared to v2:
- Split second patch into two patches.
- Refined patch descriptions.

Changes compared to v1:
- Included a patch to rename QUEUE_FLAG_DEAD.
- Refined the descriptions of the __blk_run_queue_uncond() and
  blk_cleanup_queue() functions.

--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [usb-storage] Re: usb3 fails to write when using usb3 hub in usb3 port

2012-09-27 Thread Peter Stuge 
Adrian Sandu wrote:
> I tried with a 3.3.8 , same thing happened. I don't understand why my
> gentoo (asrock) fails and fedora(laptop) didn't ! :|

Try what Alan suggested, start the Gentoo userland with the Fedora
kernel.

Do you have some crazy USE flags for your toolchain?

If the Fedora kernel works, I would suggest to re-emerge binutils and
gcc with USE=vanilla, and then build a fresh kernel.


//Peter
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [usb-storage] Re: usb3 fails to write when using usb3 hub in usb3 port

2012-09-27 Thread Alan Stern 
On Thu, 27 Sep 2012, Adrian Sandu wrote:

> I tried with a 3.3.8 , same thing happened. I don't understand why my
> gentoo (asrock) fails and fedora(laptop) didn't ! :|

Come to think of it, you could try running the same kernel on both 
computers to see what happens.  For example, boot both of them from a 
Fedora install disc in rescue mode.

Alan Stern

--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [usb-storage] Re: usb3 fails to write when using usb3 hub in usb3 port

2012-09-27 Thread Alan Stern 
On Thu, 27 Sep 2012, Adrian Sandu wrote:

> >> I tried with a 3.3.8 , same thing happened. I don't understand why my
> >> gentoo (asrock) fails and fedora(laptop) didn't ! :|
> >> Why ? What causes it to shutdown ? It can copy to/from drives ( in the
> >> hub or directly in the root hub ) .. but what makes it fail sometimes
> >> :|
> >
> > If we knew the answer, the problem would already be fixed.  :-)
> 
> Would a usbmon dump on a working 3.5.2 ( my fedora ) for comparison
> with the gentoo help ( when doing the same actions that would fail on
> the gentoo ) ?

I don't know.  Sarah is the expert on this stuff.

Alan Stern

--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v7 3/6] scsi: sr: support zero power ODD(ZPODD)

2012-09-27 Thread Aaron Lu 
On 09/27/2012 10:42 PM, Alan Stern wrote:
> On Thu, 27 Sep 2012, Aaron Lu wrote:
> 
>>> Moreover, I'd like to migrate SCSI drivers to the PM handling based on 
>>> struct
>>> dev_pm_ops eventually and your change is kind of going in the opposite
>>> direction.  I don't know how much effort the migration is going to take,
>>> though, so perhaps we can just make this change first.
>>
>> Does the following change look OK?
>>
>> diff --git a/drivers/scsi/scsi_pm.c b/drivers/scsi/scsi_pm.c
>> index dc0ad85..1fb7ccc 100644
>> --- a/drivers/scsi/scsi_pm.c
>> +++ b/drivers/scsi/scsi_pm.c
>> @@ -143,7 +143,15 @@ static int scsi_runtime_suspend(struct device *dev)
>>  
>>  dev_dbg(dev, "scsi_runtime_suspend\n");
>>  if (scsi_is_sdev_device(dev)) {
>> -err = scsi_dev_type_suspend(dev, PMSG_AUTO_SUSPEND);
>> +err = scsi_device_quiesce(to_scsi_device(dev));
>> +if (err)
>> +goto out;
>> +
>> +err = pm_generic_runtime_suspend(dev);
>> +if (!err)
>> +goto out;
>> +
>> +scsi_device_resume(to_scsi_device(dev));
>>  if (err == -EAGAIN)
>>  pm_schedule_suspend(dev, jiffies_to_msecs(
>>  round_jiffies_up_relative(HZ/10)));
> 
> Maybe in the end it will be better, but for now this looks like 
> unnecessary code duplication.  Basically you are copying 
> scsi_dev_type_suspend() into scsi_runtime_suspend(), except that you 
> omitted the debugging statement.

And I've used pm_generic_runtime_suspend :-)
That would allow me to write runtime callbacks of dev_pm_ops for
indivisual scsi drivers, like sr.

Thanks,
Aaron

--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [usb-storage] Re: usb3 fails to write when using usb3 hub in usb3 port

2012-09-27 Thread Adrian Sandu 
>> I tried with a 3.3.8 , same thing happened. I don't understand why my
>> gentoo (asrock) fails and fedora(laptop) didn't ! :|
>> Why ? What causes it to shutdown ? It can copy to/from drives ( in the
>> hub or directly in the root hub ) .. but what makes it fail sometimes
>> :|
>
> If we knew the answer, the problem would already be fixed.  :-)

Would a usbmon dump on a working 3.5.2 ( my fedora ) for comparison
with the gentoo help ( when doing the same actions that would fail on
the gentoo ) ?
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [usb-storage] Re: usb3 fails to write when using usb3 hub in usb3 port

2012-09-27 Thread Alan Stern 
On Thu, 27 Sep 2012, Adrian Sandu wrote:

> >> Anything else I can help with ? :| I'm stuck .. dunno what to test
> >> more or what else helpfull info I could give ya' guys ..
> >
> > You could run a test with a 3.3 kernel, as Sarah asked earlier.  Other
> > than that, I can't think of anything.  Maybe Sarah will come up with a
> > patch for you to try out.
> 
> I tried with a 3.3.8 , same thing happened. I don't understand why my
> gentoo (asrock) fails and fedora(laptop) didn't ! :|
> Why ? What causes it to shutdown ? It can copy to/from drives ( in the
> hub or directly in the root hub ) .. but what makes it fail sometimes
> :|

If we knew the answer, the problem would already be fixed.  :-)

Alan Stern

--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v7 3/6] scsi: sr: support zero power ODD(ZPODD)

2012-09-27 Thread Alan Stern 
On Thu, 27 Sep 2012, Aaron Lu wrote:

> > Moreover, I'd like to migrate SCSI drivers to the PM handling based on 
> > struct
> > dev_pm_ops eventually and your change is kind of going in the opposite
> > direction.  I don't know how much effort the migration is going to take,
> > though, so perhaps we can just make this change first.
> 
> Does the following change look OK?
> 
> diff --git a/drivers/scsi/scsi_pm.c b/drivers/scsi/scsi_pm.c
> index dc0ad85..1fb7ccc 100644
> --- a/drivers/scsi/scsi_pm.c
> +++ b/drivers/scsi/scsi_pm.c
> @@ -143,7 +143,15 @@ static int scsi_runtime_suspend(struct device *dev)
>  
>   dev_dbg(dev, "scsi_runtime_suspend\n");
>   if (scsi_is_sdev_device(dev)) {
> - err = scsi_dev_type_suspend(dev, PMSG_AUTO_SUSPEND);
> + err = scsi_device_quiesce(to_scsi_device(dev));
> + if (err)
> + goto out;
> +
> + err = pm_generic_runtime_suspend(dev);
> + if (!err)
> + goto out;
> +
> + scsi_device_resume(to_scsi_device(dev));
>   if (err == -EAGAIN)
>   pm_schedule_suspend(dev, jiffies_to_msecs(
>   round_jiffies_up_relative(HZ/10)));

Maybe in the end it will be better, but for now this looks like 
unnecessary code duplication.  Basically you are copying 
scsi_dev_type_suspend() into scsi_runtime_suspend(), except that you 
omitted the debugging statement.

Alan Stern

--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [usb-storage] Re: usb3 fails to write when using usb3 hub in usb3 port

2012-09-27 Thread Adrian Sandu 
>> Anything else I can help with ? :| I'm stuck .. dunno what to test
>> more or what else helpfull info I could give ya' guys ..
>
> You could run a test with a 3.3 kernel, as Sarah asked earlier.  Other
> than that, I can't think of anything.  Maybe Sarah will come up with a
> patch for you to try out.

I tried with a 3.3.8 , same thing happened. I don't understand why my
gentoo (asrock) fails and fedora(laptop) didn't ! :|
Why ? What causes it to shutdown ? It can copy to/from drives ( in the
hub or directly in the root hub ) .. but what makes it fail sometimes
:|
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [usb-storage] Re: usb3 fails to write when using usb3 hub in usb3 port

2012-09-27 Thread Alan Stern 
Please trim unnecessary junk from your emails.  There's no reason to 
send all the stuff at the end of those messages to everybody on the 
mailing list.

On Thu, 27 Sep 2012, Adrian Sandu wrote:

> Anything else I can help with ? :| I'm stuck .. dunno what to test
> more or what else helpfull info I could give ya' guys ..

You could run a test with a 3.3 kernel, as Sarah asked earlier.  Other
than that, I can't think of anything.  Maybe Sarah will come up with a
patch for you to try out.

Alan Stern

--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [usb-storage] Re: usb3 fails to write when using usb3 hub in usb3 port

2012-09-27 Thread Adrian Sandu 
On Wed, Sep 26, 2012 at 8:16 PM, Adrian Sandu  wrote:
> 2012-09-26T20:13:09.700606+03:00 d3xt3r01 kernel: [ 2466.455403] usb
> 3-1.1: reset SuperSpeed USB device number 14 using xhci_hcd
> 2012-09-26T20:13:09.713629+03:00 d3xt3r01 kernel: [ 2466.468373]
> xhci_hcd :04:00.0: xHCI xhci_drop_endpoint called with disabled ep
> 88011aea1300
> 2012-09-26T20:13:09.713667+03:00 d3xt3r01 kernel: [ 2466.468384]
> xhci_hcd :04:00.0: xHCI xhci_drop_endpoint called with disabled ep
> 88011aea1340
> 2012-09-26T20:13:44.480669+03:00 d3xt3r01 kernel: [ 2501.235365] hub
> 3-1:1.0: Cannot enable port 1.  Maybe the USB cable is bad?
> 2012-09-26T20:13:45.005111+03:00 d3xt3r01 kernel: [ 2501.759279] sd
> 18:0:0:0: Device offlined - not ready after error recovery
> 2012-09-26T20:13:45.005118+03:00 d3xt3r01 kernel: [ 2501.759300] sd
> 18:0:0:0: [sdb] Unhandled error code
> 2012-09-26T20:13:45.005125+03:00 d3xt3r01 kernel: [ 2501.759305] sd
> 18:0:0:0: [sdb]  Result: hostbyte=DID_ABORT driverbyte=DRIVER_OK
> 2012-09-26T20:13:45.005133+03:00 d3xt3r01 kernel: [ 2501.759312] sd
> 18:0:0:0: [sdb] CDB: Read(10): 28 00 00 03 2c 00 00 00 f0 00
> 2012-09-26T20:13:45.005139+03:00 d3xt3r01 kernel: [ 2501.759328]
> end_request: I/O error, dev sdb, sector 207872
> 2012-09-26T20:13:45.005146+03:00 d3xt3r01 kernel: [ 2501.759334]
> quiet_error: 23 callbacks suppressed
> 2012-09-26T20:13:45.005151+03:00 d3xt3r01 kernel: [ 2501.759339]
> Buffer I/O error on device sdb, logical block 25984
> 2012-09-26T20:13:45.005157+03:00 d3xt3r01 kernel: [ 2501.759351]
> Buffer I/O error on device sdb, logical block 25985
> 2012-09-26T20:13:45.005163+03:00 d3xt3r01 kernel: [ 2501.759357]
> Buffer I/O error on device sdb, logical block 25986
> 2012-09-26T20:13:45.005169+03:00 d3xt3r01 kernel: [ 2501.759363]
> Buffer I/O error on device sdb, logical block 25987
> The result of a simple d3xt3r01 ~ # hdparm -tT /dev/sdb
>
> /dev/sdb:
>  Timing cached reads:   1494 MB in  2.00 seconds = 747.20 MB/sec
>  Timing buffered disk reads: read(2097152) returned 1572864 bytes
> BLKFLSBUF failed: No such device
>
> It didn't fail the first time though .. I just executed the same
> command twice ..
> Assuming that 3u is the good thing to cat ..
> http://d3xt3r01.tk/~dexter/usbmon/1348679651_3u ..
> ( given the output in /sys/kernel/debug/usb/devices )
>
> Hope this helps more to identify the issue ..

Anything else I can help with ? :| I'm stuck .. dunno what to test
more or what else helpfull info I could give ya' guys ..

> 2012-09-26T20:13:45.005175+03:00 d3xt3r01 kernel: [ 2501.759369]
> Buffer I/O error on device sdb, logical block 25988
> 2012-09-26T20:13:45.005182+03:00 d3xt3r01 kernel: [ 2501.759375]
> Buffer I/O error on device sdb, logical block 25989
> 2012-09-26T20:13:45.005188+03:00 d3xt3r01 kernel: [ 2501.759382]
> Buffer I/O error on device sdb, logical block 25990
> 2012-09-26T20:13:45.005194+03:00 d3xt3r01 kernel: [ 2501.759393] sd
> 18:0:0:0: rejecting I/O to offline device
> 2012-09-26T20:13:45.005200+03:00 d3xt3r01 kernel: [ 2501.759407] sd
> 18:0:0:0: [sdb] killing request
> 2012-09-26T20:13:45.005207+03:00 d3xt3r01 kernel: [ 2501.759415]
> Buffer I/O error on device sdb, logical block 25991
> 2012-09-26T20:13:45.005213+03:00 d3xt3r01 kernel: [ 2501.759426]
> Buffer I/O error on device sdb, logical block 25992
> 2012-09-26T20:13:45.005220+03:00 d3xt3r01 kernel: [ 2501.759432]
> Buffer I/O error on device sdb, logical block 25993
> 2012-09-26T20:13:45.005227+03:00 d3xt3r01 kernel: [ 2501.759440] sd
> 18:0:0:0: rejecting I/O to offline device
> 2012-09-26T20:13:45.005233+03:00 d3xt3r01 kernel: [ 2501.759494] sd
> 18:0:0:0: rejecting I/O to offline device
> 2012-09-26T20:13:45.005240+03:00 d3xt3r01 kernel: [ 2501.759505] sd
> 18:0:0:0: rejecting I/O to offline device
> 2012-09-26T20:13:45.005246+03:00 d3xt3r01 kernel: [ 2501.759624] sd
> 18:0:0:0: [sdb] Unhandled error code
> 2012-09-26T20:13:45.005252+03:00 d3xt3r01 kernel: [ 2501.759630] sd
> 18:0:0:0: [sdb]  Result: hostbyte=DID_NO_CONNECT driverbyte=DRIVER_OK
> 2012-09-26T20:13:45.005259+03:00 d3xt3r01 kernel: [ 2501.759637] sd
> 18:0:0:0: [sdb] CDB: Read(10): 28 00 00 03 2c f0 00 00 10 00
> 2012-09-26T20:13:45.005267+03:00 d3xt3r01 kernel: [ 2501.759654]
> end_request: I/O error, dev sdb, sector 208112
> 2012-09-26T20:13:45.020696+03:00 d3xt3r01 kernel: [ 2501.775198] usb
> 3-1.1: USB disconnect, device number 14
>
>
> On Wed, Sep 26, 2012 at 7:59 PM, Adrian Sandu  wrote:
>> On Wed, Sep 26, 2012 at 5:50 PM, Alan Stern  
>> wrote:
>>> On Tue, 25 Sep 2012, Sarah Sharp wrote:
>>>
 Alan, I'm wondering if the xHCI ring expansion is causing issues with
 USB hard drives under xHCI.  Testing with a Buffalo USB 3.0 hard drive
 with an NEC uPD720200 xHCI host, I see that the usb-storage and SCSI
 initialization produces I/O errors on random sectors in 3.4.0, 3.4.6,
 and 3.5.0.  I can't get those errors to be reproduced in 3.3.1.

 The xHCI ring expansion was added in 3

Re: [PATCH v7 2/6] scsi: sr: support runtime pm

2012-09-27 Thread Oliver Neukum 
On Tuesday 25 September 2012 16:01:35 Aaron Lu wrote:
> On Mon, Sep 24, 2012 at 11:40:18PM +0200, Rafael J. Wysocki wrote:
> > On Monday, September 24, 2012, Aaron Lu wrote:
> > > On Mon, Sep 24, 2012 at 02:55:31PM +0200, Rafael J. Wysocki wrote:

> I just checked the spec again and tested, when the ODD has power, it
> will also send out notifications on pressing the eject button/inserting
> a disc. So we should be able to capture such a event.

In this case there's no need to poll for disk change unless the button has
been pressed.

> I'm thinking of enabling this GPE in sr_suspend once we decided that it
> is ready to be powered off, so the time frame between sr_suspend and
> when the power is actually removed in libata should be taken care of by
> the GPE. If GPE fires, the notification function will request a runtime
> resume of the device. Does this sound OK?

This sounds terribly, needlessly complicated. Just enable it when
you detect the presence of a disk drive that supports it.

Furthermore we have a device which can detect that a button has
been pressed. It is fundamentally wrong to poll for medium change in
such devices. You know that it hasn't been changed.
We should notify the upper layers that we can do medium change
detection on our own.

Regards
Oliver

--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH scsi] Short the path length of scsi_cmd_to_driver()

2012-09-27 Thread Li Zhong 
Hi James, Martin,  

Here is the updated version, please help to review.

Thanks, Zhong


As suggested by James: this patch tries to short the path length of
scsi_cmd_to_driver(). As only REQ_TYPE_BLOCK_PC commands can be
submitted without a driver, so we could avoid the related NULL 
checking, as long as we make sure we don't use it for REQ_TYPE_BLOCK_PC
type commands. Plus, this fixes a bug where you get different behaviors
from REQ_TYPE_BLOCK_PC commands when a driver is and isn't attached. 

And Martin pointed out that we could have eh action be triggered for 
REQ_TYPE_FS type only. 

Signed-off-by: Li Zhong 
---
 drivers/scsi/scsi_error.c |8 +---
 include/scsi/scsi_cmnd.h  |   12 ++--
 2 files changed, 7 insertions(+), 13 deletions(-)

diff --git a/drivers/scsi/scsi_error.c b/drivers/scsi/scsi_error.c
index de2337f..4001559 100644
--- a/drivers/scsi/scsi_error.c
+++ b/drivers/scsi/scsi_error.c
@@ -789,7 +789,6 @@ static int scsi_send_eh_cmnd(struct scsi_cmnd *scmd, 
unsigned char *cmnd,
 int cmnd_size, int timeout, unsigned sense_bytes)
 {
struct scsi_device *sdev = scmd->device;
-   struct scsi_driver *sdrv = scsi_cmd_to_driver(scmd);
struct Scsi_Host *shost = sdev->host;
DECLARE_COMPLETION_ONSTACK(done);
unsigned long timeleft;
@@ -845,8 +844,11 @@ static int scsi_send_eh_cmnd(struct scsi_cmnd *scmd, 
unsigned char *cmnd,
 
scsi_eh_restore_cmnd(scmd, &ses);
 
-   if (sdrv && sdrv->eh_action)
-   rtn = sdrv->eh_action(scmd, cmnd, cmnd_size, rtn);
+   if (scmd->request->cmd_type == REQ_TYPE_FS) {
+   struct scsi_driver *sdrv = scsi_cmd_to_driver(scmd);
+   if (sdrv->eh_action)
+   rtn = sdrv->eh_action(scmd, cmnd, cmnd_size, rtn);
+   }
 
return rtn;
 }
diff --git a/include/scsi/scsi_cmnd.h b/include/scsi/scsi_cmnd.h
index ac06cc5..de5f5d8 100644
--- a/include/scsi/scsi_cmnd.h
+++ b/include/scsi/scsi_cmnd.h
@@ -132,18 +132,10 @@ struct scsi_cmnd {
unsigned char tag;  /* SCSI-II queued command tag */
 };
 
+/* make sure not to use it with REQ_TYPE_BLOCK_PC commands */
 static inline struct scsi_driver *scsi_cmd_to_driver(struct scsi_cmnd *cmd)
 {
-   struct scsi_driver **sdp;
-
-   if (!cmd->request->rq_disk)
-   return NULL;
-
-   sdp = (struct scsi_driver **)cmd->request->rq_disk->private_data;
-   if (!sdp)
-   return NULL;
-
-   return *sdp;
+   return *(struct scsi_driver **)cmd->request->rq_disk->private_data;
 }
 
 extern struct scsi_cmnd *scsi_get_command(struct scsi_device *, gfp_t);
-- 
1.7.7.6



--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v7 0/6] ZPODD patches

2012-09-27 Thread Aaron Lu 
On Tue, Sep 25, 2012 at 03:02:29PM +0400, James Bottomley wrote:
> On Tue, 2012-09-25 at 16:18 +0800, Aaron Lu wrote:
> > A example patch would be something like the following, I didn't seperate
> > these ACPI calls in sr.c as this is just a concept proof, if this is the
> > right thing to do, I will separate them into another file sr-acpi.c and
> > make empty stubs for them in sr.h for systems do not have ACPI configured.
> 
> Apart from the needed separation to compile in the !ACPI case
> 
> > +static void sr_acpi_add_pm_notifier(struct device *dev)
> > +{
> > +   struct acpi_device *acpi_dev;
> > +   acpi_handle handle;
> > +   acpi_status status;
> > +
> > +   handle = dev->archdata.acpi_handle;
> 
> This is a complete no-no.  archdata is defined to be specific to the
> architecture it's supposed to be opaque to non-arch code.  You'll find
> that only x86 and ia64 defines an acpi_handle there.  This will
> instantly fail to compile on non intel.  If you need the handle, it
> should be obtained via some accessor like dev_to_acpi_handle() which
> will allow this to continue to function when, say, arm acquires ACPI.
> 
> I've got to say, this looks like a fault in ACPI itself.  If the handles
> are 1:1 with struct device, then why not have all the functions taking
> handles take the device instead and leave the embedded handle safely in
> the architecture specific code?

I've prepared a complete code change for you to take a look, with the
notification code resides in sr, I can move the need_eject flag from
scsi_device to scsi_cd, which should make more sense.


diff --git a/drivers/scsi/Makefile b/drivers/scsi/Makefile
index 888f73a..9f0a1da 100644
--- a/drivers/scsi/Makefile
+++ b/drivers/scsi/Makefile
@@ -177,6 +177,7 @@ sd_mod-objs := sd.o
 sd_mod-$(CONFIG_BLK_DEV_INTEGRITY) += sd_dif.o
 
 sr_mod-objs:= sr.o sr_ioctl.o sr_vendor.o
+sr_mod-$(CONFIG_ACPI)  += sr_acpi.o
 ncr53c8xx-flags-$(CONFIG_SCSI_ZALON) \
:= -DCONFIG_NCR53C8XX_PREFETCH -DSCSI_NCR_BIG_ENDIAN \
-DCONFIG_SCSI_NCR53C8XX_NO_WORD_TRANSFERS
diff --git a/drivers/scsi/sr.c b/drivers/scsi/sr.c
index 4d1a610..cb6703c 100644
--- a/drivers/scsi/sr.c
+++ b/drivers/scsi/sr.c
@@ -734,6 +734,7 @@ static int sr_probe(struct device *dev)
 
sdev_printk(KERN_DEBUG, sdev,
"Attached scsi CD-ROM %s\n", cd->cdi.name);
+   sr_acpi_add_pm_notifier(dev);
scsi_autopm_put_device(cd->device);
 
return 0;
@@ -984,6 +985,7 @@ static int sr_remove(struct device *dev)
struct scsi_cd *cd = dev_get_drvdata(dev);
 
scsi_autopm_get_device(cd->device);
+   sr_acpi_remove_pm_notifier(dev);
 
blk_queue_prep_rq(cd->device->request_queue, scsi_prep_fn);
del_gendisk(cd->disk);
diff --git a/drivers/scsi/sr.h b/drivers/scsi/sr.h
index 37c8f6b..1f66fa0a 100644
--- a/drivers/scsi/sr.h
+++ b/drivers/scsi/sr.h
@@ -48,6 +48,8 @@ typedef struct scsi_cd {
bool get_event_changed:1;   /* changed according to GET_EVENT */
bool ignore_get_event:1;/* GET_EVENT is unreliable, use TUR */
 
+   bool need_eject:1; /* User wakes up the ODD, need eject the tray */
+
struct cdrom_device_info cdi;
/* We hold gendisk and scsi_device references on probe and use
 * the refs on this kref to decide when to release them */
@@ -74,4 +76,13 @@ void sr_vendor_init(Scsi_CD *);
 int sr_cd_check(struct cdrom_device_info *);
 int sr_set_blocklength(Scsi_CD *, int blocklength);
 
+/* sr_acpi.c */
+#ifdef CONFIG_ACPI
+extern void sr_acpi_add_pm_notifier(struct device *);
+extern void sr_acpi_remove_pm_notifier(struct device *);
+#else
+static inline void sr_acpi_add_pm_notifier(struct device *dev) {}
+static inline void sr_acpi_remove_pm_notifier(struct device *dev) {}
+#endif
+
 #endif
diff --git a/drivers/scsi/sr_acpi.c b/drivers/scsi/sr_acpi.c
new file mode 100644
index 000..ce6bc11
--- /dev/null
+++ b/drivers/scsi/sr_acpi.c
@@ -0,0 +1,64 @@
+#include 
+#include 
+#include 
+#include 
+#include 
+#include "sr.h"
+
+static void sr_acpi_wake_dev(acpi_handle handle, u32 event, void *context)
+{
+   struct device *dev = context;
+   struct scsi_cd *cd = dev_get_drvdata(dev);
+
+   if (event == ACPI_NOTIFY_DEVICE_WAKE && pm_runtime_suspended(dev)) {
+   cd->need_eject = 1;
+   pm_runtime_resume(dev);
+   }
+}
+
+void sr_acpi_add_pm_notifier(struct device *dev)
+{
+   struct acpi_device *acpi_dev;
+   acpi_handle handle;
+   acpi_status status;
+   struct scsi_device *sdev = to_scsi_device(dev);
+
+   if (!sdev->can_power_off)
+   return;
+
+   handle = DEVICE_ACPI_HANDLE(dev);
+   if (!handle)
+   return;
+
+   status = acpi_bus_get_device(handle, &acpi_dev);
+   if (ACPI_FAILURE(status))
+   return;
+
+   acpi_power_resource_register_device(dev, handle);
+   acpi_install_notify_handler(handle, ACPI_SYSTEM_NOTIFY,

Re: [PATCH v7 3/6] scsi: sr: support zero power ODD(ZPODD)

2012-09-27 Thread Aaron Lu 
On 09/22/2012 05:02 AM, Rafael J. Wysocki wrote:
> On Friday, September 21, 2012, Aaron Lu wrote:
>> On Fri, Sep 21, 2012 at 12:07:23AM +0200, Rafael J. Wysocki wrote:
>>> On Wednesday, September 12, 2012, Aaron Lu wrote:
  static struct scsi_driver sr_template = {
.owner  = THIS_MODULE,
 @@ -87,6 +89,8 @@ static struct scsi_driver sr_template = {
.name   = "sr",
.probe  = sr_probe,
.remove = sr_remove,
 +  .suspend= sr_suspend,
 +  .resume = sr_resume,
},
.done   = sr_done,
  };
 @@ -172,6 +176,52 @@ static void scsi_cd_put(struct scsi_cd *cd)
mutex_unlock(&sr_ref_mutex);
  }
>>>
>>> Besides, I need some help to understand how this is supposed to work.
>>>
>>> Do I think correctly that sr_suspend(), for example, will be run by the
>>> SCSI bus type layer in case of a CD device runtime suspend?  However,
>>
>> Yes.
>>
>>> won't this routine be used during system suspend as well and won't it cause
>>> problems to happen if so?
>>
>> On system suspend, nothing needs to be done.
>> I'll add the following code in next version.
>>
>>  if (!PMSG_IS_AUTO(msg))
>>  return 0;
> 
> Please don't.  The pm_message_t thing is obsolete and shoulnd't really be
> used by device drivers.  I know that ATA relies on it internally, but that's
> just something that needs to be changed at one point.
> 
> Moreover, I'd like to migrate SCSI drivers to the PM handling based on struct
> dev_pm_ops eventually and your change is kind of going in the opposite
> direction.  I don't know how much effort the migration is going to take,
> though, so perhaps we can just make this change first.

Does the following change look OK?

diff --git a/drivers/scsi/scsi_pm.c b/drivers/scsi/scsi_pm.c
index dc0ad85..1fb7ccc 100644
--- a/drivers/scsi/scsi_pm.c
+++ b/drivers/scsi/scsi_pm.c
@@ -143,7 +143,15 @@ static int scsi_runtime_suspend(struct device *dev)
 
dev_dbg(dev, "scsi_runtime_suspend\n");
if (scsi_is_sdev_device(dev)) {
-   err = scsi_dev_type_suspend(dev, PMSG_AUTO_SUSPEND);
+   err = scsi_device_quiesce(to_scsi_device(dev));
+   if (err)
+   goto out;
+
+   err = pm_generic_runtime_suspend(dev);
+   if (!err)
+   goto out;
+
+   scsi_device_resume(to_scsi_device(dev));
if (err == -EAGAIN)
pm_schedule_suspend(dev, jiffies_to_msecs(
round_jiffies_up_relative(HZ/10)));
@@ -151,6 +159,7 @@ static int scsi_runtime_suspend(struct device *dev)
 
/* Insert hooks here for targets, hosts, and transport classes */
 
+out:
return err;
 }
 
@@ -159,11 +168,17 @@ static int scsi_runtime_resume(struct device *dev)
int err = 0;
 
dev_dbg(dev, "scsi_runtime_resume\n");
-   if (scsi_is_sdev_device(dev))
+   if (scsi_is_sdev_device(dev)) {
+   err = pm_generic_runtime_resume(dev);
+   if (err)
+   goto out;
+
err = scsi_dev_type_resume(dev);
+   }
 
/* Insert hooks here for targets, hosts, and transport classes */
 
+out:
return err;
 }
 

And I'll define runtime callbacks for sr and sd.

Thanks,
Aaron

--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html