pm24.git/arch, branch v2.6.26-rc2

Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/sparc-2.6

2008-05-11T16:55:48Z

* git://git.kernel.org/pub/scm/linux/kernel/git/davem/sparc-2.6: sparc: Fix debugger syscall restart interactions. sparc: Fix ptrace() detach. sparc32: Don't twiddle PT_DTRACE in exec. sparc video: remove open boot prom code

sparc: Fix debugger syscall restart interactions.

2008-05-11T09:07:19Z

So, forever, we've had this ptrace_signal_deliver implementation which tries to handle all of the nasties that can occur when the debugger looks at a process about to take a signal. It's meant to address all of these issues inside of the kernel so that the debugger need not be mindful of such things. Problem is, this doesn't work. The idea was that we should do the syscall restart business first, so that the debugger captures that state. Otherwise, if the debugger for example saves the child's state, makes the child execute something else, then restores the saved state, we won't handle the syscall restart properly because we lose the "we're in a syscall" state. The code here worked for most cases, but if the debugger actually passes the signal through to the child unaltered, it's possible that we would do a syscall restart when we shouldn't have. In particular this breaks the case of debugging a process under a gdb which is being debugged by yet another gdb. gdb uses sigsuspend to wait for SIGCHLD of the inferior, but if gdb itself is being debugged by a top-level gdb we get a ptrace_stop(). The top-level gdb does a PTRACE_CONT with SIGCHLD to let the inferior gdb see the signal. But ptrace_signal_deliver() assumed the debugger would cancel out the signal and therefore did a syscall restart, because the return error was ERESTARTNOHAND. Fix this by simply making ptrace_signal_deliver() a nop, and providing a way for the debugger to control system call restarting properly: 1) Report a "in syscall" software bit in regs->{tstate,psr}. It is set early on in trap entry to a system call and is fully visible to the debugger via ptrace() and regsets. 2) Test this bit right before doing a syscall restart. We have to do a final recheck right after get_signal_to_deliver() in case the debugger cleared the bit during ptrace_stop(). 3) Clear the bit in trap return so we don't accidently try to set that bit in the real register. As a result we also get a ptrace_{is,clear}_syscall() for sparc32 just like sparc64 has. M68K has this same exact bug, and is now the only other user of the ptrace_signal_deliver hook. It needs to be fixed in the same exact way as sparc. Signed-off-by: David S. Miller

sparc: Fix ptrace() detach.

2008-05-11T08:59:05Z

Forever we had a PTRACE_SUNOS_DETACH which was unconditionally recognized, regardless of the personality of the process. Unfortunately, this value is what ended up in the GLIBC sys/ptrace.h header file on sparc as PTRACE_DETACH and PT_DETACH. So continue to recognize this old value. Luckily, it doesn't conflict with anything we actually care about. Signed-off-by: David S. Miller

Merge master.kernel.org:/home/rmk/linux-2.6-arm

2008-05-11T04:14:05Z

* master.kernel.org:/home/rmk/linux-2.6-arm: [ARM] 5033/1: Unbreak corgi_ssp by registering ssp drivers earlier. [ARM] Orion: clean up addr-map.c after window setting code purge [ARM] Orion: pass proper t_clk into mv643xx_eth [ARM] Orion: use mv643xx_eth driver mbus window handling [ARM] pxa: Fix RCSR handling [ARM] lubbock: fix compilation [ARM] 5032/1: Added cpufreq support for pxa27x CPU [ARM] 5031/1: Indentation correction in cpu-pxa.c. [ARM] 5028/1: pxafb: fix broken "backward compatibility way" in framebuffer [ARM] 4882/2: Correction for S3C2410 clkout generation [ARM] 5027/1: Fixed random memory corruption on pxa suspend cycle. [ARM] 5024/1: Fix some minor clk issues in the MMCI PL18x driver [ARM] 5023/1: Fix broken gpio interrupts on ep93xx ns9xxx: fix sparse warning ns9xxx: check for irq lockups ns9xxx: fix handle_prio_irq to unmask irqs with lower priority

Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/x86/linux-2.6-x86

