On Tue, 2013-10-08 at 20:55 -0700, H. Peter Anvin wrote:
> Why not add a minimum number to pci_enable_msix(), i.e.:
>
> pci_enable_msix(pdev, msix_entries, nvec, minvec)
>
> ... which means "nvec" is the number of interrupts *requested*, and
> "minvec" is the minimum acceptable number (otherwise
On 10/02/2013 03:29 AM, Alexander Gordeev wrote:
>
> As result, device drivers will cease to use the overcomplicated
> repeated fallbacks technique and resort to a straightforward
> pattern - determine the number of MSI/MSI-X interrupts required
> before calling pci_enable_msi_block() and pci_enab
On 13-10-02 06:29 AM, Alexander Gordeev wrote:
..
> This update converts pci_enable_msix() and pci_enable_msi_block()
> interfaces to canonical kernel functions and makes them return a
> error code in case of failure or 0 in case of success.
Rather than silently break dozens of drivers in mysterio
On Tue, Oct 08, 2013 at 09:33:02AM +0200, Alexander Gordeev wrote:
> On Tue, Oct 08, 2013 at 03:33:30PM +1100, Michael Ellerman wrote:
> > On Wed, Oct 02, 2013 at 12:29:04PM +0200, Alexander Gordeev wrote:
> > > This technique proved to be confusing and error-prone. Vast share
> > > of device drive
--
Vážení Web - Mail Majitel účtu:
To přišlo na naše upozornění , že vaše e-mailová neprošel ověření /
aktualizace proces, který jsme v současné době pracuje na . V současné
době modernizace naší databázi a e - mailový účet centrum , čímž Smazání
všech starých webový e-mail e-mailový účet v
Hello Nab,
> target: Make target_do_xcopy failures return INVALID_PARAMETER_LIST
> target: Allow non zero ListID in EXTENDED_COPY parameter list
> target: Reject EXTENDED_COPY when emulate_3pc is disabled
I pull them right now, rebuild and test them tomorrow in my currently
ongoing class. I
From: Nicholas Bellinger
This patch changes target_do_xcopy() to properly return
TCM_INVALID_PARAMETER_LIST instead of TCM_INVALID_CDB_FIELD
for failures related to the EXTENDED_COPY parameter list parsing.
Also, move struct xcopy_op allocation ahead of kmapping to
handle the special TCM_OUT_OF_
From: Nicholas Bellinger
Hi folks,
Here are a few extra EXTENDED_COPY bugfixes that have come up recently.
This includes:
- Reporting the correct ASC/ASCQ during target_do_xcopy() failures
- Allow non zero list IDs to be processed as SNLID=1
- Reject copy offload requests on source + des
From: Nicholas Bellinger
This patch rejects EXTENDED_COPY when the emulate_3pc attribute has
been explicitly disabled for the receiving device.
It also adds a similar check in target_xcopy_locate_se_dev_e4() to
ignore these devices when doing a search based upon the identifier
WWN provided by EX
From: Nicholas Bellinger
This patch changes target_do_xcopy() to allow processing of non-zero
ListIDs in EXTENDED_COPY parameter list data, instead of returning
CHECK_CONDITION status.
As the copy offload implementation reports SNLID=1 (Supports No ListID)
in OPERATING PARAMETERS, any ListID val
Hi,
We have several reports (against a distro kernel) of panics in
blk_requeue_request that look like this:
kernel BUG at block/blk-core.c:1045!
invalid opcode: [#1] SMP
last sysfs file:
/sys/devices/pci:40/:40:03.0/:55:00.0/infiniband_mad/umad0/port
CPU 0
Modules linked in: ipm
http://gentlemensoutfitters.net.au/r4.php
--
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
Since several people are working on xcopy; I have collected
various fixes, improved documentation and debug to sg_xcopy
(in sg3_utils) and ddpt into new betas dated today. They
can be found in the News section at the top of:
http://sg.danny.cz/sg
There are a lot of other fixes to sg3_utils (see
On 13-10-08 02:44 AM, vaughan wrote:
Hi Madper,
CC to Douglas to get comments.
I use the rw_semaphore o_sem to protect excl open, introduced in commit
15b06f9a02406e5460001db6d5af5c738cd3d4e7 since v3.12-rc1.
Is it forbidden to do like that in kernel?...
It appears you can not (allow sg_open()
On Mon, Oct 07, 2013 at 02:01:11PM -0400, Tejun Heo wrote:
> > What about introducing pci_lock_msi() and pci_unlock_msi() and let device
> > drivers care about their ranges and specifics in race-safe manner?
> > I do not call to introduce it right now (since it appears pSeries has not
> > been hitt
Hi!
I'm wondering where to find information on the specific error codes
mpt2sas spits out. I'm experiencing fault_state(0x5851) which is
rendering my system unusable whenever I try to write to any of the
WD20EARX drives. I've appended a dmesg snippet of the problem to this
message.
I apologize if
On Mon, Oct 07, 2013 at 02:21:17PM -0400, Tejun Heo wrote:
> Whee that's a lot more than I expected. I was just scanning
> multiple msi users. Maybe we can stage the work in more manageable
> steps so that you don't have to go through massive conversion only to
> do it all over again afterwar
On Mon, Oct 07, 2013 at 02:10:43PM -0400, Tejun Heo wrote:
> On Wed, Oct 02, 2013 at 12:48:21PM +0200, Alexander Gordeev wrote:
> > Make pci_msix_table_size() to return a error code if the device
> > does not support MSI-X. This update is needed to facilitate a
> > forthcoming re-design MSI/MSI-X i
On Mon, Oct 07, 2013 at 02:17:49PM -0400, Tejun Heo wrote:
> Hello,
>
> On Wed, Oct 02, 2013 at 12:48:23PM +0200, Alexander Gordeev wrote:
> > +static int foo_driver_enable_msi(struct foo_adapter *adapter, int nvec)
> > +{
> > + rc = pci_get_msi_cap(adapter->pdev);
> > + if (rc < 0)
> > +
On Tue, Oct 08, 2013 at 03:33:30PM +1100, Michael Ellerman wrote:
> On Wed, Oct 02, 2013 at 12:29:04PM +0200, Alexander Gordeev wrote:
> > This technique proved to be confusing and error-prone. Vast share
> > of device drivers simply fail to follow the described guidelines.
>
> To clarify "Vast sh
20 matches
Mail list logo
