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

[Heiko Schocher <hs@denx.de>]

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