Kernel compiling, Broadcom wl.ko module & you

[Deb-fan]

Since there isn't an I majorly FACEPALMED myself section in the forums, putting this here. On the off-chance that anyone else is dorkish or unfortunate enough to do what I did and somehow miraculously finds this post on the internet. Here goes ... the wl.ko kernel module applies to plenty of Broadcom wireless chips.

Just got done a few hours ago compiling a 4.19 vanilla kernel. Why would I say that ? Geek cred dang it, geek cred. Very pleased with the outcome. Had done the 4.19 just a month 1/2 or so ago and had what I considered a very nice kern running, with one lil naggling problem. I couldn't get my <expletive, more expletives + more here> Broadcom Limited BCM4312 802.11b/g wireless chipset to be recognized. Reason ? I had built cfg80211 into the actual kernel, thus broadcom-sta-dkms (dkms) wouldn't touch the thing. Even tried building the <expletive> wl.ko module with broadcom-sta-source and module assistant ... NOPE !!! Thought about reverting back to the b43.ko module, which actually works with this wifi but isn't the right one.

Put it on the to-do list till now. Finally got around to really dorking with it (read: It was driving me nuts) and digging around, noticed references to cfg80211 scattered around the operating system associated with dkms and/or module assistant and by pure luck while looking around in the .config options I'm using, noticed I had it set to be built in vs as a module. Set it to compile as a module in the .config file this time around, crossed fingers and wham, almost 3 hours of friggin compile time later wound up with handy linux-image and linux-header .deb(s) Installed them, grabbed latest broadcom-sta-dkms package from Buster, installed the sucker and WHAMO, wireless showing up and working fine, FINALLY !!! Also finally consigned/purged the other 4.19 kernel to the darkest circles of cyber-HEEL, where it belongs. YAY, go me !!!

There's an addendum to this too. Actually don't even know if this is true/valid I had already set the following config option to =n (not set) in the .config file I used but came across it while trying to sort out why broadcom-sta etc wasn't working and wouldn't build. For people who custom compile their kernels and also are afflicted with Broadcom wifi and need the wl.ko module to get it working. During the process of setting kernel config options (ie: make menuconfig) there's a selection under the Kernel Hacking category named CONFIG_DEBUG_LOCK_ALLOC which supposedly a person needs to unset, don't answer =y (clear/destroy this option) Otherwise again supposedly this often results in an "unknown symbol" error when attempting to build/install the $&$)#E^E^ wl.ko module.

Ahhhh, I feel better .... DIE BROADCOM, DIE, DIE wl.ko, DIE !!!! Now I feel better.

[Wheelerof4te]

Heh, it was a fun read. I have one of those buggers, so I feel your pain.

Code: Select all

Network controller: Broadcom Limited BCM43142 802.11b/g/n (rev 01)
	Subsystem: Hewlett-Packard Company BCM43142 802.11b/g/n
	Kernel driver in use: wl
	Kernel modules: bcma, wl

However, I don't know why would you compile 4.19 kernel, unless you're running Stretch. Even then, it would be much faster and safer just to install the backported kernel.
Now, here's a real challenge: compile the latest stable kernel, and get it to work with your Broadcom chip. Or better, don't and save yourself some hair

[stevepusser]

The broadcom-sta driver regularly needs patching for newer kernels in order to build. I had to patch the MX test repo version for it to build on the 5.1 kernel, but haven't tested it on 5.2 or checked to see it Debian has also added the patches...

If your kernel is taking three hours to build, and you have some cores sitting there the whole time doing nothing, you can pass the "-jX" flag to speed up the build, where the "X" = number of cores to devote to the job. Watch out if your machine has any cooling issues, since this will stress that system to the limit!

[Wheelerof4te]

Code: Select all

scripts/config --disable DEBUG_INFO

can also save a lot of time, since you don't really need debugging features if you're an ordinary user.

[Deb-fan]

Hey thanks fellas, some really useful tips. Wheelerof4te, gotta love these Broadcom chips. Thinking about getting I luv Broadcom tattooed on my chest.

Dang sure going to visit your repo @Stevep. Now I know where to go next time the kernel bug bites me. Yeah this is an ancient laptop, 10yrs old dual-core. Was top of the line in it's day and actually the thing still isn't a slouch. Dell inspiron 1545. Feel bad even putting it through that but for whatever reason taken to custom compiling kernels last several years. There's some config's that someone just doesn't get to dork with otherwise and I did use -j3 on the poor thing. Also jmo, if anything best to get the source from Debian and then just simply recompile the thing with it's .config file as a basis to start tweaking with. Or as @Wheeler notes, save yaself the pain. Really isn't much to be gained out of going through all the hassle. Never really got much by way of performance improvements out a the MASSIVE amount of time invested in it.

Really was for the sake of trying to learn about the topic. Plus I get the geek cred, errrr well if wasting literally months of someone's life dorking around with the kernel deserves geek cred. The 4.19 thing is mostly a fluke, it's the source code I had onhand and it kept staring at me. Read the 4.20 was going to have 300k new lines of code in it. Plus one of the goals here was to actually compile out some Spectre and Meltdown mitigates. Now everytime I boot that kernel I get a nice was "not compiled with retpoline, no Spectre v2 mitigation for you mister!! I KNOW, I spent hours compiling the dang thing w/o ratpoline !!! Again thanks guys, this thread could actually help some of us poor folks coping with BWS = Broadcom wireless syndrome.

