On 09/24/2013 10:51 PM, Ric Wheeler wrote:
> On 08/29/2013 09:06 AM, Hannes Reinecke wrote:
>> Hi James,
>>
>> On 08/07/2013 08:43 AM, Ren Mingxin wrote:
>>> Hi, James:
>>>
>>> On 07/11/2013 04:35 AM, Ewan Milne wrote:
Looks good. We have been testing this extensively.
Acked-by: Ewa
On Tue, Sep 24 2013 at 4:44pm -0400,
Martin K. Petersen wrote:
> The other headache is what happens if a stacking driver gets -EIO or
> -EREMOTEIO on a WRITE SAME request. That's what Mike was trying to fix
> with his patch. Maybe it would make sense for us to use -EINVAL or
> something similar
> -Original Message-
> From: Mike Christie [mailto:micha...@cs.wisc.edu]
> Sent: Tuesday, September 24, 2013 10:21 AM
> To: KY Srinivasan
> Cc: Jack Wang; Greg KH; linux-ker...@vger.kernel.org;
> de...@linuxdriverproject.org; oher...@suse.com; jbottom...@parallels.com;
> h...@infradead.or
> "Mikulas" == Mikulas Patocka writes:
Mikulas> Propagating the limits up the tree won't work anyway because of
Mikulas> a race condition. Think of this case:
Mikulas> 1. We test queue limits and find out that the device supports
Mikulas>WRITE_SAME
Mikulas> 2. We build a WRITE_SAME bio t
On 08/29/2013 09:06 AM, Hannes Reinecke wrote:
Hi James,
On 08/07/2013 08:43 AM, Ren Mingxin wrote:
Hi, James:
On 07/11/2013 04:35 AM, Ewan Milne wrote:
Looks good. We have been testing this extensively.
Acked-by: Ewan D. Milne
Do you think this patchset can be applied? If so, When? Perhap
From: Nicholas Bellinger
This patch converts tcm_fc to use transport_init_session_tags()
pre-allocation logic for struct ft_cmd descriptors using per-cpu
session tag pooling in order to effectively avoid memory allocation
+ release for each received I/O.
It adds percpu_ida_alloc() in ft_recv_cmd
On Fri, Sep 6, 2013 at 4:47 PM, Bjorn Helgaas wrote:
> On Fri, Sep 6, 2013 at 3:51 AM, Jiri Kosina wrote:
>>> >> > Commit d5dea7d95 ("PCI: msi: Disable msi interrupts when we initialize
>>> >> > a
>>> >> > pci device") makes MSIs be forcibly disabled at boot time.
>>> >> >
>>> >> > It turns out
There is an error with the medium access timeout feature of the sd driver. The
sdkp->medium_access_timed_out value is set to zero in sd_done() in the wrong
place. It is set to zero only if a command returns sense data. If an I/O
command times out, error handling succeeds, and the I/O commands com
On Mon, 16 Sep 2013 oli...@neukum.org wrote:
> From: Oliver Neukum
>
> It makes no sense to flush the cache of a device without medium.
> Errors during suspend must be handled according to their causes.
> Errors due to missing media or unplugged devices must be ignored.
> Errors due to devices b
On 13-09-24 03:12 PM, Jeremy Linton wrote:
On 9/24/2013 12:39 AM, Hannes Reinecke wrote:
My drives support 'report opcodes', and report that write same is
supported: ... 93 16Write same(16) ...
but no support for page 'b0'. And yes, these are real SAS drives.
So t
http://marc.info/?l=linux-scsi&m=133901769900806&w=2
Can we reconsider applying patch 4 in Mike's set?
The problem still exists, and there was never another
solution proposed as far as I can see. (I posted a
question about this a while back...)
It is a big issue for people who happen to get a
KO
On 9/24/2013 12:39 AM, Hannes Reinecke wrote:
> My drives support 'report opcodes', and report that write same is
> supported: ... 93 16Write same(16) ...
>
> but no support for page 'b0'. And yes, these are real SAS drives.
So the question is, how many devices get t
On Fri, 20 Sep 2013, Mike Snitzer wrote:
> On Thu, Sep 19 2013 at 12:13pm -0400,
> Mike Snitzer wrote:
>
> > Workaround the SCSI layer's problematic WRITE SAME heuristics by
> > disabling WRITE SAME in the DM multipath device's queue_limits if an
> > underlying device disabled it.
>
> ...
>
Curious. There were some commits made recently that make it possible using
LSI's raid controllers.
I checked out the LSI website and it sees that the Syncro product line has been
updated to include support for Linux.
Can anyone comment on if these patches enable the feature stand-alone with ANY
Hi. I'm running Ubuntu 13.04 Raring on a Power Edge R515 with Dell H700
controller. I'm using kernel 3.10.12
Its a test platform and I'm driving quite a bit of i/o through it. Under load
at times, the megaraid_sas driver will spit out the following error:
Sep 24 11:16:17 ubuntu1 kernel: [52243.8
On 09/24/2013 07:35 AM, KY Srinivasan wrote:
>
>
>> -Original Message-
>> From: Jack Wang [mailto:xjtu...@gmail.com]
>> Sent: Tuesday, September 24, 2013 5:08 AM
>> To: KY Srinivasan
>> Cc: Greg KH; linux-ker...@vger.kernel.org; de...@linuxdriverproject.org;
>> oher...@suse.com; jbottom..
On Tue, Sep 24 2013 at 9:49am -0400,
Martin K. Petersen wrote:
> > "Mike" == Mike Snitzer writes:
>
> Mike> So are there drives like this?:
> Mike> 1) don't support RSOC
> Mike> 2) do support WRITE SAME
> Mike> 3) do populate VPD page with either WRITE SAME w/ discard bit set
> Mike>or
> "Mike" == Mike Snitzer writes:
Mike> So are there drives like this?:
Mike> 1) don't support RSOC
Mike> 2) do support WRITE SAME
Mike> 3) do populate VPD page with either WRITE SAME w/ discard bit set
Mike>or UNMAP?
Yes.
But again, the fundamental issue here is not the drives. It's the
On Tue, 2013-09-24 at 11:37 +0200, Paolo Bonzini wrote:
> Il 21/09/2013 00:03, Martin K. Petersen ha scritto:
> >
> > The major headache here of course is that WRITE SAME is inherently
> > destructive. We can't just fire off one during discovery and see if it
> > works. For WRITE you can issue a c
On 09/24/2013 02:35 PM, KY Srinivasan wrote:
-Original Message-
From: Jack Wang [mailto:xjtu...@gmail.com]
Sent: Tuesday, September 24, 2013 5:08 AM
To: KY Srinivasan
Cc: Greg KH; linux-ker...@vger.kernel.org; de...@linuxdriverproject.org;
oher...@suse.com; jbottom...@parallels.com; h.
> -Original Message-
> From: Jack Wang [mailto:xjtu...@gmail.com]
> Sent: Tuesday, September 24, 2013 5:08 AM
> To: KY Srinivasan
> Cc: Greg KH; linux-ker...@vger.kernel.org; de...@linuxdriverproject.org;
> oher...@suse.com; jbottom...@parallels.com; h...@infradead.org; linux-
> s...@vger
On Tue, Sep 24 2013 at 1:39am -0400,
Hannes Reinecke wrote:
> On 09/23/2013 08:18 PM, Ewan Milne wrote:
> > On Fri, 2013-09-20 at 18:03 -0400, Martin K. Petersen wrote:
> > ...
> >> Only a handful of the very latest and greatest devices support RSOC. The
> >> number of devices that support WRITE
On 09/21/2013 07:24 AM, KY Srinivasan wrote:
>
>
>> -Original Message-
>> From: Greg KH [mailto:gre...@linuxfoundation.org]
>> Sent: Friday, September 20, 2013 1:32 PM
>> To: KY Srinivasan
>> Cc: linux-ker...@vger.kernel.org; de...@linuxdriverproject.org;
>> oher...@suse.com; jbottom...@p
Il 21/09/2013 00:03, Martin K. Petersen ha scritto:
>
> The major headache here of course is that WRITE SAME is inherently
> destructive. We can't just fire off one during discovery and see if it
> works. For WRITE you can issue a command with a transfer length of 0 to
> see if things work. But un
On Wed, Sep 18, 2013 at 09:33:04AM +0200, Gerd Hoffmann wrote:
> > > While being at it rename the list head from "list" to "work", preparing
> > > for the addition of a second list.
> >
> > Why do you even the list?
>
> The list was already there when I took over maintainance ...
>
> > What woul
Hi James,
Can you please help to review the patch and comment it?
Thanks,
Joe
On 09/20/13 08:16, Joe Jin wrote:
> When do disk pull/insert test we encountered below:
>
> WARNING: at fs/sysfs/dir.c:455 sysfs_add_one+0xbc/0xe0()
> Hardware name: SUN FIRE X4370 M2 SERVER
> sysfs: cannot create du
26 matches
Mail list logo
