High CPU load in "top" due to budget_av slot polling

saa7146: saa7146_wait_for_debi_done_sleep(): saa7146 (0):

Hello all,

meanwhile I also found old threads from August 2007 and earlier, named "System load raises when budget_av is loaded" and "System load raises when budget_av is loaded", which describe exactly the same issue. However, both were written before the latest code changes.

The latest debi_done code change from November 2007 does not use any DEBI_E checks anymore. To my understanding this SAA7146 event indicates
DEBI errors like timeout via PCI and should be received by the driver much earlier than those 250ms (=end of cycle). Seems like I have to
play around with this myself.

Time for a bugzilla ticket?

Hello,

on 2.6.24 I run into a small issue with the budget_av driver:

Hardware: Athlon 64X2 3800+, Satelco Easywatch DVB-C (1894:002c), no CI/CAM
Software: Linux kernel 2.6.24 (gentoo-r4) SMP x86_64, budget_av module

Error description:
After the budget_av driver module is loaded (even without any DVB application), the CPU load average in 'top' rises to ~1, but in top no active tasks are found. After unloading the driver, the load decreases again to ~0.

Displaying the blocked tasks during high load with Alt-SysRq-W shows that the kdvb-ca kernel thread seems to be accounted as blocked when it polls for the CI slot status:
---------------------------------------------------
SysRq : Show Blocked State
task PC stack pid father
kdvb-ca-0:0 D 0000000100d78984 0 2046 2
ffff81007ee73c70 0000000000000046 0000000000000000 0000000000000008 0000000000000800 0000000000000000 0000000000000286 ffff81007bebe080 ffff81007f8d47e0 ffff81007ee73c80 ffff81007ed91a00 0000000100d78984

Call Trace:
[<ffffffff80241da6>] __mod_timer+0xb6/0xd0
[<ffffffff804e52ff>] schedule_timeout+0x5f/0xd0
[<ffffffff80241890>] process_timeout+0x0/0x10
[<ffffffff80241dd6>] msleep+0x16/0x30
[<ffffffff880a0189>] :saa7146:saa7146_wait_for_debi_done+0x159/0x260
[<ffffffff880bba3a>] :budget_core:ttpci_budget_debiread+0x6a/0x140
[<ffffffff880d1cfb>] :budget_av:ciintf_poll_slot_status+0xbb/0x1c0
[<ffffffff880aa800>] :dvb_core:dvb_ca_en50221_thread+0x0/0xa10
[<ffffffff880a9339>] :dvb_core:dvb_ca_en50221_check_camstatus+0x59/0x100
[<ffffffff880aa8ba>] :dvb_core:dvb_ca_en50221_thread+0xba/0xa10
[<ffffffff8022f221>] update_curr+0x61/0xb0
[<ffffffff8022f221>] update_curr+0x61/0xb0
[<ffffffff802341e6>] dequeue_task_fair+0x46/0x80
[<ffffffff8022f79d>] __dequeue_entity+0x3d/0x50
[<ffffffff804e4a7e>] thread_return+0x3d/0x52f
[<ffffffff80288da4>] filp_close+0x54/0x90
[<ffffffff880aa800>] :dvb_core:dvb_ca_en50221_thread+0x0/0xa10
[<ffffffff8024d48b>] kthread+0x4b/0x80
[<ffffffff8020ca48>] child_rip+0xa/0x12
[<ffffffff8024d440>] kthread+0x0/0x80
[<ffffffff8020ca3e>] child_rip+0x0/0x12
---------------------------------------------------

Enabling debug traces shows that polling for the PSR in function 'saa7146_wait_for_debi_done_sleep' constantly times out after 250x1ms sleeps:

Quoted 1 line

saa7146: saa7146_wait_for_debi_done_sleep(): saa7146 (0):

saa7146_wait_for_debi_done_sleep timed out while waiting for transfer completion

