1. 20 Aug, 2005 4 commits
    • Steven Rostedt's avatar
      [PATCH] Mobil Pentium 4 HT and the NMI · cd3716ab
      Steven Rostedt authored
      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: default avatarSteven Rostedt <rostedt@goodmis.org>
      Acked-by: default avatarZwane Mwaikambo <zwane@arm.linux.org.uk>
      Acked-by: default avatarMikael Pettersson <mikpe@csd.uu.se>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      cd3716ab
    • Al Viro's avatar
      [PATCH] Fix up symlink function pointers · 008b150a
      Al Viro authored
      This fixes up the symlink functions for the calling convention change:
      
       * afs, autofs4, befs, devfs, freevxfs, jffs2, jfs, ncpfs, procfs,
         smbfs, sysvfs, ufs, xfs - prototype change for ->follow_link()
       * befs, smbfs, xfs - same for ->put_link()
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      008b150a
    • Linus Torvalds's avatar
      Fix nasty ncpfs symlink handling bug. · cc314eef
      Linus Torvalds authored
      This bug could cause oopses and page state corruption, because ncpfs
      used the generic page-cache symlink handlign functions.  But those
      functions only work if the page cache is guaranteed to be "stable", ie a
      page that was installed when the symlink walk was started has to still
      be installed in the page cache at the end of the walk.
      
      We could have fixed ncpfs to not use the generic helper routines, but it
      is in many ways much cleaner to instead improve on the symlink walking
      helper routines so that they don't require that absolute stability.
      
      We do this by allowing "follow_link()" to return a error-pointer as a
      cookie, which is fed back to the cleanup "put_link()" routine.  This
      also simplifies NFS symlink handling.
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      cc314eef
    • Al Viro's avatar
      [PATCH] jffs2: fix symlink error handling · 2fb1e308
      Al Viro authored
      The current calling conventions for ->follow_link() are already fairly
      complex.
      
      What we have is
      	1) you can return -error; then you must release nameidata yourself
      	   and ->put_link() will _not_ be called.
      	2) you can do nd_set_link(nd, ERR_PTR(-error)) and return 0
      	3) you can do nd_set_link(nd, path) and return 0
      	4) you can return 0 (after having moved nameidata yourself)
      
      jffs2 follow_link() is broken - it has an exit where it returns
      -EIO and leaks nameidata.
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      2fb1e308
  2. 18 Aug, 2005 34 commits
  3. 17 Aug, 2005 2 commits