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  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, 21 Jun 2008 11:12:53 +0400
From:	Evgeniy Polyakov <>
To:	Travis Stratman <>
Subject: Re: data received but not detected

On Fri, Jun 20, 2008 at 04:06:12PM -0500, Travis Stratman ( wrote:
> This is what I have been focusing on. I'm still trying to figure out a
> good way to see if the interrupt is triggered for a specific packet
> because I have no way of determining which packet it will freeze on and
> if I put any prints in the interrupt handler or poll function it slows
> things down enough that the problem disappears.

It may or may not be the driver issue, but the way it works with NAPI.
Or driver just looses interrupt (or if it has weird interrupt
coalescing/mitigation feature) under the load. What about adding a
counter into interrupt handler and napi polling callback with ability to
clear/read it via driver ioctl (or just clear it when first small packet
is recived and dump when module is unloaded), so can determine via
tcpdump how many packets were actually received and what counter is.
It can be trivial issue with work_done < or <= than budget, which was a
frequent error in drivers for a while, and with your protocol it can be
fatal until next received packet.

	Evgeniy Polyakov
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to
More majordomo info at

Powered by blists - more mailing lists