Re: More 2.4.22pre10 ACPI breakage

Re: More 2.4.22pre10 ACPI breakage

[Jeff Garzik]

Feldman, Scott wrote:
>>  It appears that the intel Se7501BR mother is also having 
>>issues with ACPI.  When ACPI support is enable the e1000
>>controller stops working printing "<6>NETDEV WATCHDOG:
>>eth0: transmit timed out".
> 
> 
> Must...have...interrupts.

You are 100% correct.

That said... I'm tempted to extend NAPI just a bit, to provide an 
"always poll" mode.  It seems like all the bug reports I get these days 
for 8139too are caused by x86 ACPI/APIC/irq routing troubles completely 
unrelated to the driver.  Tulip-almost-NAPI in 2.4 has an always-poll 
mode, so I have a convenient excuse :)

	Jeff

RE: More 2.4.22pre10 ACPI breakage

[Feldman, Scott]

> That said... I'm tempted to extend NAPI just a bit, to provide an 
> "always poll" mode.  It seems like all the bug reports I get 
> these days for 8139too are caused by x86 ACPI/APIC/irq routing
troubles 
> completely unrelated to the driver.  Tulip-almost-NAPI in 2.4 has an
> always-poll mode, so I have a convenient excuse :)

NAPI always-poll mode...that would be fun to play with.  JC was getting
his best results for small packets when he modified the dev e100 driver
to stay in polling mode, even if the quota wasn't met.  Basically
running without interrupts.  If there is someway for the the driver to
sample/ack the device for events when interrupts are disabled/unrouted,
then these async events can be handled in the poll routine.  I'm
thinking of events like link-status-change.

Is this what you're thinking: 1) block any place the driver enables
interrupts so interrupts stay disabled, 2) ignore netif_rx_complete so
we stay in polling mode, 3) ignore return code from netdev->poll.

For 1), the driver needs some way to know that we're in always-poll-mode
so enabling interrupts is a nop.

Just thinking out loud - haven't tried any of this.

-scott

RE: More 2.4.22pre10 ACPI breakage

[Robert Olsson]

Feldman, Scott writes:

 > NAPI always-poll mode...that would be fun to play with...

 > Is this what you're thinking: 1) block any place the driver enables
 > interrupts so interrupts stay disabled, 2) ignore netif_rx_complete so
 > we stay in polling mode, 3) ignore return code from netdev->poll.
 > 
 > For 1), the driver needs some way to know that we're in always-poll-mode
 > so enabling interrupts is a nop.
 > 

 I will work but I doubt the usefulness of it as we spin aggressively even
 when there low or no load. This as NAPI tries to serve your dev->poll 
 fastest possible given the fairness conditions are met.
 
 I could think of a variant... 

 As dev->poll is callback we could possibly schedule (and delay) via a timer 
 or something with in turn does the the schedule dev->poll for us. We have 
 to return netif_rx_complete and have RX-buffers etc.


 > Just thinking out loud - haven't tried any of this.

 Same here... :-)

 Cheers.
						--ro