RE: [openib-general] OpenIB and OpenRDMA: Convergence on common RDMAAPIs and ULPs for Linux

"Woodruff, Robert J" <[EMAIL PROTECTED]> wrote on 05/26/2005 05:12:27 PM: > >RNIC-PI is at least an attempt at providing full control over > >both iWARP and IB while making as much common as > >possible. > > Where were you last year when the IB verbs header files/API were being > discussed. > Se

Re: [Rdma-developers] Re: [openib-general] OpenIB and OpenRDMA: Convergence on common RDMA APIs and ULPs for Linux

[EMAIL PROTECTED] wrote on 05/25/2005 09:47:00 PM: > Venkata, > Interesting coincidence: I was talking with someone (at HP) today > who knows substantially more than I do about RNICs. > They indicated RNICs need to manage TCP state on the card from userspace. > I suspect that's only possible thro

[openib-general] RE: registering read-only memory

Title: RE: registering read-only memory R> Are you sure?  It seems to work for me if I just pass write=0 to R> get_user_pages(). I saw this this on Suse 9.3 and the memory was like: static const char *my_string = "Hello world"; defined locally in a function. This produced a VMA with VM_IO se

RE: [openib-general] [PATCHv2][RFC] kDAPL: use cm timers instead of own

>So, here is the strategy I am taking. Please let me know if it is >wrong. > >When dapl_ep_connect() is called, I save off the timeout value into the >dapl_ep struct. Then, when we get ready to call ib_send_cm_req(), I >stuff the timeout value (after munging it into IB's strange format) into >the

[openib-general] [PATCHv2][RFC] kDAPL: use cm timers instead of own

On Tue, 2005-05-24 at 15:00 -0400, James Lentini wrote: > Tom, are you willing to rework the patch to use the CM timeout values? So, here is the strategy I am taking. Please let me know if it is wrong. When dapl_ep_connect() is called, I save off the timeout value into the dapl_ep struct. Then,

Re: [openib-general] RE: registering read-only memory

Grant> Sorry - why do you need the physical address of memory? Grant> Did you mean you need the DMA address? We don't really need the physical address. The userspace verbs do get_user_pages() on a userspace virtual address to get a bunch of struct page *s, and then pass those to dma_map_s

Re: [openib-general] RE: registering read-only memory

On Thu, May 26, 2005 at 10:23:55PM +0300, Eli Cohen wrote: > I'm afraid that won't solve the problem. From some reason the vma of such a > region is flagged with VM_IO and that's why get_user_pages() will fail. We > need to find another way to get the physical address of such memory. Sorry - why d

RE: [openib-general] OpenIB and OpenRDMA: Convergence on common RDMAAPIs and ULPs for Linux

>RNIC-PI is at least an attempt at providing full control over >both iWARP and IB while making as much common as >possible. Where were you last year when the IB verbs header files/API were being discussed. Seems like that was the time to discuss new APIs. Now it is a bit late to propose something

RE: [openib-general] QP sq->tail always = 0

> From: Jeff Carr [mailto:[EMAIL PROTECTED] > Sent: Thursday, May 26, 2005 3:56 PM > > On 05/26/05 14:35, Sean Hefty wrote: > > If the code is based on cmpost, this is likely the case. Cmpost creates > > the QP with IB_SIGNAL_REQ_WR, but does not set the IB_SEND_SIGNALED flag. > > > > Since peopl

Re: [openib-general] OOPS: ib_mad crashery on bootup

Jeff Carr wrote: Just to chim in with the same. I've been able to generate a potentially similar error on bootup. I put the openib svn on top of 2.6.12-rc4-git7. Thanks for the info. I am looking into this. - Sean ___ openib-general mailing list ope

Re: [openib-general] OOPS: ib_mad crashery on bootup

On 05/25/05 10:18, Sean Hefty wrote: I've been able to hit an issue in the MAD layer that might be related. I still do not know the root cause, however. Just to chim in with the same. I've been able to generate a potentially similar error on bootup. I put the openib svn on top of 2.6.12-rc4-g

[openib-general] [ANNOUNCE][PATCH] New Linux 2.6.9 backport patches and corresponding userspace tar ball available

Hal asked if I could send out my latest backport patches for 2.6.9 kernels, so here they are. They are rather big, so I just put them into to SVN where people can get them. The latest ones I have are based on svn2425, but I will try to track the changes in SVN and provide newer updates period

Re: [openib-general] QP sq->tail always = 0

On 05/26/05 14:35, Sean Hefty wrote: If the code is based on cmpost, this is likely the case. Cmpost creates the QP with IB_SIGNAL_REQ_WR, but does not set the IB_SEND_SIGNALED flag. Since people are refering to this as a sample, I will look at changing the code to avoid confusing people. A

Re: [openib-general] QP sq->tail always = 0

On 05/26/05 14:35, Sean Hefty wrote: Roland Dreier wrote: Are you seeing any send completions on the CQ attached to the send queue? No. One possibility is that you're not generating any send completions because you created your CQ with a sq_sig_type of IB_SIGNAL_REQ_WR and then posting se

Re: [openib-general] QP sq->tail always = 0

Roland Dreier wrote: Are you seeing any send completions on the CQ attached to the send queue? One possibility is that you're not generating any send completions because you created your CQ with a sq_sig_type of IB_SIGNAL_REQ_WR and then posting send requests without the IB_SEND_SIGNALED flag.

Re: [openib-general] QP sq->tail always = 0

Jeff> For the server, it first runs: ib_post_recv() for N times Jeff> (N=5 here) Jeff> ib_mthca :09:00.0: SQ 050406 (1 head, 0 tail, 5 max) Jeff> ib_mthca :09:00.0: RQ 050406 (5 head, 0 tail, 5 max) Jeff> ib_mthca :09:00.0: SQ 050406 (2 head, 0 tail, 5 max) Jeff

Re: [openib-general] QP sq->tail always = 0

On 05/26/05 14:17, Jeff Carr wrote: When I run my test, the output for the server and client look similar. For the server, it first runs: ib_post_recv() for N times (N=5 here) sorry s/ib_post_recv/ib_post_send/ ib_mthca :09:00.0: SQ 050406 (1 head, 0 tail, 5 max) ib_mthca :09:00.0:

[openib-general] QP sq->tail always = 0

In my code (based on cmtest) I was using a single CQ for both send and recv. I broke them into seperate queues to try to figure out why I could only do N transfers for each CQ that I created. I added some debugging output to mthca_cq.c to dump out the SQ and RQ for each QP. When I run my tes

[openib-general] Re: registering read-only memory

Eli> I'm afraid that won't solve the problem. From some reason the Eli> vma of such a region is flagged with VM_IO and that's why Eli> get_user_pages() will fail. Are you sure? It seems to work for me if I just pass write=0 to get_user_pages(). - R. _

Re: [openib-general] [PATCH] mthca: cosmetic fix for handle_error_cqe()

Thanks, I cleaned this up even more so we only dump error CQEs for local QP operation errors (we don't really need the see the CQE for other error completions). - R. ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/lis

Re: [openib-general] OpenIB and OpenRDMA: Convergence on common RDMAAPIs and ULPs for Linux

Roland> Yes, that is probably a better way of saying what I was Roland> trying to drive at. There's a significant portion of Roland> kDAPL that doesn't seem necessary or useful to me. For Roland> example, why do we need a new API for posting work Roland> requests? Why do we n

Re: [openib-general] [PATCH] mthca, ibverbs userspace readability

Roland> This patch seems to consist mostly of replacing tabs with Roland> 8 spaces. Why is that an improvement for readability? Bernhard> It does indeed. But with the patch, it's easier to read Bernhard> and code for. Also, there are a couple of fixes for Bernhard> super-long

[openib-general] RE: registering read-only memory

Title: RE: registering read-only memory I'm afraid that won't solve the problem. From some reason the vma of such a region is flagged with VM_IO and that's why get_user_pages() will fail. We need to find another way to get the physical address of such memory. One thing I can think of is implem

Re: [openib-general] Re: registering read-only memory

I just checked in a fix for this. I'm now able to register read-only memory (as long as the permissions on the registration are read-only). - R. ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-genera

[openib-general] Re: registering read-only memory

OK, I think I understand the problem. The compiler puts a string defined with "const char *foo" on a read-only page, but in uverbs_mem.c we always pass write=1 to get_user_pages(). I need to fix the code so that it only asks for writeable pages if we're registering with writable permissions. -

[openib-general] [PATCH 3/3] kDAPL: consolidate dapl_psp*.c into one file

Signed-off-by: Tom Duffy <[EMAIL PROTECTED]> diff -Nurp -X /home/tduffy/dontdiff linux-kernel-rsp/dat-provider/dapl_psp.c linux-kernel-psp/dat-provider/dapl_psp.c --- linux-kernel-rsp/dat-provider/dapl_psp.c1969-12-31 16:00:00.0 -0800 +++ linux-kernel-psp/dat-provider/dapl_psp.c2

Re: [openib-general] [HELP] Encounter Kernel Panic when Add MellanoxHCA Supporting on 2.6.9 Kernel

Hmm, I can't make it happen here unfortunately... I just get the following on 2.6.12-rc5 with CONFIG_DEBUG_SPINLOCK: [ 26.001979] ib_mthca: Mellanox InfiniBand HCA driver v0.06-pre (November 8, 2004) [ 26.026622] ib_mthca: Initializing Mellanox Technologies MT23108 InfiniHost (:04:00.0)

[openib-general] [PATCH 2/3] kDAPL: consolidate dapl_rsp*.c into one file

Signed-off-by: Tom Duffy <[EMAIL PROTECTED]> diff -Nurp -X /home/tduffy/dontdiff linux-kernel-srq/dat-provider/dapl_rsp.c linux-kernel-rsp/dat-provider/dapl_rsp.c --- linux-kernel-srq/dat-provider/dapl_rsp.c1969-12-31 16:00:00.0 -0800 +++ linux-kernel-rsp/dat-provider/dapl_rsp.c2

[openib-general] [PATCH 1/3] kDAPL: consolidate dapl_srq*.c into one file

Signed-off-by: Tom Duffy <[EMAIL PROTECTED]> Index: linux-kernel-srq/dat-provider/dapl_srq.c === --- linux-kernel-srq/dat-provider/dapl_srq.c(revision 0) +++ linux-kernel-srq/dat-provider/dapl_srq.c(revision 0) @@ -0,0 +1,500

[openib-general] Re: umad abi 2 v 3 and multicast join failed

Quoting r. Roland Dreier <[EMAIL PROTECTED]>: > Subject: Re: umad abi 2 v 3 and multicast join failed > > Michael> Actually, it would be quite useful if whatever is > Michael> submitted to mainline is kept on some subversion branch, > Michael> too. Roland - would that disrupt your dev

Re: [openib-general] umad abi 2 v 3 and multicast join failed

On Wed, 2005-05-25 at 19:06, Troy Benjegerdes wrote: > I was running a crufty version of opensm (compiled from the > roland-uverbs branch), and I started getting these kinds of errors for > no apparent reason: > > ib0: multicast join failed for ff12:401b::0:0:0::, status > -22 > ib0: m

Re: [openib-general] OpenIB and OpenRDMA: Convergence on common RDMA APIs and ULPs for Linux

At 09:49 AM 5/26/2005, Sean Hefty wrote: Roland Dreier wrote: I believe the way forward is to evolve the existing drivers/infiniband code already in Linux into a drivers/rdma that supports both IB and RNICs.  To be extremely blunt, I believe the RNIC-PI is irrelevant to the Linux kernel -- no IB

Re: [openib-general] OpenIB and OpenRDMA: Convergence on common RDMAAPIs and ULPs for Linux

At 09:42 AM 5/26/2005, Bernhard Fischer wrote: On Thu, May 26, 2005 at 09:25:27AM -0700, Caitlin Bestler wrote: >The current OpenIB structure is, not surprisingly, tremendously >IB-centric. Any attempt to implement an iWARP RNIC through >them will have to go through several layers of obfuscation.

Re: [Rdma-developers] RE: [openib-general] OpenIB and OpenRDMA: Convergence on common RDMAAPIs and ULPs for Linux

At 09:29 AM 5/26/2005, Talpey, Thomas wrote: At 11:49 AM 5/26/2005, Bob Woodruff wrote: >Finally, until there is some consensus about allowing TCP offload in Linux, >I see no need to start to hack up the InfiniBand stack to support iWarp. It is not a requirement that TCP offload be supported in

RE: [openib-general] OpenIB and OpenRDMA: Convergence on common RDMAAPIs and ULPs for Linux

>You're absolutely right that the IB core didn't start out that way. >However, it seems better in the long run to fix it rather than just >piling another layer on top to hide problems. >- R. I think that perhaps Sean's suggestion of having some RNIC vendor implement a verbs driver for their H/W

Re: [openib-general] [PATCH] mthca, ibverbs userspace readability

On Thu, May 26, 2005 at 06:58:19PM +0200, Bernhard Fischer wrote: > On Thu, May 26, 2005 at 09:29:17AM -0700, Roland Dreier wrote: > >Bernhard> - improve readability of mthca and ibverbs headers > >Bernhard> installed to userspace. > > > >This patch seems to consist mostly of replacing tabs

Re: [openib-general] [PATCH] mthca, ibverbs userspace readability

On Thu, May 26, 2005 at 06:47:07PM +0200, Bernhard Fischer wrote: > On Thu, May 26, 2005 at 09:29:17AM -0700, Roland Dreier wrote: > >Bernhard> - improve readability of mthca and ibverbs headers > >Bernhard> installed to userspace. > > > >This patch seems to consist mostly of replacing tabs

Re: [openib-general] OpenIB and OpenRDMA: Convergence on common RDMAAPIs and ULPs for Linux

Sean> My personal view is that any higher level abstractions could Sean> combine common functionality or simplify the interface, Sean> possibly with a loss of lower level control. For example, Sean> an interface could be created that allowed the user to Sean> operate with more

Re: [openib-general] OpenIB and OpenRDMA: Convergence on common RDMAAPIs and ULPs for Linux

Robert> The InfiniBand core mid-layer is infiniband specific. I Robert> don't think it was intended to be an RDMA device Robert> independent layer. kDAPL was intended to be that layer. You're absolutely right that the IB core didn't start out that way. However, it seems better in the l

Re: [openib-general] OpenIB and OpenRDMA: Convergence on common RDMAAPIs and ULPs for Linux

Roland Dreier wrote: Bob> There is already a RDMA device independent API being Bob> developed for the kernel by people on this list. It is Bob> starting with the kDAPL code base, which was designed to Bob> support both IBA and iWarp devices. I believe kDAPL-based layers are an OK

Re: [openib-general] [PATCH] mthca, ibverbs userspace readability

On Thu, May 26, 2005 at 09:29:17AM -0700, Roland Dreier wrote: >Bernhard> - improve readability of mthca and ibverbs headers >Bernhard> installed to userspace. > >This patch seems to consist mostly of replacing tabs with 8 spaces. >Why is that an improvement for readability? It does indeed

Re: [openib-general] OpenIB and OpenRDMA: Convergence on common RDMA APIs and ULPs for Linux

Roland Dreier wrote: I believe the way forward is to evolve the existing drivers/infiniband code already in Linux into a drivers/rdma that supports both IB and RNICs. To be extremely blunt, I believe the RNIC-PI is irrelevant to the Linux kernel -- no IB vendors will support ripping out a workin

Re: [openib-general] [PATCH] mthca, ibverbs userspace readability

On Thu, May 26, 2005 at 09:29:17AM -0700, Roland Dreier wrote: >Bernhard> - improve readability of mthca and ibverbs headers >Bernhard> installed to userspace. > >This patch seems to consist mostly of replacing tabs with 8 spaces. >Why is that an improvement for readability? care to read o

RE: [openib-general] OpenIB and OpenRDMA: Convergence on common RDMAAPIs and ULPs for Linux

Roland wrote, >I believe kDAPL-based layers are an OK short-term solution, but I >don't think anything like this should be proposed for merging in the >Linus kernel. If we need another abstraction layer on top of our >existing abstraction layer, that just says to me that we should fix >the curre

Re: [openib-general] OpenIB and OpenRDMA: Convergence on common RDMAAPIs and ULPs for Linux

On Thu, May 26, 2005 at 09:25:27AM -0700, Caitlin Bestler wrote: >The current OpenIB structure is, not surprisingly, tremendously >IB-centric. Any attempt to implement an iWARP RNIC through >them will have to go through several layers of obfuscation. > >States do not match. Error codes do not match

RE: [openib-general] OpenIB and OpenRDMA: Convergence on common RDMAAPIs and ULPs for Linux

At 11:49 AM 5/26/2005, Bob Woodruff wrote: >Finally, until there is some consensus about allowing TCP offload in Linux, >I see no need to start to hack up the InfiniBand stack to support iWarp. It is not a requirement that TCP offload be supported in order to support iWARP. Upper layers which do

Re: [openib-general] OpenIB and OpenRDMA: Convergence on common RDMAAPIs and ULPs for Linux

Bob> There is already a RDMA device independent API being Bob> developed for the kernel by people on this list. It is Bob> starting with the kDAPL code base, which was designed to Bob> support both IBA and iWarp devices. I believe kDAPL-based layers are an OK short-term solution, b

Re: [openib-general] OpenIB and OpenRDMA: Convergence on common RDMAAPIs and ULPs for Linux

Caitlin> Is there a real willingness in OpenIB to make a transport Caitlin> neutral verb layer? Has anyone even *read* the RNIC-PI Caitlin> for substance rather than "pure Linux" debating points? There is definitely a willingness to consider thoroughly all changes proposed by the RNIC

Re: [openib-general] [PATCH] mthca, ibverbs userspace readability

Bernhard> - improve readability of mthca and ibverbs headers Bernhard> installed to userspace. This patch seems to consist mostly of replacing tabs with 8 spaces. Why is that an improvement for readability? Thanks, Roland ___ openib-general ma

Re: [openib-general] Re: umad abi 2 v 3 and multicast join failed

Troy> What's the status on getting ABI ver 3 into 2.6.1X ? Not submitted -- 2.6.12 is far too deep into the freeze phase to make a change like this. Once 2.6.13 opens up, we'll merge the pending MAD changes at least. - R. ___ openib-general mailin

[openib-general] Re: umad abi 2 v 3 and multicast join failed

Michael> Actually, it would be quite useful if whatever is Michael> submitted to mainline is kept on some subversion branch, Michael> too. Roland - would that disrupt your development Michael> process a lot? It's a bit of a pain to get started but perhaps it would be useful to hav

Re: [openib-general] OpenIB and OpenRDMA: Convergence on common RDMAAPIs and ULPs for Linux

The current OpenIB structure is, not surprisingly, tremendously IB-centric. Any attempt to implement an iWARP RNIC through them will have to go through several layers of obfuscation. States do not match. Error codes do not match. Completion Statuses do not match. There is a lot of information that

RE: [openib-general] OpenIB and OpenRDMA: Convergence on common RDMAAPIs and ULPs for Linux

Venkat wrote, >Absolutely and this is exactly what I would like to see without impacting >the IB development but supporting common ULPs is critical. >Thanks >Venkat Great, the best way to influence the code is to send in patches to the list and then discuss them. James is currently coordin

Re: [openib-general] Re: umad abi 2 v 3 and multicast join failed

On Thu, May 26, 2005 at 10:29:09AM +0300, Michael S. Tsirkin wrote: > Quoting r. Grant Grundler <[EMAIL PROTECTED]>: > > Subject: Re: umad abi 2 v 3 and multicast join failed > > > > On Wed, May 25, 2005 at 09:07:25PM -0700, Roland Dreier wrote: > > > In general, given that kernels 2.6.11 and 2.6.

[openib-general] [PATCH] mthca, ibverbs userspace readability

Hi, No object code changes. linux-kernel/infiniband/ulp/sdp/sdp_conn.c |1 userspace/libibverbs/include/infiniband/driver.h | 34 +- userspace/libibverbs/include/infiniband/kern-abi.h |2 userspace/libibverbs/include/infiniband/verbs.h| 253 ++--- userspace

RE: [openib-general] OpenIB and OpenRDMA: Convergence on common RDMAAPIs and ULPs for Linux

"Bob Woodruff" <[EMAIL PROTECTED]> wrote on 05/26/2005 08:49:59 AM: >  Venkat>  I would like to start a discussion around the convergence of RDMA > APIs and ULPs >  Venkat>  between OpenIB and OpenRDMA projects. > > Once the RNIC people have a mid-layer that interfaces with the RDMA API > (kDA

RE: [openib-general] OpenIB and OpenRDMA: Convergence on common RDMAAPIs and ULPs for Linux

Venkat> I would like to start a discussion around the convergence of RDMA APIs and ULPs Venkat> between OpenIB and OpenRDMA projects. There is already a RDMA device independent API being developed for the kernel by people on this list. It is starting with the kDAPL code base, which was design

Re: [Rdma-developers] Re: [openib-general] OpenIB and OpenRDMA: Convergence on common RDMA APIs and ULPs for Linux

[EMAIL PROTECTED] wrote on 05/26/2005 04:33:46 AM: > On Wed, May 25, 2005 at 11:20:14PM -0700, Venkata Jagana wrote: > > I would like to really understand the technical reasons why you say > > RNIC-PI is irrelevant to Linux kernel. > > RNIC-PI is developed to support not only the RNICs  but it is

Re: [openib-general] OpenIB and OpenRDMA: Convergence on common RDMA APIs and ULPs for Linux

At 08:45 AM 5/26/2005, Christoph Hellwig wrote: >>> >The sf.net mail archives are too f*d up to allow retrieving >attachments. Here it is again... My opinions/assertions only, presented at the April OpenRDMA f2f. Tom.

[openib-general] [PATCH] mthca: cosmetic fix for handle_error_cqe()

Hi, - remove unneeded if-condition in mthca's cq error path Signed-off-by: Bernhard Fischer <[EMAIL PROTECTED]> diff -X excl -rduNp gen2.2423.oorig/trunk/src/linux-kernel/infiniband/hw/mthca/mthca_cq.c gen2.2423/trunk/src/linux-kernel/infiniband/hw/mthca/mthca_cq.c --- gen2.2423.oorig/trunk/sr

Re: [openib-general] OpenIB and OpenRDMA: Convergence on common RDMA APIs and ULPs for Linux

On Thu, May 26, 2005 at 08:27:40AM -0400, Talpey, Thomas wrote: > * > > The sf.net mail archives are too fucked up to allow retrieving attachments. ___ openib-general ma

Re: [openib-general] OpenIB and OpenRDMA: Convergence on common RDMA APIs and ULPs for Linux

At 02:20 AM 5/26/2005, Venkata Jagana wrote: >I would like to really understand the technical reasons why you say RNIC-PI is >irrelevant to Linux kernel. >RNIC-PI is developed to support not only the RNICs but it is also IB >compatible. I'm not Roland, but my belief is that until RNIC-PI exists

Re: [openib-general] umad abi 2 v 3 and multicast join failed

On Thu, 2005-05-26 at 00:07, Roland Dreier wrote: > Troy> warn: [24878] umad_init: wrong ABI version: > Troy> /sys/class/infiniband_mad/abi_version is 2 but library ABI > Troy> is 3 > > Hal> Right. This is old OpenSM (actually old libibumad) with the > Hal> latest from OpenIB s

Re: [openib-general] OpenIB and OpenRDMA: Convergence on common RDMA APIs and ULPs for Linux

On Wed, May 25, 2005 at 11:20:14PM -0700, Venkata Jagana wrote: > I would like to really understand the technical reasons why you say > RNIC-PI is irrelevant to Linux kernel. > RNIC-PI is developed to support not only the RNICs but it is also IB > compatible. This interface is > something that is

Re: [openib-general] OpenIB and OpenRDMA: Convergence on common RDMA APIs and ULPs for Linux

On Wed, May 25, 2005 at 06:38:36PM -0700, Venkata Jagana wrote: > However, we also have a challenge to address in implementing these common > ULPs and APIs > since OpenIB is currently using verbs PI for Linux defined through an open > source process and > OpenRDMA is currently defining RNIC-PI (sup

[openib-general] Question about APM in openib gen1

Hi. I have tested APM in openib gen1 sources, but can not succssfully. I have two node, the node 1 has one cable link to switch and the node 2 has two cable to switch. When establishing connection using CM, the node 2 is the listen server, and the node 1 is the client. After connection established

[openib-general] Re: umad abi 2 v 3 and multicast join failed

Quoting r. Grant Grundler <[EMAIL PROTECTED]>: > Subject: Re: umad abi 2 v 3 and multicast join failed > > On Wed, May 25, 2005 at 09:07:25PM -0700, Roland Dreier wrote: > > In general, given that kernels 2.6.11 and 2.6.12 are shipping with ABI > > version 2, does it make sense to avoid problems l

RE: [openib-general] [HELP] Encounter Kernel Panic when Add MellanoxHCA Supporting on 2.6.9 Kernel

Dear Woody & Roland I downloaded the newest firmware and updated the system with it. Now it works. Kernel can be booted and module can be loaded successfully. Thanks for your great help. It is very useful to me. Thanks - Lenber -Original Message- From: Roland Dreier [mailto:[EMAIL PROTECT