On 02/19/2013 05:33 PM, James Bottomley wrote:
On Tue, 2013-02-19 at 10:30 -0600, Michael Christie wrote:
On Feb 19, 2013, at 2:18 AM, Hannes Reinecke wrote:
diff --git a/drivers/scsi/cxgbi/libcxgbi.c b/drivers/scsi/cxgbi/libcxgbi.c
index b44c1cf..95105c0 100644
--- a/drivers/scsi/cxgbi/libcx
In August 2010, Jens and Alan discussed about "Runtime PM and the block
layer". http://marc.info/?t=12825910841&r=1&w=2
And then Alan has given a detailed implementation guide:
http://marc.info/?l=linux-scsi&m=133727953625963&w=2
To test:
# ls -l /sys/block/sda
/sys/devices/pci:00/:00:
From: Lin Ming
Add runtime pm helper functions:
void blk_pm_runtime_init(struct request_queue *q, struct device *dev)
- Initialization function for drivers to call.
int blk_pre_runtime_suspend(struct request_queue *q)
- If any requests are in the queue, mark last busy and return -EBUSY.
From: Lin Ming
Add a flag REQ_PM to identify the request is PM related, such requests
will not change the device request queue's runtime status. It is
intended to be used in driver's runtime PM callback, so that driver can
perform some IO to the device there with the queue's runtime status
unaffe
From: Lin Ming
When a request is added:
If device is suspended or is suspending and the request is not a
PM request, resume the device.
When the last request finishes:
Call pm_runtime_mark_last_busy().
When pick a request:
If device is resuming/suspending, then only PM request i
From: Lin Ming
Uses block layer runtime pm helper functions in
scsi_runtime_suspend/resume for devices that take advantage of it.
Remove scsi_autopm_* from sd open/release path and check_events path.
Signed-off-by: Lin Ming
Signed-off-by: Aaron Lu
---
drivers/scsi/scsi_pm.c | 84
On 02/20/2013 09:43 AM, Nicholas A. Bellinger wrote:
> From: Nicholas Bellinger
>
> Hi mkp, hch, & Co,
>
> Please review this patch to add support for WRITE_SAME w/ UNMAP=0
> emulation into FILEIO, as I'd really like to include this in the
> upcoming for-3.9 target merge.
>
> Thank you,
>
> --
Hello,
For a 64-bit DMA capable PCIe storage HBA running under the 64-bit
AMD-VI IOMMU environment, the amd_iommu code was observed to hit an
overflow when it tries to page align the dma_parms->segment_boundary_mask.
This overflow would eventually trigger the BUG_ON in the iommu-helper's
iommu_is_
From: Nicholas Bellinger
Hi mkp, hch, & Co,
Please review this patch to add support for WRITE_SAME w/ UNMAP=0
emulation into FILEIO, as I'd really like to include this in the
upcoming for-3.9 target merge.
Thank you,
--nab
-
More prep work for immutable bvecs/effecient bio splitting - usage of
bi_vcnt has to be auditing, so getting rid of all the unnecessary usage
makes that easier.
Plus, bio_segments() is really what this code wanted, as it respects the
current value of bi_idx.
Signed-off-by: Kent Overstreet
CC: Je
On 13-02-19 04:52 PM, Dave Jones wrote:
On Tue, Feb 19, 2013 at 04:04:33PM -0500, Douglas Gilbert wrote:
> On 13-02-19 01:37 PM, Tommi Rantala wrote:
> > Hello,
> >
> > Hit this WARNING once while fuzzing the kernel with trinity in a qemu
> > virtual machine as the root user.
> >
>
On Tue, Feb 19, 2013 at 04:04:33PM -0500, Douglas Gilbert wrote:
> On 13-02-19 01:37 PM, Tommi Rantala wrote:
> > Hello,
> >
> > Hit this WARNING once while fuzzing the kernel with trinity in a qemu
> > virtual machine as the root user.
> >
> > Does this make any sense? I have occasionally s
The following changes since commit 5b97fabdc815b4b60bac2328b58c5c7274debf58:
libfc: fix REC handling (2012-12-04 10:16:38 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/rwlove/fcoe.git
tags/for-next-02-19-13
for you to fetch changes up to 1f9
On 13-02-19 01:37 PM, Tommi Rantala wrote:
Hello,
Hit this WARNING once while fuzzing the kernel with trinity in a qemu
virtual machine as the root user.
Does this make any sense? I have occasionally seen some ATA related
troubles while fuzzing in a VM, but this warning is new to me.
[ 490.71
From: Bhanu Prakash Gollapudi
When there are multiple FCFs in the fabric, and one of them becomes
unavailable, the fabric name for the unavailable FCF becomes 0 along
with FIP_FL_AVAIL getting reset. In this case, FCF selection logic does
not select any FCF as it first checks for conflicting FCFs
On 2/19/2013 11:30 AM, Robert Love wrote:
> This series is mostly a resend of previously sent patches. The primary change
> in this series is the addition of the fcoe_sysfs "control" interfaces.
> Additionally there are a few fix/cleanup patches and UAPI conversions. Almost
> all of these patche
From: Krishna Mohan
schedule_delayed_work() is using msec instead of jiffies. On PLOGI
reject from target, remote port retry is scheduled @ 20 sec instead
of 2sec(FC_DEF_E_D_TOV).
XenServer dom0 kernel is configured with CONFIG_HZ=100Hz
Signed-off-by: Krishna Mohan
Signed-off-by: Robert Love
-
From: Neerav Parikh
This patch fixes following deadlock caused by destroying of
an FCoE interface with active NPIV ports on that interface.
Call Trace:
[] schedule+0x64/0x66
[] schedule_timeout+0x36/0xe3
[] ? update_curr+0xd6/0x110
[] ? hrtick_update+0x1b/0x4d
[] ? dequeu
From: Bhanu Prakash Gollapudi
When a CVL is received while we wait to select best FCF, we drop it
without handling it. This causes initiator and the switch to go
out-of-sync. Initiator proceeds selecting one of the FCFs and tries to
send FIP FLOGI. However the switch may reject the FLOGI, as it h
From: Neil Horman
When creating an fcoe interfce, we call fcoe_link_speed_update before we add the
lports fcoe interface to the fc_hostlist. Since network device events like
NETDEV_CHANGE are only processed if an fcoe interface is found with an
underlying netdev that matches the netdev of the ev
From: Al Viro
AFAICS, the situation for fcoe_transport_disable() seems to be
the same as for fcoe_transport_enable(). IOW, shouldn't it have
restart_syscall() removed as well? I don't see any in-tree ->disable()
instances that could return -ERESTARTSYS, anyway...
Signed-off-by: Al Viro
From: Yi Zou
Drop the bnx2fc_xxx versions as they are basically the same.
Signed-off-by: Yi Zou
Cc: Bhanu Prakash Gollapudi
Tested-by: Marcus Dennis
Signed-off-by: Robert Love
---
drivers/scsi/bnx2fc/bnx2fc_fcoe.c | 53 +
1 file changed, 7 insertions(+)
From: Yi Zou
We have fcoe_link_speed_update() in libfcoe ready for use now, take out the
bnx2fc version which is almost the same.
Signed-off-by: Yi Zou
Cc: Bhanu Prakash Gollapudi
Tested-by: Marcus Dennis
Signed-off-by: Robert Love
---
drivers/scsi/bnx2fc/bnx2fc_fcoe.c | 33 ++
From: Yi Zou
Adds support to fcoe_port's newly added get_netdev fucntion pointer for bnx2fc.
Signed-off-by: Yi Zou
Cc: Bhanu Prakash Gollapudi
Tested-by: Marcus Dennis
Signed-off-by: Robert Love
---
drivers/scsi/bnx2fc/bnx2fc_fcoe.c |5 +++--
1 file changed, 3 insertions(+), 2 deletions
From: Yi Zou
Similarly they can be moved into libfcoe instead of being private to fcoe now.
Also add comments particularly on the term LESB to the corresponding function.
Signed-off-by: Yi Zou
Cc: Bhanu Prakash Gollapudi
Tested-by: Marcus Dennis
Signed-off-by: Robert Love
---
drivers/scsi/f
From: Yi Zou
With the previous patch, fcoe_link_speed_update() can be moved into libfcoe and
exported to used by fcoe, bnx2fc, and etc.
Signed-off-by: Yi Zou
Cc: Bhanu Prakash Gollapudi
Tested-by: Marcus Dennis
Signed-off-by: Robert Love
---
drivers/scsi/fcoe/fcoe.c | 35 ---
From: Yi Zou
Adds support to fcoe_port's newly added get_netdev fucntion pointer.
Signed-off-by: Yi Zou
Cc: Bhanu Prakash Gollapudi
Tested-by: Marcus Dennis
Signed-off-by: Robert Love
---
drivers/scsi/fcoe/fcoe.c |1 +
include/scsi/libfcoe.h | 12
2 files changed, 13 in
From: Yi Zou
Currently, in the default kernel fcoe driver, it is needed to get to the
underlying
private per fcoe transport's private structure, e.g., fcoe_interface in
fcoe.ko, and returns the associated netdev. The similar logic exists in other
fcoe drivers, e.g., bnx2fc, so we add a function
Convert libfc, libfcoe and fcoe's debug_logging macros
to use pr_info() instead of printk(KERN_INFO, ...). checkpatch.pl
now complains about this, so convert libfcoe to preferred
method.
Signed-off-by: Robert Love
Tested-by: Marcus Dennis
---
drivers/scsi/fcoe/fcoe.h |6 +++---
drivers
This patch does a few things.
1) Makes /sys/bus/fcoe/ctlr_{create,destroy} interfaces.
These interfaces take an and will either
create an FCoE Controller or destroy an FCoE
Controller depending on which file is written to.
The new FCoE Controller will start in a DISABLED
state and
This patch adds support for the new fcoe_sysfs
control interface to bnx2fc.ko. It keeps the deprecated
interface in tact and therefore either the legacy
or the new control interfaces can be used. A mixed mode
is not supported. A user must either use the new
interfaces or the old ones, but not both.
This patch adds support for the new fcoe_sysfs
control interface to fcoe.ko. It keeps the deprecated
interface in tact and therefore either the legacy
or the new control interfaces can be used. A mixed mode
is not supported. A user must either use the new
interfaces or the old ones, but not both.
Add missing 'devices/ subdirectory to /sys/bus/fcoe/devices/ctlr_X
and /sys/bus/fcoe/devices/fcf_X references.
Signed-off-by: Robert Love
Tested-by: Ross Brattain
---
Documentation/ABI/testing/sysfs-bus-fcoe |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentatio
Add a macro to print fcoe_sysfs debug statements.
Signed-off-by: Robert Love
Acked-by: Neil Horman
---
drivers/scsi/fcoe/fcoe_sysfs.c |7 +++
drivers/scsi/fcoe/libfcoe.h| 11 ---
2 files changed, 15 insertions(+), 3 deletions(-)
diff --git a/drivers/scsi/fcoe/fcoe_sysfs.c
Instead of creating a structure with an enum and a pointer
to a string, simply allocate an array of strings and use
the enum values for the indicies.
This means that we do not need to iterate through the list
of entries when looking up a string name by its enum key.
This will also help with a lat
From: Vasu Dev
Currently fc_fcp_timeout doesn't check FC_RP_FLAGS_REC_SUPPORTED
flag first, this prevents REC request ever going out at all
to the target having REC support. So this patches fixes the
fc_fcp_timeout by checking FC_RP_FLAGS_REC_SUPPORTED flag first.
The changed order won't cause a
This series is mostly a resend of previously sent patches. The primary change
in this series is the addition of the fcoe_sysfs "control" interfaces.
Additionally there are a few fix/cleanup patches and UAPI conversions. Almost
all of these patches have already been reviewed on linux-scsi.
I wil
Hello,
Hit this WARNING once while fuzzing the kernel with trinity in a qemu
virtual machine as the root user.
Does this make any sense? I have occasionally seen some ATA related
troubles while fuzzing in a VM, but this warning is new to me.
[ 490.717030] WARNING: at
/home/ttrantal/git/linux-2.
On Tue, 19 Feb 2013, Aaron Lu wrote:
> Hi Alan,
>
> On Tue, Feb 05, 2013 at 04:03:15PM +0800, Aaron Lu wrote:
> > From: Lin Ming
> >
> > When a request is added:
> > If device is suspended or is suspending and the request is not a
> > PM request, resume the device.
> >
> > When the las
On Tue, 2013-02-19 at 10:30 -0600, Michael Christie wrote:
> On Feb 19, 2013, at 2:18 AM, Hannes Reinecke wrote:
>
> > diff --git a/drivers/scsi/cxgbi/libcxgbi.c b/drivers/scsi/cxgbi/libcxgbi.c
> > index b44c1cf..95105c0 100644
> > --- a/drivers/scsi/cxgbi/libcxgbi.c
> > +++ b/drivers/scsi/cxgbi/
On Feb 19, 2013, at 2:18 AM, Hannes Reinecke wrote:
> diff --git a/drivers/scsi/cxgbi/libcxgbi.c b/drivers/scsi/cxgbi/libcxgbi.c
> index b44c1cf..95105c0 100644
> --- a/drivers/scsi/cxgbi/libcxgbi.c
> +++ b/drivers/scsi/cxgbi/libcxgbi.c
> @@ -245,7 +245,7 @@ void cxgbi_hbas_remove(struct cxgbi_d
On 02/19/2013 02:15 AM, Bart Van Assche wrote:
On 02/18/13 20:15, Rob Evers wrote:
+/*
+ * bytes 6 - 9: length of the command.
+ */
+scsi_cmd[6] = (unsigned char) (length >> 24) & 0xff;
+scsi_cmd[7] = (unsigned char) (length >> 16) & 0xff;
+scsi_cmd[8] = (unsigned char) (
On Tue, Feb 19, 2013 at 11:35:21AM -0300, Mauro Carvalho Chehab wrote:
> Em Tue, 19 Feb 2013 14:50:56 +0100
> Borislav Petkov escreveu:
>
> > On Tue, Feb 19, 2013 at 03:38:09PM +0200, Felipe Balbi wrote:
> > > because changing the permission will cause the same issue:
> >
> > Actually, I take th
On Tue, Feb 19, 2013 at 11:35:21AM -0300, Mauro Carvalho Chehab wrote:
> That's covers everything but Hannes arguments. I don't think that
> adding just one more device_create_file() on a driver that creates
> dozens (or hundreds) of sys nodes, depending on the number of DIMMS
> on the system would
Em Tue, 19 Feb 2013 14:50:56 +0100
Borislav Petkov escreveu:
> On Tue, Feb 19, 2013 at 03:38:09PM +0200, Felipe Balbi wrote:
> > because changing the permission will cause the same issue:
>
> Actually, I take that back. Mauro's patch will already create the file
> anyway:
>
> if (mci->set
Hi,
On Tue, Feb 19, 2013 at 11:14:40AM -0300, Mauro Carvalho Chehab wrote:
> > Please consider adding a default attribute which return '-EINVAL' or
> > somesuch when the function pointers are not set.
> > But _not_ adding it via device_create_file(). That's evil.
>
> This thread started with Fel
Em Tue, 19 Feb 2013 14:58:07 +0100
Hannes Reinecke escreveu:
> On 02/19/2013 02:50 PM, Borislav Petkov wrote:
> > On Tue, Feb 19, 2013 at 03:38:09PM +0200, Felipe Balbi wrote:
> >> because changing the permission will cause the same issue:
> >
> > Actually, I take that back. Mauro's patch will al
On Tue, Feb 19, 2013 at 02:58:07PM +0100, Hannes Reinecke wrote:
> Please consider adding a default attribute which return '-EINVAL' or
> somesuch when the function pointers are not set. But _not_ adding it
> via device_create_file(). That's evil.
This is what we do now. We probably could add the
On 02/19/2013 02:50 PM, Borislav Petkov wrote:
On Tue, Feb 19, 2013 at 03:38:09PM +0200, Felipe Balbi wrote:
because changing the permission will cause the same issue:
Actually, I take that back. Mauro's patch will already create the file
anyway:
if (mci->set_sdram_scrub_rate || mci->
On Tue, Feb 19, 2013 at 10:50:48AM -0300, Mauro Carvalho Chehab wrote:
> It is actually worse, as if someone is using a C code to open the device
> with
> fp = open ("/sys/devices/system/edac/mc/mc0/sdram_scrub_rate", O_RDWR);
>
> It will now start to fail if the device doesn't have both per
Em Tue, 19 Feb 2013 15:38:09 +0200
Felipe Balbi escreveu:
> Hi,
>
> On Tue, Feb 19, 2013 at 02:28:54PM +0100, Borislav Petkov wrote:
> > On Tue, Feb 19, 2013 at 03:15:00PM +0200, Felipe Balbi wrote:
> > > what's the problem with that ?
> >
> > Not a problem - simply annoying.
> >
> > $ ./test.
On Tue, Feb 19, 2013 at 03:38:09PM +0200, Felipe Balbi wrote:
> because changing the permission will cause the same issue:
Actually, I take that back. Mauro's patch will already create the file
anyway:
if (mci->set_sdram_scrub_rate || mci->get_sdram_scrub_rate)
Adjusting the permissions
Em Tue, 19 Feb 2013 14:06:26 +0100
Borislav Petkov escreveu:
> > No, on both cases, open() will return an error (-ENOENT against -EPERM).
>
> What if it is a shell script doing:
>
> cat /sys/devices/system/edac/mc/mc0/sdram_scrub_rate
>
> or similar?
Well, cat will return "1" if an error is f
Hi,
On Tue, Feb 19, 2013 at 02:28:54PM +0100, Borislav Petkov wrote:
> On Tue, Feb 19, 2013 at 03:15:00PM +0200, Felipe Balbi wrote:
> > what's the problem with that ?
>
> Not a problem - simply annoying.
>
> $ ./test.sh
> cat: /path/to/file/that/doesnt/exist.txt: No such file or directory
> Set
On Tue, Feb 19, 2013 at 03:15:00PM +0200, Felipe Balbi wrote:
> what's the problem with that ?
Not a problem - simply annoying.
$ ./test.sh
cat: /path/to/file/that/doesnt/exist.txt: No such file or directory
Setting scrubrate to:
I'm sure someone would ask themselves why all of a sudden the file
On Tue, Feb 19, 2013 at 02:06:26PM +0100, Borislav Petkov wrote:
> On Tue, Feb 19, 2013 at 09:46:40AM -0300, Mauro Carvalho Chehab wrote:
> > Ah, now I see what you're meaning. That would require to dynamically
> > create a per-mci DEVICE_ATTR().
>
> Dude, look at the code, we do that already. And
On Tue, Feb 19, 2013 at 09:46:40AM -0300, Mauro Carvalho Chehab wrote:
> Ah, now I see what you're meaning. That would require to dynamically
> create a per-mci DEVICE_ATTR().
Dude, look at the code, we do that already. And you're using it with
dev_attr_sdram_scrub_rate.
Simply change the permiss
Em Tue, 19 Feb 2013 13:35:02 +0100
Borislav Petkov escreveu:
> On Tue, Feb 19, 2013 at 09:16:10AM -0300, Mauro Carvalho Chehab wrote:
> > I'm not sure if is there a way to pass fs permissions to something similar
> > to device_create_file().
>
> struct device_attribute.attr.mode? I.e., second ar
On Tue, Feb 19, 2013 at 09:16:10AM -0300, Mauro Carvalho Chehab wrote:
> I'm not sure if is there a way to pass fs permissions to something similar
> to device_create_file().
struct device_attribute.attr.mode? I.e., second arg.
> On both cases, an error will happen at open:
> - if file does
Em Tue, 19 Feb 2013 12:43:46 +0100
Borislav Petkov escreveu:
> On Tue, Feb 19, 2013 at 08:11:49AM -0300, Mauro Carvalho Chehab wrote:
> > > > I remember I saw some discussions about it in the past at bluesmoke ML,
> > > > saying that -ENODEV is the expected behavior when this is not supported.
>
On Tue, Feb 19, 2013 at 08:11:49AM -0300, Mauro Carvalho Chehab wrote:
> > > I remember I saw some discussions about it in the past at bluesmoke ML,
> > > saying that -ENODEV is the expected behavior when this is not supported.
> > >
> > > Changing from -ENODEV to "N/A" will break anything that wo
Em Tue, 19 Feb 2013 12:11:21 +0200
Felipe Balbi escreveu:
> Hi,
>
> On Tue, Feb 19, 2013 at 07:03:10AM -0300, Mauro Carvalho Chehab wrote:
> > > But my gut feeling says to stay concervative and not touch this code -
> > > we don't know what uses it and how much we would break by "fixing" it.
> >
Hi,
On Tue, Feb 19, 2013 at 07:03:10AM -0300, Mauro Carvalho Chehab wrote:
> > But my gut feeling says to stay concervative and not touch this code -
> > we don't know what uses it and how much we would break by "fixing" it.
> > The current situation is not that big of a deal IMVHO and I'd be will
Em Mon, 18 Feb 2013 23:44:05 +0100
Borislav Petkov escreveu:
> On Mon, Feb 18, 2013 at 02:26:18PM -0800, Greg KH wrote:
> > I don't know, it depends on if userspace can handle this properly or
> > not. What tools rely on this sysfs file? WHat happens when they get a
> > non-number in the file?
T
On 4 February 2013 13:45, Sachin Kamat wrote:
> version.h header file inclusion is not necessary.
>
> Signed-off-by: Sachin Kamat
> ---
> drivers/scsi/fnic/fnic_trace.c |1 -
> 1 files changed, 0 insertions(+), 1 deletions(-)
ping..
>
> diff --git a/drivers/scsi/fnic/fnic_trace.c b/drivers
Now that we're using 64-bit LUNs internally we need to increase
the size of max_luns to 64 bits, too.
Signed-off-by: Hannes Reinecke
---
drivers/message/i2o/i2o_scsi.c |6 +++---
drivers/scsi/cxgbi/libcxgbi.c|2 +-
drivers/scsi/cxgbi/libcxgbi.h|2 +-
drivers/scs
This patchset updates the SCSI midlayer to use 64-bit LUNs internally.
It eliminates the need to limit the number of LUNs artificially to
avoid aliasing issues; the SCSI midlayer can now accept any LUN presented
to it.
The LLDD specific settings for 'max_lun' have been left untouched;
it should be
Obsolete now; either use 'max_lun' if the host supports only a
limited number of LUNs or BLIST_NOLUN if the target has problems
addressing more than one LUN.
Signed-off-by: Hannes Reinecke
---
drivers/scsi/Kconfig | 14 --
drivers/scsi/dc395x.c|9 +
drivers/scsi
scsilun_to_int() has an error which prevents it from generating
correct LUN numbers for 64bit values.
Also we should remove the misleading comment about portions of
the LUN being ignored; the initiator should treat the LUN as
an opaque value.
Signed-off-by: Hannes Reinecke
---
drivers/scsi/scsi_
69 matches
Mail list logo
