Realtek ethernet (was Re: recent mobo recommendation)
in [Debian]
|
From: Ron Johnson on 14 Apr 2010 23:20 On 2010-04-14 21:58, Stan Hoeppner wrote: > Ron Johnson put forth on 4/14/2010 8:28 AM: >> On 2010-04-13 22:50, Stan Hoeppner wrote: >>> Hugo Vanwoerkom put forth on 4/13/2010 3:53 PM: >> [snip] >>> Either way, avoid onboard RealTek ethernet as it's not currently >>> supported >>> well by Debian. One might be able to make it work, but the process >>> requires >>> some serious hoop jumping. >>> >> Really? RealTek chips are as common as flies on horse poop, and works >> perfectly for me. > > Check the list archives. Not long ago (couple months maybe) Debian released > a 2.6.3x.x (not sure if it was Stable or Testing) kernel that omitted the > RealTek firmware blob due to "non free" status of the code, thus bricking > ethernet for quite a few users who upgraded to the new kernel via regular > aptitude upgrades. Is this situation fixed with newer Debian kernels or are > you manually telling the driver where to grab the firmware file on the root > filesystem? Was this situation limited to just that one kernel release? Nothing I've seen in dmesg has ever led me to think that the r8169 driver in my Sid linux-source-2.6.31 kernel (yes, it's old; .32 and 33 fail to build) loads a blob. > At least a couple of people on this list went out and bought non-RealTek PCI > NICs to fix the problem instead of reverting to the older kernel. I sort of remember that. [snip] > > Additionally I've seen a number of people state their GigE RTL chips only > achieve about 1/3rd of wire speed whereas Intel chips get over 80% of wire > speed without jumbo frames. TTBOMK there has never been a "free" code issue > with Intel drivers or firmware. They have a very long term rock solid track > record. I'm not surprised. Since I'm only connected to a small 100Mbps LAN which then connects to a 12Mbps cable modem, it doesn't really affect me. > Thus, I recommend users to stay away from RealTek chips and go with Intel > when they can. Yeah, RTL is "everywhere" because they're cheap as horse > dung, but there are plenty of alternatives, if one just looks around a bit. > > AFAIK, for those who roll their own kernels from kernel.org source, there's > no problem with RTL chips if you compile all blobs into the kernel. For > those using stock Debian kernels, RTL chips have been a problem, and may yet > be again. > Maybe if I ever get .32 or .33 I'll squeal in anger. Until then... -- Dissent is patriotic, remember? -- To UNSUBSCRIBE, email to debian-user-REQUEST(a)lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmaster(a)lists.debian.org Archive: http://lists.debian.org/4BC68489.5010307(a)cox.net
From: briand on 14 Apr 2010 23:40 On Wed, 14 Apr 2010 22:14:17 -0500 Ron Johnson <ron.l.johnson(a)cox.net> wrote: > On 2010-04-14 21:58, Stan Hoeppner wrote: > > Ron Johnson put forth on 4/14/2010 8:28 AM: > >> On 2010-04-13 22:50, Stan Hoeppner wrote: > >>> Hugo Vanwoerkom put forth on 4/13/2010 3:53 PM: > >> [snip] > >>> Either way, avoid onboard RealTek ethernet as it's not currently > >>> supported > >>> well by Debian. One might be able to make it work, but the > >>> process requires > >>> some serious hoop jumping. > >>> > >> Really? RealTek chips are as common as flies on horse poop, and > >> works perfectly for me. > > > > Check the list archives. Not long ago (couple months maybe) Debian > > released a 2.6.3x.x (not sure if it was Stable or Testing) kernel > > that omitted the RealTek firmware blob due to "non free" status of > > the code, thus bricking ethernet for quite a few users who upgraded > > to the new kernel via regular aptitude upgrades. Is this situation > > fixed with newer Debian kernels or are you manually telling the > > driver where to grab the firmware file on the root filesystem? Was > > this situation limited to just that one kernel release? > running 2.6.32-trunk on an Atom/Intel board and I'm not seeing any problems. RTL8111/8168B is what's listed via lspci I'm getting 1GB performance I do see the firmware messages: r8169 requesting rtl8169-1.fw so I'm not sure why it doesn't seem to be a problem. There is a disturbing trend on the part of HW manufacturers to have these customize firmware blobs, and that's not good. Brian -- To UNSUBSCRIBE, email to debian-user-REQUEST(a)lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmaster(a)lists.debian.org Archive: http://lists.debian.org/20100414203534.3b42f830(a)windy.deldotd.com
From: Ron Johnson on 15 Apr 2010 00:20 On 2010-04-14 22:35, briand(a)aracnet.com wrote: [snip] > > r8169 requesting rtl8169-1.fw > What package is that in? -- Dissent is patriotic, remember? -- To UNSUBSCRIBE, email to debian-user-REQUEST(a)lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmaster(a)lists.debian.org Archive: http://lists.debian.org/4BC691B8.7090200(a)cox.net
From: Stan Hoeppner on 15 Apr 2010 00:30 Ron Johnson put forth on 4/14/2010 10:14 PM: > Nothing I've seen in dmesg has ever led me to think that the r8169 > driver in my Sid linux-source-2.6.31 kernel (yes, it's old; .32 and 33 > fail to build) loads a blob. Almost all NICs load firmware blobs. It's in dmesg somewhere. When the firmware doesn't load you get something like this in dmesg: eth1: RTL8168d/8111d at 0xffffc90000c4e000,xx:xx:xx:xx:xx:xx, XID 083000c0 IRQ 32 eth1: unable to apply firmware patch That's a paste from one of the OPs here who was bitten by the 2.6.32-trunk upgrade which IIRC is the one that ripped out the RTL firmware blob. I can't find via Google a dmesg snippet of a successful RTL firmware load. Here's what it looks like for Intel 8255X using the e100 driver, with the firmware blobs all compiled into the kernel: e100 0000:00:0d.0: firmware: using built-in firmware e100/d101m_ucode.bin "built-in" signifies that the firmware blob has been included in the kernel at compile time. I do this to avoid issues such as this RTL problem. It only adds a couple hundred K to the kernel image. And I use the vanilla kernel.org sources to avoid any Debian "non-free" issues. Just about every NIC on the planet uses a firmware blob. There are, IIRC, 3 ways to load the device firmware into the Linux kernel. This applies to all devices that require soft firmware, not just NICs: 1. Compile all device firmware blobs into the kernel 2. Compile the individual blob into the driver, use initrd 3. Put firmware file in root filesystem, tell kernel the path #3 won't work with drivers that are needed during the boot process such as block device drivers. Those require method 1 or 2. NICs should be able to use 1-3. There are 3 different dmesg statements and 3 different errors depending on which method 1-3 above that you're using. >> At least a couple of people on this list went out and bought >> non-RealTek PCI >> NICs to fix the problem instead of reverting to the older kernel. > > I sort of remember that. Yeah, I just pulled the mails. One upgraded to 2.6.32-trunk on his firewall, bricking it until he disabled the onboard RTL and installed an Intel e100 IIRC. They thought it was a udev issue til I noticed the firmware load failure message referenced up above in this email. The other had an RTL wireless that failed for the same reason. I can't recall how they fixed that one. IIRC the OP didn't swap hardware to achieve the fix, so they did something with the kernel/driver/firmware. > I'm not surprised. Since I'm only connected to a small 100Mbps LAN > which then connects to a 12Mbps cable modem, it doesn't really affect me. Do some FTP or SCP tests back and forth to another LAN machine and see what transfers rates you get out of that RTL chip. I bet you get 1/3rd wire speed at best, about 30MB/s, if even that. The machines themselves need to be modern to saturate the link--no slow CPUs or disks. Any ~2GHz CPU with 512MB RAM and a decent 7.2K RPM SATA disk should be able to push/pull 50MB/s across the wire. For that matter, eliminate the disk by creating a 200MB RAM disk on each machine. Create a test file with dd and FTP/SCP it back and forth between the RAM disks. If your RTL chip can peak the wire it'll be a 2-3 second transfer if your network chips and Linux TCP stacks are up to the task. > Maybe if I ever get .32 or .33 I'll squeal in anger. Until then... It's looking like the RTL firmware blob issue may have been limited to the trunk kernel. You may get lucky. Then again, if you roll your own and put the firmware blobs in the kernel itself as I do, you shouldn't have a problem. That is, if the Debian kernel source doesn't have the blob ripped out for being "non-free". You mentioned you had problems building 2.6.32 and .33 kernel source. Do you use the Debian kernel source or kernel.org source? I've been using the kernel.org source for quite some time and have never had any real problems with it (knocks on wood). I had a build problem with .33 a while back but that turned out to be due to a slight bit too much overclock on my machine in this warmer weather. ;) -- Stan -- To UNSUBSCRIBE, email to debian-user-REQUEST(a)lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmaster(a)lists.debian.org Archive: http://lists.debian.org/4BC6960E.7020202(a)hardwarefreak.com
From: Stan Hoeppner on 15 Apr 2010 01:10 briand(a)aracnet.com put forth on 4/14/2010 10:35 PM: > running 2.6.32-trunk on an Atom/Intel board and I'm not seeing any > problems. Which 2.6.32? Apparently this bug was fixed in 2.6.32-3. I'm not sure if this firmware bug affected all RTL chips or even all RTL 8168/9 chips. Count yourself lucky. Here's the bug report: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=561309 > RTL8111/8168B is what's listed via lspci > > I'm getting 1GB performance That's impossible. GigE wire speed is 1Gb/s. Please learn the difference between [B]yte and [b]it quantities. And, I guarantee you are not getting 1Gb/s transfers between hosts with RTL chips. There's a big difference between link speed and data transmission speed/throughput. I've seen guys with serious hardware horsepower not be able to get even close to 500Mb/s with RTL chips. On the same machines, using an Intel GigE interface, they were getting over 900Mb/s. Intel ethernet chips cost about 5 times what RTL chips do. Performance is one of the reasons. > I do see the firmware messages: > > r8169 requesting rtl8169-1.fw > > so I'm not sure why it doesn't seem to be a problem. You're probably running a kernel that has the patch, or a chip/driver combo that doesn't barf when the firmware can't be loaded because neither need that firmware. > There is a disturbing trend on the part of HW manufacturers to have > these customize firmware blobs, and that's not good. That's not the problem. Firmware blobs are very necessary. They allow manufacturers to fix flaws in hardware devices or introduce enhancements after they've already shipped the products. Soft firmware blobs are a good thing. There's nothing disturbing about it, but for your lack of understanding of the subject. No offense intended, just stating facts. The problem is that Realtek apparently didn't release this particular firmware code under an appropriate free software license such as the GPL. This bug isn't technical in nature. The fix is, but the cause isn't. The cause is the fact that Realtek didn't make the firmware source "free". -- Stan -- To UNSUBSCRIBE, email to debian-user-REQUEST(a)lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmaster(a)lists.debian.org Archive: http://lists.debian.org/4BC69D69.9000308(a)hardwarefreak.com
First
|
Prev
|
Next
|
Last
Pages: 1 2 3 4 Prev: debian-user-digest Digest V2010 #630 Next: Reportbug-ng Cannot Retrieve Info |