Latest working kernel version: Earliest failing kernel version: Distribution:Ubuntu Gutsy and Hardy Hardware Environment:DFE-538TX 10/100 Ethernet Adapter RTL8139 Ethernet Software Environment: Problem Description: Steps to reproduce: 1. Shutdown machine 2. Unplug network wire 3. Restart machine 4. Wait for complete boot and login 5. Plug the network wire ** 6. Run pppoe-discovery, pppoe-start 7. Cannot discovery any access concentrators / servers 8. Shutdown 9. Keep the network wire plugged 10. Start machine and boot 11. Wait for complete boot and login 12. Run pppoe-discovery, pppoe-start - Works this time ! The network wire has to be kept connected during boot to use the pppoe-discovery command. If the network wire is plugged in later - the network/pppoe fails to work.
Reply-To: akpm@linux-foundation.org (switched to email. Please respond via emailed reply-to-all, not via the bugzilla web interface). On Sat, 17 May 2008 21:56:36 -0700 (PDT) bugme-daemon@bugzilla.kernel.org wrote: > http://bugzilla.kernel.org/show_bug.cgi?id=10739 > > Summary: PPPoE not working, if ethernet wire not plugged during > boot > Product: Networking > Version: 2.5 > KernelVersion: 2.6.22-14-generic > Platform: All > OS/Version: Linux > Tree: Mainline > Status: NEW > Severity: high > Priority: P1 > Component: Other > AssignedTo: acme@ghostprotocols.net > ReportedBy: for.dev.null@gmail.com > > > Latest working kernel version: > > Earliest failing kernel version: > > Distribution:Ubuntu Gutsy and Hardy > > Hardware Environment:DFE-538TX 10/100 Ethernet Adapter > RTL8139 Ethernet > > > Software Environment: > Problem Description: > > Steps to reproduce: > 1. Shutdown machine > 2. Unplug network wire > 3. Restart machine > 4. Wait for complete boot and login > 5. Plug the network wire ** > 6. Run pppoe-discovery, pppoe-start > 7. Cannot discovery any access concentrators / servers > 8. Shutdown > 9. Keep the network wire plugged > 10. Start machine and boot > 11. Wait for complete boot and login > 12. Run pppoe-discovery, pppoe-start - Works this time ! > > The network wire has to be kept connected during boot to use the > pppoe-discovery command. If the network wire is plugged in later - the > network/pppoe fails to work. 2.6.22 is awfully old in terms of kernel.org development. Are you able to determine whether more recent kernels have the same problem? This could be dependent upon the devidce driver which is in use. Please provide details about the physical layer?
what does ifconfig eth0, mii-tool eth0 or ethtool eth0 tell about the interface when pppe-discovery fails and when it works ? do you see a difference? i assume this isn`t a PPPoE problem at all.
I have set it to static ip so ifconfig and mii-tool works. I also assume this is not a PPPoE problem since this only occurs only when the network wire is not attached during boot. If I attach the network wire later and restart networking via /etc/init.d/networking restart and also did a ifconfig eth0 down/up it still fails to detect any server on the net iptable -L all empty (no firewall)
the question was what it shows, not if it works ;) do you see any difference in the output of ethool/mii-tool ?
Created attachment 16202 [details] dmesg output last 500 lines
tried it on ubuntu hardy xxxxx@xubuntu:~$ sudo ifconfig eth0 eth0 Link encap:Ethernet HWaddr 00:05:5d:42:52:da inet addr:169.24.xx.xx Bcast:169.24.255.255 Mask:255.255.0.0 UP BROADCAST MULTICAST MTU:1500 Metric:1 RX packets:940 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:69581 (67.9 KB) TX bytes:0 (0.0 B) Interrupt:17 Base address:0xb800 xxxxx@xubuntu:~$ sudo mii-tool eth0 eth0: 10 Mbit, half duplex, link ok xxxxxx@xubuntu:~$ sudo pppoe-discovery Timeout waiting for PADO packets xxxxxx@xubuntu:~$ sudo uname -r 2.6.24-16-generic I need to use the 10 mbps half duplex setting on my network. ls mod : Module Size Used by af_packet 23812 0 ppp_synctty 11264 0 ppp_async 13312 0 crc_ccitt 3072 1 ppp_async ppp_generic 29588 2 ppp_synctty,ppp_async slhc 7040 1 ppp_generic rfcomm 41744 2 l2cap 25728 13 rfcomm bluetooth 61156 4 rfcomm,l2cap ppdev 10372 0 cpufreq_stats 7104 0 cpufreq_userspace 5284 0 cpufreq_ondemand 9740 0 freq_table 5536 2 cpufreq_stats,cpufreq_ondemand cpufreq_powersave 2688 0 cpufreq_conservative 8712 0 sbs 15112 0 container 5632 0 sbshc 7680 1 sbs dock 11280 0 video 19856 0 output 4736 1 video battery 14212 0 iptable_filter 3840 0 ip_tables 14820 1 iptable_filter x_tables 16132 1 ip_tables ac 6916 0 lp 12324 0 snd_intel8x0 35356 1 snd_ac97_codec 101028 1 snd_intel8x0 ac97_bus 3072 1 snd_ac97_codec snd_pcm_oss 42144 0 snd_mixer_oss 17920 1 snd_pcm_oss snd_pcm 78596 3 snd_intel8x0,snd_ac97_codec,snd_pcm_oss snd_seq_dummy 4868 0 ipv6 267780 8 snd_seq_oss 35584 0 snd_seq_midi 9376 0 snd_rawmidi 25760 1 snd_seq_midi snd_seq_midi_event 8320 2 snd_seq_oss,snd_seq_midi snd_seq 54224 6 snd_seq_dummy,snd_seq_oss,snd_seq_midi,snd_seq_midi_event snd_timer 24836 2 snd_pcm,snd_seq snd_seq_device 9612 5 snd_seq_dummy,snd_seq_oss,snd_seq_midi,snd_rawmidi,snd_seq snd 56996 13 snd_intel8x0,snd_ac97_codec,snd_pcm_oss,snd_mixer_oss,snd_pcm,snd_seq_dummy,snd_seq_oss,snd_rawmidi,snd_seq,snd_timer,snd_seq_device analog 13600 0 serio_raw 7940 0 gameport 16008 1 analog psmouse 40336 0 evdev 13056 3 button 9232 0 parport_pc 36260 1 parport 37832 3 ppdev,lp,parport_pc soundcore 8800 1 snd snd_page_alloc 11400 2 snd_intel8x0,snd_pcm nvidia_agp 9628 1 agpgart 34760 1 nvidia_agp i2c_amd756 7428 0 shpchp 34452 0 pci_hotplug 30880 1 shpchp i2c_core 24832 1 i2c_amd756 pcspkr 4224 0 ext3 136712 1 jbd 48404 1 ext3 mbcache 9600 1 ext3 sg 36880 0 sr_mod 17956 0 cdrom 37408 1 sr_mod sd_mod 30720 3 ata_generic 8324 0 pata_amd 14212 2 pata_acpi 8320 0 8139too 27520 0 mii 6400 1 8139too libata 159344 3 ata_generic,pata_amd,pata_acpi scsi_mod 151436 4 sg,sr_mod,sd_mod,libata ohci_hcd 25348 0 usbcore 146028 2 ohci_hcd thermal 16796 0 processor 36872 1 thermal fan 5636 0 fbcon 42912 0 tileblit 3456 1 fbcon font 9472 1 fbcon bitblit 6784 1 fbcon softcursor 3072 1 bitblit fuse 50580 1 I also have attached the dmesg output as attachment.
>xxxxx@xubuntu:~$ sudo mii-tool eth0 >eth0: 10 Mbit, half duplex, link ok >xxxxxx@xubuntu:~$ sudo pppoe-discovery >Timeout waiting for PADO packets any difference for the working case ?
xxxxxx@ubuntudesk:~$ sudo mii-tool eth0 eth0: 10 Mbit, half duplex, link ok xxxxxxx@ubuntudesk:~$ sudo pppoe-discovery Access-Concentrator: worldnet002 Service-Name: worldnet002 Got a cookie: 08 72 76 57 96 10 30 9c b7 6e 60 50 bb 67 51 e3 ea 0c 00 00 -------------------------------------------------- AC-Ethernet-Address: 00:07:e9:0b:57:0e Access-Concentrator: MikroTik Service-Name: Blaze-World.net -------------------------------------------------- AC-Ethernet-Address: 00:08:a1:67:73:d3 Access-Concentrator: Zone.net Service-Name: Zone.Net -------------------------------------------------- AC-Ethernet-Address: 00:07:e9:0b:56:c8 Access-Concentrator: BBPaceworldnet Service-Name: BBPaceworldnet Got a cookie: 06 95 cc 7b 7d a9 c6 45 28 c7 74 c0 0a 1d c3 94 f0 03 00 00 -------------------------------------------------- AC-Ethernet-Address: 00:0d:88:45:bf:11 xxxxxxx@ubuntudesk:~$
I can't see pppoe on this lsmod above - did you try to "modprobe pppoe" before discovery?
I checked the lsmod in the working connection. There is no module named "ppp" or "pppoe" listed.
lsmod (working pppoe) Module Size Used by bsd_comp 6912 1 af_packet 23812 4 ppp_synctty 11264 0 ppp_async 13312 1 crc_ccitt 3072 1 ppp_async ppp_generic 29588 7 bsd_comp,ppp_synctty,ppp_async slhc 7040 1 ppp_generic rfcomm 41744 2 l2cap 25728 13 rfcomm bluetooth 61156 4 rfcomm,l2cap ppdev 10372 0 cpufreq_stats 7104 0 cpufreq_userspace 5284 0 cpufreq_ondemand 9740 0 freq_table 5536 2 cpufreq_stats,cpufreq_ondemand cpufreq_powersave 2688 0 cpufreq_conservative 8712 0 sbs 15112 0 container 5632 0 sbshc 7680 1 sbs dock 11280 0 video 19856 0 output 4736 1 video battery 14212 0 iptable_filter 3840 0 ip_tables 14820 1 iptable_filter x_tables 16132 1 ip_tables ac 6916 0 lp 12324 0 ipv6 267780 18 snd_intel8x0 35356 1 snd_ac97_codec 101028 1 snd_intel8x0 ac97_bus 3072 1 snd_ac97_codec snd_pcm_oss 42144 0 snd_mixer_oss 17920 1 snd_pcm_oss snd_pcm 78596 3 snd_intel8x0,snd_ac97_codec,snd_pcm_oss evdev 13056 3 serio_raw 7940 0 snd_seq_dummy 4868 0 analog 13600 0 gameport 16008 1 analog snd_seq_oss 35584 0 snd_seq_midi 9376 0 snd_rawmidi 25760 1 snd_seq_midi snd_seq_midi_event 8320 2 snd_seq_oss,snd_seq_midi snd_seq 54224 6 snd_seq_dummy,snd_seq_oss,snd_seq_midi,snd_seq_midi_event snd_timer 24836 2 snd_pcm,snd_seq snd_seq_device 9612 5 snd_seq_dummy,snd_seq_oss,snd_seq_midi,snd_rawmidi,snd_seq button 9232 0 snd 56996 13 snd_intel8x0,snd_ac97_codec,snd_pcm_oss,snd_mixer_oss,snd_pcm,snd_seq_dummy,snd_seq_oss,snd_rawmidi,snd_seq,snd_timer,snd_seq_device soundcore 8800 1 snd snd_page_alloc 11400 2 snd_intel8x0,snd_pcm parport_pc 36260 1 parport 37832 3 ppdev,lp,parport_pc nvidia_agp 9628 1 agpgart 34760 1 nvidia_agp shpchp 34452 0 i2c_amd756 7428 0 pci_hotplug 30880 1 shpchp i2c_core 24832 1 i2c_amd756 psmouse 40336 0 pcspkr 4224 0 ext3 136712 1 jbd 48404 1 ext3 mbcache 9600 1 ext3 sg 36880 0 sr_mod 17956 0 cdrom 37408 1 sr_mod sd_mod 30720 3 ata_generic 8324 0 pata_amd 14212 2 pata_acpi 8320 0 8139too 27520 0 mii 6400 1 8139too libata 159344 3 ata_generic,pata_amd,pata_acpi scsi_mod 151436 4 sg,sr_mod,sd_mod,libata ohci_hcd 25348 0 usbcore 146028 2 ohci_hcd thermal 16796 0 processor 36872 1 thermal fan 5636 0 fbcon 42912 0 tileblit 3456 1 fbcon font 9472 1 fbcon bitblit 6784 1 fbcon softcursor 3072 1 bitblit fuse 50580 1 Ony module extra is bsd_comp..i will check loading that manually and report back.
tried with loading the bsd_comp module. nothing happened. still the same problem...
> ------- Comment #12 from for.dev.null@gmail.com 2008-05-21 08:56 ------- > tried with loading the bsd_comp module. nothing happened. > > still the same problem... Hmm... It looks like this wasn't my brightest advice and this pppoe module shouldn't matter here. It seems more important is the state (and history) of your eth0: your ifconfig shows some ip address here, but man pppoe and pppoe-discovery mention there should be no ip address. Are you sure in the working case your ifconfig eth0 looks the same before running this pppoe-discovery?
>Are you sure in the working case your ifconfig eth0 looks the same before >running > this pppoe-discovery? Yes its the same. There are no changes to anything. Only difference is the ethernet wire is not plugged in while boot. > your ifconfig shows some ip address here, but man pppoe and pppoe-discovery > mention there should be no ip address. sorry i didn't exactly get your point. i assume you meant that there should be no ip address for pppoe. that is correct. pppoe has no ip address. ip address is needed to be able to access the lan for ethernet card. ip address of ethernet is different for ip address of pppoe $sudo pppoe-status ppoe-status: Link is up and running on interface ppp0 ppp0 Link encap:Point-to-Point Protocol inet addr:xxx.xxx.xxx.xxx P-t-P:xxx.xxx.xxx.xxx Mask:255.255.255.255 UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1492 Metric:1 RX packets:6428 errors:0 dropped:0 overruns:0 frame:0 TX packets:7231 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:3 RX bytes:5452869 (5.2 MB) TX bytes:1220019 (1.1 MB) no one is using pppoe who can confirm this bug...
so - did i get this correct - if you boot without network, plug in the cable later and set an ip to eth0, can you ping & connect other hosts on the network then ? if it doesn`t work, can you start tcpdump on that interface and ping from another host to see if any packets reach the interface ? if that works, then indeed i would expect it to be a pppoe problem. if you don`t have any communication at all, it must be a problem of the nic/driver.
> ------- Comment #14 from for.dev.null@gmail.com 2008-05-22 03:42 ------- > sorry i didn't exactly get your point. i assume you meant that there should > be > no ip address for pppoe. that is correct. pppoe has no ip address. ip address > is needed to be able to access the lan for ethernet card. ip address of > ethernet is different for ip address of pppoe No, I mean exactly what man pppoe-discovery reads: "-I interface The -I option specifies the Ethernet interface to use. Under Linux, it is typically eth0 or eth1. The interface should be "up" before you start pppoe-discovery, but should not be con- figured to have an IP address. The default interface is eth0." You didn't use "-I", so I assume your eth0 was probed, but you can try explicitly too. > $sudo pppoe-status > > ppoe-status: Link is up and running on interface ppp0 > ppp0 Link encap:Point-to-Point Protocol .... Does this work for you?: sudo pppoe-discovery -I ppp0
On Thu, May 22, 2008 at 06:09:39PM +0200, Jarek Poplawski wrote: ... > No, I mean exactly what man pppoe-discovery reads: ... Dev Null, I'm not sure my point was clear here: I admit the possibility of some bug here, but IMHO this should be checked according to some rules (like this man). Alas I can't test this case, so it would be nice if you could confirm that when you plug the wire after booting, do "ifconfig eth0 up" (there is no ip at the moment and no packets in eth0 statistics, which could mean some script has disturbed) this pppoe-discovery still doesn't work. Otherwise, this would rather look like a config error. Regards, Jarek P.
Created attachment 16274 [details] EtherApe - Network alive in problem case This is to show the network as working in the problem case
I have installed debian (ubuntu can get buggy) debianpc:~# ifconfig eth0 eth0 Link encap:Ethernet HWaddr 00:05:5D:42:52:DA inet addr:169.24.99.189 Bcast:169.24.255.255 Mask:255.255.0.0 UP BROADCAST MULTICAST MTU:1500 Metric:1 RX packets:216 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:20253 (19.7 KiB) TX bytes:0 (0.0 b) Interrupt:185 Base address:0xb800 The TX bytes is showing zero activity but the RX is working. I used EtherApe to sniff on network activity. As with screenshot the network was alive. I then tried to ping a few PCs but couldnt do so. So ping was not working. I tried stopping and starting network, etc. But nothing worked. debianpc:~# pppoe-discovery -I ppp0 ioctl(SIOCGIFHWADDR): No such device Strange. I rebooted with the network card attached and then I was able to ping the same Pcs. Now if I run the above command again I get debianpc:~# pppoe-discovery -I ppp0 Interface ppp0 is not Ethernet Very strange....
This is in the working case : eth0 Link encap:Ethernet HWaddr 00:05:5D:42:52:DA inet addr:169.24.99.189 Bcast:169.24.255.255 Mask:255.255.0.0 inet6 addr: fe80::205:5dff:fe42:52da/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:1053 errors:0 dropped:0 overruns:0 frame:0 TX packets:433 errors:0 dropped:0 overruns:0 carrier:0 collisions:43 txqueuelen:1000 RX bytes:336417 (328.5 KiB) TX bytes:126976 (124.0 KiB) Interrupt:185 Base address:0xb800 So no TX is happening in the problem case. Any idea whats going on. What it has to do with the network wire.
the working case has an ipv6 adress assigned, but i think this shouldn`t matter. looks like an issue with 8139too driver to me. any chance to try a recent kernel like 2.6.25 or 2.6.26rc - just to see if it makes a difference ? you may try a live-cd like opensuse 11 beta3 - see http://software.opensuse.org/developer that comes with 2.6.25 kernel
> ------- Comment #19 from for.dev.null@gmail.com 2008-05-25 07:28 ------- > I have installed debian (ubuntu can get buggy) > > debianpc:~# ifconfig eth0 > eth0 Link encap:Ethernet HWaddr 00:05:5D:42:52:DA > inet addr:169.24.99.189 Bcast:169.24.255.255 Mask:255.255.0.0 > UP BROADCAST MULTICAST MTU:1500 Metric:1 ... > I tried stopping and starting network, etc. But nothing worked. The main question (and I don't know why I didn't see it earlier) is: why there is no RUNNING flag here? It looks like carrier state isn't updated for some reason after plugging the wire. Could you try if e.g. reloading a driver (ifconfig eth0 down, modprobe -r 8139too, and modprobe 8139too, ifconfig eth0 up) helps? You could also try mii-tool or ethtool to get/reset/test current settings. ... > debianpc:~# pppoe-discovery -I ppp0 > Interface ppp0 is not Ethernet > > Very strange.... I think pppoe-discovery isn't supposed to work with ppp0 yet... If you manage to get eth0 "up" and "running" try: pppoe-discovery -I eth0
success ! after doing the modprobe as suggested it started working ! eth0 Link encap:Ethernet HWaddr 00:05:5D:42:52:DA inet addr:xxx.xx.xxx.xxx Bcast:169.24.255.255 Mask:255.255.0.0 inet6 addr: fe80::205:5dff:fe42:52da/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:239 errors:0 dropped:0 overruns:0 frame:0 TX packets:106 errors:0 dropped:0 overruns:0 carrier:0 collisions:6 txqueuelen:1000 RX bytes:89971 (87.8 KiB) TX bytes:10182 (9.9 KiB) Interrupt:185 Base address:0xb800 Is this is bug and where to file it ? Does it happen with every network card or just this one ? How do I get this fixed ? Thanks a lot !!
Hi, I forward this subject to netdev list. IMHO modprobe shouldn't be needed to get this driver RUNNING after plugging the wire. (I've tried a similar card with 2.6.24 kernel and ifconfig eth0 up was enough). If there is no good advice I think it would be better to close the current report and reopen it with better title. Regards, Jarek P. On 18-05-2008 07:10, Andrew Morton wrote: > (switched to email. Please respond via emailed reply-to-all, not via the > bugzilla web interface). > > On Sat, 17 May 2008 21:56:36 -0700 (PDT) bugme-daemon@bugzilla.kernel.org > wrote: > >> http://bugzilla.kernel.org/show_bug.cgi?id=10739 >> >> Summary: PPPoE not working, if ethernet wire not plugged during >> boot >> Product: Networking ... On Tue, May 27, 2008 at 12:16:35AM -0700, bugme-daemon@bugzilla.kernel.org wrote: > http://bugzilla.kernel.org/show_bug.cgi?id=10739 > > > > > > ------- Comment #23 from for.dev.null@gmail.com 2008-05-27 00:16 ------- > success ! after doing the modprobe as suggested it started working ! > > eth0 Link encap:Ethernet HWaddr 00:05:5D:42:52:DA > inet addr:xxx.xx.xxx.xxx Bcast:169.24.255.255 Mask:255.255.0.0 > inet6 addr: fe80::205:5dff:fe42:52da/64 Scope:Link > UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 > RX packets:239 errors:0 dropped:0 overruns:0 frame:0 > TX packets:106 errors:0 dropped:0 overruns:0 carrier:0 > collisions:6 txqueuelen:1000 > RX bytes:89971 (87.8 KiB) TX bytes:10182 (9.9 KiB) > Interrupt:185 Base address:0xb800 > > Is this is bug and where to file it ? Does it happen with every network card > or > just this one ? How do I get this fixed ? > > Thanks a lot !! > > > -- > Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email > ------- You are receiving this mail because: ------- > You are on the CC list for the bug, or are watching someone who is.
I tried doing only ifconfig eth0 up. But it didnt work. I will try with the new kernel and post back the results.
> ------- Comment #25 from for.dev.null@gmail.com 2008-05-27 04:11 ------- > I tried doing only ifconfig eth0 up. But it didnt work. Yes, I think, you wrote before ifconfig eth0 down/up didn't work. > > I will try with the new kernel and post back the results. > BTW, I've just re-checked this with my 8139too card (2.6.24) and it looks like it has no such problems: if it's UP the state is changed automatically after plugging/unplugging, and shown by ifconfig; if it's down at the moment, "ifconfig eth0 up" is enough.
Shouldnt the interface be bought up automaticaly ? Why does it need to be done manually ?? BTW I still havent checked the latest kernel (will do it soon)
> ------- Comment #27 from for.dev.null@gmail.com 2008-05-30 21:25 ------- > Shouldnt the interface be bought up automaticaly ? Why does it need to be > done > manually ?? BTW I still havent checked the latest kernel (will do it soon) It depends on your config: usually some script brings an interface up if it's configured, so after plugging a wire later the RUNNING flag should be set automatically. On the other hand, probably some scripts or daemons could mess arround too. Anyway, reloading the driver shouldn't be necessary here. I think, you could check both newer and maybe some older kernel as well. I'd suggest to try this in kernel "single" mode (1 in starting parameters) to exclude some daemons, plugging the wire while starting, and if it's UP and RUNNING try to unplug and replug. Check this with ifconfig and "dmesg | tail" (for link messages). You could also try to get some additional info/testing with ethtool.
I tried doing the same thing on another machine which has a integrated lan card. t seems to work on that properly (no need of even bringing the interface up). This machine has a PCI LAN card. Maybe it doesnot work on that. I will do more test as time permits.
I have checked the same behaviour on few machines. The problem seems to be only with the PCI lan cards. This does not happen with onchip lan cards. Any hope of getting this fixed ?
> ------- Comment #30 from for.dev.null@gmail.com 2008-06-15 23:39 ------- > I have checked the same behaviour on few machines. The problem seems to be > only > with the PCI lan cards. This does not happen with onchip lan cards. Any hope > of > getting this fixed ? I guess so, but I would recommend: - to close this and start a new bugzilla report with more proper title, and drivers as "product" (mentioning current report), - to add some debugging like mentioned in the 8139too.c comment: "Submitting bug reports:", - maybe try to recompile this driver with changed additional 8139TOO config options. (BTW, my tests were done with a PCI card, so it's not something general.)