Grin#
>
> [<c01abce3>] c01abbe8 t ppa_completion
> [<co1b0378>] c01b0248 t aic7xxx_reset_current_bus
> [<c01ac2c5>] c01abf58 t ppa_engine
> [<c010aa65>] c010aa10 T handle_IRQ_event
> [<c01abeab>] c01abe80 t ppa_interrupt
> [<c0112852>] c01127f8 T tqueue_bh
> [<c0119b65>] c0119ae0 T do_bottom_half
> [<c0106000>] c0106000 T get_options
> [<c010abbd>] c010ab70 T do_IRQ
> [<c0108c9c>] c0108c9c T ret_from_intr
> [<c0106000>] c0106000 T get_options
> [<c0107347>] c010730c T cpu_idle
> [<c01075b7>] c0107594 T kernel_thread
>
> Well, I couldn't find any direct connection between ppa_completion (in
> ppa.c) and aic7xxx_reset_current_bus, so I guess I'll have to wait for
> further instructions.
That is quite reasonable. Things get left on the stack and the kernel
has to guess if they are relevant. The rest of the path looks quite
believable.
> really cannot pin it down to this particular problem:
>
> end SCSI request: buffer list destroyed
That is probably related. It means something truely horrid had happened
by the time the request completed - notably that it had been eaten
> Thanks again for assistance, the irony of backup lockups is getting
> _less_ funny with the passage of time, strangely enough.
Nod
-
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/