1. 21 12月, 2006 1 次提交
    • A
      PCI: Fix multiple problems with VIA hardware · 1597cacb
      Alan Cox 提交于
      This patch is designed to fix:
      - Disk eating corruptor on KT7 after resume from RAM
      - VIA IRQ handling
      - VIA fixups for bus lockups after resume from RAM
      
      The core of this is to add a table of resume fixups run at resume time.
      We need to do this for a variety of boards and features, but particularly
      we need to do this to get various critical VIA fixups done on resume.
      
      The second part of the problem is to handle VIA IRQ number rules which
      are a bit odd and need special handling for PIC interrupts. Various
      patches broke various boxes and while this one may not be perfect
      (hopefully it is) it ensures the workaround is applied to the right
      devices only.
      
      From: Jean Delvare <khali@linux-fr.org>
      
      Now that PCI quirks are replayed on software resume, we can safely
      re-enable the Asus SMBus unhiding quirk even when software suspend support
      is enabled.
      
      [akpm@osdl.org: fix const warning]
      Signed-off-by: NAlan Cox <alan@redhat.com>
      Cc: Jean Delvare <khali@linux-fr.org>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      1597cacb
  2. 16 12月, 2006 1 次提交
    • L
      Remove stack unwinder for now · d1526e2c
      Linus Torvalds 提交于
      It has caused more problems than it ever really solved, and is
      apparently not getting cleaned up and fixed.  We can put it back when
      it's stable and isn't likely to make warning or bug events worse.
      
      In the meantime, enable frame pointers for more readable stack traces.
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      d1526e2c
  3. 12 12月, 2006 1 次提交
  4. 09 12月, 2006 1 次提交
    • J
      [PATCH] Generic BUG implementation · 7664c5a1
      Jeremy Fitzhardinge 提交于
      This patch adds common handling for kernel BUGs, for use by architectures as
      they wish.  The code is derived from arch/powerpc.
      
      The advantages of having common BUG handling are:
       - consistent BUG reporting across architectures
       - shared implementation of out-of-line file/line data
       - implement CONFIG_DEBUG_BUGVERBOSE consistently
      
      This means that in inline impact of BUG is just the illegal instruction
      itself, which is an improvement for i386 and x86-64.
      
      A BUG is represented in the instruction stream as an illegal instruction,
      which has file/line information associated with it.  This extra information is
      stored in the __bug_table section in the ELF file.
      
      When the kernel gets an illegal instruction, it first confirms it might
      possibly be from a BUG (ie, in kernel mode, the right illegal instruction).
      It then calls report_bug().  This searches __bug_table for a matching
      instruction pointer, and if found, prints the corresponding file/line
      information.  If report_bug() determines that it wasn't a BUG which caused the
      trap, it returns BUG_TRAP_TYPE_NONE.
      
      Some architectures (powerpc) implement WARN using the same mechanism; if the
      illegal instruction was the result of a WARN, then report_bug(Q) returns
      CONFIG_DEBUG_BUGVERBOSE; otherwise it returns BUG_TRAP_TYPE_BUG.
      
      lib/bug.c keeps a list of loaded modules which can be searched for __bug_table
      entries.  The architecture must call
      module_bug_finalize()/module_bug_cleanup() from its corresponding
      module_finalize/cleanup functions.
      
      Unsetting CONFIG_DEBUG_BUGVERBOSE will reduce the kernel size by some amount.
      At the very least, filename and line information will not be recorded for each
      but, but architectures may decide to store no extra information per BUG at
      all.
      
      Unfortunately, gcc doesn't have a general way to mark an asm() as noreturn, so
      architectures will generally have to include an infinite loop (or similar) in
      the BUG code, so that gcc knows execution won't continue beyond that point.
      gcc does have a __builtin_trap() operator which may be useful to achieve the
      same effect, unfortunately it cannot be used to actually implement the BUG
      itself, because there's no way to get the instruction's address for use in
      generating the __bug_table entry.
      
      [randy.dunlap@oracle.com: Handle BUG=n, GENERIC_BUG=n to prevent build errors]
      [bunk@stusta.de: include/linux/bug.h must always #include <linux/module.h]
      Signed-off-by: NJeremy Fitzhardinge <jeremy@goop.org>
      Cc: Andi Kleen <ak@muc.de>
      Cc: Hugh Dickens <hugh@veritas.com>
      Cc: Michael Ellerman <michael@ellerman.id.au>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Rusty Russell <rusty@rustcorp.com.au>
      Signed-off-by: NAdrian Bunk <bunk@stusta.de>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      7664c5a1
  5. 07 12月, 2006 2 次提交
    • J
      [PATCH] unwinder: move .eh_frame to RODATA · b65780e1
      Jan Beulich 提交于
      The .eh_frame section contents is never written to, so it can as well
      benefit from CONFIG_DEBUG_RODATA.
      
      Diff-ed against firstfloor tree.
      Signed-off-by: NJan Beulich <jbeulich@novell.com>
      Signed-off-by: NAndi Kleen <ak@suse.de>
      b65780e1
    • V
      [PATCH] i386: Distinguish absolute symbols · 6569580d
      Vivek Goyal 提交于
      Ld knows about 2 kinds of symbols,  absolute and section
      relative.  Section relative symbols symbols change value
      when a section is moved and absolute symbols do not.
      
      Currently in the linker script we have several labels
      marking the beginning and ending of sections that
      are outside of sections, making them absolute symbols.
      Having a mixture of absolute and section relative
      symbols refereing to the same data is currently harmless
      but it is confusing.
      
      This must be done carefully as newer revs of ld do not place
      symbols that appear in sections without data and instead
      ld makes those symbols global :(
      
      My ultimate goal is to build a relocatable kernel.  The
      safest and least intrusive technique is to generate
      relocation entries so the kernel can be relocated at load
      time.  The only penalty would be an increase in the size
      of the kernel binary.  The problem is that if absolute and
      relocatable symbols are not properly specified absolute symbols
      will be relocated or section relative symbols won't be, which
      is fatal.
      
      The practical motivation is that when generating kernels that
      will run from a reserved area for analyzing what caused
      a kernel panic, it is simpler if you don't need to hard code
      the physical memory location they will run at, especially
      for the distributions.
      
      [AK: and merged:]
      
      o Also put a message so that in future people can be aware of it and
        avoid introducing absolute symbols.
      Signed-off-by: NEric W. Biederman <ebiederm@xmission.com>
      Signed-off-by: NVivek Goyal <vgoyal@in.ibm.com>
      Signed-off-by: NAndi Kleen <ak@suse.de>
      6569580d
  6. 21 11月, 2006 1 次提交
    • L
      Add "pure_initcall" for static variable initialization · b3438f82
      Linus Torvalds 提交于
      This is a quick hack to overcome the fact that SRCU currently does not
      allow static initializers, and we need to sometimes initialize those
      things before any other initializers (even "core" ones) can do so.
      
      Currently we don't allow this at all for modules, and the only user that
      needs is right now is cpufreq. As reported by Thomas Gleixner:
      
         "Commit b4dfdbb3 ("[PATCH] cpufreq:
          make the transition_notifier chain use SRCU breaks cpu frequency
          notification users, which register the callback > on core_init
          level."
      
      Cc: Thomas Gleixner <tglx@timesys.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Arjan van de Ven <arjan@infradead.org>
      Cc: Andrew Morton <akpm@osdl.org>,
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      b3438f82
  7. 28 10月, 2006 2 次提交
  8. 22 10月, 2006 1 次提交
    • J
      [PATCH] x86-64: Speed up dwarf2 unwinder · 690a973f
      Jan Beulich 提交于
      This changes the dwarf2 unwinder to do a binary search for CIEs
      instead of a linear work. The linker is unfortunately not
      able to build a proper lookup table at link time, instead it creates
      one at runtime as soon as the bootmem allocator is usable (so you'll continue
      using the linear lookup for the first [hopefully] few calls).
      The code should be ready to utilize a build-time created table once
      a fixed linker becomes available.
      Signed-off-by: NJan Beulich <jbeulich@novell.com>
      Signed-off-by: NAndi Kleen <ak@suse.de>
      690a973f
  9. 27 9月, 2006 1 次提交
  10. 26 9月, 2006 1 次提交
    • J
      [PATCH] x86: put .note.* sections into a PT_NOTE segment in vmlinux · 9c9b8b38
      Jeremy Fitzhardinge 提交于
      This patch will pack any .note.* section into a PT_NOTE segment in the output
      file.
      
      To do this, we tell ld that we need a PT_NOTE segment.  This requires us to
      start explicitly mapping sections to segments, so we also need to explicitly
      create PT_LOAD segments for text and data, and map the sections to them
      appropriately.  Fortunately, each section will default to its previous
      section's segment, so it doesn't take many changes to vmlinux.lds.S.
      
      This only changes i386 for now, but I presume the corresponding changes for
      other architectures will be as simple.
      
      This change also adds <linux/elfnote.h>, which defines C and Assembler macros
      for actually creating ELF notes.
      Signed-off-by: NJeremy Fitzhardinge <jeremy@xensource.com>
      Cc: Eric W. Biederman <ebiederm@xmission.com>
      Cc: Hollis Blanchard <hollisb@us.ibm.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      9c9b8b38
  11. 29 6月, 2006 1 次提交
  12. 21 3月, 2006 1 次提交
  13. 07 1月, 2006 1 次提交
  14. 07 11月, 2005 1 次提交
  15. 11 9月, 2005 1 次提交
    • P
      [PATCH] i386 / uml: add dwarf sections to static link script · a7d0c210
      Paolo 'Blaisorblade' Giarrusso 提交于
      Inside the linker script, insert the code for DWARF debug info sections. This
      may help GDB'ing a Uml binary. Actually, it seems that ld is able to guess
      what I added correctly, but normal linker scripts include this section so it
      should be correct anyway adding it.
      
      On request by Sam Ravnborg <sam@ravnborg.org>, I've added it to
      asm-generic/vmlinux.lds.s. I've also moved there the stabs debug section,
      used the new macro in i386 linker script and added DWARF debug section to
      that.
      
      In the truth, I've not been able to verify the difference in GDB behaviour
      after this change (I've seen large improvements with another patch). This
      may depend on my binutils version, older one may have worse defaults.
      
      However, this section is present in normal linker script, so add it at
      least for the sake of cleanness.
      Signed-off-by: NPaolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it>
      Acked-by: NSam Ravnborg <sam@ravnborg.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      a7d0c210
  16. 08 9月, 2005 1 次提交
    • P
      [PATCH] Kprobes: prevent possible race conditions generic · d0aaff97
      Prasanna S Panchamukhi 提交于
      There are possible race conditions if probes are placed on routines within the
      kprobes files and routines used by the kprobes.  For example if you put probe
      on get_kprobe() routines, the system can hang while inserting probes on any
      routine such as do_fork().  Because while inserting probes on do_fork(),
      register_kprobes() routine grabs the kprobes spin lock and executes
      get_kprobe() routine and to handle probe of get_kprobe(), kprobes_handler()
      gets executed and tries to grab kprobes spin lock, and spins forever.  This
      patch avoids such possible race conditions by preventing probes on routines
      within the kprobes file and routines used by kprobes.
      
      I have modified the patches as per Andi Kleen's suggestion to move kprobes
      routines and other routines used by kprobes to a seperate section
      .kprobes.text.
      
      Also moved page fault and exception handlers, general protection fault to
      .kprobes.text section.
      
      These patches have been tested on i386, x86_64 and ppc64 architectures, also
      compiled on ia64 and sparc64 architectures.
      Signed-off-by: NPrasanna S Panchamukhi <prasanna@in.ibm.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      d0aaff97
  17. 15 7月, 2005 1 次提交
    • S
      kbuild: Avoid inconsistent kallsyms data · 6d30e3a8
      Sam Ravnborg 提交于
      Several reports on inconsistent kallsyms data has been caused by the aliased symbols
      __sched_text_start and __down to shift places in the output of nm.
      The root cause was that on second pass ld aligned __sched_text_start to a 4 byte boundary
      which is the function alignment on i386.
      sched.text and spinlock.text is now aligned to an 8 byte boundary to make sure they
      are aligned to a function alignemnt on most (all?) archs.
      
      Tested by: Paulo Marques <pmarques@grupopie.com>
      Tested by: Alexander Stohr <Alexander.Stohr@gmx.de>
      Signed-off-by: NSam Ravnborg <sam@ravnborg.org>
      6d30e3a8
  18. 26 6月, 2005 1 次提交
  19. 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