> <per class='per'>Ron Johnson</per> put forth on 4/14/2010 10:14 PM:
> Nothing I've seen in <loc class='loc'>dmesg</loc> has ever led me to think > that the r8169 > driver in my <per class='per'>Sid linux-source-2.6.31</per> kernel (yes, it's > old; .32 and 33 > fail to build) loads a blob. > Nothin Almost all <org class='org'>NICs</org> load firmware blobs. It's in <loc class='loc'>dmesg</loc> somewhere. When the firmware doesn't load you get something like this in <loc class='loc'>dmesg</loc>: eth1: RTL8168d/8111d at 0xffffc90000c4e000,xx:xx:xx:xx:xx:xx, <per class='per'>XID 083000c0</per> <per class='per'>IRQ</per> 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 <per class='per'>IIRC</per> is the one that ripped out the <org class='org'>RTL</org> firmware blob. I can't find via <org class='org'>Google</org> a dmesg snippet of a successful RTL firmware load. Here's what it looks like for <org class='org'>Intel 8255X</org> using the e100 driver, with the firmware blobs all compiled into the kernel: <org class='org'>e100 0000:00:0d.</org>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 <org class='org'>RTL</org> 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, <per class='per'>IIRC</per>, 3 ways to load the device firmware into the Linux kernel. This applies to all devices that require soft firmware, not just <org class='org'>NICs</org>: 1. Compile all device firmware blobs into the kernel 2. Compile the individual blob into the driver, use <per class='per'>initrd</per> 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. <org class='org'>NICs</org> 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 >> <org class='org'>NICs</org> 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 <per class='per'>2.6.32-trunk</per> on his firewall, bricking it until he disabled the onboard <org class='org'>RTL</org> and installed an <org class='org'>Intel</org> 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 <org class='org'>RTL</org> 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 <per > class='per'>LAN</per> > 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 <org class='org'>RTL</org> chip. I bet you get 1/3rd wire speed at best, about <per class='per'>30MB/s</per>, 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 <per class='per'>push/pull 50MB/s</per> 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 <org class='org'>RTL</org> chip can peak the wire it'll be a 2-3 second transfer if your network chips and Linux <org class='org'>TCP</org> 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 <org class='org'>RTL</org> 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 <per class='per'>2.6.32</per> 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 <per class='per'>.33</per> a while back but that turned out to be due to a slight bit too much overclock on my machine in this warmer weather. ;) -- <per class='per'>Stan</per> -- To UNSUBSCRIBE, email to <per class='per'>debian-user-requ...@lists.debian.org</per> with a subject of "unsubscribe". Trouble? Contact <per class='per'>listmas...@lists.debian.org</per> Archive: <per class='per'>http://lists.debian.org/4bc6960e.7020...@hardwarefreak.com</per>
