On Wed, Aug 08, 2007 at 01:50:35PM +0200, Michael Buesch wrote:
On Wednesday 08 August 2007 14:38:10 Andi Kleen wrote:
Jeff Garzik [EMAIL PROTECTED] writes:
+ val, reg_index, addr, addr+4); */
+ writel(cpu_to_le32(reg_index), addr);
+
On Wednesday 08 August 2007 15:08:28 Andi Kleen wrote:
On Wed, Aug 08, 2007 at 03:02:35PM +0200, Michael Buesch wrote:
On Wednesday 08 August 2007 14:55:11 Andi Kleen wrote:
On Wed, Aug 08, 2007 at 01:50:35PM +0200, Michael Buesch wrote:
On Wednesday 08 August 2007 14:38:10 Andi Kleen
Tziporet,
Can you add the following as a known issue:
open-iscsi over TCP does not support usage of data digest on RedHat EL/AS 4
up3,
up4 up5.
Note that this comment should be added to OFED release notes, not to
iSER release notes. This is not an iSER bug (it's a bug in the backport
for
On Wednesday 08 August 2007 15:38:50 Andi Kleen wrote:
On Wed, Aug 08, 2007 at 03:28:33PM +0200, Michael Buesch wrote:
On Wednesday 08 August 2007 15:08:28 Andi Kleen wrote:
On Wed, Aug 08, 2007 at 03:02:35PM +0200, Michael Buesch wrote:
On Wednesday 08 August 2007 14:55:11 Andi Kleen
Tziporet,
Can we make the change to 1.2.5? This should probably include:
- change builds/connectx to builds/ofed-1.2.5 (or just add a link)
- change build names from 1.2.c to 1.2.5
Scott Weitzenkamp (sweitzen) wrote:
Cisco has been testing 1.2.c-10 IPoIB/SDP/MPI successfully on a 32-node
Erez Zilber wrote:
Tziporet,
Can you add the following as a known issue:
open-iscsi over TCP does not support usage of data digest on RedHat EL/AS 4
up3,
up4 up5.
Note that this comment should be added to OFED release notes, not to
iSER release notes. This is not an iSER bug (it's a bug
This code is far from a TCP stack. It's main purpose is to exchange
RDMA MPA request/response messages that are required by the iWarp specs
and therefore needed by our hardware. All RNIC hardware vendors need
this MPA message exchange, including those already accepted into
kernel.org. Do you
But there are indeed a few cases that look wrong.
yes...
arch/x86_64/kernel/pci-calgary.c: writel(cpu_to_be32(val), target);
eg this almost certainly wants to be
writel(swab32(val), target);
or something equivalent like
__raw_writel(cpu_to_be32(val), target);
Andi Kleen wrote:
Jeff Garzik [EMAIL PROTECTED] writes:
+ val, reg_index, addr, addr+4); */
+ writel(cpu_to_le32(reg_index), addr);
+ writel(cpu_to_le32(val),(u8 *)addr + 4);
wrong -- endian conversion macros not needed with writel()
Are you sure?
Yes.
Roland Dreier wrote:
But there are indeed a few cases that look wrong.
yes...
arch/x86_64/kernel/pci-calgary.c: writel(cpu_to_be32(val), target);
eg this almost certainly wants to be
writel(swab32(val), target);
or something equivalent like
On Wednesday 08 August 2007 18:18:31 Roland Dreier wrote:
But there are indeed a few cases that look wrong.
yes...
arch/x86_64/kernel/pci-calgary.c: writel(cpu_to_be32(val), target);
eg this almost certainly wants to be
writel(swab32(val), target);
or something
Michael Buesch wrote:
On Wednesday 08 August 2007 18:18:31 Roland Dreier wrote:
But there are indeed a few cases that look wrong.
yes...
arch/x86_64/kernel/pci-calgary.c: writel(cpu_to_be32(val), target);
eg this almost certainly wants to be
writel(swab32(val), target);
git.openfabrics.org/~glenn/libnes.git
git.openfabrics.org/~glenn/ofed_1_2.git
git.openfabrics.org/~glenn/ofascripts.git
git.openfabrics.org/~glenn/ofed_1_2_scripts.git
these aren't actually git URLs. prepending git:// seems to work though.
___
On Wednesday 08 August 2007 18:59:08 Jeff Garzik wrote:
Michael Buesch wrote:
writel doesn't guarantee flushing either.
readl does.
Not quite -- there are multiple kinds of flushing. You're thinking
about flushing across PCI bridges, which is correct, but you also have
CPU write
14 matches
Mail list logo
