25 Jan, 2008
24 commits
-
Signed-off-by: Haavard Skinnemoen
-
Turn off a few useless options, enable a few useful ones and enable
quite a few new drivers.Signed-off-by: Haavard Skinnemoen
-
Remove the CPU selection menu and instead let it be selected by the
board or daughterboard option. Add daughterboard selection for
ATSTK1000 (this was previously determined based on CPU type.)Signed-off-by: Haavard Skinnemoen
-
ATSTK1003 and ATSTK1004 are CPU daughterboards for ATSTK1000 featuring
the AT32AP7001 and AT32AP7002 CPUs, respectively.Signed-off-by: Haavard Skinnemoen
-
Reduce the ridiculous amount of #ifdef clutter in atstk1002.c a bit by
moving all the extdac stuff into its own function and providing an
empty stub for the case when it isn't wanted.Signed-off-by: Haavard Skinnemoen
-
There may be other boards than STK1002 that want to use the leds on
STK1000. Move it to stk1000 common code to make it easier to reuse.Signed-off-by: Haavard Skinnemoen
-
These are derivatives of the AT32AP7000 chip, which means that most of
the code stays the same. Rename a few files, functions, definitions
and config symbols to reflect that they apply to all AP700x chips, and
exclude some platform devices from chips where they aren't present.Signed-off-by: Haavard Skinnemoen
-
Add the following fields to /proc/cpuinfo:
* chip type and revision (from the JTAG chip id)
* cpu MHz (from clk_get_rate())
* features (from the CONFIG0 register)Also rename "cpu family" to "cpu arch" and "cpu type" to "cpu core" to
remove some ambiguity.Show chip type and revision at bootup, and clarify that the other
kinds of IDs that we're already printing are for the cpu core and
architecture. Rename "AP7000" to "AP7" since that's the name of the
core.Signed-off-by: Haavard Skinnemoen
-
This adds the necessary architecture code to run oprofile on AVR32
using the performance counters documented by the AVR32 Architecture
Manual.Signed-off-by: Haavard Skinnemoen
Acked-by: Philippe Elie -
Remove KPROBES option from Kconfig.debug and include
kernel/Kconfig.instrumentation.Signed-off-by: Haavard Skinnemoen
-
This patch disables the VGA text console for AVR32 architecture since
it does not provide the vga.h include file.AVR32 users should use framebuffer console instead if they need a
console on an attached display.Signed-off-by: Hans-Christian Egtvedt
Signed-off-by: Haavard Skinnemoen -
Keep track of processes being debugged (including the kernel itself)
and turn the OCD system on and off as appropriate. Since enabling
debugging turns off some optimizations in the CPU core, this fixes the
issue that enabling KProbes support or simply running a program under
gdbserver will reduce system performance significantly until the next
reboot.The CPU performance will still be reduced for all processes while a
process is being debugged, but this is a lot better than reducing the
performance forever.Signed-off-by: Haavard Skinnemoen
-
arch_ptrace_attach() is a hook that allows the architecture to do
book-keeping after a ptrace attach. This patch adds a call to this
hook when handling a PTRACE_TRACEME request as well.Currently only one architecture, m32r, implements this hook. When
called, it initializes a number of debug trap slots in the ptraced
task's thread struct, and it looks to me like this is the right thing
to do after a PTRACE_TRACEME request as well, not only after
PTRACE_ATTACH. Please correct me if I'm wrong.I want to use this hook on AVR32 to turn the debugging hardware on
when a process is actually being debugged and keep it off otherwise.
To be able to do this, I need to intercept PTRACE_TRACEME and
PTRACE_ATTACH, as well as PTRACE_DETACH and thread exit. The latter
two can be handled by existing hooks.Signed-off-by: Haavard Skinnemoen
-
get_signal_to_deliver() will call try_to_freeze(), so there's no point
in do_signal() doing it as well.Signed-off-by: Haavard Skinnemoen
-
dma_alloc_coherent wants to split pages after allocation in order to
reduce the memory footprint. This does not work well with GFP_COMP
pages, so drop this flag before allocation.This patch was forward-ported from BSP 2.0
Signed-off-by: Haavard Skinnemoen
-
Before transmission of the last word in PIO RX_ONLY mode rx+tx mode
is enabled:/* prevent last RX_ONLY read from triggering
* more word i/o: switch to rx+tx
*/
if (c == 0 && tx == NULL)
mcspi_write_cs_reg(spi,
OMAP2_MCSPI_CHCONF0, l);But because c is decremented after the test, c will never be zero and
rx+tx will not be enabled. This breaks RX_ONLY mode PIO transfers.Fix it by decrementing c in the beginning of the various I/O loops.
Signed-off-by: Kalle Valo
Signed-off-by: David Brownell
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
This reverts commit 81100eb80add328c4d2a377326f15aa0e7236398 for the
release, to avoid the unnecessary warning noise that is only really
relevant to wireless driver developers.The warning will probably go right back in after I cut the release, but
at least we won't unnecessarily worry users.Acked-by: John W. Linville
Signed-off-by: Linus Torvalds -
* git://git.kernel.org/pub/scm/linux/kernel/git/davem/sparc-2.6:
[SPARC64]: Partially revert "Constify function pointer tables." -
* 'release' of git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6:
Revert "ACPI: Fan: Drop force_power_state acpi_device option"
ACPI: EC: "DEBUG" needs to be defined earlier
ACPI: EC: add leading zeros to debug messages
ACPI: EC: fix dmesg spam regression
ACPI: DMI blacklist to reduce console warnings on OSI(Linux) systems.
ACPI: Add ThinkPad R61, ThinkPad T61 to OSI(Linux) white-list
ACPI: make _OSI(Linux) console messages smarter
ACPI: Delete Intel Customer Reference Board (CRB) from OSI(Linux) DMI list
ACPI: on OSI(Linux), print needed DMI rather than requesting dmidecode output
ACPI: create acpi_dmi_dump()
DMI: create dmi_get_slot()
DMI: move dmi_available declaration to linux/dmi.h
ACPI: processor: Fix null pointer dereference in throttling -
Partial revert the changes made by 04231b3002ac53f8a64a7bd142fde3fa4b6808c6
to the kmem_list3 management. On a machine with a memoryless node, this
BUG_ON was triggeringstatic void *____cache_alloc_node(struct kmem_cache *cachep, gfp_t flags, int nodeid)
{
struct list_head *entry;
struct slab *slabp;
struct kmem_list3 *l3;
void *obj;
int x;l3 = cachep->nodelists[nodeid];
BUG_ON(!l3);Signed-off-by: Mel Gorman
Cc: Pekka Enberg
Acked-by: Christoph Lameter
Cc: "Aneesh Kumar K.V"
Cc: Nishanth Aravamudan
Cc: KAMEZAWA Hiroyuki
Cc: Paul Mackerras
Cc: Benjamin Herrenschmidt
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
The shared page table code for hugetlb memory on x86 and x86_64
is causing a leak. When a user of hugepages exits using this code
the system leaks some of the hugepages.-------------------------------------------------------
Part of /proc/meminfo just before database startup:
HugePages_Total: 5500
HugePages_Free: 5500
HugePages_Rsvd: 0
Hugepagesize: 2048 kBJust before shutdown:
HugePages_Total: 5500
HugePages_Free: 4475
HugePages_Rsvd: 0
Hugepagesize: 2048 kBAfter shutdown:
HugePages_Total: 5500
HugePages_Free: 4988
HugePages_Rsvd:
0 Hugepagesize: 2048 kB
----------------------------------------------------------The problem occurs durring a fork, in copy_hugetlb_page_range(). It
locates the dst_pte using huge_pte_alloc(). Since huge_pte_alloc() calls
huge_pmd_share() it will share the pmd page if can, yet the main loop in
copy_hugetlb_page_range() does a get_page() on every hugepage. This is a
violation of the shared hugepmd pagetable protocol and creates additional
referenced to the hugepages causing a leak when the unmap of the VMA
occurs. We can skip the entire replication of the ptes when the hugepage
pagetables are shared. The attached patch skips copying the ptes and the
get_page() calls if the hugetlbpage pagetable is shared.[akpm@linux-foundation.org: coding-style cleanups]
Signed-off-by: Larry Woodman
Signed-off-by: Adam Litke
Cc: Badari Pulavarty
Cc: Ken Chen
Cc: David Gibson
Cc: William Lee Irwin III
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
: Stefan Roese said:
> ppc: 4xx: sysctl table check failed: /kernel/l2cr .1.31 Missing strategy
>
> I'm seeing this error message when booting an recent arch/ppc kernel on
> 4xx platforms (tested on Ocotea and other 4xx platforms). Booting NFS
> rootfs still works fine, but this message kind of makes me "nervous".
> This is not seen on 4xx arch/powerpc platforms. Here the bootlog:Because the data field was never filled and a binary sysctl handler was
never written this sysctl has never been usable through the sys_sysctl
interface. So just remove the binary sysctl number. Making the kernel
sanity checks happy.Signed-off-by: Eric W. Biederman
Reported-by: Stefan Roese
Cc: Josh Boyer
Cc: Wolfgang Denk
Cc: Paul Mackerras
Cc: Benjamin Herrenschmidt
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
Michael Wu noticed in his lkml post at
http://marc.info/?l=linux-kernel&m=119396182726091&w=2
that certain wireless drivers ended up having their name in module
memory, which would then crash the kernel on module unload.The patch he proposed was a bit clumsy in that it increased the size of
a lockdep entry significantly; the patch below tries another approach,
it checks, on module teardown, if the name of a class is in module space
and then zaps the class. This is very similar to what we already do
with keys that are in module space.Signed-off-by: Arjan van de Ven
Signed-off-by: Ingo Molnar
Acked-by: Peter Zijlstra
Signed-off-by: Linus Torvalds
24 Jan, 2008
16 commits
-
This partially reverts 872e2be7c4056496c2871bd9b0f2fae6c374fe47
(Constify function pointer tables.)The solaris/socksys.c transformation wasn't valid:
arch/sparc64/solaris/socksys.c:192: error: assignment of read-only variable ‘socksys_file_ops’
arch/sparc64/solaris/socksys.c:195: error: assignment of read-only variable ‘socksys_file_ops’
arch/sparc64/solaris/socksys.c:196: error: assignment of read-only variable ‘socksys_file_ops’Signed-off-by: David S. Miller
-
This reverts commit 93ad7c07ad487b036add8760dabcc35666a550ef.
http://bugzilla.kernel.org/show_bug.cgi?id=9798
Signed-off-by: Len Brown
-
The "DEBUG" symbol needs to be defined before #including to
get the pr_debug() working.Signed-off-by: Márton Németh
Signed-off-by: Len Brown -
Add leading zeros to pr_debug() calls. For example if x=0x0a, the format
"0x%2x" will result the string "0x a", the format "0x%2.2x" will result "0x0a".Signed-off-by: Márton Németh
Signed-off-by: Len Brown -
Return OBF_1 optimization workaround
http://bugzilla.kernel.org/show_bug.cgi?id=8459
Signed-off-by: Alexey Starikovskiy
Signed-off-by: Len Brown -
* git://git.kernel.org/pub/scm/linux/kernel/git/davem/sparc-2.6:
[SPARC]: Constify function pointer tables.
[SPARC64]: Fix section error in sparcspkr
[SPARC64]: Fix of section mismatch warnings. -
* git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-2.6:
sis190: scheduling while atomic error
sis190: mdio operation failure is not correctly detected
sis190: remove duplicate INIT_WORK
sis190: add cmos ram access code for the SiS19x/968 chipset pair
[INET]: Fix truesize setting in ip_append_data
[NETNS]: Re-export init_net via EXPORT_SYMBOL.
iwlwifi: fix possible read attempt on ucode that is not available
[IPV4]: Add missing skb->truesize increment in ip_append_page().
[TULIP] DMFE: Fix SROM parsing regression.
[BLUETOOTH]: Move children of connection device to NULL before connection down. -
This DMI blacklist reduces the console messages
on systems which have a BIOS that invokes OSI(Linux).As the DMI blacklist already knows about these systems,
the request for DMI info itself is disabled.Further, if OSI(Linux) has already been determined
to have no beneift, we disable the console message
requesting acpi_osi=Linux test results.Signed-off-by: Len Brown
-
acpi_osi=Linux helps sound on these systems.
Signed-off-by: Len Brown
-
If BIOS invokes _OSI(Linux), the kernel response
depends on what the ACPI DMI list knows about the system,
and that is reflectd in dmesg:1) System unknown to DMI:
ACPI: BIOS _OSI(Linux) query ignored
ACPI: DMI System Vendor: LENOVO
ACPI: DMI Product Name: 7661W1P
ACPI: DMI Product Version: ThinkPad T61
ACPI: DMI Board Name: 7661W1P
ACPI: DMI BIOS Vendor: LENOVO
ACPI: DMI BIOS Date: 10/18/2007
ACPI: Please send DMI info above to linux-acpi@vger.kernel.org
ACPI: If "acpi_osi=Linux" works better, please notify linux-acpi@vger.kernel.org2) System known to DMI, but effect of OSI(Linux) unknown:
ACPI: DMI detected: Lenovo ThinkPad T61
...
ACPI: BIOS _OSI(Linux) query ignored via DMI
ACPI: If "acpi_osi=Linux" works better, please notify linux-acpi@vger.kernel.org3) System known to DMI, which disables _OSI(Linux):
ACPI: DMI detected: Lenovo ThinkPad T61
...
ACPI: BIOS _OSI(Linux) query ignored via DMI4) System known to DMI, which enable _OSI(Linux):
ACPI: DMI detected: Lenovo ThinkPad T61
ACPI: Added _OSI(Linux)
...
ACPI: BIOS _OSI(Linux) query honored via DMIcmdline overrides take precidence over the built-in
default and the DMI prescribed default.
cmdline "acpi_osi=Linux" results in:ACPI: BIOS _OSI(Linux) query honored via cmdline
Signed-off-by: Len Brown
-
Linux does not want BIOS writers to invoke _OSI(Linux) -
for in the field it causes more Windows incompatibility problems
than it solves.So when it is seen in the BIOS for an Intel Customer Reference Board,
Linux should ignore its effect by default, and should complain loudly.
Otherwise, the reference BIOS will go unfixed, and the bad BIOS
will spread to the field.Users of this board can get the old behavior with "acpi_osi=Linux"
As this was the only entry, delete acpi_osl_dmi_table[].
Signed-off-by: Len Brown
-
Signed-off-by: Len Brown
