Re: ata, pcmcia: problem with irq and ata_dev_read_id()

[Tejun Heo <htejun@gmail.com>]

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