Messages in this thread | | | Date | Thu, 11 Sep 2008 08:19:19 +0400 | From | Mikhail Kshevetskiy <> | Subject | Re: forcedeth: option to disable 100Hz timer (try 2) |
| |
On Wed, 10 Sep 2008 17:36:30 -0700 Andrew Morton <akpm@linux-foundation.org> wrote:
> On Wed, 10 Sep 2008 18:18:20 -0600 > Robert Hancock <hancockr@shaw.ca> wrote: > > > Andrew Morton wrote: > > > On Tue, 9 Sep 2008 23:34:35 +0400 > > > Mikhail Kshevetskiy <mikhail.kshevetskiy@gmail.com> wrote: > > > > > >> On some hardware no TX done interrupts are generated, thus special > > >> 100Hz timer interrupt is required to handle this situation properly. > > >> Other device do not require that timer interrupt feature. > > >> > > >> Forcedeth has a DEV_NEED_TIMERIRQ flag to mark the broken devices. > > >> Unfortunately, nobody know the actual list of broken devices, so all > > >> device has this flag on. Other problem, this flag is not user visible, > > >> so the kernel recompilation is required to disable timer interrupts and > > >> test a device. > > >> > > >> This patch add a "disable_timerirq" option to disable interrupt > > >> timer mentioned above. This may be extremely useful for laptop users. > > > > > > Why do you feel that the timer-based completions need to be disabled? > > > Is it causing some problem? > > > > 100 unnecessary CPU wakeups per second imposes some power usage cost, > > especially on laptops with CPU C-states.. > > Is that the only reason for the change? We still don't know... > > > > Anyway, it's certainly _sufficient_ reason, however the implementation > is pretty sad - most people won't even know that the option exists so > they'll continue to chew more power than they need to. > > How do we fix this? Perhaps disable the timer by default, then wait > for the first tx timeout and then enable the timer at that stage, while > printing a message saying "add module option <foo> to prevent this > once-off timeout from happening"?
I'll try this
| |