Increasing the 250ms did not avoid the timeout. And as I understood from previous list mails, this timeout is normal when no CI/CAM is connected to the DEBI. However, for me the high frequency polling does not make sense if someone does not plan to plug in a CI/CAM.

When commenting out two lines in 'dvb_ca_en50221_thread_update_delay' to increase the polling timer for slotstate NONE from 100ms (!) to 60s, the CPU load went down to 0. So this is some kind of workaround for me.

Please note: The high CPU load is not only a statistical issue due to the kernel accounting. It would put at least some unnecessary stress on PCI and CPU and e.g. also has the effect that cron tasks with idle guard condition would not start, so on midterm this should be fixed.

Finally, my questions:
1. Did I understand this right, that the behaviour above is expected when no CI is connected?

2. Are all budget_av cards unable to check CAM slot state via interrupt for HW reasons (as budget_ci does)?

3. Would it be possible to substitute the current PSR DEBI_S polling with an interrupt based solution via IER/ISR? (driver av7110 alreadys seems to do this for its DEBI DMA)? Or was this not considered worthy, due to the expected short waiting period and the tricky IER handling? The code does not state further thoughts about this.

4. Are the high timeout periods in debi_done (50ms/250ms) in relation to the 100ms poll timer intended? (I found the recent patch to this code in the mailing list end of last year)

5. If we would be restricted to poll with high frequency: Why not at least allow users without CI to disable polling for slots or change the interval, e.g. via module options?

Quoted 20 lines · Robert Schedel

Hello,

on 2.6.24 I run into a small issue with the budget_av driver:

Hardware: Athlon 64X2 3800+, Satelco Easywatch DVB-C (1894:002c), no CI/CAM
Software: Linux kernel 2.6.24 (gentoo-r4) SMP x86_64, budget_av module

Error description:
After the budget_av driver module is loaded (even without any DVB application), the CPU load average in 'top' rises to ~1, but in top no active tasks are found. After unloading the driver, the load decreases again to ~0.

Displaying the blocked tasks during high load with Alt-SysRq-W shows that the kdvb-ca kernel thread seems to be accounted as blocked when it polls for the CI slot status:
---------------------------------------------------
[...]
---------------------------------------------------

Enabling debug traces shows that polling for the PSR in function 'saa7146_wait_for_debi_done_sleep' constantly times out after 250x1ms sleeps:

Quoted 1 line

saa7146: saa7146_wait_for_debi_done_sleep(): saa7146 (0):

saa7146_wait_for_debi_done_sleep timed out while waiting for transfer completion

Quoted 3 lines

Increasing the 250ms did not avoid the timeout. And as I understood from previous list mails, this timeout is normal when no CI/CAM is connected to the DEBI. However, for me the high frequency polling does not make sense if someone does not plan to plug in a CI/CAM.

When commenting out two lines in 'dvb_ca_en50221_thread_update_delay' to increase the polling timer for slotstate NONE from 100ms (!) to 60s, the CPU load went down to 0. So this is some kind of workaround for me.

Afaics the polling interval could be increased to something like 5s or 10s if (and only if) the slot is empty. Could you provide a patch?

Quoted 2 lines

Finally, my questions:
1. Did I understand this right, that the behaviour above is expected when no CI is connected?

Yes, but afaics the polling interval is way too short.

Quoted 2 lines

2. Are all budget_av cards unable to check CAM slot state via interrupt for HW reasons (as budget_ci does)?

I don't have any budget-av hardware, so I don't know.
But I think that Andrew(?) had a good reason to implement it this way. (In contrast the budget-ci driver was always interrupt-driven.)

If someone finds out that a given card can operate in interrupt mode, it should be changed for this card. Patches are welcome. ;-)

Quoted 1 line

3. Would it be possible to substitute the current PSR DEBI_S polling with an interrupt based solution via IER/ISR? (driver av7110 alreadys seems to do this for its DEBI DMA)? Or was this not considered worthy, due to the expected short waiting period and the tricky IER handling? The code does not state further thoughts about this.

