Hi Ben,

Benjamin Li wrote:

Hi Bruno,

No problems.  Thanks for following up with this problem, I really
appreciate all your help.

quoted

From your logs it looks like the device came up using MSI, but in the

MSI-X poll routine was being called:

[    9.836673] bnx2: eth0: using MSI
...

[  134.643459]  [<ffffffffa004019e>] bnx2_poll_msix+0x3e/0xd0 [bnx2]
[  134.643465]  [<ffffffff8135bcd1>] netpoll_poll+0xe1/0x3c0

which is incorrect.  If we are in MSI mode, the bnx2_poll() routine
should be used.

I think what is going on here is that during the bnx2x driver
initialization the current bnx2 driver adds all possible NAPI structures
that map to all the hardware vectors (BNX2_MAX_MSIX_VEC=9) to the NAPI
list in the net_device structure regardless if they are used or not
(Seen in drivers/net/bnx2.c:bnx2_init_napi()).  This can cause
uninitialized NAPI structures to be placed on the napi_list.  Because
this device is in MSI mode, only 1 vector is initialized.   Now, the
problem is triggered when net/core/netpoll.c:poll_napi() is called.
This is because this routine will run through the entire napi_list
calling all the poll routines.  In your particular case, it is calling
the poll routine on an uninitialized vector causing the kernel panic.

...

Would this same change need to be made in other places, like bnx2_init_chip()
or bnx2_clear_ring_states() ?

-Brian