- 13 Sep, 2006 1 commit
-
-
Michael Ellerman authored
As part of the new irq code pseries_kexec_cpu_down() was split into a xics and mpic version. The vpa unregister logic is now only done in the xics routine, and although that's ok in practice (we don't have SPLPAR machines with mpic), I'd rather have the two concepts stay separate. So move the vpa unregister into pseries_kexec_cpu_down(), which gets called by both the xics and mpic routines. This also gives us an obvious place to put any new kexec-down logic needed in future. Signed-off-by: Michael Ellerman <michael@ellerman.id.au> Signed-off-by: Paul Mackerras <paulus@samba.org>
-
- 31 Aug, 2006 6 commits
-
-
Paul Mackerras authored
-
git://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpcLinus Torvalds authored
* 'merge' of git://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc: [POWERPC] Fix return value from memcpy [POWERPC] iseries: Define insw et al. so libata/ide will compile [POWERPC] Fix irq enable/disable in smp_generic_take_timebase [POWERPC] Fix problem with time not advancing on 32-bit platforms [POWERPC] Restore copyright notice in arch/powerpc/kernel/fpu.S [POWERPC] Fix up ibm_architecture_vec definition [POWERPC] Make OF irq map code detect more error cases [POWERPC] Support for "weird" MPICs and fixup mpc7448_hpc2 [POWERPC] Fix MPIC sense codes in documentation [POWERPC] Fix performance regression in IRQ radix tree locking [POWERPC] Add mpc7448hpc2 device tree source file [POWERPC] Add MPC8349E MDS device tree source file to arch/powerpc/boot/dts [POWERPC] modify mpc83xx platforms to use new IRQ layer [POWERPC] Adapt ipic driver to new host_ops interface, add set_irq_type to set IRQ sense [POWERPC] back up old school ipic.[hc] to arch/ppc [POWERPC] Use mpc8641hpcn PIC base address from dev tree. [POWERPC] Allow MPC8641 HPCN to build with CONFIG_PCI disabled too. [POWERPC] Fix powerpc 44x_mmu build [POWERPC] Remove flush_dcache_all export
-
Paul Mackerras authored
This fixes a hang on ppc32. The problem was that I was comparing a 32-bit quantity with a 64-bit quantity, and consequently time wasn't advancing. This makes us use a 64-bit quantity on all platforms, which ends up simplifying the code since we can now get rid of the tb_last_stamp variable (which actually fixes another bug that Ben H and I noticed while going carefully through the code). This works fine on my G4 tibook. Let me know how it goes on your machines. Acked-by: Olaf Hering <olaf@aepfle.de> Acked-by: Mikael Pettersson <mikpe@it.uu.se> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
-
Benjamin Herrenschmidt authored
The backlight changes that went in had a bug where they could cause the kernel to access an unitialized pointer when blanking if there is no backlight control on a machine. The bug affects atyfb, aty128fb, nvidiafb and rivafb. radeonfb seems to be ok. This fixes it. Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
-
Paul Mackerras authored
As pointed out by Herbert Xu <herbert@gondor.apana.org.au>, our memcpy implementation didn't return the destination pointer as its return value, and there is code in the kernel that expects that. This fixes it. Signed-off-by: Paul Mackerras <paulus@samba.org>
-
git://git.kernel.org/pub/scm/linux/kernel/git/aegl/linux-2.6Linus Torvalds authored
* 'release' of git://git.kernel.org/pub/scm/linux/kernel/git/aegl/linux-2.6: [IA64] Increase default nodes shift to 10, nr_cpus to 1024 [IA64] remove redundant local_irq_save() calls from sn_sal.h [IA64] panic if topology_init kzalloc fails [IA64-SGI] Silent data corruption caused by XPC V2.
-
- 30 Aug, 2006 33 commits
-
-
Roland Scheidegger authored
The radeon requires a VAP state flush when enabling/disabling vertex programs on the r200 cards. Signed-off-by: Dave Airlie <airlied@linux.ie> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
-
Alan Cox authored
The following change from -mm is important to 2.6.18 (actually to 2.6.17 but its too late for that). This was contributed over three months ago by VIA to Bartlomiej and nothing happened. As a result the new chipset is now out and Linux won't run on it. By the time 2.6.18 is finalised this will be the defacto standard VIA chipset so support would be a good plan. Tested in -mm for a while, its essentially a PCI ident update but for the bridge chip because VIA do things in weird ways. Signed-off-by: Linus Torvalds <torvalds@osdl.org>
-
Suleiman Souhlal authored
It's possible to get an invalid page fault in kernel mode when we try to write out segments from vsyscall32 when dumping core for a 32bit process if the vsyscall32 DSO is not mapped in its address space (which can happen if, for example, ulimit -v 100 is run). Signed-off-by: Suleiman Souhlal <suleiman@google.com> Signed-off-by: Andi Kleen <ak@suse.de> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
-
Keith Owens authored
The values in init_tss.ist[] can change when an IST event occurs. Save the original IST values for checking stack addresses when debugging or doing stack traces. Signed-off-by: Keith Owens <kaos@ocs.com.au> Signed-off-by: Andi Kleen <ak@suse.de> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
-
Andi Kleen authored
After all their only point is having them in user space. Signed-off-by: Andi Kleen <ak@suse.de> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
-
Andi Kleen authored
There was a bogus hunk from the genirq merge that essentially broke stack switching for hard interrupts. Remove it since it isn't needed. Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Ingo Molnar <mingo@elte.hu> Signed-off-by: Andi Kleen <ak@suse.de> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
-
Andi Kleen authored
After all their only point is having them in user space. On x86-64 they don't even work in kernel space. Signed-off-by: Andi Kleen <ak@suse.de> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
-
Andi Kleen authored
As a replacement for the earlier removal of the e820 MCFG check we blacklist the Intel SDV with the original BIOS bug that motivated that check. On those machines don't use MMCONFIG. This also adds a new pci=mmconf parameter to override the blacklist. Cc: Greg KH <gregkh@suse.de> Cc: Arjan van de Ven <arjan@infradead.org> Signed-off-by: Andi Kleen <ak@suse.de> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
-
Andi Kleen authored
The .fill causes miscompilations with some binutils version. Instead just patch the lock prefix in the lock constructs. That is the majority of the cost and should be good enough. Cc: Gerd Hoffmann <kraxel@suse.de> Signed-off-by: Andi Kleen <ak@suse.de> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
-
Andi Kleen authored
The .fill causes miscompilations with some binutils version. Instead just patch the lock prefix in the lock constructs. That is the majority of the cost and should be good enough. Signed-off-by: Andi Kleen <ak@suse.de> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
-
Andi Kleen authored
Noticed by Jan Beulich. When the kernel was moved from 1MB to 2MB in 2.6.17 the kernel reservation code wasn't adjusted and it still reserved starting with 1MB. This means 1MB always were lost. This patch fixes this by reserving only starting with _text. Signed-off-by: Andi Kleen <ak@suse.de> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
-
Jan Beulich authored
The unwinder fallback logic still had potential for falling through to the legacy stack trace code without printing an indication (at once serving as a separator) of this. Further, the stack pointer retrieval for the fallback should be as restrictive as possible (in order to avoid having the legacy stack tracer try to access invalid memory). The patch tightens that, but this could certainly be further improved. Also making the call_trace command line option now conditional upon CONFIG_STACK_UNWIND (as it's meaningless otherwise). Signed-off-by: Jan Beulich <jbeulich@novell.com> Signed-off-by: Andi Kleen <ak@suse.de> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
-
Jan Beulich authored
By hard-coding the cpuid keys for alternative_smp() rather than using the symbolic constant it turned out that incorrect values were used on both i386 (0x68 instead of 0x69) and x86-64 (0x66 instead of 0x68). Signed-off-by: Jan Beulich <jbeulich@novell.com> Signed-off-by: Andi Kleen <ak@suse.de> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
-
Andi Kleen authored
One open question: Should this added push perhaps be made conditional upon CONFIG_STACK_UNWIND or CONFIG_UNWIND_INFO? [AK: not needed, these are all very slow paths] Signed-off-by: Jan Beulich <jbeulich@novell.com> Signed-off-by: Andi Kleen <ak@suse.de> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
-
Andi Kleen authored
One open question: Should these added pushes perhaps be made conditional upon CONFIG_STACK_UNWIND or CONFIG_UNWIND_INFO? [AK: Not needed -- these are all very slow paths] Signed-off-by: Jan Beulich <jbeulich@novell.com> Signed-off-by: Andi Kleen <ak@suse.de> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
-
Andi Kleen authored
The check for the MCFG table being reserved in the e820 map was originally added to detect a broken BIOS in a preproduction Intel SDV. However it also breaks the Apple x86 Macs, which can't supply this properly, but need a working MCFG. With this patch they wouldn't use the MCFG and not work. After some discussion I think it's best to remove the heuristic again. It also failed on some other boxes (although it didn't cause much problems there because old style port access for PCI config space still works as fallback), but the preproduction SDVs can just use pci=nommcfg. Supporting production machines properly is more important. Edgar Hucek did all the debugging work. Cc: Arjan van de Ven <arjan@infradead.org> Cc: Edgar Hucek <hostmaster@ed-soft.at> Signed-off-by: Andi Kleen <ak@suse.de> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
-
Andi Kleen authored
Signed-off-by: Andi Kleen <ak@suse.de> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
-
Linus Torvalds authored
* master.kernel.org:/pub/scm/linux/kernel/git/davem/sparc-2.6: [SUNLANCE]: Fix probing problem. [SPARC64]: Fix X server hangs due to large pages.
-
Linus Torvalds authored
* master.kernel.org:/pub/scm/linux/kernel/git/davem/net-2.6: [STRIP]: Fix neighbour table refcount leak. [IPV6]: ipv6_add_addr should install dstentry earlier [NETLINK]: Call panic if nl_table allocation fails [TCP]: Two RFC3465 Appropriate Byte Count fixes. [IPV6]: SNMPv2 "ipv6IfStatsInAddrErrors" counter error [E100]: Add module option to ignore bad EEPROM checksums. [SCTP]: Fix sctp_primitive_ABORT() call in sctp_close().
-
Stephen Rothwell authored
These are build fixes that enable (for example) libata and the ide code to actually build on iSeries. The associated hardware will never be supported on legacy iSeries, so the code paths don't actually need to work, but it is useful (especially for a combined kernel) if the code can build. Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by: Paul Mackerras <paulus@samba.org>
-
Paul Mackerras authored
Eran Ben-Avi <eranpublic@yahoo.com> pointed out that the arch/ppc version of smp_generic_take_timebase disables interrupts on entry but exits without restoring them. However, both it and the arch/powerpc version have another problem, which is that they use local_irq_disable/enable rather than local_irq_save/restore, and they are called with interrupts disabled. This fixes both problems; it changes a return to a break in the arch/ppc version, and changes both versions to use local_irq_save/restore. Signed-off-by: Paul Mackerras <paulus@samba.org>
-
Paul Mackerras authored
This fixes a problem introduced in 5db9fa95. The last_jiffy per-cpu variable is only 32 bits on 32-bit machines, but it was being compared with a 64-bit quantity (tb_next_jiffy), which resulted in time not advancing. This fixes it by changing last_jiffy to be 64 bits on all platforms. With this, we no longer need tb_last_stamp as a 32-bit version of tb_last_jiffy, so this gets rid of tb_last_stamp and we just use tb_last_jiffy instead. This also fixes a bug when the boot cpu is not online, because using tb_last_stamp could have caused the wrong timebase origin value to be used when calculating the time of day. Signed-off-by: Paul Mackerras <paulus@samba.org>
-
Paul Mackerras authored
This code got moved from head.S but the copyright notice on head.S didn't get transferred with it. Noticed by Cort Dougan <cort@fsmlabs.com>. Signed-off-by: Paul Mackerras <paulus@samba.org>
-
Will Schmidt authored
This problem was noticed by one of the Phyp firmware folks. Our ibm,client-architecture-support call was failing. This corrects the vector length parameters being passed in. Signed-off-by: Will Schmidt <will_schmidt@vnet.ibm.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
-
Benjamin Herrenschmidt authored
Device-tree bugs on js20 with some versions of SLOF were causing the interrupt for IDE to not be parsed correctly and fail to boot. This patch adds a bit more sanity checking to the parser to detect some of those errors and fail instead of returning bogus information. The powerpc PCI code can then trigger a fallback that works on those machines. Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Paul Mackerras <paulus@samba.org>
-
Zang Roy-r61911 authored
This adds a new hardware information table for mpic. This enables the mpic code to deal with mpic controllers with different register layouts and hardware behaviours. This introduces CONFIG_MPIC_WEIRD. For boards with non standard mpic controllers, select CONFIG_MPIC_WEIRD and add its hardware information in the mpic_infos[] array. TSI108/109 PIC takes the first index of weird hardware information table. :) The table can be extended. The Tsi108/109 PIC looks like standard OpenPIC but, in fact, is different in register mapping and behavior. The patch does not affect the behavior of standard mpic. If CONFIG_MPIC_WEIRD is not defined, the code is essentially identical to the current code. [benh@kernel.crashing.org: This patch is a slightly cleaned up version of Zang Roy's support for the TSI108 MPIC variant. It also fixes up MPC7448_hpc2 to use the new version of the type macros and changes the way MPIC is selected in Kconfig to better match what is done for other system devices. ] Signed-off-by: Roy Zang <tie-fei.zang@freescale.com> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Paul Mackerras <paulus@samba.org>
-
Krzysztof Helt authored
The current probe table causes ledma and lebuffer "le" devices to get probed twice which is not what we want. Match just "le" and look directly at the parent to get the correct top-level node information. Signed-off-by: Krzysztof Helt <krzysztof.h1@wp.pl> Signed-off-by: David S. Miller <davem@davemloft.net>
-
David S. Miller authored
This problem was introduced by changeset 14778d90 Unlike the hugetlb code paths, the normal fault code is not setup to propagate PTE changes for large page sizes correctly like the ones we make for I/O mappings in io_remap_pfn_range(). It is absolutely necessary to update all sub-ptes of a largepage mapping on a fault. Adding special handling for this would add considerably complexity to tlb_batch_add(). So let's just side-step the issue and forcefully dirty any writable PTEs created by io_remap_pfn_range(). The only other real option would be to disable to large PTE code of io_remap_pfn_range() and we really don't want to do that. Much thanks to Mikael Pettersson for tracking down this problem and testing debug patches. Signed-off-by: David S. Miller <davem@davemloft.net>
-
Stephen Hemminger authored
Found by inspection. The STRIP driver does neigh_lookup() but never releases. This driver shouldn't being doing gratuitous arp anyway. Untested, obviously, because of lack of hardware. Signed-off-by: Stephen Hemminger <shemminger@osdl.org> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Keir Fraser authored
ipv6_add_addr allocates a struct inet6_ifaddr and a dstentry, but it doesn't install the dstentry in ifa->rt until after it releases the addrconf_hash_lock. This means other CPUs will be able to see the new address while it hasn't been initialized completely yet. One possible fix would be to grab the ifp->lock spinlock when creating the address struct; a simpler fix is to just move the assignment. Acked-by: jbeulich@novell.com Acked-by: okir@suse.de Acked-by: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Akinobu Mita authored
This patch makes crash happen if initialization of nl_table fails in initcalls. It is better than getting use after free crash later. Signed-off-by: Akinobu Mita <mita@miraclelinux.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Daikichi Osuga authored
1) fix slow start after retransmit timeout 2) fix case of L=2*SMSS acked bytes comparison Signed-off-by: Daikichi Osuga <osugad@s1.nttdocomo.co.jp> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Lv Liangying authored
When I tested Linux kernel 2.6.17.7 about statistics "ipv6IfStatsInAddrErrors", found that this counter couldn't increase correctly. The criteria is RFC2465: ipv6IfStatsInAddrErrors OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of input datagrams discarded because the IPv6 address in their IPv6 header's destination field was not a valid address to be received at this entity. This count includes invalid addresses (e.g., ::0) and unsupported addresses (e.g., addresses with unallocated prefixes). For entities which are not IPv6 routers and therefore do not forward datagrams, this counter includes datagrams discarded because the destination address was not a local address." ::= { ipv6IfStatsEntry 5 } When I send packet to host with destination that is ether invalid address(::0) or unsupported addresses(1::1), the Linux kernel just discard the packet, and the counter doesn't increase(in the function ip6_pkt_discard). Signed-off-by: Lv Liangying <lvly@nanjing-fnst.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-