Bug 8930

Can you please remove all wl packages and try with open source modulse (bcma). To make bcma work you have to remove/blacklist non-free modules.

If bcma still fails to load then attach your lsmod output and dmesg output as well.

CC: (none) => sander.lepik

Created attachment 3468 [details]
lsmod output

Created attachment 3469 [details]
dmesg output

I blacklisted the wl and ssb modules, but the bcma module was not recognized (no module was associated with the device).

What happens if you load bcma manually with "modprobe bcma" - anything interesting in dmesg after that?

Nothing in dmesg.

Still reported in mcc/harddrake2 as "unknown".

http://linuxwireless.org/en/users/Drivers/brcm80211#Supported_Chips hmm, yeah, it doesn't seem to be supported by open source driver.

Hardware: x86_64 => All
Assignee: bugsquad => tmb

It worked in Mandriva 2010.2 and Mageia 2.

Can you attach the output of lspcidrake -v?
I suspec the issue is in /usr/lib/libDrakX/network/connection/ethernet.pm
where it failed to map to the correct interface

Keywords: (none) => NEEDINFO
CC: (none) => thierry.vignaud

Created attachment 3542 [details]
output of lspcidrake -v

output of lspcidrake -v as requested

The IDs do not match those you put in your first message (0x5348, 0x17173 vs 0x14e4, 0x4315), but they obviously are the same in decimal with hexa prefix: 17173 == 0x4315 and 5348=0x14e4
Please do not mix decimal and hexadecimal...

But it's definitively a side effect of the wl change by Thomas...

Priority: Normal => release_blocker
Source RPM: drakx-net-1.18-1.mga3.src.rpm => kernel
Severity: normal => critical

The only reference in upstream kernel seems to be:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=drivers/ssb/b43_pci_bridge.c#l26

http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=61e115a56d1aafd6e6a8a9fee8ac099a6128ac7b :
"SSB is an SoC bus used in a number of embedded devices.  The most
well-known of these devices is probably the Linksys WRT54G, but there
are others as well.  The bus is also used internally on the BCM43xx
and BCM44xx devices from Broadcom."

@Hoyt: can you try loading both ssb & b43?
or even better, all of: ssb b43 b44 b43legacy
From you dmesg output, it wasn't loaded (you should not blacklist it for now)
Could you then attach (not paste) the result of "ls /sys/bus" (and the listing of ssb/ if there's such a subdirectory)

@Thomas: Does this mean we should load _both_ ssb and b43 for such devices (and not just pci/usb/dmi)?

Should we detect devices on some SSB bus for those:
/lib/modules/3.8.0-desktop-2.mga3/modules.alias:alias ssb:v4243id0806rev* b44
/lib/modules/3.8.0-desktop-2.mga3/modules.alias:alias ssb:v4243id0812rev10* b43
/lib/modules/3.8.0-desktop-2.mga3/modules.alias:alias ssb:v4243id0812rev0F* b43
/lib/modules/3.8.0-desktop-2.mga3/modules.alias:alias ssb:v4243id0812rev0D* b43
/lib/modules/3.8.0-desktop-2.mga3/modules.alias:alias ssb:v4243id0812rev0C* b43
/lib/modules/3.8.0-desktop-2.mga3/modules.alias:alias ssb:v4243id0812rev0B* b43
/lib/modules/3.8.0-desktop-2.mga3/modules.alias:alias ssb:v4243id0812rev0A* b43
/lib/modules/3.8.0-desktop-2.mga3/modules.alias:alias ssb:v4243id0812rev09* b43
/lib/modules/3.8.0-desktop-2.mga3/modules.alias:alias ssb:v4243id0812rev07* b43
/lib/modules/3.8.0-desktop-2.mga3/modules.alias:alias ssb:v4243id0812rev06* b43
/lib/modules/3.8.0-desktop-2.mga3/modules.alias:alias ssb:v4243id0812rev05* b43
/lib/modules/3.8.0-desktop-2.mga3/modules.alias:alias ssb:v4243id0812rev04* b43legacy
/lib/modules/3.8.0-desktop-2.mga3/modules.alias:alias ssb:v4243id0812rev02* b43legacy
/lib/modules/3.8.0-desktop-2.mga3/modules.alias:alias ssb:v4243id0819rev* ssb_hcd
/lib/modules/3.8.0-desktop-2.mga3/modules.alias:alias ssb:v4243id0817rev* ssb_hcd
/lib/modules/3.8.0-desktop-2.mga3/modules.alias:alias ssb:v4243id0808rev* ssb_hcd

Source RPM: kernel => kernel, ldetect

(In reply to Thierry Vignaud from comment #11)
> The IDs do not match those you put in your first message (0x5348, 0x17173 vs
> 0x14e4, 0x4315), but they obviously are the same in decimal with hexa
> prefix: 17173 == 0x4315 and 5348=0x14e4
> Please do not mix decimal and hexadecimal...
> 

Then that is a bug in one of the tools, whichever one reported the UIDs in decimal. I merely redirected the output of the tools to a text file or copied them directly from the screen.

(In reply to Thierry Vignaud from comment #11)
> The IDs do not match those you put in your first message (0x5348, 0x17173 vs
> 0x14e4, 0x4315), but they obviously are the same in decimal with hexa
> prefix: 17173 == 0x4315 and 5348=0x14e4
> Please do not mix decimal and hexadecimal...
> 

Then that is a bug in one of the tools, whichever one reported the IDs in decimal. I merely redirected the output of the tools to a text file or copied them directly from the screen.

I have a BCM4313 and I can't configure it with the closed driver (same error message as original post) while it use to work in mageia 2. If I remove all the broadcom-wl packages, I can configure it using the free driver however performance is a bit slower so I'd rather use the closed driver. Why are the current broadcom-wl packages not working?

CC: (none) => philippe.l

Created attachment 3577 [details]
output of  ls /sys/bus as requested after loading all modules

Created attachment 3578 [details]
output of ls /sys/bus/ssb as requested

Ok interesting tidbit. I've kept messing around with this and was able to get it to work. I tried unloading all the free modules (that is bcma, brcmsmac, mac80211, ssb, b43). I started the network configuration tool in MCC, and selected the Broadcom Corporation BCM4313... This prompted the installation of the broadcom-wl packages since I had removed them previously. 

As before, the error message that the interface wasn't found using the wl driver. I cancelled the networking configuration tool, and I looked at /etc/modprobe.d/broadcom-wl-blacklist.conf and made sure all free modules were blacklisted. I figured maybe the wl driver needed to be loaded on a freshly booted kernel when no free modules were present.

Upon login in, I checked network manager and lo and behold, access points were showing up. I connected to my network and everything works fine. So I went back to MCC, and launched the tool that allows you to remove configured network, and saw that a new network interface called ethernet(Auto_freyja) was created (freyja is the SSID of my network). Somehow, the interface auto configured itself on rebooting and allowed me to connect even though I was unabled to complete the network configuration in MCC. This is unexpected, but I'll take it.

I looked at dmesg and saw this line
[   15.102644] eth0: Broadcom BCM4727 802.11 Hybrid Wireless Controller 5.100.82.112

It seems like some interface is picked up by the wl driver, but I don't recognize it and yet it works anyway. There's some odd behavior going on.

perhaps the changes related to broadcom drivers, fixed this issue.

can you retest with the mageia 3 RC?

CC: (none) => alien

No. It still does not detect the  Broadcom device for me. I had to use ndiswrapper and it works fine.

i guess we might have to bite the bullet and put on the errata that ndiswrapper is to be used for this chipset...

(In reply to AL13N from comment #21)
> i guess we might have to bite the bullet and put on the errata that
> ndiswrapper is to be used for this chipset...

Really?! This is regression we are talking about here. The broadcom-wl driver should work. User doesn't have to use ndiswrapper in this case. Only because drakx tools can't detect hardware properly?

Those bugs need to be fixed not be written into some bogus errata..

the way i read it, it was the closed source driver not working as it should... but i can have read this wrong.

It's drakconnect that fails to work properly. It was working just fine in Mageia 2. During Mageia 3 betas most chips supported by broadcom-wl driver had the same error message. Thomas fixed some of those bugs but he needs some more time.

Speaking as a user, as a temporary work-around, using ndiswrapper could be tolerated as long as the problem with drakconnect is being worked on and it is disclosed in the errata. I used the WindowsXP driver supplied by the hardware manufacturer (HP). Yes, it's a annoyance and some extra twiddling and yes, it's using the hated Microsoft-related product, but the goal it to get it to work for the user and not block the release of Mageia3.

IIRC, wasn't this problem started by attempting to have drakconnect prefer the FOSS driver over the binary blob? There' some irony in that.

@Sander: the way i understood it, is that tmb decided to give the new unified driver a whirl, but it seemed that too many chipsets has issues with it, and that he reverted to the old system...

i figured this particular driver had some kind of regression...

(In reply to AL13N from comment #26)
> i figured this particular driver had some kind of regression...

Did you read at least the comments from this bug? Not to mention other release critical bugs about broadcom chips. This is WIP.

Hoyt, can you test with the latest liveCD that Thomas created to debug broadcom problems: http://distrib-coffee.ipsl.jussieu.fr/pub/linux/Mageia/people/tmb/mga3-wl-test/

Do you get better results with this liveCD?

Seems people are in a rush to close bugs just to hit estimated release date...

The estimated release date is not the deciding factor, the quality is.

As Sander stated this is still WIP, and there will be another test iso soon with more changes to try and get this working better OOB.

(In reply to Sander Lepik from comment #27)

> 
> Do you get better results with this liveCD?

Same results: drakconnect did not detect the device.

Could you also attach the output of "ls /sys/bus/ssb/devices" and "ls /sys/bus/ssb/drivers"

Created attachment 3796 [details]
ls /sys/bus/ssb/devices

Created attachment 3797 [details]
ls /sys/bus/ssb/drivers

Could you also attach the output of "ls -l /sys/bus/ssb/devices/*/" ?

Created attachment 3803 [details]
s/ssb/b4[34]/ in pcitable

one fix would be to replace ssb by b43 or b44 in pcitable (by adding entries in order to override the default modalias).
The issue is: I'm not sure how to map SSB IDs to PCI IDs.

Another way would be to add a ssb_probe along (pci|dmi|usb[hid)_probe in ldetect

Last but not least, this could be fixed (but only in Mageia 4) by using udev to coldplug all devices (like Anacondo now does and like Colin wants to)

BTW what driver was used with Mageia 2?

Created attachment 3804 [details]
recognize ssb as a proper driver

Else we could also list ssb in wireless modules list in list_modules.pm

Can you try this patch? As root in a terminal, just run the following commands:

cd /usr/lib/libDrakX/
patch -p2 --dry-run </tmp/8930-list_modules.diff

Then run drakconnect

(best to actually run the patch afterwards (i.e. take off the --dry-run once you're happy it'll apply OK :))

(In reply to Thierry Vignaud from comment #36)
> Created attachment 3804 [details]
> recognize ssb as a proper driver
> 
> Else we could also list ssb in wireless modules list in list_modules.pm
> 
> Can you try this patch? As root in a terminal, just run the following
> commands:
> 
> cd /usr/lib/libDrakX/
> patch -p2 --dry-run </tmp/8930-list_modules.diff
> 
> Then run drakconnect


I was planning on adding both ssb and bcma to the list on next broadcom test iso

That should help drakconnect recognize the hw I think.

The trouble with hardcoding the ids to b43 is that some is "supported" by b43, but in reality they only work with brcm(s/f)mac

Hm, but showing bcma & ssb will only try to configure them, not the real hw.

the modules have deps from b43/b44/brcm(f/s)mac -> bcma/ssb, but not the other way

I'm going to "hardcode" every driver according to upstream docs and current bugreports  and release a new testiso with that, then we'll know how it works

Created attachment 3806 [details]
ls -l /sys/bus/ssb/devices/*/

(In reply to Thierry Vignaud from comment #36)
> Created attachment 3804 [details]
> recognize ssb as a proper driver
> 
> Else we could also list ssb in wireless modules list in list_modules.pm
> 
> Can you try this patch? As root in a terminal, just run the following
> commands:
> 
> cd /usr/lib/libDrakX/
> patch -p2 --dry-run </tmp/8930-list_modules.diff
> 
> Then run drakconnect

I had to install the patch by hand (no 'patch' on the liveCD).

RESULT: "Unable to find network interface for selected device (using ssb driver)."

(In reply to Hoyt Duff from comment #41)

> 
> I had to install the patch by hand (no 'patch' on the liveCD).
> 

Yep, I noticed that on during testing stuff on RC medias, so I added it to the configs so it will be on official RC and final


> RESULT: "Unable to find network interface for selected device (using ssb
> driver)."

Yeah, that was what I suspected in comment 39.

Stay tuned for test isos that will show up later today...

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)

Hoyt, can you please test with this new test iso?

And if it doesn't show wlan device at first then open MCC -> Hardware -> Browse and configure hardware and check if it wants to install some packages.

Your feedback is really needed, so we can hopefully close this bug.

I have the ISO and will test today

It offers only ndiswrapper as an option.


I tried to use harddrake to check on the devices recognized and it prompted me to install broadcom-ssb-config, which it installed, but still offers ndiswrapper as the only option.

(In reply to Hoyt Duff from comment #46)
> It offers only ndiswrapper as an option.
> 
> 
> I tried to use harddrake to check on the devices recognized and it prompted
> me to install broadcom-ssb-config, which it installed, but still offers
> ndiswrapper as the only option.

Did you try with net_applet or which iso did you use?

(In reply to Sander Lepik from comment #47)
.
> 
> Did you try with net_applet or which iso did you use?

Yes, I tried with net_applet first.

I used an ISO from one of the links found in Comment 43.

(In reply to Hoyt Duff from comment #48)
> Yes, I tried with net_applet first.
> 
> I used an ISO from one of the links found in Comment 43.

Was it Gnome or KDE? Did you reopen net_applet dialog after installing broadcom-ssb-config?

(In reply to Sander Lepik from comment #49)

> 
> Was it Gnome or KDE? Did you reopen net_applet dialog after installing
> broadcom-ssb-config?

It was KDE.

I re-booted and manually installed broadcom-ssb-config and received errors that modules b43legacy, brcmfmac, brcmsmac and wl were not currently loaded.

Running net_applet yields same results as before.

is your card really a bcm4312 ? because I saw some positive result (ie working) 
and maybe we can add something in the errata

seen here https://bugs.mageia.org/show_bug.cgi?id=7828#c52 and below

(In reply to Manuel Hiebel from comment #52)
> seen here https://bugs.mageia.org/show_bug.cgi?id=7828#c52 and below

Doing only

# urpmi broadcom-wl-kernel-desktop586-latest

fixes the problem!

$ lspcidrake -v | grep Broadcom
bcma            : Broadcom Corporation|BCM43224 802.11a/b/g/n [NETWORK_OTHER] (vendor:14e4 device:4353 subv:103c subd:1507) (rev: 01)

(In reply to Hoyt Duff from comment #53)
> (In reply to Manuel Hiebel from comment #52)
> > seen here https://bugs.mageia.org/show_bug.cgi?id=7828#c52 and below
> 
> Doing only
> 
> # urpmi broadcom-wl-kernel-desktop586-latest
> 
> fixes the problem!
> 
> $ lspcidrake -v | grep Broadcom
> bcma            : Broadcom Corporation|BCM43224 802.11a/b/g/n
> [NETWORK_OTHER] (vendor:14e4 device:4353 subv:103c subd:1507) (rev: 01)

I could not copy/paste directly from the Broadcom computer, so I copy/pasted from your output and forgot to change value of BCM43224 to the correct BCm4312, so correct output would be 

$ lspcidrake -v | grep Broadcom
bcma            : Broadcom Corporation|BCM43212 802.11a/b/g/n [NETWORK_OTHER] (vendor:14e4 device:4353 subv:103c subd:1507) (rev: 01)

so mine is a slightly different chip.

But it now works.

Thanks.

drakconnect --add never suggested you to install a broadcom-wl package ?

it must be some rfkill related issue

(accidentally hit send midsentence)

it must be some rfkill related issue, because bcma is the opensource driver and not the wl driver.

Hoyt Duff: when retesting with latest tmb kernel, can you recheck the driver/rfkill status? and do you have dual entries? maybe in rfkill you do? (cause my chip had a weird rfkill issue (on the opensource driver(bcma)) and had 2 wlan0 entries in rfkill.)

(In reply to AL13N from comment #57)
> (accidentally hit send midsentence)
> 
> it must be some rfkill related issue, because bcma is the opensource driver
> and not the wl driver.
> 
> Hoyt Duff: when retesting with latest tmb kernel, can you recheck the
> driver/rfkill status? and do you have dual entries? maybe in rfkill you do?
> (cause my chip had a weird rfkill issue (on the opensource driver(bcma)) and
> had 2 wlan0 entries in rfkill.)

It never did suggest to add broadcom-wl package.

How do I check rfkill status?

BTW, I just did an install from the liveCD and updated all the packages and using  kernel 3.6.12-desktop586-2

Created attachment 3945 [details]
lsmod

rfkill is a command,

i think it's "rfkill list" or something... check the man page

Should I check to see if this bug still applies to Mageia 4 beta1?

CC: (none) => hoyt

Sure

Since there are insufficient details provided in this report for us to investigate the issue further, and we have not received feedback to the information we have requested above, we will assume the problem was not reproducible, or has been fixed in one of the updates we have released for the reporter's distribution.

Users who have experienced this problem are encouraged to upgrade to the latest update of their distribution, and if this issue turns out to still be reproducible in the latest update, please reopen this bug with additional information.

Closing as OLD.

Status: NEW => RESOLVED
CC: (none) => nic
Resolution: (none) => OLD

Actually, the problem is fixed as of Mageia6.

Resolution: OLD => FIXED