- 03 8月, 2009 2 次提交
-
-
由 Zhenyu Wang 提交于
New driver hooks for support graphics memory dma remapping are introduced in this patch. It makes generic code can tell if current device needs dma remapping, then call driver provided interfaces for mapping and unmapping. Change has also been made to handle scratch_page in remapping case. Signed-off-by: NZhenyu Wang <zhenyu.z.wang@intel.com> Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>
-
由 David Woodhouse 提交于
In commit 07613ba2 ("agp: switch AGP to use page array instead of unsigned long array") we switched the mask_memory() method to take a 'struct page *' instead of an address. This is painful, because in some cases it has to be an IOMMU-mapped virtual bus address (in fact, shouldn't it _always_ be a dma_addr_t returned from pci_map_xxx(), and we just happen to get lucky most of the time?) Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>
-
- 30 7月, 2009 2 次提交
-
-
由 Hidetoshi Seto 提交于
commit d6580a9f ("kexec: sysrq: simplify sysrq-c handler") changed the behavior of sysrq-c to unconditional dereference of NULL pointer. So in cases with CONFIG_KEXEC, where crash_kexec() was directly called from sysrq-c before, now it can be said that a step of "real oops" was inserted before starting kdump. However, in contrast to oops via SysRq-c from keyboard which results in panic due to in_interrupt(), oops via "echo c > /proc/sysrq-trigger" will not become panic unless panic_on_oops=1. It means that even if dump is properly configured to be taken on panic, the sysrq-c from proc interface might not start crashdump while the sysrq-c from keyboard can start crashdump. This confuses traditional users of kdump, i.e. people who expect sysrq-c to do common behavior in both of the keyboard and proc interface. This patch brings the keyboard and proc interface behavior of sysrq-c in line, by forcing panic_on_oops=1 before oops in sysrq-c handler. And some updates in documentation are included, to clarify that there is no longer dependency with CONFIG_KEXEC, and that now the system can just crash by sysrq-c if no dump mechanism is configured. Signed-off-by: NHidetoshi Seto <seto.hidetoshi@jp.fujitsu.com> Cc: Lai Jiangshan <laijs@cn.fujitsu.com> Cc: Ken'ichi Ohmichi <oomichi@mxs.nes.nec.co.jp> Acked-by: NNeil Horman <nhorman@tuxdriver.com> Acked-by: NVivek Goyal <vgoyal@redhat.com> Cc: Brayan Arraes <brayan@yack.com.br> Cc: Eric W. Biederman <ebiederm@xmission.com> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
由 OGAWA Hirofumi 提交于
We really don't want to mark the pty as a low-latency device, because as Alan points out, the ->write method can be called from an IRQ (ppp?), and that means we can't use ->low_latency=1 as we take mutexes in the low_latency case. So rather than using low_latency to force the written data to be pushed to the ldisc handling at 'write()' time, just make the reader side (or the poll function) do the flush when it checks whether there is data to be had. This also fixes the problem with lost data in an emacs compile buffer (bugzilla 13815), and we can thus revert the low_latency pty hack (commit 3a542974: "pty: quickfix for the pty ENXIO timing problems"). Signed-off-by: NOGAWA Hirofumi <hirofumi@mail.parknet.co.jp> Tested-by: NAneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com> [ Modified to do the tty_flush_to_ldisc() inside input_available_p() so that it triggers for both read and poll() - Linus] Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
- 29 7月, 2009 1 次提交
-
-
由 Jeff Garzik 提交于
Signed-off-by: NJeff Garzik <jgarzik@redhat.com>
-
- 28 7月, 2009 1 次提交
-
-
由 Alan Cox 提交于
This also makes close stall in the normal case which is apparently needed to fix emacs Signed-off-by: NAlan Cox <alan@linux.intel.com> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
- 21 7月, 2009 3 次提交
-
-
由 Alan Cox 提交于
This function does not have an error return and returning an error is instead interpreted as having a lot of pending bytes. Reported by Jeff Harris who provided a list of some of the remaining offenders. Signed-off-by: NAlan Cox <alan@linux.intel.com> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
由 Julia Lawall 提交于
If spin_lock_irqsave is called twice in a row with the same second argument, the interrupt state at the point of the second call overwrites the value saved by the first call. Indeed, the second call does not need to save the interrupt state, so it is changed to a simple spin_lock. The semantic match that finds this problem is as follows: (http://www.emn.fr/x-info/coccinelle/) // <smpl> @@ expression lock1,lock2; expression flags; @@ *spin_lock_irqsave(lock1,flags) ... when != flags *spin_lock_irqsave(lock2,flags) // </smpl> Signed-off-by: NJulia Lawall <julia@diku.dk> Signed-off-by: NAlan Cox <alan@linux.intel.com> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
由 Kay Sievers 提交于
The buffer for the consoles are unconditionally allocated at con_init() time, which miss the creation of the vcs(a) devices. Since 2.6.30 (commit 4995f8ef, 'vcs: hook sysfs devices into object lifetime instead of "binding"' to be exact) these devices are no longer created at open() and removed on close(), but controlled by the lifetime of the buffers. Reported-by: NGerardo Exequiel Pozzi <vmlinuz386@yahoo.com.ar> Tested-by: NGerardo Exequiel Pozzi <vmlinuz386@yahoo.com.ar> Cc: stable@kernel.org Signed-off-by: NKay Sievers <kay.sievers@vrfy.org> Signed-off-by: NAlan Cox <alan@linux.intel.com> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
- 17 7月, 2009 5 次提交
-
-
由 Alan Cox 提交于
Whoops.. fortunately not many people use this yet. Signed-off-by: NAlan Cox <alan@linux.intel.com> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
由 Alan Cox 提交于
If a tty in N_TTY mode with echo enabled manages to get itself into a state where - echo characters are pending - FASYNC is enabled - tty_write_wakeup is called from either - a device write path (pty) - an IRQ (serial) then it either deadlocks or explodes taking a mutex in the IRQ path. On the serial side it is almost impossible to reproduce because you have to go from a full serial port to a near empty one with echo characters pending. The pty case happens to have become possible to trigger using emacs and ptys, the pty changes having created a scenario which shows up this bug. The code path is n_tty:process_echoes() (takes mutex) tty_io:tty_put_char() pty:pty_write (or serial paths) tty_wakeup (from pty_write or serial IRQ) n_tty_write_wakeup() process_echoes() *KABOOM* Signed-off-by: NAlan Cox <alan@linux.intel.com> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
由 Jiri Slaby 提交于
Don't forget to drop a tty refererence on fail paths in receive_data(). Signed-off-by: NJiri Slaby <jirislaby@gmail.com> Signed-off-by: NAlan Cox <alan@linux.intel.com> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
由 Johannes Weiner 提交于
Bootmem is not used for the vt screen buffer anymore as slab is now available at the time the console is initialized. Get rid of the now superfluous distinction between slab and bootmem, it's always slab. This also fixes a kmalloc leak which Catalin described thusly: Commit a5f4f52e ("vt: use kzalloc() instead of the bootmem allocator") replaced the alloc_bootmem() with kzalloc() but didn't set vc_kmalloced to 1 and the memory block is later leaked. The corresponding kmemleak trace: unreferenced object 0xdf828000 (size 8192): comm "swapper", pid 0, jiffies 4294937296 backtrace: [<c006d473>] __save_stack_trace+0x17/0x1c [<c000d869>] log_early+0x55/0x84 [<c01cfa4b>] kmemleak_alloc+0x33/0x3c [<c006c013>] __kmalloc+0xd7/0xe4 [<c00108c7>] con_init+0xbf/0x1b8 [<c0010149>] console_init+0x11/0x20 [<c0008797>] start_kernel+0x137/0x1e4 Signed-off-by: NJohannes Weiner <hannes@cmpxchg.org> Reviewed-by: NPekka Enberg <penberg@cs.helsinki.fi> Tested-by: NCatalin Marinas <catalin.marinas@arm.com> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NAlan Cox <alan@lxorguk.ukuu.org.uk> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
由 Alan Cox 提交于
We can get a situation where a hangup occurs during or after a close. In that case the ldisc gets disposed of by the close and the hangup then explodes. Signed-off-by: NAlan Cox <alan@linux.intel.com> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
- 13 7月, 2009 1 次提交
-
-
由 Alexey Dobriyan 提交于
* Remove smp_lock.h from files which don't need it (including some headers!) * Add smp_lock.h to files which do need it * Make smp_lock.h include conditional in hardirq.h It's needed only for one kernel_locked() usage which is under CONFIG_PREEMPT This will make hardirq.h inclusion cheaper for every PREEMPT=n config (which includes allmodconfig/allyesconfig, BTW) Signed-off-by: NAlexey Dobriyan <adobriyan@gmail.com> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
- 09 7月, 2009 2 次提交
-
-
由 Joe Perches 提交于
Commit 5fd29d6c ("printk: clean up handling of log-levels and newlines") changed printk semantics. printk lines with multiple KERN_<level> prefixes are no longer emitted as before the patch. <level> is now included in the output on each additional use. Remove all uses of multiple KERN_<level>s in formats. Signed-off-by: NJoe Perches <joe@perches.com> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
由 Alan Cox 提交于
This fixes the ppp problems and various other issues with call locking caused by one side of a pty called in one locking context trying to match another with differing rules on the other side. We also get a big slack space to work with that means we can bury the flow control deadlock case for any conceivable real world situation. Signed-off-by: NAlan Cox <alan@linux.intel.com> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
- 03 7月, 2009 2 次提交
-
-
由 Yoichi Yuasa 提交于
Signed-off-by: NYoichi Yuasa <yuasa@linux-mips.org> Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
-
由 Yoichi Yuasa 提交于
Signed-off-by: NYoichi Yuasa <yyuasa@linux.com> Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
-
- 30 6月, 2009 1 次提交
-
-
由 Alan Cox 提交于
Currently we reinit the ldisc on final tty close which is what the old code did to ensure that if the device retained its termios settings then it had the right ldisc. tty_ldisc_reinit does that but also leaves us with the reset ldisc reference which is then leaked. At this point we know the port will be recycled so we can kill the ldisc off completely rather than try and add another ldisc free up when the kref count hits zero. At this point it is safe to keep the ldisc closed as tty_ldisc waiting methods are only used from the user side, and as the final close we are the last such reference. Interrupt/driver side methods will always use the non wait version and get back a NULL. Found with kmemleak and investigated/identified by Catalin Marinas. Signed-off-by: NAlan Cox <alan@linux.intel.com> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
- 26 6月, 2009 2 次提交
-
-
由 Sonny Rao 提交于
On Mon, Nov 17, 2008 at 01:26:13AM -0600, Sonny Rao wrote: > On Fri, Nov 07, 2008 at 04:28:29PM +1100, Paul Mackerras wrote: > > Sonny Rao writes: > > > > > Fix the BSR driver to allow small BSR devices, which are limited to a > > > single 4k space, on a 64k page kernel. Previously the driver would > > > reject the mmap since the size was smaller than PAGESIZE (or because > > > the size was greater than the size of the device). Now, we check for > > > this case use remap_4k_pfn(). Also, take out code to set vm_flags, > > > as the remap_pfn functions will do this for us. > > > > Thanks. > > > > Do we know that the BSR size will always be 4k if it's not a multiple > > of 64k? Is it possible that we could get 8k, 16k or 32k or BSRs? > > If it is possible, what does the user need to be able to do? Do they > > just want to map 4k, or might then want to map the whole thing? > > > Hi Paul, I took a look at changing the driver to reject a request for > mapping more than a single 4k page, however the only indication we get > of the requested size in the mmap function is the vma size, and this > is always one page at minimum. So, it's not possible to determine if > the user wants one 4k page or more. As I noted in my first response, > there is only one case where this is even possible and I don't think > it is a significant concern. > > I did notice that I left out the check to see if the user is trying to > map more than the device length, so I fixed that. Here's the revised > patch. Alright, I've reworked this now so that if we get one of these cases where there's a bsr that's > 4k and < 64k on a 64k kernel we'll only advertise that it is a 4k BSR to userspace. I think this is the best solution since user programs are only supposed to look at sysfs to determine how much can be mapped, and libbsr does this as well. Please consider for 2.6.31 as a fix, thanks. Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
-
由 Sonny Rao 提交于
Add a 4096 byte BSR size which will be used on new machines. Also, remove the warning when we run into an unknown size, as this can spam the kernel log excessively. Signed-off-by: NSonny Rao <sonnyrao@us.ibm.com> Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
-
- 25 6月, 2009 3 次提交
-
-
由 Chuck Ebbert 提交于
The kernel oopses if this flag is set. [and neither driver should set it as they call tty_flip_buffer_push from IRQ paths so have always been buggy] Signed-off-by: NChuck Ebbert <cebbert@redhat.com> Signed-off-by: NAlan Cox <alan@linux.intel.com> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
由 Jiri Slaby 提交于
Since commit 3e3b5c08 ("tty: use prepare/finish_wait"), tty_port_block_til_ready() is using prepare_to_wait()/finish_wait(). Those functions require that the wait_queue_t be initialised with .func=autoremove_wake_function, via DEFINE_WAIT(). But the conversion from DECLARE_WAITQUEUE() to DEFINE_WAIT() was not made, so this code will oops in finish_wait(). Signed-off-by: NJiri Slaby <jirislaby@gmail.com> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NAlan Cox <alan@linux.intel.com> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
由 Paul Fulghum 提交于
Fix race condition when adding transmit data to active DMA buffer ring that can cause transmit stall. Update transmit timeout when adding data to active DMA buffer ring. Base transmit timeout on amount of buffered data instead of using fixed value. Signed-off-by: NPaul Fulghum <paulkf@microgate.com> Signed-off-by: NAlan Cox <alan@linux.intel.com> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
- 23 6月, 2009 6 次提交
-
-
由 Paul Fulghum 提交于
Add flush_buffer tty callback to flush rx buffers. Add TCFLSH ioctl processing to flush tx buffers. Increase default tx buffers from 1 to 3. Remove unneeded flush_buffer call in open callback. Remove vendor specific CVS version string. Signed-off-by: NPaul Fulghum <paulkf@microgate.com> Signed-off-by: NAlan Cox <alan@linux.intel.com> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
由 Jiri Slaby 提交于
Don't return from switch/case directly in vt_ioctl. Set ret and break instead so that we unlock BKL. Signed-off-by: NJiri Slaby <jirislaby@gmail.com> Signed-off-by: NAlan Cox <alan@linux.intel.com> Cc: stable@kernel.org Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
由 Jiri Slaby 提交于
Don't return from switch/case, break instead, so that we unlock BKL. Signed-off-by: NJiri Slaby <jirislaby@gmail.com> Signed-off-by: NAlan Cox <alan@linux.intel.com> Cc: stable@kernel.org Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
由 Jiri Slaby 提交于
There is omitted BKunL in r3964_read. Centralize the paths to one point with one unlock. Signed-off-by: NJiri Slaby <jirislaby@gmail.com> Signed-off-by: NAlan Cox <alan@linux.intel.com> Cc: stable@kernel.org Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
由 Mike Frysinger 提交于
The original patch garned some feedback and a v2 was posted, but that version seems to have been missed when merging the driver. At any rate, this cleans up the printk usage as suggested by Jiri Slaby. Signed-off-by: NMike Frysinger <vapier@gentoo.org> Signed-off-by: NAlan Cox <alan@linux.intel.com> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
由 Linus Torvalds 提交于
This reverts commit a90b0375, which already got fixed as commit f0e85277: the same patch (trivial differences) got applied twice. Requested-by: NAlan Cox <alan@lxorguk.ukuu.org.uk> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
- 20 6月, 2009 4 次提交
-
-
由 Pierre Willenbrock 提交于
Otherwise, the high bits to be stuffed in the unused lower bits of the page address are lost. Signed-off-by: NPierre Willenbrock <pierre@pirsoft.de> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Dirk Eibach 提交于
In moxa.c there are 32 minor numbers reserved for each device. The number of ports actually available per device is stored in moxa_board_conf->numPorts. This number is not considered in moxa_open(). Opening a port that is not available results in a kernel oops. This patch adds a test to moxa_open() that prevents opening unavailable ports. [akpm@linux-foundation.org: avoid multiple returns] Signed-off-by: NDirk Eibach <eibach@gdsys.de> Signed-off-by: NJiri Slaby <jirislaby@gmail.com> Cc: Alan Cox <alan@lxorguk.ukuu.org.uk> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
由 Mike Frysinger 提交于
The remove member of the pci_driver stli_pcidriver uses __devexit_p(), so the remove function itself should be marked with __devexit. Even more so considering the probe function is marked with __devinit. Signed-off-by: NMike Frysinger <vapier@gentoo.org> Acked-by: NGreg Ungerer <gerg@uclinux.org> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
由 Roel Kluin 提交于
With a postfix increment retries is incremented beyond DTLK_MAX_RETRIES so the error message is not displayed correctly. Signed-off-by: NRoel Kluin <roel.kluin@gmail.com> Cc: James R. Van Zandt <jrv@vanzandt.mv.com> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
- 19 6月, 2009 5 次提交
-
-
由 Dave Airlie 提交于
This should fix TTM/KMS on some of the original ATI IGP chipsets. (rs100/rs200) Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Dave Airlie 提交于
This switches AGP to use an array of pages for tracking the pages allocated to the GART. This should enable GEM on PAE to work a lot better as we can pass highmem pages to the PAT code and it will do the right thing with them. Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Ondrej Zary 提交于
Add M1621 chipset name to ali-agp, preventing "Detected ALi M???? chipset" message. Signed-off-by: NOndrej Zary <linux@rainbow-software.org> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Michel Dänzer 提交于
This adds support for TTM to the uninorth AGP bridge. Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Neil Horman 提交于
Currently the sysrq-c handler is bit over-engineered. Its behavior is dependent on a few compile time and run time factors that alter its behavior which is really unnecessecary. If CONFIG_KEXEC is not configured, sysrq-c, crashes the system with a NULL pointer dereference. If CONFIG_KEXEC is configured, it calls crash_kexec directly, which implies that the kexec kernel will either be booted (if its been previously loaded), or it will simply do nothing (the no kexec kernel has been loaded). It would be much easier to just simplify the whole thing to dereference a NULL pointer all the time regardless of configuration. That way, it will always try to crash the system, and if a kexec kernel has been loaded into reserved space, it will still boot from the page fault trap handler (assuming panic_on_oops is set appropriately). [akpm@linux-foundation.org: build fix] Signed-off-by: NNeil Horman <nhorman@tuxdriver.com> Acked-by: NVivek Goyal <vgoyal@redhat.com> Cc: Brayan Arraes <brayan@yack.com.br> Cc: "Eric W. Biederman" <ebiederm@xmission.com> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-