- 25 2月, 2010 7 次提交
-
-
由 Or Gerlitz 提交于
Remove unnecessary checks for the IB connection state and for QP overflow, as conn state changes are reported by iSER to libiscsi and handled there. QP overflow is theoretically possible only when unsolicited data-outs are used; anyway it's being checked and handled by HW drivers. Signed-off-by: NOr Gerlitz <ogerlitz@voltaire.com> Signed-off-by: NRoland Dreier <rolandd@cisco.com>
-
由 Or Gerlitz 提交于
Two minor flows in iSER's data path still use allocations; move them to be atomic as a preperation step towards moving to use libiscsi passthrough mode. Signed-off-by: NOr Gerlitz <ogerlitz@voltaire.com> Signed-off-by: NRoland Dreier <rolandd@cisco.com>
-
由 Or Gerlitz 提交于
Simplify and shrink the logic/code used for the send descriptors. Changes include removing struct iser_dto (an unnecessary abstraction), using struct iser_regd_buf only for handling SCSI commands, using dma_sync instead of dma_map/unmap, etc. Signed-off-by: NOr Gerlitz <ogerlitz@voltaire.com> Signed-off-by: NRoland Dreier <rolandd@cisco.com>
-
由 Or Gerlitz 提交于
Use a different CQ for send completions, where send completions are polled by the interrupt-driven receive completion handler. Therefore, interrupts aren't used for the send CQ. Signed-off-by: NOr Gerlitz <ogerlitz@voltaire.com> Signed-off-by: NRoland Dreier <rolandd@cisco.com>
-
由 Or Gerlitz 提交于
Now that both the posting and reaping of receive buffers is done in the completion path, the counter of outstanding buffers not be atomic. Signed-off-by: NOr Gerlitz <ogerlitz@voltaire.com> Signed-off-by: NRoland Dreier <rolandd@cisco.com>
-
由 Or Gerlitz 提交于
Currently, the recv buffer posting logic is based on the transactional nature of iSER which allows for posting a buffer before sending a PDU. Change this to post only when the number of outstanding recv buffers is below a water mark and in a batched manner, thus simplifying and optimizing the data path. Use a pre-allocated ring of recv buffers instead of allocating from kmem cache. A special treatment is given to the login response buffer whose size must be 8K unlike the size of buffers used for any other purpose which is 128 bytes. Signed-off-by: NOr Gerlitz <ogerlitz@voltaire.com> Signed-off-by: NRoland Dreier <rolandd@cisco.com>
-
由 Or Gerlitz 提交于
We will make a major change in the recv buffer posting logic, after which the problem commit bba7ebba "avoid recv buffer exhaustion caused by unexpected PDUs" comes to solve doesn't exist any more, so revert it. Signed-off-by: NOr Gerlitz <ogerlitz@voltaire.com> Signed-off-by: NRoland Dreier <rolandd@cisco.com>
-
- 12 2月, 2010 5 次提交
-
-
由 Peter Tyser 提交于
Some unused, unsupported debug code existed in the mpc85xx EDAC driver that resulted in a build failure when CONFIG_EDAC_DEBUG was defined: drivers/edac/mpc85xx_edac.c: In function 'mpc85xx_mc_err_probe': drivers/edac/mpc85xx_edac.c:1031: error: implicit declaration of function 'edac_mc_register_mcidev_debug' drivers/edac/mpc85xx_edac.c:1031: error: 'debug_attr' undeclared (first use in this function) drivers/edac/mpc85xx_edac.c:1031: error: (Each undeclared identifier is reported only once drivers/edac/mpc85xx_edac.c:1031: error: for each function it appears in.) Signed-off-by: NPeter Tyser <ptyser@xes-inc.com> Signed-off-by: Doug Thompson <dougthompson@xmission.com Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
由 Peter Tyser 提交于
Commit b4846251 ("edac: mpc85xx add mpc83xx support") accidentally broke how a chip select's first and last page addresses are calculated. The page addresses are being shifted too far right by PAGE_SHIFT. This results in errors such as: EDAC MPC85xx MC1: Err addr: 0x003075c0 EDAC MPC85xx MC1: PFN: 0x00000307 EDAC MPC85xx MC1: PFN out of range! EDAC MC1: INTERNAL ERROR: row out of range (4 >= 4) EDAC MC1: CE - no information available: INTERNAL ERROR The vaule of PAGE_SHIFT is already being taken into consideration during the calculation of the 'start' and 'end' variables, thus it is not necessary to account for it again when setting a chip select's first and last page address. Signed-off-by: NPeter Tyser <ptyser@xes-inc.com> Signed-off-by: NDoug Thompson <dougthompson@xmission.com> Cc: Ira W. Snyder <iws@ovro.caltech.edu> Cc: Kumar Gala <galak@gate.crashing.org> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
由 Johan Kristell 提交于
This patch fixes a bug in the multiblock write tests where the written data is read back for verifying one block at a time. The tests in mmc_test assumes that all cards are byte addressable. This will cause the multi block write tests to fail, leading the user of the mmc_test driver thinking there is something wrong with the sdhci driver they are testing. The start address for the block is calculated as: blocknum * 512. For block addressable cards the blocknum alone should be used. Signed-off-by: NJohan Kristell <johan.kristell@axis.com> Cc: <linux-mmc@vger.kernel.org> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
由 Marcel Selhorst 提交于
When suspending, tpm_infineon calls the generic suspend function of the TPM framework. However, the TPM framework does not return and the system hangs upon suspend. When sending the necessary command "TPM_SaveState" directly within the driver, suspending and resuming works fine. Signed-off-by: NMarcel Selhorst <m.selhorst@sirrix.com> Cc: OGAWA Hirofumi <hirofumi@mail.parknet.co.jp> Cc: Debora Velarde <debora@linux.vnet.ibm.com> Cc: Rajiv Andrade <srajiv@linux.vnet.ibm.com> Cc: <stable@kernel.org> [2.6.32.x] Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
由 Borislav Petkov 提交于
An unfortunate "WARNING" in the message amd64_edac dumps when the system doesn't support DRAM ECC or ECC checking is not enabled in the BIOS used to trigger kerneloops which qualified the message as an OOPS thus misleading the users. See, e.g. https://bugs.launchpad.net/ubuntu/+source/linux/+bug/422536 http://bugzilla.kernel.org/show_bug.cgi?id=15238 Downgrade the message level to KERN_NOTICE and fix the formulation. Cc: stable@kernel.org # .32.x Signed-off-by: NBorislav Petkov <borislav.petkov@amd.com> Acked-by: NDoug Thompson <dougthompson@xmission.com>
-
- 11 2月, 2010 13 次提交
-
-
由 Andy Getzendanner 提交于
This patch corrects a userspace pointer dereference in the VGA arbiter in 2.6.32.1. copy_from_user() is used at line 822 to copy the contents of buf into kbuf, but a call to strncmp() on line 964 uses buf rather than kbuf. This problem led to a GPF in strncmp() when X was started on my x86_32 systems. X triggered the behavior with a write of "target PCI:0000:01:00.0" to /dev/vga_arbiter. The patch has been tested against 2.6.32.1 and observed to correct the GPF observed when starting X or manually writing the string "target PCI:0000:01:00.0" to /dev/vga_arbiter. Signed-off-by: NAndy Getzendanner <james.getzendanner@students.olin.edu> Cc: Jesse Barnes <jbarnes@virtuousgeek.org> Cc: <stable@kernel.org> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Dave Airlie 提交于
ATOM appears to return 0x20 which seems to mean some sort of timeout. retry the transaction up to 10 times before failing, this makes DP->VGA convertor we bought work at least a bit more predictably. Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Pauli Nieminen 提交于
radeon_copy_dma is only available for r200 or newer cards. Call to radeon_copy_dma would result to NULL pointer dereference if benchmarking asic without dma engine. Signed-off-by: NPauli Nieminen <suokkos@gmail.com> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Thomas Hellstrom 提交于
Signed-off-by: NThomas Hellstrom <thellstrom@vmware.com> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Jakob Bornecrantz 提交于
Even if this bumps the version to 1 it does not mean the driver is out of staging. From what we know this is the last backwards incompatible change to the driver. Signed-off-by: NJakob Bornecrantz <jakob@vmware.com> Signed-off-by: NThomas Hellstrom <thellstrom@vmware.com> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Jakob Bornecrantz 提交于
Signed-off-by: NJakob Bornecrantz <jakob@vmware.com> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Thomas Hellstrom 提交于
When time-based throttling is implemented, we need to bump minor. When the old way of detecting scanout is removed, we need to bump major. In the meantime, this change should not break existing user-space. Signed-off-by: NThomas Hellstrom <thellstrom@vmware.com> Signed-off-by: NJakob Bornecrantz <jakob@vmware.com> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Dave Airlie 提交于
This memset_io was added to debug something way back and got left behind, memset the fb to black so the borders don't be all white. Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Matthew Garrett 提交于
Signed-off-by: NMatthew Garrett <mjg@redhat.com> Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Marcin Slusarz 提交于
Reported-by: NDan Carpenter <error27@gmail.com> Signed-off-by: NMarcin Slusarz <marcin.slusarz@gmail.com> Signed-off-by: NMaarten Maathuis <madman2003@gmail.com> Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Sean Hefty 提交于
Revert the following change from commit 6f8372b6 ("RDMA/cm: fix loopback address support") The defined behavior of rdma_bind_addr is to associate an RDMA device with an rdma_cm_id, as long as the user specified a non- zero address. (ie they weren't just trying to reserve a port) Currently, if the loopback address is passed to rdma_bind_addr, no device is associated with the rdma_cm_id. Fix this. It turns out that important apps such as Open MPI depend on rdma_bind_addr() NOT associating any RDMA device when binding to a loopback address. Open MPI is being updated to deal with this, but at least until a new Open MPI release is available, maintain the previous behavior: allow rdma_bind_addr() to succeed, but do not bind to a device. Signed-off-by: NSean Hefty <sean.hefty@intel.com> Acked-by: NSteve Wise <swise@opengridcomputing.com> Signed-off-by: NRoland Dreier <rolandd@cisco.com>
-
由 Julia Lawall 提交于
cohd_fin has already been verified not to be NULL, so the argument to BUG_ON cannot be true. A simplified version of the semantic match that finds this problem is as follows: (http://coccinelle.lip6.fr/) // <smpl> @r@ expression *x; expression e; identifier l; @@ if (x == NULL || ...) { ... when forall return ...; } ... when != goto l; when != x = e when != &x *x == NULL // </smpl> Signed-off-by: NJulia Lawall <julia@diku.dk> Acked-by: NLinus Walleij <linus.walleij@stericsson.com> Signed-off-by: NDan Williams <dan.j.williams@intel.com>
-
由 Guennadi Liakhovetski 提交于
If submitting new buffer failed, a wrong descriptor gets completed and it doesn't check, if a callback is at all defined, which can lead to an Oops. Fix these bugs and make ipu_update_channel_buffer() void, because it never fails. Signed-off-by: NGuennadi Liakhovetski <g.liakhovetski@gmx.de> Signed-off-by: NDan Williams <dan.j.williams@intel.com>
-
- 10 2月, 2010 7 次提交
-
-
由 NeilBrown 提交于
====== This fix is related to http://bugzilla.kernel.org/show_bug.cgi?id=15142 but does not address that exact issue. ====== sysfs does like attributes being removed while they are being accessed (i.e. read or written) and waits for the access to complete. As accessing some md attributes takes the same lock that is held while removing those attributes a deadlock can occur. This patch addresses 3 issues in md that could lead to this deadlock. Two relate to calling flush_scheduled_work while the lock is held. This is probably a bad idea in general and as we use schedule_work to delete various sysfs objects it is particularly bad. In one case flush_scheduled_work is called from md_alloc (called by md_probe) called from do_md_run which holds the lock. This call is only present to ensure that ->gendisk is set. However we can be sure that gendisk is always set (though possibly we couldn't when that code was originally written. This is because do_md_run is called in three different contexts: 1/ from md_ioctl. This requires that md_open has succeeded, and it fails if ->gendisk is not set. 2/ from writing a sysfs attribute. This can only happen if the mddev has been registered in sysfs which happens in md_alloc after ->gendisk has been set. 3/ from autorun_array which is only called by autorun_devices, which checks for ->gendisk to be set before calling autorun_array. So the call to md_probe in do_md_run can be removed, and the check on ->gendisk can also go. In the other case flush_scheduled_work is being called in do_md_stop, purportedly to wait for all md_delayed_delete calls (which delete the component rdevs) to complete. However there really isn't any need to wait for them - they have already been disconnected in all important ways. The third issue is that raid5->stop() removes some attribute names while the lock is held. There is already some infrastructure in place to delay attribute removal until after the lock is released (using schedule_work). So extend that infrastructure to remove the raid5_attrs_group. This does not address all lockdep issues related to the sysfs "s_active" lock. The rest can be address by splitting that lockdep context between symlinks and non-symlinks which hopefully will happen. Signed-off-by: NNeilBrown <neilb@suse.de>
-
由 Maarten Maathuis 提交于
Unset the bit that indicates that a ctxprog can continue at the end. Signed-off-by: NMaarten Maathuis <madman2003@gmail.com> Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Maarten Maathuis 提交于
ramfc is zero'ed upon destruction, so it's safer to do things in the right order. Signed-off-by: NMaarten Maathuis <madman2003@gmail.com> Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Maarten Maathuis 提交于
- We need to disable pgraph fifo access before checking the current channel, otherwise we could still hit a running ctxprog. - The writes to 0x400500 are already handled by pgraph->fifo_access and are therefore redundant, moreover pgraph fifo access should not be reenabled before current context is set as invalid. So remove them altogether. Signed-off-by: NMaarten Maathuis <madman2003@gmail.com> Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Maarten Maathuis 提交于
- In the current situation the padding that is added is dangerous to write to, userspace could potentially overwrite parts of another bo. - Depth and stencil buffers are supposed to be large enough in general so the waste of memory should be acceptable. - Alternatives are hiding the padding from users or splitting vram into 2 zones. Signed-off-by: NMaarten Maathuis <madman2003@gmail.com> Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Ben Skeggs 提交于
Fixes DVI+VGA on my 9400, and likely a lot of other configurations that got broken by the previos DVI-over-DP fix. Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Ben Skeggs 提交于
With DVI and DP plugged, the DVI clock change interrupts being run can cause DP link training to fail. This adds a spinlock around init table parsing to prevent this. Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
- 09 2月, 2010 8 次提交
-
-
由 Jan Glauber 提交于
If a CHPID is offline during a device shutdown the ccw_device_halt|clear may fail and the qdio device stays in state STOPPED until the shutdown is finished. If an interrupt occurs before the device is set to INACTIVE the STOPPED state triggers a WARN_ON in the interrupt handler. Prevent this WARN_ON by catching the STOPPED state in the interrupt handler. Signed-off-by: NJan Glauber <jang@linux.vnet.ibm.com> Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
-
由 Ursula Braun 提交于
Inbound traffic handling may hang if next buffer to check is in state ERROR, polling is stopped and the final check for further available inbound buffers disregards buffers in state ERROR. This patch includes state ERROR when checking availability of more inbound buffers. Cc: Jan Glauber <jang@linux.vnet.ibm.com> Signed-off-by: NUrsula Braun <ursula.braun@de.ibm.com> Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
-
由 Julia Lawall 提交于
Test the value that was just allocated rather than the previously tested one. A simplified version of the semantic match that finds this problem is as follows: (http://coccinelle.lip6.fr/) // <smpl> @r@ expression *x; expression e; identifier l; @@ if (x == NULL || ...) { ... when forall return ...; } ... when != goto l; when != x = e when != &x *x == NULL // </smpl> Signed-off-by: NJulia Lawall <julia@diku.dk> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Divy Le Ray 提交于
Verify the HW checksum state for frames handed to GRO processing. Signed-off-by: NDivy Le Ray <divy@chelsio.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 NeilBrown 提交于
This code was written long ago when it was not possible to reshape a degraded array. Now it is so the current level of degraded-ness needs to be taken in to account. Also newly addded devices should only reduce degradedness if they are deemed to be in-sync. In particular, if you convert a RAID5 to a RAID6, and increase the number of devices at the same time, then the 5->6 conversion will make the array degraded so the current code will produce a wrong value for 'degraded' - "-1" to be precise. If the reshape runs to completion end_reshape will calculate a correct new value for 'degraded', but if a device fails during the reshape an incorrect decision might be made based on the incorrect value of "degraded". This patch is suitable for 2.6.32-stable and if they are still open, 2.6.31-stable and 2.6.30-stable as well. Cc: stable@kernel.org Reported-by: NMichael Evans <mjevans1983@gmail.com> Signed-off-by: NNeilBrown <neilb@suse.de>
-
由 Ben Skeggs 提交于
Writes don't return a count, and adding the check broke native DP. Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Ben Skeggs 提交于
It appears we aren't required to do memory sizing ourselves on nv40 either. NV40 init tables read a strap from PEXTDEV_BOOT_0 into a CRTC register, and then later use that value to select a memory configuration (written to PFB_CFG0, just like INIT_COMPUTE_MEM on earlier cards) with INIT_IO_RESTRICT_PROG. Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Marcin Kościelnicki 提交于
Signed-off-by: NMarcin Kościelnicki <koriakin@0x04.net> Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-