- 11 Jul, 2008 7 commits
-
-
Ingo Molnar authored
i spent a fair amount of time chasing a 64-bit bootup crash that manifested itself as bootup segfaults: S10network[1825]: segfault at 7f3e2b5d16b8 ip 00000031108748c9 sp 00007fffb9c14c70 error 4 in libc-2.7.so[3110800000+14d000] eventually causing init to die and panic the system: Kernel panic - not syncing: Attempted to kill init! Pid: 1, comm: init Not tainted 2.6.26-rc9-tip #13878 after a maratonic bisection session, the bad commit turned out to be: | b7675791859075418199c7af86a116ea34eaf5bd is first bad commit | commit b7675791859075418199c7af86a116ea34eaf5bd | Author: Jeremy Fitzhardinge <jeremy@goop.org> | Date: Wed Jun 25 00:19:00 2008 -0400 | | x86: remove open-coded save/load segment operations | | This removes a pile of buggy open-coded implementations of savesegment | and loadsegment. after some more bisection of this patch itself, it turns out that what makes the difference are the savesegment() changes to __switch_to(). Taking a look at this portion of arch/x86/kernel/process_64.o revealed this crutial difference: | good: 99c: 8c e0 mov %fs,%eax | 99e: 89 45 cc mov %eax,-0x34(%rbp) | | bad: 99c: 8c 65 cc mov %fs,-0x34(%rbp) which is due to: | unsigned fsindex; | - asm volatile("movl %%fs,%0" : "=r" (fsindex)); | + savesegment(fs, fsindex); savesegment() is implemented as: #define savesegment(seg, value) \ asm("mov %%" #seg ",%0":"=rm" (value) : : "memory") note the "m" modifier - it allows GCC to generate the segment move into a memory operand as well. But regarding segment operands there's a subtle detail in the x86 instruction set: the above 16-bit moves are zero-extend, but only if it goes to a register. If it goes to a memory operand, -0x34(%rbp) in the above case, there's no zero-extend to 32-bit and the instruction will only save 16 bits instead of the intended 32-bit. The other 16 bits is random data - which can cause problems when that value is used later on. The solution is to only allow segment operands to go to registers. This fix allows my test-system to boot up without crashing. Signed-off-by: Ingo Molnar <mingo@elte.hu>
-
Jeremy Fitzhardinge authored
Use the X86_FEATURE_SYSENTER32 to remove hard-coded CPU vendor check. Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> Signed-off-by: Ingo Molnar <mingo@elte.hu>
-
Jeremy Fitzhardinge authored
Add pseudo-feature bits to describe whether the CPU supports sysenter and/or syscall from ia32-compat userspace. This removes a hardcoded test in vdso32-setup. Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> Signed-off-by: Ingo Molnar <mingo@elte.hu>
-
Ingo Molnar authored
Yinghai Lu reported crashes on 64-bit x86: BUG: unable to handle kernel NULL pointer dereference at 0000000000000000 IP: [<ffffffff80253b17>] hrtick_start_fair+0x89/0x173 [...] And with a long session of debugging and a lot of difficulty, tracked it down to this commit: ---------------> 8fbbc4b4 is first bad commit commit 8fbbc4b4 Author: Alok Kataria <akataria@vmware.com> Date: Tue Jul 1 11:43:34 2008 -0700 x86: merge tsc_init and clocksource code <-------------- The problem is that the TSC unification missed these Makefile rules in arch/x86/kernel/Makefile: # Do not profile debug and lowlevel utilities CFLAGS_REMOVE_tsc_64.o = -pg CFLAGS_REMOVE_tsc_32.o = -pg ... CFLAGS_tsc_64.o := $(nostackp) ... which rules make sure that various instrumentation and debugging facilities are disabled for code that might end up in a VDSO - such as the TSC code. Reported-and-bisected-by: Yinghai Lu <yhlu.kernel@gmail.com> Signed-off-by: Ingo Molnar <mingo@elte.hu> Conflicts: Signed-off-by: Ingo Molnar <mingo@elte.hu>
-
Yinghai Lu authored
when more than 4g memory is installed, don't map the big hole below 4g. Signed-off-by: Yinghai Lu <yhlu.kernel@gmail.com> Cc: Suresh Siddha <suresh.b.siddha@intel.com> Signed-off-by: Ingo Molnar <mingo@elte.hu>
-
Yinghai Lu authored
save the SLIT, in case we are using fixmap to read it, and that fixmap could be cleared by others. Signed-off-by: Yinghai Lu <yhlu.kernel@gmail.com> Cc: Suresh Siddha <suresh.b.siddha@intel.com> Signed-off-by: Ingo Molnar <mingo@elte.hu>
-
Yinghai Lu authored
also let mem= to print out modified e820 map too Signed-off-by: Yinghai Lu <yhlu.kernel@gmail.com> Cc: Bernhard Walle <bwalle@suse.de> Signed-off-by: Ingo Molnar <mingo@elte.hu>
-
- 10 Jul, 2008 14 commits
-
-
Jeremy Fitzhardinge authored
Gas 2.15 complains about 32-bit registers being used in lea. AS arch/x86/lib/copy_user_64.o /local/scratch-2/jeremy/hg/xen/paravirt/linux/arch/x86/lib/copy_user_64.S: Assembler messages: /local/scratch-2/jeremy/hg/xen/paravirt/linux/arch/x86/lib/copy_user_64.S:188: Error: `(%edx,%ecx,8)' is not a valid 64 bit base/index expression /local/scratch-2/jeremy/hg/xen/paravirt/linux/arch/x86/lib/copy_user_64.S:257: Error: `(%edx,%ecx,8)' is not a valid 64 bit base/index expression AS arch/x86/lib/copy_user_nocache_64.o /local/scratch-2/jeremy/hg/xen/paravirt/linux/arch/x86/lib/copy_user_nocache_64.S: Assembler messages: /local/scratch-2/jeremy/hg/xen/paravirt/linux/arch/x86/lib/copy_user_nocache_64.S:107: Error: `(%edx,%ecx,8)' is not a valid 64 bit base/index expression Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> Cc: Vitaly Mayatskikh <v.mayatskih@gmail.com> Signed-off-by: Ingo Molnar <mingo@elte.hu>
-
Glauber Costa authored
Integration generated a duplicate call to use_tsc_delay. Particularly, the one that is done before we check for general tsc usability seems wrong. Signed-off-by: Glauber Costa <gcosta@redhat.com> Signed-off-by: Ingo Molnar <mingo@elte.hu>
-
Ingo Molnar authored
-
Ingo Molnar authored
these two sub-architectures want PCI to be default-on, not default-off. Reported-by: Robert Richter <robert.richter@amd.com> Signed-off-by: Ingo Molnar <mingo@elte.hu>
-
Maciej W. Rozycki authored
When an interrupt is rerouted to a different I/O APIC pin the relevant entry of the irq_2_pin list should get updated accordingly so that operations are performed on the correct redirection entry. This is already done by the 32-bit variation of the code and here is a complementing 64-bit implementation. Should make someone's decision less tough when merging the two. ;) Signed-off-by: Maciej W. Rozycki <macro@linux-mips.org> Signed-off-by: Ingo Molnar <mingo@elte.hu>
-
Ingo Molnar authored
This reverts commit 90221a61a71b7ad659d8741cf1e404506b174982. This too was just temporary diagnostics - not needed now that we've got the final fix via: | commit e2079c43 | Author: Rafael J. Wysocki <rjw@sisk.pl> | Date: Tue Jul 8 16:12:26 2008 +0200 | | x86: fix C1E && nx6325 stability problem Signed-off-by: Ingo Molnar <mingo@elte.hu>
-
Ingo Molnar authored
This reverts commit a74a1cc3df0be89658bc735c8aed80c8392e2c15. This was just temporary diagnostics commit - not needed now that we've got the final fix. Signed-off-by: Ingo Molnar <mingo@elte.hu>
-
FUJITA Tomonori authored
AMD_IOMMU should depend on IOMMU_HELPER since they are the IOMMU helper functions. SWIOTLB requires IOMMU_HELPER so declaring that AMD_IOMMU depends on SWIOTLB properly fixes the problems. Signed-off-by: Ingo Molnar <mingo@elte.hu>
-
FUJITA Tomonori authored
This remove lots of duplications in iommu.h and gart.h. The end result of this patch is: - iommu.h is a header file for everyone related with IOMMUs. - gart.h is the private header file. Only pci-gart_64.c and its friends include it. Signed-off-by: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp> Cc: fujita.tomonori@lab.ntt.co.jp Signed-off-by: Ingo Molnar <mingo@elte.hu>
-
Ingo Molnar authored
-
Yinghai Lu authored
even on 64bit systems with less than 4G RAM, we can now use fixmap to handle acpi SIT near end of ram. change e820_end to e820_end_of_ram again? or e820_ram_pfn? Signed-off-by: Yinghai Lu <yhlu.kernel@gmail.com> Cc: Suresh Siddha <suresh.b.siddha@intel.com> Signed-off-by: Ingo Molnar <mingo@elte.hu>
-
Yinghai Lu authored
and let 64-bit to fall back to use fixmap too. Signed-off-by: Yinghai Lu <yhlu.kernel@gmail.com> Cc: Suresh Siddha <suresh.b.siddha@intel.com> Signed-off-by: Ingo Molnar <mingo@elte.hu>
-
Yinghai Lu authored
fix phys_pmd_init to make sure not to return bigger value than end. also print out range split:1G/2M/4K in init_memory_mapping(). Signed-off-by: Yinghai Lu <yhlu.kernel@gmail.com> Cc: Suresh Siddha <suresh.b.siddha@intel.com> Signed-off-by: Ingo Molnar <mingo@elte.hu>
-
Ingo Molnar authored
fix: arch/x86/kernel/built-in.o: In function `dmi_ignore_irq0_timer_override': boot.c:(.init.text+0x3ea4): undefined reference to `force_mask_ioapic_irq_2' Signed-off-by: Ingo Molnar <mingo@elte.hu>
-
- 09 Jul, 2008 19 commits
-
-
Vitaly Mayatskikh authored
Switch copy_user_generic_string(), copy_user_generic_unrolled() and __copy_user_nocache() from custom tail handlers to generic copy_user_tail_handle(). Signed-off-by: Vitaly Mayatskikh <v.mayatskih@gmail.com> Acked-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Ingo Molnar <mingo@elte.hu>
-
Vitaly Mayatskikh authored
Introduce generic C routine for handling necessary tail operations after protection fault in copy_*_user on x86. Signed-off-by: Vitaly Mayatskikh <v.mayatskih@gmail.com> Acked-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Ingo Molnar <mingo@elte.hu>
-
Ingo Molnar authored
-
Cyrill Gorcunov authored
Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.com> Cc: Cyrill Gorcunov <gorcunov@gmail.com> Cc: akpm@linux-foundation.org Cc: andi@firstfloor.org Signed-off-by: Ingo Molnar <mingo@elte.hu>
-
Yinghai Lu authored
to avoid warning from find_low_pfn_range for high pages size etc Signed-off-by: Yinghai Lu <yhlu.kernel@gmail.com> Signed-off-by: Ingo Molnar <mingo@elte.hu>
-
Robert Richter authored
So far subsys_initcalls has been executed in this order depending on the object order in the Makefile: arch/x86/pci/visws.c:subsys_initcall(pcibios_init); arch/x86/pci/numa.c:subsys_initcall(pci_numa_init); arch/x86/pci/acpi.c:subsys_initcall(pci_acpi_init); arch/x86/pci/legacy.c:subsys_initcall(pci_legacy_init); arch/x86/pci/irq.c:subsys_initcall(pcibios_irq_init); arch/x86/pci/common.c:subsys_initcall(pcibios_init); This patch removes the ordering dependency. There is now only one subsys_initcall function that contains subsystem initialization code with a defined order. Signed-off-by: Robert Richter <robert.richter@amd.com> Acked-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Ingo Molnar <mingo@elte.hu>
-
Robert Richter authored
Signed-off-by: Robert Richter <robert.richter@amd.com> Acked-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Ingo Molnar <mingo@elte.hu>
-
Robert Richter authored
Signed-off-by: Robert Richter <robert.richter@amd.com> Acked-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Ingo Molnar <mingo@elte.hu>
-
Robert Richter authored
Signed-off-by: Robert Richter <robert.richter@amd.com> Acked-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Ingo Molnar <mingo@elte.hu>
-
Robert Richter authored
Signed-off-by: Robert Richter <robert.richter@amd.com> Acked-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Ingo Molnar <mingo@elte.hu>
-
Robert Richter authored
Signed-off-by: Robert Richter <robert.richter@amd.com> Acked-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Ingo Molnar <mingo@elte.hu>
-
Robert Richter authored
This should be safe since mmconfig*.o and init.o do not contain *initcalls with the same level as in other files. Signed-off-by: Robert Richter <robert.richter@amd.com> Acked-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Ingo Molnar <mingo@elte.hu>
-
Robert Richter authored
Signed-off-by: Robert Richter <robert.richter@amd.com> Acked-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Ingo Molnar <mingo@elte.hu>
-
Robert Richter authored
Signed-off-by: Robert Richter <robert.richter@amd.com> Acked-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Ingo Molnar <mingo@elte.hu>
-
Robert Richter authored
Signed-off-by: Robert Richter <robert.richter@amd.com> Acked-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Ingo Molnar <mingo@elte.hu>
-
Robert Richter authored
No functional nor ordering changes here. Signed-off-by: Robert Richter <robert.richter@amd.com> Acked-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Ingo Molnar <mingo@elte.hu>
-
Ingo Molnar authored
-
Ingo Molnar authored
fix: arch/x86/kernel/acpi/boot.c: In function ‘dmi_ignore_irq0_timer_override’: arch/x86/kernel/acpi/boot.c:1443: error: implicit declaration of function ‘force_mask_ioapic_irq_2’ Signed-off-by: Ingo Molnar <mingo@elte.hu>
-
Rafael J. Wysocki authored
The problems are that, with the ACPI vs timer overring issue _fixed_, after using the box for some time (between several seconds and 1 hour, at random) processes get very high CPU loads (once I've got X using 107% of the CPU, for example) and the system becomes unresponsive, as though there were interrupts lost or something similar. Andreas Herrman reproduced similar problems: > Ok, now I've reproduced the stability problem. > - Using tip/master, > - reverting e38502eb8aa82314d5ab0eba45f50e6790dadd88 and > - applying your patch from this posting > http://marc.info/?l=linux-kernel&m=121539354224562&w=4 > > Starting X, firefox, gimp, tuxpaint and doing some drawing in tuxpaint > results in a slow system. Drawing is almost not possible anymore -- > Selections of new colors, cursors etc. is performed with huge delay > if it's performed at all. > > BTW, the code sets up timer IRQ as Virtual Wire IRQ: > > Jul 8 14:57:58 kodscha IO-APIC (apicid-pin) 2-22, 2-23 not connected. > Jul 8 14:57:58 kodscha ..TIMER: vector=0x30 apic1=0 pin1=2 apic2=-1 pin2=-1 > Jul 8 14:57:58 kodscha ...trying to set up timer as Virtual Wire IRQ... works. > > and both INT0 and INT2 of IOAPIC are masked: > > Jul 8 14:57:58 kodscha NR Dst Mask Trig IRR Pol Stat Dmod Deli Vect: > Jul 8 14:57:58 kodscha 00 000 1 0 0 0 0 0 0 00 > Jul 8 14:57:58 kodscha 01 003 0 0 0 0 0 1 1 31 > Jul 8 14:57:58 kodscha 02 003 1 0 0 0 0 0 0 30 > > I've also seen strange CPU utilization -- with syslog-ng: > > top - 15:33:06 up 35 min, 4 users, load average: 1.70, 0.68, 0.37 > Tasks: 64 total, 4 running, 60 sleeping, 0 stopped, 0 zombie > Cpu0 : 0.0%us,100.0%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st > Cpu1 : 6.4%us, 87.2%sy, 0.0%ni, 5.8%id, 0.0%wa, 0.6%hi, 0.0%si, 0.0%st > Mem: 895384k total, 283568k used, 611816k free, 35492k buffers > Swap: 1959920k total, 0k used, 1959920k free, 163044k cached > > PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND > 4632 root 20 0 17216 800 580 S 104 0.1 0:34.22 syslog-ng > 28505 root 20 0 205m 11m 4024 S 6 1.3 0:21.16 X > 28518 root 20 0 56292 5652 4492 S 1 0.6 0:01.80 fluxbox > 1 root 20 0 3724 608 508 S 0 0.1 0:00.36 init > > So far I have no clue why C1E-idle in conjunction with virtual wire > mode causes this strange behaviour. > > ... and I start to think about the root cause of all this. > > I've performed similar tests under X with the IRQ0/INT0 configuration and > I did not see above symptoms. So lets fall back to the IRQ0/INT0 configuration on this box. This basically restores the dont-use-the-lapic-timer exception mechanism that was unconditional on this box prior commit 8750bf5 ("x86: add C1E aware idle function"). Signed-off-by: Ingo Molnar <mingo@elte.hu>
-