aboutsummaryrefslogtreecommitdiff
path: root/arch/x86/kernel/quirks.c
AgeCommit message (Collapse)Author
2009-11-16x86: AMD Northbridge: Verify NB's node is onlinePrarit Bhargava
Fix panic seen on some IBM and HP systems on 2.6.32-rc6: BUG: unable to handle kernel NULL pointer dereference at (null) IP: [<ffffffff8120bf3f>] find_next_bit+0x77/0x9c [...] [<ffffffff8120bbde>] cpumask_next_and+0x2e/0x3b [<ffffffff81225c62>] pci_device_probe+0x8e/0xf5 [<ffffffff812b9be6>] ? driver_sysfs_add+0x47/0x6c [<ffffffff812b9da5>] driver_probe_device+0xd9/0x1f9 [<ffffffff812b9f1d>] __driver_attach+0x58/0x7c [<ffffffff812b9ec5>] ? __driver_attach+0x0/0x7c [<ffffffff812b9298>] bus_for_each_dev+0x54/0x89 [<ffffffff812b9b4f>] driver_attach+0x19/0x1b [<ffffffff812b97ae>] bus_add_driver+0xd3/0x23d [<ffffffff812ba1e7>] driver_register+0x98/0x109 [<ffffffff81225ed0>] __pci_register_driver+0x63/0xd3 [<ffffffff81072776>] ? up_read+0x26/0x2a [<ffffffffa0081000>] ? k8temp_init+0x0/0x20 [k8temp] [<ffffffffa008101e>] k8temp_init+0x1e/0x20 [k8temp] [<ffffffff8100a073>] do_one_initcall+0x6d/0x185 [<ffffffff8108d765>] sys_init_module+0xd3/0x236 [<ffffffff81011ac2>] system_call_fastpath+0x16/0x1b I put in a printk and commented out the set_dev_node() call when and got this output: quirk_amd_nb_node: current numa_node = 0x0, would set to val & 7 = 0x0 quirk_amd_nb_node: current numa_node = 0x0, would set to val & 7 = 0x1 quirk_amd_nb_node: current numa_node = 0x0, would set to val & 7 = 0x2 quirk_amd_nb_node: current numa_node = 0x0, would set to val & 7 = 0x3 I.e. the issue appears to be that the HW has set val to a valid value, however, the system is only configured for a single node -- 0, the others are offline. Check to see if the node is actually online before setting the numa node for an AMD northbridge in quirk_amd_nb_node(). Signed-off-by: Prarit Bhargava <prarit@redhat.com> Cc: bhavna.sarathy@amd.com Cc: jbarnes@virtuousgeek.org Cc: andreas.herrmann3@amd.com LKML-Reference: <20091112180933.12532.98685.sendpatchset@prarit.bos.redhat.com> [ v2: clean up the code and add comments ] Signed-off-by: Ingo Molnar <mingo@elte.hu>
2009-09-09x86/PCI: pci quirks, fix pci refcountingJiri Slaby
Stanse found a pci reference leak in quirk_amd_nb_node. Instead of putting nb_ht, there is a put of dev passed as an argument. http://stanse.fi.muni.cz/ Signed-off-by: Jiri Slaby <jirislaby@gmail.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2009-06-07Merge branch 'linus' into x86/cpuIngo Molnar
2009-04-24x86, hpet: Stop soliciting hpet=force users on ICH4MLen Brown
The HPET in the ICH4M is not documented in the data sheet because it was not officially validated. While it is fine for hackers to continue to use "hpet=force" to enable the hardware that they have, it is not prudent to solicit additional "hpet=force" users on this hardware. [ Impact: remove hpet=force syslog message on old-ICH systems ] Signed-off-by: Len Brown <len.brown@intel.com> Acked-by: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com> LKML-Reference: <alpine.LFD.2.00.0904231918510.15843@localhost.localdomain> Signed-off-by: Ingo Molnar <mingo@elte.hu>
2009-04-17x86: fixup numa_node information for AMD CPU northbridge functionsAndreas Herrmann
Currently the numa_node attribute for these PCI devices is 0 (it corresponds to the numa_node for PCI bus 0). This is not a big issue but incorrect. This inconsistency can be fixed by reading the node number from CPU NB function 0. [ Impact: fill in dev->numa_node information, to optimize DMA allocations ] Signed-off-by: Andreas Herrmann <andreas.herrmann3@amd.com> Cc: jbarnes@virtuousgeek.org LKML-Reference: <20090417100746.GG16198@alberich.amd.com> Signed-off-by: Ingo Molnar <mingo@elte.hu>
2009-03-28Merge branch 'linus' into x86/coreIngo Molnar
2009-03-10x86: BUG to BUG_ON changesStoyan Gaydarov
Impact: cleanup Signed-off-by: Stoyan Gaydarov <stoyboyker@gmail.com> LKML-Reference: <1236661850-8237-8-git-send-email-stoyboyker@gmail.com> Signed-off-by: Ingo Molnar <mingo@elte.hu>
2009-01-12x86: hpet: allow force enable on ICH10 HPETAndi Kleen
Intel "Smackover" x58 BIOS don't have HPET enabled in the BIOS, so allow to force enable it at least. The register layout is the same as in other recent ICHs, so all the code can be reused. Using numerical PCI-ID because it's unlikely the PCI-ID will be used anywhere else. Signed-off-by: Andi Kleen <ak@linux.intel.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-12-16x86: enable HPET on Fujitsu u9200Janne Kulmala
Impact: auto-enable HPET on Fujitsu u9200 HPET timer is listed in the ACPI table, but needs a quirk entry in order to work. Unfortunately, the quirk code runs after first HPET hpet_enable() which has already determined that the timer doesn't work (reads 0xFFFFFFFF). This patch allows hpet_enable() to be called again after running the quirk code. Signed-off-by: Janne Kulmala <janne.t.kulmala@tut.fi> Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-10-16x86: remove irqbalance in kernel for 32 bitYinghai Lu
This has been deprecated for years, the user space irqbalanced utility works better with numa, has configurable policies, etc... Signed-off-by: Yinghai Lu <yhlu.kernel@gmai.com> Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-09-05x86: hpet: modify IXP400 quirk to enable interruptsAndreas Herrmann
The current quirk is incomplete. Some more chipset fiddling has to be done to enable HPET interrupts. This patch aims to do this. From my tests it seems to work faultlessly. But the official statement is that HPET is not supported on SB4X0. Users will still have to use hpet=force to enable it. Use it at your own risk. Signed-off-by: Andreas Herrmann <andreas.herrmann3@amd.com> Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-07-15Merge branch 'timers/for-linus' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip * 'timers/for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip: x86: add PCI ID for 6300ESB force hpet x86: add another PCI ID for ICH6 force-hpet kernel-paramaters: document pmtmr= command line option acpi_pm clccksource: fix printk format warning nohz: don't stop idle tick if softirqs are pending. pmtmr: allow command line override of ioport nohz: reduce jiffies polling overhead hrtimer: Remove unused variables in ktime_divns() hrtimer: remove warning in hres_timers_resume posix-timers: print RT watchdog message
2008-07-14x86: add PCI ID for 6300ESB force hpetJoe Buehler
00:1f.0 ISA bridge: Intel Corporation 6300ESB LPC Interface Controller (rev 02) 00:1f.0 Class 0601: 8086:25a1 (rev 02) kernel: pci 0000:00:1f.0: Force enabled HPET at 0xfed00000 kernel: hpet clockevent registered kernel: hpet0: at MMIO 0xfed00000, IRQs 2, 8, 0 kernel: hpet0: 3 64-bit timers, 14318180 Hz Signed-off-by: Ingo Molnar <mingo@elte.hu> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2008-07-14x86: add another PCI ID for ICH6 force-hpetKrzysztof Oledzki
Tested on Asus P5GDC-V $ lspci -n -n |grep ISA 00:1f.0 ISA bridge [0601]: Intel Corporation 82801FB/FR (ICH6/ICH6R) LPC Interface Bridge [8086:2640] (rev 03) Force enabled HPET at base address 0xfed00000 hpet clockevent registered hpet0: at MMIO 0xfed00000, IRQs 2, 8, 0 hpet0: 3 64-bit timers, 14318180 Hz Signed-off-by: Krzysztof Piotr Oledzki <ole@ans.pl> Signed-off-by: Ingo Molnar <mingo@elte.hu> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2008-06-05x86: add another PCI ID for ICH6 force hpet.Krzysztof Oledzki
Tested on Asus P5GDC-V $ lspci -n -n |grep ISA 00:1f.0 ISA bridge [0601]: Intel Corporation 82801FB/FR (ICH6/ICH6R) LPC Interface Bridge [8086:2640] (rev 03) Force enabled HPET at base address 0xfed00000 hpet clockevent registered hpet0: at MMIO 0xfed00000, IRQs 2, 8, 0 hpet0: 3 64-bit timers, 14318180 Hz Signed-off-by: Krzysztof Piotr Oledzki <ole@ans.pl> Cc: mingo@elte.hu Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2008-05-12x86: print info about available HPET quirkThomas Gleixner
We have a lot of HPET quirks available which might force enable HPET even when the BIOS does not enable it. Some of those quirks depend on the command line option "hpet=force". Andrew pointed out that hoping that the user will find out about this boot option is not really helpful. Emit a kernel info which informs the user about the "hpet=force" boot option when we enter a quirk which depends on this option and the user did not provide it. Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2008-05-12x86: enable hpet=force for AMD SB400Andreas Herrmann
Add quirk to allow forced usage of HPET on ATI SB400. I stumbled over machines where HPET is enabled but not reported by BIOS. This patch configures the HPET base address and makes it known to the OS. Signed-off-by: Andreas Herrmann <andreas.herrmann3@amd.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2008-03-21x86: hpet clock enable quirk on nVidia nForce 430Zbigniew Luszpinski
this patch allows hpet=force on nVidia nForce 430 southbridge. This patch was tested by me on my old Asus A8N-VM CSM (where bios does not support hpet and does not advertise it via acpi entry). My nForce430 version: lspci -nn | grep LPC 00:0a.0 ISA bridge [0601]: nVidia Corporation MCP51 LPC Bridge [10de:0260] (rev a2) Kernel 2.6.24.3 after patching and using hpet=force reports this: dmesg | grep -i hpet Kernel command line: root=/dev/sda8 ro vga=773 video=vesafb:mtrr:4,ywrap vt.default_utf8=0 hpet=force Force enabled HPET at base address 0xfed00000 hpet clockevent registered Time: hpet clocksource has been installed. grep -i hpet /proc/timer_list Clock Event Device: hpet set_next_event: hpet_legacy_next_event set_mode: hpet_legacy_set_mode grep Clock /proc/timer_list (before patching) Clock Event Device: pit Clock Event Device: lapic grep Clock /proc/timer_list (after patching) Clock Event Device: hpet Clock Event Device: lapic Signed-off-by: Ingo Molnar <mingo@elte.hu> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2008-02-11Use proper abstractions in quirk_intel_irqbalanceMatthew Wilcox
Since we may not have a pci_dev for the device we need to access, we can't use pci_read_config_word. But raw_pci_read is an internal implementation detail; it's better to use the architected pci_bus_read_config_word interface. Using PCI_DEVFN instead of a mysterious constant helps reassure everyone that we really do intend to access device 8. [ Thanks to Grant Grundler for pointing out to me that this is exactly what the write immediately above this is doing -- enabling device 8 to respond to config space cycles. - Matthew Grant also says: "Can you also add a comment which points at the Intel documentation? The 'Intel E7320 Memory Controller Hub (MCH) Datasheet' at http://download.intel.com/design/chipsets/datashts/30300702.pdf Page 69 documents register F4h (DEVPRES1). And I just doubled checked that the 0xf4 register value is restored later in the quirk (obvious when you look at the code but not from the patch" so here it is. - Linus ] Signed-off-by: Matthew Wilcox <willy@linux.intel.com> Acked-by: Grant Grundler <grundler@parisc-linux.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-02-10Change pci_raw_ops to pci_raw_read/writeMatthew Wilcox
We want to allow different implementations of pci_raw_ops for standard and extended config space on x86. Rather than clutter generic code with knowledge of this, we make pci_raw_ops private to x86 and use it to implement the new raw interface -- raw_pci_read() and raw_pci_write(). Signed-off-by: Matthew Wilcox <willy@linux.intel.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-02-06x86: trivial sparse/checkpatch in quirks.cHarvey Harrison
arch/x86/kernel/quirks.c:384:3: warning: returning void-valued expression arch/x86/kernel/quirks.c:387:3: warning: returning void-valued expression arch/x86/kernel/quirks.c:390:3: warning: returning void-valued expression arch/x86/kernel/quirks.c:393:3: warning: returning void-valued expression Signed-off-by: Harvey Harrison <harvey.harrison@gmail.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-02-01PCI: use dev_printk in x86 quirk messagesbjorn.helgaas@hp.com
Convert quirk printks to dev_printk(). Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-01-30x86: force enable HPET on (some?) ICH9 boardsAlistair John Strachan
Some consumer ICH9 boards (such as the Abit IP35 Pro) do not provide a BIOS option for enabling the HPET. The same ICH workaround used for 6,7,8 can be applied to 9. Here I enable the only PCI id that was visible on my system. I have confirmed the HPETs work both from userspace and as a clocksource for the running kernel (2.6.24 here) after applying this patch. Force enabled HPET at base address 0xfed00000 hpet clockevent registered hpet0: at MMIO 0xfed00000, IRQs 2, 8, 0, 0 hpet0: 4 64-bit timers, 14318180 Hz Signed-off-by: Alistair John Strachan <alistair@devzero.co.uk> Signed-off-by: Ingo Molnar <mingo@elte.hu> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2007-10-23x86: Add HPET force support for MCP55 (nForce 5) chipsetsCarlos Corbacho
Add support to force_hpet for all known MCP55 (nForce 5) chipset LPC bridges. These are the untested nForce 5 chips (taken from Mikko's original patch, and checked against pci.ids). Signed-off-by: Carlos Corbacho <cathectic@gmail.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Ingo Molnar <mingo@elte.hu> arch/x86/kernel/quirks.c | 18 ++++++++++++++++++ 1 file changed, 18 insertions(+)
2007-10-23x86: Force enable HPET for CK804 (nForce 4) chipsetsCarlos Corbacho
This patch adds a quirk from LinuxBIOS to force enable HPET on the nVidia CK804 (nForce 4) chipset. This quirk can very likely support more than just nForce 4 (LinuxBIOS use the same code for nForce 5), and possibly nForce 3, but I don't have those chipsets, so cannot add and test them. Tested on an Abit KN9 (CK804). Signed-off-by: Carlos Corbacho <cathectic@gmail.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Ingo Molnar <mingo@elte.hu> Documentation/kernel-parameters.txt | 3 +- arch/x86/kernel/quirks.c | 37 +++++++++++++++++++++++++++++++++++- 2 files changed, 38 insertions(+), 2 deletions(-)
2007-10-19x86: enable HPET on ICH3 and ICH4Udo A. Steinberg
ICH3 and ICH4 have undocumented HPET capabilities. This patch enables HPET for platforms based around these ICHs. Tested on various ICH3 and ICH4 platforms. Because HPET is not officially documented for ICH3/4 and may not have been validated by chipset folks, we're on thin ice here. I'd recommend testing this patch in -hrt or -mm for a while and wait for success/failure reports before feeding it upstream. tglx: depends on the force_hpet command line option ! Signed-off-by: Udo A. Steinberg <us15@os.inf.tu-dresden.de> Signed-off-by: Ingo Molnar <mingo@elte.hu> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2007-10-19x86: force enable HPET on VT8235/8237 chipsetsUdo A. Steinberg
This patch adds quirks to force enable HPET on Via VT8235 and VT8237 chipsets. The datasheet for 8237 documents HPET functionality (although wrongly) whereas HPET is undocumented for 8235. Tested on A7V880 (8237) and K7VT4A+ (8235) boards. tglx: depends on the force_hept commandline option Signed-off-by: Udo A. Steinberg <us15@os.inf.tu-dresden.de> Cc: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com> Cc: Andi Kleen <ak@suse.de> Cc: john stultz <johnstul@us.ibm.com> Cc: Greg KH <greg@kroah.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Ingo Molnar <mingo@elte.hu> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2007-10-19x86: quirk.c trivial coding style and white space cleanupThomas Gleixner
Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Ingo Molnar <mingo@elte.hu>
2007-10-12x86: HPET add another ICH7 PCI idVenki Pallipadi
Add another PCI ID for ICH7 force hpet. Signed-off-by: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com> Cc: Andi Kleen <ak@suse.de> Cc: john stultz <johnstul@us.ibm.com> Cc: Greg KH <greg@kroah.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Ingo Molnar <mingo@elte.hu> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Arjan van de Ven <arjan@linux.intel.com>
2007-10-12x86: HPET force enable ICH5 suspend/resume fixVenki Pallipadi
A bugfix in ich5 hpet force detect which caused resumes to fail. Thanks to Udo A Steinberg for reporting the problem. Signed-off-by: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com> Cc: Andi Kleen <ak@suse.de> Cc: john stultz <johnstul@us.ibm.com> Cc: Greg KH <greg@kroah.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Ingo Molnar <mingo@elte.hu> Signed-off-by: Arjan van de Ven <arjan@linux.intel.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2007-10-12x86: HPET force enable for ICH5Venki Pallipadi
force_enable hpet for ICH5. [ Build fixes from Andrew Morton ] Signed-off-by: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com> Cc: Andi Kleen <ak@suse.de> Cc: john stultz <johnstul@us.ibm.com> Cc: Greg KH <greg@kroah.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Ingo Molnar <mingo@elte.hu> Signed-off-by: Arjan van de Ven <arjan@linux.intel.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2007-10-12x86: HPET force enable o ICH7 and laterVenki Pallipadi
Force detect and/or enable HPET on ICH chipsets. This patch just handles the detection part and following patches use this information. Adds a function to repeat the force enabling during resume time. Using HPET this way, instead of PIT increases the time CPUs can reside in C-state when system is totally idle. On my test system with Core 2 Duo, average C-state residency goes up from ~20mS to ~80mS. [ Build fixed from Andrew Morton ] Signed-off-by: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com> Cc: Andi Kleen <ak@suse.de> Cc: john stultz <johnstul@us.ibm.com> Cc: Greg KH <greg@kroah.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Ingo Molnar <mingo@elte.hu> Signed-off-by: Arjan van de Ven <arjan@linux.intel.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2007-10-11i386: move kernelThomas Gleixner
Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Ingo Molnar <mingo@elte.hu>