1. 19 6月, 2008 3 次提交
    • J
      drivers/char/agp - use bool · c7258012
      Joe Perches 提交于
      Use boolean in AGP instead of having own TRUE/FALSE
      
      --
      Signed-off-by: NJoe Perches <joe@perches.com>
      Signed-off-by: NDave Airlie <airlied@redhat.com>
      c7258012
    • J
      agp: two-stage page destruction issue · da503fa6
      Jan Beulich 提交于
      besides it apparently being useful only in 2.6.24 (the changes in 2.6.25
      really mean that it could be converted back to a single-stage mechanism),
      I'm seeing an issue in Xen Dom0 kernels, which is caused by the calling
      of gart_to_virt() in the second stage invocations of the destroy function.
      I think that besides this being a real issue with Xen (where
      unmap_page_from_agp() is not just a page table attribute change), this
      also is invalid from a theoretical perspective: One should not assume that
      gart_to_virt() is still valid after unmapping a page. So minimally (keeping
      the 2-stage mechanism) a patch like the one below would be needed.
      
      Jan
      Signed-off-by: NDave Airlie <airlied@redhat.com>
      da503fa6
    • G
      agp/via: fixup pci ids · dcd981a7
      Greg KH 提交于
      add a new PCI ID and remove an old dodgy one, include the explaination
      in the commented code so nobody readds later.
      
      (davej also sent the pci id addition).
      Signed-off-by: NDave Airlie <airlied@redhat.com>
      dcd981a7
  2. 13 6月, 2008 5 次提交
  3. 07 6月, 2008 4 次提交
  4. 30 5月, 2008 1 次提交
  5. 25 5月, 2008 1 次提交
  6. 23 5月, 2008 2 次提交
  7. 20 5月, 2008 1 次提交
    • D
      sparc64: Add global register dumping facility. · 93dae5b7
      David S. Miller 提交于
      When a cpu really is stuck in the kernel, it can be often
      impossible to figure out which cpu is stuck where.  The
      worst case is when the stuck cpu has interrupts disabled.
      
      Therefore, implement a global cpu state capture that uses
      SMP message interrupts which are not disabled by the
      normal IRQ enable/disable APIs of the kernel.
      
      As long as we can get a sysrq 'y' to the kernel, we can
      get a dump.  Even if the console interrupt cpu is wedged,
      we can trigger it from userspace using /proc/sysrq-trigger
      
      The output is made compact so that this facility is more
      useful on high cpu count systems, which is where this
      facility will likely find itself the most useful :)
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      93dae5b7
  8. 19 5月, 2008 1 次提交
  9. 17 5月, 2008 1 次提交
  10. 16 5月, 2008 1 次提交
    • I
      tty: fix BKL related leak and crash · 487ad7ef
      Ingo Molnar 提交于
      Enabling the BKL to be lockdep tracked uncovered the following
      upstream kernel bug in the tty code, which caused a BKL
      reference leak:
      
        ================================================
        [ BUG: lock held when returning to user space! ]
        ------------------------------------------------
        dmesg/3121 is leaving the kernel with locks still held!
        1 lock held by dmesg/3121:
         #0:  (kernel_mutex){--..}, at: [<c02f34d9>] opost+0x24/0x194
      
      this might explain some of the atomicity warnings and crashes
      that -tip tree testing has been experiencing since the BKL
      was converted back to a spinlock.
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      487ad7ef
  11. 15 5月, 2008 3 次提交
    • A
      tty_check_change(): avoid taking tasklist_lock while holding tty->ctrl_lock · 9ffee4cb
      Andrew Morton 提交于
      May 11 09:42:27 [kernel] [ 1104.496819] rarian-sk-get-c[5630]: segfault at 0 ip 7f478556caf0 sp 7fff8e3fe338 error 4 in libc-2.6.1.so[7f47854f9000+136000]
      May 11 10:59:48 [kernel] [ 2494.165792]
      May 11 10:59:48 [kernel] [ 2494.165794] =======================================================
      May 11 10:59:48 [kernel] [ 2494.165801] [ INFO: possible circular locking dependency detected ]
      May 11 10:59:48 [kernel] [ 2494.165805] 2.6.26-rc1-00007-g91b3a7a #217
      May 11 10:59:48 [kernel] [ 2494.165807] -------------------------------------------------------
      May 11 10:59:48 [kernel] [ 2494.165809] less/7053 is trying to acquire lock:
      May 11 10:59:48 [kernel] [ 2494.165812]  (tasklist_lock){..??}, at: [<ffffffff80232e95>] is_current_pgrp_orphaned+0x15/0x50
      May 11 10:59:48 [kernel] [ 2494.165821]
      May 11 10:59:48 [kernel] [ 2494.165822] but task is already holding lock:
      May 11 10:59:48 [kernel] [ 2494.165824]  (&tty->ctrl_lock){....}, at: [<ffffffff803d5f31>] tty_check_change+0x61/0x110
      May 11 10:59:48 [kernel] [ 2494.165831]
      May 11 10:59:48 [kernel] [ 2494.165832] which lock already depends on the new lock.
      May 11 10:59:48 [kernel] [ 2494.165833]
      May 11 10:59:48 [kernel] [ 2494.165835]
      May 11 10:59:48 [kernel] [ 2494.165836] the existing dependency chain (in reverse order) is:
      May 11 10:59:48 [kernel] [ 2494.165838]
      May 11 10:59:48 [kernel] [ 2494.165839] -> #2 (&tty->ctrl_lock){....}:
      May 11 10:59:48 [kernel] [ 2494.165843]        [<ffffffff80253796>] __lock_acquire+0xf86/0x1080
      May 11 10:59:48 [kernel] [ 2494.165851]        [<ffffffff80253922>] lock_acquire+0x92/0xc0
      May 11 10:59:48 [kernel] [ 2494.165858]        [<ffffffff804deee0>] _spin_lock_irqsave+0x40/0x60
      May 11 10:59:48 [kernel] [ 2494.165866]        [<ffffffff803d31b5>] __proc_set_tty+0x35/0xe0
      May 11 10:59:48 [kernel] [ 2494.165873]        [<ffffffff803d76d4>] tty_ioctl+0xbf4/0xfe0
      May 11 10:59:48 [kernel] [ 2494.165880]        [<ffffffff802a05e1>] vfs_ioctl+0x31/0x90
      May 11 10:59:48 [kernel] [ 2494.165888]        [<ffffffff802a06b3>] do_vfs_ioctl+0x73/0x2d0
      May 11 10:59:48 [kernel] [ 2494.165895]        [<ffffffff802a095a>] sys_ioctl+0x4a/0x80
      May 11 10:59:48 [kernel] [ 2494.165902]        [<ffffffff8020b5ab>] system_call_after_swapgs+0x7b/0x80
      May 11 10:59:48 [kernel] [ 2494.165910]        [<ffffffffffffffff>] 0xffffffffffffffff
      May 11 10:59:48 [kernel] [ 2494.165924]
      May 11 10:59:48 [kernel] [ 2494.165925] -> #1 (&sighand->siglock){++..}:
      May 11 10:59:48 [kernel] [ 2494.165929]        [<ffffffff80253796>] __lock_acquire+0xf86/0x1080
      May 11 10:59:48 [kernel] [ 2494.165936]        [<ffffffff80253922>] lock_acquire+0x92/0xc0
      May 11 10:59:48 [kernel] [ 2494.165943]        [<ffffffff804dec1f>] _spin_lock+0x2f/0x40
      May 11 10:59:48 [kernel] [ 2494.165951]        [<ffffffff8022d5a3>] copy_process+0x973/0x1210
      May 11 10:59:48 [kernel] [ 2494.165959]        [<ffffffff8022df12>] do_fork+0x82/0x2f0
      May 11 10:59:48 [kernel] [ 2494.165967]        [<ffffffff8020bfe1>] kernel_thread+0x81/0xde
      May 11 10:59:48 [kernel] [ 2494.165974]        [<ffffffff8020c048>] child_rip+0xa/0x12
      May 11 10:59:48 [kernel] [ 2494.165981]        [<ffffffffffffffff>] 0xffffffffffffffff
      May 11 10:59:48 [kernel] [ 2494.166038]
      May 11 10:59:48 [kernel] [ 2494.166039] -> #0 (tasklist_lock){..??}:
      May 11 10:59:48 [kernel] [ 2494.166043]        [<ffffffff802535ab>] __lock_acquire+0xd9b/0x1080
      May 11 10:59:48 [kernel] [ 2494.166050]        [<ffffffff80253922>] lock_acquire+0x92/0xc0
      May 11 10:59:48 [kernel] [ 2494.166057]        [<ffffffff804dede2>] _read_lock+0x32/0x50
      May 11 10:59:48 [kernel] [ 2494.166063]        [<ffffffff80232e95>] is_current_pgrp_orphaned+0x15/0x50
      May 11 10:59:48 [kernel] [ 2494.166071]        [<ffffffff803d5f80>] tty_check_change+0xb0/0x110
      May 11 10:59:48 [kernel] [ 2494.166078]        [<ffffffff803dac5f>] set_termios+0x1f/0x4c0
      May 11 10:59:48 [kernel] [ 2494.166085]        [<ffffffff803db379>] tty_mode_ioctl+0x279/0x3e0
      May 11 10:59:48 [kernel] [ 2494.166092]        [<ffffffff803db51d>] n_tty_ioctl+0x3d/0x260
      May 11 10:59:48 [kernel] [ 2494.166100]        [<ffffffff803d6c34>] tty_ioctl+0x154/0xfe0
      May 11 10:59:48 [kernel] [ 2494.166107]        [<ffffffff802a05e1>] vfs_ioctl+0x31/0x90
      May 11 10:59:48 [kernel] [ 2494.166114]        [<ffffffff802a06b3>] do_vfs_ioctl+0x73/0x2d0
      May 11 10:59:48 [kernel] [ 2494.166121]        [<ffffffff802a095a>] sys_ioctl+0x4a/0x80
      May 11 10:59:48 [kernel] [ 2494.166128]        [<ffffffff8020b5ab>] system_call_after_swapgs+0x7b/0x80
      May 11 10:59:48 [kernel] [ 2494.166135]        [<ffffffffffffffff>] 0xffffffffffffffff
      May 11 10:59:48 [kernel] [ 2494.166142]
      May 11 10:59:48 [kernel] [ 2494.166143] other info that might help us debug this:
      May 11 10:59:48 [kernel] [ 2494.166144]
      May 11 10:59:48 [kernel] [ 2494.166146] 1 lock held by less/7053:
      May 11 10:59:48 [kernel] [ 2494.166148]  #0:  (&tty->ctrl_lock){....}, at: [<ffffffff803d5f31>] tty_check_change+0x61/0x110
      May 11 10:59:48 [kernel] [ 2494.166155]
      May 11 10:59:48 [kernel] [ 2494.166156] stack backtrace:
      May 11 10:59:48 [kernel] [ 2494.166159] Pid: 7053, comm: less Not tainted 2.6.26-rc1-00007-g91b3a7a #217
      May 11 10:59:48 [kernel] [ 2494.166161]
      May 11 10:59:48 [kernel] [ 2494.166162] Call Trace:
      May 11 10:59:48 [kernel] [ 2494.166168]  [<ffffffff80251223>] print_circular_bug_tail+0x83/0x90
      May 11 10:59:48 [kernel] [ 2494.166172]  [<ffffffff80250889>] ? print_circular_bug_entry+0x49/0x60
      May 11 10:59:48 [kernel] [ 2494.166178]  [<ffffffff802535ab>] __lock_acquire+0xd9b/0x1080
      May 11 10:59:48 [kernel] [ 2494.166184]  [<ffffffff80232e95>] ? is_current_pgrp_orphaned+0x15/0x50
      May 11 10:59:48 [kernel] [ 2494.166189]  [<ffffffff80253922>] lock_acquire+0x92/0xc0
      May 11 10:59:48 [kernel] [ 2494.166206]  [<ffffffff803d5f80>] tty_check_change+0xb0/0x110
      May 11 10:59:48 [kernel] [ 2494.166211]  [<ffffffff803dac5f>] set_termios+0x1f/0x4c0
      May 11 10:59:48 [kernel] [ 2494.166216]  [<ffffffff803d3423>] ? tty_ldisc_try+0x23/0x60
      May 11 10:59:48 [kernel] [ 2494.166220]  [<ffffffff803d3444>] ? tty_ldisc_try+0x44/0x60
      May 11 10:59:48 [kernel] [ 2494.166224]  [<ffffffff804df2c5>] ? _spin_unlock_irqrestore+0x65/0x80
      May 11 10:59:48 [kernel] [ 2494.166230]  [<ffffffff803db379>] tty_mode_ioctl+0x279/0x3e0
      May 11 10:59:48 [kernel] [ 2494.166234]  [<ffffffff803d3444>] ? tty_ldisc_try+0x44/0x60
      May 11 10:59:48 [kernel] [ 2494.166239]  [<ffffffff803db51d>] n_tty_ioctl+0x3d/0x260
      May 11 10:59:48 [kernel] [ 2494.166244]  [<ffffffff803d6c34>] tty_ioctl+0x154/0xfe0
      May 11 10:59:48 [kernel] [ 2494.166249]  [<ffffffff80252baa>] ? __lock_acquire+0x39a/0x1080
      May 11 10:59:48 [kernel] [ 2494.166256]  [<ffffffff80252baa>] ? __lock_acquire+0x39a/0x1080
      May 11 10:59:48 [kernel] [ 2494.166263]  [<ffffffff80252baa>] ? __lock_acquire+0x39a/0x1080
      May 11 10:59:48 [kernel] [ 2494.166269]  [<ffffffff802a05e1>] vfs_ioctl+0x31/0x90
      May 11 10:59:48 [kernel] [ 2494.166274]  [<ffffffff802a06b3>] do_vfs_ioctl+0x73/0x2d0
      May 11 10:59:48 [kernel] [ 2494.166280]  [<ffffffff802a095a>] sys_ioctl+0x4a/0x80
      May 11 10:59:48 [kernel] [ 2494.166286]  [<ffffffff8020b5ab>] system_call_after_swapgs+0x7b/0x80
      May 11 10:59:48 [kernel] [ 2494.166292]
      Acked-by: NAlan Cox <alan@lxorguk.ukuu.org.uk>
      Reported-by: NMarcin Slusarz <marcin.slusarz@gmail.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      9ffee4cb
    • J
      char: select fw_loader by moxa · 4920916f
      Jiri Slaby 提交于
      Select FW_LOADER since moxa needs it, otherwise we face link problems such
      as:
      
      drivers/built-in.o: In function
      moxa_pci_probe':moxa.c:(.devinit.text+0x76d8): undefined reference to
      request_firmware'
      :moxa.c:(.devinit.text+0x7e6e): undefined reference to release_firmware'
      make: *** [.tmp_vmlinux1] Error 1
      Reported-by: NPhilippe Roussel <p.o.roussel@free.fr>
      Signed-off-by: NJiri Slaby <jirislaby@gmail.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      4920916f
    • N
      ipmi: support I/O resources in OF driver · 3b7ec117
      Nate Case 提交于
      The current OF probing assumes that the resource is IORESOURCE_MEM.  This
      checks for the IORESOURCE_IO flag and behaves appropriately.  An I/O resource
      can exist with an ipmi device node on a legacy ISA bus.
      Signed-off-by: NNate Case <ncase@xes-inc.com>
      Signed-off-by: NCorey Minyard <cminyard@mvista.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      3b7ec117
  12. 13 5月, 2008 1 次提交
  13. 09 5月, 2008 2 次提交
  14. 07 5月, 2008 4 次提交
  15. 06 5月, 2008 1 次提交
  16. 02 5月, 2008 2 次提交
    • K
      [POWERPC] Xilinx: Fix compile warnings · b17b8181
      Kumar Gala 提交于
      arch/powerpc/sysdev/xilinx_intc.c: In function 'xilinx_intc_init':
      arch/powerpc/sysdev/xilinx_intc.c:111: warning: format '%08X' expects type 'unsigned int', but argument 2 has type 'resource_size_t'
      drivers/char/xilinx_hwicap/xilinx_hwicap.c: In function 'hwicap_setup':
      drivers/char/xilinx_hwicap/xilinx_hwicap.c:626: warning: cast to pointer from integer of different size
      drivers/char/xilinx_hwicap/xilinx_hwicap.c:646: warning: format '%x' expects type 'unsigned int', but argument 6 has type 'resource_size_t'
      Signed-off-by: NKumar Gala <galak@kernel.crashing.org>
      b17b8181
    • A
      [PATCH] split linux/file.h · 9f3acc31
      Al Viro 提交于
      Initial splitoff of the low-level stuff; taken to fdtable.h
      Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      9f3acc31
  17. 01 5月, 2008 5 次提交
  18. 30 4月, 2008 2 次提交