The av7110 driver uses interrupt mode for buffer transfers in dma mode. It does not make much sense to use interrupt mode for single-word transfers, because the single-word transfers are very fast. But I understand that the timeout causes a problem in this case.

Quoted 1 line

4. Are the high timeout periods in debi_done (50ms/250ms) in relation to the 100ms poll timer intended? (I found the recent patch to this code in the mailing list end of last year)

That patch was applied to reduce the load on the pci bus in busy-wait mode. Basically it did not change anything for cam polling. (In fact I was not aware that the CAM was polled every 100ms. Imho this should be fixed.)

Quoted 2 lines

5. If we would be restricted to poll with high frequency: Why not at least allow users without CI to disable polling for slots or change the interval, e.g. via module options?

Module options are evil. ;-)
We should do this only if everything else fails.

Attached a patch for 2.6.24.4. Opinions?

Is the 250ms timeout an approved limit? Decreasing it would push the load further down. Probably it still has to cover slow CAMs as well as a stressed PCI bus. Unfortunately, without CAM/CI I cannot make any statements myself.

Quoted 4 lines · Robert Schedel

Is the 250ms timeout an approved limit? Decreasing it would push the load further down. Probably it still has to cover slow CAMs as well as a stressed PCI bus. Unfortunately, without CAM/CI I cannot make any statements myself.

Just got another idea to improve the code: Function "saa7146_wait_for_debi_done_sleep" could be reworked to use what is known as "truncated binary exponential backoff" algorithm. IOW, on each sleep duplicate the period from 1ms until a fixed maximum, e.g. 32ms. This way polling ends fast for those users with fast bus/CAM, and those requiring 200ms due to slow bus/CAM should not worry about e.g. 216ms response time.

My first tests look promising (load goes down to 0). However, is not the simple BEB algorithm already patented?

Quoted 14 lines · Robert Schedel

Quoted 4 lines · Robert Schedel

Is the 250ms timeout an approved limit? Decreasing it would push the load further down. Probably it still has to cover slow CAMs as well as a stressed PCI bus. Unfortunately, without CAM/CI I cannot make any statements myself.

Just got another idea to improve the code: Function "saa7146_wait_for_debi_done_sleep" could be reworked to use what is known as "truncated binary exponential backoff" algorithm. IOW, on each sleep duplicate the period from 1ms until a fixed maximum, e.g. 32ms. This way polling ends fast for those users with fast bus/CAM, and those requiring 200ms due to slow bus/CAM should not worry about e.g. 216ms response time.

Quoted 2 lines

My first tests look promising (load goes down to 0). However, is not the simple BEB algorithm already patented?

Load should go down to 0 if the sleep call does not busy-wait.

Please test whether the attached code fixes the problem. Btw, I will not claim a patent for that. :D

Quoted 34 lines · Oliver Endriss

Quoted 33 lines · Robert Schedel

Hello,

on 2.6.24 I run into a small issue with the budget_av driver:

Hardware: Athlon 64X2 3800+, Satelco Easywatch DVB-C (1894:002c), no CI/CAM
Software: Linux kernel 2.6.24 (gentoo-r4) SMP x86_64, budget_av module

Error description:
After the budget_av driver module is loaded (even without any DVB application), the CPU load average in 'top' rises to ~1, but in top no active tasks are found. After unloading the driver, the load decreases again to ~0.

Displaying the blocked tasks during high load with Alt-SysRq-W shows that the kdvb-ca kernel thread seems to be accounted as blocked when it polls for the CI slot status:
---------------------------------------------------
[...]
---------------------------------------------------

Enabling debug traces shows that polling for the PSR in function 'saa7146_wait_for_debi_done_sleep' constantly times out after 250x1ms sleeps:

Quoted 1 line

