Commit Graph

210185 Commits

Author SHA1 Message Date
Christoph Hellwig
22a685d09b [PATCH] officially deprecate register_ioctl32_conversion
These have been deprecated since ->compat_ioctl when in, thus only a short
deprecation period.  There's four users left: i2o_config, s390/z90crypy,
s390/dasd and s390/zfcp and for the first two patches are about to be
submitted to get rid of it.

Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-04-16 15:25:48 -07:00
Christoph Hellwig
6cae60feb6 [PATCH] kill #ifndef HAVE_ARCH_GET_SIGNAL_TO_DELIVER in signal.c
Now that no architectures defines HAVE_ARCH_GET_SIGNAL_TO_DELIVER anymore
this can go away.  It was a transitional hack only.

Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-04-16 15:25:47 -07:00
Niu YaWei
e821d94d34 [PATCH] quota: possible bug in quota format v2 support
Don't put root block of quota tree to the free list (when quota file is
completely empty).  That should not actually happen anyway (somebody should
get accounted for the filesystem root and so quota file should never be
empty) but better prevent it here than solve magical quota file
corruption.

Signed-off-by: Jan Kara <jack@suse.cz>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-04-16 15:25:47 -07:00
Jan Kara
31e7ad6ac9 [PATCH] quota: fix possible oops on quotaoff
Remove dquot structures from quota file on quotaon - quota code does not
expect them to be there.

Signed-off-by: Jan Kara <jack@suse.cz>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-04-16 15:25:46 -07:00
Bernard Blackham
e072c6f2af [PATCH] ext2 corruption - regression between 2.6.9 and 2.6.10
Whilst trying to stress test a Promise SX8 card, we stumbled across
some nasty filesystem corruption in ext2. Our tests involved
creating an ext2 partition, mounting, running several concurrent
fsx's over it, umounting, and fsck'ing, all scripted[1]. The fsck
would always return with errors.

This regression was traced back to a change between 2.6.9 and
2.6.10, which moves the functionality of ext2_put_inode into
ext2_clear_inode.  The attached patch reverses this change, and
eliminated the source of corruption.

Mingming Cao <cmm@us.ibm.com> said:

I think his patch for ext2 is correct.  The corruption on ext3 is not the same
issue he saw on ext2.  I believe that's the race between discard reservation
and reservation in-use that we already fixed it in 2.6.12- rc1.

For the problem related to ext2, at the time when we design reservation for
ext3, we decide we only need to discard the reservation at the last file
close, so we have ext3_discard_reservation on iput_final- >ext3_clear_inode.

