hi, sometime in summer this year, broadcom has issued its first real linux driver for BCM4311-, BCM4312-, BCM4321-, and BCM4322-based hardware. i tried it to get rid of ndiswrapper on my bcm4328, and things worked out pretty well, so i thought i write the stub of an ebuild. so far it's 'works for me'-proof, and i'm also sure a couple of things are not done appropriately. so, please comments! points that certainly require more input: 1.) how to deliver (and flag) broadcom's very own licence? (comes with the tarball). 2.) there are 32-bit and 64-bit versions. how to deal with it? are *two* separate ebuild necessary? 3.) build_params is somewhat unclean now, at least i haven't seen '-C' anywhere else. how to use it properly? cheers, nico Reproducible: Always
Created attachment 173053 [details] initial broadcom sta linux driver ebuild
Created attachment 173054 [details, diff] patch to build on newer (>=2.6.26) kernels
Created attachment 173055 [details, diff] patch to fix the vlanmode problem taken from http://www.cenolan.com/fedora9/
Comment on attachment 173054 [details, diff] patch to build on newer (>=2.6.26) kernels taken from http://www.cenolan.com/fedora9/
Comment on attachment 173055 [details, diff] patch to fix the vlanmode problem taken from http://www.cenolan.com/fedora9/
@mobile: any interest?
Created attachment 174402 [details] updated ebuild patch needs to be applied only for kernels >= 2.6.27
Created attachment 176017 [details, diff] Patch for kernel 2.6.27 Bump in version from previous patch.
Created attachment 176018 [details] Ebuild for Broadcom-sta version 5.10.27.11 Ebuild to go with the above patch, my fist contribution.
Comment on attachment 176018 [details] Ebuild for Broadcom-sta version 5.10.27.11 Forgot to mention this also fixes the VLAN bug, you can use SSH and TELNET. Cheers
hi vito, is it possible that the latest patch is actually the same as the one that was submitted before? cheers, nico
(In reply to comment #11) > hi vito, > is it possible that the latest patch is actually the same as the one that was > submitted before? > cheers, > nico > (In reply to comment #11) > hi vito, > is it possible that the latest patch is actually the same as the one that was > submitted before? > cheers, > nico > Hi Nico, The previous patch would not apply for me. The only thing that changed was line numbers and I could not get patch to apply. Is there something I missed? vito ***** broadcom-build-fix.patch ***** ==================================== PATCH COMMAND: patch -p0 -p1 -E < /home/vito/src/overlays/macbook-pro/net-wireless/broadcom-sta/files/broadcom-build-fix.patch ==================================== patching file src/wl/sys/wl_iw.c Hunk #1 FAILED at 931. Hunk #2 FAILED at 944. Hunk #3 FAILED at 952. Hunk #4 FAILED at 970. Hunk #5 FAILED at 978. Hunk #6 FAILED at 989. Hunk #7 FAILED at 1003. Hunk #8 FAILED at 1012. 8 out of 8 hunks FAILED -- saving rejects to file src/wl/sys/wl_iw.c.rej ==================================== PATCH COMMAND: patch -p1 -p1 -E < /home/vito/src/overlays/macbook-pro/net-wireless/broadcom-sta/files/broadcom-build-fix.patch ==================================== patching file src/wl/sys/wl_iw.c Hunk #1 FAILED at 931. Hunk #2 FAILED at 944. Hunk #3 FAILED at 952. Hunk #4 FAILED at 970. Hunk #5 FAILED at 978. Hunk #6 FAILED at 989. Hunk #7 FAILED at 1003. Hunk #8 FAILED at 1012. 8 out of 8 hunks FAILED -- saving rejects to file src/wl/sys/wl_iw.c.rej ==================================== PATCH COMMAND: patch -p2 -p1 -E < /home/vito/src/overlays/macbook-pro/net-wireless/broadcom-sta/files/broadcom-build-fix.patch ==================================== patching file src/wl/sys/wl_iw.c Hunk #1 FAILED at 931. Hunk #2 FAILED at 944. Hunk #3 FAILED at 952. Hunk #4 FAILED at 970. Hunk #5 FAILED at 978. Hunk #6 FAILED at 989. Hunk #7 FAILED at 1003. Hunk #8 FAILED at 1012. 8 out of 8 hunks FAILED -- saving rejects to file src/wl/sys/wl_iw.c.rej ==================================== PATCH COMMAND: patch -p3 -p1 -E < /home/vito/src/overlays/macbook-pro/net-wireless/broadcom-sta/files/broadcom-build-fix.patch ==================================== patching file src/wl/sys/wl_iw.c Hunk #1 FAILED at 931. Hunk #2 FAILED at 944. Hunk #3 FAILED at 952. Hunk #4 FAILED at 970. Hunk #5 FAILED at 978. Hunk #6 FAILED at 989. Hunk #7 FAILED at 1003. Hunk #8 FAILED at 1012. 8 out of 8 hunks FAILED -- saving rejects to file src/wl/sys/wl_iw.c.rej ==================================== PATCH COMMAND: patch -p4 -p1 -E < /home/vito/src/overlays/macbook-pro/net-wireless/broadcom-sta/files/broadcom-build-fix.patch ==================================== patching file src/wl/sys/wl_iw.c Hunk #1 FAILED at 931. Hunk #2 FAILED at 944. Hunk #3 FAILED at 952. Hunk #4 FAILED at 970. Hunk #5 FAILED at 978. Hunk #6 FAILED at 989. Hunk #7 FAILED at 1003. Hunk #8 FAILED at 1012. 8 out of 8 hunks FAILED -- saving rejects to file src/wl/sys/wl_iw.c.rej
hi vito, oh no, i'm sorry, *i* missed something, and that is broadcom's actually having updated the driver. the two patches change in fact the same things, just for the different driver versions. -- thanks for updating anyway! cheers, nico
hi, uhm, i had another look at the ebuild and modified it a bit such that the version number gets properly reflected everywhere and the ebuild can potentially just be copies from version to version. the patches would need a naming scheme there, too; it's now <name-of-the-patch>-<version-number-with-underscores>.patch. oh, and i believe the vlan-patch needs updating as well! i'm having issues with that right now, so i'd be cool if you could just quickly do that, vito! cheers, nico
Created attachment 176084 [details] ebuild with proper version string
Comment on attachment 176017 [details, diff] Patch for kernel 2.6.27 Posting the same patch with the correct version information
Created attachment 176108 [details, diff] added the driver version to patch file name
Created attachment 176112 [details, diff] vlan mode patch for 5.10.27.11 release Please test this patch out.
(In reply to comment #14) > hi, > > uhm, i had another look at the ebuild and modified it a bit such that the > version number gets properly reflected everywhere and the ebuild can > potentially just be copies from version to version. > > the patches would need a naming scheme there, too; it's now > <name-of-the-patch>-<version-number-with-underscores>.patch. > > oh, and i believe the vlan-patch needs updating as well! i'm having issues with > that right now, so i'd be cool if you could just quickly do that, vito! > > cheers, > nico > New patches posted, I suppose if this works good we should consolidate both patches in to one patch. Let me know how the vlan patch works for you.
hmm, i got some issues here with my patch/diff configuration (they always pull in ^M at the end of the line), so the patches don't apply properly for me -- however, by looking at it, i'm sure everything you submitted is correct. *thanks* vito! merry christmas and happy holidays, too; see you next year on bugs.gentoo.org! cheers, nico
Created attachment 176117 [details] Updated ebuild for x86/amd64 Haha, I just wrote an ebuild tonight without searching bugzilla. I don't think I'll do that again... This should make it compile on x86 (afaik), there is only a little change in the SRC_URI.
(In reply to comment #21) > Created an attachment (id=176117) [edit] > Updated ebuild for x86/amd64 > > Haha, I just wrote an ebuild tonight without searching bugzilla. I don't think > I'll do that again... > > This should make it compile on x86 (afaik), there is only a little change in > the SRC_URI. > Thanks for the updated ebuild! Glad we can now support x86 and x86_64.
(this is an automated message based on filtering criteria that matched this bug) Hello, The Gentoo Team would like to firstly thank you for your ebuild submission. We also apologize for not being able to accommodate you in a timely manor. There are simply too many new packages. Allow me to use this opportunity to introduce you to Gentoo Sunrise. The sunrise overlay[1] is a overlay for Gentoo which we allow trusted users to commit to and all users can have ebuilds reviewed by Gentoo devs for entry into the overlay. So, the sunrise team is suggesting that you look into this and submit your ebuild to the overlay where even *you* can commit to. =) Because this is a mass message, we are also asking you to be patient with us. We anticipate a large number of requests in a short time. Thanks, On behalf of the Gentoo Sunrise Team, Jeremy. [1]: http://www.gentoo.org/proj/en/sunrise/ [2]: http://overlays.gentoo.org/proj/sunrise/wiki/SunriseFaq
hi everyone and happy 2009! i just figured out why the patches refused to build for me, reason is: from the .11 version of their driver, broadcom source files ship with DOS end-of-line characters instead of unix ones. geeeez... i'll poke them right away about it. the good thing is that they issued an update to .12 on new year's eve *including* the build patch, so we don't need to bother about that one anymore. i'll try to fix up a dos-end-of-line patch for the vlanmode and submit as soon as possible. cheers, nico
Created attachment 177128 [details] .12 ebuild and here's the new ebuild...
Created attachment 177129 [details, diff] .12 vlanmode-fix patch watch out for those DOS end-of-line characters!
By the way, 5.10.27.12 seems to work fine without any patch here.
ah, okay. well, the only patch the applies in the latest ebuild is the vlanmode patch anyway, as taken from http://www.cenolan.com/broadcom-wl/ -- quite honestly, i don't even know what this thing improves. anyone got experience with that? cheers, nico
Like #10 says, it (at least) used to workaround problems with SSH and telnet behind a NAT. With the december version, I no longer need that, as things work out of box.
(In reply to comment #26) (In reply to comment #25) This ebuild and patch appears to be working very nicely for me on amd64. Thanks, chris
Created attachment 178706 [details, diff] patch for linux-2.6.29 this patch fixes compilation on linux-2.6.29 and works fine for me atm
oh, forgot to mention, lib80211 is required now
do one needs to apply the patch to the kernel? is there a chance it is part of a kernel sources that is in the tree or even in an overlay that has tuxonice
DaggyStyle, the patch is to be applied to the driver source itself. Moreover, users of kernels < 2.6.29 don't need it.
When trying broadcom-sta-5.10.27.12.ebuild, I came up with the following error: ***** broadcom-vlanmode-fix-5_10_27_12.patch ***** ================================================== PATCH COMMAND: patch -p0 -g0 -E --no-backup-if-mismatch < /usr/local/portage/net-wireless/broadcom-sta/files/broadcom-vlanmode-fix-5_10_27_12.patch ================================================== patching file src/wl/sys/wl_iw.c patch: **** malformed patch at line 11: --- src/wl/sys/wl_linux.c.orig 2009-01-02 17:54:21.000000000 +0100 ================================================== PATCH COMMAND: patch -p1 -g0 -E --no-backup-if-mismatch < /usr/local/portage/net-wireless/broadcom-sta/files/broadcom-vlanmode-fix-5_10_27_12.patch ================================================== can't find file to patch at input line 3 Perhaps you used the wrong -p or --strip option? The text leading up to this was: -------------------------- |--- src/wl/sys/wl_iw.c.orig 2009-01-02 17:53:01.000000000 +0100 |+++ src/wl/sys/wl_iw.c 2009-01-02 17:53:20.000000000 +0100 -------------------------- No file to patch. Skipping patch. patch: **** malformed patch at line 11: --- src/wl/sys/wl_linux.c.orig 2009-01-02 17:54:21.000000000 +0100 ================================================== PATCH COMMAND: patch -p2 -g0 -E --no-backup-if-mismatch < /usr/local/portage/net-wireless/broadcom-sta/files/broadcom-vlanmode-fix-5_10_27_12.patch ================================================== can't find file to patch at input line 3 Perhaps you used the wrong -p or --strip option? The text leading up to this was: -------------------------- |--- src/wl/sys/wl_iw.c.orig 2009-01-02 17:53:01.000000000 +0100 |+++ src/wl/sys/wl_iw.c 2009-01-02 17:53:20.000000000 +0100 -------------------------- No file to patch. Skipping patch. patch: **** malformed patch at line 11: --- src/wl/sys/wl_linux.c.orig 2009-01-02 17:54:21.000000000 +0100 ================================================== PATCH COMMAND: patch -p3 -g0 -E --no-backup-if-mismatch < /usr/local/portage/net-wireless/broadcom-sta/files/broadcom-vlanmode-fix-5_10_27_12.patch ================================================== can't find file to patch at input line 3 Perhaps you used the wrong -p or --strip option? The text leading up to this was: -------------------------- |--- src/wl/sys/wl_iw.c.orig 2009-01-02 17:53:01.000000000 +0100 |+++ src/wl/sys/wl_iw.c 2009-01-02 17:53:20.000000000 +0100 -------------------------- No file to patch. Skipping patch. patch: **** malformed patch at line 11: --- src/wl/sys/wl_linux.c.orig 2009-01-02 17:54:21.000000000 +0100 ================================================== PATCH COMMAND: patch -p4 -g0 -E --no-backup-if-mismatch < /usr/local/portage/net-wireless/broadcom-sta/files/broadcom-vlanmode-fix-5_10_27_12.patch ================================================== missing header for unified diff at line 3 of patch can't find file to patch at input line 3 Perhaps you used the wrong -p or --strip option? The text leading up to this was: -------------------------- |--- src/wl/sys/wl_iw.c.orig 2009-01-02 17:53:01.000000000 +0100 |+++ src/wl/sys/wl_iw.c 2009-01-02 17:53:20.000000000 +0100 -------------------------- No file to patch. Skipping patch. patch: **** malformed patch at line 11: --- src/wl/sys/wl_linux.c.orig 2009-01-02 17:54:21.000000000 +0100
I tried the ebuild without the patch, and it worked. Nice! It's not the fastest driver, but it sure does connect solidly. It's also not the b43. Yay.
ok, let me see if I go it right, I use kernel 2.6.28, all I need to do it download the 5.10.27.12 ebuild and that's it?
that's right, plus right now the ebuild requires the vlanmode-fix patch. it's not quite clear to me, however, if this is actually of any use (see comment #29). cheers, nico
the vlan mode patch isn't requried anymore on latest drivers
card is identified :) thanks, one more thing, the device created is eth1, I've tried to set it to wlan0 in udev but it won't change and won't fully load, how can I change it to wlan0 correctly?
Add something like SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:22:5f:07:d5:b8", ATTR{type}=="1", KERNEL=="eth*", NAME="wlan0" to /etc/udev/rules.d/70-persistent-net.rules. And, I think these questions are not really on-topic.
(In reply to comment #41) > Add something like > > SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", > ATTR{address}=="00:22:5f:07:d5:b8", ATTR{type}=="1", KERNEL=="eth*", > NAME="wlan0" > > to /etc/udev/rules.d/70-persistent-net.rules. > > And, I think these questions are not really on-topic. > sorr, your right, my fault
one last question, does it supports scanning for your chip? if so, what is the chip id?
btw, Broadcom guys released an updated version a few days ago.
Created attachment 179564 [details, diff] new patch for compilation against 2.6.29 and here's the updated linux-2.6.29 patch for the new release
Created attachment 179581 [details] ebuild for 5.10.27.14 I've updated the ebuild. Would it make more sense to name the patches like 5_10_27_14 as the ebuild is replacing '.' with '_' in MY_PV? * dropped the vlanmode patch * pulled in linux 2.6.29 patch (It applies but I'm running 2.6.28 so I can't really do anything but say it doesn't break the earlier version) * updated ebuild to new version and changes in download naming scheme.
hi, cool to see so many people interested in the build! thanks chris in particular for the updated ebuild. for the patch name, i personally feel like we should take the underscore notation, it seems a little unlinuxish to me. anyway, we still got ${PV} for the version with the dots, so why not replace this in the ebuild? the same goes for the "2.6.29" which may be replaced by "${KV}". i'd also vote for enclosing the patch application itself into "if [[ ${KV_PATCH} -gt 28 ]] ; then" or something like that. i mean, christoph very carefully wrapped up the .patch with many "if kernel such-and-such", but hey, you don't always want to check the whole for that, right? what do you think? cheers, nico
(In reply to comment #47) > hi, > > cool to see so many people interested in the build! thanks chris in particular > for the updated ebuild. > > for the patch name, i personally feel like we should take the underscore > notation, it seems a little unlinuxish to me. anyway, we still got ${PV} for > the version with the dots, so why not replace this in the ebuild? Good point. It does make more sense to do it that. > the same goes > for the "2.6.29" which may be replaced by "${KV}". This feels brittle to me, what happens when kernel version 2.6.30 comes out? While the patch might still be appropriate and functional there ebuild would need to be adjusted or the a copy of the patch file would need to be created. Of course the same can be said of a new version of the broadcom-sta driver and the opposite condition could also be true (the patch fails in a latter version). > > i'd also vote for enclosing the patch application itself into "if [[ > ${KV_PATCH} -gt 28 ]] ; then" or something like that. i mean, christoph very > carefully wrapped up the .patch with many "if kernel such-and-such", but hey, > you don't always want to check the whole for that, right? This makes sense, there is no reason to apply the patch for earlier versions of the kernel. I'll update the ebuild as such. Chris S.
Created attachment 179630 [details, diff] Update 5.10.27.14 ebuild * Use PV instead of MY_PV in patch name. * Only apply patch for KV_PATCH > 28
> > the same goes > > for the "2.6.29" which may be replaced by "${KV}". > > This feels brittle to me, what happens when kernel version 2.6.30 comes out? > While the patch might still be appropriate and functional there ebuild would > need to be adjusted or the a copy of the patch file would need to be created. > Of course the same can be said of a new version of the broadcom-sta driver and > the opposite condition could also be true (the patch fails in a latter > version). As a clarification, I don't like the idea of creating a dependency between the naming of a patch and the version of currently running/installed software that could be different from install to install. That just sounds like a maintenance nightmare.
(In reply to comment #47) > i'd also vote for enclosing the patch application itself into "if [[ > ${KV_PATCH} -gt 28 ]] ; then" or something like that. i mean, christoph very > carefully wrapped up the .patch with many "if kernel such-and-such", but hey, > you don't always want to check the whole for that, right? I'd say it's more logical to have one generic source (produced from the Broadcom source and the patch) that compiles for all kernels. Also, these checks occur at compile time and do not introduce runtime penalty.
(In reply to comment #49) > * Only apply patch for KV_PATCH > 28 what andrey said, we usually don't like it when patches are only applied in some situations, I've written the patch like that on purpose, it's supposed to be applied even if the code won't be used
I've sent broadcom an mail about the driver and two issues that I've noticed, this is what I've got is response: Broadcom is currently evaluating our support strategy for Linux users. As the chipset supplier, Broadcom provides Linux support to our customers - the manufacturers of wireless devices - that ultimately provide products to end customers, such as wireless LAN vendors, cable modem vendors, and notebook providers. It is up to these manufacturers to provide Linux client support to their end customers. Broadcom does not make a Linux client version available for end users at this time, however this may change in the future. In the meantime, please contact the manufacturer of your wireless device for Linux drivers. Linux support for certain products may also be available from Linuxant, and third party provider at http://www.linuxant.com/driverloader/ Regards, Broadcom Support Team Name: Dagg Stompler Subject: Web Site Feedback/Support Request - 54g Wireless LAN - Linux Drivers Email Address: stompdagger1@yahoo.com Feedback: hello, I'm running linux has a main system, I have a broadcom wireless card, the id is 0c:00.0 0280: 14e4:4315 Network controller: Broadcom Corporation BCM4312 802.11b/g (rev 01) I've tried the broadcom-sta driver but when I load the module and try to watch information on the adapter using the command iwconfig this is what I see: eth1 IEEE 802.11 Nickname:"" Access Point: Not-Associated when the output should be like this: eth1 IEEE 802.11g ESSID:off/any Mode:Managed Frequency:2.462 GHz Access Point: Not-Associated Bit Rate:54 Mb/s Tx-Power:24 dBm RTS thr:2347 B Fragment thr:2346 B Power Management:off Link Quality:0 Signal level:0 Noise level:0 Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0 Tx excessive retries:0 Invalid misc:0 Missed beacon:0 plus, when I try to scan for networks, I get an error saying that the device doesn't support scanning I wanted to know are these bugs or features not implemented yet? thanks. now I ask, what kind of a response is this?
> I've tried the broadcom-sta driver but when I load the module and try to watch > information on the adapter using the command iwconfig this is what I see: > eth1 IEEE 802.11 Nickname:"" > Access Point: Not-Associated > > when the output should be like this: > eth1 IEEE 802.11g ESSID:off/any > Mode:Managed Frequency:2.462 GHz Access Point: Not-Associated > Bit Rate:54 Mb/s Tx-Power:24 dBm > RTS thr:2347 B Fragment thr:2346 B > Power Management:off > Link Quality:0 Signal level:0 Noise level:0 > Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0 > Tx excessive retries:0 Invalid misc:0 Missed beacon:0 > > plus, when I try to scan for networks, I get an error saying that the device > doesn't support scanning > I wanted to know are these bugs or features not implemented yet? > Aside from the response that Broadcom gave you, I would suggest trying iwconfig and scanning as root. Both of these functions appear to work perfectly well when run as root but not when run as a common user. I'm not sure why though. (In reply to comment #52) > (In reply to comment #49) > > * Only apply patch for KV_PATCH > 28 > > what andrey said, we usually don't like it when patches are only applied in > some situations, I've written the patch like that on purpose, it's supposed to > be applied even if the code won't be used > I'll correct that and resubmit.
Created attachment 179742 [details] Update 5.10.27.14 ebuild * Removes conditional application of the 2.6.29 patch
ok, thank's working beside the scanning that returns Failed to read scan data : Invalid argument
Created attachment 180576 [details, diff] hidden SSID fix Hi from the Fedora maintainer for broadom-wl. Thought you might want this patch which allows the driver to associate with hidden SSID networks using Network Manager [1]. Also, thank you for the 2.6.29 build patch - very useful! [1] http://worldofxor.blogspot.com/2008/12/it-works-broadcom-official-wireless.html
(In reply to comment #57) > Created an attachment (id=180576) [edit] > hidden SSID fix > > Hi from the Fedora maintainer for broadom-wl. > > Thought you might want this patch which allows the driver to associate with > hidden SSID networks using Network Manager [1]. > > Also, thank you for the 2.6.29 build patch - very useful! > > [1] > http://worldofxor.blogspot.com/2008/12/it-works-broadcom-official-wireless.html > patch need to be changed a bit (eof characters) but it works. I haven't tested it yet. I'll upload the modified version.
Created attachment 180679 [details, diff] broadcom-wl-5.10.27.14-hidden-essid.patch
(In reply to comment #58) > > patch need to be changed a bit (eof characters) but it works. I haven't tested > it yet. I'll upload the modified version. > My bad, I haven't had chance to test it yet either. I am now hearing that the hidden SSID problem _may_ have been fixed in 5.10.27.12 but I don't see any fix in the code so it is possible that they fixed it within the binary blob? Need to test *.12 or *.14 with and without the patch to see if hidden SSID works. Hope you don't mind me jumping in on this ticket - I feel that as we have no access to upstream devs for this module then the more we can communicate and share fixes/patches between distros the better. I am trying to feed fixes upstream via Canonical but even they say they don't have great access to broadcom.
quick question, I don't seem to see a ebuild that apples the patch, is there a one in the list or I need to modify the ebuild?
(In reply to comment #61) > quick question, I don't seem to see a ebuild that apples the patch, is there a > one in the list or I need to modify the ebuild? > I made a modified ebuild in my local overlay. I didn't upload it. The only change was to add an "epatch" line.
I tried the latest broadcom*14 ebuild with 2.6.29-rc3-zen1, and firstly, it failed. After I modified the ebuild as below, it would finish. However, on reboot, I was dropped into the middle of Kernel-panic-opolis. The kernel panic was directly related to the wireless module, and happened as soon as its module was autoprobed. BEGIN>>> # Copyright 1999-2008 Gentoo Foundation # Distributed under the terms of the GNU General Public License v2 inherit linux-mod DESCRIPTION="Broadcom's IEEE 802.11a/b/g/n hybrid Linux device driver." HOMEPAGE="http://www.broadcom.com/support/802.11/linux_sta.php" MY_PV="$(replace_all_version_separators _)" SRC_BASE="http://www.broadcom.com/docs/linux_sta/hybrid-portsrc-x86" SRC_URI=" x86? ( ${SRC_BASE}_32-v${MY_PV}.tar.gz ) amd64? ( ${SRC_BASE}_64-v${MY_PV}.tar.gz )" LICENSE="broadcom" KEYWORDS="~amd64 ~x86" IUSE="" #CONFIG_CHECK="IEEE80211 IEEE80211_CRYPT_TKIP"#having the CONFIG_CHECK here insures ebuild failure when using a .29 kernel. S="${WORKDIR}" MODULE_NAMES="wl(net/wireless)" MODULESD_WL_ALIASES=("wlan0 wl") src_unpack() { unpack ${A} epatch "${FILESDIR}/broadcom-sta-${PV}-linux-2.6.29.patch" CONFIG_CHECK="IEEE80211 IEEE80211_CRYPT_TKIP" #When placed *after* patching, the ebuild finishes. } src_compile() { BUILD_PARAMS="-C ${KV_OUT_DIR} M=${S}" BUILD_TARGETS="wl.ko" linux-mod_src_compile } END>>>>>> Should I also post this as an attachment?
(In reply to comment #63) it works that way because it's completely wrong. the check is done in pkg_setup, so if you define CONFIG_CHECK in src_unpack, it'll be ignored. the correct way would be to use conditional checks based on the correct config options (I already said we need lib80211 on 2.6.29): pkg_setup() { if kernel_is ge 2 6 29; then CONFIG_CHECK="LIB802111" else CONFIG_CHECK="IEEE80211 IEEE80211_CRYPT_TKIP" fi linux-info_pkg_setup }
(In reply to comment #64) > (In reply to comment #63) > > it works that way because it's completely wrong. the check is done in > pkg_setup, so if you define CONFIG_CHECK in src_unpack, it'll be ignored. the > correct way would be to use conditional checks based on the correct config > options (I already said we need lib80211 on 2.6.29): > > pkg_setup() { > if kernel_is ge 2 6 29; then > CONFIG_CHECK="LIB802111" > else > CONFIG_CHECK="IEEE80211 IEEE80211_CRYPT_TKIP" > fi > linux-info_pkg_setup > } > That's not the bothersome part for me. The bothersome part is having the kernel panic. That's what I'd like fixed.
Created attachment 184149 [details] broadcom-sta-5.10.79.10.ebuild New release. Changelog: - I only noticed that "module licence" is now specified
Created attachment 184151 [details, diff] broadcom-sta-5.10.79.10-hidden-essid.patch The hidden-essid patch. Nothing changed but the line numbers.
Created attachment 184152 [details, diff] broadcom-sta-5.10.79.10-linux-2.6.29.patch Untouched, just renamed.
Created attachment 184198 [details] modified ebuild previous ebuild patched the code with the 2.6.29 patch even if it wasn't a 2.6.29 kernel so I've added a if condition which will apply the patch only if the kernel is 2.6.29
Created attachment 184309 [details] net-wireless/broadcom-sta-5.10.79.10.ebuild Clean up. ${P}-linux-2.6.29.patch works even if your kernel version is less than 2.6.29. I'll commit this ebuild to official portage tree.
(In reply to comment #70) > Created an attachment (id=184309) [edit] > net-wireless/broadcom-sta-5.10.79.10.ebuild > > Clean up. > ${P}-linux-2.6.29.patch works even if your kernel version is less than 2.6.29. > > I'll commit this ebuild to official portage tree. > isn't that unnecessary patching?
(In reply to comment #71) > (In reply to comment #70) > > Created an attachment (id=184309) [edit] > > net-wireless/broadcom-sta-5.10.79.10.ebuild > > > > Clean up. > > ${P}-linux-2.6.29.patch works even if your kernel version is less than 2.6.29. > > > > I'll commit this ebuild to official portage tree. > > > > isn't that unnecessary patching? > No, but the patch gives no effect older than 2.6.29 because of it uses 'if preprocessor'.
(In reply to comment #72) > (In reply to comment #71) > > (In reply to comment #70) > > > Created an attachment (id=184309) [edit] > > > net-wireless/broadcom-sta-5.10.79.10.ebuild > > > > > > Clean up. > > > ${P}-linux-2.6.29.patch works even if your kernel version is less than 2.6.29. > > > > > > I'll commit this ebuild to official portage tree. > > > > > > > isn't that unnecessary patching? > > > > No, but the patch gives no effect older than 2.6.29 because of it uses 'if > preprocessor'. > so the if I've added is actually been done?
(In reply to comment #69) > previous ebuild patched the code with the 2.6.29 patch even if it wasn't a > 2.6.29 kernel so I've added a if condition which will apply the patch only if > the kernel is 2.6.29 > It's already been said that you must not do that... and if you did, you'd have to check for >= 2.6.29, not = 2.6.29 (ge instead of eq) (In reply to comment #70) > Clean up. While you're at it, please replace those two epatches with one (it takes >=1 argument)
(In reply to comment #63) > I tried the latest broadcom*14 ebuild with 2.6.29-rc3-zen1, and firstly, it > failed. After I modified the ebuild as below, it would finish. However, on > reboot, I was dropped into the middle of Kernel-panic-opolis. The kernel panic > was directly related to the wireless module, and happened as soon as its module > was autoprobed. Also panic here. Kernel was built from sys-kernel/gentoo-sources:2.6.29, lib80211 enabled. Modules compiles and installs ok but I've got a kernel pannic when I tried to use the wl module. The kpanic however does not occur when loading the module (module loads with a "(wl): not using net_device_ops yet" warning, but does not issue any error). After that, when trying to bring the link up, I get the infamous kernel panic. I couldn't copy the panic message entirely but what I could get from it was: EIP at: wl_txflowcontrol+0x3c/0x80 This, in my opinion, looks more like an upstream bug than a but related to packaging the sta, or anything related to the patches. If I'm wrong please correct me (and the ebuild/patches).
(In reply to comment #75) > (In reply to comment #63) > > I tried the latest broadcom*14 ebuild with 2.6.29-rc3-zen1, and firstly, it > > failed. After I modified the ebuild as below, it would finish. However, on > > reboot, I was dropped into the middle of Kernel-panic-opolis. The kernel panic > > was directly related to the wireless module, and happened as soon as its module > > was autoprobed. > > Also panic here. Kernel was built from sys-kernel/gentoo-sources:2.6.29, > lib80211 enabled. Modules compiles and installs ok but I've got a kernel pannic > when I tried to use the wl module. > > The kpanic however does not occur when loading the module (module loads with a > "(wl): not using net_device_ops yet" warning, but does not issue any error). > > After that, when trying to bring the link up, I get the infamous kernel panic. > I couldn't copy the panic message entirely but what I could get from it was: > > EIP at: wl_txflowcontrol+0x3c/0x80 > > This, in my opinion, looks more like an upstream bug than a but related to > packaging the sta, or anything related to the patches. If I'm wrong please > correct me (and the ebuild/patches). > I've seen a similar kernel panic when attempting to connect to the wireless network where I work. From what I can tell, this is related to configurations of networks. My system at home works fine but I was getting a panic within seconds of connecting to wireless where I work. Unfortunately, I have not idea which network characteristic is the cause.
(In reply to comment #76) > > I've seen a similar kernel panic when attempting to connect to the wireless > network where I work. From what I can tell, this is related to configurations > of networks. My system at home works fine but I was getting a panic within > seconds of connecting to wireless where I work. Unfortunately, I have not idea > which network characteristic is the cause. > It would appear that the particular issue I was seeing is not a problem any longer. There may be a related issue though.
(In reply to comment #77) > (In reply to comment #76) > > > > I've seen a similar kernel panic when attempting to connect to the wireless > > network where I work. From what I can tell, this is related to configurations > > of networks. My system at home works fine but I was getting a panic within > > seconds of connecting to wireless where I work. Unfortunately, I have not idea > > which network characteristic is the cause. > > > > It would appear that the particular issue I was seeing is not a problem any > longer. There may be a related issue though. > I wasn't saying anything about connecting to any network. I was just talking about "ip link set eth<X> up". That's where I get the panic.
Hi, seems like Broadcom published a patch on their page http://www.broadcom.com/docs/linux_sta/wl_iw_v2.patch which looks quite ~similar~ to what we provide as broadcom-sta-5.10.79.10-wl_iw.patch. Has anyone had a look at this already? Cheers, Nico
Created attachment 187456 [details, diff] updated patch Alright, I tried it now myself and it indeed fixes some `ioctl[SIOCGIWSCAN]: Invalid argument` errors for me. Patch appended. Nico
tha patch is in cvs. but it occurs oops, bug #265385.
Created attachment 189238 [details] broadcom-sta-5.10.79.10-r1 build log on 2.6.30-rc3 broadcom-sta-5.10.79-10-r1 doesn't compile on 2.6.30-rc3 it seems that it tries to include net/ieee80211.h. however 2.6.29 patch was already applied.
Created attachment 189250 [details, diff] patch for linux-2.6.30 Please, test.
(In reply to comment #83) > Created an attachment (id=189250) [edit] > patch for linux-2.6.30 > > Please, test. > It compiles fine with your patch. Thank you. :)
SRC_URI not found anymore, returns 404 :( only a newer package available now.
broadcom-sta-5.10.91.9 in cvs. and close this bug.
(In reply to comment #84) > (In reply to comment #83) > > Created an attachment (id=189250) [edit] > > patch for linux-2.6.30 > > > > Please, test. > > > > It compiles fine with your patch. Thank you. :) > I cannot compile on 2.6.30. make: Entering directory `/usr/src/linux-2.6.30' CC [M] /var/tmp/portage/net-wireless/broadcom-sta-5.10.91.9-r1/work/src/wl/sys/wl_linux.o /var/tmp/portage/net-wireless/broadcom-sta-5.10.91.9-r1/work/src/wl/sys/wl_linux.c: In function 'wl_if_setup': /var/tmp/portage/net-wireless/broadcom-sta-5.10.91.9-r1/work/src/wl/sys/wl_linux.c:233: error: 'struct net_device' has no member named 'open' /var/tmp/portage/net-wireless/broadcom-sta-5.10.91.9-r1/work/src/wl/sys/wl_linux.c:234: error: 'struct net_device' has no member named 'stop' /var/tmp/portage/net-wireless/broadcom-sta-5.10.91.9-r1/work/src/wl/sys/wl_linux.c:235: error: 'struct net_device' has no member named 'hard_start_xmit' /var/tmp/portage/net-wireless/broadcom-sta-5.10.91.9-r1/work/src/wl/sys/wl_linux.c:236: error: 'struct net_device' has no member named 'get_stats' /var/tmp/portage/net-wireless/broadcom-sta-5.10.91.9-r1/work/src/wl/sys/wl_linux.c:237: error: 'struct net_device' has no member named 'set_mac_address' /var/tmp/portage/net-wireless/broadcom-sta-5.10.91.9-r1/work/src/wl/sys/wl_linux.c:238: error: 'struct net_device' has no member named 'set_multicast_list' /var/tmp/portage/net-wireless/broadcom-sta-5.10.91.9-r1/work/src/wl/sys/wl_linux.c:239: error: 'struct net_device' has no member named 'do_ioctl' make[1]: *** [/var/tmp/portage/net-wireless/broadcom-sta-5.10.91.9-r1/work/src/wl/sys/wl_linux.o] Error 1 make: *** [wl.ko] Error 2 make: Leaving directory `/usr/src/linux-2.6.30'
(In reply to comment #87) FIXED I had to enable CONFIG_COMPAT_NET_DEV_OPS in kernel config
Just a heads-up, somewhere between 2.6.30-git8 (which is ok) and 2.6.30-git11 CONFIG_COMPAT_NET_DEV_OPS has been removed from the mainline kernel and this driver obviously does not compile anymore.
(In reply to comment #89) > Just a heads-up, somewhere between 2.6.30-git8 (which is ok) and 2.6.30-git11 > CONFIG_COMPAT_NET_DEV_OPS has been removed from the mainline kernel and this > driver obviously does not compile anymore. > It's still there (in 2.6.30-gentoo-r1) Device Drivers ---> Network Device Support ---> Enable older network device API compatibility
Created attachment 195182 [details, diff] a patch to convert the wl driver to net_device_ops (required to build on 2.6.31+)
(In reply to comment #90) > (In reply to comment #89) > > Just a heads-up, somewhere between 2.6.30-git8 (which is ok) and 2.6.30-git11 > > CONFIG_COMPAT_NET_DEV_OPS has been removed from the mainline kernel and this > > driver obviously does not compile anymore. > > > > It's still there (in 2.6.30-gentoo-r1) > > Device Drivers ---> Network Device Support ---> Enable older network device API > compatibility > I mentioned very specific versions, clearly a bit ahead of where gentoo currently is. You can find them on http://www.kernel.org ... Thanks Tomas for the patch (I had come up with the same patch myself ;) - btw I applied the same to 5.10.79 since 5.10.91 drops association and loses packets too easily for me on 2.6.30-git14. Will try again 5.10.91 in later kernels or when I complete the move to Fedora 11 from my current Fedora 10 x86_64 (I'm not trolling, I found this bug while looking into the problems I had and thought I'd post a warning). Keep up the good work.
Just wanted to make a note in case anyone else has trouble: It seems in 2.6.30 vanilla, the only way to build the lib80211_crypt_* modules is to build the hostap driver. The Kconfig doesn't allow these modules to be selected on their own even if lib80211 is selected. I was going crazy trying to get it to work with my WPA access point until I figured this out.
(In reply to comment #54) > > I've tried the broadcom-sta driver but when I load the module and try to watch > > information on the adapter using the command iwconfig this is what I see: > > eth1 IEEE 802.11 Nickname:"" > > Access Point: Not-Associated > > > > when the output should be like this: > > eth1 IEEE 802.11g ESSID:off/any > > Mode:Managed Frequency:2.462 GHz Access Point: Not-Associated > > Bit Rate:54 Mb/s Tx-Power:24 dBm > > RTS thr:2347 B Fragment thr:2346 B > > Power Management:off > > Link Quality:0 Signal level:0 Noise level:0 > > Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0 > > Tx excessive retries:0 Invalid misc:0 Missed beacon:0 > > > > plus, when I try to scan for networks, I get an error saying that the device > > doesn't support scanning > > I wanted to know are these bugs or features not implemented yet? > > > > Aside from the response that Broadcom gave you, I would suggest trying iwconfig > and scanning as root. Both of these functions appear to work perfectly well > when run as root but not when run as a common user. I'm not sure why though. tried it now, scanning is possible via root. is there a fix for scanning via normal user? one more thing, I need /etc/init.d/net.eth1 has root for it to work, so the scanning will occur and if there is a known wireless network in range that is configured in /etc/conf.d/net then a connection will occur, am I right?
(In reply to comment #94) > tried it now, scanning is possible via root. is there a fix for scanning via > normal user? No, that's how iwconfig works. From the iwlist manual: Triggering scanning is a privileged operation (root only) and normal users can only read left-over scan results.
(In reply to comment #95) > (In reply to comment #94) > > tried it now, scanning is possible via root. is there a fix for scanning via > > normal user? > > No, that's how iwconfig works. From the iwlist manual: > Triggering scanning is a privileged operation (root only) and normal users > can only read left-over scan results. > what about my second question? there shouldn't be any problems running my current net config, right?
another question, when I load the driver, knemo (I use kde) shows that the card is connected when there isn't any network, is it a driver issue or can it be resolved by configuration somehow? in essence, I want the card not to assume it is connected when it isn't.
Another heads-up :) Shortly after mainline 2.6.32-git1, the kernel wireless infrastructure has changed and the 5.10.91.9.3 driver will not build anymore. You will need to: 1. replace in the 5.10.91.9.3 sources all occurrences of CONFIG_WIRELESS_EXT with CONFIG_CFG80211_WEXT 2. select *in your kernel* support for some unrelated wireless driver that, via Kconfig, SELECTs CONFIG_WEXT_PRIV - that symbol isn't user-selectable Discussion available here (full thread not yet archived as I write, should appear in its entirety soon): http://lkml.org/lkml/2009/12/12/137
(In reply to comment #98) > Another heads-up :) > > Shortly after mainline 2.6.32-git1, the kernel wireless infrastructure has > changed and the 5.10.91.9.3 driver will not build anymore. > > You will need to: > > 1. replace in the 5.10.91.9.3 sources all occurrences of CONFIG_WIRELESS_EXT > with CONFIG_CFG80211_WEXT > > 2. select *in your kernel* support for some unrelated wireless driver that, > via Kconfig, SELECTs CONFIG_WEXT_PRIV - that symbol isn't user-selectable > > > Discussion available here (full thread not yet archived as I write, should > appear in its entirety soon): > > http://lkml.org/lkml/2009/12/12/137 > e.g. it is a 33 issue, right?
(In reply to comment #99) > e.g. it is a 33 issue, right? This issue will appear in 2.6.33 if you only use release kernels (ie, no -git or -rc sources), yes.
*** Bug 306989 has been marked as a duplicate of this bug. ***
(In reply to comment #100) > (In reply to comment #99) > > > e.g. it is a 33 issue, right? > > This issue will appear in 2.6.33 if you only use release kernels (ie, no -git > or -rc sources), yes. > Any hint of a fix yet?
why not use the latest in portage? I have 2.6.33 and the latest in portage have no problems.
(In reply to comment #103) > why not use the latest in portage? > I have 2.6.33 and the latest in portage have no problems. > I haven't seen an update to my ebuild, and I know it craps out every time. I suppose I can give it another shot and see if it works now. It hasn't since .33 hit.
Yeppers... it craps out with 2.6.33-zen1, or plain old 2.6.33 for me. Here's the error: * Found kernel source directory: * /usr/src/linux * Found kernel object directory: * /lib/modules/2.6.33-zen1/build * Found sources for kernel version: * 2.6.33-zen1 * Checking for suitable kernel configuration options... * CONFIG_WIRELESS_EXT: is not set when it should be. * CONFIG_WEXT_PRIV: is not set when it should be. * Please check to make sure these options are set correctly. * Failure to do so may cause unexpected problems. * Once you have satisfied these options, please try merging * this package again. * ERROR: net-wireless/broadcom-sta-5.60.48.36 failed: * Incorrect kernel configuration options I'd say that's a fairly cut and dried kind of issue.
(In reply to comment #105) > Yeppers... it craps out with 2.6.33-zen1, or plain old 2.6.33 for me. Here's > the error: > > * Checking for suitable kernel configuration options... > * CONFIG_WIRELESS_EXT: is not set when it should be. > * CONFIG_WEXT_PRIV: is not set when it should be. > * Please check to make sure these options are set correctly. > * Failure to do so may cause unexpected problems. > * Once you have satisfied these options, please try merging > * this package again. > * ERROR: net-wireless/broadcom-sta-5.60.48.36 failed: > * Incorrect kernel configuration options Yep, you haven't set up your kernel correctly. The ebuild can't do that, you have to.
(In reply to comment #106) > (In reply to comment #105) > > Yeppers... it craps out with 2.6.33-zen1, or plain old 2.6.33 for me. Here's > > the error: > > > > * Checking for suitable kernel configuration options... > > * CONFIG_WIRELESS_EXT: is not set when it should be. > > * CONFIG_WEXT_PRIV: is not set when it should be. > > * Please check to make sure these options are set correctly. > > * Failure to do so may cause unexpected problems. > > * Once you have satisfied these options, please try merging > > * this package again. > > * ERROR: net-wireless/broadcom-sta-5.60.48.36 failed: > > * Incorrect kernel configuration options > > Yep, you haven't set up your kernel correctly. The ebuild can't do that, you > have to. > Really? Show me where these settings exist. # CONFIG_NET_PKTGEN is not set # CONFIG_HAMRADIO is not set # CONFIG_CAN is not set # CONFIG_IRDA is not set # CONFIG_BT is not set # CONFIG_AF_RXRPC is not set CONFIG_WIRELESS=y CONFIG_WEXT_CORE=y CONFIG_WEXT_PROC=y CONFIG_CFG80211=y # CONFIG_NL80211_TESTMODE is not set # CONFIG_CFG80211_DEVELOPER_WARNINGS is not set # CONFIG_CFG80211_REG_DEBUG is not set # CONFIG_CFG80211_DEFAULT_PS is not set # CONFIG_CFG80211_DEBUGFS is not set CONFIG_WIRELESS_OLD_REGULATORY=y CONFIG_CFG80211_WEXT=y CONFIG_WIRELESS_EXT_SYSFS=y CONFIG_LIB80211=y # CONFIG_LIB80211_DEBUG is not set # CONFIG_MAC80211 is not set # CONFIG_WIMAX is not set # CONFIG_RFKILL is not set # CONFIG_NET_9P is not set As far as I can tell, I have what I need set up. I see no options for the settings that are causing the issues. If you can tell where these settings hide, please do. I'd really like to be able to use the broadcom-sta with .33.
(In reply to comment #107) > As far as I can tell, I have what I need set up. I see no options for the > settings that are causing the issues. If you can tell where these settings > hide, please do. I'd really like to be able to use the broadcom-sta with .33. I don't know about how Gentoo implemented the solution - but please have a look at my description of the issue at comment #98 (maybe you just need to select another wireless driver in addition to the broadcom-sta as I did when I logged my heads-up to this bug).
(In reply to comment #107) > (In reply to comment #106) > > (In reply to comment #105) > > > Yeppers... it craps out with 2.6.33-zen1, or plain old 2.6.33 for me. Here's > > > the error: > > > > > > * Checking for suitable kernel configuration options... > > > * CONFIG_WIRELESS_EXT: is not set when it should be. > > > * CONFIG_WEXT_PRIV: is not set when it should be. > > > * Please check to make sure these options are set correctly. > > > * Failure to do so may cause unexpected problems. > > > * Once you have satisfied these options, please try merging > > > * this package again. > > > * ERROR: net-wireless/broadcom-sta-5.60.48.36 failed: > > > * Incorrect kernel configuration options > > > > Yep, you haven't set up your kernel correctly. The ebuild can't do that, you > > have to. > > > > Really? Show me where these settings exist. > > # CONFIG_NET_PKTGEN is not set > # CONFIG_HAMRADIO is not set > # CONFIG_CAN is not set > # CONFIG_IRDA is not set > # CONFIG_BT is not set > # CONFIG_AF_RXRPC is not set > CONFIG_WIRELESS=y > CONFIG_WEXT_CORE=y > CONFIG_WEXT_PROC=y > CONFIG_CFG80211=y > # CONFIG_NL80211_TESTMODE is not set > # CONFIG_CFG80211_DEVELOPER_WARNINGS is not set > # CONFIG_CFG80211_REG_DEBUG is not set > # CONFIG_CFG80211_DEFAULT_PS is not set > # CONFIG_CFG80211_DEBUGFS is not set > CONFIG_WIRELESS_OLD_REGULATORY=y > CONFIG_CFG80211_WEXT=y > CONFIG_WIRELESS_EXT_SYSFS=y > CONFIG_LIB80211=y > # CONFIG_LIB80211_DEBUG is not set > # CONFIG_MAC80211 is not set > # CONFIG_WIMAX is not set > # CONFIG_RFKILL is not set > # CONFIG_NET_9P is not set > > As far as I can tell, I have what I need set up. I see no options for the > settings that are causing the issues. If you can tell where these settings > hide, please do. I'd really like to be able to use the broadcom-sta with .33. > you need to findout what is blocking it, run make menuconfig, hit the / key, search for the relevant config and look at its depends
(In reply to comment #109) > (In reply to comment #107) > > (In reply to comment #106) > > > (In reply to comment #105) > > > > Yeppers... it craps out with 2.6.33-zen1, or plain old 2.6.33 for me. Here's > > > > the error: > > > > > > > > * Checking for suitable kernel configuration options... > > > > * CONFIG_WIRELESS_EXT: is not set when it should be. > > > > * CONFIG_WEXT_PRIV: is not set when it should be. > > > > * Please check to make sure these options are set correctly. > > > > * Failure to do so may cause unexpected problems. > > > > * Once you have satisfied these options, please try merging > > > > * this package again. > > > > * ERROR: net-wireless/broadcom-sta-5.60.48.36 failed: > > > > * Incorrect kernel configuration options > > > > > > Yep, you haven't set up your kernel correctly. The ebuild can't do that, you > > > have to. > > > > > > > Really? Show me where these settings exist. > > > > # CONFIG_NET_PKTGEN is not set > > # CONFIG_HAMRADIO is not set > > # CONFIG_CAN is not set > > # CONFIG_IRDA is not set > > # CONFIG_BT is not set > > # CONFIG_AF_RXRPC is not set > > CONFIG_WIRELESS=y > > CONFIG_WEXT_CORE=y > > CONFIG_WEXT_PROC=y > > CONFIG_CFG80211=y > > # CONFIG_NL80211_TESTMODE is not set > > # CONFIG_CFG80211_DEVELOPER_WARNINGS is not set > > # CONFIG_CFG80211_REG_DEBUG is not set > > # CONFIG_CFG80211_DEFAULT_PS is not set > > # CONFIG_CFG80211_DEBUGFS is not set > > CONFIG_WIRELESS_OLD_REGULATORY=y > > CONFIG_CFG80211_WEXT=y > > CONFIG_WIRELESS_EXT_SYSFS=y > > CONFIG_LIB80211=y > > # CONFIG_LIB80211_DEBUG is not set > > # CONFIG_MAC80211 is not set > > # CONFIG_WIMAX is not set > > # CONFIG_RFKILL is not set > > # CONFIG_NET_9P is not set > > > > As far as I can tell, I have what I need set up. I see no options for the > > settings that are causing the issues. If you can tell where these settings > > hide, please do. I'd really like to be able to use the broadcom-sta with .33. > > > > you need to findout what is blocking it, run make menuconfig, hit the / key, > search for the relevant config and look at its depends > Or I could just say, "screw it" and go for the b43. Since it is clear that the symbols the ebuild are looking for are symbols that don't exist, or that have to be fixed to point to the right option, as per the article listed a few places above this one, I'm not going to mess with this anymore. Since I can run the b43 with one kernel, and broadcom-sta with the kernels that will allow it to work, I don't need to pull my hair out trying to find symbols that don't exist. And I'm not going to, either. B43 works...hurray! Broadcom-sta, not so much...no great loss as far as I can see.
*** Bug 320483 has been marked as a duplicate of this bug. ***
Usual heads-up :) Somewhere between 2.6.34-git4 and 2.6.34-git8 (and hence something Gentoo will see in 2.6.35), there have been changes in the netdev area which make 5.60.48.36 broadcom-sta unbuildable again. I'm attaching what I used to make it compile (and work, as I'm typing from a 2.6.34-git8 with my patched broadcom-sta driver) - it might be the right thing, or it might not, I tried to mimic changes made in other wireless drivers... WorksForMe anyway, maybe people with better understanding of the netdev changes will be able to come up with a more appropriate fix. Note - my #if LINUX_VERSION_CODE has < 2.6.34; it should really be <= 2.6.34, because changes will see the light in 2.6.35 - but if I did that, 2.6.34-git8 would still try to build with older code and fail. Cheers, --alessandro
Created attachment 232555 [details, diff] replace mc_list handling with netdev_for_each_mc_addr
Was able to emerge net-wireless/broadcom-sta-5.60.48.36 against 2.6.34-gentoo, Funtoo testing.
(In reply to comment #114) > Was able to emerge net-wireless/broadcom-sta-5.60.48.36 against 2.6.34-gentoo, > Funtoo testing. > Same here. Gentoo 'almost' stable :) The kernel modul works fine.
(In reply to comment #114) > Was able to emerge net-wireless/broadcom-sta-5.60.48.36 against 2.6.34-gentoo, > Funtoo testing. Similar results with net-wireless/broadcom-sta-5.60.48.36-r1. Perhaps the ebuild msg should be changed since, for me, it is not CONFIG_CFG80211_WEXT that needs to be set but CONFIG_WIRELESS_EXT. The same workaround (setting PRISM54) worked.
Dear all, i'm currently try to upgrade from kernel 2.6.39-gentoo (where sta works fine) to 2.6.39-gentoo-r3 or 3.0.0-gentoo. broadcom-sta get's build fine as usual - but if i load wl i did not get any dmesg output nor device to see anymore. Tried original broadcom-sta sources from broadcom too (incl. patch) which gives the same effect. Hardware is a MacBookPro 6,1 with a lspci: 03:00.0 Network controller: Broadcom Corporation BCM43224 802.11a/b/g/n (rev 01) which usually loads under older kernels as: [ 64.000758] wl 0000:03:00.0: PCI INT A disabled [ 69.121343] wl 0000:03:00.0: PCI INT A -> GSI 17 (level, low) -> IRQ 17 [ 69.121354] wl 0000:03:00.0: setting latency timer to 64 [ 69.245802] wl 0000:03:00.0: eth1: Features changed: 0x00004800 -> 0x00004000 [ 69.250017] eth1: Broadcom BCM4353 802.11 Hybrid Wireless Controller 5.100.82.38 If i boot older kernels with the former broadcom-sta installed the device gets loaded as usual for me. Any idea? many thanks for your time. cheers, Niels. http://www.syndicat.com
