- 19 Nov, 2004 40 commits
-
-
Geert Uytterhoeven authored
M68k I/O: Move HP300 I/O macros close to other I/O macros again (after merge error in 2.6.10-rc2) Signed-off-by:
Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by:
Andrew Morton <akpm@osdl.org> Signed-off-by:
Linus Torvalds <torvalds@osdl.org>
-
Geert Uytterhoeven authored
fm2fb: Update Steffen A. Mork's email address Signed-off-by:
Steffen A. Mork <linux-dev@morknet.de> Signed-off-by:
-
Geert Uytterhoeven authored
Sun-3: Fix link error (we forgot to update vmlinux-sun3.lds during last update of vmlinux-std.lds) Signed-off-by:
-
Geert Uytterhoeven authored
68851 MMU: Fix harmless (CPU_68020 == MMU_68851 anyway) typo in the MMU configuration code. Signed-off-by:
-
Geert Uytterhoeven authored
M68k: Add 3 missing syscalls (up to 2.6.10-rc1) Signed-off-by:
-
Geert Uytterhoeven authored
M68k: Update defconfigs Signed-off-by:
-
Hirokazu Takata authored
cleanups for arch/m32r/kernel/io*.c. - Fix ugly indentation. - Change __inline__ to inline. - Remove RCS ID strings. Signed-off-by:
Hirokazu Takata <takata@linux-m32r.org> Signed-off-by:
-
Hirokazu Takata authored
Here is a patch to update arch/m32r/Makefile for m32r. - Make zImage a default build target - Add zImage to targets marked with [*].
-
Hirokazu Takata authored
This patch fixes a hanging up at boot time of 2.6.10-rc2 m32r UP kernel. It was due to a lack of update_process_times() in time.c. Such a boot hang was caused only in UP systems, because update_process_times() had been executed correctly in smp_local_timer_interrupt() of arch/m32r/kernel/smp.c for SMP. arch/m32r/kernel/time.c: - UP: Fix do_timer_interrupt() to use update_process_times(). - UP: Move profile_tick() into do_timer_interrupt(). - Change __inline__ to inline. Signed-off-by:
-
Hirokazu Takata authored
This patch updates Kconfig and add Kconfig.debug for m32r. - arch/m32r/Kconfig: Move "Kernel hacking" menu to Kconfig.debug. - arch/m32r/Kconfig.debug: Newly added. - lib/Kconfig.debug: Add m32r arch. Signed-off-by:
-
Christoph Lameter authored
- reduce processing in timer interrupt through the use of a tasklet - fix various race conditions - use the correct interrupt vector for the SN2 RTC Signed-off-by:
Dimitri Sivanich <sivanich@sgi.com> Signed-off-by:
Christoph Lameter <clameter@sgi.com> Signed-off-by:
-
Tom Rini authored
Port of the i386 patch of the same name. Signed-off-by:
Tom Rini <trini@kernel.crashing.org> Signed-off-by:
-
Olof Johansson authored
Documentation/DMA-mapping.txt says that pci_alloc_consistent() needs to return a mapping that is aligned by the closest larger order of two as the allocation. We're currently breaking this with our iommu code. To fix this, add align_order arguments to the relevant functions and pass it down. Specifying align_order of 0 gives same behaviour as previous. Signed-off-by:
Olof Johansson <olof@austin.ibm.com> Signed-off-by:
-
Paul Mackerras authored
This patch moves the emulate_step function, which is used in xmon's single-stepping code, out of xmon.c and into arch/ppc64/lib/sstep.c, so that kprobes can use it too. Signed-off-by:
Paul Mackerras <paulus@samba.org> Signed-off-by:
-
Stephen Rothwell authored
This patch just makes sure that we do not dereference a viodasd gendisk pointer after it has been freed. Signed-off-by:
Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by:
-
Andrew Morton authored
With newer gcc's: include/asm/thread_info.h:95: warning: unused variable `current_stack_pointer' Signed-off-by:
-
Adrian Bunk authored
drivers/scsi/osst.o(.bss+0x0): multiple definition of `ST_partstat' drivers/scsi/st.o(.bss+0x0): first defined here Signed-off-by:
Adrian Bunk <bunk@fs.tum.de> Cc: James Bottomley <James.Bottomley@steeleye.com> Signed-off-by:
-
Tom Rini authored
<alebas@televes.com> found that CONFIG_8260 and CONFIG_BLK_DEV_INITRD was broken as arch/ppc/syslib/m8260_setup.c was missing <linux/root_dev.h>. Signed-off-by:
-
Adrian Bunk authored
drivers/isdn/divert/divert_init.c:25: error: conflicting types for 'printk' Signed-off-by:
-
Hugh Dickins authored
With Andrea Arcangeli <andrea@novell.com> Fix a hang which occurs when mlock() encounters a mapping of /dev/mem. These have VM_IO set. follow_page() keeps returning zero (not a valid pfn) and handle_mm_fault() keeps on returning VM_FAULT_MINOR (there's a pte there), so get_user_pages() locks up. The patch changes get_user_pages() to just bale out when it hits a VM_IO region. make_pages_present() is taught to ignore the resulting -EFAULT. We still have two bugs: a) If a process has a VM_IO vma, get_user_pages() will bale early, without having considered the vmas at higher virtual addresses. As do_mlock() also walks the vma list this bug is fairly benign, but get_user_pages() is doing the wrong thing there. b) The `len' argument to get_user_pages should be long, not int. We presently have a 16TB limit on 64-bit. Signed-off-by:
Hugh Dickins <hugh@veritas.com> Signed-off-by:
-
Neil Brown authored
We replace 'size' by 'start'. 'start' means exactly the same as 'curr_offset - size', and the equivalence of the new code can be tested based on this. The difference is that 'start' will never be negative and so can fit in a 'sector_t' while 'size' could be negative. Also make curr_offset sector_t, as it should have been. Signed-off-by:
Neil Brown <neilb@cse.unsw.edu.au> Signed-off-by:
-
Andrew Morton authored
The token-based thrashing control patches introduced a problem: when a task which doesn't hold the token tries to run direct-reclaim, that task is told that pages which belong to the token-holding mm are referenced, even though they are not. This means that it is possible for a huge number of a non-token-holding mm's pages to be scanned to no effect. Eventually, we give up and go and oom-kill something. So the patch arranges for the thrashing control logic to be defeated if the caller has reached the highest level of scanning priority. Signed-off-by:
-
Giuseppe Sacco authored
The current gbefb.c source cannot be compiled as module because of a small typo where "option" was written instead of "options" in two places. Signed-off-by:
-
Bjorn Helgaas authored
This changes the HCDP/PCDP support to use the early uart console rather than using early_serial_setup(). As a consequence, ia64 serial device names will now stay constant regardless of firmware console settings. (A serial device selected as an EFI console device on HP ia64 boxes used to automatically become ttyS0.) This also removes the ia64 early-boot kludge of assuming legacy COM ports at 0x3f8 and 0x2f8. For boxes that have legacy ports but no HCDP, "console=ttyS0" will still work, but the console won't start working until after the serial driver initializes and discovers the devices. WARNING: If you have an HP machine and you're using the MP serial console port (the connector labelled "console" on the 3-headed cable), this patch will break your console! HOW TO FIX IT: 1) The console device will change from /dev/ttyS0 to /dev/ttyS1, ttyS2, or ttyS3, so: 1a) Edit /etc/inittab to add a getty entry for /dev/ttyS1 (rx4640, rx5670, rx7620, rx8620, Superdome), /dev/ttyS2 (rx1600), or /dev/ttyS3 (rx2600). 1b) Edit /etc/securetty to add ttyS1, ttyS2, or ttyS3. 1c) Leave the existing ttyS0 entries in /etc/inittab and /etc/securetty so you can still boot old kernels. 2) Edit /etc/elilo.conf to remove any "console=" arguments (see [1]). 3) Run elilo to install the bootloader with new configuration. 4) Reboot and use the EFI boot option maintenance menu to select exactly one device for console output, input, and standard error. Then do a cold reset so the changes take effect. For the MP console, be careful to select the device with "Acpi(HWP0002,700)/Pci(...)/Uart" in the path (see [2]). DETAILS: - Prior to this patch, serial device names depended on the HCDP, which in turn depends on EFI console settings. After this patch, the naming always stays the same, regardless of firmware settings. For example, an rx1600 with a single built-in serial port plus an MP has these ports: Old Old MMIO (EFI console (EFI console address on builtin) on MP port) New ========== ========== ========== ====== builtin 0xff5e0000 ttyS0 ttyS1 ttyS0 MP UPS 0xf8031000 ttyS1 ttyS2 ttyS1 MP Console 0xf8030000 ttyS2 ttyS0 ttyS2 MP 2 0xf8030010 ttyS3 ttyS3 ttyS3 MP 3 0xf8030038 ttyS4 ttyS4 ttyS4 - If you want to have multiple devices in the EFI console path, you can, but Linux won't be able to deduce which console to use, so it will default to using VGA. You can use "console=hcdp" (the UART device from the EFI path) or "console=ttyS<n>" to select the device directly. TROUBLESHOOTING: - No kernel output after "Uncompressing Linux... done": -> You're using an MP port as the console and specified "console=ttyS0". This port is now named something else. Remove the "console=" option. -> Multiple UARTs selected as EFI console devices, and you're looking at the wrong one. Make sure only one UART is selected (use the EFI Boot Manager "Boot option maintenance" menu). -> You're physically connected to the MP port but have a non-MP UART selected as EFI console device. Either move the console cable to the non-MP UART, or change the EFI console path to the MP UART (the MP UART is the one with "Acpi(HWP0002,700)/Pci(...)/Uart" in it.) - Long pause (60+ seconds) between "Uncompressing Linux... done" and start of kernel output: -> No early console, probably because you used "console=ttyS<n>". Remove the "console=" option. - Kernel and init script output works fine, but no "login:" prompt: -> Add getty entry to /etc/inittab for console tty. Use the table in (1a) above or look for the "Adding console on ttyS<n>" message that tells you which device is the console. - "login:" prompt, but can't login as root: -> Add entry to /etc/securetty for console tty. [1] When the EFI console path contains exactly one device (either serial or VGA), 2.6.6 and newer kernels default to that device automatically. So if you remove "console=" arguments, you can use the same elilo configuration to boot any 2.6.6 or newer kernel with or without this patch. If you need to boot kernels older than 2.6.6 (including RHEL3 and SLES9), keep an 'append="console=ttyS0"' line in those elilo.conf stanzas. Non-HP machines will still need "console=" for serial consoles because they don't supply the HCDP table. [2] The HP management card (MP) causes confusion because it is always active as an EFI console, even if it doesn't appear in the EFI console path. If your console path is set to a non-MP UART, and you happen to be attached to the MP UART, everything works in EFI, but the kernel will think the non-MP UART is the console, so you won't see any kernel output. Signed-off-by:Bjorn Helgaas <bjorn.helgaas@hp.com> Signed-off-by:
-
Bjorn Helgaas authored
This adds an early polled-mode "uart" console driver, based on Andi Kleen's early_printk work. The difference is that this locates the UART device directly by its MMIO or I/O port address, so we don't have to make assumptions about how ttyS devices will be named. After the normal serial driver starts, we try to locate the matching ttyS device and start a console there. Sample usage: console=uart,io,0x3f8 console=uart,mmio,0xff5e0000,115200n8 If the baud rate isn't specified, we peek at the UART to figure it out. Signed-off-by: -
Randy Dunlap authored
Fixes oops (reference to cdrom_root_table->child->) when CONFIG_SYSCTL=y and CONFIG_PROC_FS=n. Signed-off-by:
Randy Dunlap <rddunlap@osdl.org> Signed-off-by:
-
Bjorn Helgaas authored
Fix ia64 build error: implicit declaration of function `flush_tlb_page' Signed-off-by:
-
Prasanna S. Panchamukhi authored
This patch fixes the problem reported by Stas Sergeev, that kprobes steals the virtual-8086 exceptions. This fix modifies kprobe_handler() to return 0 when in virtual-8086 mode. Signed-off-by:
-
Andrea Arcangeli authored
mempolicy.c code will return the wrong policy in some cases. Signed-off-by:
Andrea Arcangeli <andrea@novell.com> Signed-off-by:
-
Andrea Arcangeli authored
With the inline symlink shmem_inode_info structure is overwritten with data until vfs_inode, and that caused the ->policy to be a corrupted pointer during unlink. It wasn't immediatly easy to see what was going on due the random mm corruption that generated a weird oops, it looked more like a race condition on freed memory at first. There's simply no need to set a policy for inodes, since the idx is always zero. All we have to do is to initialize the data structure (the semaphore may need to run during the page allocation for the non-inline symlink) but we don't need to allocate the rb nodes. This way we don't need to call mpol_free during the destroy_inode (not doable at all if the policy rbtree is corrupt by the inline symlink ;). An equivalent version of this patch based on a 2.6.5 tree with additional numa features on top of this (i.e. interleaved by default, and that's prompted me to add a comment in the LNK init path), works fine in a numa simulation on my laptop (untested on the bare hardware). Signed-off-by:
-
Hirokazu Takata authored
The modification of "Changes for arch/m32r/mm/fault.c@1.3" was prepared for enforce-a-gap-between-heap-and-stack.patch(*) of -mm tree, but it has not been merged into mainline. (*) "heap-stack-gap for 2.6" (Sep. 25, 2004) http://www.uwsg.iu.edu/hypermail/linux/kernel/0409.3/0435.html So, this patch is for withdrawing the previous arch/m32r/mm/fault.c. Signed-off-by: -
William Lee Irwin III authored
Stomp a couple of warnings which several people have tried to fix. Signed-off-by:
-
Russell King authored
The following patch fixes these build errors on machines with CONFIG_PCI=n: drivers/parport/parport_pc.c:3199: error: `parport_init_mode' undeclared (first use in this function) drivers/parport/parport_pc.c:3199: error: (Each undeclared identifier is reported only once drivers/parport/parport_pc.c:3199: error: for each function it appears in.) Signed-off-by:
Russell King <rmk@arm.linux.org.uk> Signed-off-by:
-
Stephen Rothwell authored
It appears that the PURR emulation patch was the victim of the renaming of a structure element. The current BK kernel will not build for iSeries without this patch. Signed-off-by:
-
Ingo Molnar authored
PREEMPT_RT on SMP systems triggered weird (very high) load average values rather easily, which turned out to be a mainline kernel ->nr_uninterruptible handling bug in try_to_wake_up(). the following code: if (old_state == TASK_UNINTERRUPTIBLE) { old_rq->nr_uninterruptible--; potentially executes with old_rq potentially being != rq, and hence updating ->nr_uninterruptible without the lock held. Given a sufficiently concurrent preemption workload the count can get out of whack and updates might get lost, permanently skewing the global count. Nothing except the load-average uses nr_uninterruptible() so this condition can go unnoticed quite easily. the fix is to update ->nr_uninterruptible always on the runqueue where the task currently is. (this is also a tiny performance plus for try_to_wake_up() as a stackslot gets freed up.) while fixing this bug i found three other ->nr_uninterruptible related bugs: - the update should be moved from deactivate_task() into schedule(), beacause e.g. setscheduler() does deactivate_task()+activate_task(), which in turn may result in a -1 counter-skew if setscheduler() is done on a task asynchronously, which task is still on the runqueue but has already set ->state to TASK_UNINTERRUPTIBLE. sys_sched_setscheduler() is used rarely, but the bug is real. (The fix is also a small performance enhancement.) The rules for ->nr_uninterruptible updating are the following: it gets increased by schedule() only, when a task is moved off the runqueue and it has a state of TASK_UNINTERRUPTIBLE. It is decreased by try_to_wake_up(), by the first wakeup that materially changes the state from TASK_UNINTERRUPTIBLE back to TASK_RUNNING, and moves the task to the runqueue. - on CPU-hotplug down we might zap a CPU that has a nonzero counter. Due to the fuzzy nature of the global counter a CPU might hold a nonzero ->nr_uninterruptible count even if it has no tasks anymore. The solution is to 'migrate' the counter to another runqueue. - we should not return negative counter values from the nr_uninterruptible() function, since it accesses them without taking the runqueue locks, so the total sum might be slightly above or slightly below the real count. I tested the attached patch on x86 SMP and it solves the load-average problem. (I have tested CPU_HOTPLUG compilation but not functionality.) I think this is a must-have for 2.6.10, because there are apps that go berzerk if load-average is too high (e.g. sendmail). Signed-off-by:Ingo Molnar <mingo@elte.hu> Signed-off-by:
-
bk://kernel.bkbits.net/gregkh/linux/i2c-2.6Linus Torvalds authored
into ppc970.osdl.org:/home/torvalds/v2.6/linux
-
bk://kernel.bkbits.net/gregkh/linux/pci-2.6Linus Torvalds authored
into ppc970.osdl.org:/home/torvalds/v2.6/linux
-
bk://kernel.bkbits.net/gregkh/linux/usb-2.6Linus Torvalds authored
into ppc970.osdl.org:/home/torvalds/v2.6/linux
-
Jeff Mahoney authored
If security_load_policy() fails on the first try, the cache is never cleaned up. When the policy is fixed and a reload is attempted, the old cache will still exist, causing a BUG() in kmem_cache_create(). This patch adds a destroy operation to clean up the cache on failure. Signed-off-by:
Jeff Mahoney <jeffm@novell.com> Signed-off-by:
-
bk://kernel.bkbits.net/gregkh/linux/driver-2.6Linus Torvalds authored
into ppc970.osdl.org:/home/torvalds/v2.6/linux
-
