1. 03 Sep, 2009 1 commit
    • David S. Miller's avatar
      sparc64: Kill spurious NMI watchdog triggers by increasing limit to 30 seconds. · e6617c6e
      David S. Miller authored
      This is a compromise and a temporary workaround for bootup NMI
      watchdog triggers some people see with qla2xxx devices present.
      
      This happens when, for example:
      
      CPU 0 is in the driver init and looping submitting mailbox commands to
      load the firmware, then waiting for completion.
      
      CPU 1 is receiving the device interrupts.  CPU 1 is where the NMI
      watchdog triggers.
      
      CPU 0 is submitting mailbox commands fast enough that by the time CPU
      1 returns from the device interrupt handler, a new one is pending.
      This sequence runs for more than 5 seconds.
      
      The problematic case is CPU 1's timer interrupt running when the
      barrage of device interrupts begin.  Then we have:
      
      	timer interrupt
      	return for softirq checking
      	pending, thus enable interrupts
      
      		 qla2xxx interrupt
      		 return
      		 qla2xxx interrupt
      		 return
      		 ... 5+ seconds pass
      		 final qla2xxx interrupt for fw load
      		 return
      
      	run timer softirq
      	return
      
      At some point in the multi-second qla2xxx interrupt storm we trigger
      the NMI watchdog on CPU 1 from the NMI interrupt handler.
      
      The timer softirq, once we get back to running it, is smart enough to
      run the timer work enough times to make up for the missed timer
      interrupts.
      
      However, the NMI watchdogs (both x86 and sparc) use the timer
      interrupt count to notice the cpu is wedged.  But in the above
      scenerio we'll receive only one such timer interrupt even if we last
      all the way back to running the timer softirq.
      
      The default watchdog trigger point is only 5 seconds, which is pretty
      low (the softwatchdog triggers at 60 seconds).  So increase it to 30
      seconds for now.
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      e6617c6e
  2. 25 Aug, 2009 1 commit
    • David S. Miller's avatar
      sparc64: Validate linear D-TLB misses. · d8ed1d43
      David S. Miller authored
      When page alloc debugging is not enabled, we essentially accept any
      virtual address for linear kernel TLB misses.  But with kgdb, kernel
      address probing, and other facilities we can try to access arbitrary
      crap.
      
      So, make sure the address we miss on will translate to physical memory
      that actually exists.
      
      In order to make this work we have to embed the valid address bitmap
      into the kernel image.  And in order to make that less expensive we
      make an adjustment, in that the max physical memory address is
      decreased to "1 << 41", even on the chips that support a 42-bit
      physical address space.  We can do this because bit 41 indicates
      "I/O space" and thus covers non-memory ranges.
      
      The result of this is that:
      
      1) kpte_linear_bitmap shrinks from 2K to 1K in size
      
      2) we need 64K more for the valid address bitmap
      
      We can't let the valid address bitmap be dynamically allocated
      once we start using it to validate TLB misses, otherwise we have
      crazy issues to deal with wrt. recursive TLB misses and such.
      
      If we're in a TLB miss it could be the deepest trap level that's legal
      inside of the cpu.  So if we TLB miss referencing the bitmap, the cpu
      will be out of trap levels and enter RED state.
      
      To guard against out-of-range accesses to the bitmap, we have to check
      to make sure no bits in the physical address above bit 40 are set.  We
      could export and use last_valid_pfn for this check, but that's just an
      unnecessary extra memory reference.
      
      On the plus side of all this, since we load all of these translations
      into the special 4MB mapping TSB, and we check the TSB first for TLB
      misses, there should be absolutely no real cost for these new checks
      in the TLB miss path.
      
      Reported-by: heyongli@gmail.com
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      d8ed1d43
  3. 19 Aug, 2009 4 commits
  4. 03 Aug, 2009 1 commit
  5. 28 Jul, 2009 1 commit
  6. 17 Jul, 2009 1 commit
  7. 26 Jun, 2009 6 commits
  8. 24 Jun, 2009 25 commits