2008-05-11T04:10:48Z

* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/x86/linux-2.6-x86: x86: rdc: leds build/config fix x86: sysfs cpu?/topology is empty in 2.6.25 (32-bit Intel system) x86: revert commit 709f744 ("x86: bitops asm constraint fixes") x86: restrict keyboard io ports reservation to make ipmi driver work x86: fix fpu restore from sig return x86: remove spew print out about bus to node mapping x86: revert printk format warning change which is for linux-next x86: cleanup PAT cpu validation x86: geode: define geode_has_vsa2() even if CONFIG_MGEODE_LX is not set x86: GEODE: cache results from geode_has_vsa2() and uninline x86: revert geode config dependency

BKL: revert back to the old spinlock implementation

2008-05-11T03:58:02Z

The generic semaphore rewrite had a huge performance regression on AIM7 (and potentially other BKL-heavy benchmarks) because the generic semaphores had been rewritten to be simple to understand and fair. The latter, in particular, turns a semaphore-based BKL implementation into a mess of scheduling. The attempt to fix the performance regression failed miserably (see the previous commit 00b41ec2611dc98f87f30753ee00a53db648d662 'Revert "semaphore: fix"'), and so for now the simple and sane approach is to instead just go back to the old spinlock-based BKL implementation that never had any issues like this. This patch also has the advantage of being reported to fix the regression completely according to Yanmin Zhang, unlike the semaphore hack which still left a couple percentage point regression. As a spinlock, the BKL obviously has the potential to be a latency issue, but it's not really any different from any other spinlock in that respect. We do want to get rid of the BKL asap, but that has been the plan for several years. These days, the biggest users are in the tty layer (open/release in particular) and Alan holds out some hope: "tty release is probably a few months away from getting cured - I'm afraid it will almost certainly be the very last user of the BKL in tty to get fixed as it depends on everything else being sanely locked." so while we're not there yet, we do have a plan of action. Tested-by: Yanmin Zhang Cc: Ingo Molnar Cc: Andi Kleen Cc: Matthew Wilcox Cc: Alexander Viro Cc: Andrew Morton Signed-off-by: Linus Torvalds

x86: rdc: leds build/config fix

2008-05-10T17:31:45Z

select NEW_LEDS for now until the Kconfig dependencies have been fixed. Signed-off-by: Ingo Molnar Signed-off-by: Thomas Gleixner

x86: restrict keyboard io ports reservation to make ipmi driver work

2008-05-10T17:31:45Z

On some of our (single board computer) boards (x86) we are using an IPMI controller that uses I/O ports 0x62 and 0x66 for a KCS (keyboard controller style) IPMI system interface. Trying to load the openipmi driver fails, because the ports (0x62/0x66) are reserved for keyboard. keyboard reserves the full range 0x60-0x6F while it doesn't need to. Reserve only ports 0x60 and 0x64 for the legacy PS/2 i8042 keyboad controller instead of 0x60-0x6F to allow the openipmi driver to work. [ tglx: added 64bit fixup ] Signed-off-by: Thomas Gleixner Acked-by: H. Peter Anvin Signed-off-by: Ingo Molnar

x86: fix fpu restore from sig return

2008-05-10T17:31:45Z

If the task never used fpu, initialize the fpu before restoring the FP state from the signal handler context. This will allocate the fpu state, if the task never needed it before. Reported-and-bisected-by: Eric Sesterhenn Signed-off-by: Suresh Siddha Tested-by: Eric Sesterhenn Cc: Frederik Deweerdt Signed-off-by: Thomas Gleixner

x86: remove spew print out about bus to node mapping

2008-05-10T17:31:45Z

Jeff Garzik pointed out that this printout is not needed. Signed-off-by: Yinghai Lu Signed-off-by: Ingo Molnar Signed-off-by: Thomas Gleixner