- 19 8月, 2007 2 次提交
-
-
由 Andi Kleen 提交于
This should fix an oops with PCMCIA PATA devices http://bugzilla.kernel.org/show_bug.cgi?id=8424 This is not a full fix for the problem, but probably still the right thing to do. [ I'm almost certain it's *not* the right thing to do, but it avoids an oops, and I want comments from others on what the right thing would actually be.. I suspect we should just remove the use of dma_mask entirely in this function, and just use coherent_dma_mask. - Linus ] Signed-off-by: NAndi Kleen <ak@suse.de> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
由 Jan Engelhardt 提交于
Signed-off-by: NJan Engelhardt <jengelh@gmx.de> Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de> (edited MACINTOSH_DRIVERS per Geert Uytterhoeven's remark) Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
- 18 8月, 2007 2 次提交
-
-
由 Peter Chubb 提交于
When using Ski to debug early startup, it's a bit of a pain not to have printk. This patch enables the simulated console very early. It may be worth conditionalising on the command line... but this is enough for now. Signed-off-by: NPeter Chubb <peterc@gelato.unsw.edu.au> Signed-off-by: NTony Luck <tony.luck@intel.com>
-
由 Shaohua Li 提交于
The "ri" field in the processor status register only has defined values of 0, 1, 2. Do not let ptrace set this to 3. As with other reserved fields in registers we silently discard the value. Signed-off-by: NShaohua Li <shaohua.li@intel.com> Signed-off-by: NTony Luck <tony.luck@intel.com>
-
- 17 8月, 2007 3 次提交
-
-
由 Ilpo Järvinen 提交于
A similar fix to netfilter from Eric Dumazet inspired me to look around a bit by using some grep/sed stuff as looking for this kind of bugs seemed easy to automate. This is one of them I found where it looks like this semicolon is not valid. Signed-off-by: NIlpo Järvinen <ilpo.jarvinen@helsinki.fi> Acked-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: NPaul Mackerras <paulus@samba.org>
-
由 Andrew Burgess 提交于
There is a bug in the ia64_do_page_fault code that can cause a failure to grow the register backing store, or any mapping that is marked as VM_GROWSUP if the mapping is the highest mapped area of memory. When the address accessed is below the first mapping the previous mapping is returned as NULL, and this case is handled. However, when the address accessed is above the highest mapping the vma returned is NULL, this case is not handled correctly, and it fails to spot that this access might require an existing mapping to grow upwards. Signed-off-by: NAndrew Burgess <andrew@transitive.com> Signed-off-by: NTony Luck <tony.luck@intel.com>
-
由 Andy Whitcroft 提交于
It seems we have gained an extraneous trailing ';' on one of the wait loops in scif_sercon_putc(). Although this is completely benign as the apparent payload is also the empty statement, it invites error in the future. Clean it up now. Signed-off-by: NAndy Whitcroft <apw@shadowen.org> Signed-off-by: NPaul Mundt <lethal@linux-sh.org>
-
- 16 8月, 2007 5 次提交
-
-
由 David S. Miller 提交于
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 David S. Miller 提交于
This register is not a part of the sun4v architecture. Niagara 1 and 2 happened to leave it around. Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 David S. Miller 提交于
The bzero/memset implementation stays the same as Niagara-1. Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 David S. Miller 提交于
Like the OF device tree, it's useful to let userland get at the machine description so it can pretty print the graph etc. The implementation is a simple MISC device with a read method. Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Alex Williamson 提交于
The core cpufreq code doesn't appear to understand returning -EAGAIN for the get() function of the cpufreq_driver. If PAL_GET_PSTATE returns -1, such as when running on Xen, scaling_cur_freq is happy to return 4294967285 kHz (ie. (unsigned)-11). The other drivers appear to return 0 for a failure, and doing so gives me the max frequency from scaling_cur_frequency and "<unknown>" from cpuinfo_cur_frequency. I believe that's the desired behavior. Signed-off-by: NAlex Williamson <alex.williamson@hp.com> Acked-by: NVenkatesh Pallipadi <venkatesh.pallipadi@intel.com> Signed-off-by: NTony Luck <tony.luck@intel.com>
-
- 15 8月, 2007 12 次提交
-
-
由 Haavard Skinnemoen 提交于
The NGW100 has a board controller which is hooked up to the TWI lines on AP7000. Since the TWI driver isn't in mainline, use the i2c-gpio driver in the mean time. Signed-off-by: NHaavard Skinnemoen <hskinnemoen@atmel.com>
-
由 David Brownell 提交于
Add GPIO led support: J2 to either block of LEDs on the STK1000. This uses the new LEDS_GPIO driver, and sets up a heartbeat trigger by default ... either bright (!!) amber, or a more interesting purple. Signed-off-by: NDavid Brownell <dbrownell@users.sourceforge.net> Signed-off-by: NHaavard Skinnemoen <hskinnemoen@atmel.com>
-
由 Geert Uytterhoeven 提交于
Fix probing of PS3 storage devices: in the success case, we should set `error' to zero, not `result'. Without this patch no storage devices are found. Signed-off-by: NGeert Uytterhoeven <Geert.Uytterhoeven@sonycom.com> Signed-off-by: NPaul Mackerras <paulus@samba.org>
-
由 Roland McGrath 提交于
ppc64 does the unusual thing of using #include on a compiler-generated assembly file (lparmap.s) from an assembly source file (head_64.S). This runs afoul of my recent patch to pass -gdwarf2 to the assembler under CONFIG_DEBUG_INFO. This patch avoids the problem by disabling DWARF generation (-g0) when producing lparmap.s. Signed-off-by: NRoland McGrath <roland@redhat.com> Signed-off-by: NPaul Mackerras <paulus@samba.org>
-
由 David Gibson 提交于
The 440 family of processors don't have a tlbie instruction. So, we implement TLB invalidates by explicitly searching the TLB with tlbsx., then clobbering the relevant entry, if any. Unfortunately the PID for the search needs to be stored in the MMUCR register, which is also used by the TLB miss handler. Interrupts were enabled in _tlbie(), so an interrupt between loading the MMUCR and the tlbsx could cause incorrect search results, and thus a failure to invalide TLB entries which needed to be invalidated. This fixes the problem in both arch/ppc and arch/powerpc by inhibiting interrupts (even critical and debug interrupts) across the relevant instructions. Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au> Acked-by: NJosh Boyer <jwboyer@linux.vnet.ibm.com> Signed-off-by: NPaul Mackerras <paulus@samba.org>
-
由 Becky Bruce 提交于
AFAICT, nobody is using ft_ordered(), and it causes a build warning to be generated. This patch cleans that up by removing the function and the commented-out code that calls it. Signed-off-by: NBecky Bruce <becky.bruce@freescale.com> Acked-by: NDavid Gibson <david@gibson.dropbear.id.au> Signed-off-by: NPaul Mackerras <paulus@samba.org>
-
由 Jeremy Kerr 提交于
At present, spu_create with an invalid neighbo(u)r will return -ENOSYS, not -EBADF, but only when spufs.o is built as a module. This change adds the appropriate errno, making the behaviour the same as the built-in case. Signed-off-by: NJeremy Kerr <jk@ozlabs.org> Acked-by: NArnd Bergmann <arnd.bergmann@de.ibm.com> Signed-off-by: NPaul Mackerras <paulus@samba.org>
-
由 Mark Fortescue 提交于
In sun4c_init_clean_mmu(), aligning 'kernel_end' using SUN4C_REAL_PGDIR_ALIGN() is unnecessary since the caller does this already. In sun4c_paging_init(), 4 page sizes of "fluff" were added to the address of &end. This was necessary a long time ago when sparc32 would allocate some early data structures by carving out memory chunks after &end but that no longer occurs. Signed-off-by: NMark Fortescue <mark@mtfhpc.demon.co.uk> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Mark Fortescue 提交于
This mirrors sparc64 commit 715a0ecc sparc_ramdisk_image should always be decremented by KERNBASE. Signed-off-by: NMark Fortescue <mark@mtfhpc.demon.co.uk> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 H. Peter Anvin 提交于
When filling in the MBR signature array, the setup code failed to advance boot_params.edd_mbr_sig_buf_entries, which resulted in the valid data being ignored. Signed-off-by: NH. Peter Anvin <hpa@zytor.com>
-
由 H. Peter Anvin 提交于
At least one machine has been identified in the field which advertises EDD for all drives but locks up if one attempts an extended read from a non-primary drive. The MBR is always at CHS 0-0-1, so there is no reason to use an extended read, other than the possibility that the BIOS cannot handle it. Although this might break as many machines as it fixes (a small number either way), the current state is a regression but the reverse is not. Therefore revert to the previous state of not using extended read. Quite probably the Right Thing to do is to read using plain (CHS) read and extended read on failure, but that change would definitely have to go through -mm first. Signed-off-by: NH. Peter Anvin <hpa@zytor.com>
-
由 H. Peter Anvin 提交于
The current display page is an 8-bit number, even though struct screen_info gives it a 16-bit number. The number is returned in %bh, so it needs to be >> 8 before storing. Special thanks to Jeff Chua for detailed bug reporting. Signed-off-by: NH. Peter Anvin <hpa@zytor.com>
-
- 14 8月, 2007 9 次提交
-
-
由 Mike Habeck 提交于
If the interrupt has been disabled, don't call the force_interrupt provider. Doing so can result in an infinite runaway interrupt loop. Signed-off-by: NMike Habeck <habeck@sgi.com> Signed-off-by: NTony Luck <tony.luck@intel.com>
-
由 Christoph Lameter 提交于
The slab allocator was changed in 2.6.23 to default to SLUB. However, the config files in arch/ia64/configs still use SLAB. Switch them to SLUB. Added same change to arch/ia64/defconfig ... Tony Signed-off-by: NChristoph Lameter <clameter@sgi.com> Signed-off-by: NTony Luck <tony.luck@intel.com>
-
由 David Mosberger-Tang 提交于
Explicitly put the unwind section into its own program-header. This used to be unnecessary (probably because binutils did it for us), but with current binutils (e.g., v2.17.50.20070804) we won't get the PT_IA_64_UNWIND header without this patch which will break unwinding in a debugger and simulators such as Ski. Signed-off-by: NDavid Mosberger-Tang <dmosberger@gmail.com> Signed-off-by: NTony Luck <tony.luck@intel.com>
-
由 David Mosberger-Tang 提交于
Add NOTES to linker script such that the kernel can be built with recent versions of binutils. Without this patch, final link fails with this error: ld: .tmp_vmlinux1: section `.text' can't be allocated in segment 0 ld: final link failed: Bad value This error is due to the fact that the --build-id option is used with newer linkers to include a .notes section on the kernel, but without the NOTES macro, that section won't be included in the kernel which then leads to the above error message. Signed-off-by: NDavid Mosberger-Tang <dmosberger@gmail.com> Signed-off-by: NTony Luck <tony.luck@intel.com>
-
由 David Mosberger-Tang 提交于
Add a dummy nop at the end of _start() to maintain the invariant that the return-pointer (rp) always point to the calling function. This makes unwinding stop at the last frame, as it should. Signed-off-by: NDavid Mosberger-Tang <dmosberger@gmail.com> Signed-off-by: NTony Luck <tony.luck@intel.com>
-
由 Russ Anderson 提交于
Use local_vector_to_irq() instead of looping through all NR_IRQS. This avoids registering the CPE handler on multiple irqs. Only register if the irq is valid. If no valid irq is found, print an error message and set up polling. Signed-off-by: NRuss Anderson <rja@sgi.com> Signed-off-by: NTony Luck <tony.luck@intel.com>
-
由 Satyam Sharma 提交于
arch/ia64/Kconfig failed to include kernel/Kconfig.preempt that meant it did not support PREEMPT_VOLUNTARY and PREEMPT_BKL (inadvertently). This was recently noticed when the newly-added PREEMPT_NOTIFIERS in Kconfig.preempt that was "select"ed from drivers/kvm/Kconfig (therefore) started giving bogus warnings ('select' used by config symbol 'KVM' refers to undefined symbol 'PREEMPT_NOTIFIERS') on ia64 builds. So let's remove the open-coded definition of CONFIG_PREEMPT in arch/ia64/Kconfig and replace it with just including Kconfig.preempt instead, like the other archs do. Signed-off-by: NSatyam Sharma <satyam@infradead.org> Signed-off-by: NTony Luck <tony.luck@intel.com>
-
由 Kenji Kaneshige 提交于
Add base support for implementing platform_irq_to_vector(), and then use it on SN2. Signed-off-by: NKenji Kaneshige <kaneshige.kenji@jp.fujitsu.com> Acked-by: NJohn Keller <jpk@sgi.com> Signed-off-by: NTony Luck <tony.luck@intel.com>
-
由 Dimitri Sivanich 提交于
While sending interrupts to a cpu to repeatedly wake a thread, on occasion that thread will take a full timer tick cycle (4002 usec in my case) to wakeup. The problem concerns a race condition in the code around the safe_halt() call in the default_idle() routine. Setting 'nohalt' on the kernel command line causes the long wakeups to disappear. void default_idle (void) { local_irq_enable(); while (!need_resched()) { --> if (can_do_pal_halt) --> safe_halt(); else A timer tick could arrive between the check for !need_resched and the actual call to safe_halt() (which does a pal call to PAL_HALT_LIGHT). By the time the timer tick completes, a thread that might now need to run could get held up for as long as a timer tick waiting for the halted cpu. I'm proposing that we disable irq's and check need_resched again before calling safe_halt(). Does anyone see any problem with this approach? Signed-off-by: NDimitri Sivanich <sivanich@sgi.com> Signed-off-by: NTony Luck <tony.luck@intel.com>
-
- 13 8月, 2007 1 次提交
-
-
由 Thomas Gleixner 提交于
Level type interrupts do not need to be resent. It was also found that some chipsets get confused in case of the resend. Mark the ioapic level type interrupts as such to avoid the resend functionality in the generic irq code. Signed-off-by: NThomas Gleixner <tglx@linutronix.de> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
- 12 8月, 2007 6 次提交
-
-
由 Linus Torvalds 提交于
Commit 3320ad99 broke mmio config space accesses totally on i386 - it dropped the "reg" offset to the address. Cc: dean gaudet <dean@arctic.org> Cc: Andi Kleen <ak@suse.de> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
由 Petr Vandrovec 提交于
apply_alternatives uses memcpy() to apply alternatives. Which has the unfortunate effect that while applying memcpy alternative to memcpy itself it tries to overwrite itself with nops - which causes #UD fault as it overwrites half of an instruction in copy loop, and from this point on only possible outcome is triplefault and reboot. So let's overwrite only first two instructions of memcpy - as long as the main memcpy loop is not in first two bytes it will work fine. Signed-off-by: NPetr Vandrovec <petr@vandrovec.name> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
由 Michal Piotrowski 提交于
There is no need to include linux/console.h twice. Signed-off-by: NMichal Piotrowski <michal.k.k.piotrowski@gmail.com> Signed-off-by: NPaul Mundt <lethal@linux-sh.org>
-
由 Jesper Juhl 提交于
Remove the duplicate inclusion of linux/personality.h from arch/sh64/kernel/signal.c Signed-off-by: NJesper Juhl <jesper.juhl@gmail.com> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NPaul Mundt <lethal@linux-sh.org>
-
由 Chuck Ebbert 提交于
The new percpu code has apparently broken the doublefault handler when CONFIG_DEBUG_SPINLOCK is set. Doublefault is handled by a hardware task, making the check SPIN_BUG_ON(lock->owner == current, lock, "recursion"); fault because it uses the FS register to access the percpu data for current, and that register is zero in the new TSS. (The trace I saw was on 2.6.20 where it was GS, but it looks like this will still happen with FS on 2.6.22.) Initializing FS in the doublefault_tss should fix it. AK: Also fix broken ptr_ok() and turn printks into KERN_EMERG AK: And add a PANIC prefix to make clear the system will hang AK: (e.g. x86-64 will recover) Signed-off-by: NChuck Ebbert <cebbert@redhat.com> Signed-off-by: NAndi Kleen <ak@suse.de> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
由 Andi Kleen 提交于
Fix WARNING: vmlinux.o(.text+0x183): Section mismatch: reference to .init.text:start_kernel (between 'is386' and 'check_x87') Signed-off-by: NAndi Kleen <ak@suse.de> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-