netdev - Re: [PATCH 0/1] NIU: fix spurious interrupts

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]

Message-ID: <4A132A0F.8070800@windriver.com>
Date:	Tue, 19 May 2009 17:52:15 -0400
From:	"Hong H. Pham" <hong.pham@...driver.com>
To:	David Miller <davem@...emloft.net>
CC:	netdev@...r.kernel.org, matheos.worku@....com
Subject: Re: [PATCH 0/1] NIU: fix spurious interrupts

David Miller wrote:
> Thanks for tracking down this problem, but I want to understand
> why this even happens.  As far as I can tell it shouldn't.
> 
> When we are done polling, the order of events is:
> 
> 1) unmask LDG interrupt(s)
> 2) napi_complete()
> 3) rearm LDG interrupt(s)
> 
> The interrupts should not be sent again until that rearm operation,
> which is after NAPI is completed.  So the condition you are hitting
> does not seem possible.

My thoughts exactly... this should not happen.

> Matheos, can the chip violate this?  If an RX event is reported
> in an LDG, it is masked, and then unmaked the interrupt should
> not appear until the LDG is also rearmed right?

Unfortunately I don't have a PCIe NIU card to test in an x86 box.  If
the hang does not happen on x86 (which is my suspicion), that would rule
out a problem with the NIU chip.  That would mean there's some
interaction between the NIU and sun4v hypervisor that's causing the
spurious interrupts.

Hong
--
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