Hello, On 07/05/2010 11:25 AM, Heiko Schocher wrote: >> Yeah, that's the new polling code kicking in. If the IRQ problem >> doesn't persiste (which should be the case here), polling will step >> down after a while and everything will return to normal. If you keep >> the system running more than ten minutes and use the CF device, does >> the kernel complain anymore? > > No, I can use the CF while kernel is in polling mode, also if the > kernel switched back to irq mode: > > Log, direct after kernel is up: > .. > 25: 9 MPC8XX SIU Level pata_pcmcia > 26: 10000 MPC8XX SIU Level pata_pcmcia ... > > No irq is used. > > -bash-3.2# dmesg > [...] > Freeing unused kernel memory: 132k init > IRQ 26: spurious polling finished, reenabling IRQ > -bash-3.2# > > Now it is back in irq mode: > > -bash-3.2# cat /proc/uptime > 419.65 370.56 > -bash-3.2# > ... > 25: 9 MPC8XX SIU Level pata_pcmcia > 26: 10033 MPC8XX SIU Level pata_pcmcia Cool, so it works as expected. With the new lost/spurious IRQ handling in place, removing TFLAG_POLLING from read_id for all controllers shouldn't cause much problem. However, the CF device is a pretty rare corner case and spurious IRQ handling can deal with it without too much problem, so leaving things as it is is probably better. Thanks for testing. -- tejun -- To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
