- 05 May, 2005 40 commits
-
-
Manu Abraham authored
Attached is a patch to bttv which fixes the following problems. Affected cards and problems: ~~~~~~~~~~~~~~~~~~~~~~~~ o VP-1020 (200103A) Tuning problems, device detection. o VP-1020 (DST-MOT) Errors during tuning, device detection fails in a while. o VP-1030 (DST-CI) Tuning sometimes fails after CI commands. o VP-2031 (DCT-CI) Tuning problems The timeout happens before the actual timeout occured in the MCU on the board, and hence the problems. Changes: (bttv-i2c.diff) ~~~~~~~~~~~~~~~~~~~~~~~~ o Changed the custom wait queue to wait_event_interruptible_timeout() - Suggestion by Johannes Stezenbach. o Fixed the wait queue timeout problem - This fixes the timeout problem on various cards. - This problem was visible as many * Cannot tune to channels, when signal levels are very low. * app_info does not work in some conditions for CI based cards - Smaller values worked good for newer cards, but the older cards suffered, settled down to the worst case values that could happen in any eventuality. Signed-off-by:
Manu Abraham <manu@kromtek.com> Signed-off-by:
Andrew Morton <akpm@osdl.org> Signed-off-by:
Linus Torvalds <torvalds@osdl.org>
-
Christoph Hellwig authored
The only caller that ever sets it can call fsync_bdev itself easily. Also update some comments. Signed-off-by:
Christoph Hellwig <hch@lst.de> Cc: <viro@parcelfarce.linux.theplanet.co.uk> Signed-off-by:
-
Christoph Hellwig authored
Signed-off-by:
-
Christoph Hellwig authored
This patch adds support for a new class of DAC960 controllers. It's based on the GPLed idac320 driver from IBM for Linux 2.4.18. That driver is a fork of the 2.4.18 version of DAC960 that adds support for this new type of controllers (internally called "GEM Series"), that differ from other DAC960 V2 firmware controllers only in the register offsets and removes support for all others. This patch instead integrates support for these controllers into the DAC960 driver. Thanks to Anders Norrbring for pointing me to the idac320 driver and testing this patch. No Signed-Off: line because all code is either copy & pasted from IBM's idac320 driver or support for other controllers in the 2.6 DAC960 driver. Note: the really odd formating matches the rest of the DAC960 driver. Cc: Dave Olien <dmo@osdl.org> Signed-off-by:
-
Daniel Ritz authored
Make sure that if the INTRTIE bit is set both functions of the cardbus bridge use the same IRQ before doing any probing... [ yes i hate the TI bridges for the fact that they are very flexible so that so many BIOS vendors get it wrong. ] Signed-off-by:
Daniel Ritz <daniel.ritz@gmx.ch> Signed-off-by:
Dominik Brodowski <linux@dominikbrodowski.net> Signed-off-by:
-
Dominik Brodowski authored
Enable 32-bit memory windows on pd6729 PCI-PCMCIA bridges. Signed-off-by:
Jarkko Raja <jar@pcuf.fi> Signed-off-by:
-
Frederic CAND authored
This patch handles the VIDIOC_S_FMT and VIDIOC_G_FMT ioctls for the saa6752hs. As only 4 preset video formats are supported (SIF, 1/2D1, 2/3D1, D1), we compute to which the asked resolution is the nearest and apply it. Signed-off-by:
Frederic Cand <frederic.cand@anevia.com> Acked-by:
Gerd Knorr <kraxel@bytesex.org> Signed-off-by:
-
Matt Porter authored
Additions to the dontdiff list. Signed-off-by:
Matt Porter <mporter@kernel.crashing.org> Signed-off-by:
-
Adrian Bunk authored
There's no longer a reason to document the obsolete BK usage. Signed-off-by:
Adrian Bunk <bunk@stusta.de> Cc: Jeff Garzik <jgarzik@pobox.com> Signed-off-by:
-
Andrew Morton authored
Has lots of callsites. Signed-off-by:
-
Adrian Bunk authored
These three functions are referenced from the __devinitdata sis5513_chipset. Signed-off-by:
-
Paulo Marques authored
It seems that the code responsible for this is in kernel/itimer.c:126: p->signal->real_timer.expires = jiffies + interval; add_timer(&p->signal->real_timer); If you request an interval of, lets say 900 usecs, the interval given by timeval_to_jiffies will be 1. If you request this when we are half-way between two timer ticks, the interval will only give 400 usecs. If we want to guarantee that we never ever give intervals less than requested, the simple solution would be to change that to: p->signal->real_timer.expires = jiffies + interval + 1; This however will produce pathological cases, like having a idle system being requested 1 ms timeouts will give systematically 2 ms timeouts, whereas currently it simply gives a few usecs less than 1 ms. The complex (and more computationally expensive) solution would be to check the gettimeofday time, and compute the correct number of jiffies. This way, if we request a 300 usecs timer 200 usecs inside the timer tick, we can wait just one tick, but not if we are 800 usecs inside the tick. This would also mean that we would have to lock preemption during these computations to avoid races, etc. I've searched the archives but couldn't find this particular issue being discussed before. Attached is a patch to do the simple solution, in case anybody thinks that it should be used. Signed-Off-By:
Paulo Marques <pmarques@grupopie.com> Signed-off-by:
-
Andrew Morton authored
The `last_bh' logic probably isn't worth much. In those situations where only the front part of the page is being written out we will save some looping but in the vastly more common case of an all-page writeout if just adds more code. Nick Piggin <nickpiggin@yahoo.com.au> Signed-off-by:
-
Andrew Morton authored
Remove all those get_bh()'s and put_bh()'s by extending lock_page() to cover the troublesome regions. (get_bh() and put_bh() happen every time whereas contention on a page's lock in there happens basically never). Cc: Nick Piggin <nickpiggin@yahoo.com.au> Signed-off-by:
-
Nick Piggin authored
When running fsstress -v -d $DIR/tmp -n 1000 -p 1000 -l 2 on an ext2 filesystem with 1024 byte block size, on SMP i386 with 4096 byte page size over loopback to an image file on a tmpfs filesystem, I would very quickly hit BUG_ON(!buffer_async_write(bh)); in fs/buffer.c:end_buffer_async_write It seems that more than one request would be submitted for a given bh at a time. What would happen is the following: 2 threads doing __mpage_writepages on the same page. Thread 1 - lock the page first, and enter __block_write_full_page. Thread 1 - (eg.) mark_buffer_async_write on the first 2 buffers. Thread 1 - set page writeback, unlock page. Thread 2 - lock page, wait on page writeback Thread 1 - submit_bh on the first 2 buffers. => both requests complete, none of the page buffers are async_write, end_page_writeback is called. Thread 2 - wakes up. enters __block_write_full_page. Thread 2 - mark_buffer_async_write on (eg.) the last buffer Thread 1 - finds the last buffer has async_write set, submit_bh on that. Thread 2 - submit_bh on the last buffer. => oops. So change __block_write_full_page to explicitly keep track of the last bh we need to issue, so we don't touch anything after issuing the last request. Signed-off-by:
Nick Piggin <nickpiggin@yahoo.com.au> Signed-off-by:
-
Nick Piggin authored
Fix a race where __block_prepare_write can leak out an in-flight read against a bh if get_block returns an error. This can lead to the page becoming unlocked while the buffer is locked and the read still in flight. __mpage_writepage BUGs on this condition. BUG sighted on a 2-way Itanium2 system with 16K PAGE_SIZE running fsstress -v -d $DIR/tmp -n 1000 -p 1000 -l 2 where $DIR is a new ext2 filesystem with 4K blocks that is quite small (causing get_block to fail often with -ENOSPC). Signed-off-by:
-
Daniel Ritz authored
During a warm boot the device is in D3 and has troubles coming out of it. Signed-off-by:
-
Randy.Dunlap authored
Add better support for (non-incremental) 2.6.x.y patches; If an ending version number if not specified, the script automatically increments the SUBLEVEL (x in 2.6.x.y) until no more patch files are found; however, EXTRAVERSION (y in 2.6.x.y) is never automatically incremented but must be specified fully. patch-kernel does not normally support reverse patching, but does so when applying EXTRAVERSION (x.y) patches, so that moving from 2.6.11.y to 2.6.11.z is easy and handled by the script (reverse 2.6.11.y and apply 2.6.11.z). Signed-off-by:
Randy Dunlap <rddunlap@osdl.org> Signed-off-by:
-
Ananth N Mavinakayanahalli authored
Allow registration of multiple kprobes at an address in an architecture agnostic way. Corresponding handlers will be invoked in a sequence. But, a kprobe and a jprobe can't (yet) co-exist at the same address. Signed-off-by:
Ananth N Mavinakayanahalli <amavin@redhat.com> Signed-off-by:
-
Prasanna S Panchamukhi authored
kernel oops! when unregister_kprobe() is called on a non-registered kprobe. This patch fixes the above problem by checking if the probe exists before unregistering. Signed-off-by:
Prasanna S Panchamukhi <prasanna@in.ibm.com> Signed-off-by:
-
Prasanna S Panchamukhi authored
Kprobes could not handle the insertion of a probe on the ret/lret instruction and used to oops after single stepping since kprobes was modifying eip/rip incorrectly. Adjustment of eip/rip is not required after single stepping in case of ret/lret instruction, because eip/rip points to the correct location after execution of the ret/lret instruction. This patch fixes the above problem. Signed-off-by:
-
Bodo Stroesser authored
Remove some definitions and declarations from arch/um/include/skas_ptrace.h, as they have moved to arch/um/include/sysdep/skas_ptrace.h Also, remove PTRACE_SIGPENDING support in UML at all. Signed-off-by:
Bodo Stroesser <bstroesser@fujitsu-siemens.com> Signed-off-by:
Jeff Dike <jdike@addtoit.com> Signed-off-by:
-
Bodo Stroesser authored
UML: remove no longer needed arch-signal.h Signed-off-by:
-
Bodo Stroesser authored
s390 passes parameters in registers. So the only safe way to find out the address of signal context, error-address and error-type (trap_no), which are passed to signal handlers as parameters, is to declare these parameters. So I inserted an subarch-specific macro which holds the declaration of parameters for signal handlers. Signed-off-by:
-
Bodo Stroesser authored
s390 has fast read access to realtime clock (nanosecond resolution). So it makes sense to have an arch-specific implementation not only of __delay, but __udelay also. Signed-off-by:
-
Bodo Stroesser authored
Checksum handling largely depends on the subarch. Thus, I renamed i386 arch_csum_partial in arch/um/sys-i386/checksum.S back to csum_partial, removed csum_partial from arch/um/kernel/checksum.c and shifted EXPORT_SYMBOL(csum_partial) to arch/um/sys-i386/ksyms.c. Then, csum_partial_copy_to and csum_partial_copy_from were shifted from arch/um/kernel/checksum.c to arch/um/include/sysdep-i386/checksum.h and inserted in the calling functions csum_partial_copy_from_user() and csum_and_copy_to_user(). Now, arch/um/kernel/checksum.c is empty and removed. Signed-off-by:
-
Bodo Stroesser authored
This patch replaces the contents of include/asm-um/linkage.h by #include "asm/arch/linkage.h" Signed-off-by: -
Bodo Stroesser authored
This patch make elh.h a symlink to the new arch-specific include files of the form elf-<subarch>.h, as in the same way already is done for some other includes. Also moves Elf-stuff from archparam-<subarch>.h and elf.h to the new elf-<subarch>.h files. Signed-off-by:
-
Jeff Dike authored
This cleans up the error handling and fixes a crash if a hostfs mount fails. Signed-off-by:
-
Jeff Dike authored
The completion cleanup got rid of some semaphores, but didn't remove the inclusion of asm/semaphore.h from xterm_kern.c. Signed-off-by:
-
Jeff Dike authored
Just some breaking of some overly-long lines. Signed-off-by:
-
Jeff Dike authored
This makes SIGWINCH work again, and fixes a couple of SIGWINCH-associated crashes. First, the sigio thread disables SIGWINCH because all hell breaks loose if it ever gets one and tries to call the signal handling code. Second, there was a problem with deferencing tty structs after they were freed. The SIGWINCH support for a tty wasn't being turned off or freed after the tty went away. Signed-off-by:
-
Bodo Stroesser authored
This patch removes the arch-specific fault/trap-infos from thread and skas-regs. It adds a new struct faultinfo, that is arch-specific defined in sysdep/faultinfo.h. The structure is inserted in thread.arch and thread.regs.skas and thread.regs.tt Now, segv and other trap-handlers can copy the contents from regs.X.faultinfo to thread.arch.faultinfo with one simple assignment. Also, the number of macros necessary is reduced to FAULT_ADDRESS(struct faultinfo) extracts the faulting address from faultinfo FAULT_WRITE(struct faultinfo) extracts the "is_write" flag SEGV_IS_FIXABLE(struct faultinfo) is true for the fixable segvs, i.e. (TRAP == 14) on i386 UPT_FAULTINFO(regs) result is (struct faultinfo *) to the faultinfo in regs->skas.faultinfo GET_FAULTINFO_FROM_SC(struct faultinfo, struct sigcontext *) copies the relevant parts of the sigcontext to struct faultinfo. On SIGSEGV, call user_signal() instead of handle_segv(), if the architecture provides the information needed in PTRACE_FAULTINFO, or if PTRACE_FAULTINFO is missing, because segv-stub will provide the info. The benefit of the change is, that in case of a non-fixable SIGSEGV, we can give user processes a SIGSEGV, instead of possibly looping on pagefault handling. Since handle_segv() sikked arch_fixup() implicitly by passing ip==0 to segv(), I changed segv() to call arch_fixup() only, if !is_user. Signed-off-by: -
Jeff Dike authored
This fixes write_ldt_entry to treat userspace_pid as an array. Signed-off-by:
-
Al Viro authored
O=... builds support. Very easy, actually. Signed-off-by:
Al Viro <viro@parcelfarce.linux.theplanet.co.uk> Signed-off-by:
-
Al Viro authored
make distclean et.al. are missing arch/um/sys-x86_64/utils; fixed the same way we have it done for sys-i386 counterpart. Signed-off-by:
-
Al Viro authored
helpers in arch/um/util (mk_task and mk_constants) converted. That's it - none of the helpers depends on build and target being the same architecture anymore. Signed-off-by:
-
Al Viro authored
mk_thread converted Signed-off-by:
-
Al Viro authored
The next group of helpers is a bit trickier - they want the constants similar to those in user-offsets.h, but we need target sc.h for it. So we can't put that into user-offsets (sc.h depends on it) and need the second generated header for that stuff (kernel-offsets.h. BFD... Signed-off-by:
-
Al Viro authored
Ditto for mk_sc Signed-off-by:
-
