On Thu, Aug 28, 2014 at 02:51:21PM +0530, Suman Tripathi wrote:
> This patch implements the feature to skip the PHY and clock
> initialization if it is already configured by the firmware.
>
> Signed-off-by: Loc Ho
> Signed-off-by: Suman Tripathi
Applied to libata/for-3.17-fixes.
Thanks.
--
t
On Thu, Aug 28, 2014 at 02:51:22PM +0530, Suman Tripathi wrote:
> Due to HW errata the APM X-Gene AHCI SATA host controller reports link
> down even if the device presence is detected. This issue is due to speed
> negotiation failure. This patch implements the algorithm to retry the
> COMRESET if P
One more request:
if you already do major surgery to constan.c can we get rid of the
CONFIG_SCSI_CONSTANTS all over it?
E.g. only keep the code under CONFIG_SCSI_CONSTANTS in, maybe
add a no-constants.c for the stubs and move the bit of glue code
always compiled to scsi.c?
--
To unsubscribe from
> + *cdb_name = NULL;
> + if (cmd >= 0xc0)
Can we get a START_VENDOR_SPECIFIC_CMD or similar define for 0xc0,
please?
Otherwise looks good to me,
Reviewed-by: Christoph Hellwig
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...
On Wed, Sep 03, 2014 at 12:00:39AM -0500, micha...@cs.wisc.edu wrote:
> From: Mike Christie
>
> This patches fixes a potential buffer overrun in __iscsi_conn_send_pdu.
> This function is used by iscsi drivers and userspace to send iscsi PDUs/
> commands. For login commands, we have a set buffer s
On Mon, Sep 01, 2014 at 01:14:23AM +, Elliott, Robert (Server Storage)
wrote:
> Before this patch set, ratelimited printing was impossible because
> there were so many partial-line printk calls. This patch set
> may resolve that problem.
>
> Multiple related lines may still cause problems; i
On Mon, Sep 01, 2014 at 01:00:26AM +, Elliott, Robert (Server Storage)
wrote:
> > -Original Message-
> > From: linux-scsi-ow...@vger.kernel.org [mailto:linux-scsi-
> > ow...@vger.kernel.org] On Behalf Of Christoph Hellwig
> > Sent: Sunday, 31 August, 2014 5:26 PM
> ...
> > On Thu, Aug
On Wed, Sep 03, 2014 at 12:06:15PM +0200, Hannes Reinecke wrote:
> Decode the return value if the command abort failed.
I've not seen an answer to my question in reply to the previous version
of this. Why would you do pretty printing of a variable that can just
return SUCCESS or FAILURE?
--
To u
On Fri, Sep 05, 2014 at 10:24:40AM +0900, Yoshihiro YUNOMAE wrote:
> > #define SA_NAME_LIST_SZ ARRAY_SIZE(sa_names_arr)
>
> We can delete SA_NAME_LIST_SZ because we define it out of
> CONFIG_SCSI_CONSTANTS.
I'd generally prefer to just use ARRAY_SIZE() directly instead of adding
another layer o
Looks good,
Reviewed-by: Christoph Hellwig
--
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
On Wed, Sep 03, 2014 at 12:06:03PM +0200, Hannes Reinecke wrote:
> Convert scsi_normalize_sense() and frieds to return 'bool'
> instead of an integer.
Looks good with the small fix spotted by Yunomae-san.
Signed-off-by: Christoph Hellwig
--
To unsubscribe from this list: send the line "unsubscri
On Wed, Sep 03, 2014 at 12:06:04PM +0200, Hannes Reinecke wrote:
> Last caller is gone, so we can remove it.
>
> Signed-off-by: Hannes Reinecke
Looks good,
Reviewed-by: Christoph Hellwig
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord
On Wed, Sep 03, 2014 at 12:06:02PM +0200, Hannes Reinecke wrote:
> Currently we're only decoding sense extras for tape devices.
> And even there only for fixed format sense formats.
> As this is of rather limited use in the general case we should
> be stop trying to decode sense extras; the tape dr
On Wed, Sep 03, 2014 at 12:06:01PM +0200, Hannes Reinecke wrote:
> If scsi_normalize_sense() fails we couldn't decode the sense
> buffer, and the scsi_sense_hdr fields are invalid.
> For those cases we should rather dump the sense buffer
> and not try to decode invalid fields.
This description sti
On Wed, Sep 03, 2014 at 12:05:59PM +0200, Hannes Reinecke wrote:
> Like scmd_printk(), but the device name is passed in as
> a string. Can be used by eg ULDs which do not have access
> to the scsi_cmnd structure.
>
> Signed-off-by: Hannes Reinecke
Looks good,
Reviewed-by: Christoph Hellwig
--
On Wed, Sep 03, 2014 at 12:05:57PM +0200, Hannes Reinecke wrote:
> Remove all uncommented debugging code and move all
> printk() statements over to dev_printk().
> And while we're at it we should be doing a whitespace
> cleanup, too.
Looks good,
Reviewed-by: Christoph Hellwig
--
To unsubscribe f
On Wed, Jul 30, 2014 at 09:55:10AM +0200, Hannes Reinecke wrote:
> ZAC (zoned-access command) drives translate into ZBC (Zoned block
> command) device type for SCSI. So implement the correct mappings
> into libata-scsi and update the SCSI command set versions.
Patch 2-3 look good to me.
Thanks.
Hello, Hannes.
Sorry about the delay.
On Wed, Jul 30, 2014 at 09:55:08AM +0200, Hannes Reinecke wrote:
> ata_dev_classify() just uses the 'lbah' and 'lbam'
> fields from the taskfile, so we can as well use those
> as arguments and rip out the custom code from sas_ata.
I wonder whether it'd easie
Hey,
On Fri, Sep 05, 2014 at 04:22:42PM -0700, Dmitry Torokhov wrote:
> > I don't get it. This is a behavior userland already depends on for
> > boots. What's there to agree or disagree? This is just a fact that
> > we can't do this w/o disturbing some userlands in a major way.
>
> I am just e
Hi Tejun,
On Sat, Sep 06, 2014 at 07:55:33AM +0900, Tejun Heo wrote:
> Hello, Dmitry.
>
> On Fri, Sep 05, 2014 at 03:49:17PM -0700, Dmitry Torokhov wrote:
> > On Sat, Sep 06, 2014 at 07:31:39AM +0900, Tejun Heo wrote:
> > > On Sat, Sep 06, 2014 at 07:29:56AM +0900, Tejun Heo wrote:
> > > > It is
On Fri, Sep 05, 2014 at 04:05:30PM -0700, Arjan van de Ven wrote:
> On 9/5/2014 3:52 PM, Dmitry Torokhov wrote:
> >On Fri, Sep 05, 2014 at 03:45:08PM -0700, Arjan van de Ven wrote:
> >>On 9/5/2014 3:29 PM, Tejun Heo wrote:
> >>>Hello, Dmitry.
> >>>
> >>>On Fri, Sep 05, 2014 at 11:10:03AM -0700, Dmi
On 9/5/2014 3:52 PM, Dmitry Torokhov wrote:
On Fri, Sep 05, 2014 at 03:45:08PM -0700, Arjan van de Ven wrote:
On 9/5/2014 3:29 PM, Tejun Heo wrote:
Hello, Dmitry.
On Fri, Sep 05, 2014 at 11:10:03AM -0700, Dmitry Torokhov wrote:
I do not agree that it is actually user-visible change: generally
Hello,
On Fri, Sep 05, 2014 at 03:52:48PM -0700, Dmitry Torokhov wrote:
> Ahem... and they sure it works reliably with large storage arrays? With
> SCSI doing probing asynchronously already?
I believe this has been mentioned before too but, yes, SCSI device
probing is asynchronous and parallelize
Hello, Dmitry.
On Fri, Sep 05, 2014 at 03:49:17PM -0700, Dmitry Torokhov wrote:
> On Sat, Sep 06, 2014 at 07:31:39AM +0900, Tejun Heo wrote:
> > On Sat, Sep 06, 2014 at 07:29:56AM +0900, Tejun Heo wrote:
> > > It is for storage devices which always have guaranteed synchronous
> > > probing on modu
On Fri, Sep 05, 2014 at 03:45:08PM -0700, Arjan van de Ven wrote:
> On 9/5/2014 3:29 PM, Tejun Heo wrote:
> >Hello, Dmitry.
> >
> >On Fri, Sep 05, 2014 at 11:10:03AM -0700, Dmitry Torokhov wrote:
> >>I do not agree that it is actually user-visible change: generally speaking
> >>you
> >>do not real
On 9/5/2014 3:29 PM, Tejun Heo wrote:
Hello, Dmitry.
On Fri, Sep 05, 2014 at 11:10:03AM -0700, Dmitry Torokhov wrote:
I do not agree that it is actually user-visible change: generally speaking you
do not really know if device is there or not. They come and go. Like I said,
consider all permutat
Hello, Luis.
On Fri, Sep 05, 2014 at 11:12:17AM -0700, Luis R. Rodriguez wrote:
> Meanwhile we are allowing a major design consideration such as a 30
> second timeout for both init + probe all of a sudden become a hard
> requirement for device drivers. I see your point but can't also be
> introduc
On Sat, Sep 06, 2014 at 07:29:56AM +0900, Tejun Heo wrote:
> It is for storage devices which always have guaranteed synchronous
> probing on module load and well-defined probing order. Sure, modern
> setups are a lot more dynamic but I'm quite certain that there are
> setups in the wild which depe
Hello, Dmitry.
On Fri, Sep 05, 2014 at 11:10:03AM -0700, Dmitry Torokhov wrote:
> I do not agree that it is actually user-visible change: generally speaking you
> do not really know if device is there or not. They come and go. Like I said,
> consider all permutations, with hot-pluggable buses, def
Hi Luis,
On Thu, Sep 04, 2014 at 11:37:23PM -0700, Luis R. Rodriguez wrote:
> 1) when a built-in driver takes a few seconds to initialize its
>delays can stall the overall boot process
This patch does not solve the 2nd issue fully as it only calls probe
asynchronously during driver registrati
On Fri, Sep 05, 2014 at 11:12:17AM -0700, Luis R. Rodriguez wrote:
> On Fri, Sep 5, 2014 at 10:49 AM, Tejun Heo wrote:
> > Hello,
> >
> > On Fri, Sep 05, 2014 at 09:44:05AM -0700, Dmitry Torokhov wrote:
> >> Which problem are we talking about here though? It does solve the slow
> >> device
> >> s
On Fri, Sep 5, 2014 at 10:49 AM, Tejun Heo wrote:
> Hello,
>
> On Fri, Sep 05, 2014 at 09:44:05AM -0700, Dmitry Torokhov wrote:
>> Which problem are we talking about here though? It does solve the slow device
>> stalling the rest if the kernel booting (non-module case) for me.
>
> The other one.
On Sat, Sep 06, 2014 at 02:49:25AM +0900, Tejun Heo wrote:
> Hello,
>
> On Fri, Sep 05, 2014 at 09:44:05AM -0700, Dmitry Torokhov wrote:
> > Which problem are we talking about here though? It does solve the slow
> > device
> > stalling the rest if the kernel booting (non-module case) for me.
>
>
Hello,
On Fri, Sep 05, 2014 at 09:44:05AM -0700, Dmitry Torokhov wrote:
> Which problem are we talking about here though? It does solve the slow device
> stalling the rest if the kernel booting (non-module case) for me.
The other one. The one with timeout. Neither cxgb4 or pata_marvell
has slow
James and Jens:
I got a WARNING when unbinding the sd driver from a USB flash drive and
then binding it back again. Here's where the flash drive gets probed
initially:
[ 143.300886] usb-storage 4-8:1.0: usb_probe_interface
[ 143.300911] usb-storage 4-8:1.0: usb_probe_interface - got id
[ 143
On Fri, Sep 05, 2014 at 12:59:49PM +0200, Oleg Nesterov wrote:
> On 09/04, Luis R. Rodriguez wrote:
> >
> > From: "Luis R. Rodriguez"
> >
> > The new umh kill option has allowed kthreads to receive
> > kill signals but they are generally accepting all sources
> > of kill signals
>
> And I think t
On Wed, 3 Sep 2014, James Bottomley wrote:
> On Wed, 2014-09-03 at 16:30 -0400, Alan Stern wrote:
> > On Wed, 3 Sep 2014, James Bottomley wrote:
> >
> > > Before we embark on elaborate hacks, why don't we just make the capacity
> > > writeable (by root) in sysfs from userspace (will require block
On Fri, Sep 05, 2014 at 01:24:17PM +0200, Oleg Nesterov wrote:
> On 09/04, Luis R. Rodriguez wrote:
> >
> > struct driver_private {
> > struct kobject kobj;
> > struct klist klist_devices;
> > struct klist_node knode_bus;
> > struct module_kobject *mkobj;
> > + struct driver_atta
On Friday, September 05, 2014 11:12:41 PM Tejun Heo wrote:
> On Fri, Sep 05, 2014 at 12:47:16AM -0700, Luis R. Rodriguez wrote:
> > Ah -- well without it the way we "find" drivers that need this new
> > "async feature" is by a bug report and folks saying their system can't
> > boot, or they say the
The disable_discovery module parameter is declared and only used by
mpt2sas_scsih.c. Remove the extra copy in mpt2sas_base.c.
Signed-off-by: Joe Lawrence
---
drivers/scsi/mpt2sas/mpt2sas_base.c |4
1 file changed, 4 deletions(-)
diff --git a/drivers/scsi/mpt2sas/mpt2sas_base.c
b/drive
On 09/05/14 15:56, Douglas Gilbert wrote:
With scsi-mq I think many LLDs probably have a new
race possibility between a surprise rmmod of the LLD
and another thread presenting a new command at about
the same time (or another thread's command completing
around that time). Does anything above the L
On Fri, Sep 05, 2014 at 12:47:16AM -0700, Luis R. Rodriguez wrote:
> Ah -- well without it the way we "find" drivers that need this new
> "async feature" is by a bug report and folks saying their system can't
> boot, or they say their device doesn't come up. That's all. Tracing
> this to systemd an
On Fri, 2014-09-05 at 09:31 -0400, James Smart wrote:
> On 9/5/2014 1:35 AM, Christoph Hellwig wrote:
> > - patches that you send on with your maintainer hat on should be
> > signed off by you, not just reviewed.
>
> ok - but I guess I had a different interpretation of the meaning for
> sig
With scsi-mq I think many LLDs probably have a new
race possibility between a surprise rmmod of the LLD
and another thread presenting a new command at about
the same time (or another thread's command completing
around that time). Does anything above the LLD stop
this happening?
Looking at mpt3sas
no problem, although if these rules were published, I would have tried
to do so earlier.
although - I do have a couple of questions.
On 9/5/2014 1:35 AM, Christoph Hellwig wrote:
I've applied the series, but for next time can you make sure to follow
the proper format:
- remove the version
On 09/04, Luis R. Rodriguez wrote:
>
> struct driver_private {
> struct kobject kobj;
> struct klist klist_devices;
> struct klist_node knode_bus;
> struct module_kobject *mkobj;
> + struct driver_attach_work *attach_work;
> struct device_driver *driver;
I am not
On 09/04, Luis R. Rodriguez wrote:
>
> From: "Luis R. Rodriguez"
>
> The new umh kill option has allowed kthreads to receive
> kill signals but they are generally accepting all sources
> of kill signals
And I think this is right,
> while the original motivation was to enable
> through the OOM fr
On Thu, Sep 04, 2014 at 10:40:14PM -0700, Christoph Hellwig wrote:
> Looks good to me.
>
> Olaf, Hannes - can I get another review for this (and the older hyperv
> scanning patch set)?
I agree this looks useful because on a
59753a805499f1ffbca4ac0a24b3dff67bf1 3.17rc2 kernel with
92578ea Dri
On Fri, 2014-09-05 at 00:47 -0700, Luis R. Rodriguez wrote:
> On Fri, Sep 5, 2014 at 12:19 AM, Tejun Heo wrote:
> > On Thu, Sep 04, 2014 at 11:37:24PM -0700, Luis R. Rodriguez wrote:
> > ...
> >> + /*
> >> + * I got SIGKILL, but wait for 60 more seconds for completion
> >
On Fri, Sep 5, 2014 at 12:19 AM, Tejun Heo wrote:
> On Thu, Sep 04, 2014 at 11:37:24PM -0700, Luis R. Rodriguez wrote:
> ...
>> + /*
>> + * I got SIGKILL, but wait for 60 more seconds for completion
>> + * unless chosen by the OOM killer. This delay is there a
On 09/05/2014 08:37 AM, Luis R. Rodriguez wrote:
> From: "Luis R. Rodriguez"
>
> Its reported that mptsas can at times take over 30 seconds
> to recognize SCSI storage devices [0], this is done on the
> driver's probe path. Use the the new asynch probe to
> circumvent systemd from killing this dr
On Thu, Sep 04, 2014 at 11:37:24PM -0700, Luis R. Rodriguez wrote:
...
> + /*
> + * I got SIGKILL, but wait for 60 more seconds for completion
> + * unless chosen by the OOM killer. This delay is there as a
> + * workaround for boot failure caused
On Thu, Sep 04, 2014 at 11:37:26PM -0700, Luis R. Rodriguez wrote:
> From: "Luis R. Rodriguez"
>
> Its reported that mptsas can at times take over 30 seconds
> to recognize SCSI storage devices [0], this is done on the
> driver's probe path. Use the the new asynch probe to
> circumvent systemd fr
53 matches
Mail list logo
