aboutsummaryrefslogtreecommitdiffstats
path: root/arch
Commit message (Collapse)AuthorAgeFilesLines
* ppc: Export __handle_mm_fault for MOLLinus Torvalds2005-08-061-1/+1
| | | | | | | | | | When we did the handle_mm_fault cleanup and get_user_page() race fixes, handle_mm_fault turned into an inline function that called the real __handle_mm_fault() code. The export needed for MOL on ppc wasn't updated to match the new world order, though. Turn it into a GPL export while at it, since this is all about internal interfaces and MOL is GPL'd anwyay.
* [PATCH] Update in-kernel zlib routinesTim Yamin2005-08-051-1/+2
| | | | | | | | | | | | | These bugs have been fixed in the standard zlib for a while. See for example a) http://sources.redhat.com/ml/bug-gnu-utils/1999-06/msg00183.html b) http://bugs.gentoo.org/show_bug.cgi?id=94584 Signed-off-by: Tim Yamin <plasmaroo@gentoo.org> Signed-off-by: Tavis Ormandy <taviso@gentoo.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* [PATCH] fix voyager compile after machine_emergency_restart breakageJames Bottomley2005-08-051-0/+7
| | | | | | | | | | | | | | [PATCH] i386: Implement machine_emergency_reboot introduced this new function into arch/i386/reboot.c. However, subarchitectures are entitled to implement their own copies of reboot.c from which this new function is now missing. It looks like visws will also need a similar fixup Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* [PATCH] pci and yenta: pcibios_bus_to_resourceDominik Brodowski2005-08-044-0/+68
| | | | | | | | | | | | | | | In yenta_socket, we default to using the resource setting of the CardBus bridge. However, this is a PCI-bus-centric view of resources and thus needs to be converted to generic resources first. Therefore, add a call to pcibios_bus_to_resource() call in between. This function is a mere wrapper on x86 and friends, however on some others it already exists, is added in this patch (alpha, arm, ppc, ppc64) or still needs to be provided (parisc -- where is its pcibios_resource_to_bus() ?). Signed-off-by: Dominik Brodowski <linux@dominikbrodowski.net> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* [PATCH] PCI: restore BAR values after D3hot->D0 for devices that need itJohn W. Linville2005-08-041-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Some PCI devices (e.g. 3c905B, 3c556B) lose all configuration (including BARs) when transitioning from D3hot->D0. This leaves such a device in an inaccessible state. The patch below causes the BARs to be restored when enabling such a device, so that its driver will be able to access it. The patch also adds pci_restore_bars as a new global symbol, and adds a correpsonding EXPORT_SYMBOL_GPL for that. Some firmware (e.g. Thinkpad T21) leaves devices in D3hot after a (re)boot. Most drivers call pci_enable_device very early, so devices left in D3hot that lose configuration during the D3hot->D0 transition will be inaccessible to their drivers. Drivers could be modified to account for this, but it would be difficult to know which drivers need modification. This is especially true since often many devices are covered by the same driver. It likely would be necessary to replicate code across dozens of drivers. The patch below should trigger only when transitioning from D3hot->D0 (or at boot), and only for devices that have the "no soft reset" bit cleared in the PM control register. I believe it is safe to include this patch as part of the PCI infrastructure. The cleanest implementation of pci_restore_bars was to call pci_update_resource. Unfortunately, that does not currently exist for the sparc64 architecture. The patch below includes a null implemenation of pci_update_resource for sparc64. Some have expressed interest in making general use of the the pci_restore_bars function, so that has been exported to GPL licensed modules. Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* [PATCH] x86_64: fix 32-bit thread debuggingDaniel Jacobowitz2005-08-041-4/+4
| | | | | | | | | | | | | | The IA32 ptrace emulation currently returns the wrong registers for fs/gs; it's returning what x86_64 calls gs_base. We need regs.gsindex in order for GDB to correctly locate the TLS area. Without this patch, the 32-bit GDB testsuite bombs on a 64-bit kernel. With it, results look about like I'd expect, although there are still a handful of kernel-related failures (vsyscall related?). Signed-off-by: Daniel Jacobowitz <dan@codesourcery.com> Acked-by: Andi Kleen <ak@suse.de> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* [PATCH] remove special HPET_EMULATE_RTC config optionVenkatesh Pallipadi2005-08-041-1/+2
| | | | | | | | | | | | | | | | | | | We had a user whose apps weren't working correctly because his "rtc" wasn't working fully. For the sake of simplicity, it seems sensible to always enable HPET RTC emulation. Remove a special config option for HPET_EMULATE_RTC and make it directly depend on HPET_TIMER and RTC. This will avoid the hangs when EMULATE_RTC is not configured and when some userlevel script depends on RTC interrupt, as in: http://bugzilla.kernel.org/show_bug.cgi?id=4904 Signed-off-by: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* Merge master.kernel.org:/home/rmk/linux-2.6-armLinus Torvalds2005-08-042-1/+2
|\
| * [PATCH] ARM: 2844/1: Add maintainer for Jornada 720Michael Gernoth2005-08-041-0/+1
| | | | | | | | | | | | | | | | | | | | | | Patch from Michael Gernoth As discussed on the handhelds.org Jornada mailinglist, I take over maintainership of the currently unmaintained Jornada 720-port in the mainline kernel. Signed-off-by: Michael Gernoth <michael@gernoth.net> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
| * [PATCH] ARM: 2838/1: Fix arm oprofile backtrace warningRichard Purdie2005-08-041-1/+1
| | | | | | | | | | | | | | | | | | Patch from Richard Purdie Fix a typo causing a warning in the arm oprofile backtrace code. Signed-off-by: Richard Purdie <rpurdie@rpsys.net> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
* | [PATCH] ppc64: fix for kexec boot issuePaul Mackerras2005-08-044-21/+22
| | | | | | | | | | | | | | | | | | | | | | | | The kexec boot is not successful on some power machines since all CPUs are getting removed from global interrupt queue (GIQ) before kexec boot. Some systems always expect at least one CPU in GIQ. Hence, this patch will make sure that only secondary CPUs are removed from GIQ. Signed-off-by: Haren Myneni <hbabu@us.ibm.com> Signed-off-by: Paul Mackerras <paulus@samba.org> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* | [PATCH] ppc64: Fix UP kernel buildOlof Johansson2005-08-042-2/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | CONFIG_KEXEC breaks UP builds because of a misspelled smp_release_cpus(). Also, the function isn't defined unless built with CONFIG_SMP but it is needed if we are to go from a UP to SMP kernel. Enable it and document it. Thanks to Steven Winiecki for reporting this and to Milton for remembering how it's supposed to work and why. Signed-off-by: Olof Johansson <olof@lixom.net> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* | Merge master.kernel.org:/home/rmk/linux-2.6-armLinus Torvalds2005-08-041-3/+3
|\ \ | |/
| * [PATCH] ARM: Fix ARM fault handler for get_user_pages() fixes.Russell King2005-08-041-3/+3
| | | | | | | | | | | | | | | | The ARM fault handler is optimised to make the fast path, err, fast. The renumbering of the VM_FAULT_* codes broke this because numbers were used instead of the definitions. Fix this. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
* | It wasn't just x86-64 that had hardcoded VM_FAULT_xxx numbersLinus Torvalds2005-08-046-28/+25
| | | | | | | | Fix up arm26, cris, frv, m68k, parisc and sh64 too..
* | [PATCH] x86-64: use proper VM_FAULT_xxx macrosAlexander Nyberg2005-08-041-3/+3
|/ | | | | | | | x86_64 had hardcoded the VM_ numbers so it broke down when the numbers were changed. Signed-off-by: Alexander Nyberg <alexn@telia.com> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* [PATCH] ARM: 2835/1: Add UPF_SKIP_TEST to IXP4xx serial portsDeepak Saxena2005-08-033-4/+4
| | | | | | | | | | | Patch from Deepak Saxena This allows the serial driver autconf to work properly on all the IXP serial ports. W/o it we basically put the serial port in an unrecoverable state and lose console. Signed-off-by: Deepak Saxena <dsaxena@plexity.net> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
* [PATCH] ARM: 2841/1: Fix VFP +/-0 case for doubles additionCatalin Marinas2005-08-031-0/+3
| | | | | | | | | | | Patch from Catalin Marinas The IEEE 754 standard specifies that the result of (x - x), where x is a valid number, should be -0 if the rounding mode is towards minus infinity or +0 otherwise. Signed-off-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
* [PATCH] ARM: 2839/1: Remove XScale cache and TLB locking codeDeepak Saxena2005-08-031-136/+0
| | | | | | | | | | | Patch from Deepak Saxena The XScale locking code is not something that has been validated on 2.6 and needs to be replaced with a more generic API to use with other ARMs that support locking features. Signed-off-by: Deepak Saxena <dsaxena@plexity.net> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
* [PATCH] ARM: 2837/2: Re: ARM: Make NWFPE preempt safeRichard Purdie2005-08-0311-304/+304
| | | | | | | | | | | | | | Patch from Richard Purdie NWFPE used global variables which meant it wasn't safe for use with preemptive kernels. This patch removes them and communicates the information between functions in a preempt safe manner. Generation of some exceptions was broken and this has also been corrected. Tests with glibc's maths test suite show no change in the results before/after this patch. Signed-off-by: Richard Purdie <rpurdie@rpsys.net> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
* [PATCH] ARM: 2832/1: BAST - limit clock-rate for IIC busBen Dooks2005-08-031-1/+15
| | | | | | | | | | | | Patch from Ben Dooks The default clock rate does not specify a maximum, so the default of 400KHz is used. This rate is too fast for the PMU on the EB2410ITX, so we now specify platform data with a rate of around 100KHz. Signed-off-by: Ben Dooks <ben-linux@fluff.org> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
* [PATCH] Xmon bug fix for soft-resetHaren Myneni2005-08-021-0/+3
| | | | | | | | | | | | | | | | | | For soft reset during system hang, got an error "CPU did not take control" for some CPUs even though they responded to soft-reset (called SystemReset, die and called debugger - xmon). First these CPUs entered into xmon by IPI callback and then got a soft-reset exception and re-entered into xmon again. The first CPU which re-entered into xmon got the output lock and made into xmon successfully without unlocking. Hence, the next CPU(s) which re-entered into xmon try to acquire a lock (get_output_lock). Therefore, we can not view state of those CPU(s). [This is a simple, very low risk, obvious fix for an obvious bug, and should go into 2.6.13. -- paulus] Signed-off-by: Haren Myneni <hbabu@us.ibm.com> Signed-off-by: Paul Mackerras <paulus@samba.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* [PATCH] ppc64: POWER 4 fails to boot with NUMAMike Kravetz2005-08-011-1/+6
| | | | | | | | | | | | | | | | | If CONFIG_NUMA is set, some POWER 4 systems will fail to boot. This is because of special processing needed to handle invalid node IDs (0xffff) on POWER 4. My previous patch to handle memory 'holes' within nodes forgot to add this special case for POWER 4 in one place. In reality, I'm not sure that configuring the kernel for NUMA on POWER 4 makes much sense. Are there POWER 4 based systems with NUMA characteristics that are presented by the firmware? But, distros want one kernel for all systems so NUMA is on by default in their kernels. The patch handles those cases. Signed-off-by: Mike Kravetz <kravetz@us.ibm.com> Signed-off-by: Paul Mackerras <paulus@samba.org> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* [PATCH] transmeta: CONFIG_PROC_FS=n build fixAndrew Morton2005-08-011-0/+2
| | | | | | | Fix bug found by Grant Coady <lkml@dodo.com.au>'s autobuild setup. Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* [PATCH] m32r: Fix local-timer event handlingHirokazu Takata2005-08-011-9/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | There was a scheduling problem of the m32r SMP kernel; A process rarely stopped and gave no responding but the other process have been handled by the other CPU still lives, then if we did something in the other terminal or something like that, the stopped process came back to life and continued its operation... (ex. LMbench: lat_sig) In the m32r SMP kernel, a local-timer event is delivered by using an IPI(inter processor interrupts); LOCAL_TIMER_IPI. And a function smp_send_timer() is prepared to send the LOCAL_TIMER_IPI from the current CPU to the other CPUs. The funtion smp_send_timer() was placed and used in do_IRQ() in former times (before 2.6.10-rc3-mm1 kernel), however, it was unintentionally removed when arch/m32r/kernel/irq.c was modified to employ the generic hardirq framework (CONFIG_GENERIC_HARDIRQ) in my previous patch. [PATCH 2.6.10-rc3-mm1] m32r: Use generic hardirq framework http://www.ussg.iu.edu/hypermail/linux/kernel/0412.2/0358.html The following patch fixes the above problem. Signed-off-by: Hitoshi Yamamoto <hitoshiy@isl.melco.co.jp> Signed-off-by: Hirokazu Takata <takata@linux-m32r.org> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* [PATCH] s390: ioprio & inotify system calls.Martin Schwidefsky2005-08-012-0/+31
| | | | | | | | Add system calls for io priorities and inotify. Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* [PATCH] s390: kexec fixes and improvements.Heiko Carstens2005-08-015-5/+109
| | | | | | | | | | Disable pseudo page fault handling before starting the new kernel and try to use diag308 to reset the machine. Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* [PATCH] ppc32: add bamboo defconfigMatt Porter2005-08-011-0/+943
| | | | | | | | | Add Bamboo platform defconfig Signed-off-by: Wade Farnsworth <wfarnsworth@mvista.com> Signed-off-by: Matt Porter <mporter@kernel.crashing.org> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* [PATCH] ppc32: add bamboo platformMatt Porter2005-08-012-0/+563
| | | | | | | | | Add Bamboo platform support. This is an AMCC 440EP-based reference platform. Signed-off-by: Wade Farnsworth <wfarnsworth@mvista.com> Signed-off-by: Matt Porter <mporter@kernel.crashing.org> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* [PATCH] ppc32: add 440ep supportMatt Porter2005-08-0113-3/+380
| | | | | | | | | | Add PPC440EP core support. PPC440EP is a PPC440-based SoC with a classic PPC FPU and another set of peripherals. Signed-off-by: Wade Farnsworth <wfarnsworth@mvista.com> Signed-off-by: Matt Porter <mporter@kernel.crashing.org> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* [PATCH] ppc32: Mark boards that don't build as BROKENKumar Gala2005-08-011-0/+2
| | | | | | | | | | | Marked APUS and GEMINI as BROKEN since they do not build at the platform level. We have requested that the maintainers of these boards/platforms fix them by the time 2.6.15 is released or we plan on concerning them unmaintained and thus removing them. Signed-off-by: Kumar Gala <kumar.gala@freescale.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* [PATCH] ppc64: Fix CONFIG_ALTIVEC not setBenjamin Herrenschmidt2005-08-011-0/+2
| | | | | | | | | | | The code that sets the altivec capability of the CPU based on firmware informations can enable altivec when the kernel has CONFIG_ALTIVEC disabled. This results in "interesting" crashes. Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Cc: Paul Mackerras <paulus@samba.org> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* [PATCH] disable addres space randomization default on transmeta CPUsEric Lammerts2005-08-011-0/+4
| | | | | | | | | | | | We know that the randomisation slows down some workloads on Transmeta CPUs by quite large amounts. We think it's because the CPU needs to recode the same x86 instructions when they pop up at a different virtual address after a fork+exec. So disable randomization by default on those CPUs. Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* [PATCH] remove sys_set_zone_reclaim()Ingo Molnar2005-08-012-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This removes sys_set_zone_reclaim() for now. While i'm sure Martin is trying to solve a real problem, we must not hard-code an incomplete and insufficient approach into a syscall, because syscalls are pretty much for eternity. I am quite strongly convinced that this syscall must not hit v2.6.13 in its current form. Firstly, the syscall lacks basic syscall design: e.g. it allows the global setting of VM policy for unprivileged users. (!) [ Imagine an Oracle installation and a SAP installation on the same NUMA box fighting over the 'optimal' setting for this flag. What will they do? Will they try to set the flag to their own preferred value every second or so? ] Secondly, it was added based on a single datapoint from Martin: http://marc.theaimsgroup.com/?l=linux-mm&m=111763597218177&w=2 where Martin characterizes the numbers the following way: ' Run-to-run variability for "make -j" is huge, so these numbers aren't terribly useful except to see that with reclaim the benchmark still finishes in a reasonable amount of time. ' in other words: the fundamental problem has likely not been solved, only a tendential move into the right direction has been observed, and a handful of numbers were picked out of a set of hugely variable results, without showing the variability data. How much variance is there run-to-run? I'd really suggest to first walk the walk and see what's needed to get stable & predictable kernel compilation numbers on that NUMA box, before adding random syscalls to tune a particular aspect of the VM ... which approach might not even matter once the whole picture has been analyzed and understood! The third, most important point is that the syscall exposes VM tuning internals in a completely unstructured way. What sense does it make to have a _GLOBAL_ per-node setting for 'should we go to another node for reclaim'? If then it might make sense to do this per-app, via numalib or so. The change is minimalistic in that it doesnt remove the syscall and the underlying infrastructure changes, only the user-visible changes. We could perhaps add a CAP_SYS_ADMIN-only sysctl for this hack, a'ka /proc/sys/vm/swappiness, but even that looks quite counterproductive when the generic approach is that we are trying to reduce the number of external factors in the VM balance picture. Signed-off-by: Ingo Molnar <mingo@elte.hu> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* [PATCH] x86_64: avoid wasting IRQs patch updateNatalie.Protasevich@unisys.com2005-07-301-2/+15
| | | | | | | | | | | | | | The patch adds boundary check for the MAX_GSI_NUM. Same as the update for i386, the patch addresses a problem with ACPI SCI IRQ. The patch corrects the code such that SCI IRQ is skipped and duplicate entry is avoided. The VIA chipset uses 4-bit IRQ register for internal interrupt routing, and therefore cannot handle IRQ numbers assigned to its devices. The patch corrects this problem by allowing PCI IRQs below 16. Signed-off-by: Natalie Protasevich <Natalie.Protasevich@unisys.com> Acked-by: Andi Kleen <ak@muc.de> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* Merge master.kernel.org:/pub/scm/linux/kernel/git/lenb/to-linusLinus Torvalds2005-07-305-0/+16
|\
| * merge 2.6.13-rc4 with ACPI's to-linus treeLen Brown2005-07-3050-595/+878
| |\
| * \ /home/lenb/src/to-linus branch 'acpi-2.6.12'Len Brown2005-07-295-0/+16
| |\ \
| | * | [ACPI] suspend/resume ACPI PCI Interrupt LinksDavid Shaohua Li2005-07-294-0/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add reference count and disable ACPI PCI Interrupt Link when no device still uses it. Warn when drivers have not released Link at suspend time. http://bugzilla.kernel.org/show_bug.cgi?id=3469 Signed-off-by: David Shaohua Li <shaohua.li@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
| | * | [ACPI] Always set P-state on initializationDominik Brodowski2005-07-291-0/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Otherwise a platform that supports ACPI based cpufreq and boots up at lowest possible speed could stay there forever. This because the governor may request max speed, but the code doesn't update if there is no change in speed, and it assumed the initial state of max speed. http://bugzilla.kernel.org/show_bug.cgi?id=4634 Signed-off-by: Dominik Brodowski <linux@dominikbrodowski.net> Signed-off-by: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
* | | | [PATCH] x86_64: fix bug in csum_partial_copy_generic()Dave Peterson2005-07-301-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | I was observing reproducible crashes on the "movw %bx,(%rsi)" instruction below while a process in a recvfrom() system call was copying packet data to user space. The patch below fixes the exception table and causes the crash to no longer reproduce. Please apply. Acked-by: Andi Kleen <ak@muc.de> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* | | | [PATCH] ppc32: fix 44x early serial debug for configurations with more than ↵Eugene Surovegin2005-07-305-11/+37
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 512M of RAM Fix 44x early serial debugging for big RAM configurations (more than 512M). We cannot use default OpenBIOS virtual mapping, because it interferes with pinned TLB entry. While we are at it, move early UART mapping to TLB slot 0, so it can survive longer during boot process (slot 1 is used by the first ioremap call, effectively killing UART mapping if it occupies this slot). Also, change UART TLB entry size to 4K (256M is too much for a bunch of registers :). Squash some warnings on the way. Tested on Ebony and Ocotea with 1G of RAM. Thanks to Scott Coulter <scott.coulter@cyclone.com> for diagnosing this problem. Signed-off-by: Eugene Surovegin <ebs@ebshome.net> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* | | | [PATCH] ppc64: inotify syscallsRobert Love2005-07-301-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | inotify system call support for PPC64 [ I don't think we need sys32 compatibility versions--and if we do, I failed in life. ] Signed-off-by: Robert Love <rml@novell.com> Acked-by: Paul Mackerras <paulus@samba.org> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* | | | [PATCH] ppc32: inotify syscallsRobert Love2005-07-301-0/+3
| |_|/ |/| | | | | | | | | | | | | | | | | | | | | | | | | | Add inotify system call stubs to PPC32. Signed-off-by: Robert Love <rml@novell.com> Acked-by: Paul Mackerras <paulus@samba.org> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* | | [PATCH] s390: fix inline assembly in appldataGerald Schaefer2005-07-291-1/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | Fix inline assembly that gets miscompiled by gcc 4. Signed-off-by: Gerald Schaefer <geraldsc@de.ibm.com> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* | | [PATCH] s390: check for interrupt before waitingHeiko Carstens2005-07-292-0/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The patch that introduced waiting for interrupts after resetting the reader can cause the boot to fail because the system is waiting for an interrupt that will never arrive. Add code to check if an interrupt is supposed to arrive before waiting endlessly. Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* | | [PATCH] s390: default configurationMartin Schwidefsky2005-07-291-111/+142
| | | | | | | | | | | | | | | | | | | | | | | | Update default configuration of s390. Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* | | [PATCH] uml: fix vsyscall brokennessJeff Dike2005-07-291-1/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The #if/#ifdef cleanup exposed a bug in UML's ELF header processing. With this bug fixed, UML recognizes the vsyscall info coming from the host. On FC4, there is a vsyscall page low in the address space, which UML doesn't provide. This causes an infinite page fault loop and a hang on boot. This patch works around that by making this look like a no-vsyscall system. Signed-off-by: Jeff Dike <jdike@addtoit.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* | | [PATCH] x86: avoid wasting IRQs patch updateNatalie.Protasevich@unisys.com2005-07-291-1/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The patch addresses a problem with ACPI SCI interrupt entry, which gets re-used, and the IRQ is assigned to another unrelated device. The patch corrects the code such that SCI IRQ is skipped and duplicate entry is avoided. Second issue came up with VIA chipset, the problem was caused by original patch assigning IRQs starting 16 and up. The VIA chipset uses 4-bit IRQ register for internal interrupt routing, and therefore cannot handle IRQ numbers assigned to its devices. The patch corrects this problem by allowing PCI IRQs below 16. Signed-off by: Natalie Protasevich <Natalie.Protasevich@unisys.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* | | [PATCH] Fix sync_tsc hangEric W. Biederman2005-07-292-9/+75
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | sync_tsc was using smp_call_function to ask the boot processor to report it's tsc value. smp_call_function performs an IPI_send_allbutself which is a broadcast ipi. There is a window during processor startup during which the target cpu has started and before it has initialized it's interrupt vectors so it can properly process an interrupt. Receveing an interrupt during that window will triple fault the cpu and do other nasty things. Why cli does not protect us from that is beyond me. The simple fix is to match ia64 and provide a smp_call_function_single. Which avoids the broadcast and is more efficient. This certainly fixes the problem of getting stuck on boot which was very easy to trigger on my SMP Hyperthreaded Xeon, and I think it fixes it for the right reasons. Minor changes by AK Signed-off-by: Eric W. Biederman <ebiederm@xmission.com> Signed-off-by: Andi Kleen <ak@suse.de> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>