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:	Mon, 28 Jan 2008 20:07:06 -0500
From:	Andy Gospodarek <>
To:	Carlos Carvalho <>
Subject: Re: appearing again: kernel: eth0: too many iterations (6) in nv_nic_irq

On Mon, Jan 28, 2008 at 11:32:55AM -0200, Carlos Carvalho wrote:
> It seems that this problem with NVidia's nic comes up more and more...
> From time to time we get this in the log:
> Jan 27 14:43:12 duvel kernel: eth0: too many iterations (6) in nv_nic_irq.
> We algo get
> Jan 27 11:32:43 duvel kernel: KERNEL: assertion ((int)tcp_packets_in_flight(tp) >= 0) failed at net/ipv4/tcp_input.c (1274)
> But at different moments, as shown above. Are they related? What's the
> meaning of the "assertion failed" one?
> The messages are more likely to appear when traffic is high
> (>500Mb/s). This is with
> Any suggestions?

I've noticed that when running the latest forcedeth on an older base
kernel (2.6.18 in my case) that enable_irq and disable_irq don't quite
behave the same way with using MSI as they do with INTx.  2.6.24 works
great on the same hardware so something has changed between at leat
2.6.18 and now to make life better.  I've been meaning to look at those
calls and figure out if we can replace them with simple calls to disable
the hardware IRQs only, but haven't had a chance yet.

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