saa7146: saa7146_wait_for_debi_done_sleep(): saa7146 (0):

saa7146_wait_for_debi_done_sleep timed out while waiting for transfer completion

Increasing the 250ms did not avoid the timeout. And as I understood from previous list mails, this timeout is normal when no CI/CAM is connected to the DEBI. However, for me the high frequency polling does not make sense if someone does not plan to plug in a CI/CAM.

Quoted 6 lines

Quoted 3 lines

When commenting out two lines in 'dvb_ca_en50221_thread_update_delay' to increase the polling timer for slotstate NONE from 100ms (!) to 60s, the CPU load went down to 0. So this is some kind of workaround for me.

Afaics the polling interval could be increased to something like 5s or 10s if (and only if) the slot is empty. Could you provide a patch?

Attached a patch for 2.6.24.4. Opinions?

Unfortunately, a 5s poll interval for empty slots still results in a load average of about 0,06 (~ 250ms/5s).

Increasing to 10s would decrease the load and be fine for people without CAM, but increase the delay for those users inserting CAMs during runtime. 5s sounds like a reasonable tradeoff.

Is the 250ms timeout an approved limit? Decreasing it would push the load further down. Probably it still has to cover slow CAMs as well as a stressed PCI bus. Unfortunately, without CAM/CI I cannot make any statements myself.

Quoted 13 lines

Quoted 3 lines

Finally, my questions:
1. Did I understand this right, that the behaviour above is expected when no CI is connected?

Yes, but afaics the polling interval is way too short.

Quoted 2 lines

2. Are all budget_av cards unable to check CAM slot state via interrupt for HW reasons (as budget_ci does)?

I don't have any budget-av hardware, so I don't know.
But I think that Andrew(?) had a good reason to implement it this way. (In contrast the budget-ci driver was always interrupt-driven.)

Quoted 2 lines

If someone finds out that a given card can operate in interrupt mode, it should be changed for this card. Patches are welcome. ;-)

My impression is, due to the different GPIO layout there is no way to get a CAM change IRQ. But it seems difficult to get information about the HW architecture of cards at all.

Regarding DEBI_E: Just found a av7110 code comment which also reflects what my recent tests showed:

          /* Note: Don't try to handle the DEBI error irq (MASK_18), in
           * intel mode the timeout is asserted all the time...
           */

So really only DEBI_S would be left, see below.

Quoted 10 lines

Quoted 5 lines

3. Would it be possible to substitute the current PSR DEBI_S polling with an interrupt based solution via IER/ISR? (driver av7110 alreadys seems to do this for its DEBI DMA)? Or was this not considered worthy, due to the expected short waiting period and the tricky IER handling? The code does not state further thoughts about this.

The av7110 driver uses interrupt mode for buffer transfers in dma mode. It does not make much sense to use interrupt mode for single-word transfers, because the single-word transfers are very fast. But I understand that the timeout causes a problem in this case.

OK, interrupts of course decrease performance in the "sunny day" cases (=communication with inserted card in slot state READY). Having both approaches (interrupt when slotstate empty, later polling) would combine all benefits but also be somewhat crazy.

Quoted 4 lines

Quoted 3 lines

4. Are the high timeout periods in debi_done (50ms/250ms) in relation to the 100ms poll timer intended? (I found the recent patch to this code in the mailing list end of last year)

Quoted 4 lines

That patch was applied to reduce the load on the pci bus in busy-wait mode. Basically it did not change anything for cam polling. (In fact I was not aware that the CAM was polled every 100ms. Imho this should be fixed.)

Only wondered whether the 250ms might have been smaller in former driver versions.

Quoted 35 lines · Robert Schedel

Quoted 34 lines · Oliver Endriss

Quoted 33 lines · Robert Schedel

Hello,

on 2.6.24 I run into a small issue with the budget_av driver:

