| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
- changes to ach/arch/boot/Makefile to make it easier to add new
compression types
- new piggy.lzo.S necessary for lzo compression
- changes in arch/arm/boot/compressed/misc.c to allow the use of lzo or
gzip, depending on the config
- Kconfig support
Signed-off-by: Albin Tonnerre <[email protected]>
Tested-by: Wu Zhangjin <[email protected]>
Acked-by: "H. Peter Anvin" <[email protected]>
Cc: Ingo Molnar <[email protected]>
Cc: Thomas Gleixner <[email protected]>
Tested-by: Russell King <[email protected]>
Acked-by: Russell King <[email protected]>
Cc: Ralf Baechle <[email protected]>
Cc: Martin Michlmayr <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
|
|
This patch series adds generic support for creating and extracting
LZO-compressed kernel images, as well as support for using such images on
the x86 and ARM architectures, and support for creating and using
LZO-compressed initrd and initramfs images.
Russell King said:
: Testing on a Cortex A9 model:
: - lzo decompressor is 65% of the time gzip takes to decompress a kernel
: - lzo kernel is 9% larger than a gzip kernel
:
: which I'm happy to say confirms your figures when comparing the two.
:
: However, when comparing your new gzip code to the old gzip code:
: - new is 99% of the size of the old code
: - new takes 42% of the time to decompress than the old code
:
: What this means is that for a proper comparison, the results get even better:
: - lzo is 7.5% larger than the old gzip'd kernel image
: - lzo takes 28% of the time that the old gzip code took
:
: So the expense seems definitely worth the effort. The only reason I
: can think of ever using gzip would be if you needed the additional
: compression (eg, because you have limited flash to store the image.)
:
: I would argue that the default for ARM should therefore be LZO.
This patch:
The lzo compressor is worse than gzip at compression, but faster at
extraction. Here are some figures for an ARM board I'm working on:
Uncompressed size: 3.24Mo
gzip 1.61Mo 0.72s
lzo 1.75Mo 0.48s
So for a compression ratio that is still relatively close to gzip, it's
much faster to extract, at least in that case.
This part contains:
- Makefile routine to support lzo compression
- Fixes to the existing lzo compressor so that it can be used in
compressed kernels
- wrapper around the existing lzo1x_decompress, as it only extracts one
block at a time, while we need to extract a whole file here
- config dialog for kernel compression
[[email protected]: coding-style fixes]
[[email protected]: cleanup]
Signed-off-by: Albin Tonnerre <[email protected]>
Tested-by: Wu Zhangjin <[email protected]>
Acked-by: "H. Peter Anvin" <[email protected]>
Cc: Ingo Molnar <[email protected]>
Cc: Thomas Gleixner <[email protected]>
Tested-by: Russell King <[email protected]>
Acked-by: Russell King <[email protected]>
Cc: Ralf Baechle <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
|
|
JFFS2 uses lesser compression ratio and inflate always ends up in "copy
direct from output" case.
This patch tries to optimize the direct copy procedure. Uses
get_unaligned() but only in one place.
The copy loop just above this one can also use this optimization, but I
havn't done so as I have not tested if it is a win there too.
On my MPC8321 this is about 17% faster on my JFFS2 root FS than the
original.
[[email protected]: coding-style fixes]
Signed-off-by: Joakim Tjernlund <[email protected]>
Cc: Roel Kluin <[email protected]>
Cc: Richard Purdie <[email protected]>
Cc: David Woodhouse <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
|
|
__pcpu_ptr_to_addr() can be overridden by the architecture and might not
behave well if passed a NULL pointer. So avoid calling it until we have
verified that its arg is not NULL.
Cc: Rusty Russell <[email protected]>
Cc: Kamalesh Babulal <[email protected]>
Acked-by: Tejun Heo <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
|
|
Fix resource (write-pipe file) leak in call_usermodehelper_pipe().
When call_usermodehelper_exec() fails, write-pipe file is opened and
call_usermodehelper_pipe() just returns an error. Since it is hard for
caller to determine whether the error occured when opening the pipe or
executing the helper, the caller cannot close the pipe by themselves.
I've found this resoruce leak when testing coredump. You can check how
the resource leaks as below;
$ echo "|nocommand" > /proc/sys/kernel/core_pattern
$ ulimit -c unlimited
$ while [ 1 ]; do ./segv; done &> /dev/null &
$ cat /proc/meminfo (<- repeat it)
where segv.c is;
//-----
int main () {
char *p = 0;
*p = 1;
}
//-----
This patch closes write-pipe file if call_usermodehelper_exec() failed.
Signed-off-by: Masami Hiramatsu <[email protected]>
Cc: Rusty Russell <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
|
|
DMA_FROM_DEVICE and
There is no need to perform full BIDIR sync (copying the buffers in case
of swiotlb and similar schemes) if we know that the owner (CPU or device)
hasn't altered the data.
Addresses the false-positive reported at
http://bugzilla.kernel.org/show_bug.cgi?id=14169
Signed-off-by: Krzysztof Halasa <[email protected]>
Cc: David Miller <[email protected]>
Cc: Joerg Roedel <[email protected]>
Cc: <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
|
|
It turns out that even zero-sized struct members (int foo[0];) will affect
the struct layout, causing us in particular to lose 4 bytes in struct
sock.
This patch fixes the regression in CONFIG_KMEMCHECK=n case.
Reported-by: Eric Dumazet <[email protected]>
Signed-off-by: Vegard Nossum <[email protected]>
Acked-by: Pekka Enberg <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
|
|
Add many ioctl definitions to ioctl-number.txt.
Fix some whitespace/formatting.
Correct some filenames/paths.
Signed-off-by: Randy Dunlap <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
|
|
Makes it consistent with the extern declaration, used when CONFIG_HIGHMEM
is set Removes redundant casts in printout messages
Signed-off-by: Andreas Fenkart <[email protected]>
Acked-by: Russell King <[email protected]>
Cc: Ralf Baechle <[email protected]>
Cc: David Howells <[email protected]>
Cc: Ingo Molnar <[email protected]>
Cc: Thomas Gleixner <[email protected]>
Cc: "H. Peter Anvin" <[email protected]>
Cc: Chen Liqin <[email protected]>
Cc: Lennox Wu <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
|
|
The console hangs during bootup when disable_irq is called from the
transmit interrupt handler (it will wait forever for it's "own"
interrupt in synchronize_irq). Fix by using disable_irq_nosync()
instead.
Signed-off-by: Simon Kagstrom <[email protected]>
Signed-off-by: Russell King <[email protected]>
|
|
Extend the patch from Philby John to the other "RealView" boards.
Rename the constants and offsets to reflect their actual functions.
Cc: Philby John <[email protected]>
Signed-off-by: Colin Tuckley <[email protected]>
Acked-by: Catalin Marinas <[email protected]>
Signed-off-by: Russell King <[email protected]>
|
|
Loops checking for certain condition were rather inconsistent.
Signed-off-by: Tomi Valkeinen <[email protected]>
Reported-by: Juha Leppanen <[email protected]>
|
|
Fixes bug causing VRFB memory area to be released twice.
Signed-off-by: Tomi Valkeinen <[email protected]>
Reported-by: Eino-Ville Talvala <[email protected]>
|
|
Trivial patch which adds the __init/__exit macros to the module_init/
module_exit functions of
drivers/video/omap/lcd_htcherald.c
Please have a look at the small patch and either pull it through
your tree, or please ack' it so Jiri can pull it through the trivial
tree.
Patch against linux-next-tree, 22. Dez 08:38:18 CET 2009
but also present in linus tree.
Signed-off-by: Peter Huewe <[email protected]>
Acked-by: Tony Lindgren <[email protected]>
|
|
Signed-off-by: Vaibhav Hiremath <[email protected]>
Acked-by: Tomi Valkeinen <[email protected]>
|
|
There isn't really any reason to divide those.
Signed-off-by: Tomi Valkeinen <[email protected]>
|
|
Commit fd8fbfc1 modified the way we find amount of reserved space
belonging to an inode. The amount of reserved space is checked
from dquot_transfer and thus inode_reserved_space gets called
even for filesystems that don't provide get_reserved_space callback
which results in a BUG.
Fix the problem by checking get_reserved_space callback and return 0 if
the filesystem does not provide it.
CC: Dmitry Monakhov <[email protected]>
Signed-off-by: Jan Kara <[email protected]>
|
|
Signed-off-by: Tomi Valkeinen <[email protected]>
Acked-by: Imre Deak <[email protected]>
|
|
This should fix:
WARNING: at drivers/base/core.c:131 device_release+0x68/0x7c()
Device 'omapdss' does not have a release() function, it is broken and
must be fixed.
Signed-off-by: Tomi Valkeinen <[email protected]>
|
|
omapfb platform device was still used to get clocks inside rfbi.c
Signed-off-by: Tomi Valkeinen <[email protected]>
Tested-by: Sergey Lapin <[email protected]>
|
|
Signed-off-by: Tomi Valkeinen <[email protected]>
|
|
Using ~0ULL was cauing sign issues in filemap_fdatawrite_range, so
use MAX_LFS_FILESIZE instead.
Signed-off-by: Steven Whitehouse <[email protected]>
|
|
Bail out if we don't find an enclosing IOC. Previously, if we didn't
find one, we tried to set things up using garbage for the SBA/IOC register
address, which causes a crash.
This crash only happens if firmware supplies a defective ACPI namespace, so
it doesn't fix any problems in the field.
Signed-off-by: Bjorn Helgaas <[email protected]>
Signed-off-by: Dave Airlie <[email protected]>
|
|
Commit 15b8dd53f5ffa changed the string in info->hardware_id from a static
array to a pointer and added a length field. But instead of changing
"sizeof(array)" to "length", we changed it to "sizeof(length)" (== 4),
which corrupts the string we're trying to null-terminate.
We no longer even need to null-terminate the string, but we *do* need to
check whether we found a HID. If there's no HID, we used to have an empty
array, but now we have a null pointer.
The combination of these defects causes this oops:
Unable to handle kernel NULL pointer dereference (address 0000000000000003)
modprobe[895]: Oops 8804682956800 [1]
ip is at zx1_gart_probe+0xd0/0xcc0 [hp_agp]
http://marc.info/?l=linux-ia64&m=126264484923647&w=2
Signed-off-by: Bjorn Helgaas <[email protected]>
Reported-by: Émeric Maschino <[email protected]>
Signed-off-by: Dave Airlie <[email protected]>
|
|
While investigating a kmemleak detected leak, I encountered the
agp_add_bridge function. It appears to be responsible for freeing
the agp_bridge_data in the case of a failure, but it is only doing
so for some errors.
Fix it to always free the bridge data if a failure condition is
encountered.
Signed-off-by: Kevin Winchester <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Dave Airlie <[email protected]>
|
|
* 'for-airlied' of /ssd/git/drm-nouveau-next: (28 commits)
drm/nv04: Fix set_operation software method.
drm/nouveau: initialise DMA tracking parameters earlier
drm/nouveau: use dma.max rather than pushbuf size for checking GET validity
drm/nv04: differentiate between nv04/nv05
drm/nouveau: Fix null deref in nouveau_fence_emit due to deleted fence
drm/nv50: prevent a possible ctxprog hang
drm/nouveau: have ttm's fault handler called directly
drm/nv50: restore correct cache1 get/put address on fifoctx load
drm/nouveau: create function for "dealing" with gpu lockup
drm/nouveau: remove unused nouveau_channel_idle() function
drm/nouveau: fix handling of fbcon colours in 8bpp
drm/nv04: Context switching fixes.
drm/nouveau: Use the software object for fencing.
drm/nouveau: Allocate a per-channel instance of NV_SW.
drm/nv50: make the blocksize depend on vram size
drm/nouveau: better alignment of bo sizes and use roundup instead of ALIGN
drm/nouveau: Don't skip card take down on nv0x.
drm/nouveau: Implement nv42-nv43 TV load detection.
drm/nouveau: Clean up the nv17-nv4x load detection code a bit.
drm/nv50: fix fillrect color
...
|
|
* korg/drm-radeon-next:
drm/radeon/kms: add additional safe regs for r4xx/rs6xx and r5xx
drm/radeon/kms: Don't try to enable IRQ if we have no handler installed
drm: Avoid calling vblank function is vblank wasn't initialized
drm/radeon: mkregtable.c: close a file before exit
drm/radeon/kms: Make sure we release AGP device if we acquired it
drm/radeon/kms: Schedule host path read cache flush through the ring V2
drm/radeon/kms: Workaround RV410/R420 CP errata (V3)
drm/radeon/kms: detect sideport memory on IGP chips
drm/radeon: fix a couple of array index errors
drm/radeon/kms: add support for eDP (embedded DisplayPort)
drm: Add eDP connector type
drm/radeon/kms: pull in the latest upstream ObjectID.h changes
drm/radeon/kms: whitespace changes to ObjectID.h
drm/radeon/kms: fix typo in atom connector type handling
|
|
Signed-off-by: Ben Skeggs <[email protected]>
|
|
Signed-off-by: Ben Skeggs <[email protected]>
|
|
Some upcoming G80 DMA changes will depend on this, but it's split out for
bisectibility just in case it causes some unexpected issues.
Signed-off-by: Ben Skeggs <[email protected]>
|
|
Signed-off-by: Ben Skeggs <[email protected]>
|
|
Currently Nouveau will unvalidate all buffers if it is forced to wait on
one, and then start revalidating from the beginning. While doing so, it
destroys the operation fence, causing nouveau_fence_emit to crash.
This patch fixes this bug by taking the fence object out of validate_op
and creating it just before emit. The fence pointer is initialized to 0
and unref'ed unconditionally.
In addition to fixing the bug, this prevents its reintroduction and
simplifies the code.
Signed-off-by: Luca Barbieri <[email protected]>
Signed-off-by: Ben Skeggs <[email protected]>
|
|
The below is mainly an educated guess at what's going on, docs would
sure be handy... NVIDIA? :P
It appears it's possible for a ctxprog to run even while a GPU exception
is pending. The GF8 and up ctxprogs appear to have a small snippet of
code which detects this, and stalls the ctxprog until it's been handled,
which essentially looks like:
if (r2 & 0x00008000) {
r0 |= 0x80000000;
while (r0 & 0x80000000) {}
}
I don't know of any way that flag would get cleared unless the driver
intervenes (and indeed, in the cases I've seen the hang, nothing steps
in to automagically clear it for us). This patch causes the driver to
clear the flag during the PGRAPH IRQ handler.
Signed-off-by: Ben Skeggs <[email protected]>
|
|
There's no good reason for us to have our own anymore, this is left over
from an early port to these TTM interfaces.
Signed-off-by: Ben Skeggs <[email protected]>
|
|
Signed-off-by: Ben Skeggs <[email protected]>
|
|
It's mostly a cleanup, but in nv50_fbcon_accel_init gpu lockup
message was printed, but HWACCEL_DISBALED flag was not set.
Signed-off-by: Marcin Slusarz <[email protected]>
Signed-off-by: Ben Skeggs <[email protected]>
|
|
Signed-off-by: Ben Skeggs <[email protected]>
|
|
Depending on the visual, the colours handed to us in fillrect() can either be
an actual colour, or an index into the pseudo-palette.
Signed-off-by: Ben Skeggs <[email protected]>
|
|
Signed-off-by: Francisco Jerez <[email protected]>
|
|
This should avoid a race condition on nv0x, if we're doing it with
actual PGRAPH objects and a there's a fence within the FIFO DMA fetch
area when a context switch kicks in.
In that case we get an ILLEGAL_MTHD interrupt as expected, but the
values in PGRAPH_TRAPPED_ADDR aren't calculated correctly and they're
almost useless (e.g. you can see ILLEGAL_MTHDs for the now inactive
channel, with a wrong offset/data pair).
Signed-off-by: Francisco Jerez <[email protected]>
|
|
It will be useful for various synchronization purposes, mostly stolen
from "[PATCH] drm/nv50: synchronize user channel after buffer object
move on kernel channel" by Maarten Maathuis.
Signed-off-by: Francisco Jerez <[email protected]>
|
|
- This should be better than what we have now.
- I'm less sure about the non power of two path.
Signed-off-by: Maarten Maathuis <[email protected]>
|
|
- Aligning to block size should ensure that the extra size is enough.
- Using roundup, because not all sizes are powers of two.
Signed-off-by: Maarten Maathuis <[email protected]>
|
|
Signed-off-by: Francisco Jerez <[email protected]>
|
|
Signed-off-by: Francisco Jerez <[email protected]>
|
|
Signed-off-by: Francisco Jerez <[email protected]>
|
|
struct fb_fillrect->color is not a color, but index into pseudo_palette
array
Signed-off-by: Marcin Slusarz <[email protected]>
Signed-off-by: Ben Skeggs <[email protected]>
|
|
Should fix dim panel issues reported on Dell M6400/M6500.
Signed-off-by: Ben Skeggs <[email protected]>
|
|
Signed-off-by: Francisco Jerez <[email protected]>
|
|
Signed-off-by: Francisco Jerez <[email protected]>
|