The ext2 handle discard preallocation differently at that time, it discard the
preallocation at each iput(), not in input_final(), so we think it's
unnecessary to thrash it so frequently, and the right thing to do, as we did
for ext3 reservation, discard preallocation on last iput().  So we moved the
ext2_discard_preallocation from ext2_put_inode(0 to ext2_clear_inode.

Since ext2 preallocation is doing pre-allocation on disk, so it is possible
that at the unmount time, someone is still hold the reference of the inode, so
the preallocation for a file is not discard yet, so we still mark those blocks
allocated on disk, while they are not actually in the inode's block map, so
fsck will catch/fix that error later.

This is not a issue for ext3, as ext3 reservation(pre-allocation) is done in
memory.

Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-04-16 15:25:45 -07:00
Christoph Hellwig
614a7d6a76 [PATCH] fix up newly added jsm driver
- plug various leaks and use after frees in the remove and
   initialization failure path (some still left)
 - remove useless global list of boards and use pci_set_drvdata instead
 - unobsfucate init path by merging functions together
 - kill various totally useless state variables
 - .. probably more I forgot

Note that the tty part still generates lots of sparse warnings and there's
still a totally useless layer of function pointer indirections, but maybe
someone else will fix that bit up.

Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-04-16 15:25:44 -07:00
Ken Chen
a299738283 [PATCH] use cheaper elv_queue_empty when unplug a device
In function __generic_unplug_device(), kernel can use a cheaper function
elv_queue_empty() instead of more expensive elv_next_request to find
whether the queue is empty or not.  blk_run_queue can also made conditional
on whether queue's emptiness before calling request_fn().

Signed-off-by: Jens Axboe <axboe@suse.de>
Signed-off-by: Ken Chen <kenneth.w.chen@intel.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-04-16 15:25:43 -07:00
Bert Wesarg
975e046cc0 [PATCH] fix module_param_string() calls
This patch fix 3 calls to module_param_string() in
driver/media/video/tuner-core.c and drivers/media/video/tda9887.c.  In all
three places, the len and the perm parameter was switched.

Signed-off-by: Bert Wesarg <wesarg@informatik.uni-halle.de>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-04-16 15:25:43 -07:00
Bert Wesarg
31143a1204 [PATCH] kernel/param.c: don't use .max when .num is NULL in param_array_set()
there seems to be a bug, at least for me, in kernel/param.c for arrays with
.num == NULL.  If .num == NULL, the function param_array_set() uses &.max
for the call to param_array(), wich alters the .max value to the number of
arguments.  The result is, you can't set more array arguments as the last
time you set the parameter.

example:

# a module 'example' with
# static int array[10] = { 0, };
# module_param_array(array, int, NULL, 0644);

$ insmod example.ko array=1,2,3
$ cat /sys/module/example/parameters/array
1,2,3
$ echo "4,3,2,1" > /sys/module/example/parameters/array
$ dmesg | tail -n 1
kernel: array: can take only 3 arguments

Signed-off-by: Bert Wesarg <wesarg@informatik.uni-halle.de>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-04-16 15:25:42 -07:00
Bharath Ramesh
fc9c9ab22d [PATCH] AYSNC IO using singals other than SIGIO
A question on sigwaitinfo based IO mechanism in multithreaded applications.

I am trying to use RT signals to notify me of IO events using RT signals
instead of SIGIO in a multithreaded applications.  I noticed that there was
some discussion on lkml during november 1999 with the subject of the
discussion as "Signal driven IO".  In the thread I noticed that RT signals
were being delivered to the worker thread.  I am running 2.6.10 kernel and
I am trying to use the very same mechanism and I find that only SIGIO being
propogated to the worker threads and RT signals only being propogated to
the main thread and not the worker threads where I actually want them to be
propogated too.  On further inspection I found that the following patch
which I have attached solves the problem.

I am not sure if this is a bug or feature in the kernel.


Roland McGrath <roland@redhat.com> said:

This relates only to fcntl F_SETSIG, which is a Linux extension.  So there is
no POSIX issue.  When changing various things like the normal SIGIO signalling
to do group signals, I was concerned strictly with the POSIX semantics and
generally avoided touching things in the domain of Linux inventions.  That's
why I didn't change this when I changed the call right next to it.  There is
no reason I can see that F_SETSIG-requested signals shouldn't use a group
signal like normal SIGIO does.  I'm happy to ACK this patch, there is nothing
wrong with its change to the semantics in my book.  But neither POSIX nor I
care a whit what F_SETSIG does.

Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-04-16 15:25:41 -07:00
Jens Axboe
4a534f93b3 [PATCH] possible use-after-free of bio
There is a possibility that a bio will be accessed after it has been freed
on SCSI.  It happens if you submit a bio with BIO_SYNC marked and the
auto-unplugging kicks the request_fn, SCSI re-enables interrupts in-between
so if the request completes between the add_request() in __make_request()
and the bio_sync() call, we could be looking at a dead bio.  It's a slim
race, but it has been triggered in the Real World.

So assign bio_sync() to a local variable instead.

Signed-off-by: Jens Axboe <axboe@suse.de>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-04-16 15:25:40 -07:00
Paolo 'Blaisorblade' Giarrusso
9c340d80f6 [PATCH] uml: fix compilation for __CHOOSE_MODE addition
I had added the __CHOOSE_MODE syntax to fix some warnings with newer GCC's
in the uml-fix-cond-expr-as-lvalues-warning patch.

Here is the update from the version I sent to make it work also when only
one mode (TT or SKAS) is enabled.

Signed-off-by: Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-04-16 15:25:39 -07:00
Alexander Nyberg
43117a0828 [PATCH] swsusp: SMP fix
Fix some smp_processor_id-in-preemptible warnings

Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-04-16 15:25:39 -07:00
Pavel Machek
bf2049f983 [PATCH] fix few remaining u32 vs. pm_message_t problems
This fixes remaining u32 vs.  pm_message_t confusions in -rc2-mm3.  [There
are usb changes, too; they went to Greg on his request.]

Signed-off-by: Pavel Machek <pavel@suse.cz>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-04-16 15:25:38 -07:00
Pavel Machek
3bfffd97ef [PATCH] fix u32 vs. pm_message_t in rest of the tree
This fixes u32 vs.  pm_message_t confusion in remaining places.  Fortunately
there's few of them.

Signed-off-by: Pavel Machek <pavel@suse.cz>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-04-16 15:25:37 -07:00
Pavel Machek
9bfd354b1b [PATCH] fix u32 vs. pm_message_t in driver/video
This fixes u32 vs.  pm_message_t confusion in drivers/video.  Should change no
code.

Signed-off-by: Pavel Machek <pavel@suse.cz>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-04-16 15:25:36 -07:00
Pavel Machek
0370affeec [PATCH] fix u32 vs. pm_message_t in drivers/
-rc2-mm1 still contains few places where u32 and pm_message_t.  This fixes
drivers/serial [should change no code].

Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-04-16 15:25:35 -07:00
Pavel Machek
a4ffad5b77 [PATCH] power/video.txt: update documentation with more systems
This updates video.txt documentation with information about few more
systems.

Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-04-16 15:25:34 -07:00
Pavel Machek
b1c42851b0 [PATCH] u32 vs. pm_message_t in ppc and radeon
This fixes pm_message_t vs.  u32 confusion in ppc and aty (I *hope* that's
basically radeon code...).  I was not able to test most of these, but I'm
not really changing anything, so it should be okay.

Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-04-16 15:25:34 -07:00
Pavel Machek
7f4927c1b5 [PATCH] fix u32 vs. pm_message_t in PCI, PCIE
This fixes drivers/pci (mostly pcie stuff).

Signed-off-by: Pavel Machek <pavel@suse.cz>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-04-16 15:25:33 -07:00
Pavel Machek
f45139044d [PATCH] fix u32 vs. pm_message_t in drivers/macintosh
I thought I'm done with fixing u32 vs.  pm_message_t ...  unfortunately that
turned out not to be the case as Russel King pointed out.  Here are fixes for
drivers/macintosh.

Signed-off-by: Pavel Machek <pavel@suse.cz>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-04-16 15:25:32 -07:00
Pavel Machek
0b9c33a7d6 [PATCH] Fix u32 vs. pm_message_t in x86-64
I thought I'm done with fixing u32 vs.  pm_message_t ...  unfortunately that
turned out not to be the case...  Here are fixes x86-64.

Signed-off-by: Pavel Machek <pavel@suse.cz>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-04-16 15:25:31 -07:00
Pavel Machek
e2d53566a7 [PATCH] fix pm_message_t vs. u32 in alsa
I thought I'm done with fixing u32 vs.  pm_message_t ...  unfortunately that
turned out not to be the case as Russel King pointed out.  This fixes last few
bits in alsa.

Signed-off-by: Pavel Machek <pavel@suse.cz>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-04-16 15:25:30 -07:00
Pavel Machek
e5378ca8c0 [PATCH] fix u32 vs. pm_message_t in drivers/mmc,mtd,scsi
This fixes u32 vs.  pm_message_t in drivers/mmc, drivers/mtd and
drivers/scsi.

Signed-off-by: Pavel Machek <pavel@suse.cz>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-04-16 15:25:29 -07:00
Pavel Machek
8d189f7298 [PATCH] fix u32 vs. pm_message_t in drivers/message
This fixes u32 vs. pm_message_t in drivers/message.

Signed-off-by: Pavel Machek <pavel@suse.cz>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-04-16 15:25:28 -07:00
Pavel Machek
a291068991 [PATCH] fix u32 vs. pm_message_t in drivers/media
Here are fixes for drivers/media.

Signed-off-by: Pavel Machek <pavel@suse.cz>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-04-16 15:25:27 -07:00
Pavel Machek
8bf28030f3 [PATCH] fix u32 vs. pm_message_t in pcmcia
This fixes u32 vs. pm_message_t in pcmcia.

Signed-off-by: Pavel Machek <pavel@suse.cz>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-04-16 15:25:26 -07:00
Pavel Machek
05adc3b745 [PATCH] u32 vs. pm_message_t fixes for drivers/net
This fixes remaining u32s in drivers/ net.

Signed-off-by: Pavel Machek <pavel@suse.cz>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-04-16 15:25:25 -07:00
Pavel Machek
4fd416c14c [PATCH] Fix u32 vs. pm_message_t in drivers/char
Here are fixes for drivers/char.

Signed-off-by: Pavel Machek <pavel@suse.cz>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-04-16 15:25:24 -07:00
Pavel Machek
438510f6f0 [PATCH] pm_message_t: more fixes in common and i386
I thought I'm done with fixing u32 vs.  pm_message_t ...  unfortunately
that turned out not to be the case as Russel King pointed out.  Here are
fixes for Documentation and common code (mainly system devices).

Signed-off-by: Pavel Machek <pavel@suse.cz>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-04-16 15:25:24 -07:00
Yoshinori Sato
74ad74c158 [PATCH] h8300 header update
- page.h: fix build error
- unistd.h: _syscall macro cleanup.

Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-04-16 15:25:21 -07:00
Siddha, Suresh B
d31ddaa172 [PATCH] x86, x86_64: dual core proc-cpuinfo and sibling-map fix
- broken sibling_map setup in x86_64

- grouping all the core and HT related cpuinfo fields.
  We are reasonably sure that adding new cpuinfo fields after "siblings" field,
  will not cause any app failure. Thats because today's /proc/cpuinfo
  format is completely different on x86, x86_64 and we haven't heard of any
  x86 app breakage because of this issue. Grouping these fields will 
  result in more or less common format on all architectures (ia64, x86 and 
  x86_64) and will cause less confusion.

Signed-off-by: Suresh Siddha <suresh.b.siddha@intel.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-04-16 15:25:20 -07:00
Andi Kleen
a8ab26fe5b [PATCH] x86_64: Switch SMP bootup over to new CPU hotplug state machine
This will allow hotplug CPU in the future and in general cleans up a lot of
crufty code.  It also should plug some races that the old hackish way
introduces.  Remove one old race workaround in NMI watchdog setup that is not
needed anymore.

I removed the old total sum of bogomips reporting code.  The brag value of
BogoMips has been greatly devalued in the last years on the open market.

Real CPU hotplug will need some more work, but the infrastructure for it is
there now.

One drawback: the new TSC sync algorithm is less accurate than before.  The
old way of zeroing TSCs is too intrusive to do later.  Instead the TSC of the
BP is duplicated now, which is less accurate.

akpm:

- sync_tsc_bp_init seems to have the sense of `init' inverted.

- SPIN_LOCK_UNLOCKED is deprecated - use DEFINE_SPINLOCK.

Cc: <rusty@rustcorp.com.au>
Cc: <mingo@elte.hu>
Signed-off-by: Andi Kleen <ak@suse.de>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-04-16 15:25:19 -07:00
Andi Kleen
ebfcaa96fc [PATCH] x86_64: Rename the extended cpuid level field
It was confusingly named.

Signed-off-by: Andi Kleen <ak@suse.de>
DESC
x86_64: Switch SMP bootup over to new CPU hotplug state machine
EDESC
From: "Andi Kleen" <ak@suse.de>

This will allow hotplug CPU in the future and in general cleans up a lot of
crufty code.  It also should plug some races that the old hackish way
introduces.  Remove one old race workaround in NMI watchdog setup that is not
needed anymore.

I removed the old total sum of bogomips reporting code.  The brag value of
BogoMips has been greatly devalued in the last years on the open market.

Real CPU hotplug will need some more work, but the infrastructure for it is
there now.

One drawback: the new TSC sync algorithm is less accurate than before.  The
old way of zeroing TSCs is too intrusive to do later.  Instead the TSC of the
BP is duplicated now, which is less accurate.

Cc: <rusty@rustcorp.com.au>
Cc: <mingo@elte.hu>
Signed-off-by: Andi Kleen <ak@suse.de>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-04-16 15:25:18 -07:00
Andi Kleen
229992446b [PATCH] x86_64: Add acpi_skip_timer_override option
Add acpi_skip_timer_override option.  It was missing previously.

Signed-off-by: Andi Kleen <ak@suse.de>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-04-16 15:25:17 -07:00
Andi Kleen
0a65800243 [PATCH] x86_64: Rewrite exception stack backtracing
Exceptions and hardware interrupts can, to a certain degree, nest, so when
attempting to follow the sequence of stacks used in order to dump their
contents this has to be accounted for.  Also, IST stacks have their tops
stored in the TSS, so there's no need to add the stack size to get to their
ends.

Minor changes from AK.

Signed-off-by: Jan Beulich <jbeulich@novell.com>
Signed-off-by: Andi Kleen <ak@suse.de>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-04-16 15:25:17 -07:00
Andi Kleen
635186447d [PATCH] x86_64: Final support for AMD dual core
Clean up the code greatly.  Now uses the infrastructure from the Intel dual
core patch Should fix a final bug noticed by Tyan of not detecting the nodes
correctly in some corner cases.

Patch for x86-64 and i386

Signed-off-by: Andi Kleen <ak@suse.de>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-04-16 15:25:16 -07:00
Andi Kleen
3dd9d51484 [PATCH] x86_64: add support for Intel dual-core detection and displaying
Appended patch adds the support for Intel dual-core detection and displaying
the core related information in /proc/cpuinfo.  

It adds two new fields "core id" and "cpu cores" to x86 /proc/cpuinfo and the
"core id" field for x86_64("cpu cores" field is already present in x86_64).

Number of processor cores in a die is detected using cpuid(4) and this is
documented in IA-32 Intel Architecture Software Developer's Manual (vol 2a)
(http://developer.intel.com/design/pentium4/manuals/index_new.htm#sdm_vol2a)

This patch also adds cpu_core_map similar to cpu_sibling_map.

Slightly hacked by AK.

Signed-off-by: Suresh Siddha <suresh.b.siddha@intel.com>
Signed-off-by: Andi Kleen <ak@suse.de>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-04-16 15:25:15 -07:00
Andi Kleen
f2ea2750fb [PATCH] x86_64: Remove duplicated syscall entry.
Signed-off-by: Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it>
Signed-off-by: Andi Kleen <ak@suse.de>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-04-16 15:25:14 -07:00
Andi Kleen
daeeafecf0 [PATCH] x86_64: Keep only a single debug notifier chain
Calling a notifier three times in the debug handler does not make much sense,
because a debugger can figure out the various conditions by itself.  Remove
the additional calls to DIE_DEBUG and DIE_DEBUGSTEP completely.

This matches what i386 does now.

This also makes sure interrupts are always still disabled when calling a
debugger, which prevents:

BUG: using smp_processor_id() in preemptible [00000001] code: tpopf/1470
caller is post_kprobe_handler+0x9/0x70

Call Trace:<ffffffff8024f10f>{smp_processor_id+191} <ffffffff80120e69>{post_kpro
be_handler+9} 
<ffffffff80120f7a>{kprobe_exceptions_notify+58} 
<ffffffff80144fc0>{notifier_call_chain+32} <ffffffff80110daf>{do_debug+335} 
<ffffffff8010f513>{debug+127}  <EOE> 

on preemptible debug kernels with kprobes when single stepping in user space.

This was probably a bug even on non preempt kernels, this function was
supposed to be running with interrupts off according to a comment there.

Note to third part debugger maintainers: please double check your debugger can
still single step.

Cc: <prasanna@in.ibm.com>
Cc: <jbeulich@novell.com>
Cc: <kaos@sgi.com>
Cc: <jim.houston@ccur.com>
Cc: <jfv@bluesong.net>
Signed-off-by: Andi Kleen <ak@suse.de>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-04-16 15:25:13 -07:00
Andi Kleen
ece90303ec [PATCH] x86_64: Use the e820 hole to map the IOMMU/AGP aperture
This might save memory on some Opteron systems without AGP bridge.

Signed-off-by: Andi Kleen <ak@suse.de>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-04-16 15:25:13 -07:00
Andi Kleen
a1e9778203 [PATCH] x86_64: Port over e820 gap detection from i386
Look for gaps in the e820 memory map to put PCI resources in.

This hopefully fixes problems with the PCI code assigning 32bit BARs MMIO
resources which are >32bit.

Signed-off-by: Andi Kleen <ak@suse.de>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-04-16 15:25:12 -07:00
Siddha, Suresh B
cf94b62f70 [PATCH] x86_64-always-use-cpuid-80000008-to-figure-out-mtrr fix
We need to use the size_and_mask in set_mtrr_var_ranges(which is called
while programming MTRR's for AP's

Signed-off-by: Suresh Siddha <suresh.b.siddha@intel.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-04-16 15:25:11 -07:00
Andi Kleen
1f2c958ad5 [PATCH] x86_64: Always use CPUID 80000008 to figure out MTRR address space size
It doesn't make sense to only do this only for AMD K8.

This would support future CPUs with extended address spaces properly.

For i386 and x86-64

Cc: <davej@redhat.com>
Signed-off-by: Andi Kleen <ak@suse.de>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-04-16 15:25:10 -07:00
Andi Kleen
f0de53bbc2 [PATCH] x86_64: Remove excessive stack allocation in MCE code with large NR_CPUS
Remove excessive stack allocation in MCE code with large NR_CPUS

Signed-off-by: Andi Kleen <ak@suse.de>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-04-16 15:25:10 -07:00
Andi Kleen
94ad84740f [PATCH] x86_64: Use the extended RIP MSR for machine check reporting if available.
They are rumoured to be much more reliable than the RIP in the stack frame on
P4s.

This is a borderline case because the code is very simple.  Please note there
are no plans to add support for all the MCE register MSRs.

Cc: <venkatesh.pallipadi@intel.com>
Cc: <racing.guo@intel.com>
Signed-off-by: Andi Kleen <ak@suse.de>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-04-16 15:25:09 -07:00
Andi Kleen
1c1734090e [PATCH] x86_64: Correct wrong comment in local.h
local_t is actually a win over atomic_t because it does not need lock
prefixes.

Signed-off-by: Andi Kleen <ak@suse.de>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-04-16 15:25:08 -07:00
Andi Kleen
72e76be2fe [PATCH] x86_64: Don't assume future AMD CPUs have K8 compatible performance counters
The NMI watchdog code did this incorrectly

Signed-off-by: Andi Kleen <ak@suse.de>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-04-16 15:25:07 -07:00
Andi Kleen
3a848f632f [PATCH] x86_64: Make kernel math errors a die() now
There were no reports about the previous warning for FPU exceptions in the
kernel, so make it a die() now.

Also improve the error messages slightly.

Signed-off-by: Andi Kleen <ak@suse.de>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-04-16 15:25:06 -07:00
Andi Kleen
c29601e9c1 [PATCH] x86_64: Support constantly ticking TSCs
On Intel Noconas the TSC ticks with a constant frequency.  Don't scale the
factor used by udelay when cpufreq changes the frequency.

This generalizes an earlier patch by Intel for this. 

Cc: <venkatesh.pallipadi@intel.com>
Signed-off-by: Andi Kleen <ak@suse.de>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-04-16 15:25:05 -07:00