Hardware: Athlon 64X2 3800+, Satelco Easywatch DVB-C (1894:002c), no CI/CAM
Software: Linux kernel 2.6.24 (gentoo-r4) SMP x86_64, budget_av module

Error description:
After the budget_av driver module is loaded (even without any DVB application), the CPU load average in 'top' rises to ~1, but in top no active tasks are found. After unloading the driver, the load decreases again to ~0.

Displaying the blocked tasks during high load with Alt-SysRq-W shows that the kdvb-ca kernel thread seems to be accounted as blocked when it polls for the CI slot status:
---------------------------------------------------
[...]
---------------------------------------------------

Enabling debug traces shows that polling for the PSR in function 'saa7146_wait_for_debi_done_sleep' constantly times out after 250x1ms sleeps:

Quoted 1 line

saa7146: saa7146_wait_for_debi_done_sleep(): saa7146 (0):

saa7146_wait_for_debi_done_sleep timed out while waiting for transfer completion

Increasing the 250ms did not avoid the timeout. And as I understood from previous list mails, this timeout is normal when no CI/CAM is connected to the DEBI. However, for me the high frequency polling does not make sense if someone does not plan to plug in a CI/CAM.

Quoted 8 lines

Quoted 6 lines

Quoted 3 lines

When commenting out two lines in 'dvb_ca_en50221_thread_update_delay' to increase the polling timer for slotstate NONE from 100ms (!) to 60s, the CPU load went down to 0. So this is some kind of workaround for me.

Afaics the polling interval could be increased to something like 5s or 10s if (and only if) the slot is empty. Could you provide a patch?

Attached a patch for 2.6.24.4. Opinions?

Basically it should work but it has to be tested with CI/CAM, too. Furthermore it is not sufficient to test with budget-av because many other drivers will be affected.

So I would prefer a patch which does not touch behaviour for other card drivers (if possible).

Please note for 'final' patches:
Always run 'checkpatch.pl' and fix the errors.
Sorry for that. :-(

Quoted 25 lines

Unfortunately, a 5s poll interval for empty slots still results in a load average of about 0,06 (~ 250ms/5s).

Increasing to 10s would decrease the load and be fine for people without CAM, but increase the delay for those users inserting CAMs during runtime. 5s sounds like a reasonable tradeoff.

Is the 250ms timeout an approved limit? Decreasing it would push the load further down. Probably it still has to cover slow CAMs as well as a stressed PCI bus. Unfortunately, without CAM/CI I cannot make any statements myself.

Quoted 13 lines

Quoted 3 lines

Finally, my questions:
1. Did I understand this right, that the behaviour above is expected when no CI is connected?

Yes, but afaics the polling interval is way too short.

Quoted 2 lines

2. Are all budget_av cards unable to check CAM slot state via interrupt for HW reasons (as budget_ci does)?

I don't have any budget-av hardware, so I don't know.
But I think that Andrew(?) had a good reason to implement it this way. (In contrast the budget-ci driver was always interrupt-driven.)

Quoted 6 lines

Quoted 2 lines

If someone finds out that a given card can operate in interrupt mode, it should be changed for this card. Patches are welcome. ;-)

My impression is, due to the different GPIO layout there is no way to get a CAM change IRQ. But it seems difficult to get information about the HW architecture of cards at all.

