1. 30 1月, 2008 5 次提交
    • H
      x86 boot : export boot_params via debugfs for debugging · 6d7d7433
      Huang, Ying 提交于
      This patch export the boot parameters via debugfs for debugging.
      
      The files added are as follow:
      
      boot_params/data    :  binary file for struct boot_params
      boot_params/version :  boot protocol version
      
      This patch is based on 2.6.24-rc5-mm1 and has been tested on i386 and
      x86_64 platform.
      
      This patch is based on the Peter Anvin's proposal.
      Signed-off-by: NHuang Ying <ying.huang@intel.com>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      6d7d7433
    • S
      x86: unify arch/x86/kernel/Makefile(s) · 6b0c3d44
      Sam Ravnborg 提交于
      Combine the 32 and 64 bit specific Makefiles in one file.
      While doing so link order was (almost) preserved on 32 bit
      but on 64 bit link order changed a lot.
      
      Patch was checked with defconfig + allyesconfig builds.
      The same .o files were linked in these configurations.
      
      To keep readability of the Makefiles a few Kconfig
      symbols was added/modified and it was checked that
      they were not used anywhere else.
      Signed-off-by: NSam Ravnborg <sam@ravnborg.org>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      6b0c3d44
    • I
      x86: make io_delay=0xed the default · d0049e71
      Ingo Molnar 提交于
      make io_delay=0xed the default. This frees up port 0x80 which is
      a debug port on some machines and locks up certain laptops.
      
      Testing only for now. Try the io_delay=0x80 boot option if this does not
      work for you.
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      d0049e71
    • I
      x86: various changes and cleanups to in_p/out_p delay details · 6e7c4025
      Ingo Molnar 提交于
      various changes to the in_p/out_p delay details:
      
      - add the io_delay=none method
      - make each method selectable from the kernel config
      - simplify the delay code a bit by getting rid of an indirect function call
      - add the /proc/sys/kernel/io_delay_type sysctl
      - change 'io_delay=standard|alternate' to io_delay=0x80 and io_delay=0xed
      - make the io delay config not depend on CONFIG_DEBUG_KERNEL
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Tested-by: N"David P. Reed" <dpreed@reed.com>
      6e7c4025
    • R
      x86: provide a DMI based port 0x80 I/O delay override. · b02aae9c
      Rene Herman 提交于
      x86: provide a DMI based port 0x80 I/O delay override.
      
      Certain (HP) laptops experience trouble from our port 0x80 I/O delay
      writes. This patch provides for a DMI based switch to the "alternate
      diagnostic port" 0xed (as used by some BIOSes as well) for these.
      
      David P. Reed confirmed that port 0xed works for him and provides a
      proper delay. The symptoms of _not_ working are a hanging machine,
      with "hwclock" use being a direct trigger.
      
      Earlier versions of this attempted to simply use udelay(2), with the
      2 being a value tested to be a nicely conservative upper-bound with
      help from many on the linux-kernel mailinglist but that approach has
      two problems.
      
      First, pre-loops_per_jiffy calibration (which is post PIT init while
      some implementations of the PIT are actually one of the historically
      problematic devices that need the delay) udelay() isn't particularly
      well-defined. We could initialise loops_per_jiffy conservatively (and
      based on CPU family so as to not unduly delay old machines) which
      would sort of work, but...
      
      Second, delaying isn't the only effect that a write to port 0x80 has.
      It's also a PCI posting barrier which some devices may be explicitly
      or implicitly relying on. Alan Cox did a survey and found evidence
      that additionally some drivers may be racy on SMP without the bus
      locking outb.
      
      Switching to an inb() makes the timing too unpredictable and as such,
      this DMI based switch should be the safest approach for now. Any more
      invasive changes should get more rigid testing first. It's moreover
      only very few machines with the problem and a DMI based hack seems
      to fit that situation.
      
      This also introduces a command-line parameter "io_delay" to override
      the DMI based choice again:
      
      	io_delay=<standard|alternate>
      
      where "standard" means using the standard port 0x80 and "alternate"
      port 0xed.
      
      This retains the udelay method as a config (CONFIG_UDELAY_IO_DELAY) and
      command-line ("io_delay=udelay") choice for testing purposes as well.
      
      This does not change the io_delay() in the boot code which is using
      the same port 0x80 I/O delay but those do not appear to be a problem
      as David P. Reed reported the problem was already gone after using the
      udelay version. He moreover reported that booting with "acpi=off" also
      fixed things and seeing as how ACPI isn't touched until after this DMI
      based I/O port switch I believe it's safe to leave the ones in the boot
      code be.
      
      The DMI strings from David's HP Pavilion dv9000z are in there already
      and we need to get/verify the DMI info from other machines with the
      problem, notably the HP Pavilion dv6000z.
      
      This patch is partly based on earlier patches from Pavel Machek and
      David P. Reed.
      Signed-off-by: NRene Herman <rene.herman@gmail.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      b02aae9c
  2. 30 10月, 2007 3 次提交
  3. 26 10月, 2007 1 次提交
  4. 30 7月, 2007 1 次提交
  5. 22 6月, 2007 1 次提交
  6. 21 6月, 2007 1 次提交
  7. 03 5月, 2007 1 次提交
  8. 13 2月, 2007 1 次提交
  9. 07 12月, 2006 1 次提交
    • R
      [PATCH] paravirt: Patch inline replacements for paravirt intercepts · 139ec7c4
      Rusty Russell 提交于
      It turns out that the most called ops, by several orders of magnitude,
      are the interrupt manipulation ops.  These are obvious candidates for
      patching, so mark them up and create infrastructure for it.
      
      The method used is that the ops structure has a patch function, which
      is called for each place which needs to be patched: this returns a
      number of instructions (the rest are NOP-padded).
      
      Usually we can spare a register (%eax) for the binary patched code to
      use, but in a couple of critical places in entry.S we can't: we make
      the clobbers explicit at the call site, and manually clobber the
      allowed registers in debug mode as an extra check.
      
      And:
      
      Don't abuse CONFIG_DEBUG_KERNEL, add CONFIG_DEBUG_PARAVIRT.
      
      And:
      
      AK:  Fix warnings in x86-64 alternative.c build
      
      And:
      
      AK: Fix compilation with defconfig
      
      And:
      
      ^From: Andrew Morton <akpm@osdl.org>
      
      Some binutlises still like to emit references to __stop_parainstructions and
      __start_parainstructions.
      
      And:
      
      AK: Fix warnings about unused variables when PARAVIRT is disabled.
      Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>
      Signed-off-by: NJeremy Fitzhardinge <jeremy@xensource.com>
      Signed-off-by: NChris Wright <chrisw@sous-sol.org>
      Signed-off-by: NZachary Amsden <zach@vmware.com>
      Signed-off-by: NAndi Kleen <ak@suse.de>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      139ec7c4
  10. 04 7月, 2006 2 次提交
  11. 19 4月, 2006 1 次提交
  12. 26 3月, 2006 2 次提交
  13. 23 3月, 2006 1 次提交
  14. 07 1月, 2006 1 次提交
  15. 07 11月, 2005 1 次提交
  16. 28 7月, 2005 1 次提交
  17. 17 4月, 2005 1 次提交
    • L
      Linux-2.6.12-rc2 · 1da177e4
      Linus Torvalds 提交于
      Initial git repository build. I'm not bothering with the full history,
      even though we have it. We can create a separate "historical" git
      archive of that later if we want to, and in the meantime it's about
      3.2GB when imported into git - space that would just make the early
      git days unnecessarily complicated, when we don't have a lot of good
      infrastructure for it.
      
      Let it rip!
      1da177e4