Red Hat Bugzilla – Bug 124857
Official Broadcom BCM5700 driver doesn't build on fc2 (missing "genapic" symbol)
Last modified: 2007-11-30 17:10:43 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-GB; rv:1.6) Gecko/20040116
Description of problem:
I downloaded the official drivers for the BCM5700 Gigabit ethernet
cards from http://www.broadcom.com/drivers/downloaddrivers.php and,
after installing the kernel-source-2.6.5-1.358 RPM in Fedora Core 2
(I already had the toolchain installed for kernel building), I tried
to build the bcm5700.ko driver from source (it knows about 2.5/2.6
kernels and properly uses the kernel build system).
Unfortunately, I got a missing symbol warning ("genapic" not defined)
when it was linked and I didn't want to continue after that (well, I
did as you'll read later, but it might stop some users!).
Version-Release number of selected component (if applicable):
Broadcom BCM5600 driver 7.1.22
Steps to Reproduce:
1. Install kernel building toolset (gcc etc.) and the latest FC2
2. Download and unpack the Broadcom BCM5700 official drivers (I
unpacked the .tar.gz file that was inside the .zip file).
3. Go into the BCM5700 src tree and type "make".
Actual Results: Undefined symbol "genapic" during the link stage - a
search for this symbol in the FC2 source shows that it is *not*
exported to any of the kernel modules (e.g. via
EXPORT_SYMBOL(genapic); or something similar).
Expected Results: I should be able to build and install an official
third party Linux kernel driver without problems, especially one as
important as a widely-used network card as the BCM5700 driver (shipped
with a lot of servers, particularly Dell PowerEdges). I can't in this
Yes, I know the tg3 driver is the "preferred" driver for the BCM5700
family, but I'm afraid it's horribly, horribly broken for that family
(search for "tg3" and you'll see a slew of bug reports about it, plus
I see that kernel 2.6.7's tg3 driver is going to have yet more hacks
by folks to try to fix its numerous extremely serious problems). I
want to use the bcm5700 official driver because users are reporting
that it works with no problems - the tg3 driver FC2 selected for me
for our BCM5704 cards just produces errors and intermittent hangs.
Now, I don't expect FC2 later kernels or even FC3 to ship with the
bcm5700 driver since folks at Red Hat/Fedora seem convinced that the
tg3 driver isn't seriously faulty for the bcm5700 family, but I'm
begging that you export the "genapic" symbol to modules in FC2. To
convince you, SuSE have now fixed their 2.6.5 kernel RPMs to export
"genapic" for this very reason - see:
and the comment: "- patches.fixes/missing-exports.diff: bcm5700.ko
requires the genapic symbol."
I downloaded the kernel source for that fixed SuSE release and
searched around - this is the fix they added the end of
Please can you consider putting those 3 lines in for the next FC2
kernel update? I can't see the harm in it and it would let me build
the bcm5700.ko module without having to do a complete FC2 kernel
rebuild, which I've had to do to prove that the bcm5700.ko module
actually works with no errors (it does), but I'd rather stick with the
shipped kernel and just add the module for the network card.
why on earth would a network driver need generic apic stuff... nic
drivers shouldn't touch core irq routing infrastructure
from the driver:
printk(KERN_ERR "%s: Duplicate entry of the interrupt
handler by "
that hard_smp_processor_id() is actually a bug; they use the wrong
function to get the current cpu number, they should have used
Thanks for pointing that out - at least we have the fix in Bugzilla
for anyone else who might try and report this issue. I have sent an
e-mail to the BCM5700 driver author to request that he uses
smp_processor_id() instead of hard_smp_processor_id() in the next
release. If I put that change in the driver source, it builds and runs
happily with the shipped FC2 kernel. I suspect SuSE put the genapic
export "fix" in because it would keep bug reports down (maybe they
reckoned that the next BCM5700 driver release might be not be for
months and enough people had complained to them about the issue for
them to kludge their source), but it's not really the right solution,
as you correctly explained.