IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
When truncating an UBI volume, UBI should allocates a PEB-sized
buffer but does not release it, which leads to memory leaks.
This patch fixes the issue.
Reported-by: Marek Skuczynski <mareksk7@gmail.com>
Signed-off-by: Artem Bityutskiy <Artem.Bityutskiy@nokia.com>
Tested-by: Marek Skuczynski <mareksk7@gmail.com>
Cc: stable@kernel.org
With this, mc13783 subsystems drivers can configure the mc13783 chip
reading and writing registers.
Signed-off-by: Alberto Panizzo <maramaopercheseimorto@gmail.com>
Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
No need to set the security key when writing to it.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Cc: stable@kernel.org
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
This patch abstracts out the CNF area code from tmio_mmc which
is not present in all hardware that can use this driver. This
is required so that we can support non-toshiba based hardware.
ASIC3 support by Philipp Zabel
Signed-off-by: Ian Molton <ian@mnementh.co.uk>
Signed-off-by: Magnus Damm <damm@opensource.se>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
If irq == WM8350_NUM_IRQ that would put us past the end of the array.
Signed-off-by: Dan Carpenter <error27@gmail.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
On most cards the DisplayPort connector is created with 2 encoders sharing
a single SOR (for native DP, and for DVI-over-DP). The previous logic
for turning off unused encoders didn't take into account that we could
have multiple drm_encoders on a single hw encoder and ended up turning off
encoders that were actually being used still.
This patch fixes that issue. We probably want to look at something a bit
better later on, and only expose one drm_encoder per hw encoder block.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
GPU pointer to the structure is shifted right by 10 bits, so we need to
align to 1024 bytes, not 256.
Reported-by: Maarten Maathuis <madman2003@gmail.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Currently, we take down the sgdma engine without evicting all buffers
from VRAM.
The TTM device release will try to evict anything in VRAM to GART
memory, but this will fail since sgdma has already been taken down.
This causes an infinite loop in kernel mode on module unload.
It usually doesn't happen because there aren't any buffer on close.
However, if the GPU is locked up, this condition is easily triggered.
This patch fixes it in the simplest way possible by cleaning VRAM
right before cleaning SGDMA memory.
Signed-off-by: Luca Barbieri <luca@luca-barbieri.com>
Signed-off-by: Francisco Jerez <currojerez@riseup.net>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Currently Nouveau is unable to dismiss DMA_VTX_PROTECTION errors,
which results in an infinite loop in the interrupt handler.
These errors are caused both by bugs in the Gallium driver and by
user-specified index buffers with out of bounds indices.
By mmio-tracing the nVidia drivers, I found out how this is done.
On DMA_VTX_PROTECTION, The nVidia driver reads the register 0x402000,
always getting the value 4, and then writes 4 back to 0x402000.
This patch adds that logic by reading 0x402000 and writing the same
value back.
It's unclear what should happen if the value read is not 4, and
the current approach might not be the correct one.
To test this, modify mesa/progs/trivial/vbo-drawrange.c, defining
ELTOBJ to 1 and replacing indices with huge out of bounds integers.
Without this patch, the GPU and/or kernel should lock up.
With this patch, it should misrender as expected but not lock up.
The errors are still logged since they are useful for development.
This has been tested on NV49 and may not work on other cards.
To find out how things work on other cards, run the aforementioned
test using the blob with mmiotrace and grep for a read of the PGRAPH
source register.
Signed-off-by: Luca Barbieri <luca@luca-barbieri.com>
Signed-off-by: Francisco Jerez <currojerez@riseup.net>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Can be triggered easily on certain cards (NV46 and NV50 of mine) by
running "dmesg", the DRM's channel will lockup.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
When removing several devices aic79xx will occasionally Oops
in ahd_handle_nonpkt_busfree during rescan. Looking at the
code I found that we're indeed not checking if the scb in
question is NULL. So check for it before accessing it.
Signed-off-by: Hannes Reinecke <hare@suse.de>
Signed-off-by: James Bottomley <James.Bottomley@suse.de>
The hardware used with zfcp provides a timer for CT and ELS requests
instead of an abort capability for these commands. To correctly handle
the FC BSG timeouts, pass the timeout from the BSG requests to the
hardware.
Signed-off-by: Swen Schillig <swen@vnet.ibm.com>
Signed-off-by: James Bottomley <James.Bottomley@suse.de>
Introduce a zfcp callback for timeouts triggered from FC BSG. With
zfcp, the underlying hardware cannot abort CT or ELS requests, so
there is nothing to do when the block layer timeout expires. To avoid
interference with the block layer timeout, simply indicate that the
block layer timer should be reset. The timer running in the hardware
for the pending CT or ELS request will return the request when it
expires.
Signed-off-by: Swen Schillig <swen@vnet.ibm.com>
Signed-off-by: Christof Schmitt <christof.schmitt@de.ibm.com>
Signed-off-by: James Bottomley <James.Bottomley@suse.de>
The hardware used with zfcp cannot abort a currently pending CT or ELS
request. Therefore we need the option to postpone the timeout
triggered request abort within the fc layer, since there is nothing
zfcp can do to stop the request at this point.
Cc: James Smart <James.Smart@emulex.com>
Signed-off-by: Swen Schillig <swen@vnet.ibm.com>
Signed-off-by: Christof Schmitt <christof.schmitt@de.ibm.com>
Signed-off-by: James Bottomley <James.Bottomley@suse.de>
Advance the correct pointer when inserting the linebreak for the HBA
trace. It was missing in the output since the pointer to the output
buffer was never advanced, and the linebreak character was overwritten
later.
Reviewed-by: Swen Schillig <swen@vnet.ibm.com>
Signed-off-by: Christof Schmitt <christof.schmitt@de.ibm.com>
Signed-off-by: James Bottomley <James.Bottomley@suse.de>
The patch "zfcp: Simplify handling of ct and els requests"
accidentally removed the call to zfcp_fc_wka_port_put for FC CT BSG
requests, thus not issuing a "close" request for the WKA ports.
Introduce a CT specific handler to first call zfcp_fc_wka_port_put and
then continue with the generic handler when returning from FC CT BSG
requests.
Reviewed-by: Swen Schillig <swen@vnet.ibm.com>
Signed-off-by: Christof Schmitt <christof.schmitt@de.ibm.com>
Signed-off-by: James Bottomley <James.Bottomley@suse.de>
The driver did not account for non-tape devices needing to employ
proper FCP2 recovery. Driver now checks the FCP2-capable flag
only, rather than using a midlayer-determined flag (TYPE_TAPE).
Signed-off-by: Andrew Vasquez <andrew.vasquez@qlogic.com>
Signed-off-by: Giridhar Malavali <giridhar.malavali@qlogic.com>
Signed-off-by: James Bottomley <James.Bottomley@suse.de>
Because of the terrible structuring of scsi-bidi-commands
it breaks some of the life time rules of a scsi-command.
It is now not allowed to free up the block-request before
cleanup and partial deallocation of the scsi-command. (Which
is not so for none bidi commands)
The right fix to this problem would be to make bidi command
a first citizen by allocating a scsi_sdb pointer at scsi command
just like cmd->prot_sdb. The bidi sdb should be allocated/deallocated
as part of the get/put_command (Again like the prot_sdb) and the
current decoupling of scsi_cmnd and blk-request should be kept.
For now make sure scsi_release_buffers() is called before the
call to blk_end_request_all() which might cause the suicide of
the block requests. At best the leak of bidi buffers, at worse
a crash, as there is a race between the existence of the bidi_request
and the free of the associated bidi_sdb.
The reason this was never hit before is because only OSD has the potential
of doing asynchronous bidi commands. (So does bsg but it is never used)
And OSD clients just happen to do all their bidi commands synchronously, up
until recently.
CC: Stable Tree <stable@kernel.org>
Signed-off-by: Boaz Harrosh <bharrosh@panasas.com>
Signed-off-by: James Bottomley <James.Bottomley@suse.de>
Since commit 9d2e9d66a3f032667934144cd61c396ba49f090d
mptsas driver fails to allocate memory for the MPT chain buffers
for second LSI adapter on PPC440SPe Katmai platform:
...
ioc1: LSISAS1068E B3: Capabilities={Initiator}
mptbase: ioc1: ERROR - Unable to allocate Reply, Request, Chain Buffers!
mptbase: ioc1: ERROR - didn't initialize properly! (-3)
mptsas: probe of 0002:31:00.0 failed with error -3
This commit increased MPT_FC_CAN_QUEUE value but initChainBuffers()
doesn't differentiate between SAS and FC causing increased allocation
for SAS case, too. Later pci_alloc_consistent() fails to allocate
increased chain buffer pool size for SAS case.
Provide a fix by looking at the bus type and using appropriate
MPT_SAS_CAN_QUEUE value while calculation of the number of chain
buffers.
Signed-off-by: Anatolij Gustschin <agust@denx.de>
Acked-by: Kashyap Desai <kashyap.desai@lsi.com>
Cc: Stable Tree <stable@kernel.org>
Signed-off-by: James Bottomley <James.Bottomley@suse.de>
These particular problems were reported by Cisco and SAP and customers
as well. Cisco reported on RHEL4 U6 and SAP reported on SLES9 SP4 and
SLES10 SP2. We added these fixes on RHEL4 U6 and gave a private build
to IBM and Cisco. Cisco and IBM tested it for more than 15 days and
they reported that they did not see the issue so far. Before the fix,
Cisco used to see the issue within 5 days. We generated a patch for
SLES9 SP4 and SLES10 SP2 and submitted to Novell. Novell applied the
patch and gave a test build to SAP. SAP tested and reported that the
build is working properly.
We also tested in our lab using the tools "dishogsync", which is IO
stress tool and the tool was provided by Cisco.
Issue1: File System going into read-only mode
Root cause: The driver tends to not free the memory (FIB) when the
management request exits prematurely. The accumulation of such
un-freed memory causes the driver to fail to allocate anymore memory
(FIB) and hence return 0x70000 value to the upper layer, which puts
the file system into read only mode.
Fix details: The fix makes sure to free the memory (FIB) even if the
request exits prematurely hence ensuring the driver wouldn't run out
of memory (FIBs).
Issue2: False Raid Alert occurs
When the Physical Drives and Logical drives are reported as deleted or
added, even though there is no change done on the system
Root cause: Driver IOCTLs is signaled with EINTR while waiting on
response from the lower layers. Returning "EINTR" will never initiate
internal retry.
Fix details: The issue was fixed by replacing "EINTR" with
"ERESTARTSYS" for mid-layer retries.
Signed-off-by: Penchala Narasimha Reddy <ServeRAIDDriver@hcl.in>
Signed-off-by: James Bottomley <James.Bottomley@suse.de>
lpfc_hbadisc.c and lpfc_hw4.h accidentally got set executable.
Reported-by: Thomas Backlund <tmb@mandriva.org>
Cc: James Smart <James.Smart@Emulex.Com>
Signed-off-by: James Bottomley <James.Bottomley@suse.de>
WARNING: drivers/media/dvb/mantis/built-in.o(.devinit.text+0x13d7): Section mismatch in reference from the function mantis_pci_probe() to the function .devexit.text:mantis_i2c_exit()
The function __devinit mantis_pci_probe() references
a function __devexit mantis_i2c_exit().
This is often seen when error handling in the init function
uses functionality in the exit path.
The fix is often to remove the __devexit annotation of
mantis_i2c_exit() so it may be used outside an exit section.
WARNING: drivers/media/dvb/mantis/built-in.o(.devinit.text+0x1433): Section mismatch in reference from the function mantis_pci_probe() to the function .devexit.text:mantis_pci_exit()
The function __devinit mantis_pci_probe() references
a function __devexit mantis_pci_exit().
This is often seen when error handling in the init function
uses functionality in the exit path.
The fix is often to remove the __devexit annotation of
mantis_pci_exit() so it may be used outside an exit section.
WARNING: drivers/media/dvb/mantis/built-in.o(.devinit.text+0x185e): Section mismatch in reference from the function hopper_pci_probe() to the function
.devexit.text:mantis_i2c_exit()
The function __devinit hopper_pci_probe() references
a function __devexit mantis_i2c_exit().
This is often seen when error handling in the init function
uses functionality in the exit path.
The fix is often to remove the __devexit annotation of
mantis_i2c_exit() so it may be used outside an exit section.
WARNING: drivers/media/dvb/mantis/built-in.o(.devinit.text+0x18ba): Section mismatch in reference from the function hopper_pci_probe() to the function .devexit.text:mantis_pci_exit()
The function __devinit hopper_pci_probe() references
a function __devexit mantis_pci_exit().
This is often seen when error handling in the init function
uses functionality in the exit path.
The fix is often to remove the __devexit annotation of
mantis_pci_exit() so it may be used outside an exit section.
WARNING: drivers/media/dvb/built-in.o(.devinit.text+0x68b8): Section mismatch in reference from the function mantis_pci_probe() to the function .devexit.text:mantis_i2c_exit()
The function __devinit mantis_pci_probe() references
a function __devexit mantis_i2c_exit().
This is often seen when error handling in the init function
uses functionality in the exit path.
The fix is often to remove the __devexit annotation of
mantis_i2c_exit() so it may be used outside an exit section.
WARNING: drivers/media/dvb/built-in.o(.devinit.text+0x6914): Section mismatch in reference from the function mantis_pci_probe() to the function .devexit.text:mantis_pci_exit()
The function __devinit mantis_pci_probe() references
a function __devexit mantis_pci_exit().
This is often seen when error handling in the init function
uses functionality in the exit path.
The fix is often to remove the __devexit annotation of
mantis_pci_exit() so it may be used outside an exit section.
WARNING: drivers/media/dvb/built-in.o(.devinit.text+0x6d3f): Section mismatch in reference from the function hopper_pci_probe() to the function .devexit.text:mantis_i2c_exit()
The function __devinit hopper_pci_probe() references
a function __devexit mantis_i2c_exit().
This is often seen when error handling in the init function
uses functionality in the exit path.
The fix is often to remove the __devexit annotation of
mantis_i2c_exit() so it may be used outside an exit section.
WARNING: drivers/media/dvb/built-in.o(.devinit.text+0x6d9b): Section mismatch in reference from the function hopper_pci_probe() to the function .devexit.text:mantis_pci_exit()
The function __devinit hopper_pci_probe() references
a function __devexit mantis_pci_exit().
This is often seen when error handling in the init function
uses functionality in the exit path.
The fix is often to remove the __devexit annotation of
mantis_pci_exit() so it may be used outside an exit section.
WARNING: drivers/media/built-in.o(.devinit.text+0x14634): Section mismatch in reference from the function mantis_pci_probe() to the function .devexit.text:mantis_i2c_exit()
The function __devinit mantis_pci_probe() references
a function __devexit mantis_i2c_exit().
This is often seen when error handling in the init function
uses functionality in the exit path.
The fix is often to remove the __devexit annotation of
mantis_i2c_exit() so it may be used outside an exit section.
WARNING: drivers/media/built-in.o(.devinit.text+0x14690): Section mismatch in reference from the function mantis_pci_probe() to the function .devexit.text:mantis_pci_exit()
The function __devinit mantis_pci_probe() references
a function __devexit mantis_pci_exit().
This is often seen when error handling in the init function
uses functionality in the exit path.
The fix is often to remove the __devexit annotation of
mantis_pci_exit() so it may be used outside an exit section.
WARNING: drivers/media/built-in.o(.devinit.text+0x14abb): Section mismatch in reference from the function hopper_pci_probe() to the function .devexit.text:mantis_i2c_exit()
The function __devinit hopper_pci_probe() references
a function __devexit mantis_i2c_exit().
This is often seen when error handling in the init function
uses functionality in the exit path.
The fix is often to remove the __devexit annotation of
mantis_i2c_exit() so it may be used outside an exit section.
WARNING: drivers/media/built-in.o(.devinit.text+0x14b17): Section mismatch in reference from the function hopper_pci_probe() to the function .devexit.text:mantis_pci_exit()
The function __devinit hopper_pci_probe() references
a function __devexit mantis_pci_exit().
This is often seen when error handling in the init function
uses functionality in the exit path.
The fix is often to remove the __devexit annotation of
mantis_pci_exit() so it may be used outside an exit section.
Acked-by: Manu Abraham <manu@linuxtv.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
drivers/media/dvb/mantis/mantis_pci.c: In function ‘mantis_pci_init’:
drivers/media/dvb/mantis/mantis_pci.c:76: warning: ‘DMA_nnBIT_MASK’ is deprecated
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Thanks to Matthias Wachter <mathias@waechter.wiz.at>
for pointing it out.
Signed-off-by: Manu Abraham <manu@linuxtv.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
* Initial go at VP-3028, VP-3030 devices.
* I2C communication improvements,
* Add TDA665x support
Signed-off-by: Manu Abraham <manu@linuxtv.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Do not rely on the PCI ID alone
Signed-off-by: Niklas Edmundsson <nikke@acc.umu.se>
Signed-off-by: Manu Abraham <manu@linuxtv.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
