An error occurred fetching the project authors.
- 09 Sep, 2003 1 commit
-
-
Dave Jones authored
From: Hiroshi Miura <miura@da-cha.org> Intel SpeedStep driver using a BIOS SMI call. Quoting his original announcement: "This driver is based on the information from 1. Microsoft Windows XP Document. we can get the SMI interface values from ax=E980/int15 BIOS call. 2. Intel SpeedStep Applet Document.(from HP.com) http://h18007.www1.hp.com/support/files/evonotebook/us/download/10631.html " Adds code to request transition ownership when processing the system critical resume message. When a critical hibernate occurs, the Applet does not receive any system level notification. The change forces the Applet to re-acquire transition ownership upon resume from a critical hibernate. " This is informative. This saied that something 'ownership' call is needed on SMI interface first. 3. Grover, Andrew's int 15h patch posted to cpufreq ml Message-ID: <F760B14C9561B941B89469F59BA3A847E96E28@orsmsx401.jf.intel.com> code which call BIOS to get SMI values. I included it. 4. Malik Martin's rev engineering results. call is made with BX, CX, EDI register values. and need signature 'ISG' when call. find function values. bx=1(get) and bx=2(set) 5. Marc Lehmann's 'speedstep' utility, sample of assembler code to call SMI. 6. My work. find function to return max/min freq which system supportd. (bx=4) more values are gotten, but I cannot understand... find 'ownership' function value(bx=0, which is other than 1 2 4..). ToDo(in pregress) support governor "auto" and using smi_event call, imprement auto freqchange feature. test on 440BX/ZX platform. Memo module parameters are override result of an int 15h/eax=E890h call. these parameter value are gotten from Windows XP registory." Also includes some bugfixes, updates and workarounds from me. NB: A lot of BIOS out there are buggy. You might want to try this driver also with Intel's default values -- smi_cmd = 0x82 and smi_port = 0xb2
-
- 31 Aug, 2003 1 commit
-
-
Andrew Morton authored
From: Thomas Schlichter <schlicht@uni-mannheim.de> Make the `pci=noacpi' command line option work correctly. It fixes interrupt routing probems for (at least 3) people with broken ACPI BIOSes.
-
- 20 Aug, 2003 2 commits
-
-
Andrew Morton authored
From: Emilio Gallego Arias <egallego@telefonica.net> Apparently a couple of files now need io_apic.h.
-
Jeff Garzik authored
-
- 19 Aug, 2003 1 commit
-
-
Patrick Mochel authored
A recent slew of ACPI "fixes" completely broke the build when one built without SMP, IO APICs, or Local APICs. Bad Intel, no cookie.
-
- 15 Aug, 2003 1 commit
-
-
Len Brown authored
config tweaks from Dominik Brodowski
-
- 14 Aug, 2003 1 commit
-
-
Andrew Morton authored
From: Matthew Dobson <colpatch@us.ibm.com> 16 proc x440 boxen aren't booting mainline kernels right now for many valid configs. This patch makes sure NUMA codepaths aren't executed for SMP configs. It also adds some sane error messages to the code, and cleans up some #ifdefs.
-
- 09 Aug, 2003 2 commits
- 18 Jul, 2003 1 commit
-
-
Rusty Russell authored
Richard Henderson point out a while back that linker generated symbols should be declared as: "char _text[]" so that the compiler can't make assumptions about them sitting in small sections, etc. Centralize these defintions in asm/sections.h (where some already are on x86).
-
- 22 Jun, 2003 1 commit
-
-
Andy Grover authored
-
- 13 Jun, 2003 2 commits
-
-
Andy Grover authored
-
Andy Grover authored
and also cleans up the code to a significant degree.
-
- 07 Jun, 2003 1 commit
-
-
Andrew Morton authored
From: Matt Dobson, via Martin Bligh This parses the machine's BIOS tables to populate the mp_bus_id_to_node[bus] array. Only affects Summit machines, safe, boring. Has been in -mjb tree for ages, and works fine.
-
- 06 Jun, 2003 1 commit
-
-
Christoph Hellwig authored
It was useful in 2.4 to debug the blockhighmem stuff but in 2.5 it's b0rked because doesn't have any implication except propagation of the highmem_io flags from the scsi host template to the scsi host structure. It also only worked on i386. ACKed by Jens.
-
- 29 May, 2003 1 commit
-
-
Andrew Morton authored
From: Jan Marek <linux@hazard.jcu.cz> The DRM modules (i810) need this symbol. As this is a special-case for one particular in-kernel module I changed Jan's patch from EXPORT_SYMBOL to EXPORT_SYMBOL_GPL.
-
- 20 May, 2003 1 commit
-
-
Andrew Morton authored
From: Andi Kleen <ak@suse.de> There is some assembly code in setup.c which doesn't explicitly set its section. It comes after a C function which is marked __init. The compiler does not reset the section after such C functions. The assembly code is going into .text.init. That's the wrong section. We get oopses modprobing sctp and, with Manfred's unmap-free-pages debug patch we get oopses modprobing e100.ko. In apply_alternatives().
-
- 12 May, 2003 1 commit
-
-
Steven Cole authored
Don't depend on undefined preprocessor symbols evaluating to zero.
-
- 07 May, 2003 1 commit
-
-
Andrew Morton authored
From: Andi Kleen <ak@muc.de> This patch adds an generic x86 subarchitecture. It is intended to provide an dynamic interface for APIC drivers. There are already three subarchitectures (bigsmp, summit, default) that only differ in how they drive the local APIC. A fourth - Unisys ES7000 - is scheduled to be merged soon. The subarchitecture concept separated this nicely, but it has the big drawback that they are compile time options. A Linux vendor cannot ship own binary kernel rpms for all of these machines. Runtime probing is needed instead. This patch adds a new "generic" subarchitecture that just acts as a dynamic switching layer for APIC drivers. It only tries to virtualize the APICs, no attempt is made to cover further incompatiblities. This means machines like the Visual Workstation, pc9800 or Voyager are not covered; but these are unlikely to be supported by binary distributions anyways. The generic arch reuses the existing interface in mach_ipi / mach_mpparse.h / mach_apic.h and just pulls it using some macros into an "struct genapic" object. The main APIC code does not recognize it, it is all hidden in the mach-generic include files. Auto detection of APIC types is supported in the usual way used by existing ports like Summit - checking ACPI or mptables for specific signatures - or it can be specified by the user using a new "apic=" boot option. I also moved the DMI scan to before the generic subarchitecture probe, so DMI could be used in future too to probe specific machines. Some minor hacks were needed to avoid circular declaration of a few symbols, but overall it's fairly clean. The patch has been tested on a Summit machine, an generic 4 virtual CPUs Xeon and on an ES7000.
-
- 30 Apr, 2003 1 commit
-
-
Andi Kleen authored
-
- 23 Apr, 2003 2 commits
-
-
Andrew Morton authored
Fix some warnings from the new code-patching stuff.
-
Linus Torvalds authored
not be marked __init. Noted by Petr Vandrovec
-
- 21 Apr, 2003 1 commit
-
-
Andi Kleen authored
This implements automatic code patching of memory barriers based on the CPU capabilities. Normally lock ; addl $0,(%esp) barriers are used, but these are a bit slow on the Pentium 4. Linus proposed this a few weeks ago after the support for SSE1/SSE2 barriers was introduced. I now got around to implement it. The main advantage is that it allows distributors to ship less binary kernels but still get fast kernels. In particular it avoids the need of a special Pentium 4 kernel. The patching code is quite generic and could be used to patch other instructions (like prefetches or specific other critical instructions) too. Thanks to Rusty's in kernel loader it also works seamlessly for modules. The patching is done before other CPUs start to avoid potential erratas with self modifying code on SMP systems. It makes no attempt to automatically handle assymetric systems (an secondary CPU having less capabilities than the boot CPU). In this case just boot with "noreplacement"
-
- 20 Apr, 2003 1 commit
-
-
Christoph Hellwig authored
split the initrd stuff out of blk.h, it's only needed in the boot code and the ramdisk driver.
-
- 17 Apr, 2003 1 commit
-
-
Alan Cox authored
Now hw resources can be per mach- and we dont need a pile of ugly ifdefs for weird shite
-
- 10 Apr, 2003 1 commit
-
-
James Simmons authored
-
- 16 Mar, 2003 1 commit
-
-
Andrew Morton authored
Patch from "Randy.Dunlap" <rddunlap@osdl.org> Reverts the recent alteration of the format of the `mem=' option. This is because `mem=' is interpreted by bootloaders and may not be freely changed. Instead, the new functionality to set specific memory region usages is provided via the new "memmap=" option. The documentation for memmap= is added, and the documentation for mem= is updated.
-
- 27 Feb, 2003 1 commit
-
-
Dave Jones authored
-
- 26 Feb, 2003 1 commit
-
-
Andy Grover authored
ACPI DATA blocks (Pavel Machek)
-
- 25 Feb, 2003 1 commit
-
-
Michael Hayes authored
dont -> don't (135 occurrences)
-
- 18 Feb, 2003 1 commit
-
-
Andrew Morton authored
Patch from Andrey Panin <pazke@orbita1.ru> This patch contains core support for visws subarch.
-
- 21 Jan, 2003 1 commit
-
-
Matt Domsch authored
Found by Kevin Lawton.
-
- 15 Jan, 2003 1 commit
-
-
Andy Grover authored
-
- 22 Dec, 2002 2 commits
-
-
Manfred Spraul authored
boot_cpu_data should contain the common capabilities of all cpus in the system. identify_cpu [arch/i386/kernel/cpu/common.c] tries to enforce that. But right now, the SMP trampoline code [arch/i386/kernel/head.S] overwrites boot_cpu_data when the secondary cpus are started, i.e. boot_cpu_data contains the capabilities from the last cpu that booted :-( The attached patch adds a new, __initdata variable for the asm code.
-
Andi Kleen authored
"mem=nopentium" would clear the PSE bit in boot_cpu_data, but the CPU detection later would overwrite it again from CPUID. The large pages would be correctly disabled, but cpu_has_pse was lying. This patch makes sure it stays clear when the option is given. I also took the liberty to remove these obnoxious cpu capability printks who give no use information (the data can be either gotten from CPUID in user space in raw form or from /proc/cpuinfo processed)
-
- 21 Oct, 2002 1 commit
-
-
Matt Domsch authored
-
- 09 Oct, 2002 1 commit
-
-
Matt Domsch authored
The major changes implemented in this patch: arch/i386/boot/setup.S - int13 real mode calls store results in empty_zero_page arch/i386/kernel/setup.c - copy results from empty_zero_page to local storage arch/i386/kernel/edd.c - module exports results via driverfs x86 systems suffer from a disconnect between what BIOS believes is the boot disk, and what Linux thinks BIOS thinks is the boot disk. This manifests itself in multi-disk systems - it's quite possible to install a distribution, only to fail on reboot - the disk installed to is not the disk BIOS is booting from. Dell restricts our possible standard factory installed Linux offerings to "disks on no more than one controller" to avoid this problem, but mechanisms now exist to solve it and allow such configurations. BIOS Enhanced Disk Device Services (EDD) 3.0 provides the ability for disk adapter BIOSs to tell the OS what it believes is the boot disk. While this isn't widely implemented in BIOSs yet, it's time that Linux received support to be ready as BIOSs with this feature do become available. At a minimum, LSI MegaRAID cards support this today. EDD works by providing the bus (PCI, PCI-X, ISA, InfiniBand, PCI Express, or HyperTransport) location (e.g. PCI 02:01.0) and interface (ATAPI, ATA, SCSI, USB, 1394, FibreChannel, I2O, RAID, SATA) location (e.g. SCSI ID 5 LUN 0) information for each BIOS int13 device. The patch below creates CONFIG_EDD, that when defined, makes the BIOS int13 calls to retrieve and store this information. The data is copied to a safe place in setup.c, and exported via driverfs. Here's a sample driverfs tree with two BIOS int13 devices - dev 80 has incorrect PCI bus information, thus no symlinks are made, but as much info as possible is presented. Dev 81 has correct PCI and SCSI information, thus symlinks are made to the actual disc device. /driverfs |-- bios | |-- int13_dev80 | | |-- extensions | | |-- host_bus | | |-- info_flags | | |-- interface | | |-- raw_data | | |-- sectors | | `-- version | `-- int13_dev81 | |-- extensions | |-- host_bus | |-- info_flags | |-- interface | |-- pci_dev -> ../../root/pci2/02:0c.0/03:00.0/04:00.0 | |-- raw_data | |-- disc -> ../../root/pci2/02:0c.0/03:00.0/04:00.0/scsi4/4:0:0:0 | |-- sectors | `-- version |-- bus | |-- scsi | | |-- devices | | | |-- 4:0:0:0 -> ../../../root/pci2/02:0c.0/03:00.0/04:00.0/scsi4/4:0:0:0 | | `-- drivers | | `-- sd `-- root |-- pci2 | |-- 02:0c.0 | | |-- 03:00.0 | | | |-- 04:00.0 | | | | |-- irq | | | | |-- name | | | | |-- power | | | | |-- resource | | | | `-- scsi4 | | | | |-- 4:0:0:0 | | | | | |-- 4:0:0:0::p1 | | | | | | |-- kdev | | | | | | |-- name | | | | | | |-- power | | | | | | `-- type | | | | | |-- 4:0:0:0:disc | | | | | | |-- kdev | | | | | | |-- name | | | | | | |-- power | | | | | | `-- type | | | | | |-- name | | | | | |-- power | | | | | `-- type (Yes, the 'bios' top-level directory isn't the right place, and Patrick has promised to make something there in the future, at which point this can be moved.) The 'raw_data' file contains the full set of information returned by BIOS with extra error reporting. This exists for vendor BIOS debugging purposes. The 'host-bus' file contains the PCI (or ISA, HyperTransport, ...) identifying information, as BIOS knows it. The 'interface' file contains the SCSI (or IDE, USB, ...) identifying information, as BIOS knows it. The 'extensions' file lists the BIOS EDD extensions per spec. The 'info_flags' file lists the BIOS EDD device information flags per spec. The 'sectors' file reports the number of sectors BIOS believes this device has. The 'version' file lists the EDD version. To have device path information, this must be 0x30 or above. Earlier EDD versions exist without the device path - as much information as is available is presented. At most 6 BIOS devices are reported, as that fills the space that's left in the empty_zero_page. In general you only care about device 80h, though for software RAID1 knowing what 81h is might be useful also. Known issues: - module unload leaves a directory around. Seems related to creating symlinks in that directory. Seen on kernel 2.5.41. - refcounting of struct device objects could be improved. TODO: - Add IDE and USB disk device support - when driverfs model of discs and partitions changes, update symlink accordingly. - Get symlink creator helper functions exported from drivers/base instead of duplicating them here. - move edd.[ch] to better locations if/when one is decided I'd also like to acknowledge the help and comments received from Greg KH and Patrick Mochel. This isn't something driverfs was originally conceived to handle, their assistance has been invaluable. Please pull from: BK: http://mdomsch.bkbits.net/linux-2.5-edd-tolinus Patch (against 2.5.41+BK-current): http://domsch.com/linux/edd30/edd-driverfs-6.patch http://domsch.com/linux/edd30/edd-driverfs-6.patch.sign Thanks, Matt -- Matt Domsch Sr. Software Engineer, Lead Engineer, Architect Dell Linux Solutions www.dell.com/linux Linux on Dell mailing lists @ http://lists.us.dell.com
-
- 03 Sep, 2002 2 commits
-
-
Andrew Morton authored
- All the support macros which assume a linear mem_map[] have been wrapped in !CONFIG_DISCONTIGMEM. pfn_to_page, page_to_pfn, page_to_phys, pmd_page, kern_addr_valid. - Move some initialsation macros into setup.h so they can be used in the i386 discontig.c (INITRD_START, INITRD_SIZE). - Alternate version of the bootmem allocator - add i386 discontig support and numaq support.
-
Andrew Morton authored
This restructures setup_arch() for i386 to make it easier to include the i386 numa changes (for CONFIG_DISCONTIGMEM) I've been working on. It also makes setup_arch() easier to read. A version of this patch is the in 2.4 aa tree. This does not depend on the other patches I'm submitting today, but my discontigmem patch does depend on this one. I've tested this patch on the following configurations: UP, SMP, SMP PAE, multiquad, multiquad PAE.
-
- 20 Aug, 2002 1 commit
-
-
Andy Grover authored
will disable the ACPI interpreter init, but not stop the OS from using ACPI tables for finding CPUs and IOAPICs. Another problem is that if we use the tables, but then the interpreter fails to init, we are in deep trouble, because it is too late to revert to using MPS, but we cannot get _PRT info without the interpreter. This changeset doesn't fix the latter problem, but it does at least make "acpi=off" actually do what it says, and not use the ACPI interpreter *or* the tables.
-