1. 18 7月, 2007 3 次提交
  2. 17 7月, 2007 1 次提交
    • H
      generic bug: use show_regs() instead of dump_stack() · 608e2619
      Heiko Carstens 提交于
      The current generic bug implementation has a call to dump_stack() in case a
      WARN_ON(whatever) gets hit.  Since report_bug(), which calls dump_stack(),
      gets called from an exception handler we can do better: just pass the
      pt_regs structure to report_bug() and pass it to show_regs() in case of a
      warning.  This will give more debug informations like register contents,
      etc...  In addition this avoids some pointless lines that dump_stack()
      emits, since it includes a stack backtrace of the exception handler which
      is of no interest in case of a warning.  E.g.  on s390 the following lines
      are currently always present in a stack backtrace if dump_stack() gets
      called from report_bug():
      
       [<000000000001517a>] show_trace+0x92/0xe8)
       [<0000000000015270>] show_stack+0xa0/0xd0
       [<00000000000152ce>] dump_stack+0x2e/0x3c
       [<0000000000195450>] report_bug+0x98/0xf8
       [<0000000000016cc8>] illegal_op+0x1fc/0x21c
       [<00000000000227d6>] sysc_return+0x0/0x10
      Acked-by: NJeremy Fitzhardinge <jeremy@goop.org>
      Acked-by: NHaavard Skinnemoen <hskinnemoen@atmel.com>
      Cc: Andi Kleen <ak@suse.de>
      Cc: Kyle McMartin <kyle@parisc-linux.org>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Paul Mundt <lethal@linux-sh.org>
      Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
      Signed-off-by: NHeiko Carstens <heiko.carstens@de.ibm.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      608e2619
  3. 22 6月, 2007 2 次提交
  4. 12 6月, 2007 1 次提交
    • G
      [PARISC] remove global_ack_eiem · 462b529f
      Grant Grundler 提交于
      Kudos to Thibaut Varene for spotting the (mis)use of appropriately named
      global_ack_eiem. This took a long time to figure out and both insight
      from myself, Kyle McMartin, and James Bottomley were required to narrow
      down which bit of code could have this race condition.
      
      The symptom was interrupts stopped getting delivered while some workload
      was generating IO interrupts on two different CPUs. One of the interrupt
      sources would get masked off and stay unmasked. Problem was global_ack_eiem
      was accessed with read/modified/write sequence and not protected by
      a spinlock.
      
      PA-RISC doesn't need a global ack flag though. External Interrupts
      are _always_ delivered to a single CPU (except for "global broadcast
      interrupt" which AFAIK currently is not used.) So we don't have to worry
      about any given IRQ vector getting delivered to more than one CPU.
      
      Tested on a500 and rp34xx boxen. rsync to/from gsyprf11 (a500)
      would lock up the box since NIC (tg3) interrupt and SCSI (sym2)
      were on "opposite" CPUs (2 CPU system). Put them on the same CPU
      or apply this patch and 10GB of data would rsync completely.
      
      Please apply the following critical patch.
      
      thanks,
      grant
      Signed-off-by: NGrant Grundler <grundler@parisc-linux.org>
      Acked-by: NThibaut VARENE <T-Bone@parisc-linux.org>
      Signed-off-by: NKyle McMartin <kyle@parisc-linux.org>
      462b529f
  5. 04 6月, 2007 2 次提交
    • K
      [PARISC] Fix kernel panic in check_ivt · c3d4ed4e
      Kyle McMartin 提交于
      check_ivt had some seriously broken code wrt function pointers on
      parisc64. Instead of referencing the hpmc code via a function pointer,
      export symbols and reference it as a const array.
      
      Thanks to jda for pointing out the broken 64-bit func ptr handling.
      Signed-off-by: NKyle McMartin <kyle@parisc-linux.org>
      c3d4ed4e
    • K
      [PARISC] Fix bug when syscall nr is __NR_Linux_syscalls · 3bb457af
      Kyle McMartin 提交于
      The bug was that we were comparing __NR_syscalls to be greater or equal
      to the syscall number stored in %r20. __NR_syscalls is one greater than
      the last syscall though, so we're loading one entry beyond the end of the
      syscall table, and trying to jump to it.
      
      Fix this by only checking that we're greater, alternatively, we could
      have compared to (__NR_Linux_syscalls - 1)
      Signed-off-by: NKyle McMartin <kyle@parisc-linux.org>
      3bb457af
  6. 30 5月, 2007 5 次提交
  7. 28 5月, 2007 2 次提交
  8. 23 5月, 2007 9 次提交
  9. 22 5月, 2007 1 次提交
    • A
      Detach sched.h from mm.h · e8edc6e0
      Alexey Dobriyan 提交于
      First thing mm.h does is including sched.h solely for can_do_mlock() inline
      function which has "current" dereference inside. By dealing with can_do_mlock()
      mm.h can be detached from sched.h which is good. See below, why.
      
      This patch
      a) removes unconditional inclusion of sched.h from mm.h
      b) makes can_do_mlock() normal function in mm/mlock.c
      c) exports can_do_mlock() to not break compilation
      d) adds sched.h inclusions back to files that were getting it indirectly.
      e) adds less bloated headers to some files (asm/signal.h, jiffies.h) that were
         getting them indirectly
      
      Net result is:
      a) mm.h users would get less code to open, read, preprocess, parse, ... if
         they don't need sched.h
      b) sched.h stops being dependency for significant number of files:
         on x86_64 allmodconfig touching sched.h results in recompile of 4083 files,
         after patch it's only 3744 (-8.3%).
      
      Cross-compile tested on
      
      	all arm defconfigs, all mips defconfigs, all powerpc defconfigs,
      	alpha alpha-up
      	arm
      	i386 i386-up i386-defconfig i386-allnoconfig
      	ia64 ia64-up
      	m68k
      	mips
      	parisc parisc-up
      	powerpc powerpc-up
      	s390 s390-up
      	sparc sparc-up
      	sparc64 sparc64-up
      	um-x86_64
      	x86_64 x86_64-up x86_64-defconfig x86_64-allnoconfig
      
      as well as my two usual configs.
      Signed-off-by: NAlexey Dobriyan <adobriyan@gmail.com>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      e8edc6e0
  10. 19 5月, 2007 2 次提交
  11. 10 5月, 2007 1 次提交
    • R
      rename thread_info to stack · f7e4217b
      Roman Zippel 提交于
      This finally renames the thread_info field in task structure to stack, so that
      the assumptions about this field are gone and archs have more freedom about
      placing the thread_info structure.
      
      Nonbroken archs which have a proper thread pointer can do the access to both
      current thread and task structure via a single pointer.
      
      It'll allow for a few more cleanups of the fork code, from which e.g.  ia64
      could benefit.
      Signed-off-by: NRoman Zippel <zippel@linux-m68k.org>
      [akpm@linux-foundation.org: build fix]
      Cc: Richard Henderson <rth@twiddle.net>
      Cc: Ivan Kokshaysky <ink@jurassic.park.msu.ru>
      Cc: Russell King <rmk@arm.linux.org.uk>
      Cc: Ian Molton <spyro@f2s.com>
      Cc: Haavard Skinnemoen <hskinnemoen@atmel.com>
      Cc: Mikael Starvik <starvik@axis.com>
      Cc: David Howells <dhowells@redhat.com>
      Cc: Yoshinori Sato <ysato@users.sourceforge.jp>
      Cc: "Luck, Tony" <tony.luck@intel.com>
      Cc: Hirokazu Takata <takata@linux-m32r.org>
      Cc: Geert Uytterhoeven <geert@linux-m68k.org>
      Cc: Roman Zippel <zippel@linux-m68k.org>
      Cc: Greg Ungerer <gerg@uclinux.org>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
      Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
      Cc: Paul Mundt <lethal@linux-sh.org>
      Cc: Kazumoto Kojima <kkojima@rr.iij4u.or.jp>
      Cc: Richard Curnow <rc@rc0.org.uk>
      Cc: William Lee Irwin III <wli@holomorphy.com>
      Cc: "David S. Miller" <davem@davemloft.net>
      Cc: Jeff Dike <jdike@addtoit.com>
      Cc: Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it>
      Cc: Miles Bader <uclinux-v850@lsi.nec.co.jp>
      Cc: Andi Kleen <ak@muc.de>
      Cc: Chris Zankel <chris@zankel.net>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      f7e4217b
  12. 09 5月, 2007 3 次提交
  13. 08 5月, 2007 1 次提交
  14. 03 5月, 2007 1 次提交
  15. 29 4月, 2007 1 次提交
    • J
      libata/IDE: remove combined mode quirk · 8cdfb29c
      Jeff Garzik 提交于
      Both old-IDE and libata should be able handle all controllers and
      devices found using normal resource reservation methods.
      
      This eliminates the awful, low-performing split-driver configuration
      where old-IDE drove the PATA portion of a PCI device, in PIO-only mode,
      and libata drove the SATA portion of the /same/ PCI device, in DMA mode.
      Typically vendors would ship SATA hard drive / PATA optical
      configuration, which would lend itself to slow (PIO-only) CD-ROM
      performance.
      
      For Intel users running in combined mode, it is now wholly dependent on
      your driver choice (potentially link order, if you compile both drivers
      in) whether old-IDE or libata will drive your hardware.
      
      In either case, you will get full performance from both SATA and PATA
      ports now, without having to pass a kernel command line parameter.
      Signed-off-by: NJeff Garzik <jeff@garzik.org>
      8cdfb29c
  16. 27 2月, 2007 5 次提交