- 17 8月, 2007 1 次提交
-
-
由 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>
-
- 15 8月, 2007 8 次提交
-
-
由 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>
-
由 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>
-
- 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 18 次提交
-
-
由 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>
-
由 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>
-
由 Pete Zaitcev 提交于
Create arch/x86_64/vdso/.gitignore and put vdso.lds into it. Signed-off-by: NPete Zaitcev <zaitcev@redhat.com> Signed-off-by: NAndi Kleen <ak@suse.de> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
由 Andi Kleen 提交于
The Averatec 2370 and some other Turion laptop BIOS seems to program the ENABLE_C1E MSR inconsistently between cores. This confuses the lapic use heuristics because when C1E is enabled anywhere it seems to affect the complete chip. Use a global flag instead of a per cpu flag to handle this. If any CPU has C1E enabled disabled lapic use. Thanks to Cal Peake for debugging. Cc: tglx@linutronix.de Signed-off-by: NAndi Kleen <ak@suse.de> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
由 Adrian Bunk 提交于
It's CONFIG_X86_MCE, not CONFIG_MCE. Signed-off-by: NAdrian Bunk <bunk@stusta.de> Signed-off-by: NAndi Kleen <ak@suse.de> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
由 Zachary Amsden 提交于
VT is very picky about when it can enter execution. Get all segments setup and get LDT and TR into valid state to allow VT execution under VMware and KVM (untested). This makes the boot decompression run under VT, which makes it several orders of magnitude faster on 64-bit Intel hardware. Before, I was seeing times up to a minute or more to decompress a 1.3MB kernel on a very fast box. Signed-off-by: NZachary Amsden <zach@vmware.com> Signed-off-by: NAndi Kleen <ak@suse.de> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
由 Andi Kleen 提交于
Commit 19d36ccd "x86: Fix alternatives and kprobes to remap write-protected kernel text" uses code which is being patched for patching. In particular, paravirt_ops does patching in two stages: first it calls paravirt_ops.patch, then it fills any remaining instructions with nop_out(). nop_out calls text_poke() which calls lookup_address() which calls pgd_val() (aka paravirt_ops.pgd_val): that call site is one of the places we patch. If we always do patching as one single call to text_poke(), we only need make sure we're not patching the memcpy in text_poke itself. This means the prototype to paravirt_ops.patch needs to change, to marshal the new code into a buffer rather than patching in place as it does now. It also means all patching goes through text_poke(), which is known to be safe (apply_alternatives is also changed to make a single patch). AK: fix compilation on x86-64 (bad rusty!) AK: fix boot on x86-64 (sigh) AK: merged with other patches Signed-off-by: NRusty Russell <rusty@rustcorp.com.au> Signed-off-by: NAndi Kleen <ak@suse.de> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
由 Andi Kleen 提交于
It turns out CLFLUSH support is still not complete; we flush the wrong pages. Again disable it for the release. Noticed by Jan Beulich who then also noticed a stupid typo later. Signed-off-by: NAndi Kleen <ak@suse.de> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
Current code assumed that devices were directly connected to a Calgary bridge, as it tried to get the iommu table directly from the parent bus controller. When we have another bridge between the Calgary/CalIOC2 bridge and the device we should look upwards until we get to the top (Calgary/CalIOC2 bridge), where the iommu table resides. Signed-off-by: NMurillo Fernandes Bernardes <mfb@br.ibm.com> Signed-off-by: NMuli Ben-Yehuda <muli@il.ibm.com> Signed-off-by: NAndi Kleen <ak@suse.de> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
由 dean gaudet 提交于
Some broken devices have been discovered to require %al/%ax/%eax registers for MMIO config space accesses. Modify mmconfig.c to use these registers explicitly (rather than modify the global readb/writeb/etc inlines). AK: also changed i386 to always use eax AK: moved change to extended space probing to different patch AK: reworked with inlines according to Linus' requirements. AK: improve comments. Signed-off-by: Ndean gaudet <dean@arctic.org> Signed-off-by: NAndi Kleen <ak@suse.de> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
由 Muli Ben-Yehuda 提交于
This patch finishes the i386 and x86-64 ->sysdata conversion and hopefully also fixes Riku's and Andy's observed bugs. It is based on Yinghai Lu's and Andy Whitcroft's patches (thanks!) with some changes: - introduce pci_scan_bus_with_sysdata() and use it instead of pci_scan_bus() where appropriate. pci_scan_bus_with_sysdata() will allocate the sysdata structure and then call pci_scan_bus(). - always allocate pci_sysdata dynamically. The whole point of this sysdata work is to make it easy to do root-bus specific things (e.g., support PCI domains and IOMMU's). I dislike using a default struct pci_sysdata in some places and a dynamically allocated pci_sysdata elsewhere - the potential for someone indavertantly changing the default structure is too high. - this patch only makes the minimal changes necessary, i.e., the NUMA node is always initialized to -1. Patches to do the right thing with regards to the NUMA node can build on top of this (either add a 'node' parameter to pci_scan_bus_with_sysdata() or just update the node when it becomes known). The patch was compile tested with various configurations (e.g., NUMAQ, VISWS) and run-time tested on i386 and x86-64. Unfortunately none of my machines exhibited the bugs so caveat emptor. Andy, could you please see if this fixes the NUMA issues you've seen? Riku, does this fix "pci=noacpi" on your laptop? Signed-off-by: NMuli Ben-Yehuda <muli@il.ibm.com> Cc: Yinghai Lu <yhlu.kernel@gmail.com> Cc: Andi Kleen <ak@suse.de> Cc: Chuck Ebbert <cebbert@redhat.com> Cc: <riku.seppala@kymp.net> Cc: Andy Whitcroft <apw@shadowen.org> Cc: Jeff Garzik <jeff@garzik.org> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
由 Jay Estabrook 提交于
This code corrects the usage of the request_irq() routine. Signed-off-by: NJay Estabrook <jay.estabrook@hp.com> Signed-off-by: NIvan Kokshaysky <ink@jurassic.park.msu.ru> Cc: Richard Henderson <rth@twiddle.net> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
由 Adrian Bunk 提交于
scripts/kconfig/conf -d arch/cris/Kconfig arch/cris/Kconfig:183: can't open file "drivers/cdrom/Kconfig" Signed-off-by: NAdrian Bunk <bunk@kernel.org> Cc: Mikael Starvik <starvik@axis.com> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
由 David Howells 提交于
Connect up the fallocate() system call. Signed-off-by: NDavid Howells <dhowells@redhat.com> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
由 Robin Holt 提交于
I have had four seperate system lockups attributable to this exact problem in two days of testing. Instead of trying to handle all the weird end cases and wrap, how about changing it to look for exactly what we appear to want. The following patch removes a couple races in setup_APIC_timer. One occurs when the HPET advances the COUNTER past the T0_CMP value between the time the T0_CMP was originally read and when COUNTER is read. This results in a delay waiting for the counter to wrap. The other results from the counter wrapping. This change takes a snapshot of T0_CMP at the beginning of the loop and simply loops until T0_CMP has changed (a tick has happened). <later> I have one small concern about the patch. I am not sure it meets the intent as well as it should. I think we are trying to match APIC timer interrupts up with the hpet counter increment. The event which appears to be disturbing this loop in our test environment is the NMI watchdog. What we believe has been happening with the existing code is the setup_APIC_timer loop has read the CMP value, and the NMI watchdog code fires for the first time. This results in a series of icache miss slowdowns and by the time we get back to things it has wrapped. I think this code is trying to get the CMP as close to the counter value as possible. If that is the intent, maybe we should really be testing against a "window" around the CMP. Something like COUNTER = CMP+/2. It appears COUNTER should get advanced every 89nSec (IIRC). The above seems like an unreasonably small window, but may be necessary. Without documentation, I am not sure of the original intent with this code. In summary, this code fixes my boot hangs, but since I am not certain of the intent of the existing code, I am not certain this has not introduced new bugs or unexpected behaviors. Signed-off-by: NRobin Holt <holt@sgi.com> Acked-by: NAndi Kleen <ak@suse.de> Cc: Vojtech Pavlik <vojtech@suse.cz> Cc: "Aaron Durbin" <adurbin@google.com> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
由 Bryan Wu 提交于
Cc: Alexey Dobriyan <adobriyan@gmail.com> Signed-off-by: NBryan Wu <bryan.wu@analog.com> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
- 10 8月, 2007 11 次提交
-
-
由 Heiko Carstens 提交于
0437e109 removes the migration cost init code. Remove the s390 leftovers as well. Signed-off-by: NHeiko Carstens <heiko.carstens@de.ibm.com> Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
-
由 Michael Holzheu 提交于
Signed-off-by: NMichael Holzheu <holzheu@de.ibm.com> Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
-
由 Benjamin Herrenschmidt 提交于
My "slices" address space management code that was added in the 2.6.22 implementation of get_unmapped_area() doesn't properly check that the size is a multiple of the requested page size. This allows userland to create VMAs that aren't a multiple of the huge page size with hugetlbfs (since hugetlbfs entirely relies on get_unmapped_area() to do that checking) which leads to a kernel BUG() when such areas are torn down. Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: NPaul Mackerras <paulus@samba.org>
-
由 Benjamin Herrenschmidt 提交于
powerpc has a couple of bugs in the usage of dma_masks that tend to break when drivers explicitly try to set a 32-bit mask for example. First, the code that generates the pci devices from the OF device-tree doesn't initialize the mask properly, then our implementation of set_dma_mask() was trying to validate the -previous- mask value, not the one passed in as an argument. This fixes these problems. Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: NPaul Mackerras <paulus@samba.org>
-
由 Stephen Rothwell 提交于
WARNING: vmlinux.o(.text+0x8174): Section mismatch: reference to .init.text:.prom_init (between '.__boot_from_prom' and '.__after_prom_start') WARNING: vmlinux.o(.text+0x8498): Section mismatch: reference to .init.text:.early_setup (between '.start_here_multiplatform' and '.start_here_common') WARNING: vmlinux.o(.text+0x8514): Section mismatch: reference to .init.text:.setup_system (between '.start_here_common' and 'system_call_common') WARNING: vmlinux.o(.text+0x8530): Section mismatch: reference to .init.text:.start_kernel (between '.start_here_common' and 'system_call_common') Signed-off-by: NStephen Rothwell <sfr@canb.auug.org.au> Acked-by: NGeert Uytterhoeven <Geert.Uytterhoeven@sonycom.com> Signed-off-by: NPaul Mackerras <paulus@samba.org>
-
由 Kim Phillips 提交于
This reverts commit 3baee955. That commit was a mistake from the start; I added mdio type to the bus scan list early on in my ucc_geth migrate to phylib development, which is just pure wrong (the ucc_geth_mii driver creates the mii bus and the PHY layer handles PHY enumeration without translation). This follows on from commit 77926826: Revert "[POWERPC] Don't complain if size-cells == 0 in prom_parse()" which was basically trying to hide a symptom of the original mistake this revert fixes. Signed-off-by: NKim Phillips <kim.phillips@freescale.com> Signed-off-by: NPaul Mackerras <paulus@samba.org>
-
Update ps3_defconfig. Signed-off-by: NGeoff Levand <geoffrey.levand@am.sony.com> Signed-off-by: NPaul Mackerras <paulus@samba.org>
-
由 Geoff Levand 提交于
Remove the Kconfig message that indicates the PS3 platform support is incomplete. Signed-off-by: NGeoff Levand <geoffrey.levand@am.sony.com> Signed-off-by: NPaul Mackerras <paulus@samba.org>
-
由 Geert Uytterhoeven 提交于
Fix the PS3 storage probe logic to properly find device regions on cold startup. o Change the storage probe event mask from notify_device_ready to notify_region_update. o Improve the storage probe error handling. o Change ps3_storage_wait_for_device() to use a temporary variable to hold the buffer address. Signed-off-by: NGeert Uytterhoeven <Geert.Uytterhoeven@sonycom.com> Signed-off-by: NGeoff Levand <geoffrey.levand@am.sony.com> Signed-off-by: NPaul Mackerras <paulus@samba.org>
-
由 Andre Detsch 提交于
This patch moves affinity initialization code from spu_base.c to a new spu_management_of_ops function (init_affinity), which is empty in the case of PS3. This fixes a linking problem that was happening when compiling for PS3. Also, some small code style changes were made. Signed-off-by: NAndre Detsch <adetsch@br.ibm.com> Signed-off-by: NGeoff Levand <geoffrey.levand@am.sony.com> Acked-by: NArnd Bergmann <arnd.bergmann@de.ibm.com> Signed-off-by: NPaul Mackerras <paulus@samba.org>
-
由 Paul Mackerras 提交于
We were getting a duplicate entry in the SLB shadow buffer in slb_flush_and_rebolt() if the kernel stack was in the same segment as PAGE_OFFSET, which on POWER6 causes the hypervisor to terminate the partition with an error. This fixes it. Also we were not creating an SLB entry (or an SLB shadow buffer entry) for the kernel stack on secondary CPUs when starting the CPU. This isn't a major problem, since an appropriate entry will be created on demand, but this fixes that also for consistency. Signed-off-by: NPaul Mackerras <paulus@samba.org>
-
- 09 8月, 2007 1 次提交
-
-
由 David S. Miller 提交于
Every time a cpu is added via hotplug, we allocate the per-cpu MONDO queues but we never free them up. Freeing isn't easy since the first cpu gets this memory from bootmem. Therefore, the simplest thing to do to fix this bug is to allocate the queues for all possible cpus at boot time. Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-