I am experiencing problems receiving large amounts of data, I see b44: eth0: Link is down. b44: eth0: Link is up at 100 Mbps, full duplex. b44: eth0: Flow control is off for TX and off for RX. This originally ocurred a year or so ago when I first set up the machine, but since the b44 drivers were listed as experimental in the kernel I tried the bcm4400 drivers, and everything works great. The bcm4400 drivers were working fine, since they have been masked I decided to try the ones in the kernel. I have also tried downloading the drivers from broadcom (1.00g) and they behave the same way (this was expected since they are supposed to be the same drivers now) The open source kernel drivers do appear to work without a problem on a laptop I have but lspci show it is not an identical controller. lspci from laptop that does work: 03:00.0 Ethernet controller: Broadcom Corporation BCM4401-B0 100Base-TX (rev 02) lspci from desktop that does NOT work: 01:09.0 Ethernet controller: Broadcom Corporation BCM4401 100Base-T (rev 01) As I said, the proprietary bcm4400 driver workes fine on both the desktop and laptop. I would prefer the bcm4400 package remain unmasked until this problem is resolved. Portage 2.1.1 (default-linux/x86/2006.0, gcc-4.1.1, glibc-2.4-r3, 2.6.18-rc7 i686) ================================================================= System uname: 2.6.18-rc7 i686 Intel(R) Pentium(R) 4 CPU 2.20GHz Gentoo Base System version 1.12.5 Last Sync: Fri, 15 Sep 2006 11:00:01 +0000 app-admin/eselect-compiler: [Not Present] dev-java/java-config: 1.2.11-r1 dev-lang/python: 2.3.5-r2, 2.4.3-r1 dev-python/pycrypto: 2.0.1-r5 dev-util/ccache: [Not Present] dev-util/confcache: [Not Present] sys-apps/sandbox: 1.2.17 sys-devel/autoconf: 2.13, 2.59-r7 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2 sys-devel/binutils: 2.16.1-r3 sys-devel/gcc-config: 1.3.13-r3 sys-devel/libtool: 1.5.22 virtual/os-headers: 2.6.11-r5 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CBUILD="i686-pc-linux-gnu" CFLAGS="-march=pentium4 -O2 -pipe -fomit-frame-pointer" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/share/X11/xkb" CONFIG_PROTECT_MASK="/etc/env.d /etc/gconf /etc/revdep-rebuild /etc/terminfo" CXXFLAGS="-march=pentium4 -O2 -pipe -fomit-frame-pointer" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig distlocks metadata-transfer sandbox sfperms strict" GENTOO_MIRRORS="http://distfiles.gentoo.org http://distro.ibiblio.org/pub/linux/distributions/gentoo" LINGUAS="" 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" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="x86 X a52 aac acl alsa apache2 audiofile berkdb bitmap-fonts bl bzip2 cdda cddb cdio cdparanoia cdr cdrom cjk cli crypt css cups divx4linux dlloader dri dts dv dvd dvdread edl eds elibc_glibc emboss encode esd exif expat fam fame fb fbcon ffmpeg fftw flac font-server foomaticdb fortran gd gdbm gif gimp gkrellm glut gmp gnome gpm graphviz gstreamer gtk gtk2 gtkhtml h323 hal id3 idn ieee1394 imlib input_devices_keyboard input_devices_mouse ipod ipv6 isdnlog joystick jpeg jpeg2k kernel_linux lame ldap libg++ libwww live lm_sensors logrotate lzo lzw mad maildir matroska mikmod mjpeg mmx mmxext mng motif mp3 mp4live mpeg mpeg2 mpeg4 mplayer mysql mysqli mythtv nas ncurses network nfs nls nptl nptlonly nvidia ogg openal opengl pam pcre perl player png pppd python qt3 quicktime readline reflection rtc samba sdl session smp sox speex spell spl sse sse2 ssl stream subtitles svg svga tcpd tga theora tiff timidity transcode truetype truetype-fonts type1-fonts udev unicode usb userland_GNU v4l v4l2 vcd vcdimager video_cards_nvidia videos vidix vim vlm vorbis win32codecs wma wma123 wmf x264 xanim xinerama xml xml2 xmms xorg xrandr xv xvid xvmc zlib" Unset: CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LANG, LC_ALL, LDFLAGS, MAKEOPTS, PORTAGE_RSYNC_EXTRA_OPTS, PORTDIR_OVERLAY
(In reply to comment #0) > I am experiencing problems receiving large amounts of data, I see > > b44: eth0: Link is down. > b44: eth0: Link is up at 100 Mbps, full duplex. > b44: eth0: Flow control is off for TX and off for RX. So let me get this straight, when you are receiving large amounts of data, those messages then appear in dmesg? How do they compare to the ones that appear when the connection is initially established? Also, please explain what the problems are exactly.
(In reply to comment #1) > (In reply to comment #0) > > I am experiencing problems receiving large amounts of data, I see > > > > b44: eth0: Link is down. > > b44: eth0: Link is up at 100 Mbps, full duplex. > > b44: eth0: Flow control is off for TX and off for RX. > > So let me get this straight, when you are receiving large amounts of data, > those messages then appear in dmesg? How do they compare to the ones that > appear when the connection is initially established? Yes. It appears that when I receive large amounts of data the link goes down. The only difference between the messages during initial boot, is that the first message indicating the link is down does not show up. So at bootup/initial connection, I only see the second and third messages. > > Also, please explain what the problems are exactly. > I have a MythTV frontend installed on this computer with the broadcom controller. My backend is on another machine on my network, using a different network card. I setup these computers last January and originally used the driver in the kernel (I can't remember what kernel version it was back then). It was marked experimental, but I figured I would try it. When trying to watch something (live TV, or a recorded video) on the frontend, the video would pause for a second or two at a time. For each one of these pauses I would see the tree messages listed above in the output of dmesg. I then installed the bcm4400 package, and everything worked great, no pausing, and no messages in dmesg. At the end of August the bcm4400 packages was masked, and the comment in package.mask indicated the kernel driver was ready to be used, and was infact what was being provided by broadcom now, so I decided to give it a try. When I tried the kernel driver (2.6.17-r8) I saw the same problems as before, video would pause, and I would see the messages in dmesg. I then went out the broadcom's website and downloaded the latest version of the drivers 1.00g and tried those. I saw the same results. I then looked at some of the bugs listed on this site, and saw a request to try the latest development version of the kernel, so I tried it (2.6.18-rc7) and had the same results. I have since gone back to the bcm4400 drivers, and back to kernel 2.6.17-r8 and everything is working correctly.
Please file a bug for this at http://bugzilla.kernel.org including "lspci -v" output. Explain clearly that the problem is that the driver thinks the link has gone down and then back up again when under load. We should be able to get the broadcom developers to look at this.
Any news on this? I wouldn't want to drop it while there are still open bugs about the kernel driver...
(In reply to comment #4) http://bugzilla.kernel.org/show_bug.cgi?id=3050 and http://bugzilla.kernel.org/show_bug.cgi?id=4566 are still open, so yes
Those reports do not seem to be of the same problem. Tyson, any news?
Sorry it took so long to respond, I posted a response two weeks ago, but it doesn't look like it worked, so it I go again. I too looked at those two bugs and they do not match what I was seeing. I have not submitted a bug report to kernel.org, I had previously submitted one directly to broadcom, and they were providing reasonable feedback. That has since stopped, and it appears that they have dropped the issue, and I am no longer getting any help. I have since given up and replaced this network interface, so I am no longer using this driver. I would be fine if this bug was closed, and do not see a large value in pursuing this issue as I seem to be the only one with this problem. It also only seems to effect large downloads, and is only a noticeable issue when what is being downloaded is real time content like streaming video. If the preference is to pursue a fix for this bug, I will submit the bug to kernel.org, but will not be able to do a large amount of testing as this is in a production machine now with the new network card.
OK, don't worry about it for now. Charlie suffers from this bug and will file it upstream soon.
I'm going to remove b44 sometime next week and Charlie (or another candidate) can file this upstream in their own time.
Sorry I took so long filing the upstream bug.
