- 20 Oct, 2005 7 commits
-
-
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:
Andrew Morton <akpm@osdl.org> Signed-off-by:
Linus Torvalds <torvalds@osdl.org>
-
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 1 commit
-
-
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 14 commits
-
-
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:
Russell King <rmk+kernel@arm.linux.org.uk>
-
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:
-
Mark Rustad authored
The following build error happens with 2.6.14-rc4 when CONFIG_KALLSYMS is not defined. The error message in a fragment of the output was: CC arch/i386/lib/usercopy.o AR arch/i386/lib/lib.a /bin/sh: line 1: +@: command not found make[3]: warning: jobserver unavailable: using -j1. Add `+' to parent make rule. CHK include/linux/compile.h Signed-off-by:
Mark Rustad <mrustad@mac.com> Signed-off-by:
-
Zach Brown authored
lock_kiocb() was introduced to serialize retrying and cancellation. In the process of doing so it tried to sleep waiting for KIF_LOCKED while holding the ctx_lock spinlock. Recent fixes have ensured that multiple concurrent retries won't be attempted for a given iocb. Cancel has other problems and has no significant in-tree users that have been complaining about it. So for the immediate future we'll revert sleeping with the lock held and will address proper cancellation and retry serialization in the future. Signed-off-by:
Zach Brown <zach.brown@oracle.com> Acked-by:
Benjamin LaHaise <bcrl@kvack.org> Signed-off-by:
-
Dmitry Torokhov authored
Only signal completion after marking request slot as free, otherwise other processor can free request structure before we finish using it. Signed-off-by:
Dmitry Torokhov <dtor@mail.ru> Signed-off-by:
-
Pavel Machek authored
Fix -EIO on /proc/acpi/events after suspends. This actually breaks suspending by power button in many setups. Signed-off-by:
Pavel Machek <pavel@suse.cz> Signed-off-by:
-
Stephan Brodkorb authored
Since Revision 1.10 was released the n_r3964 module wasn't able to receive any data. The reason for that behavior is because there were some wrong calls of mod_timer(...) in the function receive_char (...). This patch should fix this problem and was successfully tested with talking to some kuka industrial robots. Signed-off-by:
-
David McCullough authored
Currently you do not get all the map entries on nommu systems because the start function doesn't index into the list using the value of "pos". Signed-off-by:
David McCullough <davidm@snapgear.com> Signed-off-by:
-
- 17 Oct, 2005 13 commits
-
-
Eric Dumazet authored
This makes call_rcu() keep track of how many events there are on the RCU list, and cause a reschedule event when the list gets too long. This helps keep RCU event lists down. Signed-off-by: -
Jeff Garzik authored
This change makes quirk_intel_ide_combined() dependent on the precise conditions under which it is needed: * IDE is built in * IDE SATA option is not set * ata_piix or ahci drivers are enabled This fixes an issue where some modular configurations would not cause the quirk to be enabled. Signed-off-by:
Jeff Garzik <jgarzik@pobox.com> Signed-off-by:
-
Oleg Nesterov authored
Make sure we release the task struct properly when releasing pending timers. release_task() does write_lock_irq(&tasklist_lock), so it can't race with run_posix_cpu_timers() on any cpu. Signed-off-by:
Oleg Nesterov <oleg@tv-sign.ru> Signed-off-by:
-
Trond Myklebust authored
Oopsable since nfs_wait_on_inode() can get called as part of iput_final(). Unnecessary since the caller had better be damned sure that the inode won't disappear from underneath it anyway. Signed-off-by:
Trond Myklebust <Trond.Myklebust@netapp.com> Signed-off-by:
-
Trond Myklebust authored
If the data cache has been marked as potentially invalid by nfs_refresh_inode, we should invalidate it rather than assume that changes are due to our own activity. Also ensure that we always start with a valid cache before declaring it to be protected by a delegation. Signed-off-by:
-
Christian Krause authored
During the development of an USB device I found a bug in the handling of Highspeed HID devices in the kernel. What happened? Highspeed HID devices are correctly recognized and enumerated by the kernel. But even if usbhid kernel module is loaded, no HID reports are received by the kernel. The output of the hardware USB analyzer told me that the host doesn't even poll for interrupt IN transfers (even the "interrupt in" USB transfer are polled by the host). After some debugging in hid-core.c I've found the reason. In case of a highspeed device, the endpoint interval is re-calculated in driver/usb/input/hid-core.c: line 1669: /* handle potential highspeed HID correctly */ interval = endpoint->bInterval; if (dev->speed == USB_SPEED_HIGH) interval = 1 << (interval - 1); Basically this calculation is correct (refer to USB 2.0 spec, 9.6.6). This new calculated value of "interval" is used as input for usb_fill_int_urb: line 1685: usb_fill_int_urb(hid->urbin, dev, pipe, hid->inbuf, 0, hid_irq_in, hid, interval); Unfortunately the same calculation as above is done a second time in usb_fill_int_urb in the file include/linux/usb.h: line 933: if (dev->speed == USB_SPEED_HIGH) urb->interval = 1 << (interval - 1); else urb->interval = interval; This means, that if the endpoint descriptor (of a high speed device) specifies e.g. bInterval = 7, the urb->interval gets the value: hid-core.c: interval = 1 << (7-1) = 0x40 = 64 urb->interval = 1 << (interval -1) = 1 << (63) = integer overflow Because of this the value of urb->interval is sometimes negative and is rejected in core/urb.c: line 353: /* too small? */ if (urb->interval <= 0) return -EINVAL; The conclusion is, that the recalculaton of the interval (which is necessary for highspeed) should not be made twice, because this is simply wrong. ;-) Re-calculation in usb_fill_int_urb makes more sense, because it is the most general approach. So it would make sense to remove it from hid-core.c. Because in hid-core.c the interval variable is only used for calling usb_fill_int_urb, it is no problem to remove the highspeed re-calculation in this file. Signed-off-by:Christian Krause <chkr@plauener.de> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de> Signed-off-by:
-
Olav Kongas authored
Increased use of scatter-gather by usb-storage driver after 2.6.13 has exposed a buggy codepath in isp116x-hcd, which was probably never visited before: bug happened only for those urbs, for which URB_SHORT_NOT_OK was set AND short transfer occurred. The fix attached was tested in 2 ways: (a) it fixed failing initialization of a flash drive with an embedded hub; (b) the fix was tested with 'usbtest' against a modified g_zero driver (on top of net2280), which generated short bulk IN transfers of various lengths including multiples and non-multiples of max_packet_length. Signed-off-by:
Olav Kongas <ok@artecdesign.ee> Signed-off-by:
-
Linus Torvalds authored
Dipankar made RCU limit the batch size to improve latency, but that approach is unworkable: it can cause the RCU queues to grow without bounds, since the batch limiter ended up limiting the callbacks. So make the limit much higher, and start planning on instead limiting the batch size by doing RCU callbacks more often if the queue looks like it might be growing too long. Signed-off-by: -
Ronald S. Bultje authored
Fix the fact that the svideo input will only give input in black/white in some circumstances. Reason is that in the PCI controller driver (zr36067), after setting input, we reset norm, which overwrites the input register with the default. This patch makes it always set the correct value for the input when changing norm. Signed-off-by:
Ronald S. Bultje <rbultje@ronald.bitfreak.net> Signed-off-by:
-
Ronald S. Bultje authored
Fix bug #5404 in kernel bugzilla. It basically updates the vpx3220 initialization tables with some newer values that we've had in CVS for a while (and that, for some reason, never ended up in the kernel... must've gotten lost). Those fix a ~16 pixels noise at the top of the picture in at least SECAM, although (now that I think about it) PAL was probably affected, also. Signed-off-by:
-
Samuel Thibault authored
Fix bug 5441. I didn't know about messy programs like svgatextmode... Couldn't this be integrated in some linux/drivers/video/console/svgacon.c ?... So because of the existence of the svgatextmode program, the kernel is not supposed to touch to CRT_OVERFLOW/SYNC_END/DISP/DISP_END/OFFSET ? Disabling the check in vgacon_resize() might help indeed, but I'm really not sure whether it will work for any chipset: in my patch, CRT registers are set at each console switch, since stty rows/cols apply to consoles separately... The attached solution is to keep the test, but if it fails, we assume that the caller knows what it does (i.e. it is svgatextmode) and then disable any further call to vgacon_doresize. Svgatextmode is usually used to _expand_ the display, not to shrink it. And it is harmless in the case of a too big stty rows/cols: the display will just be cropped. I tested it on my laptop, and it works fine with svgatextmode. A better solution would be that svgatextmode explicitely tells the kernel not to care about video timing, but for this an interface needs be defined and svgatextmode be patched. Signed-off-by:
Samuel Thibault <samuel.thibault@ens-lyon.org> Cc: "Antonino A. Daplas" <adaplas@pol.net> Signed-off-by:
-
Herbert Xu authored
It seems that all the list_*_rcu primitives are missing a memory barrier on the very first dereference. For example, #define list_for_each_rcu(pos, head) \ for (pos = (head)->next; prefetch(pos->next), pos != (head); \ pos = rcu_dereference(pos->next)) It will go something like: pos = (head)->next prefetch(pos->next) pos != (head) do stuff We're missing a barrier here. pos = rcu_dereference(pos->next) fetch pos->next barrier given by rcu_dereference(pos->next) store pos Without the missing barrier, the pos->next value may turn out to be stale. In fact, if "do stuff" were also dereferencing pos and relying on list_for_each_rcu to provide the barrier then it may also break. So here is a patch to make sure that we have a barrier for the first element in the list. Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au> Acked-by:
"Paul E. McKenney" <paulmck@us.ibm.com> Signed-off-by:
-
Linus Torvalds authored
As noticed by Nick Piggin, we need to make sure that we check the page count before we check for PageDirty, since the dirty check is only valid if the count implies that we're the only possible ones holding the page. We always did do this, but the code needs a read-memory-barrier to make sure that the orderign is also honored by the CPU. (The writer side is ordered due to the atomic decrement and test on the page count, see the discussion on linux-kernel) Signed-off-by:
-
- 16 Oct, 2005 1 commit
-
-
Al Viro authored
... otherwise, things like alpha and sparc64 break and break badly. They define cpu_possible_map to something else in smp.h *AFTER* having included cpumask.h. If that puppy is a macro, expansion will happen at the actual caller, when we'd already seen #define cpu_possible_map ... and we will get the right thing used. As an inline helper it will be tokenized before we get to that define and that's it; no matter what we define later, it won't affect anything. We get modules with dependency on cpu_possible_map instead of the right symbol (phys_cpu_present_map in case of sparc64), or outright link errors if they are built-in. Signed-off-by:
Al Viro <viro@zeniv.linux.org.uk> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
- 15 Oct, 2005 4 commits
-
-
Andrew Morton authored
Signed-off-by:
-
maximilian attems authored
The modem is said to work with belows addition to pnp_dev_table[]: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=296011Signed-off-by:
maximilian attems <janitor@sternwelten.at> Signed-off-by:
-
Randall Nortman authored
Kernel version 2.6.13 introduced a regression in the generic USB serial converter driver (usbserial.o, drivers/usb/serial/generic.c). The bug manifests, as far as I can tell, whenever you attempt to write to the device -- the write will never complete (write() returns 0, or blocks). Signed-off-by:
Randall Nortman <oss@wonderclown.org> Signed-off-by:
-
Linus Torvalds authored
-
