Here is a patch that helps. It's still an RFC of course, since its somewhat ugly :) I am now able to have 8 receivers on my 8 cpus machine, with one multicast packet every 10 us, without any loss. (standard setup, no affinity games) oprofile results see that scheduler overhead vanished, we get back to pure network profile :) (First offender being __copy_skb_header because of the atomic_inc on dst refcount) CPU: Core 2, speed 3000.43 MHz (estimated) Counted CPU_CLK_UNHALTED events (Clock ...

Feel free to add Acked-by or Tested-by: Kyle McMartin <kyle@mcmartin.ca>, it doesn't cause any regressions on any of my tulip cards. regards, Kyle --

So Yinghai has now written a driver fix and a generic code fix as well and both are being rejected pointing to the other side? This really sucks for users (who'd be happy with any of the patches) and the disagreement needs to be resolved ASAP. Ingo --

This is not enough, because the PM code doesn't change system_state and This breaks suspend/hibernation, doesn't it? Surely, we want to put devices into D3 when going for suspend, for example. I don't like this at all, sorry. I thought we were supposed to avoid using system_state in such a way, apart from the other things. Thanks, Rafael --

Please note that i havent reviewed the patches and i did not take any sides in the discussion - i just flagged the maintainer ping-pong. As long as we pick one of the patches (or a third one) within a bound amount of time we should be fine :) Ingo --

And, quite frankly, I'm not sure if users will be happy with the $subject patch, because it _really_ breaks things (well, the kexec users who don't use suspend might be, but surely suspend users who don't use kexec won't). Thanks, Rafael --

Agreed, but pci_set_power_state() may be called for too many different reasons to be a suitable place for a fix IMO. Thanks, Rafael --

Yes, because we've already decided we'd put the device into D3_hot by calling pci_enable_wake(pdev, PCI_D3hot, 1) in __igb_shutdown(). In fact we should first determine the target state and _then_ call pci_enable_wake() and pci_set_power_state() with that as the argument, but this is a separate issue. For now, IMO, it's better to use D3_hot in both places directly. On a slightly related note, the sequence pci_enable_wake(pdev, PCI_D3hot, 1); ...

tip/master also RHEL 5.3 with igb + kexec have the same problem. YH --

I hope you read my other comment (that you deleted from the reply)? If we're going to fix this at the core level along the Yinghai's patch lines, we'll have to introduce a few additional values for system_state and make suspend and hibernation code use them. Do you think it's worth the effort, given that only a couple of drivers have been found to be affected so far? Rafael --

In which case you need to rework igb_shutdown() rather than igb_suspend(). Something like the patch below, perhaps (totally untested). Thanks, Rafael --- drivers/net/igb/igb_main.c | 24 +++++++++++++++++++----- 1 file changed, 19 insertions(+), 5 deletions(-) Index: linux-2.6/drivers/net/igb/igb_main.c =================================================================== --- linux-2.6.orig/drivers/net/igb/igb_main.c +++ linux-2.6/drivers/net/igb/igb_main.c @@ -4299,7 +4299,7 @@ ...

On Sun, 08 Mar 2009 01:55:06 +0100 from the ioctl manpage: ERRORS [snip] ENOTTY The specified request does not apply to the kind of object that the descriptor d references. -- Arjan van de Ven Intel Open Source Technology Centre For development, discussion and tips for power savings, visit http://www.lesswatts.org --

Not at all. ENODEV means "no such device", which would be quite wrong. The device does exist and is in all probability working perfectly fine. There's precedent for using ENOSYS for that case, for example in drivers/char/vt_ioctl.c. But I'm open for other suggestions. Thanks, Tilman --=20 Tilman Schmidt E-Mail: tilman@imap.cc Bonn, Germany Diese Nachricht besteht zu 100% aus wiederverwerteten Bits. Unge=F6ffnet mindestens haltbar bis: (siehe R=FCckseite)

Interesting, though slightly surprising proposition. "Not a typewriter" is certainly correct. :-) "Not a tty device", however, which I take is the customary interpretation, much less clearly so. The device most certainly is a tty device. It just happens to know a few additional ioctl commands which may or may not be implemented, depending on the kernel config. Not to question your authority, but I would really like a second opinion on that issue before I adopt your proposition, simply ...

Sorry my mistake, discard It should be echo "filter add dev $2 parent ffff: protocol ip prio 10 u32 \ match u32 0 0 flowid 1:1 \ action skbedit priority 0x${lowid} pipe \ action mirred egress redirect dev ifb0" (i forgot pipe) ipt use another way of defining action (depends on return value of iptables). --

Hi again I test again HTB and HFSC, this time in very simple case. Regarding HTB - i try without quantum, with different values, without and with cburst (big and small), with HZ=1000 and default, hysteresis on and off - it is almost same result. While i set limit at 57, it can reach 61. HFSC results is perfect. Here is graph snapshopts. http://www.nuclearcat.com/netdev/htb-problem.png You can see points where HTB enabled. Other points if HFSC. Scripts source is: HTB ...