Sagi Grimberg wrote on 01/08/2015 05:45 AM:
>> RFC 3720 namely requires that iSCSI numbering is
>> session-wide. This means maintaining a single counter for all MC/S
>> sessions. Such a counter would be a contention point. I'm afraid that
>> because of that counter performance on a multi-socket ini
The initio driver has for many years had two copies of the
same module device table. One of them is also used for registering
the other driver, the other one is entirely useless after the
large scale cleanup that Alan Cox did back in 2007.
The compiler warns about this whenever the driver is built
The ips driver contains
#warning "This driver has only been tested on the x86/ia64/x86_64 platforms"
which gets printed by the compiler every time this driver gets
build for something other than those three architectures. The same
is true for most other drivers, but none of them prints a warning
This seemed to bounce on most of the lists to which it originally
sent. I'm resending..
I've uploaded an introductory design document at
https://github.com/Seagate/SMR_FS-EXT4. I'll update regularly. Please
feel free to send questions my way.
It seems there are many sub topics requested related
On Thu, 2015-01-08 at 07:43 +0100, Hannes Reinecke wrote:
> Use an external buffer for __scsi_print_command() and
> move command logging over to use the per-cpu logging
> buffer. With that we can guarantee the command always
> will always be formatted in one line.
> So we can even print out a varia
Replaced null tests on the value return by pci_map_single by calls to
pci_dma_mapping_error.
Added initialization of the ret variable, to return an error code on
failure.
Reorganized error handling code to remove the need for tests on
dma_addr_out, dma_addr_in, and mf.
Added new error labels for
On Thu, 2015-01-08 at 07:43 +0100, Hannes Reinecke wrote:
> - sdev_printk(prefix, (scmd)->device, fmt, ##a)
> +extern int sdev_prefix_printk(const char *, const struct scsi_device *,
> + const char *, const char *, ...);
> +
> +#define sdev_printk(l, sdev, fmt, a...)
On Wed, 2015-01-14 at 01:21 +0800, kbuild test robot wrote:
> Hi Wu,
>
> FYI, this happens on a merge commit, which indicates conflicting
> changes with one of the below merged branches.
>
> d48f782 Merge 'scsi/for-next' into devel-lkp-ib03-powerpc-201501140043
> c03f620 Merge 'sound/for-next' in
On Tue, Jan 13 2015 at 9:28am -0500,
Bart Van Assche wrote:
> On 01/13/15 15:18, Mike Snitzer wrote:
> > On Tue, Jan 13 2015 at 7:29am -0500,
> > Bart Van Assche wrote:
> >> However, I hit another issue while running I/O on top of a multipath
> >> device (on a kernel with lockdep and SLUB memo
On 01/13/2015 04:29 PM, Christoph Hellwig wrote:
> Use a single set of the hardware description headers instead of
> having them in the source tree twice.
>
> Signed-off-by: Christoph Hellwig
A round of applause.
Reviewed-by: Hannes Reinecke
Cheers,
Hannes
--
Dr. Hannes Reinecke
Thanks,
Ive applied the series to the scsi-for-3.20 branch.
--
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
Some devices might not implement config space access
(e.g. remoteproc used not to - before 3.9).
virtio/scsi needs config space access so make it
fail gracefully if not there.
Signed-off-by: Michael S. Tsirkin
---
drivers/scsi/virtio_scsi.c | 6 ++
1 file changed, 6 insertions(+)
diff --git
2015-01-12 18:36 GMT+09:00 Christoph Hellwig :
> On Sun, Jan 11, 2015 at 10:50:02PM +0900, Akinobu Mita wrote:
>> While accessing a scsi_device, the use count of the underlying LLDD module
>> is incremented. The module reference is retrieved through .module field of
>> struct scsi_host_template.
>
On 1/12/2015 10:05 PM, Mike Christie wrote:
On 01/11/2015 03:23 AM, Sagi Grimberg wrote:
On 1/9/2015 8:00 PM, Michael Christie wrote:
Session wide command sequence number synchronization isn't something to
be removed as part of the MQ work. It's a iSCSI/iSER protocol
requirement.
That is,
On 1/12/2015 2:56 PM, Bart Van Assche wrote:
On 01/11/15 10:40, Sagi Grimberg wrote:
I would say there is no need for specific coordination from iSCSI PoV.
This is exactly what flow steering is designed for. As I see it, in
order to get the TX/RX to match rings, the user can attach 5-tuple rules
15 matches
Mail list logo
