- 10 Jul, 2008 10 commits
-
-
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 authored
This reverts commit a74a1cc3df0be89658bc735c8aed80c8392e2c15. This was just temporary diagnostics commit - not needed now that we've got the final fix. Signed-off-by: -
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: -
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 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:
-
Yinghai Lu authored
and let 64-bit to fall back to use fixmap too. Signed-off-by:
-
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:
-
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:
-
- 09 Jul, 2008 30 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:
-
Vitaly Mayatskikh authored
Introduce generic C routine for handling necessary tail operations after protection fault in copy_*_user on x86. Signed-off-by:
-
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:
-
Yinghai Lu authored
to avoid warning from find_low_pfn_range for high pages size etc Signed-off-by:
-
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: -
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:
-
FUJITA Tomonori authored
Hmm, looks like it would be nice to have more cleanups of iommu.h and gart.h. Signed-off-by:
-
Yinghai Lu authored
handle head and tail that are not aligned to big pages (2MB/1GB boundary). with this patch, on system that support gbpages, change: last_map_addr: 1080000000 end: 1078000000 to: last_map_addr: 1078000000 end: 1078000000 Signed-off-by:
-
Yinghai Lu authored
When system have 4g less ram installed, and acpi table sit near end of ram, make max_pfn cover them too, so 64bit kernel don't need to mess up fixmap. Signed-off-by:
-
Yinghai Lu authored
Signed-off-by:
-
Yinghai Lu authored
prepare for overmapped patch also printout last_map_addr together with end Signed-off-by:
-
Glauber Costa authored
Remove them from the arch-specific file. Signed-off-by:
Glauber Costa <gcosta@redhat.com> Signed-off-by:
H. Peter Anvin <hpa@zytor.com> Signed-off-by:
-
Glauber Costa authored
x86_64 does not need it, but it won't have X86_INTEL_USERCOPY defined either. Signed-off-by:
-
Glauber Costa authored
We also carry the unaligned version with us. Only x86_64 uses it, but there's no problem in defining it. Signed-off-by:
-
Glauber Costa authored
Move both versions, which are highly similar, to uaccess.h. Note that, for x86_64, X86_WP_WORKS_OK is always defined. Signed-off-by:
-
Glauber Costa authored
We also check user pointer in x86_64 put_user, the way i386 does. In a separate patch for bisecting purposes. Signed-off-by:
-
Glauber Costa authored
For both __put_user_x and __put_user_8 macros, pass the error variable explicitly. Signed-off-by:
-
Glauber Costa authored
Move __get_user_asm and __get_user_size and __get_user_nocheck to uaccess.h. This requires us to define a macro at __get_user_size for the 64-bit access case. Signed-off-by:
-
Glauber Costa authored
Let the user of the macro specify the desired return. Signed-off-by:
-
Glauber Costa authored
Move both __put_user_asm and __put_user_size to uaccess.h. i386 already had a special function for 64-bit access, so for x86_64, we just define a macro with the same name. Note that for X86_64, CONFIG_X86_WP_WORKS_OK will always be defined, so the #else part will never be even compiled in. Signed-off-by:
-
Glauber Costa authored
Let the user of the macro specify the desired return. Signed-off-by:
-
Glauber Costa authored
Select X86_WP_WORKS_OK for x86_64 too. Signed-off-by:
-
Glauber Costa authored
Do it in a separate patch for bisectability. Goal is to have put_user_size integrated. Signed-off-by:
-
Glauber Costa authored
Take it out of uaccess_32.h. Since it seems that no users of the x86_64 exists, we simply pick the i386 version. Signed-off-by:
-
Glauber Costa authored
Merge versions of getuser from uaccess_32.h and uaccess_64.h into uaccess.h. There is a part which is 64-bit only (for now), and for that, we use a __get_user_8 macro. Signed-off-by:
-
Glauber Costa authored
Common parts of uaccess_32.h and uaccess_64.h are put in uaccess.h. Bits in uaccess_32.h and uaccess_64.h that come to this file are equal except for comments and whitespaces differences. Signed-off-by:
-
Glauber Costa authored
Using explicit hexa (0xFFFFFFUL) introduces an unnecessary difference between i386 and x86_64 because of the size of their long. Use -1UL instead. Signed-off-by:
-
Glauber Costa authored
Do not refer to the processor word-size with int, as it won't work with x86_64. Use long instead. Signed-off-by:
-
Glauber Costa authored
Put the likely hint in access_ok. Just for bisectability. Signed-off-by:
-
