linux-kernel - Re: forcedeth: option to disable 100Hz timer (try 2)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 10 Sep 2008 22:25:03 -0600
From:	Robert Hancock <hancockr@...w.ca>
To:	Andrew Morton <akpm@...ux-foundation.org>
CC:	mikhail.kshevetskiy@...il.com, linux-kernel@...r.kernel.org,
	aabdulla@...dia.com, jgarzik@...ox.com
Subject: Re: forcedeth: option to disable 100Hz timer (try 2)

Andrew Morton wrote:
> On Wed, 10 Sep 2008 18:18:20 -0600
> Robert Hancock <hancockr@...w.ca> wrote:
> 
>> Andrew Morton wrote:
>>> On Tue, 9 Sep 2008 23:34:35 +0400
>>> Mikhail Kshevetskiy <mikhail.kshevetskiy@...il.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"?

It at least provides some way forward, where those that care can add the 
option and find out if their chipset can have the timer disabled in the 
driver by default in the future..

I'm not sure how long the TX timeout is, but I suspect it would be too 
disruptive to only enable the interrupt after a timeout. Enabling by 
default and disabling after a TX done interrupt was received would 
likely be a better approach (or one of the more creative approaches that 
others have mentioned). But it's quite likely that at least some of the 
chipsets that this driver supports don't need this timer nonsense at all.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/