James Chapman wrote: > Mark Lord wrote: >> One way to deal with it in an embedded device, is to force the >> application that's generating the I/O to self-throttle. >> Or modify the device driver to self-throttle. > > Does disk access have to be so interrupt driven? Could disk interrupt > handling be done in a softirq/kthread like the networking guys deal with > network device interrupts? This would prevent the system from > live-locking when it is being bombarded with disk IO events. It doesn't > seem right that the disk IO subsystem can cause interrupt live-lock on > relatively slow CPUs... > >> You may want to find an embedded Linux consultant to help out >> with this situation if it's beyond your expertise. > > Check out the rtlinux patch, which pushes all interrupt handling out to > per-cpu kernel threads (irqd). The kernel scheduler then regains control > of what runs when. > > Another option is to change your ATA driver to do interrupt processing > at task level using a workqueue or similar. SFF ATA controllers are peculiar in that... 1. it doesn't have reliable IRQ pending bit. 2. it doesn't have reliable IRQ mask bit. 3. some controllers tank the machine completely if status or data register is accessed differently than the chip likes. So, it's not like we're all dickheads. We know it's good to take those out of irq handler. The hardware just isn't very forgiving and I bet you'll get obscure machine lockups if the RT kernel arbitrarily pushes ATA PIO data transfers into kernel threads. I think doing what IDE has been doing (disabling IRQ from interrupt controller) is the way to go. -- tejun - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
