kernel/linux.git/drivers/infiniband, branch linux-2.6.16.y

IB/mthca: Fix off-by-one in FMR handling on memfree

2007-03-11T06:37:12+00:00

From: Michael S. Tsirkin mthca_table_find() will return the wrong address when the table entry being searched for is exactly at the beginning of a sglist entry (other than the first), because it uses >= when it should use >. Example: assume we have 2 entries in scatterlist, 4K each, offset is 4K. The current code will return first entry + 4K when we really want the second entry. In particular this means mapping an FMR on a memfree HCA may end up writing the page table into the wrong place, leading to memory corruption and also causing the HCA to use an incorrect address translation table. Signed-off-by: Michael S. Tsirkin Signed-off-by: Roland Dreier Signed-off-by: Adrian Bunk

IPoIB: Rejoin all multicast groups after a port event

2007-03-11T06:36:27+00:00

When ipoib_ib_dev_flush() is called because of a port event, the driver needs to rejoin all multicast groups, since the flush will call ipoib_mcast_dev_flush() (via ipoib_ib_dev_down()). Otherwise no (non-broadcast) multicast groups will be rejoined until the networking core calls ->set_multicast_list again, and so multicast reception will be broken for potentially a long time. Signed-off-by: Eli Cohen Signed-off-by: Michael S. Tsirkin Signed-off-by: Roland Dreier Signed-off-by: Adrian Bunk

IB/mthca: Use mmiowb after doorbell ring

2007-03-11T06:35:15+00:00

We discovered a problem when running IPoIB applications on multiple CPUs on an Altix system. Many messages such as: ib_mthca 0002:01:00.0: SQ 000014 full (19941644 head, 19941707 tail, 64 max, 0 nreq) appear in syslog, and the driver wedges up. Apparently this is because writes to the doorbells from different CPUs reach the device out of order. The following patch adds mmiowb() calls after doorbell rings to ensure the doorbell writes are ordered. Signed-off-by: Arthur Kepner Signed-off-by: Roland Dreier Signed-off-by: Adrian Bunk

IB/mthca: restore missing PCI registers after reset

2006-08-07T17:04:22+00:00

mthca does not restore the following PCI-X/PCI Express registers after reset: PCI-X device: PCI-X command register PCI-X bridge: upstream and downstream split transaction registers PCI Express : PCI Express device control and link control registers This causes instability and/or bad performance on systems where one of these registers is set to a non-default value by BIOS. Signed-off-by: Michael S. Tsirkin Signed-off-by: Adrian Bunk

IB/srp: Don't send task management commands after target removal

2006-03-04T01:50:16+00:00

Just fail abort and reset requests that come in after we've already decided to remove a target. Signed-off-by: Roland Dreier

Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/roland/infiniband

2006-02-14T21:49:37+00:00

IB/mthca: bump driver version and release date

2006-02-13T20:19:44+00:00

Signed-off-by: Roland Dreier

IPoIB: Yet another fix for send-only joins

2006-02-11T20:22:12+00:00

Even after the last fix, it's still possible for a send-only join to start before the join for the broadcast group has finished. This could cause us to create a multicast group using attributes from the broadcast group that haven't been initialized yet, so we would use garbage for the Q_Key, etc. Fix this by waiting until the broadcast group's attached flag is set before starting send-only joins. Signed-off-by: Roland Dreier

IB/mthca: Don't print debugging info until we have all values

2006-02-11T02:02:44+00:00

When debugging is enabled, the mthca_QUERY_DEV_LIM() firmware command function prints out some of the device limits that it queries. However the debugging prints happen before all of the fields are extracted from the firmware response, so some of the values that get printed are uninitialized junk. Move the prints to the end of the function to fix this. Signed-off-by: Roland Dreier

IPoIB: Fix another send-only join race

2006-02-08T00:39:26+00:00

Further, there's an additional issue that I saw in testing: ipoib_mcast_send may get called when priv->broadcast is NULL (e.g. if the device was downed and then upped internally because of a port event). If this happends and the send-only join request gets completed before priv->broadcast is set, we get an oops. Signed-off-by: Michael S. Tsirkin Signed-off-by: Roland Dreier