Bug 113035

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.