TG3(Tigoon) & Kernel 2.4.27

Hello

When I try to compile kernel 2.4.27 for one of my servers i get this error.
--------------
drivers/net/net.o(.text+0x17550): In function tg3_request_firmware': : undefined reference to request_firmware' drivers/net/net.o(.text+0x17652): In function tg3_request_firmware': : undefined reference to release_firmware'
-------------

Any clue?

PS: I can include a part of my .config

On Tue, 24 Aug 2004 17:13:57 +0200 Laurent CARON wrote:

| Hello
| 
| When I try to compile kernel 2.4.27 for one of my servers i get this error.
| --------------
| drivers/net/net.o(.text+0x17550): In function `tg3_request_firmware': : 
| undefined reference to `request_firmware'
| drivers/net/net.o(.text+0x17652): In function `tg3_request_firmware': : 
| undefined reference to `release_firmware'
| -------------
| 
| Any clue?
| 
| PS: I can include a part of my .config

You need to enable CONFIG_EXPERIMENTAL and CONFIG_HOTPLUG and then CONFIG_FW_LOADER in the Library routines menu.

--
~Randy

Oh on the contrary, I've never seen a call to request_firmware() in any copy of the tg3 driver and that's strange being that I'm the maintainer. :-)

People, if you're going to use patched up kernels, report your problems to the people you got the kernel from. Thanks.

As a matter of fact this is most certainly kernel-source-2.4.27 from Debian. This problem was recently fixed (as discussed in the mini-thread about how CML1 blows chunks.)

For what it's worth to Google, kernel-tree-2.4.27-4 has just hit unstable (will reach mirrors by tomorrow) and should have fixed this problem.

Sorry for the noise caused to LKML.

Joshua Kwan

On Tue, 24 Aug 2004 18:37:41 -0700 Joshua Kwan wrote:

| David S. Miller wrote:
| > Oh on the contrary, I've never seen a call to request_firmware()
| > in any copy of the tg3 driver and that's strange being that I'm
| > the maintainer. :-)
| > 
| > People, if you're going to use patched up kernels, report your
| > problems to the people you got the kernel from.  Thanks.
| 
| As a matter of fact this is most certainly kernel-source-2.4.27 from 
| Debian. This problem was recently fixed (as discussed in the mini-thread 
| about how CML1 blows chunks.)
| 
| For what it's worth to Google, kernel-tree-2.4.27-4 has just hit 
| unstable (will reach mirrors by tomorrow) and should have fixed this 
| problem.
| 
| Sorry for the noise caused to LKML.

Please don't drop people from to: / cc:

--
~Randy

Something is wrong with this MUA. Sorry.

Joshua Kwan

Hi David,

I think that he's using a debian kernel and thinks he's using a vanilla kernel while it's not. I've just installed one on an ultra5 and discovered a directory with about 60 patches, one of which was dedicated to the removal of this "undesired closed-source tg3 firmware" ! I was happy not having lost time debugging this on a machine with a tg3 NIC.

I find it a bit odd when distro makers don't clearly put their name in their kernels, because it confuses people who honnestly think it's a vanilla one. Indeed, I'm yet not really sure what they put in the kernel that booted my sparc, but it's not a problem now since I've replaced it ;-)

Cheers,
Willy

I knew he was using a debian kernel from the moment I saw the string "tg3_request_firmware()" in the very first email of this thread.

I pity the poor fool who wishes to netboot his system using a tg3 card and use an nfsroot with Debian. Kind of hard to get the card firmware from the filesystem in that case.

I guess these debian kernel folks replace the BIOS on their system with one they have the sources for as well.

The tg3 firmware is just a bunch of MIPS instructions. I guess if I ran objdump --disassemble on the image and used the output of that in the tg3 driver and "compiled that source" they'd be happy. And this makes the situation even more ludicrious.

For the record, I made this change to Debian's kernel source, because the project consensus was that the firmware blobs were not free according to Debian's Free Software Guidelines.

Now I hope you're also aware that tg3 without the firmware works for about ~90-95% of all tigon3 based devices.

Anyway, to tell you the truth, I would have preferred not making this change. But the alternative was impossible: sticking the kernel into our non-free section. See below for more.

Nope. Good ol' Award is fine enough for me.

Then again, LinuxBIOS would satisfy the need for source, wouldn't it? ;)

I'm curious: run that by [email protected] and see what they say. They're the folks who started all this.

As far as I'm personally concerned, as long as Linus/Marcelo thinks it's free (i.e. it can be found in BK) and no one but people in Debian have the boredom/presence of mind/whatever to point out that this breaks our software guidelines, I find myself siding with the majority who believe it's free enough. The linux-kernel community seems to be actively cracking down on blatant GPL violations (see: Linksys WRT54G), and that's good, but they (perhaps wisely) seem to have overlooked the supposed firmware-in-file issue, and I figure that does say something.

I'm not clear on the details but what they seem to have deduced is that as long as the firmware 'variable' is not shipped into Debian as part of the compiled tg3.o, it's barely Free. See

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=243044

for details of the loophole. To me, it makes no difference...

Interesting to know that it's a "bunch of MIPS instructions." I'd wager
that eventually, some enterprising, bored hacker would probably come up
with a glorious Free cleanroom implementation of the firmware that you need to use a MIPS assembler or C comiler on on at build time.. (AIUI there's already some of that stuff in linux-2.6, though they're actually the original source code.)

As I said it's all very disgusting (hmm.. déjà vu..) and maybe people will stop caring about it someday.

Joshua Kwan

Am Mittwoch, 25. August 2004 09:47 schrieb Joshua Kwan:

And it really strains the meaning of "bugreport"

Regards
Oliver

And I have to assume that you guys did the same thing to the qlogic scsi drivers too? That should wipe out about half of the ia64 boxes out there, ROFL!

initramfs?

For GPL compliance, no, that wouldn't work. The GPL states:
"The source code for a work means the preferred form of the work for making modifications to it."

Which is likely C or at least assembly with label names and comments in this case.

-Ryan

Then it's a part of the kernel image.
You can't have it both ways dude.

It would have taken less time for the people who removed the firmware and will assure support for their users to disassemble this code and put labels and comments in it. When I was 16, I totally disassembled my PC's bios (8kB) commented it and labelled it to the point of making it re-assemblable. It did not take very much time (a week-end), and it was crappy x86 code with unaligned and mangled code/data + hard-coded stack values for the "calls" without any RAM usage. Here you have about 2kB of clean MIPS code which is about 500 instructions (500 lines). I doubt anyone knowing mips assembly enough would spend more than a week-end putting comments and labels in it.

Now another possibility would be for those zealots to replace the firmware by an open-source one such as http://alteon.shareable.org/ which BTW contains all the tools needed for the dirty work.

Anyway, this thread is getting boring...

Regards,
Willy

My mistake, I forgot to mention I was using a debian-source :(

Laurent