An error occurred fetching the project authors.
- 19 Feb, 2004 1 commit
-
-
Andrew Morton authored
gcc-3.4 incorretly inlines rest_init() into start_kernel(), causing things to crash when the .text.init section gets unloaded. Use noinline to prevent that.
-
- 18 Feb, 2004 2 commits
-
-
Andrew Morton authored
From: Tim Hockin <thockin@sun.com> Remove the max_anon via dynamically allocation. We also change the idr_pre_get() interface to take a gfp mask, which should have always been there.
-
Andrew Morton authored
From: Werner Almesberger <werner@almesberger.net> When passing too many unrecognized boot command line options (which become arguments or environment variables), the 2.6 kernel panics (unlike 2.4, which just ignores the extra items). Unfortunately, this happens before the console is initialized, so all you get is a kernel that dies quickly, for no apparent reason. This is particularly irritating if using UML with init=something wi th a lot of ar gu men t s The patch below delays the panic until after console_init. (akpm: I mainly added this in because we have other places where the panic-later-on machinery is needed).
-
- 04 Feb, 2004 1 commit
-
-
Andrew Morton authored
From: Jes Sorensen <jes@trained-monkey.org> I'd like to propose the following for 2.6.1-mm/2.6.2. On systems with a large number of CPUs the number of printk's flowing by for each CPU booting starts becoming a real console hog. The following patch eliminates a couple of them (already sent a patch to David for the ia64 specific ones) as well as changes the "Building zonelist : X" in "Built Y zonelists". IMHO it doesn't make any sense to print for each zonelist since it's run in a for loop running from 0 to Y-1 anyway. The patch nukes a few new printk's that were introduced with the scheduler changes to the NUMA code in -mm3, if these are still needed then I won't fight for that part of the patch.
-
- 26 Jan, 2004 1 commit
-
-
Linus Torvalds authored
-
- 23 Jan, 2004 1 commit
-
-
Dave Jones authored
This currently prints out the maximum number of CPUs the kernel is configured to support, instead of the actual number that the kernel brought up. Which results in odd displays that look like you have more CPUs than you do.
-
- 19 Jan, 2004 2 commits
-
-
Paul Mackerras authored
This patch arranges for the exception tables to be sorted on most architectures. It sorts the main kernel exception table on startup and the module exception tables when they get loaded. The main table is sorted reasonably early - just after kmem_cache_init - but that could be moved even earlier if necessary. There is now a lib/extable.c which includes the sort_extable() function from arch/ppc/mm/extable.c and the search_extable() function from arch/i386/mm/extable.c, which had been copied to many architectures. On many architectures, arch/$(ARCH)/mm/extable.c became empty and so I have removed it. There are four architectures which do things differently from i386: alpha, ia64, sparc and sparc64. Alpha and ia64 store the offset from the offset from the exception table entry to the instruction, and sparc and sparc64 have range entries in the table. For those architectures I have added empty sort_extable functions. The maintainers for those architectures can implement something better if they care to. As it is they are no worse off than before. Although it is a moderately sizable patch, it ends up with a net reduction of 377 lines in the size of the kernel source. :) I have tested this on x86 and ppc with a module that uses __get_user in an init function, deliberately laid out to get the exception table out of order, and it works (whereas it oopsed without this patch).
-
Andrew Morton authored
From: Jes Sorensen <jes@trained-monkey.org> The following patch removes a couple of null-ilizers of global variables. Not a big deal, but every byte helps in the .data segment ;-)
-
- 30 Dec, 2003 1 commit
-
-
Andrew Morton authored
From: OGAWA Hirofumi <hirofumi@mail.parknet.co.jp> - remove unused "rows" and "cols" - change the 2 variable to static
-
- 29 Dec, 2003 3 commits
-
-
Andrew Morton authored
From: James Morris <jmorris@redhat.com> The patch below removes the CLONE_FILES flag from the kernel_thread() call which starts init. This is to prevent other kernel threads from sharing file descriptors opened by init (try 'lsof /dev/initctl' on a 2.6 system :-). The reason this patch is being proposed is so that usermode helper apps launched via kernel threads (e.g. modprobe, hotplug) do not then inherit any such file descriptors. This is not a problem in itself so far (other than being messy), but it is a problem for SELinux, which will otherwise need to grant access to /dev/initctl by modprobe and hotplug, a somewhat undesirable scenario. As far as I can tell, there is no reason why init needs to be spawned with CLONE_FILES. Please let me know if there are any objections to the change, which I would like to propose for 2.6.0+ as a cleanup.
-
Andrew Morton authored
This tunable refers to the amount of free memory which the VM will attempt to sustain. It is mainly needed for atomic allocations (eg, networking receive). It is currently hardwired to 1024k, which is far too large for small machines and too small for large machines. Rework it to be 128k on tiny machines and 16M on huge machines.
-
Andrew Morton authored
From: Matt Tolentino <metolent@snoqualmie.dp.intel.com> Attached is a patch that enables EFI boot-up support in ia32 kernels. In order to continue to determine whether the kernel should initialize using EFI tables, I've temporarily added a check on the LOADER_TYPE boot parameter. Although I haven't requested that elilo be assigned an id for this yet, I've used this to determine whether the kernel should use the EFI initialization path as well as a check to see if the EFI_SYSTAB boot parameter contains anything. If someone has a better suggestion for determining this, I'm open... This patch also uses the existing ioremapping functions to map the efi tables into kernel virtual address space. I've added an option such that I could use Dave Hansen's boot_ioremap() before paging_init(). After paging_init, I then remap the efi memmap using bt_ioremap for use later. This has eliminated the need for several functions...thanks for the suggestions and thanks for your help Dave. Still this could use a look-see.
-
- 22 Oct, 2003 1 commit
-
-
Andrew Morton authored
There seems to be no header file which declares system_running.
-
- 07 Oct, 2003 1 commit
-
-
Arnaldo Carvalho de Melo authored
-
- 21 Sep, 2003 1 commit
-
-
Andrew Morton authored
From: Erik Andersen <andersen@codepoet.org> When someone specifies "init=" to select an alternative binary to run instead of /sbin/init, argv[0] is not set correctly. This is a problem for programs such as busybox that multiplex applications based on the value of argv[0]. For example, even if you specify init=/bin/sh" on the kernel command line, busybox will still receive "/sbin/init" as argv[0] and will therefore run init rather than /bin/sh...
-
- 31 Aug, 2003 2 commits
-
-
Andrew Morton authored
From: "Pallipadi, Venkatesh" <venkatesh.pallipadi@intel.com> High Precision Event Timer (HPET) is next generation timer hardware and has various advantages over legacy 8254 (PIT) timer, like: - Associated registers are mapped to memory space. So, we no longer require in and out on legacy ioports - Memory map address is reported by ACPI (and are not hard-coded) - Each timer can be configured to generate separate interrupts, even sharing lines with PCI devices - HPET has a minimum period of 100 nanosecs and is not fixed. Giving a flexibility of increasing the resolution in future. - Most current implementations has 3 counters, but in future, we can have as many as 32 timers per block, and 8 HPET timer blocks (total 256 timers) - Can support 32bit and 64bit counting (Refer to http://www.intel.com/labs/platcomp/hpet/hpetspec.htm for complete specs) The patchset that follow adds support for High Precision Event Timer (HPET) based timer in kernel. This uses the HPET in LegacyReplacement mode (so that counter 0 will be tied to IRQ0, and counter 1 will be tied to IRQ 8). In this mode, HPET overrides PIT and RTC interrupt lines. The patch will enable HPET by default, on systems where ACPI tables reports this feature. The patch will have no impact on systems that do not support this feature. A major change from previous version is elimination of fixmap for HPET. Based on Andrew Morton's suggestion, we have a new hook in init/main.c for late_time_init(), at which time we can use ioremap, in place of fixmap. Impact on other archs: Calibrate_delay() (and hence loops_per_jiffy calculation) has moved down in main.c, from after time_init() to after kmem_cache_init(). 1/6 - hpet1.patch - main.c change to introduce late_time_init()
-
Andrew Morton authored
From: Andrea Arcangeli <andrea@suse.de> aka: "vmalloc allocations in ipc needs smp initialized (and vm must be allowed to schedule in 2.6)" In short if you change SEMMNI to 8192 the kernel will crash at boot, beause it tries to call vmalloc before the smp is initialized. The reason is that vmalloc calls into the pte alloc code, and the fast pte alloc is tried first, but that reads into the pte_quicklist, that requires the cpu_data to be initialized (and that happens in smp_init()). the patch is obviously safe, since no piece of kernel (especially the code in the check_bugs and smp_init paths ;) calls into the ipc subsystem. The reason this started to trigger wasn't really that we increased SEMMNI, but what happend is that some IPC data structure grown, and for some reason the corruption due the uninitalized pte_quicklist triggers only for smp boxes with less than 1G (not very common anymore ;). So it wasn't immediatly reproducible on all setups. 2.6 doesn't suffer from the same problem, simply because 2.6 isn't using the quicklist anymore, but I think it would be much more correct to make the same change in 2.6 too, since whatever cond_resched() in the vm paths (and they're definitely allowed to call it), will lead to a crash since the init task isn't initialized and the scheduler can't be invoked yet. (and 2.6 already has the bigger data structures that should trigger the vmalloc all the time on all setups)
-
- 17 Jul, 2003 1 commit
-
-
Adrian Bunk authored
This causes blk.h to print a warning and removes all uses of blk.h. I've tested the compilation in 2.6.0-test1 with a .config that tries to compile as many drivers as possible.
-
- 15 Jun, 2003 1 commit
-
-
Roman Zippel authored
Declare the parameter array as an array, rather than a single entry. This doesn't matter for code generation, but may be less likely to cause problems down the line, since we're telling gcc more about the real situation.
-
- 13 Jun, 2003 1 commit
-
-
Chris Wright authored
As discussed before, this allows for early initialization of security modules when compiled statically into the kernel. The standard do_initcalls is too late for complete coverage of all filesystems and threads, for example.
-
- 06 Jun, 2003 3 commits
-
-
Rusty Russell authored
Trivial patch: when these were introduced cpu.h didn't exist.
-
Andrew Morton authored
From: Matthew Dobson <colpatch@us.ibm.com> This resurrects the old /proc/sys/vm/free_pages functionality: the ability to tell page reclaim how much free memory to maintain. This may be needed for specialised networking applications, and it provides an interesting way to stress the kernel: set it very low so atomic allocations can easily fail. Also, a 16G ppc64 box currently cruises along at 1M free memory, which is surely too little to supporthigh-speed networking. We have not changed that setting here, but it is now possible to do so. The patch also reduces the amount of free memory which the VM will maintain in ZONE_HIGHMEM, as it is almost always wasted memory.
-
Andrew Morton authored
From: Rusty Russell <rusty@rustcorp.com.au> OK, this does the *minimum* required to support DEFINE_PER_CPU inside modules. If we decide to change kmalloc_percpu later, great, we can turf this out. Basically, overallocates the amount of per-cpu data at boot to at least PERCPU_ENOUGH_ROOM if CONFIG_MODULES=y (arch-specific by default 32k: I have only 7744 bytes of percpu data in my kernel here, so makes sense), and a special allocator in module.c dishes it out.
-
- 07 May, 2003 1 commit
-
-
Andrew Morton authored
From: Manfred Spraul <manfred@colorfullife.com> attached is the promised cleanup/bugfix patch for the slab bootstrap: - kmem_cache_init & kmem_cache_sizes_init merged into one function, called after mem_init(). It's impossible to bring slab to an operational state without working gfp, thus the early partial initialization is not necessary. - g_cpucache_up set to FULL at the end of kmem_cache_init instead of the module init call. This is a bugfix: slab was completely initialized, just the update of the state was missing. - some documentation for the bootstrap added. The minimal fix for the bug is a two-liner: move g_cpucache_up=FULL from cpucache_init to kmem_cache_sizes_init, but I want to get rid of kmem_cache_sizes_init, too.
-
- 20 Apr, 2003 1 commit
-
-
Christoph Hellwig authored
split the initrd stuff out of blk.h, it's only needed in the boot code and the ramdisk driver.
-
- 09 Apr, 2003 1 commit
-
-
Andrew Morton authored
Now that sparc64 is using gcc-3.x we can disallow gcc-2.91, etc. Documentation/Changes already says 2.95.3, which is working fine for me. With this change, we no longer require that per-cpu data definitions be initialised. That was a workaround for a bug in older gccs. So remove the build infrastructure which was checking for that. Also, mention that nfs-utils-1.0.3 is required. It isn't required yet, but will be once we enable larger dev_t: there is an interface for exportfs which passes dev_t's into the kernel which breaks with larger dev_t. That interface is old, deprecated and is not used in nfs-utils-1.0.3.
-
- 28 Mar, 2003 1 commit
-
-
Andrew Morton authored
The patch is designed to help locate where the kernel is dying during the startup sequence. - Boot parameter "initcall_debug" causes the kernel to print out the address of each initcall before calling it. The kallsyms tables do not cover __init sections, so printing the symbolic version of these symbols doesn't work. They need to be looked up in System.map. - Detect whether an initcall returns with interrupts disabled or with a locking imbalance. If it does, complain and then try to fix it up.
-
- 16 Mar, 2003 1 commit
-
-
Andrew Morton authored
Patch from Anders Gustafsson <andersg@0x63.nu> We're getting a division-by-zero in the writeback code during early rootfs population, because writeback has not yet been initialised. Fix that by performing an explicit initialisation rather than relying on initcall ordering.
-
- 12 Mar, 2003 1 commit
-
-
Linus Torvalds authored
set. A few versions of gcc-2.96 generate seriously incorrect code.
-
- 04 Mar, 2003 1 commit
-
-
Patrick Mochel authored
- Call driver_init() from init/main.c::do_basic_setup(). This ensures that all the driver model subsystems are initialized before any drivers or devices can be registered. It nearly frees up the core and postcore initcall levels, making them available for other kernel code to use freely.
-
- 16 Jan, 2003 1 commit
-
-
Martin J. Bligh authored
Patch from Michael Hohnbaum This adds a hook, sched_balance_exec(), to the exec code, to make it place the exec'ed task on the least loaded queue. We have less state to move at exec time than fork time, so this is the cheapest point to cross-node migrate. Experience in Dynix/PTX and testing on Linux has confirmed that this is the cheapest time to move tasks between nodes. It also macro-wraps changes to nr_running, to allow us to keep track of per-node nr_running as well. Again, no impact on non-NUMA machines.
-
- 05 Jan, 2003 3 commits
-
-
Geert Uytterhoeven authored
Remove unused prototype for init_modules()
-
Rusty Russell authored
This patch combines the common exception table searching functionality for various architectures, to avoid unneccessary (and currently buggy) duplication, and so that the exception table list and lock can be kept private to module.c. The archs provide "struct exception_table" and "search_extable": the generic infrastructure drives the rest.
-
Andrew Morton authored
Patch from Bill Irwin. Prodding from me. The hashtables in kernel/pid.c are 128 kbytes, which is far too large for very small machines. So we dynamically size them and allocate them from bootmem. From 16 buckets on the very smallest machine up to 4096 buckets (effectively half the current size) with one gigabyte of memory or more. The patch also switches the hashing from a custom hash over to the more powerful hash_long().
-
- 30 Dec, 2002 1 commit
-
-
Andrew Morton authored
George Anzinger identified the following problem: when a secondary CPU is coming up, it calls printk() before it is "online". It calls the console drivers before its per-cpu storage has been prepared. And the vga console driver does a mod_timer(). This CPU's timers have not yet been initialised; it is not clear why this doesn't oops - George thinks it is because virtual address zero is still accessible at that time. I believe the right way to fix this is to change printk so that a not-online CPU will not call the console drivers. Because printk should always be callable. If the CPU is not online the message is buffered, so the next caller to printk who is online will actually display it. ia64 has been doing exactly this for ages, so we can remove the arch_consoles_callable() hook and just open-code the cpu_online() test in printk. That fixes things up for the secondary CPUs. But this change causes a problem for the boot CPU: it is being marked online very late in boot, so the printk buffer is being displayed much later than we would like. I believe that the solution to this is to mark the boot CPU online much earlier. So in this patch we call the new arch-provided function smp_prepare_boot_cpu() immediately after the boot CPU's per-cpu areas are set up. Its mandate is to (at least) mark the boot CPU "online". The change has been reviewed by davem and rth. No comments were received from the other arch maintainers.
-
- 22 Dec, 2002 1 commit
-
-
Rusty Russell authored
Restore the accidentally dropped code to handle "init=xxx"
-
- 15 Dec, 2002 2 commits
-
-
Rusty Russell authored
This patch is a rewrite of the insmod and boot parameter handling, to unify them. The new format is fairly simple: built on top of __module_param_call there are several helpers, eg "module_param(foo, int, 000)". The final argument is the permissions bits, for exposing parameters in sysfs (if non-zero) at a later stage.
-
Randy Dunlap authored
Moves console_loglevel & friends to an array, as sysctl expects.
-
- 06 Dec, 2002 1 commit
-
-
Martin Schwidefsky authored
Rewrite of the s390 channel subsystem driver for the new driver model The channel subsystem driver a.k.a s390 common I/O layer is the low level driver for most device drivers on s390 systems. The old code is largely unchanged from the initial linux-2.2 port and there is a lot of bitrot on it. In particular, concepts from the 2.5 driver model are implemented in a completely different and more complicated way here. This rewrite tries to get the driver ready for 2.6. The new interface is not compatible to the old one but should be rather stable now unless someone finds major flaws. The 's390dyn' and 'chandev' interfaces have been removed entirely (yippii!) and are replaced by hotplug and sysfs interfaces. Authors: Arnd Bergmann <arndb@de.ibm.com>, Cornelia Huck <cohuck@de.ibm.com>, Martin Schwidefsky <schwidefsky@de.ibm.com>
-
- 18 Nov, 2002 1 commit
-
-
Richard Henderson authored
-