Broadcom 4318 and ACPI

[jaggerblade]

Hello there,

I'm about a month into learning Linux (though I've learned a lot) and I recently came over to straight Gentoo (2006.1 with 2.6.17-gentoo-r8 genkernel) from Sabayon in order to streamline things on my Dell Inspiron B130.

Although I got it working under Sabayon, which is Gentoo-based, my Broadcom 4318 is giving me hell under regular Gentoo. I got the bcmwl5.inf driver working under ndiswrapper, but since I emerged bcm43xx-fwcutter and created /lib/firmware to put the *.fw files in, both the bcmwl5 and the bcmwl5a (which I used to make it work in Sabayon) show up as invalid drivers.

iwconfig shows the card (eth1) as if it is not connected (ESSID="off/any") and iwlist says it doesn't support scanning (which is a sign of a bad driver). ndiswrapper -l actually says "Invalid driver!" instead of "driver present, hardware present" as it did before I installed firmware. Also might be worth noting that even when I got it working before, I've never gotten it to show up as wlan0.

Secondly for acpi... My /proc/acpi directory is very thin. It has no directories (not empty directories... just none) for processor, battery, etc., and various boot options in grub (acpi=on, off, force...) that I've found in other forums have done nothing. My motherboard does a little bit of acpi stuff by default, but I'd like to assign runlevel 0 to a press of the power button or a lid-close (both of which currently do nothing; lid-close causes a system hang in a suspended state). More importantly, without battery information in the proc pseudo-filesystem, I can't tell how long before my laptop just shuts off.

Thanks in advance for the help, and please be specific. After a month of learning and reading the Wikis and forums this is the first time I've ever had to actually ask a question on a forum. Chances are that if you post a link to a man-page or another forum, I've already seen it, tried it, and got the t-shirt.

[Big Jim Slade]

If you are using ndiswrapper, you do not need the firmware. The firmware is needed if you are using the native kernel driver for the bcm43xx, but the native driver is more difficult to setup. I would suggest unmerging the firmware and then re-install the driver (might not be necessary, but as a precaution) and see if the device works again.

And, it doesn't need to show up as wlan0 for any reason that I know of. It should show up as eth0 or eth1 and you should be fine. Is there a reason it needs to be wlan0 as opposed to eth0?

Now, as for the ACPI stuff, I know you've stated you've read everything, but have you read through the Power Management Guide for setting up ACPI events?

I lack some knowledge of ACPI, but that guide will help you set up some things at least. My lid switch works to some extent, in that it turns off the display, but I'm not sure where it's getting that event from. Tailing the acpid log doesn't produce an event, but somewhere it's working...

[jaggerblade]

Thanks for your reply.

RE: don't need the firmware.

I had the driver installed (successfully) using ndiswrapper and it was still complaining about not being able to find bcm43xx.microcode.fw during boot. I had to install it to get it to work before. It also suggests on the gentoo-wiki that you need both the .inf and the .sys - the .sys has the firmware in it.

RE: wlan0

modprobe wlan0 and alias wlan0 ndiswrapper; I've read on several forums where people have suggested that once ndiswrapper is properly configured that the wireless interface will show up in iwconfig as wlan0. As that's never been the case for me, I thought maybe I had used ndiswrapper incorrectly.

RE: ACPI

In fact, I have read that, and I have acpi emerged. The problem is that program only makes use of the information contained in the /proc directly which on my system isn't being correctly populated.

<edit to prevent double-post>

Actually, your post gave me an idea, though. I tried getting rid of the firmware and playing with ndiswrapper again to no avail. If you're right about ndiswrapper not wanting the firmware, though, then it's possible that genkernel is wanting to use the native kernel driver, since I'm using 2.6.17. I should probably find the name of it and blacklist it to see if that does any good.