broken PCNET32 in 2.6.24 requires experimental PCNET32_NAPI?

broken PCNET32 in 2.6.24 requires experimental PCNET32_NAPI?

[Erez Zadok]

I'm using Linus's git tree as of commit
d85714d81cc0408daddb68c10f7fd69eafe7c213.  I built that kernel under vmware
workstation 6.0.1 which emulates a pcnet32 nic.  When I only turn on
CONFIG_PCNET32, my network interface doesn't seem to come up fully: my dhcp
server sees a request, offers an IP addr, but the VM running 2.6.24 doesn't
pick up the response.  Manually configuring the eth0 and pinging yields
similar results: no replies come back.  The same VM has lots of other
kernels on it, all of which work fine (so it's not an iptables/selinux
problem, or the like).

If, however, I turn on the EXPERIMENTAL feature CONFIG_PCNET32_NAPI, then
the driver works again.  So, is this NAPI feature now a required one or did
the base driver somehow got broken?  I've not investigated this further.

Cheers,
Erez.

Re: broken PCNET32 in 2.6.24 requires experimental PCNET32_NAPI?

[Jeff Garzik]

Erez Zadok wrote:
> I'm using Linus's git tree as of commit
> d85714d81cc0408daddb68c10f7fd69eafe7c213.  I built that kernel under vmware
> workstation 6.0.1 which emulates a pcnet32 nic.  When I only turn on
> CONFIG_PCNET32, my network interface doesn't seem to come up fully: my dhcp
> server sees a request, offers an IP addr, but the VM running 2.6.24 doesn't
> pick up the response.  Manually configuring the eth0 and pinging yields
> similar results: no replies come back.  The same VM has lots of other
> kernels on it, all of which work fine (so it's not an iptables/selinux
> problem, or the like).
> 
> If, however, I turn on the EXPERIMENTAL feature CONFIG_PCNET32_NAPI, then
> the driver works again.  So, is this NAPI feature now a required one or did
> the base driver somehow got broken?  I've not investigated this further.

Fixes were posted by the maintainer, and pushed to Linus, yesterday...

	Jeff

Re: broken PCNET32 in 2.6.24 requires experimental PCNET32_NAPI?

[Erez Zadok]

In message <4717C90A.4060208@garzik.org>, Jeff Garzik writes:
> Erez Zadok wrote:
> > I'm using Linus's git tree as of commit
> > d85714d81cc0408daddb68c10f7fd69eafe7c213.  I built that kernel under vmware
> > workstation 6.0.1 which emulates a pcnet32 nic.  When I only turn on
> > CONFIG_PCNET32, my network interface doesn't seem to come up fully: my dhcp
> > server sees a request, offers an IP addr, but the VM running 2.6.24 doesn't
> > pick up the response.  Manually configuring the eth0 and pinging yields
> > similar results: no replies come back.  The same VM has lots of other
> > kernels on it, all of which work fine (so it's not an iptables/selinux
> > problem, or the like).
> > 
> > If, however, I turn on the EXPERIMENTAL feature CONFIG_PCNET32_NAPI, then
> > the driver works again.  So, is this NAPI feature now a required one or did
> > the base driver somehow got broken?  I've not investigated this further.
> 
> Fixes were posted by the maintainer, and pushed to Linus, yesterday...
> 
> 	Jeff

Thanks.  Now, with more patches that Linus committed, I get a different oops
when I try to configure the interface (ifup eth0).  I'm using:

CONFIG_PCNET32=m

And I tried with and without CONFIG_PCNET32_NAPI.

Cheers,
Erez.

------------------------------------------------------------------------------

