It seemed odd to say "since 4.17" in a 4.4 kernel. Consider
rewording the reference to indicate where in the stable series
it was introduced as well as where it originated.
Signed-off-by: Mark Rustad
---
Does this brief elaboration add useful information? It seems to
me that som
.
Signed-off-by: Mark Rustad <mark.d.rus...@intel.com>
Reviewed-by: Alexander Duyck <alexander.h.du...@intel.com>
---
Changes in V4:
- V3 was a mis-send, this has what was intended
- Move most code to new helpers in pci/iov.c, pci_sriov_configure_generic
and pci_sriov_disable_gener
.
Signed-off-by: Mark Rustad
Reviewed-by: Alexander Duyck
---
Changes in V4:
- V3 was a mis-send, this has what was intended
- Move most code to new helpers in pci/iov.c, pci_sriov_configure_generic
and pci_sriov_disable_generic
- Correct mislabeling of vendor and device IDs
- Other minor
.
Signed-off-by: Mark Rustad <mark.d.rus...@intel.com>
Reviewed-by: Alexander Duyck <alexander.h.du...@intel.com>
---
Changes in V3:
- Move most code to a new helper in pci/iov.c, pci_sriov_configure
Changes in V2:
- Simplified logic from previous version, removed added driver variable
.
Signed-off-by: Mark Rustad
Reviewed-by: Alexander Duyck
---
Changes in V3:
- Move most code to a new helper in pci/iov.c, pci_sriov_configure
Changes in V2:
- Simplified logic from previous version, removed added driver variable
- Disable SR-IOV on driver removal excapt when VFs are assigned
.
Signed-off-by: Mark Rustad <mark.d.rus...@intel.com>
Reviewed-by: Alexander Duyck <alexander.h.du...@intel.com>
---
Changes in V2:
- Simplified logic from previous version, removed added driver variable
- Disable SR-IOV on driver removal excapt when VFs are assigned
- Sent as RFC t
.
Signed-off-by: Mark Rustad
Reviewed-by: Alexander Duyck
---
Changes in V2:
- Simplified logic from previous version, removed added driver variable
- Disable SR-IOV on driver removal excapt when VFs are assigned
- Sent as RFC to virtio-dev, linux-pci, netdev, lkml and others
---
drivers/virtio
On 9/21/15 9:14 PM, Jarod Wilson wrote:
> Just switching to adapter->io_addr everywhere seems to not work as
> noted above. :\ Note that I'm also chasing this from the other end
> with the author of the pci patches that seem to have triggered this,
> so the real bug might be over in pci-land,
On 9/21/15 9:14 PM, Jarod Wilson wrote:
> Just switching to adapter->io_addr everywhere seems to not work as
> noted above. :\ Note that I'm also chasing this from the other end
> with the author of the pci patches that seem to have triggered this,
> so the real bug might be over in pci-land,
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 2/12/15 2:20 AM, Rasmus Villemoes wrote:
> Rather weak arguments, but I have three of them :-)
Yes, weak. All three.
> (1) If I'm reading some code and spot a non-constant format
> argument, I sometimes track back to see how e.g. fmt_value is
>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 2/12/15 2:20 AM, Rasmus Villemoes wrote:
Rather weak arguments, but I have three of them :-)
Yes, weak. All three.
(1) If I'm reading some code and spot a non-constant format
argument, I sometimes track back to see how e.g. fmt_value is
Commit-ID: 9ea029f12aab2fa3f2913e67d17cc24801ba694e
Gitweb: http://git.kernel.org/tip/9ea029f12aab2fa3f2913e67d17cc24801ba694e
Author: Mark Rustad
AuthorDate: Fri, 5 Sep 2014 19:55:49 -0700
Committer: Ingo Molnar
CommitDate: Sat, 6 Sep 2014 10:20:53 +0200
x86/tty/serial/8250: Resolve
Commit-ID: 9ea029f12aab2fa3f2913e67d17cc24801ba694e
Gitweb: http://git.kernel.org/tip/9ea029f12aab2fa3f2913e67d17cc24801ba694e
Author: Mark Rustad mark.d.rus...@intel.com
AuthorDate: Fri, 5 Sep 2014 19:55:49 -0700
Committer: Ingo Molnar mi...@kernel.org
CommitDate: Sat, 6 Sep 2014 10:20
Commit-ID: 315427691c7a064718b5ad7d378d7f1c1898a626
Gitweb: http://git.kernel.org/tip/315427691c7a064718b5ad7d378d7f1c1898a626
Author: Mark Rustad
AuthorDate: Wed, 3 Sep 2014 03:17:24 -0700
Committer: Ingo Molnar
CommitDate: Thu, 4 Sep 2014 07:17:24 +0200
locking/semaphore: Resolve
Commit-ID: 315427691c7a064718b5ad7d378d7f1c1898a626
Gitweb: http://git.kernel.org/tip/315427691c7a064718b5ad7d378d7f1c1898a626
Author: Mark Rustad mark.d.rus...@intel.com
AuthorDate: Wed, 3 Sep 2014 03:17:24 -0700
Committer: Ingo Molnar mi...@kernel.org
CommitDate: Thu, 4 Sep 2014 07:17
needs some way to drop them in SCSI ML. BSG is almost perfect
for this, but doesn't do iovec, leading to lots of memcpy.
Precisely.
--
Mark Rustad, [EMAIL PROTECTED]
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTE
way to drop them in SCSI ML. BSG is almost perfect
for this, but doesn't do iovec, leading to lots of memcpy.
Precisely.
--
Mark Rustad, [EMAIL PROTECTED]
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info
LT_REASON_IDX ARRAY_SIZE(fault_reason_strings)
+#define MAX_FAULT_REASON_IDX ARRAY_SIZE(fault_reason_strings) - 1
This define now should really have ()'s around its value now that it
is an expression to avoid potential problems at its reference sites.
--
Mark Rustad, [EMAIL PROTECTED]
-
To
(fault_reason_strings)
+#define MAX_FAULT_REASON_IDX ARRAY_SIZE(fault_reason_strings) - 1
This define now should really have ()'s around its value now that it
is an expression to avoid potential problems at its reference sites.
snip
--
Mark Rustad, [EMAIL PROTECTED]
-
To unsubscribe from this list
ocessors, cpu_possible_map);
num_processors++;
--
Mark Rustad, [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
);
num_processors++;
--
Mark Rustad, [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
picid);
+ physids_or(phys_cpu_present_map, phys_cpu_present_map,
phys_cpu);
+
cpu_set(num_processors, cpu_possible_map);
num_processors++;
--
Mark Rustad, [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of
uess there is a bug somewhere.
I will be digging further, but I was interested in posing the
question in any case.
--
Mark Rustad, [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info
the
question in any case.
--
Mark Rustad, [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
(phys_cpu_present_map, phys_cpu_present_map,
phys_cpu);
+
cpu_set(num_processors, cpu_possible_map);
num_processors++;
--
Mark Rustad, [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo
On Mar 27, 2007, at 1:38 PM, Jeff Garzik wrote:
Mark Rustad wrote:
reorder any queued operations. Of course if you really care about
your data, you don't really want to turn write cache on.
That's a gross exaggeration. FLUSH CACHE and FUA both ensure data
integrity as well.
Turning
inly a big problem.
--
Mark Rustad, [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
problem.
--
Mark Rustad, [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
On Mar 27, 2007, at 1:38 PM, Jeff Garzik wrote:
Mark Rustad wrote:
reorder any queued operations. Of course if you really care about
your data, you don't really want to turn write cache on.
That's a gross exaggeration. FLUSH CACHE and FUA both ensure data
integrity as well.
Turning
On Feb 6, 2007, at 9:55 AM, Bill Davidsen wrote:
Mark Rustad wrote:
On Feb 5, 2007, at 5:32 PM, Linus Torvalds wrote:
And I told you that you could just improve the tools that track
those
dependencies ANYWAY!
They aren't that bad even now. Using menuconfig (I'm a fossil that
just uses
On Feb 6, 2007, at 9:55 AM, Bill Davidsen wrote:
Mark Rustad wrote:
On Feb 5, 2007, at 5:32 PM, Linus Torvalds wrote:
snip
And I told you that you could just improve the tools that track
those
dependencies ANYWAY!
They aren't that bad even now. Using menuconfig (I'm a fossil that
just
particular entry. That is good enough for me now. Maybe I
am just willing to ask for help, but the help already seems to be there.
--
Mark Rustad, [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTE
any particular entry. That is good enough for me now. Maybe I
am just willing to ask for help, but the help already seems to be there.
snip
--
Mark Rustad, [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED
On Jan 24, 2007, at 5:45 PM, Chris Rankin wrote:
--- Mark Rustad <[EMAIL PROTECTED]> wrote:
Exactly. Halting use of a version of the kernel based on a single
incident provides no insight to the source of the problem. It could
be anything...
There is a world of difference between a
incident provides no insight to the source of the problem. It could
be anything...
--
Mark Rustad, [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org
are data corruption accidents waiting to
happen.
--
Mark Rustad, [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FA
are data corruption accidents waiting to
happen.
--
Mark Rustad, [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http
incident provides no insight to the source of the problem. It could
be anything...
--
Mark Rustad, [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo
On Jan 24, 2007, at 5:45 PM, Chris Rankin wrote:
--- Mark Rustad [EMAIL PROTECTED] wrote:
Exactly. Halting use of a version of the kernel based on a single
incident provides no insight to the source of the problem. It could
be anything...
There is a world of difference between a polite request
ing the
battle, but I still don't have to like it.
--
Mark Rustad, [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the
the
battle, but I still don't have to like it.
--
Mark Rustad, [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http
that that approach does not work on.
--
Mark Rustad, [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FA
that that approach does not work on.
--
Mark Rustad, [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org
ecs = 0;
- bio->bi_flags &= (BIO_POOL_MASK - 1);
+ bio_phys_segments(q, bio);
+ bio_hw_segments(q, bio);
}
/**
@@ -250,7 +235,7 @@
*/
struct bio *bio_clone(struct bio *bio, int gfp_mask)
{
- struct bio *b = bio_alloc(gfp_mask, 0);
+ struct bio *b = bio_alloc(gfp_mask,
);
}
/**
@@ -250,7 +235,7 @@
*/
struct bio *bio_clone(struct bio *bio, int gfp_mask)
{
- struct bio *b = bio_alloc(gfp_mask, 0);
+ struct bio *b = bio_alloc(gfp_mask, bio-bi_max_vecs);
if (b)
__bio_clone(b, bio);
--
Mark Rustad, [EMAIL PROTECTED]
-
To unsubscribe
45 matches
Mail list logo
