aboutsummaryrefslogtreecommitdiffstats
path: root/arch/x86/kernel
Commit message (Collapse)AuthorAgeFilesLines
* x86, arch/x86/kernel/io_apic_32.c: use kzalloc instead of kmalloc/memsetChristophe Jaillet2008-07-081-6/+3
| | | | | | | | | 1) replace kmalloc/memset with equivalent kzalloc. Signed-off-by: Christophe Jaillet <jaillet.christophe@wanadoo.fr> Cc: cj <jaillet.christophe@wanadoo.fr> Cc: petero2@telia.com Signed-off-by: Ingo Molnar <mingo@elte.hu>
* x86: fix IO APIC breakage on HP nx6325, v2Maciej W. Rozycki2008-07-081-2/+26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | > That helped a lot, the system seems to work normally now. > > Here's the relevant snippet from dmesg: > > [ 0.108006] ..TIMER: vector=0x30 apic1=0 pin1=2 apic2=-1 pin2=-1 > [ 0.108006] ..MP-BIOS bug: 8254 timer not connected to IO-APIC > [ 0.108006] ...trying to set up timer (IRQ0) through the 8259A ... <3> > [ 0.108006] ..... (found apic 0 pin 2) ...<3> failed. > [ 0.108006] ...trying to set up timer as Virtual Wire IRQ...<3> works. > > and the whole thing is at: http://www.sisk.pl/kernel/debug/20080618/dmesg-2.log Hmm, that only proved the 8259A is indeed wired to the pin #2 of the I/O APIC. > I, personally, don't have any and AMD only has SB600 documentation on its > web page (it's still marked as "AMD confidential" ;-)). Well, the IC block is most likely the same as that's not rocket science and once done there is no need to fiddle with that. That written, I am afraid there is nothing useful about the IC in the document, except that it's there and consists of an I/O APIC providing 24 inputs and the usual pair of 8259A cores. Thanks for the reference anyway. > There is an interrupt controller in there, but I'm not sure if there's any > 8259A. The northbridge is on the CPU, actually. I will praise the day someone ships an x86 machine without an 8259A core! As expressed in another mail I suspect there may actually be a direct route from the 8254 to INTIN0 in the southbridge -- this is what other bootstrap logs seen in the Internet suggest. This would mean this particular BIOS is buggy (is it the latest version?) and provides an incorrect IRQ override in its ACPI tables, for example because the responsible block has been blindly copied from a machine using a commoner wiring. This could be moderately easily fixed up with a quirk based on the PCI ID (after checking it again, we actually used to have a quirk for ATI in this area, but the way it was done suggests the issue was not understood well enough). Could you please remove the hack sent yesterday and test the patch provided below? I do hope it builds, but I have no immediate means to check it. Please report the output. The intent is to test INTIN0 directly before testing INTIN2 through the 8259A. Thanks. Aside of that, what I have gathered from your reports (please correct me if I have got it wrong) is that when the through-8259A mode is used, then after a while 8254 timer interrupts stop arriving. What's interesting, the "Virtual Wire IRQ" seems to work for you correctly (that's quite an odd setup where a local APIC input is used in the native mode -- please post /proc/interrupts for confirmation), which in turn implies the master 8259A drives its INT output as we expect. Why would the I/O APIC input have problems then? Hmm... [ mingo@elte.hu: revert the "x86: fix IO APIC breakage on HP nx6325" version. ] Signed-off-by: Ingo Molnar <mingo@elte.hu>
* x86: fix IO APIC breakage on HP nx6325Maciej W. Rozycki2008-07-081-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | On Thu, 19 Jun 2008, Rafael J. Wysocki wrote: > > With such a configuration the "x86: I/O APIC: timer through 8259A > > second-chance" patch should not matter, because the only change it > > introduces is an attempt to try the same I/O APIC pin again, but with the > > IRQ0 line of the master 8259A enabled. That's not a terribly unusual > > configuration and nothing should get confused in the system. > > But it _does_ get confused, really. Something certainly gets confused, but so far I am not sure which bit exactly it is, are you? > > Barring the unlikely possibility of the 8259A actually being wired to > > INTIN2 of the I/O APIC I can see two possible explanations: > > > > 1. The 8259A interrupt actually escapes to the CPU somehow and is handled > > as an ExtINTA interrupt. This would make the code in check_timer() > > decide it has found a working configuration, while actually it has been > > fooled. [...] > Here you go: > > [ 0.108006] ..TIMER: vector=0x30 apic1=0 pin1=2 apic2=-1 pin2=-1 > [ 0.108006] ..MP-BIOS bug: 8254 timer not connected to IO-APIC > [ 0.108006] ...trying to set up timer (IRQ0) through the 8259A ... <3> > [ 0.108006] ..... (found apic 0 pin 2) ...<3> works. > > The full dmesg is at: http://www.sisk.pl/kernel/debug/20080618/dmesg-1.log Thanks. In this case I suspect the case #1 quoted above happens, that is the 8259A manages to deliver its interrupt somehow. Note at this stage it is meant to be in the AEOI mode, so it can happily resubmit the interrupt indefinitely with no additional handling as long as it receives INTA cycles. Can you please try the patch below on top of "x86: I/O APIC: timer through 8259A second-chance" to see whether my hypothesis is true? It modifies the through-8259A setup path so that the APIC input gets masked, but the 8259A has the timer interrupt still enabled. Let me know how the timer interrupt is routed in this case. Bisected-by: "Rafael J. Wysocki" <rjw@sisk.pl> Tested-by: "Rafael J. Wysocki" <rjw@sisk.pl> Signed-off-by: Ingo Molnar <mingo@elte.hu>
* x86: coding style fixes to arch/x86/kernel/io_apic_32.cPaolo Ciarrocchi2008-07-081-175/+173
| | | | | | | | | | | | | | | | | | Before: total: 91 errors, 73 warnings, 2850 lines checked After: total: 1 errors, 47 warnings, 2848 lines checked Compile tested: paolo@paolo-desktop:/tmp$ size io* text data bss dec hex filename 13836 1756 11104 26696 6848 io_apic_32.o.after 13836 1756 11104 26696 6848 io_apic_32.o.before Signed-off-by: Paolo Ciarrocchi <paolo.ciarrocchi@gmail.com> Signed-off-by: Ingo Molnar <mingo@elte.hu>
* x86, io-apic: use predefined names instead of numeric constantsCyrill Gorcunov2008-07-082-10/+13
| | | | | | | This patch replaces some hard-coded numbers with predefined names. Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.com> Signed-off-by: Ingo Molnar <mingo@elte.hu>
* x86: APIC/SMP: Downgrade the NMI watchdog for "nosmp"Maciej W. Rozycki2008-07-081-0/+3
| | | | | | | | | If configured to use the I/O APIC, the NMI watchdog is deemed to fail if the chip has been deactivated as a result of "nosmp". Downgrade to the local APIC watchdog similarly to what is done for the UP case. Signed-off-by: Maciej W. Rozycki <macro@linux-mips.org> Signed-off-by: Ingo Molnar <mingo@elte.hu>
* x86: APIC/UP: Remove redundant NMI watchdog downgradeMaciej W. Rozycki2008-07-081-3/+0
| | | | | | | | | For the UP case the NMI watchdog downgrade is done consistently in APIC_init_uniprocessor() now. Remove redundant code used only when BIOS-disabled local APIC is activated. Signed-off-by: Maciej W. Rozycki <macro@linux-mips.org> Signed-off-by: Ingo Molnar <mingo@elte.hu>
* x86: APIC/UP: Downgrade the NMI watchdog for no I/O APICMaciej W. Rozycki2008-07-082-0/+6
| | | | | | | | | | | | | | | | If configured to use the I/O APIC, the NMI watchdog is deemed to fail if the chip will not be used in the UP configuration, because "noapic" has been specified or the chip is simply not there. Downgrade to the local APIC watchdog to rectify. The new #ifdef is ugly, I know. A proper solution is to provide suitable definitions of smp_found_config, etc. for !CONFIG_X86_IO_APIC in a header. Likewise the whole if () condition should be moved to a static inline function. Such clean-ups are beyond the scope of this change and can be done once the whole issue of the timer has been sorted out. Signed-off-by: Maciej W. Rozycki <macro@linux-mips.org> Signed-off-by: Ingo Molnar <mingo@elte.hu>
* Revert "x86: APIC/SMP: downgrade the NMI watchdog for "nosmp""Ingo Molnar2008-07-081-4/+0
| | | | | | This reverts commit 791b93d3dfaf16c23e978bec0cc0a3dd9d855d63. A better fix from Maciej will be merged.
* Revert "x86, io-apic: fix nmi_watchdog=1 bootup hang"Ingo Molnar2008-07-082-8/+4
| | | | | | This reverts commit 2229ff84f01746d02fb6b79e156fb5cce48c908f. A better fix from Maciej will be merged.
* x86, io-apic: fix nmi_watchdog=1 bootup hangIngo Molnar2008-07-082-4/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | nmi_watchdog=1 hangs on 64-bit: [ 0.250000] Detected 12.564 MHz APIC timer. [ 0.254178] APIC timer registered as dummy, due to nmi_watchdog=1! [ 0.260366] Testing NMI watchdog ... <4>WARNING: CPU#0: NMI appears to be stuck (0->0)! [ ... ] [ 0.470003] calling genl_init+0x0/0xd0 [ hard hang ] bisected it down to: git-bisect start git-bisect good 1beee8dc8cf58e3f605bd7b34d7a39939be7d8d2 git-bisect bad 11582ece0aaa2d0f94f345c08a4ab9997078a083 git-bisect bad 5479c623bb44089844022c03d4c0eb16d5b7a15f git-bisect bad cfb4c7fabeb499e1c29f9d1878968e37a938e28a git-bisect good 246dd412d31e4f5de1d43aa6422a325b785f36e4 git-bisect bad 3f8237eaff7dc1e35fa791dae095574fd974e671 git-bisect good 90e23b13ab849e2a11f00c655eb3a2011b4623be git-bisect bad 833526a34eeefc117df3191a594c3c3a4f15a9ac git-bisect good 791b93d3dfaf16c23e978bec0cc0a3dd9d855d63 git-bisect bad 65767c64068f2c93e56a1accfed5c78230ac12d7 git-bisect bad 2abc5c05dd82c188e3bdf6641a274f013348d14b git-bisect bad 317e1f2597ffb4d4db940577bbe56dc6e881ef07 | 317e1f2597ffb4d4db940577bbe56dc6e881ef07 is first bad commit | commit 317e1f2597ffb4d4db940577bbe56dc6e881ef07 | Author: Maciej W. Rozycki <macro@linux-mips.org> | Date: Wed May 21 22:10:22 2008 +0100 | x86: I/O APIC: clean up the 8259A on a NMI watchdog failure the problem is that in the dummy-lapic branch we rely on the i8259A but if the NMI watchdog fails we turn off IRQ 0 - which doesnt work too well ;-) Signed-off-by: Ingo Molnar <mingo@elte.hu>
* x86: IO-APIC - use NMI_NONE instead of numeric constantCyrill Gorcunov2008-07-082-2/+2
| | | | | | | | | | | Not sure but maybe it is better to use NMI_DISABLED, will take a look. But for now this patch is not change anything in logic so it will not hurt/broke the kernel. For most cases nmi_watchdog assignment is by one of NMI_* macro so I think there it make sense too. Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.com> Signed-off-by: Ingo Molnar <mingo@elte.hu>
* x86 build fix:Ingo Molnar2008-07-081-1/+1
| | | | | | | arch/x86/kernel/io_apic_64.c: In function 'check_timer': arch/x86/kernel/io_apic_64.c:1688: error: 'vector' undeclared (first use in this function) arch/x86/kernel/io_apic_64.c:1688: error: (Each undeclared identifier is reported only once arch/x86/kernel/io_apic_64.c:1688: error: for each function it appears in.)
* x86: apic_64.c fix sparse warnings about shadowed variablesThomas Gleixner2008-07-081-4/+4
| | | | | Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Ingo Molnar <mingo@elte.hu>
* x86: make irq_cfg staticThomas Gleixner2008-07-081-1/+1
| | | | | Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Ingo Molnar <mingo@elte.hu>
* x86: I/O APIC: timer through 8259A second-chanceMaciej W. Rozycki2008-07-082-17/+57
| | | | | | | | | | | | | | | | | | | | | | | Some systems incorrectly report the ExtINTA pin of the I/O APIC as the genuine target of the timer interrupt. Here is a change that copies timer pin information found to the other pin if one has been found only. This way both a direct and a through-8259A route is tested with the pin letting these problematic systems work well enough. If no timer pin information has been found for the I/O APIC, then local APIC variations are tried only, similarly to what is done without the change (except without the misleading messages). Obviously if we try the first-chance path without being told by the BIOS to do so, we should not complain either, so do not print the message in this case. The 64-bit variation should be updated with a call to replace_pin_at_irq() which can be done with the upcoming merge. Since add_pin_to_irq() is now always called in the first-chance path, the condition to require it in the second-chance path no longer happens. Signed-off-by: Maciej W. Rozycki <macro@linux-mips.org> Signed-off-by: Ingo Molnar <mingo@elte.hu>
* x86: I/O APIC: keep the timer IRQ masked during set-upMaciej W. Rozycki2008-07-082-2/+2
| | | | | | | | Keep the timer interrupt line masked when reconfiguring its interrupt redirection entry in the I/O APIC. Signed-off-by: Maciej W. Rozycki <macro@linux-mips.org> Signed-off-by: Ingo Molnar <mingo@elte.hu>
* x86: I/O APIC: unmask the second-chance timer interruptMaciej W. Rozycki2008-07-082-0/+2
| | | | | | | | | Unmask the timer interrupt line set up in the through-8259A mode explicitly after setup_timer_IRQ0_pin() has set up the I/O APIC interrupt redirection entry to let the two operations be unbound from each other. Signed-off-by: Maciej W. Rozycki <macro@linux-mips.org> Signed-off-by: Ingo Molnar <mingo@elte.hu>
* x86: I/O APIC: rename setup_ExtINT_IRQ0_pin()Maciej W. Rozycki2008-07-082-9/+10
| | | | | | | | | | | | Rename setup_ExtINT_IRQ0_pin() to setup_timer_IRQ0_pin() to better reflect the upcoming role of a function setting up a (semi-)arbitrary I/O APIC pin appropriately for the 8254 timer. By "appropriate" the following settings are meant: edge-triggered, active-high, all the other settings per-architecture. Adjust comments to reflect code appropriately. No functional changes. Signed-off-by: Maciej W. Rozycki <macro@linux-mips.org> Signed-off-by: Ingo Molnar <mingo@elte.hu>
* x86: I/O APIC: remove redundant LVT0 maskingMaciej W. Rozycki2008-07-082-6/+0
| | | | | | | | | The LINT0 line of the local APIC is masked in the LVT0 entry in check_timer() before this function is ever called. Removed the redundant unmasking for better control. Signed-off-by: Maciej W. Rozycki <macro@linux-mips.org> Signed-off-by: Ingo Molnar <mingo@elte.hu>
* x86: I/O APIC: remove redundant 8259A {,un}maskingMaciej W. Rozycki2008-07-082-8/+0
| | | | | | | | | | For a better control the masking and unmasking of the timer interrupt line in the 8259A operating in the 'Virtual Wire' mode has been moved out of setup_ExtINT_IRQ0_pin() now, so remove the redundant calls from the function. Signed-off-by: Maciej W. Rozycki <macro@linux-mips.org> Signed-off-by: Ingo Molnar <mingo@elte.hu>
* x86: I/O APIC: fix the name of the through-8259A handlerMaciej W. Rozycki2008-07-081-2/+1
| | | | | | | | | | | | | When the through-8259A mode is used for the timer, the call to set_irq_handler() will register a NULL handler name, resulting in "IO-APIC-<NULL>" reported. Fix by calling ioapic_register_intr() as done for all the other I/O APIC interrupts. The 64-bit variation calls set_irq_chip_and_handler_name() here needlessly and should get fixed with the upcoming merge. Signed-off-by: Maciej W. Rozycki <macro@linux-mips.org> Signed-off-by: Ingo Molnar <mingo@elte.hu>
* x86: I/O APIC: fix the name of the L-APIC IRQ handlerMaciej W. Rozycki2008-07-081-1/+1
| | | | | | | | | | | | | | | | The local APIC interrupt handler gets registered with set_irq_chip_and_handler_name(), which results in "local-APIC-edge-fasteoi" reported as the name of the handler. Fix by removing the type of the handler left over from before the generic handlers were introduced. The 64-bit variation should get fixed with the upcoming merge. NB It should really use the "edge" handler and not the "fasteoi" one, but that's a separate issue. Signed-off-by: Maciej W. Rozycki <macro@linux-mips.org> Signed-off-by: Ingo Molnar <mingo@elte.hu>
* x86: I/O APIC: clean up the 8259A on a NMI watchdog failureMaciej W. Rozycki2008-07-084-2/+17
| | | | | | | | | | There is no point in keeping the 8259A enabled if the I/O APIC NMI watchdog has failed and the 8259A is not used to pass through regular timer interrupts. This fixes problems with some systems where some logic gets confused. Signed-off-by: Maciej W. Rozycki <macro@linux-mips.org> Signed-off-by: Ingo Molnar <mingo@elte.hu>
* x86: APIC/SMP: downgrade the NMI watchdog for "nosmp"Maciej W. Rozycki2008-07-081-0/+4
| | | | | | | | | If configured to use the I/O APIC, the NMI watchdog is deemed to fail if the chip has been deactivated as a result of "nosmp". Downgrade to the local APIC watchdog similarly to what is done for the UP case. Signed-off-by: Maciej W. Rozycki <macro@linux-mips.org> Signed-off-by: Ingo Molnar <mingo@elte.hu>
* x86: APIC/SMP: correct the message for "nosmp"Maciej W. Rozycki2008-07-081-2/+1
| | | | | | | | The local APIC is no longer forced off when "nosmp" has been specified. Correct the message printed. Signed-off-by: Maciej W. Rozycki <macro@linux-mips.org> Signed-off-by: Ingo Molnar <mingo@elte.hu>
* x86: I/O APIC: keep IRQ off when changing LVT registersMaciej W. Rozycki2008-07-082-0/+4
| | | | | | | | | | Disable the 8259A acting in the "virtual wire" mode to keep the interrupt line inactive while fiddling with local APIC interrupt vector registers associated with its destination inputs. To be on the safe side, especially concerning flipping the trigger mode. Signed-off-by: Maciej W. Rozycki <macro@linux-mips.org> Signed-off-by: Ingo Molnar <mingo@elte.hu>
* x86: I/O APIC: clean up after a fasteoi failureMaciej W. Rozycki2008-07-082-0/+2
| | | | | | | | Disable the 8259A when routing of the timer interrupt through the chip to the local APIC of the primary processor has failed. Signed-off-by: Maciej W. Rozycki <macro@linux-mips.org> Signed-off-by: Ingo Molnar <mingo@elte.hu>
* x86: I/O APIC: remove parameters to fiddle with the 8259AMaciej W. Rozycki2008-07-083-51/+4
| | | | | | | | | | | Remove the "disable_8254_timer" and "enable_8254_timer" kernel parameters. Now that AEOI acknowledgements are no longer needed for correct timer operation, the 8259A can be kept disabled unconditionally unless interrupts, either timer or watchdog ones, are actually passed through it. Signed-off-by: Maciej W. Rozycki <macro@linux-mips.org> Signed-off-by: Ingo Molnar <mingo@elte.hu>
* x86: I/O APIC: AEOI timer acknowledgement clean-upsMaciej W. Rozycki2008-07-084-19/+13
| | | | | | | | | | | | | | The code that used to be in do_slow_gettimeoffset() that relied on the IRR bit of the master 8259A PIC for IRQ0 to check the state of the output timer 0 of the PIT is no longer there. As a result, there is no need to use the POLL command to acknowledge the timer interrupt in the "8259A Virtual Wire", except for the NMI watchdog when the i82489DX APIC is used (this is because this particular APIC treats NMIs as level-triggered and keeping the input asserted would keep motherboard NMI sources held off for too long). Remove the unneeded bits and adjust comments accordingly. Signed-off-by: Maciej W. Rozycki <macro@linux-mips.org> Signed-off-by: Ingo Molnar <mingo@elte.hu>
* Revert "Revert "x86: fix ioapic bug again""Ingo Molnar2008-07-082-4/+17
| | | | | | | | This reverts commit 0b6a39f7ebcb1c82587ce35b401c513eed41ac5c. The changes in tip/x86/apic solve this better. Signed-off-by: Ingo Molnar <mingo@elte.hu>
* Merge branch 'x86/s2ram-fix' into x86/urgentIngo Molnar2008-07-053-2/+57
|\
| * x86 ACPI: normalize segment descriptor register on resumeH. Peter Anvin2008-07-053-2/+57
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Some Dell laptops enter resume with apparent garbage in the segment descriptor registers (almost certainly the result of a botched transition from protected to real mode.) The only way to clean that up is to enter protected mode ourselves and clean out the descriptor registers. This fixes resume on Dell XPS M1210 and Dell D620. Reference: http://bugzilla.kernel.org/show_bug.cgi?id=10927 Signed-off-by: H. Peter Anvin <hpa@zytor.com> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Pavel Machek <pavel@ucw.cz> Cc: pm list <linux-pm@lists.linux-foundation.org> Cc: Len Brown <lenb@kernel.org> Signed-off-by: Ingo Molnar <mingo@elte.hu> Tested-by: Kirill A. Shutemov <kirill@shutemov.name> Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Signed-off-by: Ingo Molnar <mingo@elte.hu>
* | x86 ACPI: fix resume from suspend to RAM on uniprocessor x86-64Rafael J. Wysocki2008-07-051-1/+1
|/ | | | | | | | | | | | | | | Since the trampoline code is now used for ACPI resume from suspend to RAM, the trampoline page tables have to be fixed up during boot not only on SMP systems, but also on UP systems that use the trampoline. Reference: http://bugzilla.kernel.org/show_bug.cgi?id=10923 Reported-by: Dionisus Torimens <djtm@gmx.net> Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Cc: Andi Kleen <andi@firstfloor.org> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: pm list <linux-pm@lists.linux-foundation.org> Signed-off-by: Ingo Molnar <mingo@elte.hu>
* Merge branch 'x86-fixes-for-linus' of ↵Linus Torvalds2008-07-041-4/+4
|\ | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip * 'x86-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip: xen: fix address truncation in pte mfn<->pfn conversion arch/x86/mm/init_64.c: early_memtest(): fix types x86: fix Intel Mac booting with EFI
| * x86: fix Intel Mac booting with EFIHugh Dickins2008-07-031-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Fedora reports that mem_init()'s zap_low_mappings(), extended to SMP in 61165d7a035f6571c7576e7f51e7230157724c8d x86: fix app crashes after SMP resume causes 32-bit Intel Mac machines to reboot very early when booting with EFI. The EFI code appears to manage low mappings for itself when needed; but like many before it, confuses PSE with PAE. So it has only been mapping half the space it needed when PSE but not PAE. This remained unnoticed until we moved the SMP zap_low_mappings() before efi_enter_virtual_mode(). Presumably could have been noticed years ago if anyone ran a UP kernel on such machines? Reported-by: Peter Jones <pjones@redhat.com> Signed-off-by: Hugh Dickins <hugh@veritas.com> Cc: Peter Jones <pjones@redhat.com> Cc: Glauber Costa <gcosta@redhat.com> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Ingo Molnar <mingo@elte.hu> Tested-by: Peter Jones <pjones@redhat.com>
* | Merge branch 'x86-fixes-for-linus' of ↵Linus Torvalds2008-06-302-3/+2
|\ \ | |/ | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip * 'x86-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip: ptrace GET/SET FPXREGS broken x86: fix cpu hotplug crash x86: section/warning fixes x86: shift bits the right way in native_read_tscp
| * ptrace GET/SET FPXREGS brokenTAKADA Yoshihito2008-06-301-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When I update kernel 2.6.25 from 2.6.24, gdb does not work. On 2.6.25, ptrace(PTRACE_GETFPXREGS, ...) returns ENODEV. But 2.6.24 kernel's ptrace() returns EIO. It is issue of compatibility. I attached test program as pt.c and patch for fix it. #include <stdio.h> #include <stdlib.h> #include <unistd.h> #include <signal.h> #include <errno.h> #include <sys/ptrace.h> #include <sys/types.h> struct user_fxsr_struct { unsigned short cwd; unsigned short swd; unsigned short twd; unsigned short fop; long fip; long fcs; long foo; long fos; long mxcsr; long reserved; long st_space[32]; /* 8*16 bytes for each FP-reg = 128 bytes */ long xmm_space[32]; /* 8*16 bytes for each XMM-reg = 128 bytes */ long padding[56]; }; int main(void) { pid_t pid; pid = fork(); switch(pid){ case -1:/* error */ break; case 0:/* child */ child(); break; default: parent(pid); break; } return 0; } int child(void) { ptrace(PTRACE_TRACEME); kill(getpid(), SIGSTOP); sleep(10); return 0; } int parent(pid_t pid) { int ret; struct user_fxsr_struct fpxregs; ret = ptrace(PTRACE_GETFPXREGS, pid, 0, &fpxregs); if(ret < 0){ printf("%d: %s.\n", errno, strerror(errno)); } kill(pid, SIGCONT); wait(pid); return 0; } /* in the kerel, at kernel/i387.c get_fpxregs() */ Signed-off-by: Ingo Molnar <mingo@elte.hu>
| * x86: fix cpu hotplug crashZhang, Yanmin2008-06-301-1/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Vegard Nossum reported crashes during cpu hotplug tests: http://marc.info/?l=linux-kernel&m=121413950227884&w=4 In function _cpu_up, the panic happens when calling __raw_notifier_call_chain at the second time. Kernel doesn't panic when calling it at the first time. If just say because of nr_cpu_ids, that's not right. By checking the source code, I found that function do_boot_cpu is the culprit. Consider below call chain: _cpu_up=>__cpu_up=>smp_ops.cpu_up=>native_cpu_up=>do_boot_cpu. So do_boot_cpu is called in the end. In do_boot_cpu, if boot_error==true, cpu_clear(cpu, cpu_possible_map) is executed. So later on, when _cpu_up calls __raw_notifier_call_chain at the second time to report CPU_UP_CANCELED, because this cpu is already cleared from cpu_possible_map, get_cpu_sysdev returns NULL. Many resources are related to cpu_possible_map, so it's better not to change it. Below patch against 2.6.26-rc7 fixes it by removing the bit clearing in cpu_possible_map. Signed-off-by: Zhang Yanmin <yanmin_zhang@linux.intel.com> Tested-by: Vegard Nossum <vegard.nossum@gmail.com> Acked-by: Rusty Russell <rusty@rustcorp.com.au> Signed-off-by: Ingo Molnar <mingo@elte.hu>
* | x86: KVM guest: Use the paravirt clocksource structs and functionsGerd Hoffmann2008-06-241-56/+33
| | | | | | | | | | | | | | | | | | | | | | | | | | This patch updates the kvm host code to use the pvclock structs and functions, thereby making it compatible with Xen. The patch also fixes an initialization bug: on SMP systems the per-cpu has two different locations early at boot and after CPU bringup. kvmclock must take that in account when registering the physical address within the host. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Signed-off-by: Avi Kivity <avi@qumranet.com>
* | x86: Add structs and functions for paravirt clocksourceGerd Hoffmann2008-06-242-0/+142
|/ | | | | | | | | | | | | | | | This patch adds structs for the paravirt clocksource ABI used by both xen and kvm (pvclock-abi.h). It also adds some helper functions to read system time and wall clock time from a paravirtual clocksource (pvclock.[ch]). They are based on the xen code. They are enabled using CONFIG_PARAVIRT_CLOCK. Subsequent patches of this series will put the code in use. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Acked-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> Signed-off-by: Avi Kivity <avi@qumranet.com>
* x86, geode: add a VSA2 ID for General SoftwareJordan Crouse2008-06-191-1/+4
| | | | | | | | | | | | General Software writes their own VSA2 module for their version of the Geode BIOS, which returns a different ID then the standard VSA2. This was causing the framebuffer driver to break for most GSW boards. Signed-off-by: Jordan Crouse <jordan.crouse@amd.com> Cc: tglx@linutronix.de Cc: linux-geode@lists.infradead.org Signed-off-by: Ingo Molnar <mingo@elte.hu>
* x86: use BOOTMEM_EXCLUSIVE on 32-bitBernhard Walle2008-06-191-2/+8
| | | | | | | | | | | | This patch uses the BOOTMEM_EXCLUSIVE for crashkernel reservation also for i386 and prints a error message on failure. The patch is still for 2.6.26 since it is only bug fixing. The unification of reserve_crashkernel() between i386 and x86_64 should be done for 2.6.27. Signed-off-by: Bernhard Walle <bwalle@suse.de> Signed-off-by: Ingo Molnar <mingo@elte.hu> Cc: <stable@kernel.org>
* x86, 32-bit: fix boot failure on TSC-less processorsMikael Pettersson2008-06-191-10/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Booting 2.6.26-rc6 on my 486 DX/4 fails with a "BUG: Int 6" (invalid opcode) and a kernel halt immediately after the kernel has been uncompressed. The BUG shows EIP pointing to an rdtsc instruction in native_read_tsc(), invoked from native_sched_clock(). (This error occurs so early that not even the serial console can capture it.) A bisection showed that this bug first occurs in 2.6.26-rc3-git7, via commit 9ccc906c97e34fd91dc6aaf5b69b52d824386910: >x86: distangle user disabled TSC from unstable > >tsc_enabled is set to 0 from the command line switch "notsc" and from >the mark_tsc_unstable code. Seperate those functionalities and replace >tsc_enable with tsc_disable. This makes also the native_sched_clock() >decision when to use TSC understandable. > >Preparatory patch to solve the sched_clock() issue on 32 bit. > >Signed-off-by: Thomas Gleixner <tglx@linutronix.de> The core reason for this bug is that native_sched_clock() gets called before tsc_init(). Before the commit above, tsc_32.c used a "tsc_enabled" variable which defaulted to 0 == disabled, and which only got enabled late in tsc_init(). Thus early calls to native_sched_clock() would skip the TSC and use jiffies instead. After the commit above, tsc_32.c uses a "tsc_disabled" variable which defaults to 0, meaning that the TSC is Ok to use. Early calls to native_sched_clock() now erroneously try to use the TSC on !cpu_has_tsc processors, leading to invalid opcode exceptions. My proposed fix is to initialise tsc_disabled to a "soft disabled" state distinct from the hard disabled state set up by the "notsc" kernel option. This fixes the native_sched_clock() problem. It also allows tsc_init() to be simplified: instead of setting tsc_disabled = 1 on every error return, we just set tsc_disabled = 0 once when all checks have succeeded. I've verified that this lets my 486 boot again. I've also verified that a Core2 machine still uses the TSC as clocksource after the patch. Signed-off-by: Mikael Pettersson <mikpe@it.uu.se> Signed-off-by: Ingo Molnar <mingo@elte.hu>
* x86: fix NULL pointer deref in __switch_toSuresh Siddha2008-06-192-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Patrick McHardy reported a crash: > > I get this oops once a day, its apparently triggered by something > > run by cron, but the process is a different one each time. > > > > Kernel is -git from yesterday shortly before the -rc6 release > > (last commit is the usb-2.6 merge, the x86 patches are missing), > > .config is attached. > > > > I'll retry with current -git, but the patches that have gone in > > since I last updated don't look related. > > > > [62060.043009] BUG: unable to handle kernel NULL pointer dereference at > > 000001ff > > [62060.043009] IP: [<c0102a9b>] __switch_to+0x2f/0x118 > > [62060.043009] *pde = 00000000 > > [62060.043009] Oops: 0002 [#1] PREEMPT Vegard Nossum analyzed it: > This decodes to > > 0: 0f ae 00 fxsave (%eax) > > so it's related to the floating-point context. This is the exact > location of the crash: > > $ addr2line -e arch/x86/kernel/process_32.o -i ab0 > include/asm/i387.h:232 > include/asm/i387.h:262 > arch/x86/kernel/process_32.c:595 > > ...so it looks like prev_task->thread.xstate->fxsave has become NULL. > Or maybe it never had any other value. Somehow (as described below) TS_USEDFPU is set but the fpu is not allocated or freed. Another possible FPU pre-emption issue with the sleazy FPU optimization which was benign before but not so anymore, with the dynamic FPU allocation patch. New task is getting exec'd and it is prempted at the below point. flush_thread() { ... /* * Forget coprocessor state.. */ clear_fpu(tsk); <----- Preemption point clear_used_math(); ... } Now when it context switches in again, as the used_math() is still set and fpu_counter can be > 5, we will do a math_state_restore() which sets the task's TS_USEDFPU. After it continues from the above preemption point it does clear_used_math() and much later free_thread_xstate(). Now, at the next context switch, it is quite possible that xstate is null, used_math() is not set and TS_USEDFPU is still set. This will trigger unlazy_fpu() causing kernel oops. Fix this by clearing tsk's fpu_counter before clearing task's fpu. Reported-by: Patrick McHardy <kaber@trash.net> Signed-off-by: Suresh Siddha <suresh.b.siddha@intel.com> Signed-off-by: Ingo Molnar <mingo@elte.hu>
* Merge branch 'for-linus' of ↵Linus Torvalds2008-06-141-4/+10
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/jbarnes/pci-2.6 * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jbarnes/pci-2.6: PCI: fixup write combine comment in pci_mmap_resource x86: PAT export resource_wc in pci sysfs x86, pci-dma.c: don't always add __GFP_NORETRY to gfp suspend-vs-iommu: prevent suspend if we could not resume x86: pci-dma.c: use __GFP_NO_OOM instead of __GFP_NORETRY pci, x86: add workaround for bug in ASUS A7V600 BIOS (rev 1005) PCI: use dev_to_node in pci_call_probe PCI: Correct last two HP entries in the bfsort whitelist
| * Merge branch 'pci-for-jesse' of ↵Jesse Barnes2008-06-121-4/+10
| |\ | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/x86/linux-2.6-tip into for-linus
| | * x86, pci-dma.c: don't always add __GFP_NORETRY to gfpMiquel van Smoorenburg2008-06-101-3/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently arch/x86/kernel/pci-dma.c always adds __GFP_NORETRY to the allocation flags, because it wants to be reasonably sure not to deadlock when calling alloc_pages(). But really that should only be done in two cases: - when allocating memory in the lower 16 MB DMA zone. If there's no free memory there, waiting or OOM killing is of no use - when optimistically trying an allocation in the DMA32 zone when dma_mask < DMA_32BIT_MASK hoping that the allocation happens to fall within the limits of the dma_mask Also blindly adding __GFP_NORETRY to the the gfp variable might not be a good idea since we then also use it when calling dma_ops->alloc_coherent(). Clearing it might also not be a good idea, dma_alloc_coherent()'s caller might have set it on purpose. The gfp variable should not be clobbered. [ mingo@elte.hu: converted to delta patch ontop of previous version. ] Signed-off-by: Miquel van Smoorenburg <miquels@cistron.nl> Signed-off-by: Ingo Molnar <mingo@elte.hu>
| | * suspend-vs-iommu: prevent suspend if we could not resumePavel Machek2008-06-021-1/+30
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | iommu/gart support misses suspend/resume code, which can do bad stuff, including memory corruption on resume. Prevent system suspend in case we would be unable to resume. Signed-off-by: Pavel Machek <pavel@suse.cz> Tested-by: Patrick <ragamuffin@datacomm.ch> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Ingo Molnar <mingo@elte.hu>
| | * x86: pci-dma.c: use __GFP_NO_OOM instead of __GFP_NORETRYMiquel van Smoorenburg2008-06-021-4/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | On Wed, 2008-05-28 at 04:47 +0200, Andi Kleen wrote: > > So... why not just remove the setting of __GFP_NORETRY? Why is it > > wrong to oom-kill things in this case? > > When the 16MB zone overflows (which can be common in some workloads) > calling the OOM killer is pretty useless because it has barely any > real user data [only exception would be the "only 16MB" case Alan > mentioned]. Killing random processes in this case is bad. > > I think for 16MB __GFP_NORETRY is ok because there should be > nothing freeable in there so looping is useless. Only exception would be the > "only 16MB total" case again but I'm not sure 2.6 supports that at all > on x86. > > On the other hand d_a_c() does more allocations than just 16MB, especially > on 64bit and the other zones need different strategies. Okay, so how about this then ? Signed-off-by: Ingo Molnar <mingo@elte.hu>
generated by cgit v1.1 at 2025-08-08 00:23:25 +0000