For most cards we have no hw info. :-(

Quoted 7 lines

Regarding DEBI_E: Just found a av7110 code comment which also reflects what my recent tests showed:

          /* Note: Don't try to handle the DEBI error irq (MASK_18), in
           * intel mode the timeout is asserted all the time...
           */

So really only DEBI_S would be left, see below.

Did you check whether DEBI_S and/or DEBI_E are ever asserted with your setup? If not, an interrupt would never occur anyway...

Quoted 20 lines

Quoted 10 lines

Quoted 5 lines

3. Would it be possible to substitute the current PSR DEBI_S polling with an interrupt based solution via IER/ISR? (driver av7110 alreadys seems to do this for its DEBI DMA)? Or was this not considered worthy, due to the expected short waiting period and the tricky IER handling? The code does not state further thoughts about this.

The av7110 driver uses interrupt mode for buffer transfers in dma mode. It does not make much sense to use interrupt mode for single-word transfers, because the single-word transfers are very fast. But I understand that the timeout causes a problem in this case.

OK, interrupts of course decrease performance in the "sunny day" cases (=communication with inserted card in slot state READY). Having both approaches (interrupt when slotstate empty, later polling) would combine all benefits but also be somewhat crazy.

Quoted 4 lines

Quoted 3 lines

4. Are the high timeout periods in debi_done (50ms/250ms) in relation to the 100ms poll timer intended? (I found the recent patch to this code in the mailing list end of last year)

Quoted 7 lines

Quoted 4 lines

That patch was applied to reduce the load on the pci bus in busy-wait mode. Basically it did not change anything for cam polling. (In fact I was not aware that the CAM was polled every 100ms. Imho this should be fixed.)

Only wondered whether the 250ms might have been smaller in former driver versions.

Iirc it should be even worse with older drivers.

Basically the 250ms timeout is just a last resort to escape from the loop, if the debi transfer hangs for some reason. We might try to reduce the timeout but I don't know how far we can go. (Touching 'magic' values might be dangeous.)

CU
Oliver

Quoted 8 lines · Robert Schedel

Quoted 7 lines · Oliver Endriss

Quoted 6 lines · Robert Schedel

Enabling debug traces shows that polling for the PSR in function 'saa7146_wait_for_debi_done_sleep' constantly times out after 250x1ms sleeps:

Quoted 1 line

saa7146: saa7146_wait_for_debi_done_sleep(): saa7146 (0):

saa7146_wait_for_debi_done_sleep timed out while waiting for transfer completion

Quoted 6 lines

Quoted 5 lines

Quoted 3 lines

Increasing the 250ms did not avoid the timeout. And as I understood from previous list mails, this timeout is normal when no CI/CAM is connected to the DEBI. However, for me the high frequency polling does not make sense if someone does not plan to plug in a CI/CAM.

When commenting out two lines in 'dvb_ca_en50221_thread_update_delay' to increase the polling timer for slotstate NONE from 100ms (!) to 60s, the CPU load went down to 0. So this is some kind of workaround for me.

Afaics the polling interval could be increased to something like 5s or 10s if (and only if) the slot is empty. Could you provide a patch?

Attached a patch for 2.6.24.4. Opinions?

Basically it should work but it has to be tested with CI/CAM, too.

Furthermore it is not sufficient to test with budget-av because many other drivers will be affected.

So I would prefer a patch which does not touch behaviour for other card drivers (if possible).

Please note for 'final' patches:
Always run 'checkpatch.pl' and fix the errors.
Sorry for that. :-(

Quoted 7 lines

Regarding DEBI_E: Just found a av7110 code comment which also reflects what my recent tests showed:

          /* Note: Don't try to handle the DEBI error irq (MASK_18), in
           * intel mode the timeout is asserted all the time...
           */

So really only DEBI_S would be left, see below.

Did you check whether DEBI_S and/or DEBI_E are ever asserted with your setup? If not, an interrupt would never occur anyway...

Quoted 7 lines

Quoted 5 lines

Quoted 1 line

4. Are the high timeout periods in debi_done (50ms/250ms) in relation to the 100ms poll timer intended? (I found the recent patch to this code in the mailing list end of last year)

That patch was applied to reduce the load on the pci bus in busy-wait mode. Basically it did not change anything for cam polling. (In fact I was not aware that the CAM was polled every 100ms. Imho this should be fixed.)

Only wondered whether the 250ms might have been smaller in former driver versions.

Iirc it should be even worse with older drivers.

Basically the 250ms timeout is just a last resort to escape from the loop, if the debi transfer hangs for some reason. We might try to reduce the timeout but I don't know how far we can go. (Touching 'magic' values might be dangeous.)

Quoted 20 lines · Oliver Endriss

Quoted 19 lines · Robert Schedel

Quoted 18 lines · Oliver Endriss

Quoted 17 lines · Robert Schedel

Enabling debug traces shows that polling for the PSR in function 'saa7146_wait_for_debi_done_sleep' constantly times out after 250x1ms sleeps:

Quoted 1 line

saa7146: saa7146_wait_for_debi_done_sleep(): saa7146 (0):

saa7146_wait_for_debi_done_sleep timed out while waiting for transfer completion

Increasing the 250ms did not avoid the timeout. And as I understood from previous list mails, this timeout is normal when no CI/CAM is connected to the DEBI. However, for me the high frequency polling does not make sense if someone does not plan to plug in a CI/CAM.

When commenting out two lines in 'dvb_ca_en50221_thread_update_delay' to increase the polling timer for slotstate NONE from 100ms (!) to 60s, the CPU load went down to 0. So this is some kind of workaround for me.

Quoted 5 lines

Quoted 3 lines

Quoted 2 lines

Afaics the polling interval could be increased to something like 5s or 10s if (and only if) the slot is empty. Could you provide a patch?

Attached a patch for 2.6.24.4. Opinions?

Basically it should work but it has to be tested with CI/CAM, too.

Correct, unfortunately I cannot test it against a CI.

Quoted 5 lines

Furthermore it is not sufficient to test with budget-av because many other drivers will be affected.

So I would prefer a patch which does not touch behaviour for other card drivers (if possible).

To my understanding of the DVB code dvb_ca_en50221 is only referenced by budget_av and budget_ci, at least in the vanilla kernel 2.6.25.

The patch only changes the timer for slot state EMPTY if DVB_CA_EN50221_FLAG_IRQ_CAMCHANGE is not set, which is for
1) budget_av
2) budget_ci if the CI firmware version is 0xa2 (because IRQs for CAM change are not supported in this version)

