1. 31 1月, 2008 15 次提交
  2. 30 1月, 2008 24 次提交
    • L
      [net] Gracefully handle shared e1000/1000e driver PCI ID's · 60e23317
      Linus Torvalds 提交于
      Both the old e1000 driver and the new e1000e driver can drive some
      PCI-Express e1000 cards, and we should avoid ambiguity about which
      driver will pick up the support for those cards when both drivers are
      enabled.
      
      This solves the problem by having the old driver support those cards if
      the new driver isn't configured, but otherwise ceding support for PCI
      Express versions of the e1000 chipset to the newer driver.  Thus
      allowing both legacy configurations where only the old driver is active
      (and handles all chips it knows about) and the new configuration with
      the new driver handling the more modern PCIE variants.
      Acked-by: NJeff Garzik <jeff@garzik.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      60e23317
    • B
      x86: early boot debugging via FireWire (ohci1394_dma=early) · f212ec4b
      Bernhard Kaindl 提交于
      This patch adds a new configuration option, which adds support for a new
      early_param which gets checked in arch/x86/kernel/setup_{32,64}.c:setup_arch()
      to decide wether OHCI-1394 FireWire controllers should be initialized and
      enabled for physical DMA access to allow remote debugging of early problems
      like issues ACPI or other subsystems which are executed very early.
      
      If the config option is not enabled, no code is changed, and if the boot
      paramenter is not given, no new code is executed, and independent of that,
      all new code is freed after boot, so the config option can be even enabled
      in standard, non-debug kernels.
      
      With specialized tools, it is then possible to get debugging information
      from machines which have no serial ports (notebooks) such as the printk
      buffer contents, or any data which can be referenced from global pointers,
      if it is stored below the 4GB limit and even memory dumps of of the physical
      RAM region below the 4GB limit can be taken without any cooperation from the
      CPU of the host, so the machine can be crashed early, it does not matter.
      
      In the extreme, even kernel debuggers can be accessed in this way. I wrote
      a small kgdb module and an accompanying gdb stub for FireWire which allows
      to gdb to talk to kgdb using remote remory reads and writes over FireWire.
      
      An version of the gdb stub fore FireWire is able to read all global data
      from a system which is running a a normal kernel without any kernel debugger,
      without any interruption or support of the system's CPU. That way, e.g. the
      task struct and so on can be read and even manipulated when the physical DMA
      access is granted.
      
      A HOWTO is included in this patch, in Documentation/debugging-via-ohci1394.txt
      and I've put a copy online at
      ftp://ftp.suse.de/private/bk/firewire/docs/debugging-via-ohci1394.txt
      
      It also has links to all the tools which are available to make use of it
      another copy of it is online at:
      ftp://ftp.suse.de/private/bk/firewire/kernel/ohci1394_dma_early-v2.diffSigned-Off-By: NBernhard Kaindl <bk@suse.de>
      Tested-By: NThomas Renninger <trenn@suse.de>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      f212ec4b
    • I
      x86: remove flush_agp_mappings() · 5398f985
      Ingo Molnar 提交于
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      5398f985
    • T
      x86: cpa: move flush to cpa · d7c8f21a
      Thomas Gleixner 提交于
      The set_memory_* and set_pages_* family of API's currently requires the
      callers to do a global tlb flush after the function call; forgetting this is
      a very nasty deathtrap. This patch moves the global tlb flush into
      each of the callers
      Signed-off-by: NArjan van de Ven <arjan@linux.intel.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      d7c8f21a
    • A
      x86: convert CPA users to the new set_page_ API · 6d238cc4
      Arjan van de Ven 提交于
      This patch converts various users of change_page_attr() to the new,
      more intent driven set_page_*/set_memory_* API set.
      Signed-off-by: NArjan van de Ven <arjan@linux.intel.com>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      6d238cc4
    • Y
      cpufreq: fix obvious condition statement error · 53391fa2
      Yi Yang 提交于
      The function __cpufreq_set_policy in file drivers/cpufreq/cpufreq.c
      has a very obvious error:
      
              if (policy->min > data->min && policy->min > policy->max) {
                      ret = -EINVAL;
                      goto error_out;
              }
      
      This condtion statement is wrong because it returns -EINVAL only if
      policy->min is greater than policy->max (in this case,
      "policy->min > data->min" is true for ever.). In fact, it should
      return -EINVAL as well if policy->max is less than data->min.
      
      The correct condition should be:
      
      	if (policy->min > data->max || policy->max < data->min) {
      
      The following test result testifies the above conclusion:
      
      Before applying this patch:
      
      [root@yangyi-dev /]# cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies
      2394000 1596000
      [root@yangyi-dev /]# echo 1596000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq
      [root@yangyi-dev /]# cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq
      1596000
      [root@yangyi-dev /]# cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq
      1596000
      [root@yangyi-dev /]# echo "2000000" > /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq
      -bash: echo: write error: Invalid argument
      [root@yangyi-dev /]# cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq
      1596000
      [root@yangyi-dev /]# echo "0" > /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq
      [root@yangyi-dev /]# cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq
      1596000
      [root@yangyi-dev /]# echo "1595000" > /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq
      [root@yangyi-dev /]# cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq
      1596000
      [root@yangyi-dev /]#
      
      After applying this patch:
      
      [root@yangyi-dev /]# cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies
      2394000 1596000
      [root@yangyi-dev /]# echo 1596000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq
      [root@yangyi-dev /]# cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq
      1596000
      [root@yangyi-dev /]# cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq
      1596000
      [root@localhost /]# echo "2000000" > /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq
      -bash: echo: write error: Invalid argument
      [root@localhost /]# cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq
      1596000
      [root@localhost /]# echo "0" > /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq
      -bash: echo: write error: Invalid argument
      [root@localhost /]# echo "1595000" > /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq
      -bash: echo: write error: Invalid argument
      [root@localhost /]# cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq
      1596000
      [root@localhost /]# echo "1596000" > /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq
      [root@localhost /]# echo "2394000" > /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq
      [root@localhost /]# cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq
      2394000
      [root@localhost /]
      Signed-off-by: NYi Yang <yi.y.yang@intel.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      53391fa2
    • Y
      x86: left over fix for leak of early_ioremp in dmi_scan · 3212bff3
      Yinghai Lu 提交于
      Signed-off-by: NYinghai Lu <yinghai@sun.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      3212bff3
    • B
      rtc: use the IRQ callback interface in (old) RTC driver · f8f76481
      Bernhard Walle 提交于
      the previous patch in the old RTC driver.  It also removes the direct
      rtc_interrupt() call from arch/x86/kernel/hpetc.c so that there's finally no
      (code) dependency to CONFIG_RTC in arch/x86/kernel/hpet.c.
      
      Because of this, it's possible to compile the drivers/char/rtc.ko driver as
      module and still use the HPET emulation functionality.  This is also expressed
      in Kconfig.
      Signed-off-by: NBernhard Walle <bwalle@suse.de>
      Cc: Alessandro Zummo <a.zummo@towertech.it>
      Cc: David Brownell <david-b@pacbell.net>
      Cc: Andi Kleen <ak@suse.de>
      Cc: john stultz <johnstul@us.ibm.com>
      Cc: Robert Picco <Robert.Picco@hp.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      f8f76481
    • I
      x86: fix DMI ioremap leak · 0d64484f
      Ingo Molnar 提交于
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      0d64484f
    • A
      x86: don't disable TSC in any C states on AMD Fam10h · ddb25f9a
      Andi Kleen 提交于
      The ACPI code currently disables TSC use in any C2 and C3
      states. But the AMD Fam10h BKDG documents that the TSC
      will never stop in any C states when the CONSTANT_TSC bit is
      set. Make this disabling conditional on CONSTANT_TSC
      not set on AMD.
      
      I actually think this is true on Intel too for C2 states
      on CPUs with p-state invariant TSC, but this needs
      further discussions with Len to really confirm :-)
      
      So far it is only enabled on AMD.
      
      Cc: lenb@kernel.org
      Signed-off-by: NAndi Kleen <ak@suse.de>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      ddb25f9a
    • A
      git-x86: drivers/pnp/pnpbios/bioscalls.c build fix · 39657b65
      Andrew Morton 提交于
      drivers/pnp/pnpbios/bioscalls.c:64: warning: (near initialization for 'bad_bios_desc.<anonymous>')
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      39657b65
    • V
      x86: voluntary leave_mm before entering ACPI C3 · bde6f5f5
      Venki Pallipadi 提交于
      Aviod TLB flush IPIs during C3 states by voluntary leave_mm()
      before entering C3.
      
      The performance impact of TLB flush on C3 should not be significant with
      respect to C3 wakeup latency. Also, CPUs tend to flush TLB in hardware while in
      C3 anyways.
      
      On a 8 logical CPU system, running make -j2, the number of tlbflush IPIs goes
      down from 40 per second to ~ 0. Total number of interrupts during the run
      of this workload was ~1200 per second, which makes it ~3% savings in wakeups.
      
      There was no measurable performance or power impact however.
      
      [ akpm@linux-foundation.org: symbol export fixes. ]
      Signed-off-by: NVenkatesh Pallipadi <venkatesh.pallipadi@intel.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      bde6f5f5
    • P
      x86: fix DMI out of memory problems · 79da4721
      Parag Warudkar 提交于
      People with HP Desktops (including me) encounter couple of DMI errors
      during boot - dmi_save_oem_strings_devices: out of memory and
      dmi_string: out of memory.
      
      On some HP desktops the DMI data include OEM strings (type 11) out of
      which only few are meaningful and most other are empty. DMI code
      religiously creates copies of these 27 strings (65 bytes each in my
      case) and goes OOM in dmi_string().
      
      If DMI_MAX_DATA is bumped up a little then it goes and fails in
      dmi_save_oem_strings while allocating dmi_devices of sizeof(struct
      dmi_device) corresponding to these strings.
      
      On x86_64 since we cannot use alloc_bootmem this early, the code uses a
      static array of 2048 bytes (DMI_MAX_DATA) for allocating the memory DMI
      needs. It does not survive the creation of empty strings and devices.
      
      Fix this by detecting and not newly allocating empty strings and instead
      using a one statically defined dmi_empty_string.
      
      Also do not create a new struct dmi_device for each empty string - use
      one statically define dmi_device with .name=dmi_empty_string and add
      that to the dmi_devices list.
      
      On x64 this should stop the OOM with same current size of DMI_MAX_DATA
      and on x86 this should save a good amount of (27*65 bytes +
      27*sizeof(struct dmi_device) bootmem.
      
      Compile and boot tested on both 32-bit and 64-bit x86.
      Signed-off-by: NParag Warudkar <parag.warudkar@gmail.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      79da4721
    • G
      x86: get rid of _MASK flags · 053de044
      Glauber de Oliveira Costa 提交于
      There's no need for the *_MASK flags (TF_MASK, IF_MASK, etc), found in
      processor.h (both _32 and _64). They have a one-to-one mapping with the
      EFLAGS value. This patch removes the definitions, and use the already
      existent X86_EFLAGS_ version when applicable.
      
      [ roland@redhat.com: KVM build fixes. ]
      Signed-off-by: NGlauber de Oliveira Costa <gcosta@redhat.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      053de044
    • I
      x86: replace outb_p() with udelay(2) in drivers/input/mouse/pc110pad.c · 41e191e8
      Ingo Molnar 提交于
      replace outb_p() with udelay(2). This is a real ISA device so it likely
      needs this particular delay.
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      41e191e8
    • G
      x86: unify struct desc_ptr · 6b68f01b
      Glauber de Oliveira Costa 提交于
      This patch unifies struct desc_ptr between i386 and x86_64.
      They can be expressed in the exact same way in C code, only
      having to change the name of one of them. As Xgt_desc_struct
      is ugly and big, this is the one that goes away.
      
      There's also a padding field in i386, but it is not really
      needed in the C structure definition.
      Signed-off-by: NGlauber de Oliveira Costa <gcosta@redhat.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      6b68f01b
    • I
      x86: clean up drivers/char/rtc.c · 5fd1fe9c
      Ingo Molnar 提交于
      tons of style cleanup in drivers/char/rtc.c - no code changed:
      
         text    data     bss     dec     hex filename
         6400     384      32    6816    1aa0 rtc.o.before
         6400     384      32    6816    1aa0 rtc.o.after
      
      since we seem to have a number of open breakages in this code we might
      as well start with making the code more readable and maintainable.
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      5fd1fe9c
    • H
      x86: use generic register name in the thread and tss structures · faca6227
      H. Peter Anvin 提交于
      This changes size-specific register names (eip/rip, esp/rsp, etc.) to
      generic names in the thread and tss structures.
      Signed-off-by: NH. Peter Anvin <hpa@zytor.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      faca6227
    • T
      x86: nuke a ton of dead hpet code · 02456c70
      Thomas Gleixner 提交于
      No users, just ballast
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      02456c70
    • B
      x86: assign IRQs to HPET timers, fix · 37a47db8
      Balaji Rao 提交于
      Looks like IRQ 31 is assigned to timer 3, even without the patch!
      I wonder who wrote the number 31. But the manual says that it is
      zero by default.
      
      I think we should check whether the timer has been allocated an IRQ before
      proceeding to assign one to it.  Here is a patch that does this.
      Signed-off-by: NBalaji Rao <balajirrao@gmail.com>
      Tested-by: NYinghai Lu <yhlu.kernel@gmail.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      37a47db8
    • B
      x86: assign IRQs to HPET timers · e3f37a54
      Balaji Rao 提交于
      The userspace API for the HPET (see Documentation/hpet.txt) did not work. The
      HPET_IE_ON ioctl was failing as there was no IRQ assigned to the timer
      device. This patch fixes it by allocating IRQs to timer blocks in the HPET.
      
      arch/x86/kernel/hpet.c |   13 +++++--------
      drivers/char/hpet.c    |   45 ++++++++++++++++++++++++++++++++++++++-------
      include/linux/hpet.h   |    2 +-
      3 files changed, 44 insertions(+), 16 deletions(-)
      Signed-off-by: NBalaji Rao <balajirrao@gmail.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      e3f37a54
    • L
      Mostly revert "e1000/e1000e: Move PCI-Express device IDs over to e1000e" · 5b10ca19
      Linus Torvalds 提交于
      The new e1000e driver is apparently not yet suitable for general use, so
      mark it experimental, and re-instate all the PCI-Express device IDs in
      the old and stable e1000 driver so that people (namely me) can continue
      to use a driver that actually works.
      
      Auke & co have been appraised of the situation.
      
      Cc: Auke Kok <auke-jan.h.kok@intel.com>
      Cc: Jeff Garzik <jeff@garzik.org>
      Cc: David Miller <davem@davemloft.net>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      5b10ca19
    • J
      cciss: fix bug in overriding ->data_len before completion · e7d9dc9c
      Jens Axboe 提交于
      For BLOCK_PC requests, we need that length for completing the request.
      Andrew Vasquez <andrew.vasquez@qlogic.com> reported the following
      oops
      
      Hitting a consistent BUG() with recent Linus' linux-2.6.git:
      
      	[   12.941428] ------------[ cut here ]------------
      	[   12.944874] kernel BUG at drivers/block/cciss.c:1260!
      	[   12.944874] invalid opcode: 0000 [1] SMP
      	[   12.944874] CPU 0
      	[   12.944874] Modules linked in:
      	[   12.944874] Pid: 0, comm: swapper Not tainted 2.6.24 #43
      	[   12.944874] RIP: 0010:[<ffffffff8039e43d>]  [<ffffffff8039e43d>] cciss_softirq_done+0xbc/0x1bf
      	[   12.944874] RSP: 0018:ffffffff8063aed0  EFLAGS: 00010202
      	[   12.944874] RAX: 0000000000000001 RBX: ffff8100cf800010 RCX: ffff81042f1253b0
      	[   12.944874] RDX: ffff81042de398f0 RSI: ffff81042de398f0 RDI: 0000000000000001
      	[   12.944874] RBP: ffff81042daa0000 R08: ffff81042f1253b0 R09: 0000000000000001
      	[   12.944874] R10: 00000000000000fe R11: 0000000000000000 R12: 0000000000000002
      	[   12.944874] R13: 0000000000000001 R14: ffff8100cf800000 R15: ffff81042de398f0
      	[   12.944874] FS:  0000000000000000(0000) GS:ffffffff805bb000(0000) knlGS:0000000000000000
      	[   12.944874] CS:  0010 DS: 0018 ES: 0018 CR0: 000000008005003b
      	[   12.944874] CR2: 00002afed7eea340 CR3: 000000042dbba000 CR4: 00000000000006e0
      	[   12.944874] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      	[   12.944874] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
      	[   12.944874] Process swapper (pid: 0, threadinfo ffffffff805f4000, task ffffffff805624a0)
      	[   12.944874] Stack:  0000000000000000 ffffffff8063af10 0000000000000001 ffffffff80632d60
      	[   12.944874]  0000000000000000 000000000000000a ffffffff805bb900 ffffffff8032038f
      	[   12.944874]  ffffffff8063af10 ffffffff8063af10 ffffffff805bb940 ffffffff802346b4
      	[   12.944874] Call Trace:
      	[   12.944874]  <IRQ>  [<ffffffff8032038f>] blk_done_softirq+0x69/0x78
      	[   12.944874]  [<ffffffff802346b4>] __do_softirq+0x6f/0xd8
      	[   12.944874]  [<ffffffff8020c45c>] call_softirq+0x1c/0x30
      	[   12.944874]  [<ffffffff8020e347>] do_softirq+0x30/0x80
      	[   12.944874]  [<ffffffff8020e409>] do_IRQ+0x72/0xd9
      	[   12.944874]  [<ffffffff8020a50a>] mwait_idle+0x0/0x46
      	[   12.944874]  [<ffffffff8020a3da>] default_idle+0x0/0x3d
      	[   12.944874]  [<ffffffff8020b7e1>] ret_from_intr+0x0/0xa
      	[   12.944874]  <EOI>  [<ffffffff8020a54c>] mwait_idle+0x42/0x46
      	[   12.944874]  [<ffffffff8020a481>] cpu_idle+0x6a/0xae
      	[   12.944874]
      	[   12.944874]
      	[   12.944874] Code: 0f 0b eb fe 48 8d 85 d8 c0 00 00 48 89 04 24 48 89 c7 e8 e5
      	[   12.944874] RIP  [<ffffffff8039e43d>] cciss_softirq_done+0xbc/0x1bf
      	[   12.944874]  RSP <ffffffff8063aed0>
      	[   12.944903] ---[ end trace e9c631603f90d22f ]---
      
      which is caused by blk_end_request() returning 'not done' for a request,
      since it gets asked to complete zero bytes.
      Signed-off-by: NJens Axboe <jens.axboe@oracle.com>
      e7d9dc9c
    • J
      xsysace: end request handling fix · 9bf72259
      Jens Axboe 提交于
      In ace_fsm_dostate(), the variable 'i' was used only for passing
      sector size of the request to end_that_request_first().
      So I removed it and changed the code to pass the size in bytes
      directly to __blk_end_request()
      Signed-off-by: NJens Axboe <jens.axboe@oracle.com>
      9bf72259
  3. 29 1月, 2008 1 次提交