Hello Tejun, Tejun Heo wrote: > 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. Hmm.. I am not sure if "leaving things as it is" is the better way, because this behaviour comes every time, I insert a card! And with my patch I can prevent this behaviour ... > Thanks for testing. Thanks for your comments! bye Heiko -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany -- 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
