Re: [blfs-dev] My latest build adventure
>On Sat, 04 Jan 2014 22:13:23 +0100 >"Armin K." wrote: > Do not hesitate to ask any questions. Careful, you might be > surprised :P > > www.linuxfromscratch.org/~krejzi/blfs-systemd-20140104.txt It says here you use ca-certificates-20130906 from Debian. Since my own certificate bundle has the texture and coloration of your average forgot-it-in-the-back-of-the-fridge food item, I'm curious as to how are those certificates assembled. I'm also interested in where you can find that bundle, but I suppose you can get it through Debian's on-line repositories. So, is this bundle just the reformated bundle from Firefox, or did Debian people assemble it themselves? -- Svi moji e-mailovi su kriptografski potpisani. Proverite ih. All of my e-mails are cryptographically signed. Verify them. -- You don't need an AI for a robot uprising. Humans will do just fine. signature.asc Description: PGP signature -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] My latest build adventure
On 01/04/2014 11:02 PM, Aleksandar Kuktin wrote: >> On Sat, 04 Jan 2014 22:13:23 +0100 >> "Armin K." wrote: > >> Do not hesitate to ask any questions. Careful, you might be >> surprised :P >> >> www.linuxfromscratch.org/~krejzi/blfs-systemd-20140104.txt > > It says here you use ca-certificates-20130906 from Debian. Since my own > certificate bundle has the texture and coloration of your average > forgot-it-in-the-back-of-the-fridge food item, I'm curious as to how > are those certificates assembled. I'm also interested in where you can > find that bundle, but I suppose you can get it through Debian's on-line > repositories. So, is this bundle just the reformated bundle from > Firefox, or did Debian people assemble it themselves? > > > They use python script to extract the certificates. You can find and browse the source online here http://anonscm.debian.org/gitweb/?p=collab-maint/ca-certificates.git;a=tree -- Note: My last name is not Krejzi. -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] My latest build adventure
>On Sat, 4 Jan 2014 23:02:22 +0100 >Aleksandar Kuktin wrote: > > >On Sat, 04 Jan 2014 22:13:23 +0100 > >"Armin K." wrote: > > > Do not hesitate to ask any questions. Careful, you might be > > surprised :P > > > > www.linuxfromscratch.org/~krejzi/blfs-systemd-20140104.txt Also, what is broadcom-sta-5.100.82.112? I also have a Broadcom WiFi interface, but I seem to be unable to make it work. lspci reports: Broadcom Corporation BCM4311 802.11b/g WLAN [14e4:4311] I've built the in-tree kernel driver, installed and loaded the firmware, but all to no avail. I'm currently reaching the list via UMTS (mobile internet) using a PCMCIA modem. While its cool to use pppd and chat to connect first to the modem and then to the world, I'd really like to let my Linux kick the poor Windows boxes from the air again. :evil_grin: Is broadcom-sta the part I am missing? Other questions: AFAIK, librsvg is involved in a circular dependency with GTK+. You seem to build GTK+, then librsvg, but never rebuild GTK+ to gain librsvg support in GTK+. If this is correct, is there a special reason for that? Skype is mentioned. I suppose this is a binary linux distribution downloaded from Skypes website. Correct? What exactly is intel-ucode-20130222 for? -- Svi moji e-mailovi su kriptografski potpisani. Proverite ih. All of my e-mails are cryptographically signed. Verify them. -- You don't need an AI for a robot uprising. Humans will do just fine. signature.asc Description: PGP signature -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] My latest build adventure
>On Sat, 04 Jan 2014 23:08:20 +0100 >"Armin K." wrote: > > They use python script to extract the certificates. You can find and > browse the source online here > > http://anonscm.debian.org/gitweb/?p=collab-maint/ca-certificates.git;a=tree Judging by the stuff one can see there, this is Fixefox's CA bundle together with one or certs from cacert.org and spi-inc.org . Hmhh.. Might as well pull it though. No point in continuing to use an antediluvian CA bundle. -- Svi moji e-mailovi su kriptografski potpisani. Proverite ih. All of my e-mails are cryptographically signed. Verify them. -- You don't need an AI for a robot uprising. Humans will do just fine. signature.asc Description: PGP signature -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] My latest build adventure
On 01/04/2014 11:25 PM, Aleksandar Kuktin wrote: >> On Sat, 4 Jan 2014 23:02:22 +0100 >> Aleksandar Kuktin wrote: >> >>> On Sat, 04 Jan 2014 22:13:23 +0100 >>> "Armin K." wrote: >> >>> Do not hesitate to ask any questions. Careful, you might be >>> surprised :P >>> >>> www.linuxfromscratch.org/~krejzi/blfs-systemd-20140104.txt > > Also, what is broadcom-sta-5.100.82.112? I also have a Broadcom WiFi > interface, but I seem to be unable to make it work. > It's a wifi driver, but an older version since current (v6.0) doesn't play well with the model I have. > lspci reports: > Broadcom Corporation BCM4311 802.11b/g WLAN [14e4:4311] > 02:00.0 Network controller [0280]: Broadcom Corporation BCM4313 802.11bgn Wireless Network Adapter [14e4:4727] (rev 01) > I've built the in-tree kernel driver, installed and loaded the > firmware, but all to no avail. I'm currently reaching the list via > UMTS (mobile internet) using a PCMCIA modem. While its cool to use pppd > and chat to connect first to the modem and then to the world, I'd really > like to let my Linux kick the poor Windows boxes from the > air again. :evil_grin: > I did try to use brcmsmac driver from the kernel, but signal was very poor and power management was bad. > Is broadcom-sta the part I am missing? > Probably. Some distros call it broadcom-wl or simply wl since the module it builds is actually "wl". Since I got the source from Debian (older one, upstream has only the latest one) and they call it broadcom-sta, I kept the name. > Other questions: > > AFAIK, librsvg is involved in a circular dependency with GTK+. You seem > to build GTK+, then librsvg, but never rebuild GTK+ to gain librsvg > support in GTK+. If this is correct, is there a special reason for that? > GTK+ doesn't depend on librsvg at all. Where did you get that from? Even BLFS doesn't list it as a dep neither for GTK+2 nor GTK+3. librsvg uses GTK+3 to build rsvg-view-3 program. > Skype is mentioned. I suppose this is a binary linux distribution > downloaded from Skypes website. Correct? > Yes > What exactly is intel-ucode-20130222 for? > CPU microcode update. It updates CPU microcode at runtime using "microcode" driver in the kernel. It's firmware actually. Now that you mention it, it seems that it doesn't work anymore somehow, probably since I've built microcode driver into kernel but firmware is in /lib/firmware. -- Note: My last name is not Krejzi. -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] My latest build adventure
On 01/04/2014 11:32 PM, Aleksandar Kuktin wrote: >> On Sat, 04 Jan 2014 23:08:20 +0100 >> "Armin K." wrote: >> >> They use python script to extract the certificates. You can find and >> browse the source online here >> >> http://anonscm.debian.org/gitweb/?p=collab-maint/ca-certificates.git;a=tree > > Judging by the stuff one can see there, this is Fixefox's CA bundle > together with one or certs from cacert.org and spi-inc.org . Hmhh.. > This was exactly the reason - because it ships aditional ca certs than the mozilla ones. Note that ca-bundle.crt in BLFS is actually called ca-certificates.crt there, so adjust your scripts or simply drop the switches pointing to the blfs ca bundle - this one gets auto detected for most if not all the packages. > Might as well pull it though. No point in continuing to use an > antediluvian CA bundle. > > > -- Note: My last name is not Krejzi. -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] My latest build adventure
>On Sat, 04 Jan 2014 23:33:13 +0100 >"Armin K." wrote: > > On 01/04/2014 11:25 PM, Aleksandar Kuktin wrote: > > Other questions: > > > > AFAIK, librsvg is involved in a circular dependency with GTK+. You > > seem to build GTK+, then librsvg, but never rebuild GTK+ to gain > > librsvg support in GTK+. If this is correct, is there a special > > reason for that? > > > > GTK+ doesn't depend on librsvg at all. Where did you get that from? > Even BLFS doesn't list it as a dep neither for GTK+2 nor GTK+3. > librsvg uses GTK+3 to build rsvg-view-3 program. Well, there's something since I always rebuild GTK+ after I build librsvg. [checking an older version of BLFS where I saw that] Okay, so not really. Cairo requires it for testing the SVG backend. Although I am 100% sure librsvg is also required for something else. [checking build logs] Okay, Emacs uses it, but that's not what I was after. Nevermind. Still sure something else requres librsvg but can't prove it. :) > > Skype is mentioned. I suppose this is a binary linux distribution > > downloaded from Skypes website. Correct? > > Yes Bugger. I did at one point see some seed of an open-source implementation of Skype, but that code had questionable legal origin and it didn't really work. It was also a one-person operation. > > What exactly is intel-ucode-20130222 for? > > CPU microcode update. It updates CPU microcode at runtime using > "microcode" driver in the kernel. It's firmware actually. > > Now that you mention it, it seems that it doesn't work anymore > somehow, probably since I've built microcode driver into kernel but > firmware is in /lib/firmware. Hmm.. Any improvements in the way system handles itself with the new firmware? Normally I use AMD, but I'm now on an Intel box so I have to bother with this a bit. BTW, I found that putting firmware into the kernel binary (as opposed to /lib/firmware) works best for me. No need to deal with helper programs and other such stuff. -- Svi moji e-mailovi su kriptografski potpisani. Proverite ih. All of my e-mails are cryptographically signed. Verify them. -- You don't need an AI for a robot uprising. Humans will do just fine. signature.asc Description: PGP signature -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] My latest build adventure
Hi, On Sun, 5 Jan 2014, Aleksandar Kuktin wrote: > Well, there's something since I always rebuild GTK+ after I build > librsvg. > > Okay, Emacs uses it, but that's not what I was after. Nevermind. > Still sure something else requires librsvg but can't prove it. :) I doubt that it helps, but I for one did start building librsvg (after GTK) because gimp seemed to require it a couple of years ago. BLFS gimp instructions mention it as optional nowadays (and GTK as required), so no reason for a circular dependency here either. According to my logs gimp seems to by my only package that actually uses librsvg... Uwe -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] My latest build adventure
On Sun, Jan 05, 2014 at 12:14:53AM +0100, Aleksandar Kuktin wrote: > >On Sat, 04 Jan 2014 23:33:13 +0100 > >"Armin K." wrote: > > > > On 01/04/2014 11:25 PM, Aleksandar Kuktin wrote: > > > > What exactly is intel-ucode-20130222 for? > > > > CPU microcode update. It updates CPU microcode at runtime using > > "microcode" driver in the kernel. It's firmware actually. > > > > Now that you mention it, it seems that it doesn't work anymore > > somehow, probably since I've built microcode driver into kernel but > > firmware is in /lib/firmware. Yeah, a similar "progress update" on lkml at the end of this week reporting (in the context of an original report that it was ok in 3.8.2 but broke in 3.8.3) that in fact it doesn't work if built in. Certainly, when I last tried firmware updates (perhaps 6 months ago) I had the impression that none of my boxes had available newer firmware, but I was almost certainly building it in. > > Hmm.. Any improvements in the way system handles itself with the new > firmware? Normally I use AMD, but I'm now on an Intel box so I have to > bother with this a bit. Apart from anything else, you need a CPU version for which updates have been issued (I guess that is usually to install workarounds for errata). In the lkml thread I got involved in, I think that kmail was unusable without the update! Not at all what I had expected. Meanwhile both my own and the other guy's AMD phenoms tend to lose their lunch when using 'make -j4' (fixed by dropping the caches and using -j3) and apparently the firmware update might not alter that. > > BTW, I found that putting firmware into the kernel binary (as opposed > to /lib/firmware) works best for me. No need to deal with helper > programs and other such stuff. > For ordinary drivers (video, particularly radeon, and nic or wifi) that seems to be easier - it does, however, waste kernel memory which is why kernel devs don't recommend it - I guess that is more important on a distro which builds everything, and for 32-bit kernels where at most 4GB (less PCI space, particularly for video) is addressable. The notes look interesting, particularly /lib and /lib32, but I'm supposed to be spending all my time on my (UK) tax return this month, and for the moment I can't afford to study them. Also, I used to think that X32 would be interesting - but modern DDR3 memory sticks are so big that I'm no longer convinced that would be worth the effort. And I don't need any 32-bit binaries in linux. So maybe I won look to deeply at multilib. But it's always interesting to see how other people build things, particularly the order, and to challenge my choices. So, thanks. ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] My latest build adventure
>On Sat, 04 Jan 2014 23:33:13 +0100 >"Armin K." wrote: > > On 01/04/2014 11:25 PM, Aleksandar Kuktin wrote: > > lspci reports: > > Broadcom Corporation BCM4311 802.11b/g WLAN [14e4:4311] > > > > 02:00.0 Network controller [0280]: Broadcom Corporation BCM4313 > 802.11bgn Wireless Network Adapter [14e4:4727] (rev 01) I know I'll sound like an idiot, but correct me if I'm wrong: a 802.11b end-station is able to connect to a 802.11n AP, right? Ditto for 802.11g end-station and 802.11n AP, am I correct? That's what I read just about everywhere yet am unable to make it work. So naturally I have to doubt everything. :) > > Is broadcom-sta the part I am missing? > > > > Probably. Some distros call it broadcom-wl or simply wl since the > module it builds is actually "wl". Since I got the source from Debian > (older one, upstream has only the latest one) and they call it > broadcom-sta, I kept the name. Aaaand.. it fails to build. Building against Linux-3.12.1 (weird how glibc is suddenly irrelevant). But the problem is, I have absolutely no idea where to start mending the problem. wl's code calls the function create_proc_entry(), supposedly expecting it to be defined in the kernel, but which only exists in two points in the kernel, both of them behind an "#if 0" switch which means the code is deleted by the preprocesor. IOW, there is no mention of create_proc_entry() in the kernel. And it also tries to access fields in some structure (struct proc_dir_entry) that simply do not exist. So I expect I will be unable to make it compile since I have no idea even where to begin with fixing this much lossage. For reference, what kernel do you build your version against? -- Svi moji e-mailovi su kriptografski potpisani. Proverite ih. All of my e-mails are cryptographically signed. Verify them. -- You don't need an AI for a robot uprising. Humans will do just fine. signature.asc Description: PGP signature -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] My latest build adventure
On 5.1.2014 2:42, Aleksandar Kuktin wrote: >> On Sat, 04 Jan 2014 23:33:13 +0100 >> "Armin K." wrote: >> >> On 01/04/2014 11:25 PM, Aleksandar Kuktin wrote: > >>> lspci reports: >>> Broadcom Corporation BCM4311 802.11b/g WLAN [14e4:4311] >>> >> >> 02:00.0 Network controller [0280]: Broadcom Corporation BCM4313 >> 802.11bgn Wireless Network Adapter [14e4:4727] (rev 01) > > I know I'll sound like an idiot, but correct me if I'm wrong: a 802.11b > end-station is able to connect to a 802.11n AP, right? Ditto for > 802.11g end-station and 802.11n AP, am I correct? > > That's what I read just about everywhere yet am unable to make it work. > So naturally I have to doubt everything. :) > Can't comment on this. My router seems to be set up for n, but I've seen a mobile phone connect to it just fine. It has some dual mode set up or whatever. >>> Is broadcom-sta the part I am missing? >>> >> >> Probably. Some distros call it broadcom-wl or simply wl since the >> module it builds is actually "wl". Since I got the source from Debian >> (older one, upstream has only the latest one) and they call it >> broadcom-sta, I kept the name. > > Aaaand.. it fails to build. Building against Linux-3.12.1 (weird how > glibc is suddenly irrelevant). > > But the problem is, I have absolutely no idea where to start mending > the problem. wl's code calls the function create_proc_entry(), > supposedly expecting it to be defined in the kernel, but which only > exists in two points in the kernel, both of them behind an "#if 0" > switch which means the code is deleted by the preprocesor. IOW, there > is no mention of create_proc_entry() in the kernel. And it also tries > to access fields in some structure (struct proc_dir_entry) that simply > do not exist. > > So I expect I will be unable to make it compile since I have no idea > even where to begin with fixing this much lossage. > Use the patches from my Archlinux AUR package: https://aur.archlinux.org/packages/br/broadcom-sta-dkms/broadcom-sta-dkms.tar.gz Apply them in the same order as in the PKGBUILD (not really important, there are only two of them): https://aur.archlinux.org/packages/br/broadcom-sta-dkms/PKGBUILD Don't forget to run "depmod" after running "make install" and disable all of drivers that kernel provides or if they are built as modules, blacklist them. > For reference, what kernel do you build your version against? 3.13.0-rc5, as mentioned in the document. -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] My latest build adventure
On Sun, Jan 05, 2014 at 01:11:56AM +0100, dueff...@uwe-dueffert.de wrote: > Hi, > > On Sun, 5 Jan 2014, Aleksandar Kuktin wrote: > > > Well, there's something since I always rebuild GTK+ after I build > > librsvg. > > > > Okay, Emacs uses it, but that's not what I was after. Nevermind. > > Still sure something else requires librsvg but can't prove it. :) > I doubt that it helps, but I for one did start building librsvg (after > GTK) because gimp seemed to require it a couple of years ago. BLFS gimp > instructions mention it as optional nowadays (and GTK as required), so no > reason for a circular dependency here either. According to my logs gimp > seems to by my only package that actually uses librsvg... > > Uwe [ /me goes off and looks at my git scripts ... ] - you are right : a couple of years ago I was building librsvg in my script after firefox had been built, i.e. where I was building print packages and the gimp, as well as ImageMagick. That was for gnome-2.32-ish and gimp-2.6. Initially, I had been going to say I was surprised by your comment, because I've been building librsvg late in my sequence (at first for abiword or goffice, now for libreoffice) for as long as I can remember. Yeah, my memory is short! The only thing I can say with any confidence is that over time, all dependencies and build orders will change ;-) ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] My latest build adventure
On 01/05/2014 12:14 AM, Aleksandar Kuktin wrote: >> On Sat, 04 Jan 2014 23:33:13 +0100 >> "Armin K." wrote: >> >> On 01/04/2014 11:25 PM, Aleksandar Kuktin wrote: >>> What exactly is intel-ucode-20130222 for? >> >> CPU microcode update. It updates CPU microcode at runtime using >> "microcode" driver in the kernel. It's firmware actually. >> >> Now that you mention it, it seems that it doesn't work anymore >> somehow, probably since I've built microcode driver into kernel but >> firmware is in /lib/firmware. > > Hmm.. Any improvements in the way system handles itself with the new > firmware? Normally I use AMD, but I'm now on an Intel box so I have to > bother with this a bit. > > BTW, I found that putting firmware into the kernel binary (as opposed > to /lib/firmware) works best for me. No need to deal with helper > programs and other such stuff. > > > Now that I've built it as module, the microcode firmware seems to load just fine and I did notice something: dmesg output, early boot - before /sbin/init has been ran: [0.040548] perf_event_intel: PEBS disabled due to CPU errata, please upgrade microcode dmesg output, after udev has been started and it has loaded the microcode module: [ 10.471604] microcode: CPU0 sig=0x206a7, pf=0x10, revision=0x25 [ 10.720949] microcode: CPU0 sig=0x206a7, pf=0x10, revision=0x25 [ 10.722411] microcode: CPU0 updated to revision 0x28, date = 2012-04-24 [ 10.722486] microcode: CPU1 sig=0x206a7, pf=0x10, revision=0x25 [ 10.722555] microcode: CPU1 sig=0x206a7, pf=0x10, revision=0x25 [ 10.723511] microcode: CPU1 updated to revision 0x28, date = 2012-04-24 [ 10.723549] microcode: CPU2 sig=0x206a7, pf=0x10, revision=0x25 [ 10.723617] microcode: CPU2 sig=0x206a7, pf=0x10, revision=0x25 [ 10.724582] microcode: CPU2 updated to revision 0x28, date = 2012-04-24 [ 10.724596] microcode: CPU3 sig=0x206a7, pf=0x10, revision=0x25 [ 10.724631] microcode: CPU3 sig=0x206a7, pf=0x10, revision=0x25 [ 10.725553] microcode: CPU3 updated to revision 0x28, date = 2012-04-24 [ 10.725573] perf_event_intel: PEBS enabled due to microcode update [ 10.725673] microcode: Microcode Update Driver: v2.00 , Peter Oruba I don't know what PEBS is, but in this case, microcode update seems to enable it. -- Note: My last name is not Krejzi. -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] My latest build adventure
On Sun, Jan 05, 2014 at 06:51:44PM +0100, Armin K. wrote: > > Now that I've built it as module, the microcode firmware seems to load > just fine and I did notice something: > > dmesg output, early boot - before /sbin/init has been ran: > > [0.040548] perf_event_intel: PEBS disabled due to CPU errata, please > upgrade microcode > > dmesg output, after udev has been started and it has loaded the > microcode module: > > [ 10.471604] microcode: CPU0 sig=0x206a7, pf=0x10, revision=0x25 > [ 10.720949] microcode: CPU0 sig=0x206a7, pf=0x10, revision=0x25 > [ 10.722411] microcode: CPU0 updated to revision 0x28, date = 2012-04-24 > [ 10.722486] microcode: CPU1 sig=0x206a7, pf=0x10, revision=0x25 > [ 10.722555] microcode: CPU1 sig=0x206a7, pf=0x10, revision=0x25 > [ 10.723511] microcode: CPU1 updated to revision 0x28, date = 2012-04-24 > [ 10.723549] microcode: CPU2 sig=0x206a7, pf=0x10, revision=0x25 > [ 10.723617] microcode: CPU2 sig=0x206a7, pf=0x10, revision=0x25 > [ 10.724582] microcode: CPU2 updated to revision 0x28, date = 2012-04-24 > [ 10.724596] microcode: CPU3 sig=0x206a7, pf=0x10, revision=0x25 > [ 10.724631] microcode: CPU3 sig=0x206a7, pf=0x10, revision=0x25 > [ 10.725553] microcode: CPU3 updated to revision 0x28, date = 2012-04-24 > [ 10.725573] perf_event_intel: PEBS enabled due to microcode update > [ 10.725673] microcode: Microcode Update Driver: v2.00 > , Peter Oruba > > > > I don't know what PEBS is, but in this case, microcode update seems to > enable it. > I knew it was something to do with kernel performance monitoring, (i.e. instrumenting how long is spent in various parts of the code) and eventually found it documented in http://perfmon2.sourceforge.net/pfmon_intel_core.html : Precise Event-Based Sampling. ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] My latest build adventure
On 01/05/2014 07:19 PM, Ken Moffat wrote: > On Sun, Jan 05, 2014 at 06:51:44PM +0100, Armin K. wrote: >> >> Now that I've built it as module, the microcode firmware seems to load >> just fine and I did notice something: >> >> dmesg output, early boot - before /sbin/init has been ran: >> >> [0.040548] perf_event_intel: PEBS disabled due to CPU errata, please >> upgrade microcode >> >> dmesg output, after udev has been started and it has loaded the >> microcode module: >> >> [ 10.471604] microcode: CPU0 sig=0x206a7, pf=0x10, revision=0x25 >> [ 10.720949] microcode: CPU0 sig=0x206a7, pf=0x10, revision=0x25 >> [ 10.722411] microcode: CPU0 updated to revision 0x28, date = 2012-04-24 >> [ 10.722486] microcode: CPU1 sig=0x206a7, pf=0x10, revision=0x25 >> [ 10.722555] microcode: CPU1 sig=0x206a7, pf=0x10, revision=0x25 >> [ 10.723511] microcode: CPU1 updated to revision 0x28, date = 2012-04-24 >> [ 10.723549] microcode: CPU2 sig=0x206a7, pf=0x10, revision=0x25 >> [ 10.723617] microcode: CPU2 sig=0x206a7, pf=0x10, revision=0x25 >> [ 10.724582] microcode: CPU2 updated to revision 0x28, date = 2012-04-24 >> [ 10.724596] microcode: CPU3 sig=0x206a7, pf=0x10, revision=0x25 >> [ 10.724631] microcode: CPU3 sig=0x206a7, pf=0x10, revision=0x25 >> [ 10.725553] microcode: CPU3 updated to revision 0x28, date = 2012-04-24 >> [ 10.725573] perf_event_intel: PEBS enabled due to microcode update >> [ 10.725673] microcode: Microcode Update Driver: v2.00 >> , Peter Oruba >> >> >> >> I don't know what PEBS is, but in this case, microcode update seems to >> enable it. >> > I knew it was something to do with kernel performance monitoring, > (i.e. instrumenting how long is spent in various parts of the code) > and eventually found it documented in > http://perfmon2.sourceforge.net/pfmon_intel_core.html : Precise > Event-Based Sampling. > > ĸen > Thanks for that. I don't think it's useful to me but good to know. I was just answering to the question if microcode update enabled something ... Well, to be honest, till today I didn't know if it did :D -- Note: My last name is not Krejzi. -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] My latest build adventure
>On Sun, 05 Jan 2014 04:02:30 +0100
>"Armin K." wrote:
>
> On 5.1.2014 2:42, Aleksandar Kuktin wrote:
> > So I expect I will be unable to make it compile since I have no idea
> > even where to begin with fixing this much lossage.
>
> Use the patches from my Archlinux AUR package:
>
> https://aur.archlinux.org/packages/br/broadcom-sta-dkms/broadcom-sta-dkms.tar.gz
I had to apply the changes manually since the hybrid's code changed in
the meantime and these patches do not apply anymore. I'm attaching the
new patches to this e-mail.
> > [snip]
> >
> > For reference, what kernel do you build your version against?
>
> 3.13.0-rc5, as mentioned in the document.
Right. I read many packages in there but forgot to look at the kernel.
While I made a lot of progress, I am now in a way worse off then I was
before. I built the module, built the lib80211 module (which is
autoselecting so I had to build an unneeded driver to make it build),
unloaded both the b43 and ssb (which required disabling the b44 driver
- that one's for Broadcom ethernet devices), loaded wl and got treated
to this:
lib80211: common routines for IEEE802.11 drivers
lib80211_crypt: registered algorithm 'NULL'
wl: module license 'MIXED/Proprietary' taints kernel.
Disabling lock debugging due to kernel taint
malloc in abgphy done
wl driver 6.30.223.141 (r415941) failed with code 21
[ cut here ]
kernel BUG at include/net/cfg80211.h:3127!
invalid opcode: [#1] PREEMPT SMP
Modules linked in: wl(PO+) lib80211
CPU: 0 PID: 165 Comm: modprobe Tainted: PW O 3.12.1 #17
... and so on with the rest of the backtrace ...
The backtrace happens because wl_cfg80211_detach() from the open-source
part of wl gets passed zero as argument to which then ndev_to_wl()
(which is a wrapper over a wrapper to some function defined in
include/net/cfg80211.h) panics. That's not the problem.
The problem is the line about "failed with code 21", the cause of which
I managed to trace into the blob. Or rather, that is not the problem,
that is an accomplishment (this was my first time debugging the kernel
and it was fun!), but the problem is that I have been living for years
in open source where everything is possible (subject to the Law of
conservation of matter), but now I'm looking at having to either debug
a blob (nevermind I'm legaly not supposed to do that) or wait (read:
beg) for Broadcom to mercifully decide to *try* to fix the problem and
maybe succeed, but also maybe not, provided they don't give up halfway
through.
--
Svi moji e-mailovi su kriptografski potpisani. Proverite ih.
All of my e-mails are cryptographically signed. Verify them.
--
You don't need an AI for a robot uprising.
Humans will do just fine.
diff -Naur wl-old/Makefile wl-new/Makefile
--- wl-old/Makefile 2013-08-01 08:52:22.0 +0200
+++ wl-new/Makefile 2014-01-05 14:42:57.0 +0100
@@ -126,17 +126,23 @@
EXTRA_CFLAGS += -I$(src)/src/shared/bcmwifi/include
#EXTRA_CFLAGS += -DBCMDBG_ASSERT
+ifeq ($(KVER),)
+ KVER = $(shell uname -r)
+endif
+
+PWD = $(shell pwd)
+
EXTRA_LDFLAGS := $(src)/lib/wlc_hybrid.o_shipped
-KBASE ?= /lib/modules/`uname -r`
+KBASE ?= /lib/modules/$(KVER)
KBUILD_DIR ?= $(KBASE)/build
MDEST_DIR ?= $(KBASE)/kernel/drivers/net/wireless
all:
- KBUILD_NOPEDANTIC=1 make -C $(KBUILD_DIR) M=`pwd`
+ KBUILD_NOPEDANTIC=1 make -C $(KBUILD_DIR) M=$(PWD)
clean:
- KBUILD_NOPEDANTIC=1 make -C $(KBUILD_DIR) M=`pwd` clean
+ KBUILD_NOPEDANTIC=1 make -C $(KBUILD_DIR) M=$(PWD) clean
install:
install -D -m 755 wl.ko $(MDEST_DIR)
diff -Naur wl-old/src/wl/sys/wl_linux.c wl-new/src/wl/sys/wl_linux.c
--- wl-old/src/wl/sys/wl_linux.c 2013-08-01 08:52:22.0 +0200
+++ wl-new/src/wl/sys/wl_linux.c 2014-01-05 14:44:11.0 +0100
@@ -179,6 +179,8 @@
static void wl_report_radio_state(wl_info_t *wl);
#endif
+MODULE_LICENSE("MIXED/Proprietary");
+
static struct pci_device_id wl_id_table[] =
{
{ PCI_ANY_ID, PCI_ANY_ID, PCI_ANY_ID, PCI_ANY_ID,
@@ -235,7 +237,7 @@
#define to_str(s) #s
#define quote_str(s) to_str(s)
-#define BRCM_WLAN_IFNAME eth%d
+#define BRCM_WLAN_IFNAME wlan%d
static char intf_name[IFNAMSIZ] = quote_str(BRCM_WLAN_IFNAME);
diff -Naur wl-old/Makefile wl-new/Makefile
--- wl-old/Makefile 2014-01-05 15:18:51.0 +0100
+++ wl-new/Makefile 2014-01-05 14:47:53.0 +0100
@@ -21,7 +21,7 @@
ifneq ($(KERNELRELEASE),)
LINUXVER_GOODFOR_CFG80211:=$(strip $(shell \
-if [ "$(VERSION)" -ge "2" -a "$(PATCHLEVEL)" -ge "6" -a "$(SUBLEVEL)" -ge "32" -o "$(VERSION)" -ge "3" ]; then \
+if [ "$(VERSION)" -ge "3" -o "$(VERSION)" -ge "2" -a "$(PATCHLEVEL)" -ge "6" -a "$(SUBLEVEL)" -ge "32" ]; then \
echo TRUE; \
else \
echo FALSE; \
@@ -29,7 +29,7 @@
))
LINUXVER_WEXT_ONLY:=$(strip $(shell \
-if [ "$(VERSION)" -ge "2" -a "$(PATCHLEVEL)" -ge "6" -a "$(SUBLEVEL)" -ge "17" ]; then \
+if [ "$(VERSION)"
Re: [blfs-dev] My latest build adventure
On 01/05/2014 11:53 PM, Aleksandar Kuktin wrote: >> On Sun, 05 Jan 2014 04:02:30 +0100 >> "Armin K." wrote: >> >> On 5.1.2014 2:42, Aleksandar Kuktin wrote: > >>> So I expect I will be unable to make it compile since I have no idea >>> even where to begin with fixing this much lossage. >> >> Use the patches from my Archlinux AUR package: >> >> https://aur.archlinux.org/packages/br/broadcom-sta-dkms/broadcom-sta-dkms.tar.gz > > I had to apply the changes manually since the hybrid's code changed in > the meantime and these patches do not apply anymore. I'm attaching the > new patches to this e-mail. > That's version 5, for version 6 you should use patches from https://aur.archlinux.org/packages/broadcom-wl I did mention that I use version 5 because version 6 doesn't play nicely with this chip. >>> [snip] >>> >>> For reference, what kernel do you build your version against? >> >> 3.13.0-rc5, as mentioned in the document. > > Right. I read many packages in there but forgot to look at the kernel. > > While I made a lot of progress, I am now in a way worse off then I was > before. I built the module, built the lib80211 module (which is > autoselecting so I had to build an unneeded driver to make it build), > unloaded both the b43 and ssb (which required disabling the b44 driver > - that one's for Broadcom ethernet devices), loaded wl and got treated > to this: > > lib80211: common routines for IEEE802.11 drivers > lib80211_crypt: registered algorithm 'NULL' > wl: module license 'MIXED/Proprietary' taints kernel. > Disabling lock debugging due to kernel taint > malloc in abgphy done > wl driver 6.30.223.141 (r415941) failed with code 21 > [ cut here ] > kernel BUG at include/net/cfg80211.h:3127! > invalid opcode: [#1] PREEMPT SMP > Modules linked in: wl(PO+) lib80211 > CPU: 0 PID: 165 Comm: modprobe Tainted: PW O 3.12.1 #17 > ... and so on with the rest of the backtrace ... > > The backtrace happens because wl_cfg80211_detach() from the open-source > part of wl gets passed zero as argument to which then ndev_to_wl() > (which is a wrapper over a wrapper to some function defined in > include/net/cfg80211.h) panics. That's not the problem. > > The problem is the line about "failed with code 21", the cause of which > I managed to trace into the blob. Or rather, that is not the problem, > that is an accomplishment (this was my first time debugging the kernel > and it was fun!), but the problem is that I have been living for years > in open source where everything is possible (subject to the Law of > conservation of matter), but now I'm looking at having to either debug > a blob (nevermind I'm legaly not supposed to do that) or wait (read: > beg) for Broadcom to mercifully decide to *try* to fix the problem and > maybe succeed, but also maybe not, provided they don't give up halfway > through. > > > -- Note: My last name is not Krejzi. -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] My latest build adventure
>On Sun, 05 Jan 2014 23:54:23 +0100 >"Armin K." wrote: > That's version 5, for version 6 you should use patches from > > https://aur.archlinux.org/packages/broadcom-wl This is actually my first time using Arch's package system. :) The "6" patch produces the same end result as the rediffed "5" patch (wlc_attach() fails with code 21) but I did have a problem with the new patch: $make KBUILD_NOPEDANTIC=1 make -C /lib/modules/`uname -r`/build M=`pwd` make[1]: Entering directory `/home/ak/hack/rad/linux-stable' CFG80211 API is prefered for this kernel version Using CFG80211 API LD /home/ak/hack/rad/arch-wl/wl/built-in.o CC [M] /home/ak/hack/rad/arch-wl/wl/src/shared/linux_osl.o CC [M] /home/ak/hack/rad/arch-wl/wl/src/wl/sys/wl_linux.o CC [M] /home/ak/hack/rad/arch-wl/wl/src/wl/sys/wl_iw.o CC [M] /home/ak/hack/rad/arch-wl/wl/src/wl/sys/wl_cfg80211_hybrid.o LD [M] /home/ak/hack/rad/arch-wl/wl/wl.o Building modules, stage 2. CFG80211 API is prefered for this kernel version Using CFG80211 API MODPOST 1 modules WARNING: modpost: Found 1 section mismatch(es). To see full details build your kernel with: 'make CONFIG_DEBUG_SECTION_MISMATCH=y' CC /home/ak/hack/rad/arch-wl/wl/wl.mod.o LD [M] /home/ak/hack/rad/arch-wl/wl/wl.ko make[1]: Leaving directory `/home/ak/hack/rad/linux-stable' Rebuildig with 'make CONFIG_DEBUG_SECTION_MISMATCH=y' produces the following elaboration: WARNING: /home/ak/hack/rad/arch-wl/wl/wl.o(.data+0x77e10): Section mismatch in reference from the variable wl_pci_driver to the function .init.text:wl_pci_probe() The variable wl_pci_driver references the function __init wl_pci_probe() If the reference is valid then annotate the variable with __init* or __refdata (see linux/init.h) or name the variable: *_template, *_timer, *_sht, *_ops, *_probe, *_probe_one, *_console Looking at the 5 patch, wl_pci_driver is marked with __refdata while the 6 patch omits that. In the interest of being usefull, I have added the missing annotation and am attaching the new patch. > I did mention that I use version 5 because version 6 doesn't play > nicely with this chip. Correct. However, when I saw the patch non-applying, the thought that there may be other patches did not even cross my mind. I suppose that, as an LFS user, you are used to dealing with (so to speak) broken patches and, more generally, broken software which does not compile. :) -- Svi moji e-mailovi su kriptografski potpisani. Proverite ih. All of my e-mails are cryptographically signed. Verify them. -- You don't need an AI for a robot uprising. Humans will do just fine. arch-hybrid-6-patch.patch.xz Description: application/xz signature.asc Description: PGP signature -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] My latest build adventure
>On Sun, 5 Jan 2014 23:53:00 +0100 >Aleksandar Kuktin wrote: > The problem is the line about "failed with code 21", the cause of > which I managed to trace into the blob. Or rather, that is not the > problem, that is an accomplishment (this was my first time debugging > the kernel and it was fun!), but the problem is that I have been > living for years in open source where everything is possible (subject > to the Law of conservation of matter), but now I'm looking at having > to either debug a blob (nevermind I'm legaly not supposed to do that) > or wait (read: beg) for Broadcom to mercifully decide to *try* to fix > the problem and maybe succeed, but also maybe not, provided they > don't give up halfway through. Posting for completeness. Broadcom was actually very quick with the response. I posted to the linux-wlan-client-support-list and got the complete response within 24 hours, much faster then I was expecting. The gist of the response is that my WiFi card had its ROM FUBAR-ed and that there no help for it. -- Svi moji e-mailovi su kriptografski potpisani. Proverite ih. All of my e-mails are cryptographically signed. Verify them. -- You don't need an AI for a robot uprising. Humans will do just fine. signature.asc Description: PGP signature -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
