timer_bh behaviour incorrect for 2.2.13?

William Montgomery (william@opinicus.com)
Thu, 9 Dec 1999 09:52:44 -0500 (EST)


Bottom half behaviour for timer_bh does not appear correct
in some cases. Normally a timer_interrupt is followed by
do_bottom_half upon return from interrupt handling which then
calls timer_bh, however it is possible for do_bottom_half to be
interrupted by network code then timer_bh never runs and the
kernel returns to user space totally skipping timer_bh.

The following ktrace shows this:
c010a64d do_IRQ +<d/54> ( 0.39 ) ( 123767.76 ) pid(5392)
c010a1cf do_8259A_IRQ +<13/b4> ( 2.74 ) ( 123768.15 ) pid(5392)
c010a4f4 handle_IRQ_event +<10/78> ( 0.62 ) ( 123770.89 ) pid(5392)
c010e1ce timer_interrupt +<12/12c> ( 6.21 ) ( 123771.51) pid(5392)
c011418d do_timer +<d/5c> ( 1.20 ) ( 123777.72 ) pid(5392)
c010a109 enable_8259A_irq +<d/3c> ( 0.83 ) ( 123778.92 ) pid(5392)
c010a672 do_IRQ +<32/54> ( 0.13 ) ( 123779.75 ) pid(5392)
c011b630 do_bottom_half +<10/78> ( 0.14 ) ( 123779.88 ) pid(5392)
c010a68d do_IRQ +<4d/54> ( 1.19 ) ( 123780.02 ) pid(5392)
c0176841 tcp_send_delayed_ack +<d/60> ( 0.46 ) ( 123781.21 ) pid(5392)
c0112e7a add_timer +<e/190> ( 1.16 ) ( 123781.67 ) pid(5392)
c010a68d do_IRQ +<4d/54> ( 8294.68 ) ( 123782.83 ) pid(5392)
^^^----Ouch! Notice timer_bh is never run
until *after* the next timer_interrupt
c010a64d do_IRQ +<d/54> ( 0.44 ) ( 132077.51 ) pid(5392)
c010a1cf do_8259A_IRQ +<13/b4> ( 2.21 ) ( 132077.95 ) pid(5392)
c010a4f4 handle_IRQ_event +<10/78> ( 0.43 ) ( 132080.16 ) pid(5392)
c010e1ce timer_interrupt +<12/12c> ( 5.69 ) ( 132080.59 ) pid(5392)
c011418d do_timer +<d/5c> ( 0.77 ) ( 132086.28 ) pid(5392)
c010a109 enable_8259A_irq +<d/3c> ( 0.81 ) ( 132087.06 ) pid(5392)
c010a672 do_IRQ +<32/54> ( 0.13 ) ( 132087.86 ) pid(5392)
c011b630 do_bottom_half +<10/78> ( 0.66 ) ( 132087.99 ) pid(5392)
c0113e54 timer_bh +<10/33c> ( 0.77 ) ( 132088.65 ) pid(5392)

I set HZ=120 so it is reasonable for timer_interrupts to occur
at 8msec intervals. Also pid(5392) is set SCHED_FIFO and is
doing huge amounts of number crunching and hardly any system calls.

Many hours grepping and tracing kernel code has not revealed
the cause to me. Any ideas?

Wm

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/