<3>BUG: soft lockup - CPU#0 stuck for 25s! [pppd:3976]
<4>Modules linked in: i2c_bit2(P) i2c_bit1(P)
<4>
<4>Pid: 3976, comm:                 pppd
<4>CPU: 0    Tainted: P            (2.6.30 #2)
<4>PC is at __do_softirq+0x4c/0x104
<4>LR is at __do_softirq+0x38/0x104
<4>pc : [<c003b988>]    lr : [<c003b974>]    psr: 20000013
<4>sp : c39d9d50  ip : c39d9d50  fp : 00000000
<4>r10: 0000000a  r9 : 00000000  r8 : 00000001
<4>r7 : 00000008  r6 : c39d8000  r5 : 00000000  r4 : c0304320
<4>r3 : 20000013  r2 : c39d8000  r1 : 00000003  r0 : 00000000
<4>Flags: nzCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment user
<4>Control: 0005317f  Table: 23b94000  DAC: 00000015
<4>[<c0029580>] (unwind_backtrace+0x0/0xdc) from [<c005f5dc>] (softlockup_tick+0x134/0x19c)
<4>[<c005f5dc>] (softlockup_tick+0x134/0x19c) from [<c0040d9c>] (update_process_times+0x2c/0x5c)
<4>[<c0040d9c>] (update_process_times+0x2c/0x5c) from [<c0057180>] (tick_sched_timer+0x88/0xbc)
<4>[<c0057180>] (tick_sched_timer+0x88/0xbc) from [<c004efc8>] (__run_hrtimer+0x64/0x130)
<4>[<c004efc8>] (__run_hrtimer+0x64/0x130) from [<c004fd38>] (hrtimer_interrupt+0x18c/0x218)
<4>[<c004fd38>] (hrtimer_interrupt+0x18c/0x218) from [<c01bfa70>] (ch2_irq+0x24/0x30)
<4>[<c01bfa70>] (ch2_irq+0x24/0x30) from [<c005fc70>] (handle_IRQ_event+0x40/0x114)
<4>[<c005fc70>] (handle_IRQ_event+0x40/0x114) from [<c0061aec>] (handle_level_irq+0xbc/0x138)
<4>[<c0061aec>] (handle_level_irq+0xbc/0x138) from [<c0024050>] (_text+0x50/0x78)
<4>[<c0024050>] (_text+0x50/0x78) from [<c0024a68>] (__irq_svc+0x48/0x8c)
<4>Exception stack(0xc39d9d08 to 0xc39d9d50)
<4>9d00:                   00000000 00000003 c39d8000 20000013 c0304320 00000000
<4>9d20: c39d8000 00000008 00000001 00000000 0000000a 00000000 c39d9d50 c39d9d50
<4>9d40: c003b974 c003b988 20000013 ffffffff
<4>[<c0024a68>] (__irq_svc+0x48/0x8c) from [<c003b974>] (__do_softirq+0x38/0x104)
<4>[<c003b974>] (__do_softirq+0x38/0x104) from [<c003ba84>] (irq_exit+0x44/0x98)
<4>[<c003ba84>] (irq_exit+0x44/0x98) from [<c0024060>] (_text+0x60/0x78)
<4>[<c0024060>] (_text+0x60/0x78) from [<c0024a68>] (__irq_svc+0x48/0x8c)
<4>Exception stack(0xc39d9d98 to 0xc39d9de0)
<4>9d80:                                                       c030c600 800008be
<4>9da0: c4868000 000f0000 c00008c2 c030c600 c3adbb60 0000013e a0000013 c397e910
<4>9dc0: 00004b00 c3adbb60 0000000a c39d9de0 c015b800 c015b814 60000013 ffffffff
<4>[<c0024a68>] (__irq_svc+0x48/0x8c) from [<c015b800>] (atmel_set_termios+0x1e8/0x22c)
<4>[<c015b800>] (atmel_set_termios+0x1e8/0x22c) from [<c0157d70>] (uart_change_speed+0x70/0x74)
<4>[<c0157d70>] (uart_change_speed+0x70/0x74) from [<c01584d8>] (uart_set_termios+0x64/0x2f8)
<4>[<c01584d8>] (uart_set_termios+0x64/0x2f8) from [<c0147eec>] (change_termios+0x258/0x2d4)
<4>[<c0147eec>] (change_termios+0x258/0x2d4) from [<c0148288>] (set_termios+0x1e0/0x1f4)
<4>[<c0148288>] (set_termios+0x1e0/0x1f4) from [<c01483b8>] (tty_mode_ioctl+0x11c/0x418)
<4>[<c01483b8>] (tty_mode_ioctl+0x11c/0x418) from [<c0143ee4>] (tty_ioctl+0x608/0x664)
<4>[<c0143ee4>] (tty_ioctl+0x608/0x664) from [<c0095364>] (vfs_ioctl+0x2c/0x8c)
<4>[<c0095364>] (vfs_ioctl+0x2c/0x8c) from [<c009593c>] (do_vfs_ioctl+0x268/0x2a0)
<4>[<c009593c>] (do_vfs_ioctl+0x268/0x2a0) from [<c00959ac>] (sys_ioctl+0x38/0x5c)
<4>[<c00959ac>] (sys_ioctl+0x38/0x5c) from [<c0024e40>] (ret_fast_syscall+0x0/0x2c)


[frogger@hardanger:linux-2.6 (master)]$ git show 0ccad87012c6c2e7446e4dc0f0894cf182a5270a
commit 0ccad87012c6c2e7446e4dc0f0894cf182a5270a
Author: Haavard Skinnemoen <haavard.skinnemoen@atmel.com>
Date:   Tue Jun 16 17:02:03 2009 +0100

    atmel_serial: fix hang in set_termios when crtscts is enabled

    After enabling hardware flow control, any subsequent termios call may hang
    waiting for the transmitter to drain.  This appears to be caused by a
    busy-loop in set_termios() waiting for the transmitter to become empty,
    which may take a very long time (or hang indefinitely) if the device at
    the other end is blocking us.

    A quick look through the tty and serial_core code indicates that any
    necessary flushing (which is optional) has already been done at this
    point, so there's no need for the driver to flush the transmitter on its
    own.

    Fix it by removing the busy-loop altogether.

    Tested-by: Eirik Aanonsen <eaa@wprmedical.com>
    Signed-off-by: Haavard Skinnemoen <haavard.skinnemoen@atmel.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Alan Cox <alan@linux.intel.com>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>