netdev - Re: 2.6.20-rc7: known regressions (v2) (part 1)

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:	Sat, 03 Feb 2007 13:26:12 -0800
From:	Auke Kok <auke-jan.h.kok@...el.com>
To:	Adam Kropelin <akropel1@...hester.rr.com>
Cc:	Auke Kok <auke-jan.h.kok@...el.com>,
	"Eric W. Biederman" <ebiederm@...ssion.com>,
	Adrian Bunk <bunk@...sta.de>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	jgarzik@...ox.com, alan@...rguk.ukuu.org.uk,
	Allen Parker <parker@...hunt.com>, jesse.brandeburg@...el.com,
	gregkh@...e.de, linux-pci@...ey.karlin.mff.cuni.cz,
	netdev@...r.kernel.org
Subject: Re: 2.6.20-rc7: known regressions (v2) (part 1)

Adam Kropelin wrote:
> Auke Kok wrote:
>> Adam Kropelin wrote:
>>> I've never had this device work 100% with MSI on any kernel version
>>> I've tested so far. But I'm not the original reporter of the
>>> problem, and I believe for him it was a true regression where a
>>> previous kernel wored correctly.
>> maybe I've been unclear, but here's how e1000 detects link changes:
>>
>> 1) by checking every 2 seconds in the watchdog by reading PHY
>> registers
> 
> That would explain why I see link status changes but 0 interrupt count 
> in /proc/interrupts. However, on >= 2.6.19 the link state never changes. 
> Ever. It's always down. On <= 2.6.18 the link state does change but with 
> 0 interupt count.
> 
>> 2) by receiving an interrupt from the NIC with the LSI bit
>> in the interrupt control register
>>
>> if the link is down to start with, the watchdog will obviously spot a
>> 'link up' change since it doesn't use any interrupts.
> 
> This does not seem to work on 2.6.19+. Unless the watchdog interval is 
> tens of minutes. I've waited at least 5 minutes and link never went up.

that's explained by a driver change that did that. Since at initialization we're 
basically waiting for a link change to tell the stack that we're up, we decided 
to change the order to have the hardware fire an LSI interrupt to trigger a 
watchdog run. So no interrupts would immediately explain why the watchdog never 
runs. That's nothing to worry about for this problem, as soon as interrupts are 
seen in /proc/interrupts this all starts working for e1000.

Cheers,

Auke
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html