On Fri, Dec 14, 2012 at 7:36 AM, Linus Torvalds
wrote:
>> Any problem with this tree, or did it just slip through the cracks?
>
> It was merged seven hours before your email. Forgot to check?
No, just dumb-assery in how I fetched in one place and checked in
another. Sorry.
--
To unsubscribe
On Mon, Dec 10, 2012 at 9:59 PM, Roland Dreier wrote:
> Hi Linus,
>
> Please pull from
>
> git://git.kernel.org/pub/scm/linux/kernel/git/roland/infiniband.git
> tags/rdma-for-linus
Hi Linus,
Any problem with this tree, or did it just slip through the cracks?
On Mon, Dec 10, 2012 at 9:59 PM, Roland Dreier rol...@kernel.org wrote:
Hi Linus,
Please pull from
git://git.kernel.org/pub/scm/linux/kernel/git/roland/infiniband.git
tags/rdma-for-linus
Hi Linus,
Any problem with this tree, or did it just slip through the cracks?
Thanks,
Roland
On Fri, Dec 14, 2012 at 7:36 AM, Linus Torvalds
torva...@linux-foundation.org wrote:
Any problem with this tree, or did it just slip through the cracks?
It was merged seven hours before your email. Forgot to check?
No, just dumb-assery in how I fetched in one place and checked in
another.
:
IB/mlx4: Fix spinlock order to avoid lockdep warnings
mlx4_core: Fix potential deadlock in mlx4_eq_int()
Julia Lawall (3):
RDMA/nes: Use WARN()
RDMA/cxgb4: use WARN
RDMA/cxgb3: use WARN
Or Gerlitz (1):
mlx4: 64-byte CQE/EQE support
Roland Dreier (4):
/mlx4: Fix spinlock order to avoid lockdep warnings
mlx4_core: Fix potential deadlock in mlx4_eq_int()
Julia Lawall (3):
RDMA/nes: Use WARN()
RDMA/cxgb4: use WARN
RDMA/cxgb3: use WARN
Or Gerlitz (1):
mlx4: 64-byte CQE/EQE support
Roland Dreier (4):
Merge branches
Thanks, applied.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Thanks, applied.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Roland Dreier
After we've done __elv_add_request() and __blk_run_queue() in
blk_execute_rq_nowait(), the request might finish and be freed
immediately. Therefore checking if the type is REQ_TYPE_PM_RESUME
isn't safe afterwards, because if it isn't, rq might be gone.
Instead, check
From: Roland Dreier rol...@purestorage.com
After we've done __elv_add_request() and __blk_run_queue() in
blk_execute_rq_nowait(), the request might finish and be freed
immediately. Therefore checking if the type is REQ_TYPE_PM_RESUME
isn't safe afterwards, because if it isn't, rq might be gone
/mlx4: Synchronize cleanup of MCGs in MCG paravirtualization
Jack Morgenstein (1):
IB/mlx4: Fix QP1 P_Key processing in the Primary Physical Function (PPF)
Or Gerlitz (1):
mlx4_core: Remove annoying debug messages from SR-IOV flow
Roland Dreier (1):
Merge branches 'cxgb4' and 'mlx4
/mlx4: Synchronize cleanup of MCGs in MCG paravirtualization
Jack Morgenstein (1):
IB/mlx4: Fix QP1 P_Key processing in the Primary Physical Function (PPF)
Or Gerlitz (1):
mlx4_core: Remove annoying debug messages from SR-IOV flow
Roland Dreier (1):
Merge branches 'cxgb4' and 'mlx4
ble.
Alex Tabachnik (1):
IB/iser: Add more RX CQs to scale out processing of SCSI responses
Jack Morgenstein (1):
mlx4_core: Adjust flow steering attach wrapper so that IB works on SR-IOV
VFs
Roland Dreier (2):
IPoIB: Fix bu
.
Alex Tabachnik (1):
IB/iser: Add more RX CQs to scale out processing of SCSI responses
Jack Morgenstein (1):
mlx4_core: Adjust flow steering attach wrapper so that IB works on SR-IOV
VFs
Roland Dreier (2):
IPoIB: Fix build
-after-free of multicast object
Roland Dreier (7):
mlx4_core: Trivial readability fix: "0X30" -> "0x30"
mlx4_core: Trivial cleanups to driver log messages
mlx4_core: Fix crash on uninitialized priv->cmd.slave_sem
mlx4_core: Stash PCI ID driver_d
-after-free of multicast object
Roland Dreier (7):
mlx4_core: Trivial readability fix: 0X30 - 0x30
mlx4_core: Trivial cleanups to driver log messages
mlx4_core: Fix crash on uninitialized priv-cmd.slave_sem
mlx4_core: Stash PCI ID driver_data in mlx4_priv structure
On Mon, Sep 24, 2012 at 7:02 AM, Stephen Rothwell wrote:
> After merging the akpm tree, today's linux-next build (powerpc
> ppc64_defconfig) failed like this:
>
> drivers/infiniband/hw/mlx4/cm.c: In function 'id_map_alloc':
> drivers/infiniband/hw/mlx4/cm.c:228:36: error: 'MAX_ID_MASK' undeclared
On Mon, Sep 24, 2012 at 7:02 AM, Stephen Rothwell s...@canb.auug.org.au wrote:
After merging the akpm tree, today's linux-next build (powerpc
ppc64_defconfig) failed like this:
drivers/infiniband/hw/mlx4/cm.c: In function 'id_map_alloc':
drivers/infiniband/hw/mlx4/cm.c:228:36: error:
of unsignaled WQE
Roland Dreier (1):
Merge branches 'cxgb4', 'ipoib', 'mlx4', 'ocrdma' and 'qib' into for-next
Shlomo Pongratz (2):
IPoIB: Fix memory leak in the neigh table deletion flow
IPoIB: Fix AB-BA deadlock when deleting neighbours
Wei Yongjun (1):
RDMA/cxgb4: Move
of unsignaled WQE
Roland Dreier (1):
Merge branches 'cxgb4', 'ipoib', 'mlx4', 'ocrdma' and 'qib' into for-next
Shlomo Pongratz (2):
IPoIB: Fix memory leak in the neigh table deletion flow
IPoIB: Fix AB-BA deadlock when deleting neighbours
Wei Yongjun (1):
RDMA/cxgb4: Move
Roland Dreier (3):
RDMA/ocrdma: Don't call vlan_dev_real_dev() for non-VLAN netdevs
mlx4_core: Clean up buddy bitmap allocation
Merge branches 'cma', 'ipoib', 'misc', 'mlx4', 'ocrdma', 'qib' and 'srp'
into for-next
Shlomo Pongratz (2):
IB/ipoib: Add missing locking when
Roland Dreier (3):
RDMA/ocrdma: Don't call vlan_dev_real_dev() for non-VLAN netdevs
mlx4_core: Clean up buddy bitmap allocation
Merge branches 'cma', 'ipoib', 'misc', 'mlx4', 'ocrdma', 'qib' and 'srp'
into for-next
Shlomo Pongratz (2):
IB/ipoib: Add missing locking when
On Wed, Aug 15, 2012 at 6:44 PM, Stephen Rothwell wrote:
> After merging the infiniband tree, today's linux-next build (powerpc
> ppc64_defconfig) failed like this:
>
> drivers/net/ethernet/mellanox/mlx4/mr.c: In function 'mlx4_buddy_init':
> drivers/net/ethernet/mellanox/mlx4/mr.c:134:4: error:
On Wed, Aug 15, 2012 at 6:44 PM, Stephen Rothwell s...@canb.auug.org.au wrote:
After merging the infiniband tree, today's linux-next build (powerpc
ppc64_defconfig) failed like this:
drivers/net/ethernet/mellanox/mlx4/mr.c: In function 'mlx4_buddy_init':
> Use PCIe capabilities access functions to simplify mthca driver's
> implementation.
Acked-by: Roland Dreier
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kern
Use PCIe capabilities access functions to simplify mthca driver's
implementation.
Acked-by: Roland Dreier rol...@purestorage.com
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http
On Wed, Aug 1, 2012 at 6:38 AM, Lukas Hejtmanek wrote:
> [3.558296] mlx4_core :02:00.0: not enough MMIO resources for SR-IOV
> (nres: 0, iov->nres: 1)
This comes from the core sriov_enable() function, not anything in mlx4.
(although my kernel doesn't have the print of nres in that
On Wed, Aug 1, 2012 at 6:38 AM, Lukas Hejtmanek xhejt...@ics.muni.cz wrote:
[3.558296] mlx4_core :02:00.0: not enough MMIO resources for SR-IOV
(nres: 0, iov-nres: 1)
This comes from the core sriov_enable() function, not anything in mlx4.
(although my kernel doesn't have the print of
contention
IB/qib: Add congestion control agent implementation
IB/qib: checkpatch fixes
Roland Dreier (4):
RDMA/ocrdma: Fix assignment of max_srq_sge in device query
RDMA/cxgb4: Fix endianness of addition to mpa->private_data_size
IB: Use IS_ENABLED(CONFIG_I
contention
IB/qib: Add congestion control agent implementation
IB/qib: checkpatch fixes
Roland Dreier (4):
RDMA/ocrdma: Fix assignment of max_srq_sge in device query
RDMA/cxgb4: Fix endianness of addition to mpa-private_data_size
IB: Use IS_ENABLED(CONFIG_IPV6
Thanks Hugh. I just went ahead and built 3.5 final, and suspend/resume
look to be working again.
I'm not even going to try to understand how a timekeeping bug broke resume...
- R.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
On Wed, Jul 18, 2012 at 9:46 PM, Tomasz Chmielewski wrote:
> After upgrading to 3.5-rc7, my laptop no longer wakes up reliable from
> suspend to RAM. 3.4.x worked fine.
FWIW, I've been having similar problems with 3.5-rc7. With 3.5-rc6 my
laptop resumed fine, but since updating to -rc7, it
On Wed, Jul 18, 2012 at 9:46 PM, Tomasz Chmielewski t...@wpkg.org wrote:
After upgrading to 3.5-rc7, my laptop no longer wakes up reliable from
suspend to RAM. 3.4.x worked fine.
FWIW, I've been having similar problems with 3.5-rc7. With 3.5-rc6 my
laptop resumed fine, but since updating to
Thanks Hugh. I just went ahead and built 3.5 final, and suspend/resume
look to be working again.
I'm not even going to try to understand how a timekeeping bug broke resume...
- R.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to
thanks, applied.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
thanks, applied.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This looks like a really nice approach to me. Olaf?
- R.
--
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/
This looks like a really nice approach to me. Olaf?
- R.
--
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/
thanks, applied all 8 patches
--
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/
Thanks, applied, although I assume based on the Signed-off-by line
that you left out a
From: Bryan Rosenburg <[EMAIL PROTECTED]>
at the top (to get the authorship in git correctly).
> RDMA/cxgb3: Shift calculation wrong for single sge entries.
BTW, there's no need to duplicate the subject
Thanks, applied, although I assume based on the Signed-off-by line
that you left out a
From: Bryan Rosenburg [EMAIL PROTECTED]
at the top (to get the authorship in git correctly).
RDMA/cxgb3: Shift calculation wrong for single sge entries.
BTW, there's no need to duplicate the subject line
thanks, applied all 8 patches
--
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/
> Is it really intended to merge drivers without _any_ kind of review?
>
> This driver even lacks a basic "please fix the > 250 checkpatch errors" [1]
> and similar low hanging fruits that could easily be spotted and then
> fixed by the submitter within a short amount of time.
Just to be
> This driver should really have gotten some review before being included
> in the kernel.
> Even a simple checkpatch run finds more than > 250 stylistic errors
> (not code bugs but cases where the driver violates the standard code
> formatting rules of kernel code).
Linus has strongly
This driver should really have gotten some review before being included
in the kernel.
Even a simple checkpatch run finds more than 250 stylistic errors
(not code bugs but cases where the driver violates the standard code
formatting rules of kernel code).
Linus has strongly stated
Is it really intended to merge drivers without _any_ kind of review?
This driver even lacks a basic please fix the 250 checkpatch errors [1]
and similar low hanging fruits that could easily be spotted and then
fixed by the submitter within a short amount of time.
Just to be clear,
BTW, sorry I didn't get a chance to try some of the other debugging
you suggested yet... got busy with other stuff.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
> I just tried Ingo's patch[1] on a 2.6.25-rc2 kernel with printk timestamps
> turned on ... and it booted just fine on my tiger4. The default path
> for non-boot cpus is from head.S to start_secondary(), and that
> calls cpu_init() pretty quickly. There shouldn't normally[2] be any
>
> No, 51af33e8 was for a similar same bug 400 lines below this bug...
Heh, sorry.
Glenn -- please review Adrian's patches and let me know which ones are
good to apply.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More
No, 51af33e8 was for a similar same bug 400 lines below this bug...
Heh, sorry.
Glenn -- please review Adrian's patches and let me know which ones are
good to apply.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More
I just tried Ingo's patch[1] on a 2.6.25-rc2 kernel with printk timestamps
turned on ... and it booted just fine on my tiger4. The default path
for non-boot cpus is from head.S to start_secondary(), and that
calls cpu_init() pretty quickly. There shouldn't normally[2] be any
printk()
BTW, sorry I didn't get a chance to try some of the other debugging
you suggested yet... got busy with other stuff.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
Thanks, this is already upstream as 51af33e8
--
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/
fixes:
Pradeep Satyanarayana (1):
IPoIB/cm: Fix ipoib_cm_dev_stop() cleanup when drain times out
Roland Dreier (1):
IB/mthca: Free correct MPT on error exit from mthca_fmr_alloc()
drivers/infiniband/hw/mthca/mthca_mr.c |2 +-
drivers/infiniband/ulp/ipoib/ipoib_cm.c | 10
fixes:
Pradeep Satyanarayana (1):
IPoIB/cm: Fix ipoib_cm_dev_stop() cleanup when drain times out
Roland Dreier (1):
IB/mthca: Free correct MPT on error exit from mthca_fmr_alloc()
drivers/infiniband/hw/mthca/mthca_mr.c |2 +-
drivers/infiniband/ulp/ipoib/ipoib_cm.c | 10
Thanks, this is already upstream as 51af33e8
--
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/
It seems that we've come up with two reasonable cases where it makes
sense to use these notifiers for InfiniBand/RDMA:
First, the ability to safely to DMA to/from userspace memory with the
memory regions mlock()ed but the pages not pinned. In this case the
notifiers here would seem to suit us
for the new nes driver:
Chien Tung (1):
RDMA/nes: Fix VLAN support
Glenn Streiff (1):
RDMA/nes: Fix MAC interrupt erroneously masked on ifdown
Li Zefan (1):
IB: Fix return value in ib_device_register_sysfs()
Roland Dreier (1):
RDMA/nes: Fix possible array overrun
drivers
> > AFAIK mapping PCI memory WB is not allowed, so WC is really our only
> > choice.
> afaik that depends on the BAR being prefetchable or not.
In my case the BAR is prefetchable.
> (and by your argument, ioremap_cached() would not be useful, and since that
> was, until
> 2.6.25-rc1, the
> I've yet to see a user who wants WC. Lets face it, WC *sucks*. This is why
> the folks who care about performance (the graphics guys) stopped using it.
> WC is slow, and on modern cpus leads to really bad performance. I'm really
> half tempted to just ignore WC entirely and suggest that we
I've yet to see a user who wants WC. Lets face it, WC *sucks*. This is why
the folks who care about performance (the graphics guys) stopped using it.
WC is slow, and on modern cpus leads to really bad performance. I'm really
half tempted to just ignore WC entirely and suggest that we don't
AFAIK mapping PCI memory WB is not allowed, so WC is really our only
choice.
afaik that depends on the BAR being prefetchable or not.
In my case the BAR is prefetchable.
(and by your argument, ioremap_cached() would not be useful, and since that
was, until
2.6.25-rc1, the default
for the new nes driver:
Chien Tung (1):
RDMA/nes: Fix VLAN support
Glenn Streiff (1):
RDMA/nes: Fix MAC interrupt erroneously masked on ifdown
Li Zefan (1):
IB: Fix return value in ib_device_register_sysfs()
Roland Dreier (1):
RDMA/nes: Fix possible array overrun
drivers
It seems that we've come up with two reasonable cases where it makes
sense to use these notifiers for InfiniBand/RDMA:
First, the ability to safely to DMA to/from userspace memory with the
memory regions mlock()ed but the pages not pinned. In this case the
notifiers here would seem to suit us
Wow, good catch. How did you find this bug?
Anyway, thanks, applied.
- R.
--
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
):
IB/mthca: Convert to use be16_add_cpu()
Roland Dreier (3):
IB/mthca: Add missing sg_init_table() in mthca_map_user_db()
IB/cm: Remove debug printk()s that snuck upstream
IB/cm: Fix infiniband_cm class kobject ref counting
Sean Hefty (1):
RDMA/cma: Do not issue MRA if user
> The first things I need from the subsystem maintainers (you know who you
> are) are a contact address (a list address is fine) and at least one git
> branch or quilt series that contains all the things you want to see go
> into 2.6.26.
For InfiniBand/RDMA, the tree is:
> > The strange thing is that Ingo's patch to make cpu_clock() a NOP until
> > after sched_init() didn't fix things for me...
> Very strange. I threw in an output line counter into the printk code() ...
> if I
> disable the timestamps for the first 30 lines, then everything is good (so
> I can indeed try to re-make, passing CONFIG_DEBUG_SECTION_MISMATCH=y on the
> command line, but I can't turn on the option in my .config. That's because
> the option depends on "UNDEFINED". (Was that an attempt to "hide" the
> option? Why?) The following small patch allows me to set the
I can indeed try to re-make, passing CONFIG_DEBUG_SECTION_MISMATCH=y on the
command line, but I can't turn on the option in my .config. That's because
the option depends on UNDEFINED. (Was that an attempt to hide the
option? Why?) The following small patch allows me to set the option
The strange thing is that Ingo's patch to make cpu_clock() a NOP until
after sched_init() didn't fix things for me...
Very strange. I threw in an output line counter into the printk code() ...
if I
disable the timestamps for the first 30 lines, then everything is good (so
the
The first things I need from the subsystem maintainers (you know who you
are) are a contact address (a list address is fine) and at least one git
branch or quilt series that contains all the things you want to see go
into 2.6.26.
For InfiniBand/RDMA, the tree is:
):
IB/mthca: Convert to use be16_add_cpu()
Roland Dreier (3):
IB/mthca: Add missing sg_init_table() in mthca_map_user_db()
IB/cm: Remove debug printk()s that snuck upstream
IB/cm: Fix infiniband_cm class kobject ref counting
Sean Hefty (1):
RDMA/cma: Do not issue MRA if user
Wow, good catch. How did you find this bug?
Anyway, thanks, applied.
- R.
--
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
> I'll take a closer look at what is needed tomorrow.
Hi Tony,
Just curious -- can you reproduce the same problem with
CONFIG_PRINTK_TIME as I'm seeing? If not I'm happy to test anything
you want to try.
The strange thing is that Ingo's patch to make cpu_clock() a NOP until
after sched_init()
> > so .. how about the patch below? Note that we already had an "early
> > bootup" special (the rq->idle check), it's now just made explicit via
> > the scheduler_running flag.
>
> the one below even builds. (untested otherwise)
I just tried this... it doesn't work on top of current git
: Fail loopback connections
The cxgb3 HW and driver don't support loopback RDMA connections. So
fail any connection attempt where the destination address is local.
Signed-off-by: Steve Wise <[EMAIL PROTECTED]>
Signed-off-by: Roland Dreier <[EMAIL PROTECTED]>
di
> how can a static void function return 0?
good question... I've fixed the patch in my tree.
--
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
how can a static void function return 0?
good question... I've fixed the patch in my tree.
--
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
loopback connections
The cxgb3 HW and driver don't support loopback RDMA connections. So
fail any connection attempt where the destination address is local.
Signed-off-by: Steve Wise [EMAIL PROTECTED]
Signed-off-by: Roland Dreier [EMAIL PROTECTED]
diff --git a/drivers
so .. how about the patch below? Note that we already had an early
bootup special (the rq-idle check), it's now just made explicit via
the scheduler_running flag.
the one below even builds. (untested otherwise)
I just tried this... it doesn't work on top of current git (same
I'll take a closer look at what is needed tomorrow.
Hi Tony,
Just curious -- can you reproduce the same problem with
CONFIG_PRINTK_TIME as I'm seeing? If not I'm happy to test anything
you want to try.
The strange thing is that Ingo's patch to make cpu_clock() a NOP until
after sched_init()
I'm seeing a strange hang with current git (head 96b5a46e) on an ia64
box -- an Intel SDV with 2 dual core hyperthreaded Itanium 2 CPUs (so
8 logical CPUs to the kernel). It hangs without printing anything
("Uncompressing Linux... done" from ELILO is the last thing I see) if
I have
neat. applied...
--
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/
applied, although:
> +static void is_loopback_dst(struct iw_cm_id *cm_id)
> +{
> +struct net_device *dev;
> +
> +dev = ip_dev_find(_net, cm_id->remote_addr.sin_addr.s_addr);
> +if (!dev)
> +return 0;
> +dev_put(dev);
> +return 1;
> +}
is there any
> > Chelsio's T3 HW doesn't support this.
> Not so far I guess but it could be equipped with these features right?
I don't know anything about the T3 internals, but it's not clear that
you could do this without a new chip design in general. Lot's of RDMA
devices were designed expecting that
> The work I'm doing here is for stupid PCI firmware engineers, who have
> created devices that are different things, all bound up under the same
> PCI device. I'm thinking of watchdog timers and random number
> generator and i2c controller on the same PCI device, or even the more
> basic,
> The other is that once somebody says "ok, I *really* need to cause this
> breakage, because there's a major bug or we need it for fundamental reason
> XYZ", then that person should
>
> (a) create a base tree with _just_ that fundamental infrastructure change,
> and make sure that
Chelsio's T3 HW doesn't support this.
Not so far I guess but it could be equipped with these features right?
I don't know anything about the T3 internals, but it's not clear that
you could do this without a new chip design in general. Lot's of RDMA
devices were designed expecting that
applied, although:
+static void is_loopback_dst(struct iw_cm_id *cm_id)
+{
+struct net_device *dev;
+
+dev = ip_dev_find(init_net, cm_id-remote_addr.sin_addr.s_addr);
+if (!dev)
+return 0;
+dev_put(dev);
+return 1;
+}
is there any way this
neat. applied...
--
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/
The work I'm doing here is for stupid PCI firmware engineers, who have
created devices that are different things, all bound up under the same
PCI device. I'm thinking of watchdog timers and random number
generator and i2c controller on the same PCI device, or even the more
basic, frame
The other is that once somebody says ok, I *really* need to cause this
breakage, because there's a major bug or we need it for fundamental reason
XYZ, then that person should
(a) create a base tree with _just_ that fundamental infrastructure change,
and make sure that base
I'm seeing a strange hang with current git (head 96b5a46e) on an ia64
box -- an Intel SDV with 2 dual core hyperthreaded Itanium 2 CPUs (so
8 logical CPUs to the kernel). It hangs without printing anything
(Uncompressing Linux... done from ELILO is the last thing I see) if
I have
[Adding [EMAIL PROTECTED] to get the IB/RDMA people involved]
This thread has patches that add support for notifying drivers when a
process's memory map changes. The hope is that this is useful for
letting RDMA devices handle registered memory without pinning the
underlying pages, by updating
Linus, please pull from
master.kernel.org:/pub/scm/linux/kernel/git/roland/infiniband.git for-linus
This tree is also available from kernel.org mirrors at:
git://git.kernel.org/pub/scm/linux/kernel/git/roland/infiniband.git
for-linus
This will get one build fix:
Olof Johansson (1):
Thanks, applied.
Jack, I thought you guys tested the build on powerpc. How did this
sneak through?
--
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
[Adding [EMAIL PROTECTED] to get the IB/RDMA people involved]
This thread has patches that add support for notifying drivers when a
process's memory map changes. The hope is that this is useful for
letting RDMA devices handle registered memory without pinning the
underlying pages, by updating
Linus, please pull from
master.kernel.org:/pub/scm/linux/kernel/git/roland/infiniband.git for-linus
This tree is also available from kernel.org mirrors at:
git://git.kernel.org/pub/scm/linux/kernel/git/roland/infiniband.git
for-linus
This will get one build fix:
Olof Johansson (1):
Thanks, applied.
Jack, I thought you guys tested the build on powerpc. How did this
sneak through?
--
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
201 - 300 of 1691 matches
Mail list logo
