- 16 Apr, 2005 40 commits
-
-
Ken Chen authored
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>
-
Bert Wesarg authored
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:
-
Bert Wesarg authored
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: -
Bharath Ramesh authored
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:
-
Jens Axboe authored
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:
-
Paolo 'Blaisorblade' Giarrusso authored
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:
-
Alexander Nyberg authored
Fix some smp_processor_id-in-preemptible warnings Signed-off-by:
-
Pavel Machek authored
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:
-
Pavel Machek authored
This fixes u32 vs. pm_message_t confusion in remaining places. Fortunately there's few of them. Signed-off-by:
-
Pavel Machek authored
This fixes u32 vs. pm_message_t confusion in drivers/video. Should change no code. Signed-off-by:
-
Pavel Machek authored
-rc2-mm1 still contains few places where u32 and pm_message_t. This fixes drivers/serial [should change no code]. Signed-off-by:
-
Pavel Machek authored
This updates video.txt documentation with information about few more systems. Signed-off-by:
-
Pavel Machek authored
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:
-
Pavel Machek authored
This fixes drivers/pci (mostly pcie stuff). Signed-off-by:
-
Pavel Machek authored
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 authored
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 authored
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 authored
This fixes u32 vs. pm_message_t in drivers/mmc, drivers/mtd and drivers/scsi. Signed-off-by:
-
Pavel Machek authored
This fixes u32 vs. pm_message_t in drivers/message. Signed-off-by:
-
Pavel Machek authored
Here are fixes for drivers/media. Signed-off-by:
-
Pavel Machek authored
This fixes u32 vs. pm_message_t in pcmcia. Signed-off-by:
-
Pavel Machek authored
This fixes remaining u32s in drivers/ net. Signed-off-by:
-
Pavel Machek authored
Here are fixes for drivers/char. Signed-off-by:
-
Pavel Machek authored
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:
-
Yoshinori Sato authored
- page.h: fix build error - unistd.h: _syscall macro cleanup. Signed-off-by:
-
Siddha, Suresh B authored
- 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:
-
Andi Kleen authored
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:
-
Andi Kleen authored
It was confusingly named. Signed-off-by:
-
Andi Kleen authored
Add acpi_skip_timer_override option. It was missing previously. Signed-off-by:
-
Andi Kleen authored
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 authored
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:
Rafael J. Wysocki <rjw@sisk.pl> Signed-off-by:
-
Andi Kleen authored
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: -
Andi Kleen authored
Signed-off-by:
-
Andi Kleen authored
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 authored
This might save memory on some Opteron systems without AGP bridge. Signed-off-by:
-
Andi Kleen authored
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:
-
Siddha, Suresh B authored
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:
-
Andi Kleen authored
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 authored
Remove excessive stack allocation in MCE code with large NR_CPUS Signed-off-by:
-
Andi Kleen authored
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:
-
