handle_stripe5 and handle_stripe6 have very deep logic paths handling the
various states of a stripe_head. By introducing the 'stripe_head_state'
and 'r6_state' objects, large portions of the logic can be moved to
sub-routines.
'struct stripe_head_state' consumes all of the automatic variables that previously
stood alone in handle_stripe5,6. 'struct r6_state' contains the handle_stripe6
specific variables like p_failed and q_failed.
One of the nice side effects of the 'stripe_head_state' change is that it
allows for further reductions in code duplication between raid5 and raid6.
The following new routines are shared between raid5 and raid6:
handle_completed_write_requests
handle_requests_to_failed_array
handle_stripe_expansion
Changes:
* v2: fixed 'conf->raid_disk-1' for the raid6 'handle_stripe_expansion' path
* v3: removed the unused 'dirty' field from struct stripe_head_state
* v3: coalesced open coded bi_end_io routines into return_io()
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Acked-By: NeilBrown <neilb@suse.de>
The async_tx api provides methods for describing a chain of asynchronous
bulk memory transfers/transforms with support for inter-transactional
dependencies. It is implemented as a dmaengine client that smooths over
the details of different hardware offload engine implementations. Code
that is written to the api can optimize for asynchronous operation and the
api will fit the chain of operations to the available offload resources.
I imagine that any piece of ADMA hardware would register with the
'async_*' subsystem, and a call to async_X would be routed as
appropriate, or be run in-line. - Neil Brown
async_tx exploits the capabilities of struct dma_async_tx_descriptor to
provide an api of the following general format:
struct dma_async_tx_descriptor *
async_<operation>(..., struct dma_async_tx_descriptor *depend_tx,
dma_async_tx_callback cb_fn, void *cb_param)
{
struct dma_chan *chan = async_tx_find_channel(depend_tx, <operation>);
struct dma_device *device = chan ? chan->device : NULL;
int int_en = cb_fn ? 1 : 0;
struct dma_async_tx_descriptor *tx = device ?
device->device_prep_dma_<operation>(chan, len, int_en) : NULL;
if (tx) { /* run <operation> asynchronously */
...
tx->tx_set_dest(addr, tx, index);
...
tx->tx_set_src(addr, tx, index);
...
async_tx_submit(chan, tx, flags, depend_tx, cb_fn, cb_param);
} else { /* run <operation> synchronously */
...
<operation>
...
async_tx_sync_epilog(flags, depend_tx, cb_fn, cb_param);
}
return tx;
}
async_tx_find_channel() returns a capable channel from its pool. The
channel pool is organized as a per-cpu array of channel pointers. The
async_tx_rebalance() routine is tasked with managing these arrays. In the
uniprocessor case async_tx_rebalance() tries to spread responsibility
evenly over channels of similar capabilities. For example if there are two
copy+xor channels, one will handle copy operations and the other will
handle xor. In the SMP case async_tx_rebalance() attempts to spread the
operations evenly over the cpus, e.g. cpu0 gets copy channel0 and xor
channel0 while cpu1 gets copy channel 1 and xor channel 1. When a
dependency is specified async_tx_find_channel defaults to keeping the
operation on the same channel. A xor->copy->xor chain will stay on one
channel if it supports both operation types, otherwise the transaction will
transition between a copy and a xor resource.
Currently the raid5 implementation in the MD raid456 driver has been
converted to the async_tx api. A driver for the offload engines on the
Intel Xscale series of I/O processors, iop-adma, is provided in a later
commit. With the iop-adma driver and async_tx, raid456 is able to offload
copy, xor, and xor-zero-sum operations to hardware engines.
On iop342 tiobench showed higher throughput for sequential writes (20 - 30%
improvement) and sequential reads to a degraded array (40 - 55%
improvement). For the other cases performance was roughly equal, +/- a few
percentage points. On a x86-smp platform the performance of the async_tx
implementation (in synchronous mode) was also +/- a few percentage points
of the original implementation. According to 'top' on iop342 CPU
utilization drops from ~50% to ~15% during a 'resync' while the speed
according to /proc/mdstat doubles from ~25 MB/s to ~50 MB/s.
The tiobench command line used for testing was: tiobench --size 2048
--block 4096 --block 131072 --dir /mnt/raid --numruns 5
* iop342 had 1GB of memory available
Details:
* if CONFIG_DMA_ENGINE=n the asynchronous path is compiled away by making
async_tx_find_channel a static inline routine that always returns NULL
* when a callback is specified for a given transaction an interrupt will
fire at operation completion time and the callback will occur in a
tasklet. if the the channel does not support interrupts then a live
polling wait will be performed
* the api is written as a dmaengine client that requests all available
channels
* In support of dependencies the api implicitly schedules channel-switch
interrupts. The interrupt triggers the cleanup tasklet which causes
pending operations to be scheduled on the next channel
* Xor engines treat an xor destination address differently than a software
xor routine. To the software routine the destination address is an implied
source, whereas engines treat it as a write-only destination. This patch
modifies the xor_blocks routine to take a an explicit destination address
to mirror the hardware.
Changelog:
* fixed a leftover debug print
* don't allow callbacks in async_interrupt_cond
* fixed xor_block changes
* fixed usage of ASYNC_TX_XOR_DROP_DEST
* drop dma mapping methods, suggested by Chris Leech
* printk warning fixups from Andrew Morton
* don't use inline in C files, Adrian Bunk
* select the API when MD is enabled
* BUG_ON xor source counts <= 1
* implicitly handle hardware concerns like channel switching and
interrupts, Neil Brown
* remove the per operation type list, and distribute operation capabilities
evenly amongst the available channels
* simplify async_tx_find_channel to optimize the fast path
* introduce the channel_table_initialized flag to prevent early calls to
the api
* reorganize the code to mimic crypto
* include mm.h as not all archs include it in dma-mapping.h
* make the Kconfig options non-user visible, Adrian Bunk
* move async_tx under crypto since it is meant as 'core' functionality, and
the two may share algorithms in the future
* move large inline functions into c files
* checkpatch.pl fixes
* gpl v2 only correction
Cc: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Acked-By: NeilBrown <neilb@suse.de>
The async_tx api tries to use a dma engine for an operation, but will fall
back to an optimized software routine otherwise. Xor support is
implemented using the raid5 xor routines. For organizational purposes this
routine is moved to a common area.
The following fixes are also made:
* rename xor_block => xor_blocks, suggested by Adrian Bunk
* ensure that xor.o initializes before md.o in the built-in case
* checkpatch.pl fixes
* mark calibrate_xor_blocks __init, Adrian Bunk
Cc: Adrian Bunk <bunk@stusta.de>
Cc: NeilBrown <neilb@suse.de>
Cc: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
The current implementation assumes that a channel will only be used by one
client at a time. In order to enable channel sharing the dmaengine core is
changed to a model where clients subscribe to channel-available-events.
Instead of tracking how many channels a client wants and how many it has
received the core just broadcasts the available channels and lets the
clients optionally take a reference. The core learns about the clients'
needs at dma_event_callback time.
In support of multiple operation types, clients can specify a capability
mask to only be notified of channels that satisfy a certain set of
capabilities.
Changelog:
* removed DMA_TX_ARRAY_INIT, no longer needed
* dma_client_chan_free -> dma_chan_release: switch to global reference
counting only at device unregistration time, before it was also happening
at client unregistration time
* clients now return dma_state_client to dmaengine (ack, dup, nak)
* checkpatch.pl fixes
* fixup merge with git-ioat
Cc: Chris Leech <christopher.leech@intel.com>
Signed-off-by: Shannon Nelson <shannon.nelson@intel.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Acked-by: David S. Miller <davem@davemloft.net>
The current dmaengine interface defines mutliple routines per operation,
i.e. dma_async_memcpy_buf_to_buf, dma_async_memcpy_buf_to_page etc. Adding
more operation types (xor, crc, etc) to this model would result in an
unmanageable number of method permutations.
Are we really going to add a set of hooks for each DMA engine
whizbang feature?
- Jeff Garzik
The descriptor creation process is refactored using the new common
dma_async_tx_descriptor structure. Instead of per driver
do_<operation>_<dest>_to_<src> methods, drivers integrate
dma_async_tx_descriptor into their private software descriptor and then
define a 'prep' routine per operation. The prep routine allocates a
descriptor and ensures that the tx_set_src, tx_set_dest, tx_submit routines
are valid. Descriptor creation and submission becomes:
struct dma_device *dev;
struct dma_chan *chan;
struct dma_async_tx_descriptor *tx;
tx = dev->device_prep_dma_<operation>(chan, len, int_flag)
tx->tx_set_src(dma_addr_t, tx, index /* for multi-source ops */)
tx->tx_set_dest(dma_addr_t, tx, index)
tx->tx_submit(tx)
In addition to the refactoring, dma_async_tx_descriptor also lays the
groundwork for definining cross-channel-operation dependencies, and a
callback facility for asynchronous notification of operation completion.
Changelog:
* drop dma mapping methods, suggested by Chris Leech
* fix ioat_dma_dependency_added, also caught by Andrew Morton
* fix dma_sync_wait, change from Andrew Morton
* uninline large functions, change from Andrew Morton
* add tx->callback = NULL to dmaengine calls to interoperate with async_tx
calls
* hookup ioat_tx_submit
* convert channel capabilities to a 'cpumask_t like' bitmap
* removed DMA_TX_ARRAY_INIT, no longer needed
* checkpatch.pl fixes
* make set_src, set_dest, and tx_submit descriptor specific methods
* fixup git-ioat merge
* move group_list and phys to dma_async_tx_descriptor
Cc: Jeff Garzik <jeff@garzik.org>
Cc: Chris Leech <christopher.leech@intel.com>
Signed-off-by: Shannon Nelson <shannon.nelson@intel.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Acked-by: David S. Miller <davem@davemloft.net>
Under kexec, I/OAT initialization breaks over busy resources because the
previous kernel did not release them.
I'm not sure this fix can be considered a complete one but it works for me.
I guess something similar to the *_remove method should occur there..
Signed-off-by: Dan Aloni <da-x@monatomic.org>
Signed-off-by: Chris Leech <christopher.leech@intel.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
There's only one now anyway, and it's not in a performance path,
so make it behave the same on 32-bit and 64-bit CPUs.
Signed-off-by: Chris Leech <christopher.leech@intel.com>
Every 20 descriptors turns out to be to few append commands with
newer/faster CPUs. Pushing every 4 still cuts down on MMIO writes to an
acceptable level without letting the DMA engine run out of work.
Signed-off-by: Chris Leech <christopher.leech@intel.com>
PIO4 is a maximum PIO mode supported by a driver. Using "255" as a max_mode
argument to ide_get_best_pio_mode() could result in wrong timings being used
by a driver (for "pio" equal to 5) or OOPS (for "pio" values > 5 && < 255).
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Acked-by: Sergei Shtylyov <sshtylyov@ru.mvista.com>
Reviewed-by: Alan Cox <alan@lxorguk.ukuu.org.uk>
The SiS966 has one additional PCI-ID 1180.
If the chipset is using this PCI-ID, the primary channel is connected to the
first PATA-port. The secondary channel is connected to SATA-ports in IDE
emulation mode. The legacy IO-ports are used.
The including of the PCI-ID into pata_sis is not sufficient, because the legacy
driver in drivers/ide is initialized before pata_sis.
Signed-off-by: Uwe Koziolek <uwe.koziolek@gmx.net>
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
In 7d12e780e0 David Howells performed
this evolution:
"IRQ: Maintain regs pointer globally rather than passing to IRQ handlers"
He correctly updated many of the function definitions that were using this
extra regs pointer parameter but forgot to update some caller sites of
those functions. The reason the modifications was not properly done on all
drivers is that some drivers were rarely compiled because they are for
AMIGA, or that some code sites were inside #ifdefs where the option is not
set or inside #if 0.
Here is the semantic patch that found the occurences
and fixed the problem.
@ rule1 @
identifier fn;
identifier irq, dev_id;
typedef irqreturn_t;
@@
static irqreturn_t fn(int irq, void *dev_id)
{
...
}
@@
identifier rule1.fn;
expression E1, E2, E3;
@@
fn(E1, E2
- ,E3
)
Signed-off-by: Yoann Padioleau <padator@wanadoo.fr>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Jeff Garzik <jeff@garzik.org>
Cc: Greg KH <greg@kroah.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
When we enable the SMCf010 IR device, the Toshiba Portege 4000 BIOS claims
the device is working, but it really isn't configured correctly. The BIOS
*will* configure it, but only if we call _SRS after (1) reversing the order
of the SIR and FIR I/O port regions and (2) changing the IRQ from
active-high to active-low.
This patch addresses the 2.6.22 regression:
"no irda0 interface (2.6.21 was OK), smsc does not find chip"
I tested this on a Portege 4000. The smsc-ircc2 driver correctly detects
the device, and "irattach irda0 -s && irdadump" shows transmitted and
received packets.
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Cc: Andrey Borzenkov <arvidjaar@mail.ru>
Cc: Samuel Ortiz <samuel@sortiz.org>
Cc: "Linus Walleij (LD/EAB)" <linus.walleij@ericsson.com>
Cc: Michal Piotrowski <michal.k.k.piotrowski@gmail.com>
Cc: Adam Belay <ambx1@neo.rr.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input:
Input: document some of keycodes
Input: add a new EV_SW SW_RADIO event, for radio switches on laptops
Input: serio - take drv_mutex in serio_cleanup()
Input: atkbd - use printk_ratelimit for spurious ACK messages
Input: atkbd - throttle LED switching
Input: i8042 - add HP Pavilion ZT1000 to the MUX blacklist
* 'merge' of git://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc:
[POWERPC] Update defconfigs
[POWERPC] Uninline and export virq_to_hw() for the pasemi_mac driver
[POWERPC] Fix PMI breakage in cbe_cbufreq driver
[POWERPC] Disable old EMAC driver in arch/powerpc
Yeah, we could have just disabled it, but there's work on a new one that
isn't as fundamentally broken, so there really doesn't seem to be any
point in keeping it around.
The recent timer cleanup broke the only valid use, and when I say
"valid", I obviously mean "totally broken". So it's not like it works,
or really even can work in the current format that uses the unsafe
"panic" LED blinking routines..
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
drivers/ide/setup-pci.c: In function 'ide_scan_pcibus':
drivers/ide/setup-pci.c:879: warning: ignoring return value of '__pci_register_driver', declared with attribute warn_unused_result
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Recently the PLL input clock of Promise 2027x is sometimes detected
higher than expected (e.g. 20.027 MHz compared to 16.714 MHz).
It seems sometimes the mdelay() function is not as precise as it
used to be. Per Alan's advice, HT or power management might affect
the precision of mdelay().
This patch calls gettimeofday() to measure the time elapsed and
calculate the PLL input clock accordingly.
Signed-off-by: Albert Lee <albertcc@tw.ibm.com>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: Bahadir Balban <bahadir.balban@gmail.com>
Acked-by: Sergei Shtylyov <sshtylyov@ru.mvista.com>
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
SWDMA modes are unsupported by it821x. Attempts to tune SWDMA modes always
fail (due to sanity check in ->speedproc) and result in PIO being tuned.
* Fix incorrect SWDMA mask so core code won't try these modes and will just
tune PIO if no other DMA modes are available.
* Bump driver version.
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Acked-by: Sergei Shtylyov <sshtylyov@ru.mvista.com>
* Driver can't skip programming transfer mode on the device in amd_set_drive()
(similar fix has been applied to via82cxxx driver ages ago).
* While at it remove redundant warning (ide_config_drive_speed() already
produces more valuable one).
* Bump driver version.
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
The HPT36x chips finally turned out to have the channel enable bits -- however,
badly implemented. Make use of them despite it's probably only going to burden
the driver's code -- assuming both channels are always enabled by the HighPoint
BIOS anyway...
Signed-off-by: Sergei Shtylyov <sshtylyov@ru.mvista.com>
Acked-by: Linas Vepstas <linas@austin.ibm.com>
Cc: michal.kepien@poczta.onet.pl
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Add the MAXTOR STM3320620A drive into the UltraDMA/66 mode blacklist
for the HPT36x chips.
Signed-off-by: Sergei Shtylyov <sshtylyov@ru.mvista.com>
Acked-by: Linas Vepstas <linas@austin.ibm.com>
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Found by a static analyser. It is in theory possible we dereference
dev->id when it has become invalid. Re-order to avoid this.
Not needed for new-ide as we no longer support the crazy exabyte nest stuff
Signed-off-by: Alan Cox <alan@redhat.com>
Cc: Andrew Morton <akpm@osdl.org>
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Look at wait_drive_not_busy in drivers/ide/ide-taskfile.c:
static u8 wait_drive_not_busy(ide_drive_t *drive)
{
ide_hwif_t *hwif = HWIF(drive);
int retries = 100;
u8 stat;
/*
* Last sector was transfered, wait until drive is ready.
* This can take up to 10 usec, but we will wait max 1 ms
* (drive_cmd_intr() waits that long).
*/
while (((stat = hwif->INB(IDE_STATUS_REG)) & BUSY_STAT) && retries--)
udelay(10);
if (!retries)
printk(KERN_ERR "%s: drive still BUSY!\n", drive->name);
return stat;
}
`printk' is never called because `retries' never holds zero at the
outside of `while' loop: when `retries' holds zero at the while's loop
condition, `retries' will hold -1 at the if condition.
Signed-off-by: Masatake YAMATO <jet@gyve.org>
Cc: Chuck Ebbert <cebbert@redhat.com>
Cc: joe@perches.com
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
if the call to budget_register() fails in ttpci_budget_int(),
ttpci_budget_init() returns success. The attached patch will
fix this problem.
Signed-off-by: Hartmut Birr <e9hack@googlemail.com>
Signed-off-by: Michael Krufky <mkrufky@linuxtv.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
Spotted and tested by Thomas Sattler <tsattler@gmx.de>.
cinergyT2.c does cancel_delayed_work() + flush_scheduled_work() while
holding cinergyt2->sem. This leads to deadlock because work->func()
needs the same mutex to complete. Another bug is that this code in fact
can't reliably stop the re-arming delayed_work.
Convert this code to use cancel_rearming_delayed_work() and move it
out of ->sem. Another mutex, ->wq_sem, was added to protect against the
concurrent open/resume.
This patch is a horrible hack to fix the lockup which happens in practice.
As Dmitry Torokhov pointed out this driver has other problems and needs
further changes.
Signed-off-by: Oleg Nesterov <oleg@tv-sign.ru>
Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
v4l-info and other programs would loop indefinitely while querying the
tuners for cx88-blackbird cards.
The cause was that vidioc_g_tuner didn't return an error value for
qctrl->id != 0, making the application think there is a never ending
list of tuners...
This patch adds the same index check as done in vidioc_g_tuner() in
cx88-video.
Signed-off-by: Jelle Foks <jelle@foks.8m.com>
Signed-off-by: Michael Krufky <mkrufky@linuxtv.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
If one uses a V4L *one* application, such as vlc or mplayer's v4l driver, as
the first user after the driver is loaded, the driver wedges itself and will
never capture properly. Even if one uses a V4L2 application later, it still
won't work.
If one uses a V4L *two* application first, such as tvtime or mplayer's v4l2
driver, then the driver will be ok. One can then run a V4L1 application, and
it will work.
It turns out the problem is with norm changing and the crop support that was
added in 2.6.21. The driver defaults to PAL, and keeps the last norm it was
set too across opens. If one changes the norm via V4L1, the cropping
parameters are not reset like they should be, and they'll remain broken across
device opens.
This patch removes the direct setting of btv->tvnorm in the V4L1 ioctl
VIDIOCSCHAN handler. The norm is set via the existing call to set_input(),
which calls set_tvnorm(), which will reset the cropping values now that it is
able to detect the norm change.
Signed-off-by: Trent Piepho <xyzzy@speakeasy.org>
Signed-off-by: Michael Krufky <mkrufky@linuxtv.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
PCMCIA doesn't use DMA and as this driver is used on many platforms we
don't want it to fail on those that define the DMA alloc API as a NULL
return
Signed-off-by: Alan Cox <alan@redhat.com>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
We got it backwards and now the other detects are fixed it shows up
Signed-off-by: Alan Cox <alan@redhat.com>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
host->irq and host->irq2 should be set before ata_host_register() for
IRQ reporting to work. Move up host->irq assignment in
ata_host_activate() and add it to ata_pci_init_one() native path and
pata_cs5520.
The port info printing in ata_host_register() doesn't fit all the
different controllers. It should probably be moved out to LLDs with
some helpers in the future.
Signed-off-by: Tejun Heo <htejun@gmail.com>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
Need to check for special case "acpi_osi=!Linux" before handling the
general case "acpi_osi=!*", or it will have no effect.
Signed-off-by: Len Brown <len.brown@intel.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* 'upstream-linus' of master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/netdev-2.6:
3c589_cs: fix local_bh_enable warning
RESEND [PATCH 3/3] NetXen: Graceful teardown of interface and hardware upon module unload
drivers/net/ns83820.c: fix a check-after-use
net/usb/cdc_ether minor sparse cleanup
RESEND [PATCH 2/3] NetXen: Support per PCI-function interrupt mask registers
RESEND [PATCH 1/3] NetXen: Fix issue of MSI not working correctly
dm9601: Return 0 from bind() on success
Update MAINTAINERS for USB network devices
usbnet: Zero padding byte if there is tail room in skb
dm9601: HW header size shouldn't be included in packet length
starfire list alpha as 64 bit arch
myri10ge: SET_NETDEV_DEV()
gianfar: Fix typo bug introduced by move to udp_hdr()
[PATCH] libertas: remove private ioctls
[PATCH] libertas: fix WPA associations by handling ENABLE_RSN correctly
[PATCH] libertas: kill wlan_scan_process_results
[PATCH] libertas: style fixes
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/ieee1394/linux1394-2.6:
firewire: add Kconfig help on building both stacks
firewire: fix async reception on big endian machines
If a page can't be allocated for the frag list of a skb, the code to
unmap the partially allocated list is off by one. For exaple, if
'frags' equals one, i == 0, and the alloc_page() fails, then the old
loop would have unmapped mapping[1] which is uninitialized. The same
would happen if the call to ib_dma_map_page() failed.
Signed-off-by: Ralph Campbell <ralph.campbell@qlogic.com>
Acked-by: Michael S. Tsirkin <mst@dev.mellanox.co.il>
Signed-off-by: Roland Dreier <rolandd@cisco.com>
Russell King wrote:
> Having upgraded from 2.6.16 to 2.6.22-rc6, I'm now seeing the following.
>
> Looks like netfilter is calling local_bh_enable() with IRQs disabled,
> which would appear to be illegal. Thankfully, this is a warn-once
> warning.
>
> WARNING: at /home/rmk/git/linux-2.6-rmk/kernel/softirq.c:138 local_bh_enable()
> [...]
> [<c01447fc>] (nf_conntrack_destroy+0x0/0x2c) from [<c012c05c>] (__kfree_skb+0xd0/0x100)
> [<c012bf8c>] (__kfree_skb+0x0/0x100) from [<c012c0d8>] (kfree_skb+0x4c/0x50)
> r5:c12a3800 r4:00000300
> [<c012c08c>] (kfree_skb+0x0/0x50) from [<bf03cbb0>] (el3_start_xmit+0xb8/0xd0 [3c589_cs])
> [<bf03caf8>] (el3_start_xmit+0x0/0xd0 [3c589_cs]) from [<c01324dc>] (dev_hard_start_xmit+0x1a8/0x244)
> r7:c12a3800 r6:c1a9aa00 r5:c1a9aa00 r4:c12a3800
> [<c0132334>] (dev_hard_start_xmit+0x0/0x244) from [<c013fcc0>] (__qdisc_run+0xb0/0x198)
Thats a bug in the 3c589_cs driver. Patch attached.
Signed-off-by: Patrick McHardy <kaber@trash.net>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
Changed PATA handler for PATA-ports used by sata_sis.
This patch was originally submitted by Jeff Garzik.
Added PCI-ID 1180 for SiS966 Controller in pata_sis.
The 1180 mode is fully compatible to other SiS PATA-controller.
The PCI-ID 1183 is SATA in PATA-emulation, but not fully compatible
to SiS5513/5518. sata_sis.c is forwarding this ID to pata_sis.
1183 is not working if simply added to pata_sis.
This handling fixes issues with SiS968.
Signed-off-by: Uwe Koziolek <uwe.koziolek@gmx.net>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
Another member of HTS5416* family doing spurious NCQ completion.
Signed-off-by: Tejun Heo <htejun@gmail.com>
Cc: Enrico Sardi <enricoss@tiscali.it>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
The sata_nv driver was missing the change_queue_depth hook in the SCSI host
template which the other NCQ-capable libata drivers had. This made it impossible
to change the queue depth by user request. Add this in.
Signed-off-by: Robert Hancock <hancockr@shaw.ca>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
sata_inic162x can't do LBA48 properly yet and is likely to corrupt
data on drives larger than LBA28 limit. Disable LBA48 devices during
device configuration.
Signed-off-by: Tejun Heo <htejun@gmail.com>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
Dan Williams
Patrick McHardy