1. 06 Jun, 2003 9 commits
    • Andrew Morton's avatar
      [PATCH] Console blanking fix · 520aa095
      Andrew Morton authored
      From: Samuel Thibault <Samuel.Thibault@ens-lyon.fr>
      
      Some fixes for console blanking: on some laptops, doing VESA blanking after
      the bios did an apm blanking because of a screen closure thrashes the
      recovery (the video board doesn't seem to have synchronisation registers
      correctly initialized, since the LCD panel progressively turns white, maybe
      damaging it ?).
      
      I hence moved the schedule for vesa powerdown after the apm blank hook
      call, so that if it succeeds, it won't be called.  I also moved the apm
      unblank & palette restoration after the vesa unblank, to have a more lifo
      scheme (also required, or the screen remains black).
      
      Btw, why del_timer_sync was called twice in timer_do_blank_screen when
      vesa_off_interval==0 ?
      520aa095
    • Andrew Morton's avatar
      [PATCH] fix wobbly /proc/stat:btime · daee4676
      Andrew Morton authored
      From: john stultz <johnstul@us.ibm.com>
      
      Since jiffies didn't necessarily start incrementing at a second boundary,
      jiffies/HZ doesn't increment at the same moment as xtime.tv_sec.  This
      causes one second wobbles in the calculation of btime (xtime.tv_sec -
      jiffies/HZ).
      
      This fix increases the precision of the calculation so the usec component
      of xtime is used as well.  Additionally it fixes some of the non-atomic
      reading of time values.
      daee4676
    • Andrew Morton's avatar
      [PATCH] force_successful_syscall_return() · a4369a58
      Andrew Morton authored
      From: David Mosberger <davidm@napali.hpl.hp.com>, Christoph Hellwig
      
      I believe this is the last outstanding piece that prevents ia64 from being
      fully in sync with Linus' tree (yes, there are some minor ACPI changes
      outstanding and a toolchain bug that's left to fix, but other than that, I
      think we're clean).
      
      Many architectures (alpha, ia64, ppc, ppc64, sparc, and sparc64 at least)
      use a syscall convention which provides for a return value and a separate
      error flag.  On those architectures, it can be beneficial if the kernel
      provides a mechanism to signal that a syscall call has completed
      successfully, even when the returned value is potentially a (small)
      negative number.  The patch below provides a hook for such a mechanism via
      a macro called force_successful_syscall_return().  On x86, this would be
      simply a no-op (because on x86, user-level has to be hacked to handle such
      cases).  On Alpha, it would be something along the lines of:
      
       #define force_successful_syscall_return()  ptregs->r0 = 0
      
      where "ptregs" is a pointer to the user's ptregs structure of the current
      task.  On ia64, we have been using this for a long time:
      
       static inline void force_successful_syscall_return (void) {
      	ia64_task_regs(current)->r8 = 0;
       }
      
      The other architectures (ppc, ppc64, sparc, and sparc64) currently have no
      mechanism to force a syscall return to be successful.  But since the
      syscall convention already provide for a separate error flag, the arch
      maintainers could change this if they wanted to.
      
      There are only 3 places in the platform-independent portion of the kernel
      that need this macro:
      
       - memory_lseek() in drivers/char/mem.c
       - fs/fcntl.c for F_GETOWN
       - lseek for /proc/mem in fs/proc/array.c
      
      Ideally, there are a couple of other places that could benefit from this
      macro:
      
       - sys_getpriority()
       - sys_shmat()
       - sys_brk()
       - do_mmap2()
       - do_mremap()
      
      but these are not so critical, because the can be worked around in
      platform-specific code (e.g., see arch/ia64/kernel/sys_ia64.c).
      
      Note that for the above 3 cases, handling them in user level is rather
      suboptimal:
      
       - it would affect all lseek() syscalls, even though only /proc/mem and
         /dev/mem need the special treatment (at least until there are
         filesystems that can handle files >= 2^63 bytes)
      
       - all fcntl() calls would be affected, even though only F_GETOWN needs
         the special treatment
      
      so I think handling these in the kernel for the platforms that can makes
      tons of sense.
      
      The only limitation of force_successful_syscall_return() is that it doesn't
      help with system calls performed by the kernel.  But the kernel does that
      so rarely and for such a limited set of syscalls that this is not a real
      problem.
      a4369a58
    • Andrew Morton's avatar
      [PATCH] IRQs: fix up irq_desc initialisation for non-ia32 · 792fb4b7
      Andrew Morton authored
      The addition of more fields to irq_desc_t may have broken compilation of
      other architectures.  Go through and C99ify them (was needed anyway).
      792fb4b7
    • Andrew Morton's avatar
      [PATCH] IRQs: handle bad return values from handlers · 13c01fe7
      Andrew Morton authored
      Attempt to do something intelligent with IRQ handlers which don't return
      IRQ_HANDLED.
      
      - If they return neither IRQ_HANDLED nor IRQ_NONE, complain.
      
      - If they return IRQ_NONE more than 99900 times in 100000 interrupts, complain
        and disable the IRQ.
      
        I did have it at 750-in-1000, but someone had an otherwise-functioning
        system which triggered it.
      
        The 99.9% ratio is designed to address the problem wherein the babbling
        device shares an IRQ with a good device.  We don't want the good device's
        trickle of IRQ_HANDLED callouts to defeat the lockup detector.  (fat chance
        os this working right).
      
      - Add a kernel boot parameter `noirqdebug' to turn the whole thing off.
      13c01fe7
    • Andrew Morton's avatar
      [PATCH] per-cpu support inside modules (minimal) · 21af2f02
      Andrew Morton authored
      From: Rusty Russell <rusty@rustcorp.com.au>
      
      OK, this does the *minimum* required to support DEFINE_PER_CPU inside
      modules.  If we decide to change kmalloc_percpu later, great, we can turf
      this out.
      
      Basically, overallocates the amount of per-cpu data at boot to at least
      PERCPU_ENOUGH_ROOM if CONFIG_MODULES=y (arch-specific by default 32k: I have
      only 7744 bytes of percpu data in my kernel here, so makes sense), and a
      special allocator in module.c dishes it out.
      21af2f02
    • Andrew Morton's avatar
      [PATCH] kmalloc_percpu: interface change · 32028c70
      Andrew Morton authored
      From: Rusty Russell <rusty@rustcorp.com.au>
      
      Several tweaks to the kmalloc_percpu()/kfree_percpu() interface, to
      allow future implementations to be more flexible, and make easier to
      use now we can see how it's actually being used.
      
      1) No flags argument: GFP_ATOMIC doesn't make much sense,
      
      2) Explicit alignment argument, so we don't have to give SMP_CACHE_BYTES
         alignment always,
      
      3) Zeros memory, since most callers want that and it's not entirely
         trivial,
      
      4) Convenient type-safe wrapper which takes a typename, and
      
      5) Rename to alloc_percpu/__alloc_percpu, since usage no longer matches
         kmalloc.
      32028c70
    • Roman Zippel's avatar
      [PATCH] ignore attempts to change unchangable symbols · 6b206194
      Roman Zippel authored
      This fixes a problem which can show up with the new select facility, e.g.
      a symbol is forced to 'y', so we should never even try to change such
      symbols.
      6b206194
    • Roman Zippel's avatar
      [PATCH] boolean symbol state fix · cffbe99e
      Roman Zippel authored
      This is an important fix to allow changing boolean symbols, whose
      dependency is 'm'. All internal symbol states must be converted from
      the tristate into boolean the state.
      
      I missed this change while adding expression support for defaults,
      please apply.
      cffbe99e
  2. 05 Jun, 2003 31 commits