kernel.git/arch/i386/kernel, branch linux-2.6.13.y

[PATCH] i386: fix incorrect FP signal code

2005-08-24T02:52:37Z

i386 floating-point exception handling has a bug that can cause error code 0 to be sent instead of the proper code during signal delivery. This is caused by unconditionally checking the IS and c1 bits from the FPU status word when they are not always relevant. The IS bit tells whether an exception is a stack fault and is only relevant when the exception is IE (invalid operation.) The C1 bit determines whether a stack fault is overflow or underflow and is only relevant when IS and IE are set. Signed-off-by: Chuck Ebbert <76306.1226@compuserve.com> Signed-off-by: Linus Torvalds

[PATCH] Mobil Pentium 4 HT and the NMI

2005-08-20T01:44:56Z

I'm trying to get the nmi working with my laptop (IBM ThinkPad G41) and after debugging it a while, I found that the nmi code doesn't want to set it up for this particular CPU. Here I have: $ cat /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 15 model : 4 model name : Mobile Intel(R) Pentium(R) 4 CPU 3.33GHz stepping : 1 cpu MHz : 3320.084 cache size : 1024 KB physical id : 0 siblings : 2 core id : 0 cpu cores : 1 fdiv_bug : no hlt_bug : no f00f_bug : no coma_bug : no fpu : yes fpu_exception : yes cpuid level : 3 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe pni monitor ds_cpl est tm2 cid xtpr bogomips : 6642.39 processor : 1 vendor_id : GenuineIntel cpu family : 15 model : 4 model name : Mobile Intel(R) Pentium(R) 4 CPU 3.33GHz stepping : 1 cpu MHz : 3320.084 cache size : 1024 KB physical id : 0 siblings : 2 core id : 0 cpu cores : 1 fdiv_bug : no hlt_bug : no f00f_bug : no coma_bug : no fpu : yes fpu_exception : yes cpuid level : 3 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe pni monitor ds_cpl est tm2 cid xtpr bogomips : 6637.46 And the following code shows: $ cat linux-2.6.13-rc6/arch/i386/kernel/nmi.c [...] void setup_apic_nmi_watchdog (void) { switch (boot_cpu_data.x86_vendor) { case X86_VENDOR_AMD: if (boot_cpu_data.x86 != 6 && boot_cpu_data.x86 != 15) return; setup_k7_watchdog(); break; case X86_VENDOR_INTEL: switch (boot_cpu_data.x86) { case 6: if (boot_cpu_data.x86_model > 0xd) return; setup_p6_watchdog(); break; case 15: if (boot_cpu_data.x86_model > 0x3) return; Here I get boot_cpu_data.x86_model == 0x4. So I decided to change it and reboot. I now seem to have a working NMI. So, unless there's something know to be bad about this processor and the NMI. I'm submitting the following patch. Signed-off-by: Steven Rostedt Acked-by: Zwane Mwaikambo Acked-by: Mikael Pettersson Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

[PATCH] x86: Remove obsolete get_cpu_vendor call

2005-08-18T19:53:59Z

Since early CPU identify is in this information is already available Signed-off-by: Andi Kleen Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

[PATCH] transmeta: CONFIG_PROC_FS=n build fix

2005-08-02T04:38:00Z

Fix bug found by Grant Coady 's autobuild setup. Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

[PATCH] disable addres space randomization default on transmeta CPUs

2005-08-02T02:13:59Z

We know that the randomisation slows down some workloads on Transmeta CPUs by quite large amounts. We think it's because the CPU needs to recode the same x86 instructions when they pop up at a different virtual address after a fork+exec. So disable randomization by default on those CPUs. Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

[PATCH] remove sys_set_zone_reclaim()

2005-08-01T17:03:56Z

This removes sys_set_zone_reclaim() for now. While i'm sure Martin is trying to solve a real problem, we must not hard-code an incomplete and insufficient approach into a syscall, because syscalls are pretty much for eternity. I am quite strongly convinced that this syscall must not hit v2.6.13 in its current form. Firstly, the syscall lacks basic syscall design: e.g. it allows the global setting of VM policy for unprivileged users. (!) [ Imagine an Oracle installation and a SAP installation on the same NUMA box fighting over the 'optimal' setting for this flag. What will they do? Will they try to set the flag to their own preferred value every second or so? ] Secondly, it was added based on a single datapoint from Martin: http://marc.theaimsgroup.com/?l=linux-mm&m=111763597218177&w=2 where Martin characterizes the numbers the following way: ' Run-to-run variability for "make -j" is huge, so these numbers aren't terribly useful except to see that with reclaim the benchmark still finishes in a reasonable amount of time. ' in other words: the fundamental problem has likely not been solved, only a tendential move into the right direction has been observed, and a handful of numbers were picked out of a set of hugely variable results, without showing the variability data. How much variance is there run-to-run? I'd really suggest to first walk the walk and see what's needed to get stable & predictable kernel compilation numbers on that NUMA box, before adding random syscalls to tune a particular aspect of the VM ... which approach might not even matter once the whole picture has been analyzed and understood! The third, most important point is that the syscall exposes VM tuning internals in a completely unstructured way. What sense does it make to have a _GLOBAL_ per-node setting for 'should we go to another node for reclaim'? If then it might make sense to do this per-app, via numalib or so. The change is minimalistic in that it doesnt remove the syscall and the underlying infrastructure changes, only the user-visible changes. We could perhaps add a CAP_SYS_ADMIN-only sysctl for this hack, a'ka /proc/sys/vm/swappiness, but even that looks quite counterproductive when the generic approach is that we are trying to reduce the number of external factors in the VM balance picture. Signed-off-by: Ingo Molnar Signed-off-by: Linus Torvalds

merge 2.6.13-rc4 with ACPI's to-linus tree

2005-07-30T05:55:32Z

/home/lenb/src/to-linus branch 'acpi-2.6.12'

2005-07-30T03:31:17Z

[ACPI] Always set P-state on initialization

2005-07-29T22:29:47Z

Otherwise a platform that supports ACPI based cpufreq and boots up at lowest possible speed could stay there forever. This because the governor may request max speed, but the code doesn't update if there is no change in speed, and it assumed the initial state of max speed. http://bugzilla.kernel.org/show_bug.cgi?id=4634 Signed-off-by: Dominik Brodowski Signed-off-by: Venkatesh Pallipadi Signed-off-by: Len Brown

[PATCH] x86: avoid wasting IRQs patch update

2005-07-29T22:01:13Z

The patch addresses a problem with ACPI SCI interrupt entry, which gets re-used, and the IRQ is assigned to another unrelated device. The patch corrects the code such that SCI IRQ is skipped and duplicate entry is avoided. Second issue came up with VIA chipset, the problem was caused by original patch assigning IRQs starting 16 and up. The VIA chipset uses 4-bit IRQ register for internal interrupt routing, and therefore cannot handle IRQ numbers assigned to its devices. The patch corrects this problem by allowing PCI IRQs below 16. Signed-off by: Natalie Protasevich Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds