[ofa-general] ofa_1_3_kernel 20071004-0200 daily build status
This email was generated automatically, please do not reply git_url: git://git.openfabrics.org/ofed_1_3/linux-2.6.git git_branch: ofed_kernel Common build parameters: --with-ipoib-mod --with-sdp-mod --with-srp-mod --with-user_mad-mod --with-user_access-mod --with-mthca-mod --with-mlx4-mod --with-core-mod --with-addr_trans-mod --with-rds-mod --with-cxgb3-mod --with-nes-mod Passed: Passed on i686 with 2.6.15-23-server Passed on i686 with linux-2.6.22 Passed on i686 with linux-2.6.21.1 Passed on i686 with linux-2.6.18 Passed on i686 with linux-2.6.17 Passed on i686 with linux-2.6.16 Passed on i686 with linux-2.6.19 Passed on i686 with linux-2.6.14 Passed on i686 with linux-2.6.13 Passed on i686 with linux-2.6.15 Passed on i686 with linux-2.6.12 Passed on x86_64 with linux-2.6.20 Passed on x86_64 with linux-2.6.18 Passed on x86_64 with linux-2.6.12 Passed on x86_64 with linux-2.6.16 Passed on powerpc with linux-2.6.14 Passed on ppc64 with linux-2.6.16 Passed on ppc64 with linux-2.6.18 Passed on powerpc with linux-2.6.15 Passed on powerpc with linux-2.6.12 Passed on ppc64 with linux-2.6.15 Passed on x86_64 with linux-2.6.19 Passed on x86_64 with linux-2.6.13 Passed on ppc64 with linux-2.6.12 Passed on x86_64 with linux-2.6.17 Passed on ppc64 with linux-2.6.19 Passed on powerpc with linux-2.6.13 Passed on ia64 with linux-2.6.17 Passed on ia64 with linux-2.6.13 Passed on ia64 with linux-2.6.12 Passed on x86_64 with linux-2.6.14 Passed on ia64 with linux-2.6.15 Passed on x86_64 with linux-2.6.21.1 Passed on ppc64 with linux-2.6.13 Passed on ppc64 with linux-2.6.14 Passed on x86_64 with linux-2.6.22 Passed on ppc64 with linux-2.6.17 Passed on ia64 with linux-2.6.18 Passed on ia64 with linux-2.6.14 Passed on ia64 with linux-2.6.19 Passed on ia64 with linux-2.6.16 Passed on x86_64 with linux-2.6.16.21-0.8-smp Passed on x86_64 with linux-2.6.15 Passed on x86_64 with linux-2.6.16.43-0.3-smp Passed on x86_64 with linux-2.6.18-8.el5 Passed on x86_64 with linux-2.6.9-42.ELsmp Passed on x86_64 with linux-2.6.9-22.ELsmp Passed on x86_64 with linux-2.6.9-55.ELsmp Passed on ia64 with linux-2.6.22 Passed on ia64 with linux-2.6.16.21-0.8-default Passed on x86_64 with linux-2.6.18-1.2798.fc6 Passed on ia64 with linux-2.6.21.1 Passed on ppc64 with linux-2.6.18-8.el5 Passed on x86_64 with linux-2.6.9-34.ELsmp Failed: Build failed on powerpc with linux-2.6.18 Log: /home/vlad/tmp/ofa_1_3_kernel-20071004-0200_linux-2.6.18_powerpc_check/drivers/infiniband/hw/ehca/ehca_main.c:936: error: invalid type argument of '-' /home/vlad/tmp/ofa_1_3_kernel-20071004-0200_linux-2.6.18_powerpc_check/drivers/infiniband/hw/ehca/ehca_main.c:939: error: invalid type argument of '-' /home/vlad/tmp/ofa_1_3_kernel-20071004-0200_linux-2.6.18_powerpc_check/drivers/infiniband/hw/ehca/ehca_main.c:940: error: invalid type argument of '-' make[4]: *** [/home/vlad/tmp/ofa_1_3_kernel-20071004-0200_linux-2.6.18_powerpc_check/drivers/infiniband/hw/ehca/ehca_main.o] Error 1 make[3]: *** [/home/vlad/tmp/ofa_1_3_kernel-20071004-0200_linux-2.6.18_powerpc_check/drivers/infiniband/hw/ehca] Error 2 make[2]: *** [/home/vlad/tmp/ofa_1_3_kernel-20071004-0200_linux-2.6.18_powerpc_check/drivers/infiniband] Error 2 make[1]: *** [_module_/home/vlad/tmp/ofa_1_3_kernel-20071004-0200_linux-2.6.18_powerpc_check] Error 2 make[1]: Leaving directory `/home/vlad/kernel.org/powerpc/linux-2.6.18' make: *** [kernel] Error 2 -- Build failed on powerpc with linux-2.6.19 Log: /home/vlad/tmp/ofa_1_3_kernel-20071004-0200_linux-2.6.19_powerpc_check/drivers/infiniband/hw/ehca/ehca_main.c:936: error: invalid type argument of '-' /home/vlad/tmp/ofa_1_3_kernel-20071004-0200_linux-2.6.19_powerpc_check/drivers/infiniband/hw/ehca/ehca_main.c:939: error: invalid type argument of '-' /home/vlad/tmp/ofa_1_3_kernel-20071004-0200_linux-2.6.19_powerpc_check/drivers/infiniband/hw/ehca/ehca_main.c:940: error: invalid type argument of '-' make[4]: *** [/home/vlad/tmp/ofa_1_3_kernel-20071004-0200_linux-2.6.19_powerpc_check/drivers/infiniband/hw/ehca/ehca_main.o] Error 1 make[3]: *** [/home/vlad/tmp/ofa_1_3_kernel-20071004-0200_linux-2.6.19_powerpc_check/drivers/infiniband/hw/ehca] Error 2 make[2]: *** [/home/vlad/tmp/ofa_1_3_kernel-20071004-0200_linux-2.6.19_powerpc_check/drivers/infiniband] Error 2 make[1]: *** [_module_/home/vlad/tmp/ofa_1_3_kernel-20071004-0200_linux-2.6.19_powerpc_check] Error 2 make[1]: Leaving directory `/home/vlad/kernel.org/powerpc/linux-2.6.19' make: *** [kernel] Error 2 -- Build failed on powerpc with linux-2.6.17 Log: /home/vlad/tmp/ofa_1_3_kernel-20071004-0200_linux-2.6.17_powerpc_check/drivers/infiniband/hw/ehca/ehca_main.c:936: error: invalid type argument of '-' /home/vlad/tmp/ofa_1_3_kernel-20071004-0200_linux-2.6.17_powerpc_check/drivers/infiniband/hw/ehca/ehca_main.c:939: error: invalid
[ofa-general] ***SPAM*** Türk Patent Enstitüsü ve Moğo listan Fikri Mülkiyet Ofisi Dayanışması
Türk Patent Enstitüsü ve Moğolistan Fikri Mülkiyet Ofisi Dayanışması Türk Patent Enstitüsü (TPE) ve Moğolistan Fikri Mülkiyet Ofisi (IPOM) arasındaki teknik işbirliği görüşmeleri 21-23 Ağustos 2007 tarihlerinde Moğolistan'ın Ulan Batur şehrinde gerçekleştirildi. IPOM personelinin coğrafi işaretler ve enformasyon faaliyetleri eğitimi, TPE eş-başkanlığında yürütülmekte olan İslam Konferansı Teşkilatı Projesi ve Ekonomik İşbirliği Örgütü altında düzenlenebilecek eğitimlere Moğolistan'ın da katılımını öngören bir faaliyet planı oluşturuldu.Kaynak: TPE Time'ın Değerlendirdiği 2006 Yılının En İyi Cihazları Time'ın değerlendirmelerine göre, 2006 yılının en iyi 8 cihazı; Logitech VX, Sanyo HDI Digital Media, Apple Macbook Pro, Nintendo DS Lite, Logitech Wireless DJ, Nike + ipod sport kid, Garmin Street Pilot c550 ve Palm Treo 700W yer almakta. Kaynak: time.com İstanbul Büyükşehir Belediyesi, Kentin Elektronik Haritasını Çıkarttı! İstanbulluların www.sehirrehberi.ibb.gov.tr internet adresinden ulaşabilecekleri rehberde turistik ve tarihi mekanlar, adres bilgileri, nöbetçi eczaneler, yol durumu gibi çok sayıda merak edilen konuya ulaşılabiliyor. Ayrıca İstanbul'un uydu ve hava fotoğraflarıda bulunmakta. İstanbullular bu sanal rehberden trafik kazası, yangın, sel, kapalı yol ve yol daraltması gibi son gelişmeleride sıcağı sıcağına takip edebilecekler. Bu buuml;ltenleri almak istemiyorsan1z [EMAIL PROTECTED] adresine bo_ bir mail gouml;ndermenizi rica ederiz. Bouml;yle bir talebiniz olmad1 1 suuml;rece duuml;zenli olarak buuml;ltenlerimizi alabilirsiniz. NETMARK PATENT T:0212 220 31 20 F:0212 220 74 21 ___ general mailing list general@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
Re: [ofa-general] iSER data corruption issues
At 11:09 PM 10/3/2007, Roland Dreier wrote: ... It just keeps a list of FMRs that are available to remap, and batches up the unregistration. It is true that an R_Key may remain valid after an FMR is unmapped, but that's the whole point of FMRs: if you don't batch up the real flushing to amortize the cost, they're no better than regular MRs really. This is an aside, but in my experience the FMR is actually a win even if it's invalidated after each use. In testing with NFS/RDMA, I believe that direct FMR manipulation via ib_map_phys_mr()/ib_unmap_fmr() was worth somewhere on the order of 35% over straight ib_reg_phys_mr()/ib_dereg_mr(). I can only assume this was because the TPT-entry setup (ib_alloc_fmr()) is avoided on a per-I/O basis. As for the pools not invalidating the R_key/handle. Speaking as a storage provider, we take data integrity darn seriously. It's my opinion that a dynamic registration scheme that doesn't include per-I/O protection is pretty much not the point of dynamic registration. In many environments however, the performance tradeoff is important - this is why I prefer an all-physical scheme to FMRs, even though it requires additional RDMA ops to handle the resulting extra scatter/gather. Additionally, FMRs don't provide byte-range protection granularity, and they're not supported by iWARP hardware (plus they're buggy as heck on early Tavors, etc). So I didn't make them a default. Tom. ___ general mailing list general@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
[ofa-general] Fwd: [NFS] What's slated for inclusion in 2.6.24-rc1 from the NFS client git tree...
I'm happy to forward this note from Trond that the NFS/RDMA kernel client will be available in the mainline after the 2.6.24-rcX process begins, among other NFS improvements of course. There is a new nfs-aware mount command required to actually invoke an NFS/RDMA mount. The easiest way to accomplish this is to fetch the latest nfs-utils from git://linux-nfs.org/nfs-utils and to invoke the mount.nfs binary directly. I'll forward more details later. Tom. -- Forwarded Message -- From: Trond Myklebust [EMAIL PROTECTED] To: [EMAIL PROTECTED], Andrew Morton [EMAIL PROTECTED] Date: Wed, 03 Oct 2007 19:41:16 -0400 Cc: [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: [NFS] What's slated for inclusion in 2.6.24-rc1 from the NFS client git tree... List-Id: Discussion of NFS under Linux development, interoperability, and testing. nfs.lists.sourceforge.net List-Archive: http://sourceforge.net/mailarchive/forum.php?forum_name=nfs List-Post: mailto:[EMAIL PROTECTED] List-Help: mailto:[EMAIL PROTECTED] List-Subscribe: https://lists.sourceforge.net/lists/listinfo/nfs, mailto:[EMAIL PROTECTED] Sender: [EMAIL PROTECTED] Aside from the usual updates from Chuck for NFS-over-IPv6 (still incomplete) and a number of bugfixes for the text-based mount code, the main news in the NFS tree is the merging of support for the NFS/RDMA client code from Tom Talpey and the NetApp New England (NANE) team. We also have the 64-bit inode support from RedHat/Peter Staubach. There is also the addition of a nfs_vm_page_mkwrite() method in order to clean up the mmap() write code. Finally, I've been working on a number of updates for the attribute revalidation, having pulled apart most of the dentry and attribute revalidation into separate variables. A number of fixes that address existing bugs fell out of that review, which should hopefully result in more efficient dcache behaviour... The NFS client git tree can be found at git://git.linux-nfs.org/pub/linux/nfs-2.6.git or on gitweb at http://linux-nfs.org/cgi-bin/gitweb.cgi?p=nfs-2.6.git;a=summary Finally, a full set of patches may be found on http://client.linux-nfs.org/Linux-2.6.x/2.6.23-rc9/ Cheers Trond --- Adrian Bunk (1): [2.6 patch] net/sunrpc/rpcb_clnt.c: make struct rpcb_program static Christoph Hellwig (1): [NFS] [PATCH] nfs: tiny makefile cleanup Chuck Lever (41): SUNRPC: Fix a signed v. unsigned comparison in rpcbind's XDR routines SUNRPC: Fix a signed v. unsigned comparison in net/sunrpc/xprtsock.c SUNRPC: Use standard macros for printing IP addresses SUNRPC: Free address buffers in a loop SUNRPC: Add hex-formatted address support to rpc_peeraddr2str() SUNRPC: Rename xs_format_peer_addresses SUNRPC: add a function to format IPv6 addresses SUNRPC: add support for IPv6 to the kernel's rpcbind client SUNRPC: Introduce support for setting the port number in IPv6 addresses SUNRPC: Rename xs_bind() to prepare for IPv6-specific bind method SUNRPC: create an IPv6-savvy mechanism for binding to a reserved port SUNRPC: Refactor a part of socket connect logic into a helper function SUNRPC: Rename IPv4 connect workers SUNRPC: create connect workers for IPv6 SUNRPC: Add IPv6 address support to net/sunrpc/xprtsock.c SUNRPC: Add a helper for extracting the address using the correct type SUNRPC: Split xs_reclassify_socket into an IPv4 and IPv6 version SUNRPC: Add support for formatted universal addresses SUNRPC: Fix generation of universal addresses for SUNRPC: Only one dprintk is needed during client creation SUNRPC: fix a signed v. unsigned comparison nit in rpc_bind_new_program SUNRPC: Use correct argument type in memcpy() SUNRPC: Make sure server name is reasonable before trying to print it SUNRPC: Clean up in rpc_show_tasks SUNRPC: Make rpcb_decode_getaddr more picky about universal addresses SUNRPC: Retry bad rpcbind replies SUNRPC: Add a new error code for retry waiting for another binder SUNRPC: Split another new rpcbind retry error code from EACCES SUNRPC: RPC bind failures should be permanent for NULL requests NFS: Kernel mount client should use async bind NFS: Add new 'mountaddr=' mount option NFS: Convert printk's to dprintk's in fs/nfs/nfs?xdr.c LOCKD: Convert printk's to dprintk's in lockd XDR routines NFSD: Convert printk's to dprintk's in NFSD's nfs4xdr NFS: Verify server address before invoking in-kernel mount client NFS: Show nointr mount option SUNRPC: Fix bytes-per-op accounting for RPC over UDP NFS: Don't call nfs_renew_times() in nfs_dentry_iput() NFS: Eliminate nfs_renew_times() NFS: Eliminate nfs_refresh_verifier() SUNRPC: Use correct type in buffer length calculations Fabio Olive Leite (1): Re: [NFS] [PATCH] Attribute timeout handling
Re: [ofa-general] iSER data corruption issues
[EMAIL PROTECTED] wrote on Wed, 03 Oct 2007 15:01 -0700: Machines are opteron, fedora 7 up-to-date with its openfab libs, kernel 2.6.23-rc6 on target. Either 2.6.23-rc6 or 2.6.22 or 2.6.18-rhel5 on initiator. For some reason, it is much easier to produce with the rhel5 kernel. There was a bug in mthca that caused data corruption with FMRs on Sinai (1-port PCIe) HCAs. It was fixed in commit 608d8268 (IB/mthca: Fix data corruption after FMR unmap on Sinai) which went in shortly before 2.6.21 was released. I don't know if the RHEL5 2.6.18 kernel has this fix or not -- but if you still see the problem on 2.6.22 and later kernels then this isn't the fix anyway. This is definitely it. Same test setup runs for an hour with this patch, but fails in tens of seconds without it. Thanks for pointing it out. This rhel5 kernel is 2.6.18-8.1.6. Perhaps there are newer ones about that have this critical patch included. I'm going to add a Big Fat Warning on the iser distribution about pre-2.6.21 kernels. It also crashes if the iSER connection drops in a certain easy-to-reproduce way, another reason to avoid it. Regarding the larger test I talked about that fails even on modern kernels, I'm still not able to reproduce that on my setup. I ran it literally all night with a hacked target that calculated the return buffer rather than accessing the disk. For now I'm calling that a separate bug and will investigate it further. Thanks to Tom and Tom for helping debug this. -- Pete ___ general mailing list general@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
Re: [ofa-general] iSER data corruption issues
[EMAIL PROTECTED] wrote on Thu, 04 Oct 2007 07:55 -0400: This is an aside, but in my experience the FMR is actually a win even if it's invalidated after each use. In testing with NFS/RDMA, I believe that direct FMR manipulation via ib_map_phys_mr()/ib_unmap_fmr() was worth somewhere on the order of 35% over straight ib_reg_phys_mr()/ib_dereg_mr(). I can only assume this was because the TPT-entry setup (ib_alloc_fmr()) is avoided on a per-I/O basis. As for the pools not invalidating the R_key/handle. Speaking as a storage provider, we take data integrity darn seriously. It's my opinion that a dynamic registration scheme that doesn't include per-I/O protection is pretty much not the point of dynamic registration. In many environments however, the performance tradeoff is important - this is why I prefer an all-physical scheme to FMRs, even though it requires additional RDMA ops to handle the resulting extra scatter/gather. Ack. Unfortunately in the iSER case, we are limited to a single virtual address per command. Page size fragmentation may destroy performance, even with heavy pipelining. -- Pete Additionally, FMRs don't provide byte-range protection granularity, and they're not supported by iWARP hardware (plus they're buggy as heck on early Tavors, etc). So I didn't make them a default. ___ general mailing list general@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
Re: [ofa-general] iSER data corruption issues
On Thu, 2007-10-04 at 12:14 -0400, Pete Wyckoff wrote: [EMAIL PROTECTED] wrote on Wed, 03 Oct 2007 15:01 -0700: Machines are opteron, fedora 7 up-to-date with its openfab libs, kernel 2.6.23-rc6 on target. Either 2.6.23-rc6 or 2.6.22 or 2.6.18-rhel5 on initiator. For some reason, it is much easier to produce with the rhel5 kernel. There was a bug in mthca that caused data corruption with FMRs on Sinai (1-port PCIe) HCAs. It was fixed in commit 608d8268 (IB/mthca: Fix data corruption after FMR unmap on Sinai) which went in shortly before 2.6.21 was released. I don't know if the RHEL5 2.6.18 kernel has this fix or not -- but if you still see the problem on 2.6.22 and later kernels then this isn't the fix anyway. This is definitely it. Same test setup runs for an hour with this patch, but fails in tens of seconds without it. Thanks for pointing it out. This rhel5 kernel is 2.6.18-8.1.6. Perhaps there are newer ones about that have this critical patch included. I'm going to add a Big Fat Warning on the iser distribution about pre-2.6.21 kernels. It also crashes if the iSER connection drops in a certain easy-to-reproduce way, another reason to avoid it. Regarding the larger test I talked about that fails even on modern kernels, I'm still not able to reproduce that on my setup. I ran it literally all night with a hacked target that calculated the return buffer rather than accessing the disk. For now I'm calling that a separate bug and will investigate it further. Thanks to Tom and Tom for helping debug this. Thanks to Roland who actually knew what it was ... ;-) -- Pete ___ general mailing list general@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general ___ general mailing list general@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
[ofa-general] Re: [PATCH 2 of 3 for-2.6.24] mlx4: always fill MTTs from CPU
+/* Reserved mtt entries must be aligned up to a cacheline boundary, + * since the FW will write to them, while the driver writes to all + * other mtt entries. (Note that the variable dev-caps.mtt_entry_sz + * below is really the mtt segment size, not the raw entry size) + */ +num_mtt_res_bytes = ((dev-caps.reserved_mtts * + (dev-caps.mtt_entry_sz / MLX4_MTT_ENTRY_PER_SEG) + + L1_CACHE_BYTES - 1) / + L1_CACHE_BYTES) * L1_CACHE_BYTES; Shouldn't this be dma_get_cache_alignment() instead of L1_CACHE_BYTES (which would match what mthca does)? - R. ___ general mailing list general@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
[ofa-general] Issues to scale to 64K ranks.
When talking to run 64K processes, I noticed that, on connectX with 2.2 firmware, ibv_devinfo only shows: max_qp: 65472, that means we can not create 65536 QPs on this HCA, Is this max_qp on per process basis, or per HCA basis ? How to increase this number ? any hardware/firmwire change needed ? Thanks. ___ general mailing list general@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
[ofa-general] ***SPAM*** HELLO
My dear, I am miss Angela from Asmara, Eritrea, single and 21 years old . Immediately after going through your profile i made up my mind to contact you for long term relationship, because you are my choice of trust and i see nothing wrong with the choice that i have made in you. Now that i am in a state of absolute confussion I must let you know that my daddy was the Financial controler to the Common Wealth North African Region.The following information is my purpose of chosing you. My daddy was killed by unidentified family enemies and my daddy's lawyer and my daddy's brother are among the suspects, they are all against me because of my daddy's properties in Eritrea. Before my daddy died he made me the beneficiary of the amount of 14.5 Million gbp£ in his account with Citi Bank in Dakar, Senegal, i have the bank statement of account in my travelling bag in this prison. on my way travelling to dakar, senegal i arrived this gambia on transit, on the same night i arrived Gambia i was attacked by 2 big boys in my guest house (hotel) room, they robbed me, collected my hand bag that contained all my money, as if that was not enough, they tried to rape me so i collected the nearest object in the room and hit one of them on the head and screamed to the hearing of the neighbouring compounds and people came out and decended on the criminals, the next morning the police came to the guest house and arrested me, since then i have been kept under awaiting trial here in this central prison of Gambia because the criminal i heated died as a result of the severe beating given to him by the neighbourhood. I am among the girls newly appointed to head the girls sector in this prison, hence i have the advantage to use the prison computer to communicate with you, and i will be very glad to also have a detailed information about you. From here i communicated with citi bank and they said that according to the agreement that my daddy signed with them that i must be present in their bank to claim the money by myself OR that i should appoint a foreign partner who will claim and receive the money on my behalf. the money is my only hope in life. as soon as Citi Bank transfers the money into your bank account, you will use some of the money to get me a lawyer/s to fight for my case and get me out of here, then thesame week of my release you will fly down here in Gambia and i and you will depart to your home in your country together. I want you to help me claim and receive the amount and also be my fund and investment manager. Reply me only on email: [EMAIL PROTECTED] ONLY. In your reply do give me your house address so that i will put it in my diary. Yours sincerely,Miss Angela Kennedy _ Discover the new Windows Vista http://search.msn.com/results.aspx?q=windows+vistamkt=en-USform=QBRE___ general mailing list general@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
[ofa-general] Re: [PATCH 2 of 3 for-2.6.24] mlx4: always fill MTTs from CPU
+num_mtt_res_bytes = ((dev-caps.reserved_mtts * + (dev-caps.mtt_entry_sz / MLX4_MTT_ENTRY_PER_SEG) + + L1_CACHE_BYTES - 1) / + L1_CACHE_BYTES) * L1_CACHE_BYTES; err = mlx4_init_icm_table(dev, priv-mr_table.mtt_table, init_hca-mtt_base, dev-caps.mtt_entry_sz, dev-caps.num_mtt_segs, - dev-caps.reserved_mtts, 1, 0); + num_mtt_res_bytes / dev-caps.mtt_entry_sz, + 1, 0); This is a little off I think because it may be that mtt_entry_sz might be bigger than L1_CACHE_BYTES so the number of reserved objects might not be big enough. Also the current meaning of reserved_mtts is really wrong (it leads to the driver reserving too much stuff) -- we should convert it to segments, like this (I'll put this in my queue before this patch and fix up the expression above): diff --git a/drivers/net/mlx4/main.c b/drivers/net/mlx4/main.c index 07c2847..ed7e8d7 100644 --- a/drivers/net/mlx4/main.c +++ b/drivers/net/mlx4/main.c @@ -149,7 +149,8 @@ static int __devinit mlx4_dev_cap(struct mlx4_dev *dev, struct mlx4_dev_cap *dev dev-caps.max_cqes = dev_cap-max_cq_sz - 1; dev-caps.reserved_cqs = dev_cap-reserved_cqs; dev-caps.reserved_eqs = dev_cap-reserved_eqs; - dev-caps.reserved_mtts = dev_cap-reserved_mtts; + dev-caps.reserved_mtts = DIV_ROUND_UP(dev_cap-reserved_mtts, + MLX4_MTT_ENTRY_PER_SEG); dev-caps.reserved_mrws = dev_cap-reserved_mrws; dev-caps.reserved_uars = dev_cap-reserved_uars; dev-caps.reserved_pds = dev_cap-reserved_pds; ___ general mailing list general@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
[ofa-general] Question about mthca_alloc_memfree and mthca_alloc_db
Roland,
We hit a bug in the RHEL4 kernel which was fixed in your latest tree. The bug
was in mthca_alloc_memfree. When comparing your code to the current RH kernel,
we wondered why you would not return the error code from mthca_alloc_db rather
than -ENOMEM as demonstrated in the patch below?
Thoughts?
Ira
From f8c47490fd039efcf74f6470b34e2351fb302455 Mon Sep 17 00:00:00 2001
From: Ira K. Weiny [EMAIL PROTECTED]
Date: Thu, 4 Oct 2007 15:16:45 -0700
Subject: [PATCH] Return the error code mthca_alloc_db rather than mask its code
with ENOMEM.
Signed-off-by: Ira K. Weiny [EMAIL PROTECTED]
---
drivers/infiniband/hw/mthca/mthca_qp.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/infiniband/hw/mthca/mthca_qp.c
b/drivers/infiniband/hw/mthca/mthca_qp.c
index df01b20..c1f7e14 100644
--- a/drivers/infiniband/hw/mthca/mthca_qp.c
+++ b/drivers/infiniband/hw/mthca/mthca_qp.c
@@ -1144,13 +1144,13 @@ static int mthca_alloc_memfree(struct mthca_dev *dev,
qp-rq.db_index = mthca_alloc_db(dev, MTHCA_DB_TYPE_RQ,
qp-qpn, qp-rq.db);
if (qp-rq.db_index 0)
- return -ENOMEM;
+ return (qp-rq.db_index);
qp-sq.db_index = mthca_alloc_db(dev, MTHCA_DB_TYPE_SQ,
qp-qpn, qp-sq.db);
if (qp-sq.db_index 0) {
mthca_free_db(dev, MTHCA_DB_TYPE_RQ, qp-rq.db_index);
- return -ENOMEM;
+ return (qp-sq.db_index);
}
}
--
1.5.1
___
general mailing list
general@lists.openfabrics.org
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general
To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
[ofa-general] Re: Question about mthca_alloc_memfree and mthca_alloc_db
We hit a bug in the RHEL4 kernel which was fixed in your latest tree. The bug was in mthca_alloc_memfree. When comparing your code to the current RH kernel, we wondered why you would not return the error code from mthca_alloc_db rather than -ENOMEM as demonstrated in the patch below? Does Red Hat know about the bug so they can fix it in an update? Anyway, I don't think the return value matters much -- I think when I wrote the code, I just figured that the allocation failed so it makes sense to return ENOMEM rather than whatever internal reason caused the allocation to fail. Does it make any practical difference one way or another? - R. ___ general mailing list general@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
[ofa-general] Re: ib_create_cq in OFED 1.2.5 Vs 1.2
Any ideas? thanks much in advance. On 10/3/07, Rajouri Jammu [EMAIL PROTECTED] wrote: The ib_create_cq() api changed from 1.2 to 1.2.5. We have a custom driver that runs on OFED kernel modules. Is there a way to find out at compile time the ABI version for the kernel verbs? ___ general mailing list general@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
Re: [ofa-general] Setting lowest-common denominator ipoib multicast rate?
On Thu, 2007-10-04 at 17:23 -0500, Troy Benjegerdes wrote: How can I set the ipoib broadcast multicast group rate such that even a 1X SDR connected machine can still join the group? I tried the following in /etc/osm-partitions.conf What version of OpenSM ? That's the default for an OFED 1.2 based version of OpenSM. Default is /etc/ofa/opensm-partitions.conf for a master/OFED 1.3 version. based on a mail list posting from awhile ago, but it doesn't seem to work.. Default=0x7fff,ipoib,rate=1:ALL=full; rate=2 And then what does it take on the ipoib client side to pick up the new partition parameters and such? reloading ipoib, or a full restart? Restarting opensm after making the configuration change to the partitions file should be sufficient. -- Hal ___ general mailing list general@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general ___ general mailing list general@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
[ofa-general] Setting lowest-common denominator ipoib multicast rate?
How can I set the ipoib broadcast multicast group rate such that even a 1X SDR connected machine can still join the group? I tried the following in /etc/osm-partitions.conf based on a mail list posting from awhile ago, but it doesn't seem to work.. Default=0x7fff,ipoib,rate=1:ALL=full; And then what does it take on the ipoib client side to pick up the new partition parameters and such? reloading ipoib, or a full restart? ___ general mailing list general@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
[ofa-general] Re: [PATCH 3 of 3 for-2.6.24] mlx4: implement FMRs
+#define MLX4_MTT_FLAG_PRESENT 1 Am I missing something? Hasn't mlx4 already defined this since forever? - R. ___ general mailing list general@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
Re: [ofa-general] Setting lowest-common denominator ipoib multicast rate?
Hal Rosenstock wrote: On Thu, 2007-10-04 at 17:23 -0500, Troy Benjegerdes wrote: How can I set the ipoib broadcast multicast group rate such that even a 1X SDR connected machine can still join the group? I tried the following in /etc/osm-partitions.conf What version of OpenSM ? That's the default for an OFED 1.2 based version of OpenSM. Default is /etc/ofa/opensm-partitions.conf for a master/OFED 1.3 version. This is an ofed 1.2 version based on a mail list posting from awhile ago, but it doesn't seem to work.. Default=0x7fff,ipoib,rate=1:ALL=full; rate=2 Can we get something added to the opensm man page about what the different rate= options mean? I couldn't find anything documenting what these rates map to. And then what does it take on the ipoib client side to pick up the new partition parameters and such? reloading ipoib, or a full restart? Restarting opensm after making the configuration change to the partitions file should be sufficient. -- Hal ___ general mailing list general@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general ___ general mailing list general@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
Re: [ofa-general] Setting lowest-common denominator ipoib multicast rate?
Can we get something added to the opensm man page about what the different rate= options mean? I couldn't find anything documenting what these rates map to. FWIW the rates are defined in the IB spec, and you can look at enum ib_rate in rdma/ib_verbs.h in the kernel to see all the values. ___ general mailing list general@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
Re: [ofa-general] Setting lowest-common denominator ipoib multicast rate?
On Thu, 2007-10-04 at 18:22 -0500, Troy Benjegerdes wrote: Can we get something added to the opensm man page about what the different rate= options mean? I couldn't find anything documenting what these rates map to. The opensm man page says: Note that values for rate, mtu, and scope should be specified as defined in the IBTA specification (for example, mtu=4 for 2048). in the PARTITION CONFIGURATION section. ___ general mailing list general@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
[ofa-general] nightly osm_sim report 2007-10-05:normal completion
OSM Simulation Regression Summary [Generated mail - please do NOT reply] OpenSM binary date = 2007-10-04 OpenSM git rev = Tue_Oct_2_22:28:56_2007 [d5c34ddc158599abff9f09a6cc6c8cad67745f0b] ibutils git rev = Tue_Sep_4_17:57:34_2007 [4bf283f6a0d7c0264c3a1d2de92745e457585fdb] Total=520 Pass=520 Fail=0 Pass: 39 Stability IS1-16.topo 39 Pkey IS1-16.topo 39 OsmTest IS1-16.topo 39 OsmStress IS1-16.topo 39 Multicast IS1-16.topo 39 LidMgr IS1-16.topo 13 Stability IS3-loop.topo 13 Stability IS3-128.topo 13 Pkey IS3-128.topo 13 OsmTest IS3-loop.topo 13 OsmTest IS3-128.topo 13 OsmStress IS3-128.topo 13 Multicast IS3-loop.topo 13 Multicast IS3-128.topo 13 LidMgr IS3-128.topo 13 FatTree merge-roots-4-ary-2-tree.topo 13 FatTree merge-root-4-ary-3-tree.topo 13 FatTree gnu-stallion-64.topo 13 FatTree blend-4-ary-2-tree.topo 13 FatTree RhinoDDR.topo 13 FatTree FullGnu.topo 13 FatTree 4-ary-2-tree.topo 13 FatTree 2-ary-4-tree.topo 13 FatTree 12-node-spaced.topo 13 FTreeFail 4-ary-2-tree-missing-sw-link.topo 13 FTreeFail 4-ary-2-tree-links-at-same-rank-2.topo 13 FTreeFail 4-ary-2-tree-links-at-same-rank-1.topo 13 FTreeFail 4-ary-2-tree-diff-num-pgroups.topo Failures: ___ general mailing list general@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
