|Summary:||BCM 5700 Broadcom gigabit driver patch not longer included in gentoo-dev-sources 2.6.7|
|Product:||Gentoo Linux||Reporter:||Peter van der Spoel <peter.vanderspoel>|
|Component:||[OLD] Core system||Assignee:||x86-kernel (DEPRECATED) <x86-kernel>|
|Package list:||Runtime testing required:||---|
Description Peter van der Spoel 2004-06-19 15:29:14 UTC
The BCM 5700 Broadcom gigabit driver patch is needed for me to be able to use my network connection from my motherboard. I've tried other drivers that are by default included in the kernel (i.e. Broadcom Tigon3), but these do not work. The BCM5700 driver is the only one that works for me and have been included in the genpatches-x.x.x-base file since 2.4.* version uptil 2.6.6. Reproducible: Always Steps to Reproduce: 1. compile kernel, modules 2. install new kernel 3. try to access the network Actual Results: The eth0 device was not available and thus unable to connect to the network. Expected Results: ehh, connect to the network ?
Comment 1 Greg Kroah-Hartman (RETIRED) 2004-06-21 00:44:27 UTC
Why does the tg3 driver not work for you? Care to work with the tg3 driver authors to help fix this? Anyway, this patch has been removed on purpose, as it should be a stand alone package as it will never be added to the main kernel tree. If you want to create such a package, I would be glad to add it to the portage tree.
Comment 2 Tim Yamin (RETIRED) 2004-06-21 12:40:16 UTC
*** Bug 54624 has been marked as a duplicate of this bug. ***
Comment 3 Daniel Drake (RETIRED) 2004-06-23 01:31:56 UTC
*** Bug 54851 has been marked as a duplicate of this bug. ***
Comment 4 Roger Hill-Cottingham 2004-06-30 01:33:16 UTC
The tg3 driver just doesn't work, I'm afraid. The module loads, but doesn't talk to the ethernet card. If there is any more information you would like me to give, please ask. This is on an Acer Aspire 1501LMi amd_64 notebook. Changing the ethernet card is not an option :) I would be willing to help test modifications to the tg3 driver, but I'm afraid my coding skills kernel-wise are not up to the task of rewriting a kernel driver -- my preferred language is fortran :) Roger.
Comment 5 Greg Kroah-Hartman (RETIRED) 2004-06-30 16:32:23 UTC
Open up a bug at bugzilla.kernel.org where the tg3 driver authors can help you out. This isn't a gentoo specific issue.
Comment 6 Kevin L. Ford 2004-07-01 17:15:34 UTC
Well, I disagree. This is a Gentoo issue. As of gentoo-dev-sources 2.6.3-rxx the Broadcom patch was included in the gentoo patch-set. I did extract the patch and applied it. The driver did show up in menuconfig, and is presently in operation. So, unless the bcm5700 patch is no longer going to be support by Gentoo or the Linux Kernel Developers, it should be re-included into the base patch set.
Comment 7 Greg Kroah-Hartman (RETIRED) 2004-07-01 22:21:34 UTC
gentoo is not going to support this patch, as the linux kernel developers are not going to. Again, I suggest working with the tg3 developers to fix your problem.
Comment 8 J.O. Aho 2004-07-02 11:38:58 UTC
I had always the impression that patches was there to add more support or fix bugs... I would really like to see the bcm5700 to reappear in the gentoo-dev kernel. I got major problems when I upgraded from 2.6.5 to 2.6.7 and lost the network and half of the important files wasn't avaible as the nfs-partittions wasn't mounted as there was no network... Maybe there should be a major update of the kernel ebuilds, instead of having many ebuilds for different kind of kernels, maybe you should have a list of avaible patches, and each user could select those patches that they will be interested of and that way get a more personal kernel.
Comment 9 Greg Kroah-Hartman (RETIRED) 2004-07-02 12:51:26 UTC
Patches can not always be "mixed and matched" like you are suggesting. And attempting to try to support such a configuration would be a nightmare. So for now, we are going to try to stick to the kernel.org kernel as closely as possible. This lets us take advantage of the kernel community's support, and allows us to give back to that community by moving the patches that we really need, into the mainline kernel (as we are already working toward.)