- 01 Jul, 2006 40 commits
-
-
Bryan O'Sullivan authored
Signed-off-by:
Dave Olson <dave.olson@qlogic.com> Signed-off-by:
Bryan O'Sullivan <bryan.osullivan@qlogic.com> Cc: "Michael S. Tsirkin" <mst@mellanox.co.il> Cc: Roland Dreier <rolandd@cisco.com> Signed-off-by:
Andrew Morton <akpm@osdl.org> Signed-off-by:
Linus Torvalds <torvalds@osdl.org>
-
Bryan O'Sullivan authored
We can't tell for sure if any packets are in the infinipath receive buffer when we shut down a chip port. Normally this is taken care of by orderly shutdown, but when processes are terminated, or sending process has a bug, we can continue to receive packets. So rather than writing zero to the address registers for the closing port, we point it at a dummy memory. Signed-off-by:
-
Bryan O'Sullivan authored
We must increment uaddr by size we are reading or writing, since it's passed as a char *, not a pointer to the appropriate size. Signed-off-by:
-
Bryan O'Sullivan authored
We do a few more explicit checks for specific models, and now also support the old PathScale serial number style, or new QLogic style. This is backwards compatible with previous versions of software and hardware. That is, older software will see a plausible serial number and correct GUID when used with a new board, while newer software will correctly handle an older board. Signed-off-by:
Mike Albaugh <mike.albaugh@qlogic.com> Signed-off-by:
-
Bryan O'Sullivan authored
This attribute group made it into the original driver, but should not have. Signed-off-by:
-
Bryan O'Sullivan authored
The two arrays only had space for 4 units. Also changed from ipath_set_sps_lid() to ipath_set_lid(); the sps was leftover. Signed-off-by:
-
Bryan O'Sullivan authored
This patch separates QP state used for sending and receiving RC packets so the processing in the receive interrupt handler can be done mostly without locks being held. ACK packets are now sent without requiring synchronization with the send tasklet. Signed-off-by:
Ralph Campbell <ralph.campbell@qlogic.com> Signed-off-by:
-
Bryan O'Sullivan authored
This patch fixes some problems uncovered during IB compliance testing to return the right values for error counters returned by the Performance Get Counters packet. Signed-off-by:
-
Bryan O'Sullivan authored
Signed-off-by:
-
Bryan O'Sullivan authored
The tail register read became redundant as the result of earlier receive interrupt bug fixes. Drop another unneeded register read. And another line that got duplicated. Signed-off-by:
-
Bryan O'Sullivan authored
Signed-off-by:
-
Bryan O'Sullivan authored
Signed-off-by:
-
Bryan O'Sullivan authored
Do an extra check to see if in-memory tail changed while processing packets, and if so, going back through the loop again (but only once per call to ipath_kreceive()). In practice, this seems to be enough to guarantee that if we crossed the clearing of an interrupt at start of ipath_intr with a scheduled tail register update, that we'll process the "extra" packet that lost the interrupt because we cleared it just as it was about to arrive. Signed-off-by:
-
Bryan O'Sullivan authored
The problem was that I was updating the head register multiple times in the rcvhdrq processing loop, and setting the counter on each update. Since that meant that the tail register was ahead of head for all but the last update, we would get extra interrupts. The fix was to not write the counter value except on the last update. I also changed to update rcvhdrhead and rcvegrindexhead at most every 16 packets, if there were lots of packets in the queue (and of course, on the last packet, regardless). I also made some small cleanups while debugging this. With these changes, xeon/monty typically sees two openib packets per interrupt on sdp and ipoib, opteron/monty is about 1.25 pkts/intr. I'm seeing about 3800 Mbit/s monty/xeon, and 5000-5100 opteron/monty with netperf sdp. Netpipe doesn't show as good as that, peaking at about 4400 on opteron/monty sdp. Plain ipoib xeon is about 2100+ netperf, opteron 2900+, at 128KB Signed-off-by: olson@eng-12.pathscale.com Signed-off-by:
Bryan O'Sullivan <bos@pathscale.com> Cc: "Michael S. Tsirkin" <mst@mellanox.co.il> Cc: Roland Dreier <rolandd@cisco.com> Signed-off-by:
-
Bryan O'Sullivan authored
Also count the number of interrupts where that works (fastrcvint). On any interrupt where the port0 head and tail registers are not equal, just call the ipath_kreceive code without reading the interrupt status, thus saving the approximately 0.25usec processor stall waiting for the read to return. If any other interrupt bits are set, or head==tail, take the normal path, but that has been reordered to handle read ahead of pioavail. Also no longer call ipath_kreceive() from ipath_qcheck(), because that just seems to make things worse, and isn't really buying us anything, these days. Also no longer loop in ipath_kreceive(); better to not hold things off too long (I saw many cases where we would loop 4-8 times, and handle thousands (up to 3500) in a single call). Signed-off-by:
-
Bryan O'Sullivan authored
Made in-memory rcvhdrq tail update be in dma_alloc'ed memory, not random user or special kernel (needed for ppc, also "just the right thing to do"). Some cleanups to make unexpected link transitions less likely to produce complaints about packet errors, and also to not leave SMA packets stuck and unable to go out. A few other random debug and comment cleanups. Always init rcvhdrq head/tail registers to 0, to avoid race conditions (should have been that way some time ago). Signed-off-by:
-
Bryan O'Sullivan authored
This is not a DMA target, so no need to use dma_alloc_coherent on it. Signed-off-by:
-
Bryan O'Sullivan authored
This helps us to survive better when memory is fragmented. Signed-off-by:
-
Bryan O'Sullivan authored
Signed-off-by:
-
Bryan O'Sullivan authored
Signed-off-by:
-
Bryan O'Sullivan authored
Signed-off-by:
-
Bryan O'Sullivan authored
These limits are somewhat artificial in that we don't actually have any device limits. However, the verbs layer expects that such limits exist and are enforced, so we make up arbitrary (but sensible) limits. Signed-off-by:
Robert Walsh <robert.walsh@qlogic.com> Signed-off-by:
-
Bryan O'Sullivan authored
Signed-off-by:
-
Bryan O'Sullivan authored
Signed-off-by:
-
Bryan O'Sullivan authored
Signed-off-by:
-
Bryan O'Sullivan authored
Signed-off-by:
-
Bryan O'Sullivan authored
Signed-off-by:
-
Bryan O'Sullivan authored
Signed-off-by:
-
Bryan O'Sullivan authored
There is no longer a /dev/ipath_diag file; instead, there's /dev/ipath_diag0, 1, etc. It's still not possible to have diags run on more than one unit at a time, but that's easy to fix at some point. Signed-off-by:
-
Bryan O'Sullivan authored
Signed-off-by:
-
Bryan O'Sullivan authored
Signed-off-by:
-
Bryan O'Sullivan authored
Signed-off-by:
-
Bryan O'Sullivan authored
Signed-off-by:
-
Bryan O'Sullivan authored
Signed-off-by:
-
Jae-hyeon Park authored
Fix typo in message. Signed-off-by:
Randy Dunlap <rdunlap@xenotime.net> Signed-off-by:
-
Doug Thompson authored
Fix the quoted module name in the sysfs for EDAC modules and reported by several people. Instead of ../_edac_e752x_/ now the following will be presented, like other modules: ../edac_e752x/ Signed-off-by:
Doug Thompson <norsk5@xmission.com> Signed-off-by:
-
Bjorn Helgaas authored
Make warnings more consistent. Signed-off-by:
Bjorn Helgaas <bjorn.helgaas@hp.com> Cc: Thomas Gleixner <tglx@linutronix.de> Acked-by:
Ingo Molnar <mingo@elte.hu> Signed-off-by:
-
Bjorn Helgaas authored
IRQ_PER_CPU is a bit in the struct irq_desc "status" field, not in the struct irqaction "flags", so the previous code checked the wrong bit. SA_PERCPU_IRQ is only used by drivers/char/mmtimer.c for SGI ia64 boxes. Signed-off-by:
Thomas Gleixner <tglx@linutronix.de> Signed-off-by:
-
Ingo Molnar authored
Fix futex_wake() exit condition bug when handling the robust-list with PI futexes on them. (reported by Ulrich Drepper, debugged by the lock validator.) Signed-off-by:
-
Vernon Mauery authored
lock_queue was getting called essentially twice in a row and was continually incrementing the mm_count ref count, thus causing a memory leak. Dinakar Guniguntala provided a proper fix for the problem that simply grabs the spinlock for the hash bucket queue rather than calling lock_queue. The second time we do a queue_lock in futex_lock_pi, we really only need to take the hash bucket lock. Signed-off-by:
Dinakar Guniguntala <dino@in.ibm.com> Signed-off-by:
Vernon Mauery <vernux@us.ibm.com> Acked-by:
Paul E. McKenney <paulmck@us.ibm.com> Signed-off-by:
-