pcnet32: PCnet/PCI II 79C970A at 0x1080, 00 0c 29 f0 e5 15 assigned IRQ 9.
eth0: registered as PCnet/PCI II 79C970A
pcnet32: 1 cards_found.
EXT3 FS on hda1, internal journal
Adding 522104k swap on /dev/hda2.  Priority:-1 extents:1 across:522104k
eth0: link up
BUG: unable to handle kernel NULL pointer dereference at virtual address
00000004
printing eip: c022f03d *pde = 00000000 
Oops: 0000 [#1] DEBUG_PAGEALLOC
Modules linked in: pcnet32
CPU:    0
EIP:    0060:[<c022f03d>]    Not tainted VLI
EFLAGS: 00010246   (2.6.23-unionfs2-2.6.24-rc0-pre #7)
EIP is at sk_filter_delayed_uncharge+0x1/0x22
eax: c1d21bf0   ebx: 00000000   ecx: c022f1a7   edx: 00000000
esi: c1ffdf70   edi: c1d21bf0   ebp: c3e13f04   esp: c3e13ed4
ds: 007b   es: 007b   fs: 0000  gs: 0033  ss: 0068
Process dhclient (pid: 1221, ti=c3e12000 task=c1edf5b0 task.ti=c3e12000)
Stack: c3e13f04 c022f1ff 00000002 00000001 c022f1a7 00000068 c1ffdf80
00000058 
       00000000 c1d21bf0 c3e13f2c c4435d90 c3e13f50 c021ea1b c17a08e0
c3d121c0 
       36947065 c3d8ae28 0000001a 0000000b 0000000b c1ff0800 0000000b
80070600 
Call Trace:
 [<c0102bc2>] show_trace_log_lvl+0x1a/0x2f
 [<c0102c72>] show_stack_log_lvl+0x9b/0xa3
 [<c0102e2e>] show_registers+0x1b4/0x285
 [<c0102fff>] die+0x100/0x21d
 [<c010a72f>] do_page_fault+0x434/0x515
 [<c026a40a>] error_code+0x6a/0x70
 [<c021ea1b>] sock_setsockopt+0x43f/0x494
 [<c021b994>] sys_setsockopt+0x4f/0x85
 [<c021ce0e>] sys_socketcall+0x1cb/0x222
 [<c0102586>] sysenter_past_esp+0x5f/0x91
 =======================
Code: 18 01 39 d0 7d 19 43 4e 39 d3 0f 8c 3d fe ff ff 0f b7 44 d1 f8 31 d2
83 e0 
07 83 f8 06 74 05 ba ea ff ff ff 5b 89 d0 5e 5d c3 55 <8b> 4a 04 89 e5 8d 0c
cd 1
0 00 00 00 29 88 b8 00 00 00 8d 42 08 
EIP: [<c022f03d>] sk_filter_delayed_uncharge+0x1/0x22 SS:ESP 0068:c3e13ed4

------------------------------------------------------------------------------

Re: broken PCNET32 in 2.6.24 requires experimental PCNET32_NAPI?

[David Miller]

From: Erez Zadok <ezk@cs.sunysb.edu>
Date: Fri, 19 Oct 2007 00:33:09 -0400

> Call Trace:
>  [<c0102bc2>] show_trace_log_lvl+0x1a/0x2f
>  [<c0102c72>] show_stack_log_lvl+0x9b/0xa3
>  [<c0102e2e>] show_registers+0x1b4/0x285
>  [<c0102fff>] die+0x100/0x21d
>  [<c010a72f>] do_page_fault+0x434/0x515
>  [<c026a40a>] error_code+0x6a/0x70
>  [<c021ea1b>] sock_setsockopt+0x43f/0x494
>  [<c021b994>] sys_setsockopt+0x4f/0x85
>  [<c021ce0e>] sys_socketcall+0x1cb/0x222
>  [<c0102586>] sysenter_past_esp+0x5f/0x91

This fix from Olof Johnson should fix it.

I'll merge this tonight.

diff --git a/net/core/filter.c b/net/core/filter.c
index 1f0068e..e0a0694 100644
--- a/net/core/filter.c
+++ b/net/core/filter.c
@@ -447,7 +447,8 @@ int sk_attach_filter(struct sock_fprog *fprog, struct sock *sk)
 	rcu_assign_pointer(sk->sk_filter, fp);
 	rcu_read_unlock_bh();
 
-	sk_filter_delayed_uncharge(sk, old_fp);
+	if (old_fp)
+		sk_filter_delayed_uncharge(sk, old_fp);
 	return 0;
 }