summaryrefslogtreecommitdiffstats
AgeCommit message (Collapse)AuthorFilesLines
2005-04-16[PATCH] pci enumeration on ixp2000: overflow in kernel/resource.cLennert Buytenhek1-1/+1
IXP2000 (ARM-based) platforms use a separate 'struct resource' for PCI MEM space. Resource allocation for PCI BARs always fails because the 'root' resource (the IXP2000 PCI MEM resource) always has the entire address space (00000000-ffffffff) free, and find_resource() calculates the size of that range as ffffffff-00000000+1=0, so all allocations fail because it thinks there is no space. (akpm: pls. double-check) Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-04-16[PATCH] CREDITS updateColin Leroy1-1/+2
Update Colin's credits entry. Signed-off-by: Colin Leroy <colin@colino.net> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-04-16[PATCH] Add dontdiff fileRandy.Dunlap1-0/+137
Add a current 'dontdiff' file for use with 'diff -X dontdiff'. Signed-off-by: Randy Dunlap <rddunlap@osdl.org> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-04-16[PATCH] update maintainer for /dev/randomMatt Mackall3-1/+7
Ted has agreed to let me take over as maintainer of /dev/random and friends. I've gone ahead and added a line to his entry in CREDITS. Signed-off-by: Matt Mackall <mpm@selenic.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-04-16[PATCH] opl3sa2: MODULE_PARM_DESCMagnus Damm1-1/+1
opl3sa2: Fix "irq"-parameter name typo for parameter description. Signed-off-by: Magnus Damm <damm@opensource.se> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-04-16[PATCH] add Big Endian variants of ioread/iowriteJames Bottomley3-0/+93
In the new io infrastructure, all of our operators are expecting the underlying device to be little endian (because the PCI bus, their main consumer, is LE). However, there are a fair few devices and busses in the world that are actually Big Endian. There's even evidence that some of these BE bus and chip types are attached to LE systems. Thus, there's a need for a BE equivalent of our io{read,write}{16,32} operations. The attached patch adds this as io{read,write}{16,32}be. When it's in, I'll add the first consume (the 53c700 SCSI chip driver). Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-04-16[PATCH] efi: eliminate bad section referencesmaximilian attems1-2/+2
Randy please double check especially this one. there may be a better solution. Fix efi section references: remove __initdata for struct efi efi_phys and struct efi_memory_map memmap Error: ./arch/i386/kernel/efi.o .text refers to 000000d3 R_386_32 .init.data Error: ./arch/i386/kernel/efi.o .text refers to 000000ff R_386_32 .init.data efi_memmap_walk (which is not __init nor static) accesses both efi_phys and memmap. Signed-off-by: maximilian attems <janitor@sternwelten.at> Acked-by: Randy Dunlap <rddunlap@osdl.org> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-04-16[PATCH] hd: eliminate bad section referencesmaximilian attems1-1/+1
Fix hd section references: make parse_hd_setup() __init Error: ./drivers/ide/legacy/hd.o .text refers to 00000943 R_386_PC32 .init.text Signed-off-by: maximilian attems <janitor@sternwelten.at> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-04-16[PATCH] pnpbios: eliminate bad section referencesmaximilian attems1-1/+1
one of the last buildcheck errors on i386, thanks Randy again for double checking. Fix pnpbios section references: make dmi_system_id pnpbios_dmi_table __initdata Error: ./drivers/pnp/pnpbios/core.o .data refers to 00000100 R_386_32 .init.text Error: ./drivers/pnp/pnpbios/core.o .data refers to 0000012c R_386_32 .init.text Signed-off-by: maximilian attems <janitor@sternwelten.at> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-04-16[PATCH] Fix comment in list.h that refers to nonexistent APIPaul E. McKenney1-1/+1
The hlist_for_each_entry_rcu() comment block refers to a nonexistent hlist_add_rcu() API, needs to change to hlist_add_head_rcu(). Signed-off-by: Paul E. McKenney <paulmck@us.ibm.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-04-16[PATCH] Direct IO async short read fixDaniel McNeil1-3/+17
The direct I/O code is mapping the read request to the file system block. If the file size was not on a block boundary, the result would show the the read reading past EOF. This was only happening for the AIO case. The non-AIO case truncates the result to match file size (in direct_io_worker). This patch does the same thing for the AIO case, it truncates the result to match the file size if the read reads past EOF. When I/O completes the result can be truncated to match the file size without using i_size_read(), thus the aio result now matches the number of bytes read to the end of file. Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-04-16[PATCH] undo do_readv_writev() behavior changeDave Hansen1-2/+2
Bugme bug 4326: http://bugme.osdl.org/show_bug.cgi?id=4326 reports: executing the systemcall readv with Bad argument ->len == -1) it gives out error EFAULT instead of EINVAL Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-04-16[PATCH] officially deprecate register_ioctl32_conversionChristoph Hellwig2-2/+12
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[PATCH] kill #ifndef HAVE_ARCH_GET_SIGNAL_TO_DELIVER in signal.cChristoph Hellwig1-4/+0
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[PATCH] quota: possible bug in quota format v2 supportNiu YaWei1-1/+2
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[PATCH] quota: fix possible oops on quotaoffJan Kara1-0/+1
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[PATCH] ext2 corruption - regression between 2.6.9 and 2.6.10Bernard Blackham3-3/+15
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[PATCH] fix up newly added jsm driverChristoph Hellwig3-311/+91
- 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[PATCH] use cheaper elv_queue_empty when unplug a deviceKen Chen1-1/+2
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[PATCH] fix module_param_string() callsBert Wesarg2-3/+3
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[PATCH] kernel/param.c: don't use .max when .num is NULL in param_array_set()Bert Wesarg1-1/+2
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[PATCH] AYSNC IO using singals other than SIGIOBharath Ramesh1-1/+1
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[PATCH] possible use-after-free of bioJens Axboe1-2/+3
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[PATCH] uml: fix compilation for __CHOOSE_MODE additionPaolo 'Blaisorblade' Giarrusso1-17/+10
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[PATCH] swsusp: SMP fixAlexander Nyberg1-2/+2
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[PATCH] fix few remaining u32 vs. pm_message_t problemsPavel Machek1-1/+1
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[PATCH] fix u32 vs. pm_message_t in rest of the treePavel Machek6-6/+6
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[PATCH] fix u32 vs. pm_message_t in driver/videoPavel Machek5-6/+6
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[PATCH] fix u32 vs. pm_message_t in drivers/Pavel Machek8-8/+8
-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[PATCH] power/video.txt: update documentation with more systemsPavel Machek1-7/+8
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[PATCH] u32 vs. pm_message_t in ppc and radeonPavel Machek4-4/+4
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[PATCH] fix u32 vs. pm_message_t in PCI, PCIEPavel Machek6-9/+9
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[PATCH] fix u32 vs. pm_message_t in drivers/macintoshPavel Machek2-2/+2
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[PATCH] Fix u32 vs. pm_message_t in x86-64Pavel Machek5-5/+5
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[PATCH] fix pm_message_t vs. u32 in alsaPavel Machek2-4/+4
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[PATCH] fix u32 vs. pm_message_t in drivers/mmc,mtd,scsiPavel Machek7-11/+11
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[PATCH] fix u32 vs. pm_message_t in drivers/messagePavel Machek3-4/+4
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[PATCH] fix u32 vs. pm_message_t in drivers/mediaPavel Machek5-6/+6
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[PATCH] fix u32 vs. pm_message_t in pcmciaPavel Machek8-8/+8
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[PATCH] u32 vs. pm_message_t fixes for drivers/netPavel Machek15-19/+19
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[PATCH] Fix u32 vs. pm_message_t in drivers/charPavel Machek5-5/+5
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[PATCH] pm_message_t: more fixes in common and i386Pavel Machek11-14/+17
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[PATCH] h8300 header updateYoshinori Sato2-147/+139
- 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[PATCH] x86, x86_64: dual core proc-cpuinfo and sibling-map fixSiddha, Suresh B3-16/+6
- 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[PATCH] x86_64: Switch SMP bootup over to new CPU hotplug state machineAndi Kleen7-389/+371
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[PATCH] x86_64: Rename the extended cpuid level fieldAndi Kleen2-8/+7
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[PATCH] x86_64: Add acpi_skip_timer_override optionAndi Kleen1-0/+4
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[PATCH] x86_64: Rewrite exception stack backtracingAndi Kleen1-68/+79
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[PATCH] x86_64: Final support for AMD dual coreAndi Kleen3-44/+53
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[PATCH] x86_64: add support for Intel dual-core detection and displayingAndi Kleen10-32/+163
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>