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

From the further brainstorming department... It appears we are using the wait for the completion for two distinct purposes. Waiting until it is safe to free storage. Blocking module unregistration until the all of the users of the code are gone. I'm wondering if we could move the memory freeing. And consolidate the waiting ultimately moving the wait for completion into netdev_run_todo after we drop the lock. The reason I care is that it looks like to get hotplug handling sane, ...

Impact: second kernel by kexec will have some pci devices working Found one system with 82575EB, in the kernel that is kexeced, probe igb failed with -2. it looks like the same behavior happened on forcedeth. try to check system_state to make sure if put it on D3 Jesse Brandeburg said that we should do that check in core code instead of every device driver. Signed-off-by: Yinghai Lu <yinghai@kernel.org> --- drivers/pci/pci.c | 17 +++++++++++++++++ 1 file changed, 17 ...

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

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

In fact pci_enable_device() calls pci_set_power_state(dev, PCI_D0) as the first thing. The question is why it doesn't work as expected. What kernel(s) have you tested? Thanks, Rafael --

Ok, I'm convinced. I'll redo the patch with ENOTTY instead of ENOSYS. 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)

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

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

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

Thanks, I remember now. This appears to be quirky hardware, doesn't it? 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 @@ ...

you don't need to use pci_choose_state(pdev, state), but use PCI-D3hot directly? YH --

can you go through e1000, e1000e, ixgb, ixgbe too? YH --