- 12 Jan, 2006 40 commits
-
-
Andi Kleen authored
Previously apic was foced with apic=logopt was specified. Signed-off-by:
Andi Kleen <ak@suse.de> Signed-off-by:
Linus Torvalds <torvalds@osdl.org>
-
Andi Kleen authored
It might be still needed for non APIC related issues. Signed-off-by:
-
Andi Kleen authored
Print bits for RDTSCP, SVM, CR8-LEGACY. Also now print power flags on i386 like x86-64 always did. This will add a new line in the 386 cpuinfo, but that shouldn't be an issue - did that in the past too and I haven't heard of any breakage. I shrunk some of the fields in the i386 cpuinfo_x86 to chars to make up for the new int "x86_power" field. Overall it's smaller than before. Signed-off-by:
-
Andi Kleen authored
They previously tried to figure this out on their own. Suggested by Venkatesh. Cc: venkatesh.pallipadi@intel.com Cc: davej@redhat.com Signed-off-by:
-
Andi Kleen authored
Define it for i386 too. This is a synthetic flag that signifies that the CPU's TSC runs at a constant P state invariant frequency. Fix up the logic on x86-64/i386 to set it on all known CPUs. Use the AMD defined bit to set it on future AMD CPUs. Cc: venkatesh.pallipadi@intel.com Signed-off-by:
-
Andi Kleen authored
Was only used by the floppy driver to work around some ancient hardware bug that should never occur on any 64bit system. Signed-off-by:
-
Andi Kleen authored
Cc: len.brown@intel.com, ashok.ray@intel.com Signed-off-by:
-
Andi Kleen authored
Most users don't need it so no need to waste memory. This means an user has to specify the appropiate number of hotplug CPUs on the command line with additional_cpus=... or fix their BIOS to follow the convention in Documentation/x86-64/cpu-hotplug-spec Signed-off-by:
-
Andi Kleen authored
Noticed by Andreas Schwab Signed-off-by:
-
Andi Kleen authored
head.S already clears EFLAGS completely. Following an i386 patch from Zachary Amsden. Signed-off-by:
-
Andi Kleen authored
Pretty obvious Signed-off-by:
-
Jan Beulich authored
Adjust page fault protection error check before considering it to be a vmalloc synchronization candidate. Signed-off-by:
-
Jan Beulich authored
Make sure no iret can fault without attached recovery code. Cannot happen in the normal case, but might be useful with kernel debuggers Signed-off-by:
-
Jan Beulich authored
Since a double fault always implies that kernel data structures are corrupt, this fault should neither be handed to user mode handling, nor should the handler allow resuming the faulting code stream (since architecturally this isn't a fault, but an abort). Note that this slightly depends on the previously submitted patch adjusting the prototype of notify_die() (a compiler warning will result without that other patch). AK: Removed obsolete CONFIG_CHECKING code, added comments Signed-off-by:
-
Jan Beulich authored
This adjusts things so that handlers of the die() notifier will have sufficient information about the trap currently being handled. It also adjusts the notify_die() prototype to (again) match that of i386. Signed-off-by:
-
Jan Beulich authored
Signed-off-by:
-
Jan Beulich authored
Other than apparently commonly assumed, the bound instruction does not require the corresponding IDT entry to have DPL 3. Signed-off-by:
-
Jan Beulich authored
As a follow-up to the introduction of CONFIG_UNWIND_INFO, this separates the generation of frame unwind information for x86-64 from that of full debug information. Signed-off-by:
-
Andi Kleen authored
Based on the documentation recently posted by Richard Brunner. Signed-off-by:
-
Jan Beulich authored
Frame unwind information was still incorrect for ia32_ptregs_common (sorry, my fault), and could be improved for some of the other entry points. Signed-Off-By:
Jan Beulich <jbeulich@novell.com> Signed-off-by:
-
Andi Kleen authored
Signed-off-by:
-
Andrew Morton authored
Run all rio files through indent -kr -i8 -bri0 -l255, as requested by Alan. rioboot.c and rioinit.c were skipped due to worrisome lindent warnings. Cc: Alan Cox <alan@lxorguk.ukuu.org.uk> Signed-off-by:
Andrew Morton <akpm@osdl.org> Signed-off-by:
-
Randy Dunlap authored
arch: Use <linux/capability.h> where capable() is used. Signed-off-by:
Randy Dunlap <rdunlap@xenotime.net> Signed-off-by:
-
Randy Dunlap authored
net: Use <linux/capability.h> where capable() is used. Signed-off-by:
-
Randy Dunlap authored
fs: Use <linux/capability.h> where capable() is used. Signed-off-by:
Tim Schmielau <tim@physik3.uni-rostock.de> Signed-off-by:
-
Randy.Dunlap authored
- Move capable() from sched.h to capability.h; - Use <linux/capability.h> where capable() is used (in include/, block/, ipc/, kernel/, a few drivers/, mm/, security/, & sound/; many more drivers/ to go) Signed-off-by:
-
Ingo Molnar authored
Uninline capable(). Saves 2K of kernel text on a generic .config, and 1K on a tiny config. In addition it makes the use of capable more consistent between CONFIG_SECURITY and !CONFIG_SECURITY Signed-off-by:
Ingo Molnar <mingo@elte.hu> Signed-off-by:
-
Matt Domsch authored
With Andi Kleen's x86_64 patch to use DMI, and my ia64 to use DMI, there is now a new CONFIG_DMI option which takes the place of CONFIG_X86 to denote the availability of the DMI functions. Make the IPMI driver use CONFIG_DMI instead. Tested on ia64 2.6.15 kernel plus the previous patch, on a Dell PowerEdge 7250 Itanium2 server, and it now autodetects the IPMI KCS driver as expected. Signed-off-by:
Matt Domsch <Matt_Domsch@dell.com> Acked-by:
Corey Minyard <minyard@acm.org> Signed-off-by:
-
Jesper Juhl authored
sound/oss/i810_audio.c:3431: warning: label `out_pio' defined but not used Signed-off-by: Jesper Juhl <jesper.juhl@gmail.com Signed-off-by:
-
Keshavamurthy Anil S authored
There is a window where a probe gets removed right after the probe is hit on some different cpu. In this case probe handlers can't find a matching probe instance related to break address. In this case we need to read the original instruction at break address to see if that is not a break/int3 instruction and recover safely. Previous code had a bug where we were not checking for the above race in case of reentrant probes and the below patch fixes this race. Tested on IA64, Powerpc, x86_64. Signed-off-by:
Anil S Keshavamurthy <anil.s.keshavamurthy@intel.com> Signed-off-by:
-
Keshavamurthy Anil S authored
When a kprobes modules is written in such a way that probes are inserted on itself, then unload of that moudle was not possible due to reference couning on the same module. The below patch makes a check and incrementes the module refcount only if it is not a self probed module. We need to allow modules to probe themself for kprobes performance measurements This patch has been tested on several x86_64, ppc64 and IA64 architectures. Signed-off-by: Anil S Keshavamurthy <anil.s.keshavamurthy> Signed-off-by:
-
Jan Kara authored
Sometimes we call do_journal_end() with t_refcount == 0. If quota is turned on and we happen to have some inode with preallocation bad things happen as we try to use the current handle for quota operations. Checks for t_refcount in journal_begin() fail and we Oops. We raise t_refcount to make those checks happy. We should not cause any bad as all the needed quota blocks should be already attached to the transaction (they were attached to the transaction when we allocated those preallocation blocks). Signed-off-by:
Jan Kara <jack@suse.cz> Cc: Jeff Mahoney <jeffm@suse.com> Cc: Chris Mason <mason@suse.com> Signed-off-by:
-
Paul Fulghum authored
Remove unnecessary and incorrectly implemented page alignment of register base address before calling ioremap() Signed-off-by:
Paul Fulghum <paulkf@microgate.com> Signed-off-by:
-
Stephen Hemminger authored
Get rid of bogus extern attribute that causes sparse warning. Signed-off-by:
Stephen Hemminger <shemminger@osdl.org> Acked-by:
Matt Mackall <mpm@selenic.com> Signed-off-by:
-
Alan Cox authored
Signed-off-by:
Alan Cox <alan@redhat.com> Signed-off-by:
-
Vivek Goyal authored
o fs/proc/vmcore.c compilation gives warnings on ppc64. The reason being that u64 is defined as unsigned long hence u64* is not same as loff_t* and compiler cribs. o Changed the parameter type to u64* instead of loff_t* to resolve the conflict. Signed-off-by:
Vivek Goyal <vgoyal@in.ibm.com> Signed-off-by:
-
Jean Delvare authored
Fix the help text of the cs89x0 network driver Kconfig entry. Signed-off-by:
Jean Delvare <khali@linux-fr.org> Signed-off-by:
-
Lennert Buytenhek authored
There's an ifdef in cs89x0.c that seems to have been the wrong way round since it was merged (and noone seems to have noticed) -- the IXDP2x01 doesn't support ISA-style DMA, but when building for IXDP2x01, cs89x0's ALLOW_DMA is set to 1, and when building for another platform, ALLOW_DMA is set to 0. Signed-off-by:
Lennert Buytenhek <buytenh@wantstofly.org> Signed-off-by:
-
Alan Cox authored
I sent this out a couple of months ago and the driver author said it he'd merge it. Nothing has happened since so I'm submitting it directly. No functionality changes just texts. Signed-off-by:
-
Alan Cox authored
Someone wanted access to this usually unused (and unused by Linux) value for the day of week. Existing kernels have the field in the struct but return 0 always. This updates the kernel to fill in the field. The usual case of 'not set' conveniently is 0. Signed-off-by:
-
