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

[PATCH] x86: pci_assign_unassigned_resources() update

2005-09-10T02:42:51Z

I had some time to think about PCI assign issues in 2.6.13-rc series. The major problem here is that we call pci_assign_unassigned_resources() way too early - at subsys_initcall level. Therefore we give no chances to ACPI and PnP routines (called at fs_initcall level) to reserve their respective resources properly, as the comments in drivers/pnp/system.c and drivers/acpi/motherboard.c suggest: /** * Reserve motherboard resources after PCI claim BARs, * but before PCI assign resources for uninitialized PCI devices */ So I moved the pci_assign_unassigned_resources() call to pcibios_assign_resources() (fs_initcall), which should hopefully fix a lot of problems and make PCIBIOS_MIN_IO tweaks unnecessary. Other changes: - remove resource assignment code from pcibios_assign_resources(), since it duplicates pci_assign_unassigned_resources() functionality and actually does nothing in 2.6.13; - modify ROM assignment code as per Ben's suggestion: try to use firmware settings by default (if PCI_ASSIGN_ROMS is not set); - set CARDBUS_IO_SIZE back to 4K as it's a wonderful stress test for various setups. Confirmed by Tero Roponen (who had problems with the 4kB CardBus IO size previously). Signed-off-by: Linus Torvalds Signed-off-by: Chris Wright Signed-off-by: Greg Kroah-Hartman

[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] Move the fix to align node_end_pfns to a proper location

2005-08-07T17:00:39Z

Move the fix to align node_end_pfns to a proper location. The earlier fix made the node_remap_start_vaddr to get misaligned causing remap_numa_kva to barf again :-/ Signed-off-by: Ravikiran Thirumalai Signed-off-by: Shai Fultheim Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

[PATCH] visws: linkage fix

2005-08-07T17:00:38Z

This patch add stubs to allow the visws subarch to link again. Signed-off-by: Tom Duffy Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

[PATCH] i386 visws: Add machine_shutdown and emergency_restart

2005-08-06T19:54:57Z

Another x86 subarchitecture bit I missed. This adds both machine_emergency_restart missed in my reboot fixes and machine_shutdown needed for kexec support. Signed-off-by: Linus Torvalds

[PATCH] i386 voyager: Add machine_shutdown

2005-08-06T19:54:57Z

Here is one more bit of breakage my x86 sub-architecture confusion caused. Add machine_shutdown to voyager so it will compile with CONFIG_KEXEC. Signed-off-by: Linus Torvalds

[PATCH] fix voyager compile after machine_emergency_restart breakage

2005-08-05T19:22:37Z

[PATCH] i386: Implement machine_emergency_reboot introduced this new function into arch/i386/reboot.c. However, subarchitectures are entitled to implement their own copies of reboot.c from which this new function is now missing. It looks like visws will also need a similar fixup Signed-off-by: James Bottomley Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

[PATCH] remove special HPET_EMULATE_RTC config option

2005-08-04T23:27:58Z

We had a user whose apps weren't working correctly because his "rtc" wasn't working fully. For the sake of simplicity, it seems sensible to always enable HPET RTC emulation. Remove a special config option for HPET_EMULATE_RTC and make it directly depend on HPET_TIMER and RTC. This will avoid the hangs when EMULATE_RTC is not configured and when some userlevel script depends on RTC interrupt, as in: http://bugzilla.kernel.org/show_bug.cgi?id=4904 Signed-off-by: Venkatesh Pallipadi Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds