Created attachment 2385 [details] Output of 'lspci -vnn' The current entry causes following issues: 1. lscpidrake incorrectly states 'wl' as being used, although 'brcmsmac' was sucessfully loaded, assuming you've 'kernel-firmware-nonfree' installed. 2. drak-tools like drakroam and draknetcenter create an entry titled 'Broadcom Corporation|BCM4313 802.11b/g/n Wireless LAN Controller', which will pull in 'wl' whenever you click on it, although wlan0 is up and running with 'brcmsmac'. Therefore I would like to propose that the pcitable entry for 14e4:4727 is changed from 'wl' to 'bcma' to match the mappings that were automaically added to /etc/modprobe.conf. The kernel driver is working flawlessly so I do not see any reason to pull in a nonfree proprietary driver. See lspci.sb and modprobe.sb.conf for details.
Created attachment 2386 [details] /etc/modprobe.conf
CC: (none) => thinksteve
CC: thinksteve => (none)
CC: (none) => mageia, thierry.vignaud
What happens if we just remove that line instead?
CC: (none) => tmbDepends on: (none) => 2266
Blino, Thomas, what should we do? Rely on in kernel bcma for these devices or on external wl? Stefan, please answer above question? Also do you know what driver other distros use on your machine? (You can try a livecd)
Keywords: (none) => NEEDINFO
> What happens if we just remove that line instead? When removing the line bcma stack is being used. The duplicated entry is not showing up in draknetcenter, and installation of 'wl' will not be suggested. In case this is reproducible on other machines, this is definitely a possible solution. > Also do you know what driver other distros use on your machine? Current releases of Debian, Fedora and openSUSE are using the bcma stack. As far as I know, they don't rely on ldetect-lst when choosing an appropriate driver.
Fixed in git though I would like an answer from Thomas about other wl entries...
Status: NEW => ASSIGNED
Assignee: bugsquad => tmb
Created attachment 3830 [details] Output of 'lspci -vnn'
Attachment 2385 is obsolete: 0 => 1
Created attachment 3831 [details] /etc/modprobe.conf
Attachment 2386 is obsolete: 0 => 1
Attachment 3831 mime type: application/octet-stream => text/plain
Attachment 3830 mime type: application/octet-stream => text/plain
brcmsmac is now being used in Mageia 3 RC 1. wlan0 is showing up and is operational. Unfortunally drak-tools still create an entry titled 'Broadcom Corporation|BCM4313 802.11b/g/n Wireless LAN Controller' which mutters 'Unable to find network interface for selected device (using brcmsmac driver)' on selection. It disappears when removing the corresponding line from pcitable and 90default.lst. Making an educated guess I would say that there is an issue with mapping devices from modprobe.conf and ldetect-lst. No guarantee here, as I didn't skim through the code.
Seems to be similar issue that I had with another Broadcom device (https://bugs.mageia.org/show_bug.cgi?id=7828#c45).
Keywords: NEEDINFO => (none)CC: (none) => sander.lepik
There is now new sets of isos to test broadcom wireless configuration And to make it more fun... there is now 4 isos so you can test on both i586 & x86_64 and with both Gnome and KDE4. NOTE! the isos have "CD" in their name, but most of them are bigger than 700M so you need a DVD media if you want to burn them, otherwise I suggest to use a usb stick to boot from, using: dd if=name_of_iso of=/path/to/usb/stick bs=1M And to find the isos: http://mirrors.kernel.org/mageia/people/tmb/mga3-wl-test/ http://ftp.acc.umu.se/mirror/mageia/people/tmb/mga3-wl-test/ http://distrib-coffee.ipsl.jussieu.fr/pub/linux/Mageia/people/tmb/mga3-wl-test/ (and soon on any mirror carrying mageia people/tmb/mga3-wl-test/ tree)
I've just built a fresh install for a laptop with a BCM4313 14e4:4727 device, and when I boot the new system, the wireless device cannot be seen. I checked lsmod and none of wl, b43, b43legacy, bcma, brcm* are loaded. If I manually modprobe wl, NetworkManager sees the device and initializaes it with no problem. I see an entry in broadcom-wl-alias for this device, but for whatever reason neither NM nor drakconnect loads wl automatically (or anything else). Upon testing a bit, I find that /etc/modprobe.d/broadcom-bcma-blacklist.conf has a "blacklist wl" entry, and broadcom-wl-blacklist.conf blacklists everything else, so I guess that's the cause of this. If I comment out the "blacklist wl", the wireless comes up just fine. lspcidrake -v shows that wl is the driver for this chip, which is confusing because the previous comments here (including the request of the OP) seem to suggest that things were changed not to use wl. Like the OP, my chip works with both brcmsmac and wl. In any case, loading nothing doesn't seem to be a promising approach.
CC: (none) => ftg
Something went wrong on your system install then... broadcom-bcma-config (that has broadcom-bcma-blacklist.conf) conflicts with broadcom-wl-common (wich has broadcom-wl-blacklist.conf) so they should not be on the system at the same time. It's done that way in order to blacklist conflicting drivers so the one you want can load.
I think I see what happened. Part of my post-install is to take an rpm -qa list of the packages installed on the prior system and feed it to urpmi with xargs to bring the system up to the same level as before. That list contains the wl packages, and for historical reasons the urpmi is done with --force. So the install must have installed the bcma stuff, and then I jammed the wl stuff in on top of it. I'll have to get rid of the --force and see if it's still needed. Sorry for the noise.
Thomas Backlund wrote: > There is now new sets of isos to test broadcom wireless > configuration[...] Issue from comment #8 has been resolved in latest test live media and should be included in current release. Thank you for your efforts.
Status: ASSIGNED => RESOLVEDResolution: (none) => FIXED