- 17 May, 2005 34 commits
-
-
Suresh Siddha authored
Use bitmap_zero instead of bitmap_empty to initialise cpu mask This makes it actually run reliable instead of relying on stack state. 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>
-
Andi Kleen authored
The PTEs can point to ioremap mappings too, and these are often outside mem_map. The NUMA hash page lookup functions cannot handle out of bounds accesses properly. Signed-off-by:
-
Andi Kleen authored
Allowed user programs to set a non canonical segment base, which would cause oopses in the kernel later. Credit-to: Alexander Nyberg <alexn@dsv.su.se> For identifying and reporting this bug. Signed-off-by:
-
Andi Kleen authored
This works around an AMD Erratum. Signed-off-by:
-
Andi Kleen authored
There are unfortunately more and more multi processor Opteron systems which don't have HPET timer support in the southbridge. This covers in particular Nvidia and VIA chipsets. They also don't guarantee that the TSCs are synchronized between CPUs; and especially with MP powernow the systems are nearly unusable because the time gets very inconsistent between CPUs. The timer code for x86-64 was originally written under the assumption that we could fall back to the HPET timer on such systems. But this doesn't work there. Another alternative is to use the ACPI PM timer as primary time source. This patch does that. The kernel only uses PM timer when there is no other choice because it has some disadvantages. Ported over from i386. It should be faster than the i386 version because I dropped the "read three times" workaround, but is still considerable slower than HPET and also does not work together with vsyscalls which have to be disabled. Cc: <mark.langsdorf@amd.com> Signed-off-by:
-
Andi Kleen authored
It is unnecessary on modern Intel or AMD systems, and that is all we support on x86-64 Also causes problems on various systems Signed-off-by:
-
Andi Kleen authored
It is not very useful to the user and more an kernel internal implementation detail. So hide it. Signed-off-by:
-
Andi Kleen authored
Remove x86_apicid field Signed-off-by:
-
Andi Kleen authored
The new TSC sync algorithm recently submitted did not work too well. The result was that some MP machines where the TSC came up of the BIOS very unsynchronized and that did not have HPET support were nearly unusable because the time would jump forwards and backwards between CPUs. After a lot of research ;-) and some more prototypes I ended up with just using the one from IA64 which looks best. It has some internal self tuning that should adapt to changing interconnect latencies. It holds up in my tests so far. I believe it was originally written by David Mosberger, I just ported it over to x86-64. See the inline comment for a description. This cleans up the code because it uses smp_call_function for syncing instead of having custom hooks in SMP bootup. Please note that the cycle numbers it outputs are too optimistic because they do not take into account the latency of WRMSR and RDTSC, which can be hundreds of cycles. It seems to be able to sync a dual Opteron to 200-300 cycles, which is probably good enough. There is a timing window during AP bootup where interrupts can see inconsistent time before the TSC is synced. It is hard to avoid unfortunately because we can only do the TSC sync after some setup, and we need to enable interrupts before that. I just ignored it for now. Signed-off-by:
-
Andi Kleen authored
It could be in a memory hole not mapped in mem_map and that causes the hash lookup to go off to nirvana. Signed-off-by:
-
Andi Kleen authored
Needed by big systems and only costs a few K of memory. Signed-off-by:
-
Andi Kleen authored
Last round hopefully of cpu_core_id changes hopefully fow now: - Always initialize cpu_core_id for all CPUs, even when no dual core setup is detected. This prevents funny /proc/cpuinfo output - Do the same with phys_proc_id[] even when no HyperThreading - dito. - Use the CPU APIC-ID from CPUID 1 instead of the linux virtual CPU number to identify the core for AMD dual core setups. Patch for i386/x86-64. Signed-off-by:
-
Andi Kleen authored
This works around a bug in the AMD K8 CPUs. Signed-off-by:
-
Andi Kleen authored
Cleans up the system exit call slightly and synchronizes with my tree again. Signed-off-by:
-
Andi Kleen authored
NR_CPUs can be quite big these days. kmalloc the per CPU array instead of putting it onto the stack Signed-off-by:
-
Kirill Korotaev authored
This patch fixes mm->total_vm and mm->locked_vm acctounting in case when move_page_tables() fails inside move_vma(). Signed-Off-By:
Kirill Korotaev <dev@sw.ru> Signed-off-by:
-
Bjorn Steinbrink authored
This patch fixes a bug introduced by the "mm counter operations through macros" patch, which replaced a decrement operation in with an increment macro in try_to_unmap_one(). Signed-off-by:
Björn Steinbrink <B.Steinbrink@gmx.de> Signed-off-by:
-
NeilBrown authored
We we set the too early, they may still be in place and possibly get called even though the array didn't get set up properly. Signed-off-by:
Neil Brown <neilb@cse.unsw.edu.au> Signed-off-by:
-
NeilBrown authored
When a request crosses a boundary between devices, it needs to be split. But where we should calculate the amount of the request before the boundary to find the split-point, we care currently calculating the amount that is *after* the boundary !!! Signed-off-by:
-
Paolo 'Blaisorblade' Giarrusso authored
Replace one memcpy() call with overlapping source and dest arguments with one call to memmove(), to avoid data corruption. Signed-off-by:
Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it> Signed-off-by:
-
Paolo 'Blaisorblade' Giarrusso authored
Actually remove elf.h in the tree. The previous patch, due to a quilt bug/misuse, left it in the tree as a 0-length file, preventing the build to see it as missing and to generate a symlink in its place. Signed-off-by:
-
Peter Lundkvist authored
Additional i8xx_tco device support. Cc: David Hardeman <david@2gen.com> Cc: <wim@iguana.be> Signed-off-by:
-
Zhang, Yanmin authored
Kernel 2.6 has an ide proc destroy error. Run #modprobe ide-core and #rmmod ide-core, then kernel will dump stack information like below. **********Log****************** Badness in remove_proc_entry at fs/proc/generic.c:693 Call Trace: [<a0000001000117e0>] show_stack+0x80/0xa0 sp=3De0000003e05dfbe0 = bsp=3De0000003e05d0ea8 [<a0000001000120b0>] dump_stack+0x30/0x60 sp=3De0000003e05dfdb0 = bsp=3De0000003e05d0e90 [<a000000100183090>] remove_proc_entry+0x530/0x540 sp=3De0000003e05dfdb0 = bsp=3De0000003e05d0e20 [<a000000221cbd280>] proc_ide_destroy+0x120/0x140 [ide_core] sp=3De0000003e05dfdc0 = bsp=3De0000003e05d0df0 [<a000000221ca65f0>] cleanup_module+0x50/0xa0 [ide_core] sp=3De0000003e05dfdc0 = bsp=3De0000003e05d0dd0 [<a0000001000a9e10>] sys_delete_module+0x390/0x580 sp=3De0000003e05dfdc0 = bsp=3De0000003e05d0d50 [<a00000010000af40>] ia64_ret_from_syscall+0x0/0x20 sp=3De0000003e05dfe30 = bsp=3De0000003e05d0d50 [<a000000000010640>] _stext+0xffffffff00010640/0x400 sp=3De0000003e05e0000 = bsp=3De0000003e05d0d50 Signed-off-by:Zhang Yanmin <yanmin.zhang@intel.com> Cc: Bartlomiej Zolnierkiewicz <B.Zolnierkiewicz@elka.pw.edu.pl> Cc: Greg KH <greg@kroah.com> Signed-off-by:
-
Hugh Dickins authored
VmallocTotal: 34359738367 kB VmallocUsed: 266288 kB VmallocChunk: 18014366299193295 kB is unsettling - x86_64 and some other architectures keep a separate address range for modules in vmalloc's vmlist, which /proc/meminfo should pass over. Signed-off-by:
Hugh Dickins <hugh@veritas.com> Signed-off-by:
-
Dmitry Torokhov authored
move serio port's id attributes into separate subdirectory: ..devices/serioX/id_type -> ..devices/serioX/id/type ..devices/serioX/id_proto -> ..devices/serioX/id/proto Signed-off-by:Dmitry Torokhov <dtor@mail.ru> Cc: Vojtech Pavlik <vojtech@suse.cz> Signed-off-by:
-
Dmitry Torokhov authored
serport - avoid calling serio_interrupt or serio_write_wakeup on unregistered port. Also fix memory leak which could happen if serport was left unused by moving serio allocation down to serport_ldisc_read. Signed-off-by:
-
Dmitry Torokhov authored
ALPS needs to be reset for detection to work reliably when reconnecting. Signed-off-by:
-
Andrew Morton authored
Make the alps printk output look consistent. Cc: Vojtech Pavlik <vojtech@suse.cz> Signed-off-by:
-
Dmitry Torokhov authored
serio - do not attempt to immediately disconnect port if resume failed, let kseriod take care of it. Otherwise we may attempt to unregister associated input devices which will generate hotplug events which are not handled well during swsusp. Signed-off-by:
-
Pete Jewell authored
This is a tiny patch that fixes bttv-cards.c so that Leadtek WinFast VC100 XP video capture cards work. I've been advised to post it here after having already posted it to the v4l mailing list. Acked-by:
Gerd Knorr <kraxel@bytesex.org> Signed-off-by:
-
Peter Osterlund authored
ioctl_by_bdev may only be used INSIDE the kernel. If the "arg" argument refers to memory that is accessed by put_user/get_user in the ioctl function, the memory needs to be in the kernel address space (that's the set_fs(KERNEL_DS) doing in the ioctl_by_bdev). This works on i386 because even with set_fs(KERNEL_DS) the user space memory is still accessible with put_user/get_user. That is not true for s390. In short the ioctl implementation of the pktcdvd device driver is horribly broken. Signed-off-by:
Peter Osterlund <petero2@telia.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Stephen Tweedie authored
[Patch] Fix raw device ioctl pass-through Raw character devices are supposed to pass ioctls through to the block devices they are bound to. Unfortunately, they are using the wrong function for this: ioctl_by_bdev(), instead of blkdev_ioctl(). ioctl_by_bdev() performs a set_fs(KERNEL_DS) before calling the ioctl, redirecting the user-space buffer access to the kernel address space. This is, needless to say, a bad thing. This was noticed first on s390, where raw IO was non-functioning. The s390 driver config does not actually allow raw IO to be enabled, which was the first part of the problem. Secondly, the s390 kernel address space is distinct from user, causing legal raw ioctls to fail. I've reproduced this on a kernel built with 4G:4G split on x86, which fails in the same way (-EFAULT if the address does not exist kernel-side; returns success without actually populating the user buffer if it does.) The patch below fixes both the config and address-space problems. It's based closely on a patch by Jan Glauber <jang@de.ibm.com>, which has been tested on s390 at IBM. I've tested it on x86 4G:4G (split address space) and x86_64 (common address space). Kernel-address-space access has been assigned CAN-2005-1264. Signed-off-by:
Stephen Tweedie <sct@redhat.com> Signed-off-by:
Dave Jones <davej@redhat.com> Signed-off-by:
-
Greg Kroah-Hartman authored
As reported by Paul Starzetz <ihaquer@isec.pl> Reference: CAN-2005-1263 Signed-off-by: -
Linus Torvalds authored
-
- 16 May, 2005 6 commits
-
-
Russell King authored
Mainline kernels don't have VECTORS_HIGH nor COPYPAGE_MINICACHE yet. Signed-off-by:Russell King <rmk@arm.linux.org.uk>
-
Linus Torvalds authored
-
Linus Torvalds authored
-
Daniel Andersen authored
Version 2 of the 3com OfficeConnect 11g Cardbus Card aka 3CRWE154G72 is not supported by the prism54 project. To stop confusion, the kernel documentation should state so as 3com made a good job hiding the version. Signed-off-by: -
Jiri Benc authored
This patch fixes a typo in tulip driver in 2.6.12-rc3.
-
Geoff Levand authored
Fix IBM EMAC driver ioctl bug. I found IBM EMAC driver bug. So mii-tool command print wrong status. # mii-tool eth0: 10 Mbit, half duplex, no link eth1: 10 Mbit, half duplex, no link I can get correct status on fixed kernel. # mii-tool eth0: negotiated 100baseTx-FD, link okZZ eth1: negotiated 100baseTx-FD, link ok Hiroaki Fuse Signed-off-by: Geoff Levand <geoffrey.levand@am.sony.com> for CELF
-
