You've already forked linux-apfs
mirror of
https://github.com/linux-apfs/linux-apfs.git
synced 2026-05-01 15:00:59 -07:00
Merge branch 'master'
This commit is contained in:
@@ -11,6 +11,8 @@
|
||||
Joel Schopp <jschopp@austin.ibm.com>
|
||||
ia64/x86_64:
|
||||
Ashok Raj <ashok.raj@intel.com>
|
||||
s390:
|
||||
Heiko Carstens <heiko.carstens@de.ibm.com>
|
||||
|
||||
Authors: Ashok Raj <ashok.raj@intel.com>
|
||||
Lots of feedback: Nathan Lynch <nathanl@austin.ibm.com>,
|
||||
@@ -44,10 +46,24 @@ maxcpus=n Restrict boot time cpus to n. Say if you have 4 cpus, using
|
||||
maxcpus=2 will only boot 2. You can choose to bring the
|
||||
other cpus later online, read FAQ's for more info.
|
||||
|
||||
additional_cpus=n [x86_64 only] use this to limit hotpluggable cpus.
|
||||
additional_cpus=n [x86_64, s390 only] use this to limit hotpluggable cpus.
|
||||
This option sets
|
||||
cpu_possible_map = cpu_present_map + additional_cpus
|
||||
|
||||
ia64 and x86_64 use the number of disabled local apics in ACPI tables MADT
|
||||
to determine the number of potentially hot-pluggable cpus. The implementation
|
||||
should only rely on this to count the #of cpus, but *MUST* not rely on the
|
||||
apicid values in those tables for disabled apics. In the event BIOS doesnt
|
||||
mark such hot-pluggable cpus as disabled entries, one could use this
|
||||
parameter "additional_cpus=x" to represent those cpus in the cpu_possible_map.
|
||||
|
||||
|
||||
possible_cpus=n [s390 only] use this to set hotpluggable cpus.
|
||||
This option sets possible_cpus bits in
|
||||
cpu_possible_map. Thus keeping the numbers of bits set
|
||||
constant even if the machine gets rebooted.
|
||||
This option overrides additional_cpus.
|
||||
|
||||
CPU maps and such
|
||||
-----------------
|
||||
[More on cpumaps and primitive to manipulate, please check
|
||||
|
||||
@@ -0,0 +1,234 @@
|
||||
=================================
|
||||
INTERNAL KERNEL ABI FOR FR-V ARCH
|
||||
=================================
|
||||
|
||||
The internal FRV kernel ABI is not quite the same as the userspace ABI. A number of the registers
|
||||
are used for special purposed, and the ABI is not consistent between modules vs core, and MMU vs
|
||||
no-MMU.
|
||||
|
||||
This partly stems from the fact that FRV CPUs do not have a separate supervisor stack pointer, and
|
||||
most of them do not have any scratch registers, thus requiring at least one general purpose
|
||||
register to be clobbered in such an event. Also, within the kernel core, it is possible to simply
|
||||
jump or call directly between functions using a relative offset. This cannot be extended to modules
|
||||
for the displacement is likely to be too far. Thus in modules the address of a function to call
|
||||
must be calculated in a register and then used, requiring two extra instructions.
|
||||
|
||||
This document has the following sections:
|
||||
|
||||
(*) System call register ABI
|
||||
(*) CPU operating modes
|
||||
(*) Internal kernel-mode register ABI
|
||||
(*) Internal debug-mode register ABI
|
||||
(*) Virtual interrupt handling
|
||||
|
||||
|
||||
========================
|
||||
SYSTEM CALL REGISTER ABI
|
||||
========================
|
||||
|
||||
When a system call is made, the following registers are effective:
|
||||
|
||||
REGISTERS CALL RETURN
|
||||
=============== ======================= =======================
|
||||
GR7 System call number Preserved
|
||||
GR8 Syscall arg #1 Return value
|
||||
GR9-GR13 Syscall arg #2-6 Preserved
|
||||
|
||||
|
||||
===================
|
||||
CPU OPERATING MODES
|
||||
===================
|
||||
|
||||
The FR-V CPU has three basic operating modes. In order of increasing capability:
|
||||
|
||||
(1) User mode.
|
||||
|
||||
Basic userspace running mode.
|
||||
|
||||
(2) Kernel mode.
|
||||
|
||||
Normal kernel mode. There are many additional control registers available that may be
|
||||
accessed in this mode, in addition to all the stuff available to user mode. This has two
|
||||
submodes:
|
||||
|
||||
(a) Exceptions enabled (PSR.T == 1).
|
||||
|
||||
Exceptions will invoke the appropriate normal kernel mode handler. On entry to the
|
||||
handler, the PSR.T bit will be cleared.
|
||||
|
||||
(b) Exceptions disabled (PSR.T == 0).
|
||||
|
||||
No exceptions or interrupts may happen. Any mandatory exceptions will cause the CPU to
|
||||
halt unless the CPU is told to jump into debug mode instead.
|
||||
|
||||
(3) Debug mode.
|
||||
|
||||
No exceptions may happen in this mode. Memory protection and management exceptions will be
|
||||
flagged for later consideration, but the exception handler won't be invoked. Debugging traps
|
||||
such as hardware breakpoints and watchpoints will be ignored. This mode is entered only by
|
||||
debugging events obtained from the other two modes.
|
||||
|
||||
All kernel mode registers may be accessed, plus a few extra debugging specific registers.
|
||||
|
||||
|
||||
=================================
|
||||
INTERNAL KERNEL-MODE REGISTER ABI
|
||||
=================================
|
||||
|
||||
There are a number of permanent register assignments that are set up by entry.S in the exception
|
||||
prologue. Note that there is a complete set of exception prologues for each of user->kernel
|
||||
transition and kernel->kernel transition. There are also user->debug and kernel->debug mode
|
||||
transition prologues.
|
||||
|
||||
|
||||
REGISTER FLAVOUR USE
|
||||
=============== ======= ====================================================
|
||||
GR1 Supervisor stack pointer
|
||||
GR15 Current thread info pointer
|
||||
GR16 GP-Rel base register for small data
|
||||
GR28 Current exception frame pointer (__frame)
|
||||
GR29 Current task pointer (current)
|
||||
GR30 Destroyed by kernel mode entry
|
||||
GR31 NOMMU Destroyed by debug mode entry
|
||||
GR31 MMU Destroyed by TLB miss kernel mode entry
|
||||
CCR.ICC2 Virtual interrupt disablement tracking
|
||||
CCCR.CC3 Cleared by exception prologue (atomic op emulation)
|
||||
SCR0 MMU See mmu-layout.txt.
|
||||
SCR1 MMU See mmu-layout.txt.
|
||||
SCR2 MMU Save for EAR0 (destroyed by icache insns in debug mode)
|
||||
SCR3 MMU Save for GR31 during debug exceptions
|
||||
DAMR/IAMR NOMMU Fixed memory protection layout.
|
||||
DAMR/IAMR MMU See mmu-layout.txt.
|
||||
|
||||
|
||||
Certain registers are also used or modified across function calls:
|
||||
|
||||
REGISTER CALL RETURN
|
||||
=============== =============================== ===============================
|
||||
GR0 Fixed Zero -
|
||||
GR2 Function call frame pointer
|
||||
GR3 Special Preserved
|
||||
GR3-GR7 - Clobbered
|
||||
GR8 Function call arg #1 Return value (or clobbered)
|
||||
GR9 Function call arg #2 Return value MSW (or clobbered)
|
||||
GR10-GR13 Function call arg #3-#6 Clobbered
|
||||
GR14 - Clobbered
|
||||
GR15-GR16 Special Preserved
|
||||
GR17-GR27 - Preserved
|
||||
GR28-GR31 Special Only accessed explicitly
|
||||
LR Return address after CALL Clobbered
|
||||
CCR/CCCR - Mostly Clobbered
|
||||
|
||||
|
||||
================================
|
||||
INTERNAL DEBUG-MODE REGISTER ABI
|
||||
================================
|
||||
|
||||
This is the same as the kernel-mode register ABI for functions calls. The difference is that in
|
||||
debug-mode there's a different stack and a different exception frame. Almost all the global
|
||||
registers from kernel-mode (including the stack pointer) may be changed.
|
||||
|
||||
REGISTER FLAVOUR USE
|
||||
=============== ======= ====================================================
|
||||
GR1 Debug stack pointer
|
||||
GR16 GP-Rel base register for small data
|
||||
GR31 Current debug exception frame pointer (__debug_frame)
|
||||
SCR3 MMU Saved value of GR31
|
||||
|
||||
|
||||
Note that debug mode is able to interfere with the kernel's emulated atomic ops, so it must be
|
||||
exceedingly careful not to do any that would interact with the main kernel in this regard. Hence
|
||||
the debug mode code (gdbstub) is almost completely self-contained. The only external code used is
|
||||
the sprintf family of functions.
|
||||
|
||||
Futhermore, break.S is so complicated because single-step mode does not switch off on entry to an
|
||||
exception. That means unless manually disabled, single-stepping will blithely go on stepping into
|
||||
things like interrupts. See gdbstub.txt for more information.
|
||||
|
||||
|
||||
==========================
|
||||
VIRTUAL INTERRUPT HANDLING
|
||||
==========================
|
||||
|
||||
Because accesses to the PSR is so slow, and to disable interrupts we have to access it twice (once
|
||||
to read and once to write), we don't actually disable interrupts at all if we don't have to. What
|
||||
we do instead is use the ICC2 condition code flags to note virtual disablement, such that if we
|
||||
then do take an interrupt, we note the flag, really disable interrupts, set another flag and resume
|
||||
execution at the point the interrupt happened. Setting condition flags as a side effect of an
|
||||
arithmetic or logical instruction is really fast. This use of the ICC2 only occurs within the
|
||||
kernel - it does not affect userspace.
|
||||
|
||||
The flags we use are:
|
||||
|
||||
(*) CCR.ICC2.Z [Zero flag]
|
||||
|
||||
Set to virtually disable interrupts, clear when interrupts are virtually enabled. Can be
|
||||
modified by logical instructions without affecting the Carry flag.
|
||||
|
||||
(*) CCR.ICC2.C [Carry flag]
|
||||
|
||||
Clear to indicate hardware interrupts are really disabled, set otherwise.
|
||||
|
||||
|
||||
What happens is this:
|
||||
|
||||
(1) Normal kernel-mode operation.
|
||||
|
||||
ICC2.Z is 0, ICC2.C is 1.
|
||||
|
||||
(2) An interrupt occurs. The exception prologue examines ICC2.Z and determines that nothing needs
|
||||
doing. This is done simply with an unlikely BEQ instruction.
|
||||
|
||||
(3) The interrupts are disabled (local_irq_disable)
|
||||
|
||||
ICC2.Z is set to 1.
|
||||
|
||||
(4) If interrupts were then re-enabled (local_irq_enable):
|
||||
|
||||
ICC2.Z would be set to 0.
|
||||
|
||||
A TIHI #2 instruction (trap #2 if condition HI - Z==0 && C==0) would be used to trap if
|
||||
interrupts were now virtually enabled, but physically disabled - which they're not, so the
|
||||
trap isn't taken. The kernel would then be back to state (1).
|
||||
|
||||
(5) An interrupt occurs. The exception prologue examines ICC2.Z and determines that the interrupt
|
||||
shouldn't actually have happened. It jumps aside, and there disabled interrupts by setting
|
||||
PSR.PIL to 14 and then it clears ICC2.C.
|
||||
|
||||
(6) If interrupts were then saved and disabled again (local_irq_save):
|
||||
|
||||
ICC2.Z would be shifted into the save variable and masked off (giving a 1).
|
||||
|
||||
ICC2.Z would then be set to 1 (thus unchanged), and ICC2.C would be unaffected (ie: 0).
|
||||
|
||||
(7) If interrupts were then restored from state (6) (local_irq_restore):
|
||||
|
||||
ICC2.Z would be set to indicate the result of XOR'ing the saved value (ie: 1) with 1, which
|
||||
gives a result of 0 - thus leaving ICC2.Z set.
|
||||
|
||||
ICC2.C would remain unaffected (ie: 0).
|
||||
|
||||
A TIHI #2 instruction would be used to again assay the current state, but this would do
|
||||
nothing as Z==1.
|
||||
|
||||
(8) If interrupts were then enabled (local_irq_enable):
|
||||
|
||||
ICC2.Z would be cleared. ICC2.C would be left unaffected. Both flags would now be 0.
|
||||
|
||||
A TIHI #2 instruction again issued to assay the current state would then trap as both Z==0
|
||||
[interrupts virtually enabled] and C==0 [interrupts really disabled] would then be true.
|
||||
|
||||
(9) The trap #2 handler would simply enable hardware interrupts (set PSR.PIL to 0), set ICC2.C to
|
||||
1 and return.
|
||||
|
||||
(10) Immediately upon returning, the pending interrupt would be taken.
|
||||
|
||||
(11) The interrupt handler would take the path of actually processing the interrupt (ICC2.Z is
|
||||
clear, BEQ fails as per step (2)).
|
||||
|
||||
(12) The interrupt handler would then set ICC2.C to 1 since hardware interrupts are definitely
|
||||
enabled - or else the kernel wouldn't be here.
|
||||
|
||||
(13) On return from the interrupt handler, things would be back to state (1).
|
||||
|
||||
This trap (#2) is only available in kernel mode. In user mode it will result in SIGILL.
|
||||
@@ -36,6 +36,10 @@ Module Parameters
|
||||
(default is 1)
|
||||
Use 'init=0' to bypass initializing the chip.
|
||||
Try this if your computer crashes when you load the module.
|
||||
* reset: int
|
||||
(default is 0)
|
||||
The driver used to reset the chip on load, but does no more. Use
|
||||
'reset=1' to restore the old behavior. Report if you need to do this.
|
||||
|
||||
Description
|
||||
-----------
|
||||
|
||||
@@ -1133,6 +1133,8 @@ running once the system is up.
|
||||
Mechanism 1.
|
||||
conf2 [IA-32] Force use of PCI Configuration
|
||||
Mechanism 2.
|
||||
nommconf [IA-32,X86_64] Disable use of MMCONFIG for PCI
|
||||
Configuration
|
||||
nosort [IA-32] Don't sort PCI devices according to
|
||||
order given by the PCI BIOS. This sorting is
|
||||
done to get a device order compatible with
|
||||
@@ -1636,6 +1638,9 @@ running once the system is up.
|
||||
Format:
|
||||
<irq>,<irq_mask>,<io>,<full_duplex>,<do_sound>,<lockup_hack>[,<irq2>[,<irq3>[,<irq4>]]]
|
||||
|
||||
norandmaps Don't use address space randomization
|
||||
Equivalent to echo 0 > /proc/sys/kernel/randomize_va_space
|
||||
|
||||
|
||||
______________________________________________________________________
|
||||
Changelog:
|
||||
|
||||
+40
-37
@@ -136,17 +136,20 @@ Kprobes, jprobes, and return probes are implemented on the following
|
||||
architectures:
|
||||
|
||||
- i386
|
||||
- x86_64 (AMD-64, E64MT)
|
||||
- x86_64 (AMD-64, EM64T)
|
||||
- ppc64
|
||||
- ia64 (Support for probes on certain instruction types is still in progress.)
|
||||
- ia64 (Does not support probes on instruction slot1.)
|
||||
- sparc64 (Return probes not yet implemented.)
|
||||
|
||||
3. Configuring Kprobes
|
||||
|
||||
When configuring the kernel using make menuconfig/xconfig/oldconfig,
|
||||
ensure that CONFIG_KPROBES is set to "y". Under "Kernel hacking",
|
||||
look for "Kprobes". You may have to enable "Kernel debugging"
|
||||
(CONFIG_DEBUG_KERNEL) before you can enable Kprobes.
|
||||
ensure that CONFIG_KPROBES is set to "y". Under "Instrumentation
|
||||
Support", look for "Kprobes".
|
||||
|
||||
So that you can load and unload Kprobes-based instrumentation modules,
|
||||
make sure "Loadable module support" (CONFIG_MODULES) and "Module
|
||||
unloading" (CONFIG_MODULE_UNLOAD) are set to "y".
|
||||
|
||||
You may also want to ensure that CONFIG_KALLSYMS and perhaps even
|
||||
CONFIG_KALLSYMS_ALL are set to "y", since kallsyms_lookup_name()
|
||||
@@ -262,18 +265,18 @@ at any time after the probe has been registered.
|
||||
|
||||
5. Kprobes Features and Limitations
|
||||
|
||||
As of Linux v2.6.12, Kprobes allows multiple probes at the same
|
||||
address. Currently, however, there cannot be multiple jprobes on
|
||||
the same function at the same time.
|
||||
Kprobes allows multiple probes at the same address. Currently,
|
||||
however, there cannot be multiple jprobes on the same function at
|
||||
the same time.
|
||||
|
||||
In general, you can install a probe anywhere in the kernel.
|
||||
In particular, you can probe interrupt handlers. Known exceptions
|
||||
are discussed in this section.
|
||||
|
||||
For obvious reasons, it's a bad idea to install a probe in
|
||||
the code that implements Kprobes (mostly kernel/kprobes.c and
|
||||
arch/*/kernel/kprobes.c). A patch in the v2.6.13 timeframe instructs
|
||||
Kprobes to reject such requests.
|
||||
The register_*probe functions will return -EINVAL if you attempt
|
||||
to install a probe in the code that implements Kprobes (mostly
|
||||
kernel/kprobes.c and arch/*/kernel/kprobes.c, but also functions such
|
||||
as do_page_fault and notifier_call_chain).
|
||||
|
||||
If you install a probe in an inline-able function, Kprobes makes
|
||||
no attempt to chase down all inline instances of the function and
|
||||
@@ -290,18 +293,14 @@ from the accidental ones. Don't drink and probe.
|
||||
|
||||
Kprobes makes no attempt to prevent probe handlers from stepping on
|
||||
each other -- e.g., probing printk() and then calling printk() from a
|
||||
probe handler. As of Linux v2.6.12, if a probe handler hits a probe,
|
||||
that second probe's handlers won't be run in that instance.
|
||||
probe handler. If a probe handler hits a probe, that second probe's
|
||||
handlers won't be run in that instance, and the kprobe.nmissed member
|
||||
of the second probe will be incremented.
|
||||
|
||||
In Linux v2.6.12 and previous versions, Kprobes' data structures are
|
||||
protected by a single lock that is held during probe registration and
|
||||
unregistration and while handlers are run. Thus, no two handlers
|
||||
can run simultaneously. To improve scalability on SMP systems,
|
||||
this restriction will probably be removed soon, in which case
|
||||
multiple handlers (or multiple instances of the same handler) may
|
||||
run concurrently on different CPUs. Code your handlers accordingly.
|
||||
As of Linux v2.6.15-rc1, multiple handlers (or multiple instances of
|
||||
the same handler) may run concurrently on different CPUs.
|
||||
|
||||
Kprobes does not use semaphores or allocate memory except during
|
||||
Kprobes does not use mutexes or allocate memory except during
|
||||
registration and unregistration.
|
||||
|
||||
Probe handlers are run with preemption disabled. Depending on the
|
||||
@@ -316,11 +315,18 @@ address instead of the real return address for kretprobed functions.
|
||||
(As far as we can tell, __builtin_return_address() is used only
|
||||
for instrumentation and error reporting.)
|
||||
|
||||
If the number of times a function is called does not match the
|
||||
number of times it returns, registering a return probe on that
|
||||
function may produce undesirable results. We have the do_exit()
|
||||
and do_execve() cases covered. do_fork() is not an issue. We're
|
||||
unaware of other specific cases where this could be a problem.
|
||||
If the number of times a function is called does not match the number
|
||||
of times it returns, registering a return probe on that function may
|
||||
produce undesirable results. We have the do_exit() case covered.
|
||||
do_execve() and do_fork() are not an issue. We're unaware of other
|
||||
specific cases where this could be a problem.
|
||||
|
||||
If, upon entry to or exit from a function, the CPU is running on
|
||||
a stack other than that of the current task, registering a return
|
||||
probe on that function may produce undesirable results. For this
|
||||
reason, Kprobes doesn't support return probes (or kprobes or jprobes)
|
||||
on the x86_64 version of __switch_to(); the registration functions
|
||||
return -EINVAL.
|
||||
|
||||
6. Probe Overhead
|
||||
|
||||
@@ -347,14 +353,12 @@ k = 0.77 usec; j = 1.31; r = 1.26; kr = 1.45; jr = 1.99
|
||||
|
||||
7. TODO
|
||||
|
||||
a. SystemTap (http://sourceware.org/systemtap): Work in progress
|
||||
to provide a simplified programming interface for probe-based
|
||||
instrumentation.
|
||||
b. Improved SMP scalability: Currently, work is in progress to handle
|
||||
multiple kprobes in parallel.
|
||||
c. Kernel return probes for sparc64.
|
||||
d. Support for other architectures.
|
||||
e. User-space probes.
|
||||
a. SystemTap (http://sourceware.org/systemtap): Provides a simplified
|
||||
programming interface for probe-based instrumentation. Try it out.
|
||||
b. Kernel return probes for sparc64.
|
||||
c. Support for other architectures.
|
||||
d. User-space probes.
|
||||
e. Watchpoint probes (which fire on data references).
|
||||
|
||||
8. Kprobes Example
|
||||
|
||||
@@ -411,8 +415,7 @@ int init_module(void)
|
||||
printk("Couldn't find %s to plant kprobe\n", "do_fork");
|
||||
return -1;
|
||||
}
|
||||
ret = register_kprobe(&kp);
|
||||
if (ret < 0) {
|
||||
if ((ret = register_kprobe(&kp) < 0)) {
|
||||
printk("register_kprobe failed, returned %d\n", ret);
|
||||
return -1;
|
||||
}
|
||||
|
||||
@@ -95,11 +95,13 @@ CONFIG_BLK_DEV_IDEDMA_PCI=y
|
||||
CONFIG_IDEDMA_PCI_AUTO=y
|
||||
CONFIG_BLK_DEV_IDE_AU1XXX=y
|
||||
CONFIG_BLK_DEV_IDE_AU1XXX_MDMA2_DBDMA=y
|
||||
CONFIG_BLK_DEV_IDE_AU1XXX_BURSTABLE_ON=y
|
||||
CONFIG_BLK_DEV_IDE_AU1XXX_SEQTS_PER_RQ=128
|
||||
CONFIG_BLK_DEV_IDEDMA=y
|
||||
CONFIG_IDEDMA_AUTO=y
|
||||
|
||||
Also define 'IDE_AU1XXX_BURSTMODE' in 'drivers/ide/mips/au1xxx-ide.c' to enable
|
||||
the burst support on DBDMA controller.
|
||||
|
||||
If the used system need the USB support enable the following kernel configs for
|
||||
high IDE to USB throughput.
|
||||
|
||||
@@ -115,6 +117,8 @@ CONFIG_BLK_DEV_IDE_AU1XXX_SEQTS_PER_RQ=128
|
||||
CONFIG_BLK_DEV_IDEDMA=y
|
||||
CONFIG_IDEDMA_AUTO=y
|
||||
|
||||
Also undefine 'IDE_AU1XXX_BURSTMODE' in 'drivers/ide/mips/au1xxx-ide.c' to
|
||||
disable the burst support on DBDMA controller.
|
||||
|
||||
ADD NEW HARD DISC TO WHITE OR BLACK LIST
|
||||
----------------------------------------
|
||||
|
||||
@@ -1,3 +1,26 @@
|
||||
1 Release Date : Wed Feb 03 14:31:44 PST 2006 - Sumant Patro <Sumant.Patro@lsil.com>
|
||||
2 Current Version : 00.00.02.04
|
||||
3 Older Version : 00.00.02.04
|
||||
|
||||
i. Support for 1078 type (ppc IOP) controller, device id : 0x60 added.
|
||||
During initialization, depending on the device id, the template members
|
||||
are initialized with function pointers specific to the ppc or
|
||||
xscale controllers.
|
||||
|
||||
-Sumant Patro <Sumant.Patro@lsil.com>
|
||||
|
||||
1 Release Date : Fri Feb 03 14:16:25 PST 2006 - Sumant Patro
|
||||
<Sumant.Patro@lsil.com>
|
||||
2 Current Version : 00.00.02.04
|
||||
3 Older Version : 00.00.02.02
|
||||
i. Register 16 byte CDB capability with scsi midlayer
|
||||
|
||||
"Ths patch properly registers the 16 byte command length capability of the
|
||||
megaraid_sas controlled hardware with the scsi midlayer. All megaraid_sas
|
||||
hardware supports 16 byte CDB's."
|
||||
|
||||
-Joshua Giles <joshua_giles@dell.com>
|
||||
|
||||
1 Release Date : Mon Jan 23 14:09:01 PST 2006 - Sumant Patro <Sumant.Patro@lsil.com>
|
||||
2 Current Version : 00.00.02.02
|
||||
3 Older Version : 00.00.02.01
|
||||
|
||||
@@ -1,7 +1,7 @@
|
||||
VERSION = 2
|
||||
PATCHLEVEL = 6
|
||||
SUBLEVEL = 16
|
||||
EXTRAVERSION =-rc3
|
||||
EXTRAVERSION =-rc4
|
||||
NAME=Sliding Snow Leopard
|
||||
|
||||
# *DOCUMENTATION*
|
||||
@@ -106,13 +106,12 @@ KBUILD_OUTPUT := $(shell cd $(KBUILD_OUTPUT) && /bin/pwd)
|
||||
$(if $(KBUILD_OUTPUT),, \
|
||||
$(error output directory "$(saved-output)" does not exist))
|
||||
|
||||
.PHONY: $(MAKECMDGOALS) cdbuilddir
|
||||
$(MAKECMDGOALS) _all: cdbuilddir
|
||||
.PHONY: $(MAKECMDGOALS)
|
||||
|
||||
cdbuilddir:
|
||||
$(filter-out _all,$(MAKECMDGOALS)) _all:
|
||||
$(if $(KBUILD_VERBOSE:1=),@)$(MAKE) -C $(KBUILD_OUTPUT) \
|
||||
KBUILD_SRC=$(CURDIR) \
|
||||
KBUILD_EXTMOD="$(KBUILD_EXTMOD)" -f $(CURDIR)/Makefile $(MAKECMDGOALS)
|
||||
KBUILD_EXTMOD="$(KBUILD_EXTMOD)" -f $(CURDIR)/Makefile $@
|
||||
|
||||
# Leave processing to above invocation of make
|
||||
skip-makefile := 1
|
||||
|
||||
@@ -111,7 +111,7 @@
|
||||
CALL(sys_statfs)
|
||||
/* 100 */ CALL(sys_fstatfs)
|
||||
CALL(sys_ni_syscall)
|
||||
CALL(OBSOLETE(sys_socketcall))
|
||||
CALL(OBSOLETE(ABI(sys_socketcall, sys_oabi_socketcall)))
|
||||
CALL(sys_syslog)
|
||||
CALL(sys_setitimer)
|
||||
/* 105 */ CALL(sys_getitimer)
|
||||
|
||||
@@ -23,6 +23,7 @@
|
||||
#include <linux/root_dev.h>
|
||||
#include <linux/cpu.h>
|
||||
#include <linux/interrupt.h>
|
||||
#include <linux/smp.h>
|
||||
|
||||
#include <asm/cpu.h>
|
||||
#include <asm/elf.h>
|
||||
@@ -771,6 +772,10 @@ void __init setup_arch(char **cmdline_p)
|
||||
paging_init(&meminfo, mdesc);
|
||||
request_standard_resources(&meminfo, mdesc);
|
||||
|
||||
#ifdef CONFIG_SMP
|
||||
smp_init_cpus();
|
||||
#endif
|
||||
|
||||
cpu_init();
|
||||
|
||||
/*
|
||||
|
||||
@@ -338,7 +338,6 @@ void __init smp_prepare_boot_cpu(void)
|
||||
|
||||
per_cpu(cpu_data, cpu).idle = current;
|
||||
|
||||
cpu_set(cpu, cpu_possible_map);
|
||||
cpu_set(cpu, cpu_present_map);
|
||||
cpu_set(cpu, cpu_online_map);
|
||||
}
|
||||
|
||||
@@ -64,6 +64,7 @@
|
||||
* sys_connect:
|
||||
* sys_sendmsg:
|
||||
* sys_sendto:
|
||||
* sys_socketcall:
|
||||
*
|
||||
* struct sockaddr_un loses its padding with EABI. Since the size of the
|
||||
* structure is used as a validation test in unix_mkname(), we need to
|
||||
@@ -78,6 +79,7 @@
|
||||
#include <linux/eventpoll.h>
|
||||
#include <linux/sem.h>
|
||||
#include <linux/socket.h>
|
||||
#include <linux/net.h>
|
||||
#include <asm/ipc.h>
|
||||
#include <asm/uaccess.h>
|
||||
|
||||
@@ -408,3 +410,31 @@ asmlinkage long sys_oabi_sendmsg(int fd, struct msghdr __user *msg, unsigned fla
|
||||
return sys_sendmsg(fd, msg, flags);
|
||||
}
|
||||
|
||||
asmlinkage long sys_oabi_socketcall(int call, unsigned long __user *args)
|
||||
{
|
||||
unsigned long r = -EFAULT, a[6];
|
||||
|
||||
switch (call) {
|
||||
case SYS_BIND:
|
||||
if (copy_from_user(a, args, 3 * sizeof(long)) == 0)
|
||||
r = sys_oabi_bind(a[0], (struct sockaddr __user *)a[1], a[2]);
|
||||
break;
|
||||
case SYS_CONNECT:
|
||||
if (copy_from_user(a, args, 3 * sizeof(long)) == 0)
|
||||
r = sys_oabi_connect(a[0], (struct sockaddr __user *)a[1], a[2]);
|
||||
break;
|
||||
case SYS_SENDTO:
|
||||
if (copy_from_user(a, args, 6 * sizeof(long)) == 0)
|
||||
r = sys_oabi_sendto(a[0], (void __user *)a[1], a[2], a[3],
|
||||
(struct sockaddr __user *)a[4], a[5]);
|
||||
break;
|
||||
case SYS_SENDMSG:
|
||||
if (copy_from_user(a, args, 3 * sizeof(long)) == 0)
|
||||
r = sys_oabi_sendmsg(a[0], (struct msghdr __user *)a[1], a[2]);
|
||||
break;
|
||||
default:
|
||||
r = sys_socketcall(call, args);
|
||||
}
|
||||
|
||||
return r;
|
||||
}
|
||||
|
||||
@@ -140,6 +140,18 @@ static void __init poke_milo(void)
|
||||
mb();
|
||||
}
|
||||
|
||||
/*
|
||||
* Initialise the CPU possible map early - this describes the CPUs
|
||||
* which may be present or become present in the system.
|
||||
*/
|
||||
void __init smp_init_cpus(void)
|
||||
{
|
||||
unsigned int i, ncores = get_core_count();
|
||||
|
||||
for (i = 0; i < ncores; i++)
|
||||
cpu_set(i, cpu_possible_map);
|
||||
}
|
||||
|
||||
void __init smp_prepare_cpus(unsigned int max_cpus)
|
||||
{
|
||||
unsigned int ncores = get_core_count();
|
||||
@@ -176,14 +188,11 @@ void __init smp_prepare_cpus(unsigned int max_cpus)
|
||||
max_cpus = ncores;
|
||||
|
||||
/*
|
||||
* Initialise the possible/present maps.
|
||||
* cpu_possible_map describes the set of CPUs which may be present
|
||||
* cpu_present_map describes the set of CPUs populated
|
||||
* Initialise the present map, which describes the set of CPUs
|
||||
* actually populated at the present time.
|
||||
*/
|
||||
for (i = 0; i < max_cpus; i++) {
|
||||
cpu_set(i, cpu_possible_map);
|
||||
for (i = 0; i < max_cpus; i++)
|
||||
cpu_set(i, cpu_present_map);
|
||||
}
|
||||
|
||||
/*
|
||||
* Do we need any more CPUs? If so, then let them know where
|
||||
|
||||
@@ -13,7 +13,6 @@
|
||||
#include <linux/mm.h>
|
||||
#include <linux/init.h>
|
||||
#include <linux/config.h>
|
||||
#include <linux/init.h>
|
||||
#include <linux/major.h>
|
||||
#include <linux/fs.h>
|
||||
#include <linux/platform_device.h>
|
||||
|
||||
@@ -12,7 +12,6 @@
|
||||
#include <linux/mm.h>
|
||||
#include <linux/init.h>
|
||||
#include <linux/config.h>
|
||||
#include <linux/init.h>
|
||||
#include <linux/major.h>
|
||||
#include <linux/fs.h>
|
||||
#include <linux/platform_device.h>
|
||||
|
||||
@@ -27,8 +27,6 @@ static struct flash_platform_data nslu2_flash_data = {
|
||||
};
|
||||
|
||||
static struct resource nslu2_flash_resource = {
|
||||
.start = NSLU2_FLASH_BASE,
|
||||
.end = NSLU2_FLASH_BASE + NSLU2_FLASH_SIZE,
|
||||
.flags = IORESOURCE_MEM,
|
||||
};
|
||||
|
||||
@@ -116,6 +114,10 @@ static void __init nslu2_init(void)
|
||||
{
|
||||
ixp4xx_sys_init();
|
||||
|
||||
nslu2_flash_resource.start = IXP4XX_EXP_BUS_BASE(0);
|
||||
nslu2_flash_resource.end =
|
||||
IXP4XX_EXP_BUS_BASE(0) + ixp4xx_exp_bus_size - 1;
|
||||
|
||||
pm_power_off = nslu2_power_off;
|
||||
|
||||
platform_add_devices(nslu2_devices, ARRAY_SIZE(nslu2_devices));
|
||||
|
||||
@@ -143,6 +143,18 @@ static void __init poke_milo(void)
|
||||
mb();
|
||||
}
|
||||
|
||||
/*
|
||||
* Initialise the CPU possible map early - this describes the CPUs
|
||||
* which may be present or become present in the system.
|
||||
*/
|
||||
void __init smp_init_cpus(void)
|
||||
{
|
||||
unsigned int i, ncores = get_core_count();
|
||||
|
||||
for (i = 0; i < ncores; i++)
|
||||
cpu_set(i, cpu_possible_map);
|
||||
}
|
||||
|
||||
void __init smp_prepare_cpus(unsigned int max_cpus)
|
||||
{
|
||||
unsigned int ncores = get_core_count();
|
||||
@@ -179,14 +191,11 @@ void __init smp_prepare_cpus(unsigned int max_cpus)
|
||||
local_timer_setup(cpu);
|
||||
|
||||
/*
|
||||
* Initialise the possible/present maps.
|
||||
* cpu_possible_map describes the set of CPUs which may be present
|
||||
* cpu_present_map describes the set of CPUs populated
|
||||
* Initialise the present map, which describes the set of CPUs
|
||||
* actually populated at the present time.
|
||||
*/
|
||||
for (i = 0; i < max_cpus; i++) {
|
||||
cpu_set(i, cpu_possible_map);
|
||||
for (i = 0; i < max_cpus; i++)
|
||||
cpu_set(i, cpu_present_map);
|
||||
}
|
||||
|
||||
/*
|
||||
* Do we need any more CPUs? If so, then let them know where
|
||||
|
||||
@@ -38,7 +38,6 @@
|
||||
#include <linux/pm.h>
|
||||
#include <linux/sched.h>
|
||||
#include <linux/proc_fs.h>
|
||||
#include <linux/pm.h>
|
||||
#include <linux/interrupt.h>
|
||||
|
||||
#include <asm/io.h>
|
||||
|
||||
@@ -25,6 +25,10 @@ config GENERIC_HARDIRQS
|
||||
bool
|
||||
default n
|
||||
|
||||
config TIME_LOW_RES
|
||||
bool
|
||||
default y
|
||||
|
||||
mainmenu "Fujitsu FR-V Kernel Configuration"
|
||||
|
||||
source "init/Kconfig"
|
||||
|
||||
+1
-1
@@ -81,7 +81,7 @@ endif
|
||||
# - reserve CC3 for use with atomic ops
|
||||
# - all the extra registers are dealt with only at context switch time
|
||||
CFLAGS += -mno-fdpic -mgpr-32 -msoft-float -mno-media
|
||||
CFLAGS += -ffixed-fcc3 -ffixed-cc3 -ffixed-gr15
|
||||
CFLAGS += -ffixed-fcc3 -ffixed-cc3 -ffixed-gr15 -ffixed-icc2
|
||||
AFLAGS += -mno-fdpic
|
||||
ASFLAGS += -mno-fdpic
|
||||
|
||||
|
||||
Some files were not shown because too many files have changed in this diff Show More
Reference in New Issue
Block a user