Paul Mundt [Fri, 10 Feb 2006 11:14:58 +0000 (13:14 +0200)]
ARM: OMAP: STI STI_DR handling fixup
OMAP1 was using STI_DR instead of STI_RX_DR, which was causing problems
in the RX path. OMAP2 has a consolidated XTI_TRACESELECT, the logic for
trace clearing is the logical inverse of the OMAP1 STI_DR, so fix that
while we're at it.
Signed-off-by: Mikko K. Ylinen <mikko.k.ylinen@nokia.com> Signed-off-by: Paul Mundt <paul.mundt@nokia.com>
Tony Lindgren [Thu, 9 Feb 2006 19:19:23 +0000 (11:19 -0800)]
ARM: OMAP: Adds support to clock framework to detect device id
Clock framework specifies that the selection of clock should be
done based on the device id for similar clocks. This patch adds
support for MMC clocks. Clock device id handling adapted from
mach-s3c2410/clock.c.
Imre Deak [Thu, 9 Feb 2006 16:03:54 +0000 (18:03 +0200)]
ARM: OMAP: uWire clock calculation
In the uWire driver only one of the clock dividers was used to set
the clock to the required frequency. This will add a loop to try all
possible combinations using the other divider as well.
Signed-off-by: Imre Deak <imre.deak@nokia.com> Signed-off-by: Juha Yrjölä <juha.yrjola@nokia.com>
Juha Yrjola [Thu, 9 Feb 2006 10:55:08 +0000 (12:55 +0200)]
ARM: OMAP: Add support for a procfs entry for component versions
Some bootloaders have the ability to send information about the
various component versions (e.g. HW revision, bootloader version)
through the ATAG mechanism. This patch implements a procfs entry
for reading such information.
Signed-off-by: Juha Yrjölä <juha.yrjola@nokia.com>
Juha Yrjola [Thu, 9 Feb 2006 07:57:29 +0000 (09:57 +0200)]
ARM: OMAP: Update OMAP1710 NAND controller driver
- Reserve the DMA channel at init time to reduce xfer overhead
- PSC values need to be increased in some cases where the driving
clock runs at a high frequency
- Enable auto idling
Signed-off-by: Juha Yrjölä <juha.yrjola@nokia.com>
Imre Deak [Thu, 9 Feb 2006 07:22:46 +0000 (09:22 +0200)]
ARM: OMAP: A whopping FB driver update
- Support for the Philips LPH8923 LCD panel
- Support for the Epson HWA742 LCD controller
- Support for frame buffer located in SRAM and/or SDRAM
- Support for boot loader initialized LCD controller / frame buffer
content.
- LCD panels will now register a device in the relevant board-* files
instead of specifying the LCD type as an OMAP_TAG_LCD. The controller
type is still specified in OMAP_TAG_LCD.
- A new ATAG OMAP_TAG_FBMEM is used to describe the frame buffer memory
configuration (SRAM and SDRAM regions)
- Changed the OMAP1 LCD controller driver to export its functions
through the lcd_ctrl object.
- OMAP1 pixel clock divider will now round up in lcdc.c
- Changed the OMAP1 SoSSI driver to export its functions through the
lcd_ctrl_extif object.
- OMAP1 SoSSI clock calculation goes through all possible clock
dividers. Rounding of clock tick values now takes places at each
timing parameter.
- OMAP2 RFBI clock calculation goes through all possible clock
dividers. Rounding of clock tick values now takes places at each
timing parameter.
- OMAP2 pixel clock divider will now round up in dispc.c
Signed-off-by: Imre Deak <imre.deak@nokia.com> Signed-off-by: Juha Yrjölä <juha.yrjola@nokia.com>
Paul Mundt [Wed, 8 Feb 2006 17:21:34 +0000 (19:21 +0200)]
ARM: OMAP: Add a tag for preferring the STI console.
Presently we have OMAP_TAG_SERIAL_CONSOLE that wraps in to
add_preferred_console() for the serial console, this does the same
thing with OMAP_TAG_STI_CONSOLE so it's selectable who gets tty
control.
Paul Mundt [Tue, 7 Feb 2006 23:21:58 +0000 (15:21 -0800)]
[PATCH] ARM: OMAP: STI/XTI support
This implements a simple subsystem for the OMAP serial tracing interface,
as found in omap16xx and omap24xx.
There's a few things implemented in this patch:
- STI console support
- STI netlink support
- STI RX FIFO support
In addition to this, we also provide a general tracing framework that can
be used by both the kernel and userspace (and imask control for allowing
DSP-side STI manipulation).
Since the IRQ is multiplexed, drivers register for the bits they're
interested in (the RX FIFO is an example of this).
The netlink interface exists for streaming data bi-directionally. This is
currently done using NETLINK_USERSOCK, which ends up being somewhat
limiting.
All of these things have been tested on both OMAP1 and OMAP2, and it
takes in to account some of the protocol differences.
Ladislav Michl [Tue, 7 Feb 2006 03:47:38 +0000 (19:47 -0800)]
[PATCH] ARM: OMAP: i2c-omap: Fix support for OMAP15xx
Current implementation of omap_i2c_isr doesn't work on OMAP5910 (Too
much work in one IRQ). Interrupt service routine is broken in these
aspects:
* it tries to ack interrupt by writing to read-only status register.
* it doesn't ackowledge interrupt properly by reading interrupt vector
register.
I'm assuming that driver works correctly on other OMAPs (right? ;-)), so
proposed patch adds interrupt service routine for 15xx cpus and deletes
rev1 stuff from omap_i2c_isr. Tested on OMAP5910 with DS1339 clock on
I2C bus.
Signed-off-by: Ladislav Michl <ladis@linux-mips.org> Signed-off-by: Tony Lindgren <tony@atomide.com>
Ladislav Michl [Tue, 7 Feb 2006 03:45:38 +0000 (19:45 -0800)]
[PATCH] ARM: OMAP: i2c-omap: Fix i2c_xfer for 1 msg
omap_i2c_xfer is supposed to return number of messages successfuly
transfered. Remove bogus condition which causes it to fail when
transfering one message.
Signed-off-by: Ladislav Michl <ladis@linux-mips.org> Signed-off-by: Tony Lindgren <tony@atomide.com>
Russ Anderson [Fri, 3 Feb 2006 20:47:15 +0000 (14:47 -0600)]
[IA64-SGI] Shub2 BTE address fix
After converting the cpu physical address to shub2 physical
addressing, the address was run through TO_PHYS() which
clobbered a high node offset bit causing the BTE to fail
on shub2 nodes with large memory. This fix corrects
that problem.
Signed-off-by: Russ Anderson (rja@sgi.com) Signed-off-by: Tony Luck <tony.luck@intel.com>
Linus Torvalds [Sun, 5 Feb 2006 19:26:38 +0000 (11:26 -0800)]
mm/slab.c (non-NUMA): Fix compile warning and clean up code
The non-NUMA case would do an unmatched "free_alien_cache()" on an alien
pointer that had never been allocated.
It might not matter from a code generation standpoint (since in the
non-NUMA case, the code doesn't actually _do_ anything), but it not only
results in a compiler warning, it's really really ugly too.
Fix the compiler warning by just having a matching dummy allocation.
That also avoids an unnecessary #ifdef in the code.
Robb, Sam [Sun, 5 Feb 2006 07:28:06 +0000 (23:28 -0800)]
[PATCH] kconfig: detect if -lintl is needed when linking conf,mconf
On a system where libintl.h is present, but the NLS functionality is
supplied by a separate library instead of the system C library, an attempt
to "make config" or "make menuconfig" will fail with link errors, ex:
scripts/kconfig/mconf.o:mconf.c:(.text+0xf63): undefined reference to
`_libintl_gettext'
This patch attempts to correct the problem by detecting whether or not NLS
support requires linking with libintl.
Signed-off-by: Samuel J Robb <sam.robb@timesys.com> Cc: Roman Zippel <zippel@linux-m68k.org> Cc: Sam Ravnborg <sam@ravnborg.org> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Chuck Ebbert [Sun, 5 Feb 2006 07:28:03 +0000 (23:28 -0800)]
[PATCH] i386 cpu hotplug: don't access freed memory
i386 CPU init code accesses freed init memory when booting a newly-started
processor after CPU hotplug. The cpu_devs array is searched to find the
vendor and it contains pointers to freed data.
Fix that by:
1. Zeroing entries for freed vendor data after bootup.
2. Changing Transmeta, NSC and UMC to all __init[data].
3. Printing a warning (once only) and setting this_cpu
to a safe default when the vendor is not found.
This does not change behavior for AMD systems. They were broken already
but no error was reported.
Trond Myklebust [Sun, 5 Feb 2006 07:28:01 +0000 (23:28 -0800)]
[PATCH] VFS: Ensure LOOKUP_CONTINUE flag is preserved by link_path_walk()
When walking a path, the LOOKUP_CONTINUE flag is used by some filesystems
(for instance NFS) in order to determine whether or not it is looking up
the last component of the path. It this is the case, it may have to look
at the intent information in order to perform various tasks such as atomic
open.
A problem currently occurs when link_path_walk() hits a symlink. In this
case LOOKUP_CONTINUE may be cleared prematurely when we hit the end of the
path passed by __vfs_follow_link() (i.e. the end of the symlink path)
rather than when we hit the end of the path passed by the user.
The solution is to have link_path_walk() clear LOOKUP_CONTINUE if and only
if that flag was unset when we entered the function.
Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com> Cc: Al Viro <viro@ftp.linux.org.uk> Cc: Christoph Hellwig <hch@lst.de> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
[PATCH] NUMA slab locking fixes: fix cpu down and up locking
This fixes locking and bugs in cpu_down and cpu_up paths of the NUMA slab
allocator. Sonny Rao <sonny@burdell.org> reported problems sometime back on
POWER5 boxes, when the last cpu on the nodes were being offlined. We could
not reproduce the same on x86_64 because the cpumask (node_to_cpumask) was not
being updated on cpu down. Since that issue is now fixed, we can reproduce
Sonny's problems on x86_64 NUMA, and here is the fix.
The problem earlier was on CPU_DOWN, if it was the last cpu on the node to go
down, the array_caches (shared, alien) and the kmem_list3 of the node were
being freed (kfree) with the kmem_list3 lock held. If the l3 or the
array_caches were to come from the same cache being cleared, we hit on
badness.
This patch cleans up the locking in cpu_up and cpu_down path. We cannot
really free l3 on cpu down because, there is no node offlining yet and even
though a cpu is not yet up, node local memory can be allocated for it. So l3s
are usually allocated at keme_cache_create and destroyed at
kmem_cache_destroy. Hence, we don't need cachep->spinlock protection to get
to the cachep->nodelist[nodeid] either.
Patch survived onlining and offlining on a 4 core 2 node Tyan box with a 4
dbench process running all the time.
Signed-off-by: Alok N Kataria <alokk@calsoftinc.com> Signed-off-by: Ravikiran Thirumalai <kiran@scalex86.org> Cc: Christoph Lameter <christoph@lameter.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
[PATCH] NUMA slab locking fixes: irq disabling from cahep->spinlock to l3 lock
Earlier, we had to disable on chip interrupts while taking the
cachep->spinlock because, at cache_grow, on every addition of a slab to a slab
cache, we incremented colour_next which was protected by the cachep->spinlock,
and cache_grow could occur at interrupt context. Since, now we protect the
per-node colour_next with the node's list_lock, we do not need to disable on
chip interrupts while taking the per-cache spinlock, but we just need to
disable interrupts when taking the per-node kmem_list3 list_lock.
Signed-off-by: Alok N Kataria <alokk@calsoftinc.com> Signed-off-by: Ravikiran Thirumalai <kiran@scalex86.org> Signed-off-by: Shai Fultheim <shai@scalex86.org> Cc: Christoph Lameter <christoph@lameter.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
[PATCH] NUMA slab locking fixes: move color_next to l3
colour_next is used as an index to add a colouring offset to a new slab in the
cache (colour_off * colour_next). Now with the NUMA aware slab allocator, it
makes sense to colour slabs added on the same node sequentially with
colour_next.
This patch moves the colouring index "colour_next" per-node by placing it on
kmem_list3 rather than kmem_cache.
This also helps simplify locking for CPU up and down paths.
Signed-off-by: Alok N Kataria <alokk@calsoftinc.com> Signed-off-by: Ravikiran Thirumalai <kiran@scalex86.org> Signed-off-by: Shai Fultheim <shai@scalex86.org> Cc: Christoph Lameter <christoph@lameter.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
[PATCH] hugetlb: add comment explaining reasons for Bus Errors
I just spent some time researching a Bus Error. Turns out that the huge
page fault handler can return VM_FAULT_SIGBUS for various conditions where
no huge page is available.
Add a note explaining the reasoning in the source.
Signed-off-by: Christoph Lameter <clameter@sgi.com> Acked-by: William Lee Irwin III <wli@holomorphy.com> Cc: Hugh Dickins <hugh@veritas.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Andrew Morton [Sun, 5 Feb 2006 07:27:54 +0000 (23:27 -0800)]
[PATCH] jbd: fix transaction batching
Ben points out that:
When writing files out using O_SYNC, jbd's 1 jiffy delay results in a
significant drop in throughput as the disk sits idle. The patch below
results in a 4-5x performance improvement (from 6.5MB/s to ~24-30MB/s on my
IDE test box) when writing out files using O_SYNC.
So optimise the batching code by omitting it entirely if the process which is
doing a sync write is the same as the one which did the most recent sync
write. If that's true, we're unlikely to get any other processes joining the
transaction.
(Has been in -mm for ages - it took me a long time to get on to performance
testing it)
This is the problematic single-process-doing-fsync case. With multiple
fsyncing processes the numbers are AFACIT unaltered by the patch.
Aside: performance testing and instrumentation shows that the transaction
batching almost doesn't help (testing with synctest -n 1 -uf -t 100 -p 10
dir-name on non-writeback-caching IDE). This is because by the time one
process is running a synchronous commit, a bunch of other processes already
have a transaction handle open, so they're all going to batch into the same
transaction anyway.
The batching seems to offer maybe 5-10% speedup with this workload, but I'm
pretty sure it was more important than that when it was first developed 4-odd
years ago...
Cc: "Stephen C. Tweedie" <sct@redhat.com> Cc: Benjamin LaHaise <bcrl@kvack.org> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Dave Jones [Sun, 5 Feb 2006 07:27:49 +0000 (23:27 -0800)]
[PATCH] missing license tag in intermodule
It may suck something awful, but it shouldn't taint the kernel.
Signed-off-by: Dave Jones <davej@redhat.com> Signed-off-by: Adrian Bunk <bunk@stusta.de> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Phillip Susi [Sun, 5 Feb 2006 07:27:48 +0000 (23:27 -0800)]
[PATCH] pktcdvd: Allow larger packets
The pktcdvd driver uses a compile time macro constant to define the maximum
supported packet length. I changed this from 32 sectors to 128 sectors
because that allows over 100 MB of additional usable space on a 700 MB cdrw,
and increases throughput.
Note that you need a modified cdrwtool program that can format a CDRW disc
with larger packets to benefit from this change.
Signed-off-by: Peter Osterlund <petero2@telia.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Peter Osterlund [Sun, 5 Feb 2006 07:27:47 +0000 (23:27 -0800)]
[PATCH] pktcdvd: Don't waste kernel memory
Allocate memory for read-gathering at open time, when it is known just how
much memory is needed. This avoids wasting kernel memory when the real packet
size is smaller than the maximum packet size supported by the driver. This is
always the case when using DVD discs.
Signed-off-by: Peter Osterlund <petero2@telia.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Phillip Susi [Sun, 5 Feb 2006 07:27:44 +0000 (23:27 -0800)]
[PATCH] pktcdvd: Fix overflow for discs with large packets
The pktcdvd driver was using an 8 bit field to store the packet length
obtained from the disc track info. This causes it to overflow packet length
values of 128KB or more. I changed the field to 32 bits to fix this.
The pktcdvd driver defaulted to its maximum allowed packet length when it
detected a 0 in the track info field. I changed this to fail the operation
and refuse to access the media. This seems more sane than attempting to
access it with a value that almost certainly will not work.
Signed-off-by: Peter Osterlund <petero2@telia.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Jens Axboe [Sun, 5 Feb 2006 07:27:38 +0000 (23:27 -0800)]
[PATCH] fix ordering on requeued request drainage
Previously, if a fs request which was being drained failed and got
requeued, blk_do_ordered() didn't allow it to be reissued, which causes
queue stall. This patch makes blk_do_ordered() use the sequence of each
request to determine whether a request can be issued or not. This fixes
the bug and simplifies code.
Eric Dumazet [Sun, 5 Feb 2006 07:27:36 +0000 (23:27 -0800)]
[PATCH] percpu data: only iterate over possible CPUs
percpu_data blindly allocates bootmem memory to store NR_CPUS instances of
cpudata, instead of allocating memory only for possible cpus.
As a preparation for changing that, we need to convert various 0 -> NR_CPUS
loops to use for_each_cpu().
(The above only applies to users of asm-generic/percpu.h. powerpc has gone it
alone and is presently only allocating memory for present CPUs, so it's
currently corrupting memory).
Signed-off-by: Eric Dumazet <dada1@cosmosbay.com> Cc: "David S. Miller" <davem@davemloft.net> Cc: James Bottomley <James.Bottomley@steeleye.com> Acked-by: Ingo Molnar <mingo@elte.hu> Cc: Jens Axboe <axboe@suse.de> Cc: Anton Blanchard <anton@samba.org> Acked-by: William Irwin <wli@holomorphy.com> Cc: Andi Kleen <ak@muc.de> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Quoth Andi Kleen:
"Kiran decided that it makes the problem worse than it was before.
Fixing it fully requires more work which is too much for 2.6.16. So
please revert that commit for now."
Patrick McHardy [Sat, 4 Feb 2006 10:19:46 +0000 (02:19 -0800)]
[NETFILTER]: Fix check whether dst_entry needs to be released after NAT
After DNAT the original dst_entry needs to be released if present
so the packet doesn't skip input routing with its new address. The
current check for DNAT in ip_nat_in is reversed and checks for SNAT.
Signed-off-by: Patrick McHardy <kaber@trash.net> Signed-off-by: David S. Miller <davem@davemloft.net>
Patrick McHardy [Sat, 4 Feb 2006 10:19:09 +0000 (02:19 -0800)]
[NETFILTER]: Prepare {ipt,ip6t}_policy match for x_tables unification
The IPv4 and IPv6 version of the policy match are identical besides address
comparison and the data structure used for userspace communication. Unify
the data structures to break compatiblity now (before it is released), so
we can port it to x_tables in 2.6.17.
Signed-off-by: Patrick McHardy <kaber@trash.net> Signed-off-by: David S. Miller <davem@davemloft.net>
Patrick McHardy [Sat, 4 Feb 2006 10:17:55 +0000 (02:17 -0800)]
[NETFILTER]: Fix ip6t_policy address matching
Fix two bugs in ip6t_policy address matching:
- misorder arguments to ip6_masked_addrcmp, mask must be the second argument
- inversion incorrectly applied to the entire expression instead of just
the address comparison
Signed-off-by: Patrick McHardy <kaber@trash.net> Signed-off-by: David S. Miller <davem@davemloft.net>
Kirill Korotaev [Sat, 4 Feb 2006 10:16:56 +0000 (02:16 -0800)]
[NETFILTER]: Fix possible overflow in netfilters do_replace()
netfilter's do_replace() can overflow on addition within SMP_ALIGN()
and/or on multiplication by NR_CPUS, resulting in a buffer overflow on
the copy_from_user(). In practice, the overflow on addition is
triggerable on all systems, whereas the multiplication one might require
much physical memory to be present due to the check above. Either is
sufficient to overwrite arbitrary amounts of kernel memory.
I really hate adding the same check to all 4 versions of do_replace(),
but the code is duplicate...
Found by Solar Designer during security audit of OpenVZ.org
Signed-Off-By: Kirill Korotaev <dev@openvz.org> Signed-Off-By: Solar Designer <solar@openwall.com> Signed-off-by: Patrck McHardy <kaber@trash.net> Signed-off-by: David S. Miller <davem@davemloft.net>
Samir Bellabes [Sat, 4 Feb 2006 10:16:06 +0000 (02:16 -0800)]
[NETFILTER]: nf_conntrack: fix incorrect memset() size in FTP helper
This memset() is executing with a bad size. According to Yasuyuki Kozakai,
this memset() can be deleted, as 'ftp' is declared in global area.
Signed-off-by: Samir Bellabes <sbellabes@mandriva.com> Signed-off-by: Yasuyuki Kozakai <yasuyuki.kozakai@toshiba.co.jp> Signed-off-by: Patrick McHardy <kaber@trash.net> Signed-off-by: David S. Miller <davem@davemloft.net>
[NETFILTER]: iptables: fix typos in ipt_connbytes.h
Fix some typos that make iptables userspace compilation fail.
Signed-off-by: Yasuyuki Kozakai <yasuyuki.kozakai@toshiba.co.jp> Signed-off-by: Patrick McHardy <kaber@trash.net> Signed-off-by: David S. Miller <davem@davemloft.net>
[NETFILTER]: ULOG/nfnetlink_log: Use better default value for 'nlbufsiz'
Performance tests showed that ULOG may fail on heavy loaded systems
because of failed order-N allocations (N >= 1).
The default value of 4096 is not optimal in the sense that it actually
allocates _two_ contigous physical pages. Reasoning: ULOG uses
alloc_skb(), which adds another ~300 bytes for skb_shared_info.
This patch sets the default value to NLMSG_GOODSIZE and adds some
documentation at the top.
Signed-off-by: Holger Eitzenberger <heitzenberger@astaro.com> Signed-off-by: Patrick McHardy <kaber@trash.net> Signed-off-by: David S. Miller <davem@davemloft.net>
[NETFILTER]: nf_conntrack: check address family when finding protocol module
__nf_conntrack_{l3}proto_find() doesn't check the passed protocol family,
then it's possible to touch out of the array which has only AF_MAX items.
Spotted by Pablo Neira Ayuso.
Signed-off-by: Yasuyuki Kozakai <yasuyuki.kozakai@toshiba.co.jp> Signed-off-by: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org> Signed-off-by: Patrick McHardy <kaber@trash.net> Signed-off-by: David S. Miller <davem@davemloft.net>
[NETFILTER]: ctnetlink: add MODULE_ALIAS for expectation subsystem
Add load-on-demand support for expectation request. eg. conntrack -L expect
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org> Signed-off-by: Patrick McHardy <kaber@trash.net> Signed-off-by: David S. Miller <davem@davemloft.net>
Marcus Sundberg [Sat, 4 Feb 2006 10:11:09 +0000 (02:11 -0800)]
[NETFILTER]: ctnetlink: Fix subsystem used for expectation events
The ctnetlink expectation events should use the NFNL_SUBSYS_CTNETLINK_EXP
subsystem, not NFNL_SUBSYS_CTNETLINK.
Signed-off-by: Marcus Sundberg <marcus@ingate.com> Signed-off-by: Patrick McHardy <kaber@trash.net> Signed-off-by: David S. Miller <davem@davemloft.net>
Herbert Xu [Sat, 4 Feb 2006 10:09:34 +0000 (02:09 -0800)]
[ICMP]: Fix extra dst release when ip_options_echo fails
When two ip_route_output_key lookups in icmp_send were combined I
forgot to change the error path for ip_options_echo to not drop the
dst reference since it now sits before the dst lookup. To fix it we
simply jump past the ip_rt_put call.
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: David S. Miller <davem@davemloft.net>
Jon Mason [Fri, 3 Feb 2006 20:51:59 +0000 (21:51 +0100)]
[PATCH] x86_64: IOMMU printk cleanup
This patch contains a printk reorder to remove the current problem of
displaying "PCI-DMA: Disabling IOMMU." and then "PCI-DMA: using GART
IOMMU" 20 lines later in dmesg.
It also constains a printk reorder in swiotlb to state swiotlb
enablement prior to describing the location of the bounce buffers, and a
printk reorder to state gart enablement prior to describing the
aperature.
Also constains a whitespace cleanup in arch/x86_64/kernel/setup.c
Tested (along with patch 2/2) on dual opteron with gart enabled,
iommu=soft, and iommu=off.
Andi Kleen [Fri, 3 Feb 2006 20:51:56 +0000 (21:51 +0100)]
[PATCH] x86_64: Let impossible CPUs point to reference per cpu data
Hack for 2.6.16. In 2.6.17 all code that uses NR_CPUs should
be audited and changed to only touch possible CPUs.
Don't mark the reference per cpu data init data (so it stays
around after boot) and point all impossible CPUs to it. This way
they reference some valid - although shared memory. Usually
this is only initialization like INIT_LIST_HEADs and there
won't be races because these CPUs never run. Still somewhat hackish.
Ashok Raj [Fri, 3 Feb 2006 20:51:50 +0000 (21:51 +0100)]
[PATCH] x86_64: Dont record local apic ids when they are disabled in MADT
Some broken BIOS's had processors disabled, but
same apic id as a valid processor. This causes
acpi_processor_start() to think this disabled
cpu is ok, and croak. So we dont record bad
apicid's anymore.
projects / linux-2.6-omap-h63xx.git / log