And those two cases are probably affected by the load issue and should be fixed.

Of course, we could add another DVB_CA_EN50221 flag solely for budget_av to exclude case 2), but does this make sense? Who is available to test against a budget_ci with FW=0xa2 whether it is affected by the load issue?

Quoted 8 lines

Quoted 7 lines

Regarding DEBI_E: Just found a av7110 code comment which also reflects what my recent tests showed:

          /* Note: Don't try to handle the DEBI error irq (MASK_18), in
           * intel mode the timeout is asserted all the time...
           */

So really only DEBI_S would be left, see below.

Quoted 2 lines

Did you check whether DEBI_S and/or DEBI_E are ever asserted with your setup? If not, an interrupt would never occur anyway...

DEBI_E was always asserted (as described in the av7110 code comment), so it was worthless. DEBI_S was never asserted without CI (therefore the 250ms timeout), so it would probably only be received when a CI is used. But as described in my other email with measurements, it seems that there is no need to optimize the debi_done function further.

Quoted 12 lines

Quoted 9 lines

Quoted 7 lines

Quoted 3 lines

4. Are the high timeout periods in debi_done (50ms/250ms) in relation to the 100ms poll timer intended? (I found the recent patch to this code in the mailing list end of last year)

That patch was applied to reduce the load on the pci bus in busy-wait mode. Basically it did not change anything for cam polling. (In fact I was not aware that the CAM was polled every 100ms. Imho this should be fixed.)

Only wondered whether the 250ms might have been smaller in former driver versions.

Iirc it should be even worse with older drivers.

Quoted 4 lines

Basically the 250ms timeout is just a last resort to escape from the loop, if the debi transfer hangs for some reason. We might try to reduce the timeout but I don't know how far we can go. (Touching 'magic' values might be dangeous.)

As above, according to my measurements we would not need to change the 250ms timeout.