[trinidad]

Nice work. Fun post. The first time I had to deal with an obscure BCM card and chip was some years back, Deb 7 I think. There was no particular firmware available from Debian that would work. I had to add RPM functionality and build from the RHEL maintained broadcom files where you had to match OEM board, cpu, and card IDs to get the correct files. I have no machines equipped with broadcom... anymore, not even Windows.

TC

[Deb-fan]

^Woah and I thought I was having it rough. Cool thanks for sharing that experience though. In 8 or so years this is the first time I've run up against a problem child component. Need to count my blessings esp compared to what you went through. Plus paid $90 bucks for this laptop from some old guy on Craigslist. Would buy another like it in a heartbeat.

Really can't even hang this one on Broadcom. Since I shot myself in the foot. Gonna partly blame them anyway. Even if it's like suing Smith & Wesson. One of the joys of compiling Kerns. Sometimes forget what configs were fiddled with. Like I've compiled out support for a bunch of filesystems, ext2/3/xfs/ntfs etc. Sometime in the future could turn around and want to use one. May have no idea why I'm following instructions to the letter for a project and it's failing.

Note2self: Be sure to look through the kernels config file occasionally.

[Wheelerof4te]

Broadcom woes aside, I think compiling a kernel became a bit more difficult on Buster. I don't remember having to disable certificate/keyring/module signing thingy in config just to build a damn kernel. On Stretch it was simple:
1. Download kernel source from kernel.org, extract it somewhere.
2. cd to extracted folder.
3. cp -v /boot/config-randomkernel .config
4. scripts/config --disable DEBUG_INFO
5. [optional] make oldconfig
6. make bindeb-pkg -j3
7. Install the linux-headers and linux-image .debs

On the bright side, my hardware is fully recognized in Buster, so there's no need to compile anymore (except for higher version numbers cred).

[Deb-fan]

^ Think they do it just to screw with people.

Think this is cool. Gotta give it a try.

scripts/config --disable DEBUG_INFO

Seen all kinds of weirdness. Having to edit a file on the Os and add a maintainers name + fake email address. Remember having to comment out lines in files in the build directory and one time had to create an empty file in it called REPORT_BUGS or similar. Actually this time around was shockingly easy, used the config file from a custom 4.14-4, make oldconfig and just held down the return key while it ran through all the new config options. Fired up make menuconfig and tried my best at tweaking things.

Really didn't expect it to successfully compile but the dang thing came out really well. Except for the no wifi on the laptop thing. Reason I'd dumped so much time dorking with trying to figure out the problem. Guess depends on method and never let it be said kernel devs don't have a (sometimes sadistic imo) sense of humor. There's even a make random config option. That supposedly does just that when it's used. Creates a totally randomly selected config file, WTH!?

Who would do that?! Never tried it. Have heard that if you had 10 million monkeys on typewriters, typing for a million years, eventually they'd type a masterpiece. KERNEL DEVS, STOP SCREWING WITH US!

[Deb-fan]

One more, what I believe is conclusive proof that kernel devs are intentionally screwing with us-people. Someone creates a .config file they think is pleasing and it'll look like it's compiling just fine, right up to the end and then fail with some arcane error message(s). Never had an overly powerful system, best one might complete the compile in an hour, hour and 20-30mins. First starting out dorking with compiling kernels that above scenario happened several times. So there went an hour and a half, to have it conk out at the last second !!! You can't tell me the amazingly talented folks behind all this gnu/Linuxy goodness couldn't have built in a check that would've notified someone of an issue before the last moment.

Not sure what to make of it. Maybe it's a way of saying if somebody doesn't know/learn what they're doing then they don't need to be messing with custom kernels ? Ok ... thanks again fellas for the kickbutt tips, cool contribs & shares, I have to go get some energy drinks before I croak.

PS, CR&P ... Happy 4th of July to all us in the states !! Well and wherever you are !!

[Wheelerof4te]

Well, at least in Debian, you need these packages installed in order to compile the latest upstream kernel:

Code: Select all

apt install libelf-dev bison flex bc libssl-dev libncurses5-dev build-essential

And don't forget to disable module signing or whatever it is if you're on Buster and Sid.
Also, while it sure is exciting, compiling kernels nowadays isn't needed for 95% of use-cases. Unless you're a developer looking to test some patch or push out new versions upstream, you are golden on almost any modern Linux distribution kernel. You can read more on the need for running a specific kernel here: http://www.kroah.com/log/blog/2018/08/2 ... uld-i-use/

[Deb-fan]

^ +1 and a lot of those used to come handily bundled in build-essential now separate packages someone has to install. Yet more proof they're (kern devs-etc) trying to keep us/people on our toes? Constant change, could be a legit technical reason, I don't know of any. Grudgingly admit, it's kinda brilliant, Lil twisted maybe but brilliant in my view too. How bad do you want-need it(a custom kernel?)

Think it's a pita but totally reasonable too. After the gazillion wo/man hours people have poured into developing the Linux kernel. Guess they expect folks to put in the time/effort and gain the knowledge to fiddle with it or it's GAME OVER, try again sucker.

Edit: Make that please insert another 12 to 72hrs of your life and try again.

[Deb-fan]

Really Wheeler gets a big plus one. Not something the majority are going to bother with and thanks @Stevep for all the time/effort making software available. Are those patched Broadcom packages any better than the one's in Busters repos?