aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2008-03-17drm/ati_pcigart: fix the PCIGART to use drm_pci to allocate GART table.Dave Airlie
This fixes a problem on 64-bit with 4GB with ATI RS690 chipsets. It makes sure the pcigart table is allocated in coherent memory for DMA operations. Signed-off-by: Dave Airlie <airlied@redhat.com>
2008-03-17drm/radeon: fixup RV550 chip familyAlex Deucher
This fixes up the RV550 chips which are based on RV515, not RV530. It also adds another RS690 PCI ID. Signed-off-by: Dave Airlie <airlied@redhat.com>
2008-03-17drm/via: attempt again to stabilise the AGP DMA command submission.Thomas Hellstrom
It's worth remembering that all new bright ideas on how to make this command reader work properly and according to docs will probably fail :( Bring in some old code. Also allow a larger SG-DMA download stride, and remove unnecessary waits for command regulators pauses. Signed-off-by: Dave Airlie <airlied@redhat.com>
2008-03-17drm: Fix race that can lockup the kernelMike Isely
The i915_vblank_swap() function schedules an automatic buffer swap upon receipt of the vertical sync interrupt. Such an operation is lengthy so it can't be allowed to happen in normal interrupt context, thus the DRM implements this by scheduling the work in a kernel softirq-scheduled tasklet. In order for the buffer swap to work safely, the DRM's central lock must be taken, via a call to drm_lock_take() located in drivers/char/drm/drm_irq.c within the function drm_locked_tasklet_func(). The lock-taking logic uses a non-interrupt-blocking spinlock to implement the manipulations needed to take the lock. This semantic would be safe if all attempts to use the spinlock only happen from process context. However this buffer swap happens from softirq context which is really a form of interrupt context. Thus we have an unsafe situation, in that drm_locked_tasklet_func() can block on a spinlock already taken by a thread in process context which will never get scheduled again because of the blocked softirq tasklet. This wedges the kernel hard. To trigger this bug, run a dual-head cloned mode configuration which uses the i915 drm, then execute an opengl application which synchronizes buffer swaps against the vertical sync interrupt. In my testing, a lockup always results after running anywhere from 5 minutes to an hour and a half. I believe dual-head is needed to really trigger the problem because then the vertical sync interrupt handling is no longer predictable (due to being interrupt-sourced from two different heads running at different speeds). This raises the probability of the tasklet trying to run while the userspace DRI is doing things to the GPU (and manipulating the DRM lock). The fix is to change the relevant spinlock semantics to be the interrupt-blocking form. After this change I am no longer able to trigger the lockup; the longest test run so far was 20 hours (test stopped after that point). Note: I have examined the places where this spinlock is being employed; all are reasonably short bounded sequences and should be suitable for interrupts being blocked without impacting overall kernel interrupt response latency. Signed-off-by: Mike Isely <isely@pobox.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
2008-03-16Linux 2.6.25-rc6v2.6.25-rc6Linus Torvalds
2008-03-16Merge branch 'master' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/kyle/parisc-2.6 * 'master' of git://git.kernel.org/pub/scm/linux/kernel/git/kyle/parisc-2.6: [PARISC] make ptr_to_pide() static [PARISC] head.S: section mismatch fixes [PARISC] add back Crestone Peak cpu [PARISC] futex: special case cmpxchg NULL in kernel space [PARISC] clean up show_stack [PARISC] add pa8900 CPUs to hardware inventory [PARISC] clean up include/asm-parisc/elf.h [PARISC] move defconfig to arch/parisc/configs/ [PARISC] add back AD1889 MAINTAINERS entry [PARISC] pdc_console: fix bizarre panic on boot [PARISC] dump_stack in show_regs [PARISC] pdc_stable: fix compile errors [PARISC] remove unused pdc_iodc_printf function [PARISC] bump __NR_syscalls [PARISC] unbreak pgalloc.h [PARISC] move VMALLOC_* definitions to fixmap.h [PARISC] wire up timerfd syscalls [PARISC] remove old timerfd syscall
2008-03-15[PARISC] make ptr_to_pide() staticFUJITA Tomonori
Signed-off-by: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp> Signed-off-by: Kyle McMartin <kyle@parisc-linux.org>
2008-03-15[PARISC] head.S: section mismatch fixesHelge Deller
- move boot_args[] into the init section - move $global$ into the read_mostly section - fix the following two section mismatches: WARNING: vmlinux.o(.text+0x9c): Section mismatch: reference to .init.text:start_kernel (between '$pgt_fill_loop' and '$is_pa20') WARNING: vmlinux.o(.text+0xa0): Section mismatch: reference to .init.text:start_kernel (between '$pgt_fill_loop' and '$is_pa20') Signed-off-by: Helge Deller <deller@gmx.de> SIgned-off-by: Kyle McMartin <kyle@mcmartin.ca>
2008-03-15[PARISC] add back Crestone Peak cpuKyle McMartin
Crestone Peak Slow is the 800MHz PA-8800 cpu in the C8000. 0x88B is probably the Crestone Peak Fast. Signed-off-by: Kyle McMartin <kyle@mcmartin.ca>
2008-03-15[PARISC] futex: special case cmpxchg NULL in kernel spaceKyle McMartin
Commit a0c1e9073ef7428a14309cba010633a6cd6719ea added code to futex.c to detect whether futex_atomic_cmpxchg_inatomic was implemented at run time: + curval = cmpxchg_futex_value_locked(NULL, 0, 0); + if (curval == -EFAULT) + futex_cmpxchg_enabled = 1; This is bogus on parisc, since page zero in kernel virtual space is the gateway page for syscall entry, and should not be read from the kernel. (That, and we really don't like the kernel faulting on its own address space...) Signed-off-by: Kyle McMartin <kyle@mcmartin.ca>
2008-03-15[PARISC] clean up show_stackKyle McMartin
When we show_regs, we obviously have a struct pt_regs of the calling frame. Use these in show_stack so we don't have the entire bogus call trace up to the show_stack call. Signed-off-by: Kyle McMartin <kyle@mcmartin.ca>
2008-03-15[PARISC] add pa8900 CPUs to hardware inventoryJames Bottomley
This patch adds the known pa8900 CPUs to the inventory list and removes the Crestone Peak one which apparently never escaped into the wild. Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com> Signed-off-by: Kyle McMartin <kyle@mcmartin.ca>
2008-03-15[PARISC] clean up include/asm-parisc/elf.hRandolph Chung
Cleanup some cruft. No functionality changes. Signed-off-by: Randolph Chung <tausq@parisc-linux.org> Signed-off-by: Kyle McMartin <kyle@mcmartin.ca>
2008-03-15[PARISC] move defconfig to arch/parisc/configs/Adrian Bunk
This patch moves the default parisc defconfig to arch/parisc/configs/generic_defconfig where it belongs and selects it as the default defconfig through KBUILD_DEFCONFIG. Signed-off-by: Adrian Bunk <adrian.bunk@movial.fi> Signed-off-by: Kyle McMartin <kyle@mcmartin.ca>
2008-03-15[PARISC] add back AD1889 MAINTAINERS entryThibaut VARENE
Signed-off-by: Thibaut VARENE <T-Bone@parisc-linux.org> Signed-off-by: Kyle McMartin <kyle@mcmartin.ca>
2008-03-15[PARISC] pdc_console: fix bizarre panic on bootKyle McMartin
Commit 721fdf34167580ff98263c74cead8871d76936e6 introduced a subtle bug by accidently removing the "static" from iodc_dbuf. This resulted in, what appeared to be, a trap without *current set to a task. Probably the result of a trap in real mode while calling firmware. Also do other misc clean ups. Since the only input from firmware is non blocking, share iodc_dbuf between input and output, and spinlock the only callers. Signed-off-by: Kyle McMartin <kyle@parisc-linux.org>
2008-03-15[PARISC] dump_stack in show_regsKyle McMartin
Originally, show_stack was used in BUG() output. However, a recent commit changed it to print register state (no idea what that's supposed to help, really...) and parisc was missing a backtrace because of it. Signed-off-by: Kyle McMartin <kyle@parisc-linux.org>
2008-03-15[PARISC] pdc_stable: fix compile errorsJoel Soete
Signed-off-by: Joel Soete <rubisher@scarlet.be> Signed-off-by: Kyle McMartin <kyle@parisc-linux.org>
2008-03-15[PARISC] remove unused pdc_iodc_printf functionKyle McMartin
Signed-off-by: Kyle McMartin <kyle@parisc-linux.org>
2008-03-15[PARISC] bump __NR_syscallsKyle McMartin
oops, forgot this in the previous commit. Signed-off-by: Kyle McMartin <kyle@parisc-linux.org>
2008-03-15[PARISC] unbreak pgalloc.hKyle McMartin
Commit 2f569afd9ced9ebec9a6eb3dbf6f83429be0a7b4 broke the compile rather spectacularly. Fix code errors. Signed-off-by: Kyle McMartin <kyle@parisc-linux.org>
2008-03-15[PARISC] move VMALLOC_* definitions to fixmap.hKyle McMartin
They make way more sense here, really... Signed-off-by: Kyle McMartin <kyle@parisc-linux.org>
2008-03-15[PARISC] wire up timerfd syscallsKyle McMartin
Signed-off-by: Kyle McMartin <kyle@parisc-linux.org>
2008-03-15[PARISC] remove old timerfd syscallKyle McMartin
Signed-off-by: Kyle McMartin <kyle@parisc-linux.org>
2008-03-15ACPI: Remove ACPI_CUSTOM_DSDT_INITRD optionLinus Torvalds
This essentially reverts commit 71fc47a9adf8ee89e5c96a47222915c5485ac437 ("ACPI: basic initramfs DSDT override support"), because the code simply isn't ready. It did ugly things to the init sequence to populate the rootfs image early, but that just ended up showing other problems with the whole approach. The fact is, the VFS layer simply isn't initialized this early, and the relevant ACPI code should either run much later, or this shouldn't be done at all. For 2.6.25, we'll just pick the latter option. We can revisit this concept later if necessary. Cc: Dave Hansen <haveblue@us.ibm.com> Cc: Tilman Schmidt <tilman@imap.cc> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Thomas Renninger <trenn@suse.de> Cc: Eric Piel <eric.piel@tremplin-utc.net> Cc: Len Brown <len.brown@intel.com> Cc: Christoph Hellwig <hch@infradead.org> Cc: Markus Gaugusch <dsdt@gaugusch.at> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-03-15tifm_sd: DATA_CARRY is not boolean in tifm_sd_transfer_data()Roel Kluin
DATA_CARRY is not boolean Signed-off-by: Roel Kluin <12o3l@tiscali.nl> Signed-off-by: Pierre Ossman <drzeus@drzeus.cx> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-03-15Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-2.6Linus Torvalds
* git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-2.6: [NET]: Fix tbench regression in 2.6.25-rc1
2008-03-15sched: simplify sched_slice()Ingo Molnar
Use the existing calc_delta_mine() calculation for sched_slice(). This saves a divide and simplifies the code because we share it with the other /cfs_rq->load users. It also improves code size: text data bss dec hex filename 42659 2740 144 45543 b1e7 sched.o.before 42093 2740 144 44977 afb1 sched.o.after Signed-off-by: Ingo Molnar <mingo@elte.hu> Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
2008-03-15sched: fix fair sleepersIngo Molnar
Fair sleepers need to scale their latency target down by runqueue weight. Otherwise busy systems will gain ever larger sleep bonus. Signed-off-by: Ingo Molnar <mingo@elte.hu> Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
2008-03-15sched: fix overload performance: buddy wakeupsPeter Zijlstra
Currently we schedule to the leftmost task in the runqueue. When the runtimes are very short because of some server/client ping-pong, especially in over-saturated workloads, this will cycle through all tasks trashing the cache. Reduce cache trashing by keeping dependent tasks together by running newly woken tasks first. However, by not running the leftmost task first we could starve tasks because the wakee can gain unlimited runtime. Therefore we only run the wakee if its within a small (wakeup_granularity) window of the leftmost task. This preserves fairness, but does alternate server/client task groups. Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl> Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-03-15sched: fix calc_delta_mine()Ingo Molnar
lw->weight can be 0 for a short time during bootup. Signed-off-by: Ingo Molnar <mingo@elte.hu> Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
2008-03-15sched: fix update_load_add()/sub()Ingo Molnar
Clear the cached inverse value when updating load. This is needed for calc_delta_mine() to work correctly when using the rq load. Signed-off-by: Ingo Molnar <mingo@elte.hu> Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
2008-03-15sched: min_vruntime fixPeter Zijlstra
Current min_vruntime tracking is incorrect and will cause serious problems when we don't run the leftmost task for some reason. min_vruntime does two things; 1) it's used to determine a forward direction when the u64 vruntime wraps, 2) it's used to track the leftmost vruntime to position newly enqueued tasks from. The current logic advances min_vruntime whenever the current task's vruntime advance. Because the current task may pass the leftmost task still waiting we're failing the second goal. This causes new tasks to be placed too far ahead and thus penalizes their runtime. Fix this by making min_vruntime the min_vruntime of the waiting tasks by tracking it in enqueue/dequeue, and compare against current's vruntime to obtain the absolute minimum when placing new tasks. Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl> Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-03-15sched: fix race in schedule()Hiroshi Shimamoto
Fix a hard to trigger crash seen in the -rt kernel that also affects the vanilla scheduler. There is a race condition between schedule() and some dequeue/enqueue functions; rt_mutex_setprio(), __setscheduler() and sched_move_task(). When scheduling to idle, idle_balance() is called to pull tasks from other busy processor. It might drop the rq lock. It means that those 3 functions encounter on_rq=0 and running=1. The current task should be put when running. Here is a possible scenario: CPU0 CPU1 | schedule() | ->deactivate_task() | ->idle_balance() | -->load_balance_newidle() rt_mutex_setprio() | | --->double_lock_balance() *get lock *rel lock * on_rq=0, ruuning=1 | * sched_class is changed | *rel lock *get lock : | : ->put_prev_task_rt() ->pick_next_task_fair() => panic The current process of CPU1(P1) is scheduling. Deactivated P1, and the scheduler looks for another process on other CPU's runqueue because CPU1 will be idle. idle_balance(), load_balance_newidle() and double_lock_balance() are called and double_lock_balance() could drop the rq lock. On the other hand, CPU0 is trying to boost the priority of P1. The result of boosting only P1's prio and sched_class are changed to RT. The sched entities of P1 and P1's group are never put. It makes cfs_rq invalid, because the cfs_rq has curr and no leaf, but pick_next_task_fair() is called, then the kernel panics. Signed-off-by: Hiroshi Shimamoto <h-shimamoto@ct.jp.nec.com> Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl> Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-03-14Merge branch 'for-linus' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/ieee1394/linux1394-2.6 * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/ieee1394/linux1394-2.6: firewire: fw-ohci: shut up false compiler warning on PPC32 firewire: fw-ohci: use dma_alloc_coherent for ar_buffer ieee1394: sbp2: fix for SYM13FW500 bridge (Datafab disk) firewire: fw-sbp2: fix for SYM13FW500 bridge (Datafab disk) firewire: update Kconfig help text firewire: warn on fatal condition in topology code firewire: fw-sbp2: set single-phase retry_limit firewire: fw-ohci: Apple UniNorth 1st generation support firewire: fw-ohci: PPC PMac platform code firewire: endianess annotations firewire: endianess fix
2008-03-14nfsd: fix oops on access from high-numbered portsJ. Bruce Fields
This bug was always here, but before my commit 6fa02839bf9412e18e77 ("recheck for secure ports in fh_verify"), it could only be triggered by failure of a kmalloc(). After that commit it could be triggered by a client making a request from a non-reserved port for access to an export marked "secure". (Exports are "secure" by default.) The result is a struct svc_export with a reference count one too low, resulting in likely oopses next time the export is accessed. The reference counting here is not straightforward; a later patch will clean up fh_verify(). Thanks to Lukas Hejtmanek for the bug report and followup. Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu> Cc: Lukas Hejtmanek <xhejtman@ics.muni.cz> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-03-14struct export_operations: adjust comments to match current membersMarc Dionne
The comments in the definition of struct export_operations don't match the current members. Add a comment for the 2 new functions and remove 2 comments for unused ones. Signed-off-by: Marc Dionne <marc.c.dionne@gmail.com> Acked-by: David Howells <dhowells@redhat.com> Acked-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-03-14firewire: fw-ohci: shut up false compiler warning on PPC32Stefan Richter
Shut up "may be used uninitialised in this function" warnings due to PPC32's implementation of dma_alloc_coherent(). Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
2008-03-14firewire: fw-ohci: use dma_alloc_coherent for ar_bufferJarod Wilson
Currently, we do nothing to guarantee we have a consistent DMA buffer for asynchronous receive packets. Rather than doing several sync's following a dma_map_single() to get consistent buffers, just switch to using dma_alloc_coherent(). Resolves constant buffer failures on my own x86_64 laptop w/4GB of RAM and likely to fix a number of other failures witnessed on x86_64 systems with 4GB of RAM or more. Signed-off-by: Jarod Wilson <jwilson@redhat.com> Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
2008-03-14ieee1394: sbp2: fix for SYM13FW500 bridge (Datafab disk)Stefan Richter
Fix I/O errors due to SYM13FW500's inability to handle larger request sizes. Reported by Piergiorgio Sartor <piergiorgio.sartor@nexgo.de> for firewire-sbp2 in https://bugzilla.redhat.com/show_bug.cgi?id=436879 This fix is necessary because sbp2's default request size limit has been lifted since 2.6.25-rc1. Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de> Signed-off-by: Jarod Wilson <jwilson@redhat.com>
2008-03-14firewire: fw-sbp2: fix for SYM13FW500 bridge (Datafab disk)Stefan Richter
Fix I/O errors due to SYM13FW500's inability to handle larger request sizes. Reported by Piergiorgio Sartor <piergiorgio.sartor@nexgo.de> in https://bugzilla.redhat.com/show_bug.cgi?id=436879 Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de> Signed-off-by: Jarod Wilson <jwilson@redhat.com>
2008-03-14firewire: update Kconfig help textStefan Richter
Remove some less necessary information, point out that video1394 and dv1394 should be blacklisted along with ohci1394. Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
2008-03-14firewire: warn on fatal condition in topology codeStefan Richter
If this ever happens to anybody, we want to have it in his log. Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
2008-03-14firewire: fw-sbp2: set single-phase retry_limitJarod Wilson
Per the SBP-2 specification, all SBP-2 target devices must have a BUSY_TIMEOUT register. Per the 1394-1995 specification, the retry_limt portion of the register should be set to 0x0 initially, and set on the target by a logged in initiator (i.e., a Linux host w/firewire controller(s)). Well, as it turns out, lots of devices these days have actually moved on to starting to implement SBP-3 compliance, which says that retry_limit should default to 0xf instead (yes, SBP-3 stomps directly on 1394-1995, oops). Prior to this change, the firewire driver stack didn't touch retry_limit, and any SBP-3 compliant device worked fine, while SBP-2 compliant ones were unable to retransmit when the host returned an ack_busy_X, which resulted in stalled out I/O, eventually causing the SCSI layer to give up and offline the device. The simple fix is for us to set retry_limit to 0xf in the register for all devices (which actually matches what the old ieee1394 stack did). Prior to this change, a hard disk behind an SBP-2 Prolific PL-3507 bridge chip would routinely encounter buffer I/O errors and wind up offlined by the SCSI layer. With this change, I've encountered zero I/O failures moving tens of GB of data around. Signed-off-by: Jarod Wilson <jwilson@redhat.com> Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
2008-03-14firewire: fw-ohci: Apple UniNorth 1st generation supportStefan Richter
Mostly copied from ohci1394.c. Necessary for some older Macs, e.g. PowerBook G3 Pismo and early PowerBook G4 Titanium. Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
2008-03-14firewire: fw-ohci: PPC PMac platform codeStefan Richter
Copied from ohci1394.c. This code is necessary to prevent machine check exceptions when reloading or resuming the driver. Tested on a 1st generation PowerBook G4 Titanium, which also needs the pci_probe() hunk. Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de> I was able to reproduce the system exception on resume with a 3rd-gen Titanium PowerBook G4 667, and this patch does let the system resume successfully now. Not quite clear if there was possibly an updated version coming using pci_enable_device() instead of the pair of pmac_call_feature() calls, but either way, this is a definite must-have, at least for older ppc macs -- my Aluminum PowerBook G4/1.67 suspends and resumes without this patch just fine. Signed-off-by: Jarod Wilson <jwilson@redhat.com> Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
2008-03-14firewire: endianess annotationsStefan Richter
Kills warnings from 'make C=1 CHECKFLAGS="-D__CHECK_ENDIAN__" modules': drivers/firewire/fw-transaction.c:771:10: warning: incorrect type in assignment (different base types) drivers/firewire/fw-transaction.c:771:10: expected unsigned int [unsigned] [usertype] <noident> drivers/firewire/fw-transaction.c:771:10: got restricted unsigned int [usertype] <noident> drivers/firewire/fw-transaction.h:93:10: warning: incorrect type in assignment (different base types) drivers/firewire/fw-transaction.h:93:10: expected unsigned int [unsigned] [usertype] <noident> drivers/firewire/fw-transaction.h:93:10: got restricted unsigned int [usertype] <noident> drivers/firewire/fw-ohci.c:1490:8: warning: restricted degrades to integer drivers/firewire/fw-ohci.c:1490:35: warning: restricted degrades to integer drivers/firewire/fw-ohci.c:1516:5: warning: cast to restricted type Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de> Signed-off-by: Jarod Wilson <jwilson@redhat.com>
2008-03-14firewire: endianess fixStefan Richter
The generation of incoming requests was filled in in wrong byte order on machines with big endian CPU. Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de> Signed-off-by: Jarod Wilson <jwilson@redhat.com>
2008-03-13Merge branch 'for-linus' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/roland/infiniband * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/roland/infiniband: IPoIB: Allocate priv->tx_ring with vmalloc() IPoIB/cm: Set tx_wr.num_sge in connected mode post_send() IPoIB: Don't drop multicast sends when they can be queued IB/ipath: Reset the retry counter for RDMA_READ_RESPONSE_MIDDLE packets IB/ipath: Fix error completion put on send CQ instead of recv CQ IB/ipath: Fix RC QP initialization IB/ipath: Fix potentially wrong RNR retry counter returned in ipath_query_qp() IB/ipath: Fix IB compliance problems with link state vs physical state
2008-03-13Merge branch 'fixes' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/djbw/async_tx * 'fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/djbw/async_tx: async_tx: checkpatch says s/__FUNCTION__/__func__/g iop-adma.c: replace remaining __FUNCTION__ occurrences fsldma: Add a completed cookie updated action in DMA finish interrupt. fsldma: Add device_prep_dma_interrupt support to fsldma.c dmaengine: Fix a bug about BUG_ON() on DMA engine capability DMA_INTERRUPT. fsldma: Fix fsldma.c warning messages when it's compiled under PPC64.