The following has be reported by IBM LTC: [netperf] 2.4: RedHat e1000 modules will not load without NAPI Hardware Environment: p630 4way 1 Intel Gigabit adapter Software Environment: RHEL3-GM and U1 beta Steps to Reproduce: 1.make menuconfig 2.unselect NAPI under the e1000 driver 3.compile the module and try to load it. Actual Results: It will complain about unresolve symbols. I found out that it is becuase there is an #ifdef for the poll controller and NAPI is a depencency for it but it does not seem to take care of this problem when you disable NAPI. Expected Results: e1000 loading without problems.Generic bug, the e1000 driver is not unique to ppc64. Over to Service for RedHat mirroring.Sachin - please have your team take a look at this before we contact Red Hat. You might want to contact Kent Yoder (here in Austin) for technical consultation. Thanks.Suresh can you please have a look at this bug for me. ThanksQuick googl'ing of similar problem gave me a hit to the following page: ( http://www.ussg.iu.edu/hypermail/linux/kernel/0301.1/0820.html ) Where the un-resolved symbols observed were _mmx_memcpy. And solution to the problem is "Make sure you build from distclean if you've built for other cpu options before. (cp .config ..; make distclean; cp ../.config .config; make oldconfig)". Can you please verify the problem faced is similar to the above problem and let us know if the unresolved symbols problem is resolved using the above procedure?. -SureshI followed your procedure but still I get the following: unresolved symbol .e1000_clean The reason why I get it is because when I disable NAPI, the following pieces of code still get compiled and NAPI declares the e1000_clean function that the HAVE_POLL_CONTROLLER #ifdef uses. Problem: #ifdef HAVE_POLL_CONTROLLER netdev->poll_controller = e1000_netpoll; #endif . . . #ifdef HAVE_POLL_CONTROLLER /* * Polling 'interrupt' - used by things like netconsole to send skbs * without having to re-enable interrupts. It's not called while * the interrupt routine is executing. */ static void e1000_netpoll (struct net_device *dev) { if (unlikely(netdump_mode)) { int bogus_budget = 64; /* netdev_max_backlog */ e1000_intr (dev->irq, dev, NULL); /* * Check to see if there is work to do. Only call the * clean routine if we put ourselves on the poll list. */ if (dev->poll_list.prev) e1000_clean (dev, &bogus_budget); <---- PROBLEM } else { disable_irq(dev->irq); e1000_intr (dev->irq, dev, NULL); enable_irq(dev->irq); } } #endif Shouldn't "#ifdef HAVE_POLL_CONTROLLER" include a check for "CONFIG_E1000_NAPI" because it is a dependency.code under HAVE_POLL_CONTROLLER ( and so e1000_netpoll ) has been introduced as a patch for 2.4.21-EL. I feel that before calling "e1000_clean", the check should have been performed for CONFIG_E1000_NAPI. SUSE seems to have different kind of implementation where if do not check for if (unlikely(netdump_mode)) { int bogus_budget = 64; /* netdev_max_backlog */ e1000_intr (dev->irq, dev, NULL); /* * Check to see if there is work to do. Only call the * clean routine if we put ourselves on the poll list. */ if (dev->poll_list.prev) e1000_clean (dev, &bogus_budget); } I will update with more details. -Suresh Created an attachment make modules_install will not complain about undefined sybmols Code, specific to CONFIG_E1000_NAPI has been kept under #ifdef, Thus would solve the problem of undefined symbols. -SureshCan you please let us know whether the test patch works fine with the e1000 driver. ThanksI just tried the change and now it works as expected. When is this change going to appear on a build?This needs to go into Update 1 if possible. Thanks.This bug did not make it into update 1 and now we need it in update 2. This fix is a must for update 2. Will check if this patch is in the latest RHEL distro as soon as possible.I just installed RHEL Q1 and checked for this patch and the patch did not make it into RHEL Q1. Please push it for update 2.
Created attachment 96806 [details] e1000_2.4.21-4.EL.patch
The patch is correct, but unacceptable: Red Hat does not support kernels compiled with options other than what we specify. This appears to be an attempt to avoid diagnosing why NAPI is slow on _one_ platform with _one_ NIC. Please investigate the real problem.
----- Additional Comments From ricardoz.com 2004-01-16 16:42 ------- RedHat will not take the patch because customers are not expected to recompile the driver.