eclaration into the #ifdef too.
Signed-off-by: Roland Dreier <[EMAIL PROTECTED]>
---
diff --git a/drivers/input/serio/i8042.c b/drivers/input/serio/i8042.c
index 2763394..65a74cf 100644
--- a/drivers/input/serio/i8042.c
+++ b/drivers/input/serio/i8042.c
@@ -1151,7 +1151,6 @@ static int __devinit
eclaration into the #ifdef too.
Signed-off-by: Roland Dreier <[EMAIL PROTECTED]>
---
diff --git a/drivers/input/serio/i8042.c b/drivers/input/serio/i8042.c
index 2763394..65a74cf 100644
--- a/drivers/input/serio/i8042.c
+++ b/drivers/input/serio/i8042.c
@@ -1151,7 +1151,6 @@ static int __devinit
So I was perusing the code in lib/kobject.c, and I saw this:
void kobject_init(struct kobject *kobj, struct kobj_type *ktype)
{
// [a couple of of parameter checks...]
if (kobj->state_initialized) {
/* do not error out as
> I thought the adaptor can always remove the mapping by renegotiating
> with the remote side? Even if its dumb then a callback could notify the
> driver that it may be required to tear down the mapping. We then hold the
> pages until we get okay by the driver that the mapping has been
> We have done several rounds of discussion on linux-kernel about this so
> far and the IB folks have not shown up to join in. I have tried to make
> this as general as possible.
Sorry, this has been on my "things to look at" list for a while, but I
haven't gotten a chance to really
net/sunrpc/xprtrdma/svc_rdma_sendto.c:160: warning: format '%llx' expects type
'long long unsigned int', but argument 3 has type 'u64'
Signed-off-by: Roland Dreier <[EMAIL PROTECTED]>
---
diff --git a/net/sunrpc/xprtrdma/svc_rdma_sendto.c
b/net/sunrpc/xprtrdma/svc_rdma_sendto.c
index 3
() kernel queue buffers
IB/mlx4: Use multiple WQ blocks to post smaller send WQEs
Roland Dreier (3):
IB/mlx4: Consolidate code to get an entry from a struct mlx4_buf
mlx4_core: Clean up struct mlx4_buf
IB/core: Remove unused struct ib_device.flags member
drivers/infiniband/hw
net/sunrpc/xprtrdma/svc_rdma_sendto.c:160: warning: format '%llx' expects type
'long long unsigned int', but argument 3 has type 'u64'
Signed-off-by: Roland Dreier [EMAIL PROTECTED]
---
diff --git a/net/sunrpc/xprtrdma/svc_rdma_sendto.c
b/net/sunrpc/xprtrdma/svc_rdma_sendto.c
index 3e32194
I thought the adaptor can always remove the mapping by renegotiating
with the remote side? Even if its dumb then a callback could notify the
driver that it may be required to tear down the mapping. We then hold the
pages until we get okay by the driver that the mapping has been removed.
So I was perusing the code in lib/kobject.c, and I saw this:
void kobject_init(struct kobject *kobj, struct kobj_type *ktype)
{
// [a couple of of parameter checks...]
if (kobj-state_initialized) {
/* do not error out as
into the #ifdef too.
Signed-off-by: Roland Dreier [EMAIL PROTECTED]
---
diff --git a/drivers/input/serio/i8042.c b/drivers/input/serio/i8042.c
index 2763394..65a74cf 100644
--- a/drivers/input/serio/i8042.c
+++ b/drivers/input/serio/i8042.c
@@ -1151,7 +1151,6 @@ static int __devinit i8042_setup_kbd(void
into the #ifdef too.
Signed-off-by: Roland Dreier [EMAIL PROTECTED]
---
diff --git a/drivers/input/serio/i8042.c b/drivers/input/serio/i8042.c
index 2763394..65a74cf 100644
--- a/drivers/input/serio/i8042.c
+++ b/drivers/input/serio/i8042.c
@@ -1151,7 +1151,6 @@ static int __devinit i8042_setup_kbd(void
() kernel queue buffers
IB/mlx4: Use multiple WQ blocks to post smaller send WQEs
Roland Dreier (3):
IB/mlx4: Consolidate code to get an entry from a struct mlx4_buf
mlx4_core: Clean up struct mlx4_buf
IB/core: Remove unused struct ib_device.flags member
drivers/infiniband/hw
CONFIG_COMPAT_BRK=y means that heap randomization is turned off, so
it's *always* a safe choice. I assume the help text is trying to say
that if one does not run ancient binaries, then enabling heap
randomization is safe.
Signed-off-by: Roland Dreier <[EMAIL PROTECTED]>
---
diff --git
Hi Ingo,
What are your plans for handling the x86 io_delay stuff? The current
situation is pretty confusing to someone updating their config from a
2.6.24 kernel, since arch/x86/Kconfig.debug has:
config IO_DELAY_0X80
bool "port 0x80 based port-IO delay [recommended]"
but also
choice
> Sorry, but I'm afraid you got this wrong. When the iSER transport is
> used instead of TCP, all data is sent via RDMA, including unsolicited
> data. If you have look at the iSER implementation in the Linux kernel
> (source files under drivers/infiniband/ulp/iser), you will see that
> all
Sorry, but I'm afraid you got this wrong. When the iSER transport is
used instead of TCP, all data is sent via RDMA, including unsolicited
data. If you have look at the iSER implementation in the Linux kernel
(source files under drivers/infiniband/ulp/iser), you will see that
all data is
codes from mthca_fmr_alloc()
Or Gerlitz (3):
IPoIB: Handle bonding failover race for connected neighbours too
IPoIB: Remove a misleading debug print
IB/fmr_pool: Allocate page list for pool FMRs only when caching enabled
Roland Dreier (4):
mlx4_core: Fix more section mism
> /* safety net should the EC not support AUTO
> * or FULLSPEED mode bits and just ignore them */
> if (level & TP_EC_FAN_FULLSPEED)
> level |= 7; /* safety min speed 7 */
> else if (level &
/* safety net should the EC not support AUTO
* or FULLSPEED mode bits and just ignore them */
if (level TP_EC_FAN_FULLSPEED)
level |= 7; /* safety min speed 7 */
else if (level
from mthca_fmr_alloc()
Or Gerlitz (3):
IPoIB: Handle bonding failover race for connected neighbours too
IPoIB: Remove a misleading debug print
IB/fmr_pool: Allocate page list for pool FMRs only when caching enabled
Roland Dreier (4):
mlx4_core: Fix more section mismatches
> > randconfig testing found the following build bug in latest -git:
> >
> > drivers/built-in.o: In function `v4l2_i2c_attach':
> > : undefined reference to `i2c_attach_client'
I hit this too -- it seems that commit 8ffbc655 ("V4L/DVB (6451):
v4l2: add support for bus-based I2C drivers"),
> Subject to someone _making_ it an issue, can't see it changing.
Actually I think that Sam's recent improvements to the section
mismatch detection should make it easy to get at least all of the
driver issues fixed -- the problem in the past was that many warnings
would only show with certain
Subject to someone _making_ it an issue, can't see it changing.
Actually I think that Sam's recent improvements to the section
mismatch detection should make it easy to get at least all of the
driver issues fixed -- the problem in the past was that many warnings
would only show with certain
thanks, applied 1-2
--
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
--
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/
> @@ -72,6 +73,8 @@ static void __ib_umem_release(struct ib_device *dev,
> struct ib_umem *umem, int d
> * @addr: userspace virtual address to start at
> * @size: length of region to pin
> * @access: IB_ACCESS_xxx flags for memory being pinned
> + * @dmabarrier: set a "dma barrier" so
> Could you try the patch below and give me all boot messages again?
Sure, no problem, see below for full log (I updated to the latest git,
which seems to have some other unrelated problems with things timing
out earlier in the boot, but it does get to the ide-cd init); here's
the relevant
> diff --git a/drivers/infiniband/core/umem.c b/drivers/infiniband/core/umem.c
> index 4e3128f..5b00408 100644
> --- a/drivers/infiniband/core/umem.c
> +++ b/drivers/infiniband/core/umem.c
> @@ -74,7 +74,7 @@ static void __ib_umem_release(struct ib_device *dev,
> struct ib_umem *umem, int d
diff --git a/drivers/infiniband/core/umem.c b/drivers/infiniband/core/umem.c
index 4e3128f..5b00408 100644
--- a/drivers/infiniband/core/umem.c
+++ b/drivers/infiniband/core/umem.c
@@ -74,7 +74,7 @@ static void __ib_umem_release(struct ib_device *dev,
struct ib_umem *umem, int d
*
Could you try the patch below and give me all boot messages again?
Sure, no problem, see below for full log (I updated to the latest git,
which seems to have some other unrelated problems with things timing
out earlier in the boot, but it does get to the ide-cd init); here's
the relevant
@@ -72,6 +73,8 @@ static void __ib_umem_release(struct ib_device *dev,
struct ib_umem *umem, int d
* @addr: userspace virtual address to start at
* @size: length of region to pin
* @access: IB_ACCESS_xxx flags for memory being pinned
+ * @dmabarrier: set a dma barrier so that
thanks, 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/
thanks, applied 1-2
--
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/
Actually this appears to be the bug that Jens fixed with this patch,
and with that patch my system seems fine as well:
diff --git a/block/as-iosched.c b/block/as-iosched.c
index b201d16..9603684 100644
--- a/block/as-iosched.c
+++ b/block/as-iosched.c
@@ -1275,9 +1275,13 @@ static void
I'm getting the following while building a kernel (with make -j24 on
an 8 CPU system: 4 socket dual-core opteron) with current Linus git
(5b10ca19 is my head). Once this happens the build is hung, although
I can ssh in and get a new shell OK.
Any ideas or suggestions on what would be useful
> . . STGT read SCST read.STGT read
> SCST read.
> . . performance performance . performance
> performance .
> . . (0.5K, MB/s) (0.5K, MB/s) . (1 MB, MB/s)
> (1 MB, MB/s)
. . STGT read SCST read.STGT read
SCST read.
. . performance performance . performance
performance .
. . (0.5K, MB/s) (0.5K, MB/s) . (1 MB, MB/s)
(1 MB, MB/s) .
.
I'm getting the following while building a kernel (with make -j24 on
an 8 CPU system: 4 socket dual-core opteron) with current Linus git
(5b10ca19 is my head). Once this happens the build is hung, although
I can ssh in and get a new shell OK.
Any ideas or suggestions on what would be useful
Actually this appears to be the bug that Jens fixed with this patch,
and with that patch my system seems fine as well:
diff --git a/block/as-iosched.c b/block/as-iosched.c
index b201d16..9603684 100644
--- a/block/as-iosched.c
+++ b/block/as-iosched.c
@@ -1275,9 +1275,13 @@ static void
Add mappings from HW register to PortInfo port physical state
IB/ipath: Trivial simplification of ipath_make_ud_req()
Roland Dreier (10):
IB/ipath: Fix crash on unload introduced by sysfs changes
IPoIB: Trivial formatting cleanups
IPoIB/cm: Factor out ipoib_cm_free_rx_ring()
So I think it is coming from the following code in ipath_sysfs.c:
int ipath_device_create_group(struct device *dev, struct ipath_devdata
*dd)
{
int ret;
ret = sysfs_create_group(>kobj, _attr_group);
if (ret)
Hey Greg,
with Linus's latest kernel v2.6.24-412-gb47711b (which includes the
patch in the email I'm replying to), I see the following when I do
"modprobe -r ib_ipath" (on a system that actually has ipath hardware):
kernel BUG at fs/sysfs/group.c:74!
invalid opcode: [1] SMP
CPU 1
Hey Greg,
with Linus's latest kernel v2.6.24-412-gb47711b (which includes the
patch in the email I'm replying to), I see the following when I do
modprobe -r ib_ipath (on a system that actually has ipath hardware):
kernel BUG at fs/sysfs/group.c:74!
invalid opcode: [1] SMP
CPU 1
Modules
register to PortInfo port physical state
IB/ipath: Trivial simplification of ipath_make_ud_req()
Roland Dreier (10):
IB/ipath: Fix crash on unload introduced by sysfs changes
IPoIB: Trivial formatting cleanups
IPoIB/cm: Factor out ipoib_cm_free_rx_ring()
IPoIB/cm: Factor out
So I think it is coming from the following code in ipath_sysfs.c:
int ipath_device_create_group(struct device *dev, struct ipath_devdata
*dd)
{
int ret;
ret = sysfs_create_group(dev-kobj, dev_attr_group);
if (ret)
thanks, 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/
> > Anyway, here are all the pending things that I'm aware of. As usual,
> > if something isn't already in my tree and isn't listed below, I
> > probably missed it or dropped it by mistake. Please remind me again
> > in that case.
>
> Are there any plans to merge the SDP (Sockets Direct
Anyway, here are all the pending things that I'm aware of. As usual,
if something isn't already in my tree and isn't listed below, I
probably missed it or dropped it by mistake. Please remind me again
in that case.
Are there any plans to merge the SDP (Sockets Direct Protocol)
thanks, 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/
> drivers/acpi/pci_bind.c: In function 'acpi_pci_unbind'::0:
> internal compiler error: Segmentation fault
> Depending on which kernel i build, it fails on different things.
Seems like a classic symptom of some sort of hardware fault/memory corruption...
> I tried disabling HPET and VT in
e endianness stuff elsewhere.
Anyway this is what I have in case the promised cleanups don't turn up
in time...
Signed-off-by: Roland Dreier <[EMAIL PROTECTED]>
diff --git a/drivers/infiniband/hw/nes/nes.c b/drivers/infiniband/hw/nes/nes.c
index 7a2f596..365ebaa 100644
--- a/drivers/infin
> > be improved (sparse endianness annotation,
> that's a blocker for sure. No new code that's not sparse clean, please.
I have to disagree -- remember how strongly Linus pushed to merge
hardware drivers early? the code in question will not run unless you
have the hardware it drives, and
be improved (sparse endianness annotation,
that's a blocker for sure. No new code that's not sparse clean, please.
I have to disagree -- remember how strongly Linus pushed to merge
hardware drivers early? the code in question will not run unless you
have the hardware it drives, and that
in case the promised cleanups don't turn up
in time...
Signed-off-by: Roland Dreier [EMAIL PROTECTED]
diff --git a/drivers/infiniband/hw/nes/nes.c b/drivers/infiniband/hw/nes/nes.c
index 7a2f596..365ebaa 100644
--- a/drivers/infiniband/hw/nes/nes.c
+++ b/drivers/infiniband/hw/nes/nes.c
@@ -231,10
drivers/acpi/pci_bind.c: In function 'acpi_pci_unbind':built-in:0:
internal compiler error: Segmentation fault
Depending on which kernel i build, it fails on different things.
Seems like a classic symptom of some sort of hardware fault/memory corruption...
I tried disabling HPET and VT
> --- a/include/linux/dma-attrs.h
> +++ b/include/linux/dma-attrs.h
> @@ -0,0 +1,33 @@
> +#ifndef _DMA_ATTR_H
> +#define _DMA_ATTR_H
> +
> +#include
> +
> +enum {
> +DMA_ATTR_INVALID,
> +DMA_ATTR_BARRIER,
> +DMA_ATTR_FOO,
> +DMA_ATTR_GOO,
> +DMA_ATTR_MAX,
> +};
thanks, applied 1-3
--
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/
> > - Neteffect "nes" driver. It's not terribly clean code but since
> >it's a new driver that is completely self-contained, I plan on
> >merging it and letting cleanups happen upstream.
>
> New code should be better quality than old code, not worse. I haven't
> actually seen
- Neteffect nes driver. It's not terribly clean code but since
it's a new driver that is completely self-contained, I plan on
merging it and letting cleanups happen upstream.
New code should be better quality than old code, not worse. I haven't
actually seen the driver
thanks, applied 1-3
--
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/
--- a/include/linux/dma-attrs.h
+++ b/include/linux/dma-attrs.h
@@ -0,0 +1,33 @@
+#ifndef _DMA_ATTR_H
+#define _DMA_ATTR_H
+
+#include linux/bug.h
+
+enum {
+DMA_ATTR_INVALID,
+DMA_ATTR_BARRIER,
+DMA_ATTR_FOO,
+DMA_ATTR_GOO,
+DMA_ATTR_MAX,
+};
+
thanks, applied 1-4.
--
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 1-4.
--
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/
IB/ipath: Export hardware counters more consistently
IB/ipath: Allow more flexible user register alignments
IB/ipath: Port config has on-chip effects for 7220
IB/ipath: Add flag and handling for chips with swapped register bug
Roland Dreier (8):
IPoIB: Trivial format
> Yes, indeed none of the atomic bit operations functions has
> LOCK_PREFIX in my version of Linux kernel.
You have a broken source tree then. Where did your kernel source come
from then? I'm not able to find any version of asm-i386/bitops.h
where clear_bit() doesn't have LOCK_PREFIX in any
Yes, indeed none of the atomic bit operations functions has
LOCK_PREFIX in my version of Linux kernel.
You have a broken source tree then. Where did your kernel source come
from then? I'm not able to find any version of asm-i386/bitops.h
where clear_bit() doesn't have LOCK_PREFIX in any of
consistently
IB/ipath: Allow more flexible user register alignments
IB/ipath: Port config has on-chip effects for 7220
IB/ipath: Add flag and handling for chips with swapped register bug
Roland Dreier (8):
IPoIB: Trivial formatting cleanups
IPoIB/cm: Factor out
> Then, I think there is a problem with the function written below which is
> meant to be atomic.
>
> static __inline__ void change_bit(int nr, volatile void * addr)
> {
> __asm__ __volatile__(
> "btcl %1,%0"
> :"=m" (ADDR)
> :"Ir"
Signed-off-by: Ralph Campbell <[EMAIL PROTECTED]>
Signed-off-by: Roland Dreier <[EMAIL PROTECTED]>
---
diff --git a/drivers/infiniband/hw/ipath/ipath_ud.c
b/drivers/infiniband/hw/ipath/ipath_ud.c
index 16a2a93..b3df6f3 100644
--- a/drivers/infiniband/hw/ipath/ipath_ud.c
+++ b/dri
Thanks a lot for pointing this out! I rolled the following into the
offending patch in my tree instead (I preferred avoiding #ifdefs in .c
files...)
diff --git a/drivers/infiniband/ulp/ipoib/ipoib.h
b/drivers/infiniband/ulp/ipoib/ipoib.h
index 545c5a3..fe250c6 100644
---
Thanks a lot for pointing this out! I rolled the following into the
offending patch in my tree instead (I preferred avoiding #ifdefs in .c
files...)
diff --git a/drivers/infiniband/ulp/ipoib/ipoib.h
b/drivers/infiniband/ulp/ipoib/ipoib.h
index 545c5a3..fe250c6 100644
---
Then, I think there is a problem with the function written below which is
meant to be atomic.
static __inline__ void change_bit(int nr, volatile void * addr)
{
__asm__ __volatile__(
btcl %1,%0
:=m (ADDR)
:Ir (nr));
}
If
> >I don't think that's a good idea. Drivers should be able to
> >detect this somehow.
> >Handling UC mappings as WC will probably give very poor results.
> It is the other way. ioremap_wc aliases to ioremap_nocache.
> This was based on earlier feedback from Roland.
> I'm trying to implement atomic ops for a CPU which has no inherent
> support for Read-Modify-Write Ops. Instead of using a global spin lock
> which protects all the atomic APIs, I want to use a spin lock per
> instance of atomic_t. This works well when atomic_t is unitary and
> statically
I'm trying to implement atomic ops for a CPU which has no inherent
support for Read-Modify-Write Ops. Instead of using a global spin lock
which protects all the atomic APIs, I want to use a spin lock per
instance of atomic_t. This works well when atomic_t is unitary and
statically
I don't think that's a good idea. Drivers should be able to
detect this somehow.
Handling UC mappings as WC will probably give very poor results.
It is the other way. ioremap_wc aliases to ioremap_nocache.
This was based on earlier feedback from Roland.
From: Roland Dreier [mailto
> What it wants to do is set strict ordering for the bus ... well, that is
> an attribute in the PCIe standard (it just happens to be the default one
> for a standard bus, whereas relaxed is the default for altix). However,
> set bus attribute strict would be a simple no-op for a standard bus
What it wants to do is set strict ordering for the bus ... well, that is
an attribute in the PCIe standard (it just happens to be the default one
for a standard bus, whereas relaxed is the default for altix). However,
set bus attribute strict would be a simple no-op for a standard bus
--git a/MAINTAINERS b/MAINTAINERS
index 79c711e..56e6159 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1919,7 +1919,7 @@ INFINIBAND SUBSYSTEM
P: Roland Dreier
M: [EMAIL PROTECTED]
P: Sean Hefty
-M: [EMAIL PROTECTED]
+M: [EMAIL PROTECTED]
P: Hal Rosenstock
M: [EMAIL
thanks, 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/
> > I think the case before us that Arthur is dealing with is a
> > counterexample for this: there's nothing bus-specific about it all.
> > The issue is related to reordering of DMAs within the Altix system
> > fabric, after they've left the PCI world. This issue would be present
> > no
> Onething I've missed with these patches is drivers actually using
> it. What driver actually needs it and why don't you send patches
> for them?
In previous patch series, Arthur sent fixes for the mthca IB driver.
Other IB drivers like mlx4 also need this on Altix systems. Basically
> I'm already on record saying I don't think attributes in the generic
> code is the right approach. All of the attributes I can see adding are
> bus specific (even to the extent that PCIe ones wouldn't apply to PCI
> for instance).
I think the case before us that Arthur is dealing with is a
I'm already on record saying I don't think attributes in the generic
code is the right approach. All of the attributes I can see adding are
bus specific (even to the extent that PCIe ones wouldn't apply to PCI
for instance).
I think the case before us that Arthur is dealing with is a
Onething I've missed with these patches is drivers actually using
it. What driver actually needs it and why don't you send patches
for them?
In previous patch series, Arthur sent fixes for the mthca IB driver.
Other IB drivers like mlx4 also need this on Altix systems. Basically
anything
I think the case before us that Arthur is dealing with is a
counterexample for this: there's nothing bus-specific about it all.
The issue is related to reordering of DMAs within the Altix system
fabric, after they've left the PCI world. This issue would be present
no matter what
thanks, 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/
--git a/MAINTAINERS b/MAINTAINERS
index 79c711e..56e6159 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1919,7 +1919,7 @@ INFINIBAND SUBSYSTEM
P: Roland Dreier
M: [EMAIL PROTECTED]
P: Sean Hefty
-M: [EMAIL PROTECTED]
+M: [EMAIL PROTECTED]
P: Hal Rosenstock
M: [EMAIL
> - "radiotap head [%d]\n",
> + "radiotap head [%ld]\n",
> skb_headroom(skb), sizeof(*iwl4965_rt));
Actually I think the correct printf format for printing a size_t
(coming here from sizeof foo) is "%zd".
- radiotap head [%d]\n,
+ radiotap head [%ld]\n,
skb_headroom(skb), sizeof(*iwl4965_rt));
Actually I think the correct printf format for printing a size_t
(coming here from sizeof foo) is %zd. Otherwise you'll
thanks, 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/
thanks for keeping on top of the schedule, applied for 2.6.25.
--
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
what the heck, 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/
> @@ -423,8 +423,8 @@ static void srp_remove_work(struct work_struct *work)
> list_del(>list);
> spin_unlock(>srp_host->target_lock);
>
> -srp_remove_host(target->scsi_host);
> scsi_remove_host(target->scsi_host);
> +srp_remove_host(target->scsi_host);
Thanks... I
> +if (scsi_is_srp_rport(dev))
> +srp_rport_del(dev_to_rport(dev));
This has the ring of truth to me as the right fix, although I
certainly don't know the details of this code... Fujita-san?
- R.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the
> If we've got time before 2.6.24 final, I'd wait on this a bit.
> ib_srp:srp_remove_work() has them reversed as well, and I'm currently
> tracking down why it oopses when the srp_remove_host() happens before
> the scsi_remove_host(), which is the documented call sequence.
I think the best
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 pull one fix for an oops caused by
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 pull one fix for an oops caused by
If we've got time before 2.6.24 final, I'd wait on this a bit.
ib_srp:srp_remove_work() has them reversed as well, and I'm currently
tracking down why it oopses when the srp_remove_host() happens before
the scsi_remove_host(), which is the documented call sequence.
I think the best thing
301 - 400 of 1691 matches
Mail list logo
