On Wed, 2018-10-17 at 11:30 -0400, Doug Ledford wrote:
> On Wed, 2018-10-17 at 07:43 -0700, Bart Van Assche wrote:
> > On 10/17/18 12:20 AM, Hannes Reinecke wrote:
> > > The WARN_ON() is pointless as the rport is placed in
> > > SDEV_TRANSPORT_OFFLINE
> > > at
gt; - WARN_ON_ONCE(sdev->request_queue->request_fn_active);
> > -
> > for (i = 0; i < target->ch_count; i++) {
> > ch = &target->ch[i];
>
> Although I had explained before why I think that warning is not
> pointless, I a
Bhumika Goyal
Acked-by: Doug Ledford
--
Doug Ledford
GPG KeyID: B826A3330E572FDD
Key fingerprint = AE6B 1BDA 122B 23B4 265B 1274 B826 A333 0E57 2FDD
mvsas/mv_init.c | 6 +-
> drivers/scsi/mvsas/mv_sas.c | 6 +-
> drivers/scsi/pmcraid.c| 10 +--
> drivers/scsi/pmcraid.h| 2 +-
> include/linux/mlx5/driver.h | 2 +-
> include/linux/pci.h | 9 ---
> 35 files changed, 269 insertions(+), 278 deletions(-)
>
--
Doug Ledford
GPG KeyID: B826A3330E572FDD
Key fingerprint = AE6B 1BDA 122B 23B4 265B 1274 B826 A333 0E57 2FDD
nged, 6 insertions(+), 6 deletions(-)
> >
>
> Thanks,
> Reviewed-by: Leon Romanovsky
Changes look fine to me, and it has been tested on this specific
hardware and confirmed RDMA communications still work.
Acked-by: Doug Ledford
Tested-by: Doug Ledford
--
Doug Ledford
GPG K
ter Senna Tschudin
>
Changes look ok, and I've tested them here as well.
Acked-by: Doug Ledford
Tested-by: Doug Ledford
--
Doug Ledford
GPG KeyID: B826A3330E572FDD
Key fingerprint = AE6B 1BDA 122B 23B4 265B 1274 B826 A333 0E57 2FDD
(-)
> >
>
> Thanks,
> Acked-by: Leon Romanovsky
Changes look fine to me, and in addition I've compiled and tested them
on mlx5 hardware and verified that RDMA communications still work.
Acked-by: Doug Ledford
Tested-by: Doug Ledford
--
Doug Ledford
GPG KeyID: B826A3330E572FDD
Key fingerprint = AE6B 1BDA 122B 23B4 265B 1274 B826 A333 0E57 2FDD
n_queues+0x102/0x290
>>>> [ 394.476369] [] hrtimer_interrupt+0xa8/0x1a0
>>>> [ 394.476372] [] local_apic_timer_interrupt+0x35/0x60
>>>> [ 394.476374] [] smp_apic_timer_interrupt+0x3d/0x50
>>>> [ 394.476376] [] apic_timer_interrupt+0x87/0x90
>&g
drivers/infiniband/ulp/ipoib/ipoib_cm.c| 2 +-
> drivers/infiniband/ulp/ipoib/ipoib_ib.c| 2 +-
For InfiniBand bits,
Acked-by: Doug Ledford
--
Doug Ledford
GPG KeyID: 0E572FDD
signature.asc
Description: OpenPGP digital signature
ul here:
please include the v1/v2 in your --subject-prefix you pass to git.
Patchworks does not preserve cover letters nor propagate flags from
cover letter to patch series :-/
--
Doug Ledford
GPG KeyID: 0E572FDD
signature.asc
Description: OpenPGP digital signature
the fact that I *like* having the attr struct
elements in an organized sub-struct, it's fine and it definitely
improves on all of those query calls).
--
Doug Ledford
GPG KeyID: 0E572FDD
signature.asc
Description: OpenPGP digital signature
ndeed, thanks for all the catches Bart. This patchset, with Bart's
fixups, looks good to me.
--
Doug Ledford
GPG KeyID: 0E572FDD
signature.asc
Description: OpenPGP digital signature
r the
uobj->id is set regardless of the lock.
Acked-by: Doug Ledford
> ---
> drivers/infiniband/core/uverbs_cmd.c | 12 ++--
> 1 file changed, 2 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/infiniband/core/uverbs_cmd.c
> b/drivers/infiniband/core/uverb
r-version-and-release-date.patch
Got 'em, thanks!
--
Doug Ledford
GPG KeyID: 0E572FDD
signature.asc
Description: OpenPGP digital signature
On Tue, 2015-05-05 at 17:27 +0200, Bart Van Assche wrote:
> On 05/05/15 17:10, Doug Ledford wrote:
> > On Tue, 2015-05-05 at 16:26 +0200, Bart Van Assche wrote:
> >> On 05/05/15 16:10, Doug Ledford wrote:
> >>> However, while looking through the driver to research t
On 11/08/2013 11:04 AM, Paul Gortmaker wrote:
Paul Gortmaker (1):
scsi: delete decade+ obsolete aic7xxx_old driver
Documentation/scsi/00-INDEX | 2 -
Documentation/scsi/aic7xxx_old.txt | 511 --
MAINTAINERS | 1 -
drivers/scsi/K
t Linux 7.0 days).
--
Doug Ledford
GPG KeyID: 0E572FDD
http://people.redhat.com/dledford
--
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
Yes, this driver is well past ready to be removed.
Acked-by: Doug Ledford
Sent from my ASUS Pad
Paul Gortmaker wrote:
>After getting warnings in an allyesconfig build[1] from this
>driver, I decided to remind myself just how old it was, and
>whether it warranted fixing. In the Kco
s and variables via case.
> So I don't agree with (or understand) your objections. But I can certainly
> understand reluctance to merge a large-but-minor, do-nothing-much patch into
> a large and not-very-maintained driver.
Hehehe...and here I was thinking of factoring that t
On Fri, 2005-02-25 at 09:02 -0800, Patrick Mansfield wrote:
> On Fri, Feb 25, 2005 at 06:57:39AM -0500, Doug Ledford wrote:
> > On Fri, 2005-02-25 at 03:38 -0500, Jeff Garzik wrote:
> > > Arjan van de Ven wrote:
> > > > On Thu, 2005-02-24 at 23:21 -0500, Doug Ledford
On Fri, 2005-02-25 at 03:38 -0500, Jeff Garzik wrote:
> Arjan van de Ven wrote:
> > On Thu, 2005-02-24 at 23:21 -0500, Doug Ledford wrote:
> >
> >>Don't use cmd->request->nr_hw_segments as it may not be initialized
> >>(SG_IO in particular bypasses anyt
before the mapping has taken place are
bogus.
--
Doug Ledford <[EMAIL PROTECTED]>
http://people.redhat.com/dledford
= qla_iocb.c 1.15 vs edited =
--- 1.15/drivers/scsi/qla2xxx/qla_iocb.c 2004-12-09 01:12:03 -05:00
+++ edited/qla_iocb.c 2005-02-24 16:25:55 -05:00
@@ -216,
-hiren
>
> -Original Message-
> From: Martin Peschke3 [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, July 19, 2001 12:23 PM
> To: Doug Ledford
> Cc: MEHTA,HIREN (A-SanJose,ex1); '[EMAIL PROTECTED]'
> Subject: Re: question on io_request_lock
>
> > Yes, t
io_request_lock held when using the old error handling methods. I don't know
which entry points are called with the lock held under the new error handling
code, but I would suspect the answer is "all of them".
--
Doug Ledford <[EMAIL PROTECTED]> http://people.redhat.com
ren't automatically rewind when the
tape device is closed. So, the problem isn't with mt, it's doing exactly what
it is suppossed to do. The problem is with the device you are accessing the
tape through.
--
Doug Ledford <[EMAIL PROTECTED]> http://people.redhat.com/dledfor
Max TenEyck Woodbury wrote:
>
> Doug Ledford wrote:
> >
> > Max TenEyck Woodbury wrote:
> >>
> >> Umm. Reboot? What do you think this is? Windoze?
> >
> > It's the *only* way to guarantee that the drive is never touched by more
> > than
failed writes on the primary path, I think this is of
dubious value. Right now, as I see it, multipath and failover simply don't
mix well. There is more work needed to make it work well.
> If this not any clearer than my last mail I will just wait to see the code
> :-).
>
&
capability could be plugged into this service so
> that users could reduce recoding depending on which fencing support they
> selected.
I wouldn't know about that.
--
Doug Ledford <[EMAIL PROTECTED]> http://people.redhat.com/dledford
Please check my web site for aic7xxx u
Max TenEyck Woodbury wrote:
>
> Doug Ledford wrote:
> >
> > ...
> >
> > If told to hold a reservation, then resend your reservation request once every
> > 2 seconds (this actually has very minimal CPU/BUS usage and isn't as big a
> > deal as reque
"Eric Z. Ayers" wrote:
>
> Doug Ledford writes:
> (James Bottomley commented about the need for SCSI reservation kernel patches)
> >
> > I agree. It's something that needs fixed in general, your software needs it
> > as well, and I've written
tware geared towards getting/holding reservations that also requires the
same kernel patches (plus one more to be fully functional, an ioctl to allow a
SCSI reservation to do a forced reboot of a machine). I'll be releasing that
package in the short term (once I get back from my vacation an
ut if LUN 0 doesn't exist on that target ID, then nothing on
that target ID will get scanned).
--
Doug Ledford <[EMAIL PROTECTED]> http://people.redhat.com/dledford
Please check my web site for aic7xxx updates/answers before
e-mailing me about problems
-
ommand to be sent, there are cases when we can get a QUEUE_FULL with 0
commands active on the device, resulting in a hung drive if you don't
implement a timeout for the paused queue.
--
Doug Ledford <[EMAIL PROTECTED]> http://people.redhat.com/dledford
Please check my web
so it is in the
ac series kernels) or you can use Justin Gibbs' new aic7xxx driver (which
never had this issue in the first place) which happens to be the new default
aic7xxx driver in the 2.4.3 kernel.
--
Doug Ledford <[EMAIL PROTECTED]> http://people.redhat.com/dledford
t think Adaptec makes low profiles
> SCSI cards. I've a book-pc that has only one low profile slot.
As a matter of fact, the aic7xxx driver (both the old and the new one) support
some Ultra160 low profile SCSI controllers that Adaptec makes. I don't know
if they are available in no
the problem you are referring to only
happens when a driver module is loaded prior to sd_mod.o, and that reversing
the order will solve the problem (but, I haven't looked so I could easily be
wrong ;-)
--
Doug Ledford <[EMAIL PROTECTED]> http://people.redhat.com/dledford
Plea
ilities and
starts to confirm my position.
> Maybe someone can explain the meaning of the illegal
> requests at the end. Nevertheless, I can use the drive fine.
As to the illegal request messages, I'm not sure what those are about ;-)
--
Doug Ledford <[EMAIL PROTECTED]> http:/
d simply wait for the 2.5 development and debugging cycle?)
It would still be helpful because this problem has to be fixed before 2.5.
The only question is whether to fix it with a simple patch such as I just
submitted, or a more complex patch that uses REPORT LUNs. Part of that answer
is h
that when I worked
> Why wait for a check condition? There's an INQUIRY field bit that
> indicates whether REPORT LUNs is supported.
And I'm all for using it in the 2.5 kernel SCSI stack ;-)
--
Doug Ledford <[EMAIL PROTECTED]> http://people.redhat.com/dledford
Please
Doug Ledford wrote:
> Patches welcomed. The one I sent already works on a fiber channel setup (the
> qla2x00 in question is fc and so is the Clariion array it's connected to, no
> detrimental side effects from scanning the box) and so I'm not inclined to add
> a REPORT LU
Pete Zaitcev wrote:
>
> > Date: Wed, 14 Mar 2001 21:28:14 -0500
> > From: Doug Ledford <[EMAIL PROTECTED]>
>
> > A bug report I was charged with fixing (qla2x00 driver doesn't see all luns or
> > sees multiple identical luns in different scenarios
ist. If that's not the case, and they list their
luns as all being connected, then this patch needs to go into the mainstream
kernel.
--
Doug Ledford <[EMAIL PROTECTED]> http://people.redhat.com/dledford
Please check my web site for aic7xxx updates/answers before
42 matches
Mail list logo
