- 21 Oct, 2005 7 commits
-
-
Al Viro authored
Signed-off-by:
Al Viro <viro@zeniv.linux.org.uk> Signed-off-by:
Jeff Garzik <jgarzik@pobox.com>
-
Al Viro authored
Signed-off-by:
-
Al Viro authored
Signed-off-by:
-
Al Viro authored
sata_qstor strays into a nasty area - gcc handling of wide enums is full of bugs that got fixed between gcc versions creating portability nightmare. Single-member enums are safe, so are ones that stay within the range of int or unsigned int. Anything beyond that is asking for trouble. Declaration of constants split in two enums, taking the ~0UL one into a separate enum. Signed-off-by:
-
Al Viro authored
Signed-off-by:
-
Al Viro authored
Signed-off-by:
-
Al Viro authored
Signed-off-by:
-
- 20 Oct, 2005 18 commits
-
-
Brett Russ authored
Jeff found an endian bug in the Marvell driver (thanks!). Here's the fix for it. Signed-off-by:
Brett Russ <russb@emc.com> Signed-off-by:
-
Jeff Garzik authored
-
Linus Torvalds authored
The -rc4 release was supposed to be the last -rc, but here goes. The RCU fixes and the swiotlb changes need an -rc for final testing.
-
Al Viro authored
Missing half of the [PATCH] uml: Fix sysrq-r support for skas mode We need to remove these (UPT_[DEFG]S) from the read side as well as the write one - otherwise it simply won't build. Signed-off-by:
Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it> Acked-by:
Jeff Dike <jdike@addtoit.com> Signed-off-by:
Linus Torvalds <torvalds@osdl.org>
-
Steven Rostedt authored
Found in the -rt patch set. The scsi_error thread likely will be in the TASK_INTERRUPTIBLE state upon exit. This patch fixes this bug. Signed-off-by:
Steven Rostedt <rostedt@goodmis.org> Signed-off-by:
-
Paul Mackerras authored
Signed-off-by:
Paul Mackerras <paulus@samba.org> Signed-off-by:
-
Linus Torvalds authored
-
Yasunori Goto authored
This introduces a limit parameter to the core bootmem allocator; The new parameter indicates that physical memory allocated by the bootmem allocator should be within the requested limit. We also introduce alloc_bootmem_low_pages_limit, alloc_bootmem_node_limit, alloc_bootmem_low_pages_node_limit apis, but alloc_bootmem_low_pages_limit is the only api used for swiotlb. The existing alloc_bootmem_low_pages() api could instead have been changed and made to pass right limit to the core allocator. But that would make the patch more intrusive for 2.6.14, as other arches use alloc_bootmem_low_pages(). We may be done that post 2.6.14 as a cleanup. With this, swiotlb gets memory within 4G for both x86_64 and ia64 arches. Signed-off-by:
Yasunori Goto <y-goto@jp.fujitsu.com> Cc: Ravikiran G Thirumalai <kiran@scalex86.org> Signed-off-by:
-
Peter Chubb authored
In drivers/acpi/glue.c the address of an integer is cast to the address of an unsigned long. This breaks on systems where a long is larger than an int --- for a start the int can be misaligned; for a second the assignment through the pointer will overwrite part of the next variable. Signed-off-by:
Peter Chubb <peterc@gelato.unsw.edu.au> Acked-by:
"Brown, Len" <len.brown@intel.com> Signed-off-by:
Andrew Morton <akpm@osdl.org> Signed-off-by:
-
Dave Airlie authored
I've gotten a report on lkml, of a possible regression in the MGA DRM in 2.6.14-rc4 (since -rc1), I haven't been able to reproduce it here, but I've figured out some possible issues in the mga code that were definitely wrong, some of these are from DRM CVS, the main fix is the agp enable bit on the old code path still used by everyone..... Signed-off-by:
Dave Airlie <airlied@linux.ie> Signed-off-by:
-
Alan Stern authored
The PF_NOFREEZE process flag should not be inherited when a thread is forked. This patch (as585) removes the flag from the child. This problem is starting to show up more and more as drivers turn to the kthread API instead of using kernel_thread(). As a result, their kernel threads are now children of the kthread worker instead of modprobe, and they inherit the PF_NOFREEZE flag. This can cause problems during system suspend; the kernel threads are not getting frozen as they ought to be. Signed-off-by:
Alan Stern <stern@rowland.harvard.edu> Acked-by:
Pavel Machek <pavel@ucw.cz> Signed-off-by:
-
Tom Rini authored
The variable RCS_TAR_IGNORE is used in scripts/packaging/Makefile, but not exported from the main Makefile, so it's never used. This results in the rpm targets being very unhappy in quilted trees. Signed-off-by:
Tom Rini <trini@kernel.crashing.org> Acked-by:
Sam Ravnborg <sam@ravnborg.org> Signed-off-by:
-
Benjamin Herrenschmidt authored
The implementation of __kernel_gettimeofday() in the 32 bits vDSO has a small bug (a typo actually) that will cause it to lose 1 bit of precision. Not terribly bad but worth fixing. Signed-off-by:
Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by:
-
NeilBrown authored
The main problem fixes is that in certain situations stopping md arrays may take longer than you expect, or may require multiple attempts. This would only happen when resync/recovery is happening. This patch fixes three vaguely related bugs. 1/ The recent change to use kthreads got the setting of the process name wrong. This fixes it. 2/ The recent change to use kthreads lost the ability for md threads to be signalled with SIG_KILL. This restores that. 3/ There is a long standing bug in that if: - An array needs recovery (onto a hot-spare) and - The recovery is being blocked because some other array being recovered shares a physical device and - The recovery thread is killed with SIG_KILL Then the recovery will appear to have completed with no IO being done, which can cause data corruption. This patch makes sure that incomplete recovery will be treated as incomplete. Note that any kernel affected by bug 2 will not suffer the problem of bug 3, as the signal can never be delivered. Thus the current 2.6.14-rc kernels are not susceptible to data corruption. Note also that if arrays are shutdown (with "mdadm -S" or "raidstop") then the problem doesn't occur. It only happens if a SIGKILL is independently delivered as done by 'init' when shutting down. Signed-off-by:Neil Brown <neilb@suse.de> Signed-off-by:
-
Andy Wingo authored
Changes all spinlocks that can be held during an irq handler to disable interrupts while the lock is held. Changes spin_[un]lock_irq to use the irqsave/irqrestore variants for robustness and readability. In raw1394.c:handle_iso_listen(), don't grab host_info_lock at all -- we're not accessing host_info_list or host_count, and holding this lock while trying to tasklet_kill the iso tasklet this can cause an ABBA deadlock if ohci:dma_rcv_tasklet is running and tries to grab host_info_lock in raw1394.c:receive_iso. Test program attached reliably deadlocks all SMP machines I have been able to test without this patch. Signed-off-by:
Andy Wingo <wingo@pobox.com> Acked-by:
Ben Collins <bcollins@ubuntu.com> Signed-off-by:
-
Andrew Morton authored
Brice Goglin <Brice.Goglin@ens-lyon.org> reports a printk storm from this driver. Fix. Acked-by:
David Gibson <hermes@gibson.dropbear.id.au> Cc: Jeff Garzik <jgarzik@pobox.com> Signed-off-by:
-
Hugh Dickins authored
hugetlbfs allows truncation of its files (should it?), but hugetlb.c often forgets that: crashes and misaccounting ensue. copy_hugetlb_page_range better grab the src page_table_lock since we don't want to guess what happens if concurrently truncated. unmap_hugepage_range rss accounting must not assume the full range was mapped. follow_hugetlb_page must guard with page_table_lock and be prepared to exit early. Restyle copy_hugetlb_page_range with a for loop like the others there. Signed-off-by:
Hugh Dickins <hugh@veritas.com> Signed-off-by:
-
Roland McGrath authored
Oleg Nesterov reported an SMP deadlock. If there is a running timer tracking a different process's CPU time clock when the process owning the timer exits, we deadlock on tasklist_lock in posix_cpu_timer_del via exit_itimers. That code was using tasklist_lock to check for a race with __exit_signal being called on the timer-target task and clearing its ->signal. However, there is actually no such race. __exit_signal will have called posix_cpu_timers_exit and posix_cpu_timers_exit_group before it does that. Those will clear those k_itimer's association with the dying task, so posix_cpu_timer_del will return early and never reach the code in question. In addition, posix_cpu_timer_del called from exit_itimers during execve or directly from timer_delete in the process owning the timer can race with an exiting timer-target task to cause a double put on timer-target task struct. Make sure we always access cpu_timers lists with sighand lock held. Signed-off-by:
Roland McGrath <roland@redhat.com> Signed-off-by:
Chris Wright <chrisw@osdl.org> Signed-off-by:
-
- 19 Oct, 2005 2 commits
-
-
Tony Lindgren authored
Patch from Tony Lindgren Machine restart calls cpu_proc_fin() to clean and disable cache, and turn off interrupts. This patch adds proper cpu_v6_proc_fin. Signed-off-by:
Tony Lindgren <tony@atomide.com> Signed-off-by:
Russell King <rmk+kernel@arm.linux.org.uk>
-
Seth, Rohit authored
The hugetlb pages are currently pre-faulted. At the time of mmap of hugepages, we populate the new PTEs. It is possible that HW has already cached some of the unused PTEs internally. These stale entries never get a chance to be purged in existing control flow. This patch extends the check in page fault code for hugepages. Check if a faulted address falls with in size for the hugetlb file backing it. We return VM_FAULT_MINOR for these cases (assuming that the arch specific page-faulting code purges the stale entry for the archs that need it). Signed-off-by:
Rohit Seth <rohit.seth@intel.com> [ This is apparently arguably an ia64 port bug. But the code won't hurt, and for now it fixes a real problem on some ia64 machines ] Signed-off-by:
-
- 18 Oct, 2005 13 commits
-
-
Albert Lee authored
problem: id[53-58] might be changed after initializing device CHS settings. changes: - call ata_dev_reread_id() to reread the identify device info, after initializing device CHS settings. Signed-off-by:Albert Lee <albertcc@tw.ibm.com> ============ Signed-off-by:
-
Albert Lee authored
- merge ata_prot_to_cmd() and ata_dev_set_protocol() as ata_rwcmd_protocol() - pave road for read/write multiple support - remove usage of pre-cached command and protocol values and call ata_rwcmd_protocol() instead Signed-off-by: -
Albert Lee authored
move the initialization of taskfile LBA flags "ATA_TFLAG_LBA" and "ATA_TFLAG_LBA48 flags" to the SCSI translation functions Signed-off-by: -
Jeff Garzik authored
-
Paul Schulz authored
Patch from Paul Schulz The following trivial patch is to fix what looks like a typo in the PXA register definitions. The correction comes directly from the definition in the Intel Documentation. http://www.intel.com/design/pca/applicationsprocessors/manuals/278693.htm Intel(R) PXA 255 Processor - Developers Manual - Jan 2004 - Page 12-33 Neither 'UDCCS_IO_ROF' or 'UDCCS_IO_DME' are currently used elseware in the main code (from grep of tree)... The current definitions have been in the code since at lease 2.4.7. Signed-off-by:
Paul Schulz <paul@mawsonlakes.org> Signed-off-by:
-
Antonino A. Daplas authored
Reported by: Bob Tracy <rct@gherkin.frus.com> "...I've got a Toshiba notebook (730XCDT -- Pentium 150MMX) for which I'm using the Vesa FB driver. When the machine has been idle for some time and the driver attempts to powerdown the display, rather than the display going blank, it goes gray with several strange lines. When I hit the "shift" key or other-wise wake up the display, the old video state is not fully restored..." vesafb recently added a blank method which has only 2 states, powerup and powerdown. The powerdown state is used for all blanking levels, but in his case, powerdown does not work correctly for higher levels of display powersaving. Thus, for intermediate power levels, use software blanking, and use only hardware blanking for an explicit powerdown. Signed-off-by:
Antonino Daplas <adaplas@pol.net> Signed-off-by:
-
Linus Torvalds authored
-
Linus Torvalds authored
-
Linus Torvalds authored
This still leaves driver and architecture-specific subdirectories alone, but gets rid of the bulk of the "generic" generated files that we should ignore. Signed-off-by: -
Kenneth Tan authored
Patch from Kenneth Tan The get_irqnr_and_base subroutine of ixp4xx does not take interrupt 0 condition into account properly. We should not perform "subs" here. The Z flag will be set when interrupt 0 occur, which resulting "movne r1, sp" in the caller routine (irq_handler) not being executed. When interrupt 0 occur: o if CONFIG_CPU_IXP46X is not set, "subs" will set the Z flag and return o if CONFIG_CPU_IXP46X is set, codes in upper interrupt handling will be trigerred. But since this is not supper interrupt, the "cmp" in the upper interrupt handling portion will set the Z flag and return Signed-off-by:
Kenneth Tan <chong.yin.tan@intel.com> Signed-off-by:
-
Kenneth Tan authored
Patch from Kenneth Tan The cpu_is_ixp465 macro in include/asm-arm/arch-ixp4xx/hardware.h is always returning 0 because #ifdef CONFIG_CPU_IXP465 is always false. Signed-off-by:
-
Nicolas Pitre authored
Patch from Nicolas Pitre Signed-off-by:
Nicolas Pitre <nico@cam.org> Signed-off-by:
-
Ben Dooks authored
Patch from Ben Dooks Check that the device we are looking at is really a platform device before trying to cast it to one to find out the platform bus number. Thanks to RMK for pointing this out. Signed-off-by:
Ben Dooks <ben-linux@fluff.org> Signed-off-by:
-
