When booting my IBM T23 Thinkpad and with the cable plugged in, eth0 comes up as expected. When unplugging the cable, netplug brings eth0 down as expected but plugging it back in does nothing--I have to run '/etc/init.d/net.eth0 restart' for the interface to come back up. Here is a partial log of a run where I unplugged the cable and plugged it back in. Unplug cable: Feb 11 15:29:02 corbie e100: eth0: e100_watchdog: link down Feb 11 15:29:02 corbie netplugd[31301]: eth0: state ACTIVE flags 0x00011063 UP,BROADCAST,NOTRAILERS,RUNNING,MULTICAST,10000 -> 0x00001023 UP,BROADCAST,NOTRAILERS,MULTICAST Feb 11 15:29:02 corbie netplugd[27159]: /etc/netplug.d/netplug eth0 out -> pid 27159 Feb 11 15:29:05 corbie rc-scripts: ERROR: net.eth0 is already stopping. Feb 11 15:29:09 corbie dhcpcd[31766]: terminating on signal 15 Feb 11 15:29:09 corbie netplugd[31301]: eth0: state OUTING flags 0x00001023 UP,BROADCAST,NOTRAILERS,MULTICAST -> 0x00001002 BROADCAST,MULTICAST Feb 11 15:29:10 corbie netplugd[31301]: eth0: state DOWNANDOUT pid 27159 exited status 0 Feb 11 15:29:10 corbie netplugd[27774]: /etc/netplug.d/netplug eth0 probe -> pid 27774 Feb 11 15:29:10 corbie netplugd[31301]: eth0: state PROBING pid 27774 exited status 0 Plug cable back in, run '/etc/init.d/net.eth0 restart': Feb 11 15:30:24 corbie netplugd[31301]: caught signal 15 - exiting Feb 11 15:30:26 corbie e100: eth0: e100_watchdog: link up, 100Mbps, full-duplex Feb 11 15:30:27 corbie netplugd[28688]: /etc/netplug.d/netplug eth0 in -> pid 28688 Feb 11 15:30:28 corbie rc-scripts: WARNING: net.eth0 has already been started. Feb 11 15:30:28 corbie netplugd[28687]: eth0: state INNING pid 28688 exited status 0 Feb 11 15:30:30 corbie dhcpcd[29154]: MAC address = 00:02:8a:30:d3:4b Feb 11 15:30:31 corbie dhcpcd[29154]: verified 192.168.0.25 address is not in use Feb 11 15:30:31 corbie dhcpcd[29154]: your IP address = 192.168.0.25 Now as far as I understand it, netplug should do its thing without any intervention on my part whatsoever. If that's not the case, feel free to close this bug with prejudice. :-) emerge --info: Portage 2.1.2_rc4-r6 (default-linux/x86/2006.1/desktop, gcc-4.1.1, glibc-2.4-r4, 2.6.19-gentoo-r3 i686) ================================================================= System uname: 2.6.19-gentoo-r3 i686 Mobile Intel(R) Pentium(R) III CPU - M 1200MHz Gentoo Base System version 1.12.5 Last Sync: Sat, 03 Feb 2007 07:30:01 +0000 dev-java/java-config: 1.3.7, 2.0.30 dev-lang/python: 2.4.3-r4 dev-python/pycrypto: 2.0.1-r5 sys-apps/sandbox: 1.2.18.1 sys-devel/autoconf: 2.13, 2.60 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2, 1.10 sys-devel/binutils: 2.17 sys-devel/gcc-config: 1.3.13-r4 sys-devel/libtool: 1.5.22 virtual/os-headers: 2.6.17-r2 ACCEPT_KEYWORDS="x86 ~x86" AUTOCLEAN="yes" CBUILD="i686-pc-linux-gnu" CFLAGS="-march=pentium3m -O2 -pipe" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/share/X11/xkb /usr/share/config" CONFIG_PROTECT_MASK="/etc/env.d /etc/env.d/java/ /etc/gconf /etc/java-config/vms/ /etc/revdep-rebuild /etc/terminfo /etc/texmf/web2c" CXXFLAGS="-march=pentium3m -O2 -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig distlocks metadata-transfer parallel-fetch sandbox sfperms strict" GENTOO_MIRRORS="http://distfiles.gentoo.org http://distro.ibiblio.org/pub/linux/distributions/gentoo" LANG="en_US.utf8" LDFLAGS="-Wl,--as-needed" LINGUAS="en" PKGDIR="/usr/portage/packages" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --delete-after --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="16bit 3ds 7zip X a52 aac aalib acpi alsa amr ao artworkextra asf audiofile bash-completion berkdb bitmap-fonts blender-game bzip2 cairo cdr cjk cli cpudetection cracklib crypt css cups curl dbus dga dlloader dmi dri dts dv dvd dvdr dvdread eds emboss emf encode expat fam fbcon ffmpeg fftw firefox flac fluidsynth fontconfig fortran gcj gd gdbm gif gpm graphviz gs gstreamer gtk gtk2 guile hal hbci iconv imagemagick imlib inkjar ipv6 isdnlog jack java javascript john jpeg kde ladspa lash lcms ldap libcaca libg++ logrotate lua lzo mad midi mikmod mjpeg mmap mmx mng modplug mp3 mp4 mpeg musepack ncurses nls nptl nptlonly nsplugin ofx ogg openal openexr opengl osc pam pcmcia pcre pdf perl plotutils plugin png ppds pppd python qt3 qt4 quicktime rar readline real reflection samba sdl session sndfile soundtouch sox speex spell spl sqlite sse sse-filters ssl subversion svg svga t1lib tcpd tga theora threads threadsonly tiff timidity tk truetype truetype-fonts type1-fonts udev unicode vcd vorbis wifi win32codecs wmf wordperfect x264 x86 xanim xine xml xorg xosd xpm xrandr xv xvid xvmc zip zlib" ALSA_CARDS="intel8x0" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mulaw multi null plug rate route share shm softvol" ELIBC="glibc" INPUT_DEVICES="evdev keyboard mouse" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LINGUAS="en" USERLAND="GNU" VIDEO_CARDS="savage" Unset: CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LC_ALL, MAKEOPTS, PORTAGE_RSYNC_EXTRA_OPTS lspci: 00:00.0 Host bridge: Intel Corporation 82830 830 Chipset Host Bridge (rev 04) 00:01.0 PCI bridge: Intel Corporation 82830 830 Chipset AGP Bridge (rev 04) 00:1d.0 USB Controller: Intel Corporation 82801CA/CAM USB (Hub #1) (rev 02) 00:1d.1 USB Controller: Intel Corporation 82801CA/CAM USB (Hub #2) (rev 02) 00:1d.2 USB Controller: Intel Corporation 82801CA/CAM USB (Hub #3) (rev 02) 00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev 42) 00:1f.0 ISA bridge: Intel Corporation 82801CAM ISA Bridge (LPC) (rev 02) 00:1f.1 IDE interface: Intel Corporation 82801CAM IDE U100 (rev 02) 00:1f.3 SMBus: Intel Corporation 82801CA/CAM SMBus Controller (rev 02) 00:1f.5 Multimedia audio controller: Intel Corporation 82801CA/CAM AC'97 Audio Controller (rev 02) 01:00.0 VGA compatible controller: S3 Inc. SuperSavage IX/C SDR (rev 05) 02:00.0 CardBus bridge: Texas Instruments PCI1420 02:00.1 CardBus bridge: Texas Instruments PCI1420 02:02.0 Communication controller: Agere Systems WinModem 56k (rev 01) 02:08.0 Ethernet controller: Intel Corporation 82801CAM (ICH3) PRO/100 VE (LOM) Ethernet Controller (rev 42) lspci -vv on the ethernet controller: 02:08.0 Ethernet controller: Intel Corporation 82801CAM (ICH3) PRO/100 VE (LOM) Ethernet Controller (rev 42) Subsystem: IBM ThinkPad A/T/X Series Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR+ FastB2B- Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- Latency: 66 (2000ns min, 14000ns max), Cache Line Size: 32 bytes Interrupt: pin A routed to IRQ 11 Region 0: Memory at c0200000 (32-bit, non-prefetchable) [size=4K] Region 1: I/O ports at 6400 [size=64] Capabilities: [dc] Power Management version 2 Flags: PMEClk- DSI+ D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold+) Status: D0 PME-Enable- DSel=0 DScale=2 PME-
Could you attach a log snippet where from where net.eth0 is first started by yourself and then unplug/replug the cable at 30 second intervals a few times without doing anything with net.eth0 by hand? Thanks
Here you go. I started the service, waited about 30 sec, then unplugged the cable, waited 30 sec, and then plugged it back in, waited 30 sec, unplugged and plugged back in with 30 sec waits in between. After unplugging it the first time, there was no log activity: Feb 27 21:51:00 corbie e100: eth0: e100_watchdog: link up, 100Mbps, full-duplex Feb 27 21:51:00 corbie netplugd[3809]: /etc/netplug.d/netplug eth0 in -> pid 3809 Feb 27 21:51:02 corbie dhcpcd[4251]: MAC address = 00:02:8a:30:d3:4b Feb 27 21:51:02 corbie dhcpcd[4251]: verified 192.168.0.25 address is not in use Feb 27 21:51:02 corbie dhcpcd[4251]: your IP address = 192.168.0.25 Feb 27 21:51:03 corbie netplugd[3808]: eth0: state INNING pid 3809 exited status 0 Feb 27 21:51:05 corbie nfs: server 192.168.0.9 OK Feb 27 21:51:34 corbie e100: eth0: e100_watchdog: link down Feb 27 21:51:34 corbie netplugd[3808]: eth0: state ACTIVE flags 0x00011063 UP,BROADCAST,NOTRAILERS,RUNNING,MULTICAST,10000 -> 0x00001023 UP,BROADCAST,NOTRAILERS,MULTICAST Feb 27 21:51:34 corbie netplugd[4291]: /etc/netplug.d/netplug eth0 out -> pid 4291 Feb 27 21:51:35 corbie dhcpcd[4253]: terminating on signal 15 Feb 27 21:51:35 corbie netplugd[3808]: eth0: state OUTING flags 0x00001023 UP,BROADCAST,NOTRAILERS,MULTICAST -> 0x00001002 BROADCAST,MULTICAST Feb 27 21:51:36 corbie netplugd[3808]: eth0: state DOWNANDOUT pid 4291 exited status 0 Feb 27 21:51:36 corbie netplugd[4728]: /etc/netplug.d/netplug eth0 probe -> pid 4728 Feb 27 21:51:36 corbie netplugd[3808]: eth0: state PROBING pid 4728 exited status 0 Feb 27 21:51:42 corbie nfs: server 192.168.0.9 not responding, still trying
OK, this is a driver bug. You should at least be seeing this in your logs when you plug the cable back in if the driver is fully working. e100: eth0: e100_watchdog: link up
Is this reproducible on gentoo-sources-2.6.20-r2 or newer?
The watchdog messages don't appear until I manually restart eth0. My internet link is tenuous at the moment; I will try the new kernel and report back.
OK, I'm running gentoo-sources-2.6.20-r3 and it catches the *first* insert, but ignores all subsequent inserts. So I can boot without eth0 and plug in and have eth0 come up automagically, but I have to restart eth0 if I unplug and replug in later. It's almost there. :-)
I forgot to add that it's catching the unplugging now, just not the plugging in. ;-)
Thanks. Any chance you can test the latest development kernel, currently 2.6.21-rc4, so that we can move to reporting this upstream?
I'm on a slow (28.8K) connection at the moment, and syncing my tree. Pulling a 40MB tarball is going to take some time. :-( Once I've gotten it in my machine I'll post a report. Thanks for your patience!
If you have a 2.6.20 tarball you can just apply this patch: http://www.kernel.org/pub/linux/kernel/v2.6/testing/patch-2.6.21-rc5.bz2
Please reopen when you are able to test the latest development kernel
OK, I've been able to test with a vanilla kernel (2.6.21-rc5) and it looks like we're back to square one. Unplugging gives a "e100: eth0: e100_watchdog: link down" message in the log without any intervention while getting the 'link up' message requires me to manually restart eth0.
With some additional testing, I seem to have found some consistency. As I mentioned, the 'link down' message comes all by itself but the 'link up' message requires a restart of net.eth0. Sometimes I have to unplug the cable when doing this and then plugging it back in results in eth0 coming up automagically. However, in every case a manual restart of net.eth0 is *required*. Now I'm not sure how all the components interact with each other, but it seems like one of the pieces is blocking the others. I guess the next step would be to determine if the driver itself is working properly, so I assume that the 'link up/down' messages should appear whether or not netplug is running? If so, I can test that and we can possibly rule that out as a problem.
I don't entirely understand your above comments. However, it would certainly be useful to rule netplug out. Kill all that stuff, run "ifconfig eth0" up, and plug/unplug the cable. Which events appear? Which events are missing?
OK, now we're getting somewhere. I apologize if I wasn't clear in my previous post, but at this point I don't think I need to clarify since the point is somewhat moot now: Without netplug running (just 'ifconfig eth0 up') I get the plug in *and* out messages. Partial log: May 3 10:53:07 corbie e100: eth0: e100_watchdog: link up, 100Mbps, full-duplex May 3 10:54:49 corbie e100: eth0: e100_watchdog: link down May 3 10:54:53 corbie e100: eth0: e100_watchdog: link up, 100Mbps, full-duplex May 3 10:54:57 corbie e100: eth0: e100_watchdog: link down May 3 10:55:01 corbie e100: eth0: e100_watchdog: link up, 100Mbps, full-duplex So this would seem to suggest that somehow netplug is screwing things up, since the driver appears to be working correctly. Let me know what else I can do to test this. I don't know if I mentioned this already, but I'm running netplug 1.2.9-r3.
OK. Can you now repeat the previous experiments, but at the point where you are missing an event, check if the interface is up or not. You can check this with: ifconfig eth0 If the interface is up, the 2nd line will include the word "UP"
OK, I'm not sure if this is what you're referring to; if not, my apologies in advance. Just a preface, I repeated the previous experiment without netplug and when I did 'ifconfig eth0' it showed 'UP' on the second line whether or not the cable was plugged in. Now, with netplug running, I unplugged the cable and eth0 disappeared from the interface list ('ifconfig' by itself). I then ran 'ifconfig eth0' and 'UP' did *not* show in the second line of the output. I plugged the cable back in, and the interface did not come back ('ifconfig' by itself) and when I ran 'ifconfig eth0' 'UP' still did *not* show up in the second line of the output.
That wasn't really what I asked - UP is not indicative of cable presence. What I really wanted to see is if netplug is bringing the interface down -- when the interface is down you cannot expect the driver to know about changes in link state. However, you still provided enough info: it appears that when one of the missing plug events is supposed to happen, the interface is not up (i.e. something has brought it down). So the issue here is that netplug is bringing the interface down. back to baselayout people for a fix here :)
OK, just for giggles I decided to try ifplugd and it works the way netplug should (i.e., unplug cable, eth0 goes away, plug it back in, eth0 comes back up). FYI. Yes, my version of netplug was up to date (1.2.9-r3). BTW, I've upgraded this machine to baselayout2 and openrc and netplug *still* didn't work correctly. Don't know why it can't seem to bring the interface back up after it goes down. *shrug*
Does this bug persist on modern kernels and the latest OpenRC stable? Please reopen with info.
Just to say that the recently released dhcpcd-5.5.4 has much improved link handling which may fix this bug.
As the laptop that this bug originated on was killed by my son, I think we can close it now. :-)
