1. 30 8月, 2005 2 次提交
    • D
      [SPARC64]: Fix trap state reading for instruction_access_exception. · 5ea68e02
      David S. Miller 提交于
      1) Read ASI_IMMU SFSR not ASI_DMMU.
      2) IMMU has no SFAR, read TPC instead
      3) Delete old and incorrect comment about the DTLB protection
         trap having a dependency on the SFSR contents in order to
         function correctly
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      5ea68e02
    • S
      [PATCH] convert signal handling of NODEFER to act like other Unix boxes. · 69be8f18
      Steven Rostedt 提交于
      It has been reported that the way Linux handles NODEFER for signals is
      not consistent with the way other Unix boxes handle it.  I've written a
      program to test the behavior of how this flag affects signals and had
      several reports from people who ran this on various Unix boxes,
      confirming that Linux seems to be unique on the way this is handled.
      
      The way NODEFER affects signals on other Unix boxes is as follows:
      
      1) If NODEFER is set, other signals in sa_mask are still blocked.
      
      2) If NODEFER is set and the signal is in sa_mask, then the signal is
      still blocked. (Note: this is the behavior of all tested but Linux _and_
      NetBSD 2.0 *).
      
      The way NODEFER affects signals on Linux:
      
      1) If NODEFER is set, other signals are _not_ blocked regardless of
      sa_mask (Even NetBSD doesn't do this).
      
      2) If NODEFER is set and the signal is in sa_mask, then the signal being
      handled is not blocked.
      
      The patch converts signal handling in all current Linux architectures to
      the way most Unix boxes work.
      
      Unix boxes that were tested:  DU4, AIX 5.2, Irix 6.5, NetBSD 2.0, SFU
      3.5 on WinXP, AIX 5.3, Mac OSX, and of course Linux 2.6.13-rcX.
      
      * NetBSD was the only other Unix to behave like Linux on point #2. The
      main concern was brought up by point #1 which even NetBSD isn't like
      Linux.  So with this patch, we leave NetBSD as the lonely one that
      behaves differently here with #2.
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      69be8f18
  2. 29 8月, 2005 1 次提交
  3. 28 8月, 2005 1 次提交
    • A
      [PATCH] mmaper_kern.c fixes [buffer overruns] · 6a029a90
      Al Viro 提交于
       - copy_from_user() can fail; ->write() must check its return value.
      
       - severe buffer overruns both in ->read() and ->write() - lseek to the
         end (i.e.  to mmapper_size) and
      
      	if (count + *ppos > mmapper_size)
      		count = count + *ppos - mmapper_size;
      
         will do absolutely nothing.  Then it will call
      
      	copy_to_user(buf,&v_buf[*ppos],count);
      
         with obvious results (similar for ->write()).
      
         Fixed by turning read to simple_read_from_buffer() and by doing
         normal limiting of count in ->write().
      
       - gratitious lock_kernel() in ->mmap() - it's useless there.
      
       - lots of gratuitous includes.
      Signed-off-by: NAl Viro <viro@parcelfarce.linux.theplanet.co.uk>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      6a029a90
  4. 27 8月, 2005 3 次提交
  5. 25 8月, 2005 3 次提交
  6. 24 8月, 2005 18 次提交
  7. 23 8月, 2005 2 次提交
  8. 20 8月, 2005 5 次提交
    • A
      [PATCH] x86_64: Fix race in TSC synchronization · 1eecd73c
      Andi Kleen 提交于
      Plug a race in TSC synchronization
      
      We need to do tsc_sync_wait() before the CPU is set online to prevent
      multiple CPUs from doing it in parallel - which won't work because TSC
      sync has global unprotected state.
      Signed-off-by: NAndi Kleen <ak@suse.de>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      1eecd73c
    • A
      [PATCH] x86_64: Don't print exceptions for ltrace · 5e5ec104
      Andi Kleen 提交于
      Don't printk exceptions for ltrace
      Signed-off-by: NAndi Kleen <ak@suse.de>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      5e5ec104
    • 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
    • A
      [SPARC]: Fix weak aliases · 83c4e437
      Al Viro 提交于
      sparc_ksyms.c used to declare weak alias to several gcc intrinsics.  It
      doesn't work with gcc4 anymore - it wants a declaration for the thing
      we are aliasing to and that's not going to happen for something like
      .mul, etc.  Replaced with direct injection of weak alias on the assembler
      level - .weak <alias> followed by <alias> = <aliased>; that works on all
      gcc versions.
      Signed-off-by: NAl Viro <viro@parcelfarce.linux.theplanet.co.uk>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      83c4e437
    • D
      [SPARC64]: Move kernel unaligned trap handlers into assembler file. · a3f99858
      David S. Miller 提交于
      GCC 4.x really dislikes the games we are playing in
      unaligned.c, and the cleanest way to fix this is to
      move things into assembler.
      
      Noted by Al Viro.
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      a3f99858
  9. 19 8月, 2005 5 次提交