about
the architectural changes needed to make System Area Networking and
TCP/IP offload easier under Linux.
Thanks,
Roland
--
Roland Dreier[EMAIL PROTECTED]
GPG Key fingerprint = A89F B5E9 C185 F34D BD50 4009 37E2 25CC E0EE FAC0
-
To unsubscribe from this list
Pete == Pete Zaitcev [EMAIL PROTECTED] writes:
Roland The rough idea is that WSD is a new user space library
Roland that looks at sockets calls and decides if they have to go
Roland through the usual kernel network stack, or if they can be
Roland handed off to a SAN service
Pekka If you used sockets, I believe the normal way to use SAN
Pekka boards is to just make them look like network cards with a
Pekka large MTU Sure it works, but it's not very efficient :) (I
Pekka have to admit I've not played with that kind of toys at
Pekka all, though)
We
-down_interruptible(info-write_sem);
+if(mutex_lock_interruptible(info-write_lock)){
+return -ERESTARTSYS;
+}
1) This is a semantic change. Of course using down_interruptible()
without checking the return value is almost certainly a bug, but have
you thought about
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 a one-liner that fixes data
Again, my code is faster only because I skip the key loading in
cia_encrypt method. Actually the gain is bigger in decryption mode
than in encryption one because I also generate the decryption key for
each block.
I wonder if there's some way you can cache the last caller and reload
the
I actually have a couple of Dell 1950 systems with bnx2 NICs too,
which I use for kernel development (ie one more crash is fine :)
If someone can give me an idea for what kind of load to use, I can try
this patch out to see if it triggers.
- R.
-
To unsubscribe from this list: send the line
I wonder if there's some way you can cache the last caller and reload
the key lazily (only when it changes).
yes something that allows crypto drivers to detect if the key has
changed would be good.
It seems trivial to keep the last key you were given and do a quick
memcmp in your
It seems trivial to keep the last key you were given and do a quick
memcmp in your setkey method to see if it's different from the last
key you pushed to hardware, and set a flag if it is. Then only do
your set_key() if you have a new key to pass to hardware.
I'm assuming the
After the discussions that took place back around the time of the release of
the first draft of GPLv3 it was decided to lock Linux to *ONLY* GPLv2
This is not accurate. As far back as I can easily check, the kernel's
COPYING file has said:
Also note that the only valid version of the GPL
As I mentioned, the rootfs is on reiser. So something in the boot up
scripts may trigger something that gets reiser to run through that path
with the wrong locking order. After the box is done booting, the dmesg
is clean. I then mount the ext3 fs and run the fio test, the lockdep
trace
Main include file and .c file for mlx4_ib.
Signed-off-by: Roland Dreier [EMAIL PROTECTED]
---
main.c| 612 ++
mlx4_ib.h | 285
2 files changed, 897 insertions(+)
diff --git a/drivers/infiniband/hw
Hook up mlx4_core and mlx4_ib drivers to Kconfig and Makefiles.
Signed-off-by: Roland Dreier [EMAIL PROTECTED]
---
infiniband/Kconfig |2 ++
infiniband/Makefile |1 +
infiniband/hw/mlx4/Kconfig |9 +
infiniband/hw/mlx4/Makefile |3 +++
net/Kconfig
Include files for hardware/firmware information and interface of
mlx4_core module for protocol-specific drivers (such as mlx4_ib).
Signed-off-by: Roland Dreier [EMAIL PROTECTED]
---
cmd.h | 178 +
cq.h | 123 +++
device.h
As promised, here is a series of patches adding the mlx4_core and
mlx4_ib drivers for the new Mellanox ConnectX adapter. These patches
are split up in an ad hoc way to avoid mailing list size limits, but
when this driver is finally merged, I will give it to Linus to pull in
a single changeset.
Hmm, I have links like this on my system already:
$ ls -l /sys/class/infiniband/mlx4_0/device
lrwxrwxrwx 1 root root 0 2007-04-23 12:14
/sys/class/infiniband/mlx4_0/device -
../../../devices/pci:00/:00:06.0/:0d:00.0
the patch actually looks sane but I don't understand why
+if (hipz_h_query_port(shca-ipz_hca_handle, port, rblock) != H_SUCCESS)
{
+ehca_err(shca-ib_device, Can't query port properties);
+ret = -EINVAL;
+goto modify_port1;
+}
+
+cap = (rblock-capability_mask | props-set_port_cap_mask)
+
Looks good, applied for 2.6.22.
-
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/
of the drivers and gives ehca a nice
/sys/class/infiniband/ehcaX/device symlink.
Signed-off-by: Joachim Fenkes [EMAIL PROTECTED]
Signed-off-by: Roland Dreier [EMAIL PROTECTED]
diff --git a/drivers/infiniband/core/sysfs.c b/drivers/infiniband/core/sysfs.c
index 000c086..08c299e 100644
--- a/drivers/infiniband
My suggestion would be to allocate top-down in the 32-bit IOMMU space.
I think that's good for normal things, but it's not unreasonable to
want to map 4 GB of memory at once for an Infiniband device.
So maybe we would want some heuristics about the size of the mapping
being requested or the
When ever I try and start a guest OS with kvm I get a lot of these rtc
missing interupt messages from the kernel
[ 468.510878] rtc: lost some interrupts at 1024Hz.
I started to debug this a little while ago but I never got too far.
However it doesn't seem connected with kvm -- it is
Try running your guest with -no-kvm (and even with the kvm module not
loaded, just to be sure). In my case I still saw the messages.
However, removing the -net tap line from my command line did get rid
of the messages.
Hmmm I'm getting the same thing on 2.6.20.1 as well.
With or
Holding a lock too long should be easy to debug with the -rt patch -
set the preemption related options to match mainline, and enable the
latency tracer.
Good idea, I'll give it a shot when I get a chance.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body
(1):
RDMA/cxgb3: Fix build on sparc64
Hoang-Nam Nguyen (1):
IB/ehca: Fix sync between completion handler and destroy cq
Roland Dreier (2):
IPoIB: Only handle async events for one port
IB/mthca: Fix error path in mthca_alloc_memfree()
Sean Hefty (2):
RDMA/cma
Perhaps this patch can go into Wesnoth for testing for a while before
we merge it into the kernel?
-
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
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/
It looks like devres stuff is still broken on ia64, at least on the
config below. The build dies with:
CC drivers/base/dma-mapping.o
/scratch/Ksrc/linux-git/drivers/base/dma-mapping.c: In function
'dmam_noncoherent_release':
/scratch/Ksrc/linux-git/drivers/base/dma-mapping.c:32: error:
ia64_mv.dma_free_coherent).
This patch fixes this by converting dma_{alloc,free}_noncoherent()
into inline functions that call the corresponding coherent functions,
instead of trying to do this with macros.
Signed-off-by: Roland Dreier [EMAIL PROTECTED]
---
include/asm-ia64/dma-mapping.h | 15
on 64-bit systems
IB/mthca: Always fill MTTs from CPU
Roland Dreier (1):
IB/mthca: Use correct structure size in call to memset()
Sean Hefty (2):
RDMA/cma: Increment port number after close to avoid re-use
IB: Remove redundant _wq from workqueue names
Steve Wise (1
Commit 42da9cbd (mm: mincore anon) breaks CONFIG_SWAP=n builds with:
mm/built-in.o: In function `sys_mincore':
(.text+0xe2c4): undefined reference to `swapper_space'
because swapper_space is used unconditionally in mm/mincore.c but only
defined in swap_state.c, which isn't built if
We've beat this almost to death... just need some patch merged.
Sorry, missed the discussion I guess...
-
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
Looks fine but this patch at least has serious whitespace
damage... please resend a fixed version.
- 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
I agree with Christoph -- the use of wait_for_completion() in a loop
makes no sense. When you send a new copy of this patch without
whitespace damage, please fix that up too...
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
Thanks, queued 1, 2, 3 and 5 for 2.6.21.
-
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/
Looking at this one more time, I think it actually may be buggy:
@@ -147,6 +147,7 @@ struct ib_cq *ehca_create_cq(struct ib_d
spin_lock_init(my_cq-spinlock);
spin_lock_init(my_cq-cb_lock);
spin_lock_init(my_cq-task_lock);
+init_completion(my_cq-zero_callbacks);
So
fix
Roland Dreier (5):
IB/mthca: Fix allocation of ICM chunks in coherent memory
IPoIB: Only allow root to change between datagram and connected mode
IB/core: Fix sparse warnings about shadowed declarations
IB/ipath: Make ipath_map_sg() static
IB/core: Set static rate
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
-
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/
Are these really all for 2.6.22? Some of them seem like bugfixes that
you would want in 2.6.21...
-
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
This patch format is somewhat inconvenient:
# HG changeset patch
# User Bryan O'Sullivan [EMAIL PROTECTED]
I assume this is the real author of the patch (as opposed to the
sender of the email)? git would prefer to see
From: Bryan O'Sullivan [EMAIL PROTECTED]
in the body of the email.
#
For example this seems like it should go in 2.6.21 -- otherwise
userspace verbs are completely broken with ipath, right? It's really
my fault for breaking it, but I don't see why we want to release with
a bug like that.
- R.
-
To unsubscribe from this list: send the line unsubscribe
Similarly -- shouldn't an obvious memory corruption fix be in 2.6.21?
-
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
The port sharing feature mixed kernel virtual addresses as well as
physical addresses for the offset used to describe the mmap address to map
the InfiniPath hardware into user space. This had a conflict on powerpc.
The new scheme converts it to a physical address so it doesn't conflict
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/
Something like this then? Untested.
Looks right to me, and seems to work. So I'll apply this.
- 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
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/
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 various small post-rc4 fixes:
Bryan
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 don't understand your need to try to rush an api change like this in
so quickly in an area that has a lot of churn and disagreement lately.
_Especially_ so late in the release cycle, and with no hardware publicly
availble.
I'm not sure I understood this thread properly, but if I did
OK, another data point. The config below boots and works with
2.6.21-rc4-rt1, but enabling CONFIG_CRITICAL_IRQSOFF_TIMING causes the
early boot hang.
Any idea?
Thanks,
Roland
#
# Automatically generated make config: don't edit
# Linux kernel version: 2.6.21-rc4-rt1
# Sat Mar 24 22:06:44 2007
I'm trying to use 2.6.21-rc4-rt1 to track down who's keeping
interrupts off for too long. [...]
btw., is this something you know for sure (if yes, how do you know?) -
or is it that you would like to double-check the irqs-off times of
v2.6.21-to-be?
I finally got curious enough to
the 64-bit kernel indeed hangs. Does the patch below fix it for you?
Yes, that boots and seems to work fine.
Thanks.
-
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 finally got curious enough to want to debug why starting kvm with
tun/tap networking produces a bunch of
rtc: lost some interrupts at 1024Hz.
messages. So I'm assuming it's a ~millisecond irqs-off section
somewhere.
And after everything, it's a heisenbug -- I repeatably get
= IPATH_CORE =
./drivers/Makefile:obj-$(CONFIG_IPATH_CORE) += infiniband/
Thanks, I was just noticing that myself. I'll remove it for 2.6.22.
- R.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More
Hmm, yeah I'll see if I could group them a bit. The problem there
is that the patch series contains multiple rounds of add and fix
cycles. Pretty much all the non-dependant fixes have already been
applied, BTW.
I think it's nice to roll up fixes into patches that haven't been
merged
no. Two _completely separate_ lists.
i.e. a to-be-reaped task will still be on the main list _too_. The main
list is for all the PID semantics rules. The reap-list is just for
wait4() processing. The two would be completely separate.
I guess this means we add another list head to
[I can't believe I'm stepping into an indentation flamewar, but here goes...]
Please change your coding style to conform to Documentation/CodingStyle.
*** Only indent with tabs!! ***
Every one of those examples violates that simple rule.
Yes,
Lets say that we want to do MW DMA mode 2. This has the minimum timing
of 70ns active, 25ns recovery, 120ns cycle time.
When you quantise those figures using a clock period of 62.5ns (16MHz)
you end up with: 2 clocks active (2*62.5 70), 1 clock recovery
(1*62.5 25) and 2 clocks
I'd like to announce preliminary versions of a set of mlx4 drivers
for Mellanox's new ConnectX InfiniBand/10 gigabit ethernet adapters.
(These are Mellanox's 4th generation of adapters, hence the mlx4 name)
Because these adapters can operate as both an ethernet NIC and an
InfiniBand HCA (at the
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 two small post-rc6 fixes for crasher
Fact is, we cannot remove SPIN_LOCK_UNLOCKED. It's needed for
variables outside functions:
static spinlock_t foobar = SPIN_LOCK_UNLOCKED;
DEFINE_SPINLOCK() is provided to define variables that way.
- R.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body
but that's where you would use the more explicit
__RAW_SPIN_LOCK_UNLOCKED, no? AFAIK, you really can remove the macro
SPIN_LOCK_UNLOCKED in its entirety.
I don't remember LDD speaking about __RAW_*. (And other than not
having looked into the code to date, I don't know the
Don't worry about the __RAW_SPIN_LOCK_UNLOCKED stuff, that's
obviously not for generic code to use. The right answer (as I said
before) is to use DEFINE_SPINLOCK().
that works fine if you're defining a single spinlock, but what do you
do in cases like this:
I just queued all of this for 2.6.22.
Is there any chance of getting a fix for the use-after-free that can
be caused by allocating something from userspace, failing to mmap the
buffer and then exiting? To see what happens, look at how
ipath_create_cq sticks a struct ipath_mmap_info into the
I applied this, but I still think there's some more work to do in this
area:
The port sharing feature mixed kernel virtual addresses as well as
physical addresses for the offset used to describe the mmap address to map
the InfiniPath hardware into user space. This had a conflict on
Is there any chance of getting a fix for the use-after-free that can
be caused by allocating something from userspace, failing to mmap the
buffer and then exiting? To see what happens, look at how
ipath_create_cq sticks a struct ipath_mmap_info into the pending mmap
list (and yes it
BTW: any idea how this ever got triggered? The only way I can see is
if you're either not using libipathverbs and libibverbs and you just
create the CQ some other way, which seems unlikely. Do you know how
Jason triggered this bug?
Yes, it was because he was using 32-bit userspace and
So is the cxgb3 net driver change in question already in Linus's tree?
What is the exact patch that this change goes with?
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
Indeed, port density is disappointingly poor in modern servers. Do you
know any with more than 14 ports per U? (That's an MBX 1U server with
8 on-board and a 6-port expansion).
If you really need a ton of ports you could probably build a 1U server
with 2 * 2-port 10gig NICs, and use
The patch is the 3rd of 3:
http://marc.info/?l=linux-kernelm=117617444622279w=2
Jeff applied it into his upstream tree here:
http://marc.info/?l=linux-netdevm=117630664627997w=2
OK, so it's not in Linus's tree yet. Jeff, how do you want to handle
this? (That last patch breaks
Never mind, I see that cxgb3 - missing CPL hanler and register
setting. has appeared in Linus's tree. Steve, I'll ask Linus to pull
this fix today. Jeff, never mind my question since it's too late now.
- R.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of
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 fix up some problems with
Apr 9 06:19:04 ' eth0:14250798570591813804 2284720007938 1863800
18638 0 27375938 1556640980159 3345714490000 0
0 0 '
One odd thing is that crazy number 14250798570591813804 is
c5c501cbc5c500ac in hex. I dunno what the significant of the
Apr 11 22:14:02 ' eth0:220898233988841368 66750274000 0
0 86458738 52386430545 101089219 19931300 0 199313
0 '
Apr 11 22:15:02 ' eth0:17227454818 81381144000 0
0 0 33091307388 8665838100
[Adding Michael Chan, who seems to look after bnx2, to the cc list]
To clarify it's an Intel Dual Core Xeon (I just wound up as thinking of
them all as amd64s). Network card driver in use is the one defined by
CONFIG_BNX2. Kernel's monolithic.
From a quick look at bnx2.c, it seems that the
Queued for my next merge, thanks.
-
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/
Does anyone know if there is any way to flush a cache line of the cpu to
force rereading system memory for a given address or address range?
There is the clflush instruction, but not all x86 CPUs support it.
You need to check the CPUID flag to know for sure (/proc/cpuinfo will
show a clflush
You could just remove the code instead of #if 0...
Steve, can you decide what the right thing to do with these changes is
and send me the result (or just tell me to apply Adrian's patch
as-is)?
Thanks,
Roland
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body
This patch introduces an optional alternative receive processing
functionality (enabled via module load parameter). The ehea adapter
can sort TCP traffic to multiple receive queues to be processed by
the driver in parallel on multiple CPUs. The hardware always puts
packets for an
thanks, queued for 2.6.21
-
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, queued for 2.6.21
-
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/
:
Adrian Bunk (2):
IB/mthca: Make 2 functions static
RDMA/cxgb3: cleanups
Michael S. Tsirkin (1):
IPoIB/cm: Improve small message bandwidth
Roland Dreier (3):
IPoIB: Remove unused local_rate tracking
IB/uverbs: Return correct error for invalid PD in register MR
Add hint that acpi=off doesn't work on IA64.
Would it make sense to add code to detect this and print a kernel
message like
warning: ACPI is always enabled on IA64; ignoring acpi=off
No one reads documentation :)
- R.
-
To unsubscribe from this list: send the line unsubscribe
Looks OK to me, queued for 2.6.21, except:
+#include linux/completion.h
This can just be linux/wait.h, because you're only using
wait_queue_head_t and not struct completion, right?
I fixed this up before merging.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the
Applied, thanks.
-
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/
--- linux.orig/include/asm-x86_64/nmi.h
+++ linux/include/asm-x86_64/nmi.h
@@ -63,7 +63,7 @@ extern int setup_nmi_watchdog(char *);
extern atomic_t nmi_active;
extern unsigned int nmi_watchdog;
-#define NMI_DEFAULT -1
+#define NMI_DEFAULT 0
Maybe I'm missing something obvious,
Great, thanks ... I'm not sure which of the 2 patches fixed things,
but I now got the following trace. I've not really analyzed this, but
it definitely looks like tun_init() is doing something
fishy... (149776 us maximum-latency!!)
- R.
[ 272.392694] tun: Universal TUN/TAP device driver, 1.6
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 a few small post-rc5 fixes. I still
Thanks for resurrecting this. My original email to the CIFS
maintainer got dropped somewhere, but I think this patch is probably
still a good idea.
--
Roland Dreier [EMAIL PROTECTED] GPG Key: 1024D/E0EEFAC0
Fingerprint: A89F B5E9 C185 F34D BD50 4009 37E2 25CC E0EE FAC0
Sending 500KB
I would therefore like to propose that the Linux Foundation register a
PCI ID for use by LANANA ($3000/year), and we set up a LANANA registry
for these device IDs, together with a description of the device
interface each of them expect. Similarly, a Subsystem ID registry can
be used
Obviously, anyone who adheres to the published interface can
use one of these VID:DIDs -- as far as I'm concerned, even
hardware vendors; we'll use the SID to distinguish between
implementations.
I think for this to work, some attempt at a conformance testing
program is
It would be enormously helpful if instead we got say 15 small patch sets
which are independant so that a query or NAK means 14 sets get applied
this time around not zero.
I was thinking about merging the patches together more, but the end result
would not be very readable, and we
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
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
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
1 - 100 of 1691 matches
Mail list logo
