1. 25 8月, 2005 2 次提交
  2. 20 8月, 2005 1 次提交
    • S
      [PATCH] Mobil Pentium 4 HT and the NMI · cd3716ab
      Steven Rostedt 提交于
      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: NSteven Rostedt <rostedt@goodmis.org>
      Acked-by: NZwane Mwaikambo <zwane@arm.linux.org.uk>
      Acked-by: NMikael Pettersson <mikpe@csd.uu.se>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      cd3716ab
  3. 19 8月, 2005 1 次提交
  4. 05 8月, 2005 3 次提交
  5. 02 8月, 2005 3 次提交
    • A
      [PATCH] transmeta: CONFIG_PROC_FS=n build fix · 39bbb07d
      Andrew Morton 提交于
      Fix bug found by Grant Coady <lkml@dodo.com.au>'s autobuild setup.
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      39bbb07d
    • E
      [PATCH] disable addres space randomization default on transmeta CPUs · cdf32eaa
      Eric Lammerts 提交于
      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: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      cdf32eaa
    • I
      [PATCH] remove sys_set_zone_reclaim() · 6cb54819
      Ingo Molnar 提交于
      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: NIngo Molnar <mingo@elte.hu>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      6cb54819
  6. 30 7月, 2005 5 次提交
  7. 29 7月, 2005 5 次提交
  8. 28 7月, 2005 2 次提交
  9. 27 7月, 2005 5 次提交
  10. 23 7月, 2005 3 次提交
    • L
      Remove "noreplacement" kernel command line option. · 72538d85
      Linus Torvalds 提交于
      It is no longer valid to not replace instructions, since we depend on
      different behaviour depending on CPU capabilities.
      
      If you need to limit the capabilities of the replacements (because the
      boot CPU has features that non-boot CPU's do not have, for example), you
      need to explicitly disable those capabilities that are not shared across
      all CPU's.
      
      For example, if your boot CPU has FXSR, but other CPU's in your system
      do not, you need to use the "nofxsr" kernel command line, not disable
      instruction replacement per se.
      72538d85
    • L
      x86: make restore_fpu() use alternative assembler instructions · 8ed1383f
      Linus Torvalds 提交于
      It's really just a single instruction, conditional on whether the CPU
      supports FXSR or not, so implement it as such instead of making it a
      function that queries FXSR dynamically.
      
      This means that the instruction just gets automatically rewritten to the
      correct one at boot-time.
      8ed1383f
    • L
      Fix up incorrect "unlikely()" on %gs reload in x86 __switch_to · b339a18b
      Linus Torvalds 提交于
      These days %gs is normally the TLS segment, so it's no longer zero.  As
      a result, we shouldn't just assume that %fs/%gs tend to be zero
      together, but test them independently instead.
      
      Also, fix setting of debug registers to use the "next" pointer instead
      of "current".  It so happens that the scheduler will have set the new
      current pointer before calling __switch_to(), but that's just an
      implementation detail.
      b339a18b
  11. 13 7月, 2005 1 次提交
    • R
      [PATCH] inotify · 0eeca283
      Robert Love 提交于
      inotify is intended to correct the deficiencies of dnotify, particularly
      its inability to scale and its terrible user interface:
      
              * dnotify requires the opening of one fd per each directory
                that you intend to watch. This quickly results in too many
                open files and pins removable media, preventing unmount.
              * dnotify is directory-based. You only learn about changes to
                directories. Sure, a change to a file in a directory affects
                the directory, but you are then forced to keep a cache of
                stat structures.
              * dnotify's interface to user-space is awful.  Signals?
      
      inotify provides a more usable, simple, powerful solution to file change
      notification:
      
              * inotify's interface is a system call that returns a fd, not SIGIO.
      	  You get a single fd, which is select()-able.
              * inotify has an event that says "the filesystem that the item
                you were watching is on was unmounted."
              * inotify can watch directories or files.
      
      Inotify is currently used by Beagle (a desktop search infrastructure),
      Gamin (a FAM replacement), and other projects.
      
      See Documentation/filesystems/inotify.txt.
      Signed-off-by: NRobert Love <rml@novell.com>
      Cc: John McCutchan <ttb@tentacle.dhs.org>
      Cc: Christoph Hellwig <hch@lst.de>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      0eeca283
  12. 12 7月, 2005 2 次提交
  13. 08 7月, 2005 2 次提交
  14. 06 7月, 2005 1 次提交
  15. 02 7月, 2005 1 次提交
    • G
      [PATCH] PCI: clean up dynamic pci id logic · 75865858
      Greg Kroah-Hartman 提交于
      The dynamic pci id logic has been bothering me for a while, and now that
      I started to look into how to move some of this to the driver core, I
      thought it was time to clean it all up.
      
      It ends up making the code smaller, and easier to follow, and fixes a
      few bugs at the same time (dynamic ids were not being matched
      everywhere, and so could be missed on some call paths for new devices,
      semaphore not needed to be grabbed when adding a new id and calling the
      driver core, etc.)
      
      I also renamed the function pci_match_device() to pci_match_id() as
      that's what it really does.
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      75865858
  16. 30 6月, 2005 1 次提交
  17. 28 6月, 2005 2 次提交
    • G
      [PATCH] PCI: add proper MCFG table parsing to ACPI core. · 54549391
      Greg Kroah-Hartman 提交于
      This patch is the first step in properly handling the MCFG PCI table.
      It defines the structures properly, and saves off the table so that the
      pci mmconfig code can access it.  It moves the parsing of the table a
      little later in the boot process, but still before the information is
      needed.
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      54549391
    • K
      [PATCH] ACPI based I/O APIC hot-plug: add interfaces · b1bb248a
      Kenji Kaneshige 提交于
      This patch adds the following new interfaces for I/O xAPIC
      hotplug. The implementation of these interfaces depends on each
      architecture.
      
          o int acpi_register_ioapic(acpi_handle handle, u64 phys_addr,
      			       u32 gsi_base);
      
              This new interface is to add a new I/O xAPIC specified by
              phys_addr and gsi_base pair. phys_addr is the physical address
              to which the I/O xAPIC is mapped and gsi_base is global system
              interrupt base of the I/O xAPIC. acpi_register_ioapic returns
              0 on success, or negative value on error.
      
          o int acpi_unregister_ioapic(acpi_handle handle, u32 gsi_base);
      
              This new interface is to remove a I/O xAPIC specified by
              gsi_base. acpi_unregister_ioapic returns 0 on success, or
              negative value on error.
      Signed-off-by: NKenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      b1bb248a