[lfs-dev] Enable Udev Firmware Loader
From IRC: Is anyone else seeing a problem with firmware loading since the jump from udev-198 to udev-200? It's my Atheros Wi-Fi dongle, it's supposed to load /lib/firmware/htc_7010.fw, but since the jump to udev-200 it's like udev can't locate the file. Systemd has made firmware loader build optional and disabled by default since modern kernels can load firmware by itself. The guy was running 3.6 kernel. http://cgit.freedesktop.org/systemd/systemd/commit/?id=a3bd8447be4ea2ce230eb8ae0e815c04d85fa15a http://cgit.freedesktop.org/systemd/systemd/commit/?id=61e536e1b7f3a7448428a05bafe1ea64d7e51938 http://cgit.freedesktop.org/systemd/systemd/commit/?id=d8d4bee76cf3b40ea923bc57d44aa0815ca9b5ff Just add -DHAVE_FIWMARE to defines and it should be fine. Index: Makefile.lfs === --- Makefile.lfs (revision 10241) +++ Makefile.lfs (working copy) @@ -38,7 +38,8 @@ -DROOTPREFIX= \ -DUDEVLIBEXECDIR=\"/lib/udev\"\ -D_LARGEFILE_SOURCE \ - -D_FILE_OFFSET_BITS=64 + -D_FILE_OFFSET_BITS=64\ + -DHAVE_FIRMWARE INCLUDE = -I src/libudev -I src/shared -I src -I src/login -I src/systemd -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] Enable Udev Firmware Loader
Le 05/04/2013 17:42, Armin K. a écrit : > From IRC: > > Is anyone else seeing a problem with firmware loading since > the jump from udev-198 to udev-200? > It's my Atheros Wi-Fi dongle, it's supposed to load > /lib/firmware/htc_7010.fw, but since the jump to udev-200 it's like > udev can't locate the file. > > Systemd has made firmware loader build optional and disabled by > default since modern kernels can load firmware by itself. The guy was > running 3.6 kernel. > > http://cgit.freedesktop.org/systemd/systemd/commit/?id=a3bd8447be4ea2ce230eb8ae0e815c04d85fa15a > > > http://cgit.freedesktop.org/systemd/systemd/commit/?id=61e536e1b7f3a7448428a05bafe1ea64d7e51938 > > > http://cgit.freedesktop.org/systemd/systemd/commit/?id=d8d4bee76cf3b40ea923bc57d44aa0815ca9b5ff > > > > Just add -DHAVE_FIWMARE to defines and it should be fine. > > If I understand well adding the switch --with-firmware-path=/lib/firmware to configure should do the trick. Pierre -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] Enable Udev Firmware Loader
Le 05/04/2013 18:19, Pierre Labastie a écrit : > Le 05/04/2013 17:42, Armin K. a écrit : >> From IRC: >> >> Is anyone else seeing a problem with firmware loading since >> the jump from udev-198 to udev-200? >> It's my Atheros Wi-Fi dongle, it's supposed to load >> /lib/firmware/htc_7010.fw, but since the jump to udev-200 it's like >> udev can't locate the file. >> >> Systemd has made firmware loader build optional and disabled by >> default since modern kernels can load firmware by itself. The guy was >> running 3.6 kernel. >> >> http://cgit.freedesktop.org/systemd/systemd/commit/?id=a3bd8447be4ea2ce230eb8ae0e815c04d85fa15a >> >> http://cgit.freedesktop.org/systemd/systemd/commit/?id=61e536e1b7f3a7448428a05bafe1ea64d7e51938 >> >> http://cgit.freedesktop.org/systemd/systemd/commit/?id=d8d4bee76cf3b40ea923bc57d44aa0815ca9b5ff >> >> >> Just add -DHAVE_FIWMARE to defines and it should be fine. >> >> > If I understand well adding the switch > --with-firmware-path=/lib/firmware to configure should do the trick. > > Pierre Forget the above, we do not run configure in LFS. Sorry Pierre -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] procps-ng tests
Le 04/04/2013 23:37, Bruce Dubbs a écrit :
> Pierre Labastie wrote:
>> Le 04/04/2013 18:08, Bruce Dubbs a écrit :
>>> Pierre Labastie wrote:
Le 03/04/2013 00:26, Bruce Dubbs a écrit :
> Pierre Labastie wrote:
>> Le 02/04/2013 19:39, Bruce Dubbs a écrit :
>>> I was meaning to bring this up again. I get
>>>
>>> Running ./pmap.test/pmap.exp ...
>>> FAIL: pmap X with unreachable process
>>> FAIL: pmap XX with unreachable process
> That means that it can't find /proc/1. If /proc is mounted, that should
> always be there, e.g. `cat /proc/1/cmdline`.
>
>
>>> vmstat gives me:
>>>
>>> # of expected passes6
>> I have not been able to reproduce the /proc/diskstats beginning with
>> sr0. Only in that case does the vmstat test fail.
> Isn't sr0 a cdrom? On my system, I have:
>
> 11 0 sr0 0 0 0 0 0 0 0 0 0 0 0
>
> Major dev#, minor dev#, name, counters...
>
>
The failure in the test depends on the ordering of the the
/proc/diskstats table. This morning, I had:
---
pierre@debian32-virt:~$ cat /proc/diskstats
2 0 fd0 0 0 0 0 0 0 0 0 0 0 0
11 0 sr0 19 0 152 136 0 0 0 0 0 136 136
8 0 sda 32783 8723 2567928 84792 336771 8561249 71767606
11478240 0 1477316 11607988
8 1 sda1 559 2108 19320 1148 4 0 20 0 0 956 1148
8 2 sda2 161 31 1536 172 0 0 0 0 0 172 172
[...]
---
And the test failed with:
Running ./vmstat.test/vmstat.exp ...
FAIL: vmstat partition (using sr0)
=== vmstat Summary ===
# of expected passes5
# of unexpected failures1
/sources/procps-ng-3.3.7/vmstat version 3.3.7
---
The problem is that ' 11 0 sr0 19 0 152 136 0 0 0 0 0 136 136'
matches
'\\s+\\d+\\s+\\d+\\s+\(\[a-z\]+\\d+\)\\s+\(\[0-9\]\[0-9\]+\)' (in
vmstat.exp).
>>> I guess they were not expecting you to have done reads from the cdrom.
>>>
>> I haven't. Of course, I could disable the CDROM on the virtual machine.
>> But when it is present, there are always a few reads, even if I boot
>> from disk. I guess the kernel makes a few reads at init time.
> That seems specific to your virtual system (which one?).
Qemu-kvm (1.1.2). Among the options I have:
-drive file=/mnt/virtualfs/aqemu/debian32.qcow2,cache=writeback \
-cdrom /mnt/virtualfs/debian-6.0.4-i386-businesscard.iso
So the virtual CDROM is always in the virtual drive, which explains the
few reads, although I do not mount it.
> My non-virtual
> system has:
>
> 11 0 sr0 0 0 0 0 0 0 0 0 0 0 0
>
> But it is after sd{a,b,c}, so it is a race condition also.
>
> Perhaps the search should be for [s|h]d[a-z]\s+\d\d+
Aren't there cases where the naming is different (for example SSD
drives)? Just guessing here.
Pierre
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: [lfs-dev] procps-ng tests
Pierre Labastie wrote:
> pierre@debian32-virt:~$ cat /proc/diskstats
> 2 0 fd0 0 0 0 0 0 0 0 0 0 0 0
> 11 0 sr0 19 0 152 136 0 0 0 0 0 136 136
> 8 0 sda 32783 8723 2567928 84792 336771 8561249 71767606
> 11478240 0 1477316 11607988
> 8 1 sda1 559 2108 19320 1148 4 0 20 0 0 956 1148
> 8 2 sda2 161 31 1536 172 0 0 0 0 0 172 172
> [...]
> ---
> And the test failed with:
> Running ./vmstat.test/vmstat.exp ...
> FAIL: vmstat partition (using sr0)
>
> === vmstat Summary ===
>
> # of expected passes5
> # of unexpected failures1
> /sources/procps-ng-3.3.7/vmstat version 3.3.7
> ---
> The problem is that ' 11 0 sr0 19 0 152 136 0 0 0 0 0 136 136'
> matches
> '\\s+\\d+\\s+\\d+\\s+\(\[a-z\]+\\d+\)\\s+\(\[0-9\]\[0-9\]+\)' (in
> vmstat.exp).
I guess they were not expecting you to have done reads from the cdrom.
>>> I haven't. Of course, I could disable the CDROM on the virtual machine.
>>> But when it is present, there are always a few reads, even if I boot
>>> from disk. I guess the kernel makes a few reads at init time.
>> That seems specific to your virtual system (which one?).
> Qemu-kvm (1.1.2). Among the options I have:
> -drive file=/mnt/virtualfs/aqemu/debian32.qcow2,cache=writeback \
> -cdrom /mnt/virtualfs/debian-6.0.4-i386-businesscard.iso
>
> So the virtual CDROM is always in the virtual drive, which explains the
> few reads, although I do not mount it.
>>My non-virtual
>> system has:
>>
>> 11 0 sr0 0 0 0 0 0 0 0 0 0 0 0
>>
>> But it is after sd{a,b,c}, so it is a race condition also.
>>
>> Perhaps the search should be for [s|h]d[a-z]\d\s+\d\d+
> Aren't there cases where the naming is different (for example SSD
> drives)? Just guessing here.
No, I have an ssd drive and it is just sdc. It just plugs into the
sata system like a regular drive.
I suppose it could be a problem with kvm or vmstat.
Checking with qemu-1.4:
ARGS="-enable-kvm -hda lfs73.img"
MEM="-m 2G"
CDROM="-cdrom lfslivecd-x86_64-6.3-r2160-updated-nosrc.iso"
NIC="-net nic -net tap"
sudo qemu $ARGS $CDROM $NIC $MEM $DRIVE2 $REMOTE
I get:
$ cat /proc/diskstats
7 0 loop0 0 0 0 0 0 0 0 0 0 0 0
7 1 loop1 0 0 0 0 0 0 0 0 0 0 0
8 0 sda 1307 2686 42824 8102 141 176 2626 5559 0 5786 13658
8 1 sda1 21 0 168 26 0 0 0 0 0 26 26
8 2 sda2 246 50 2152 325 1 0 2 0 0 323 325
8 3 sda3 621 766 36918 6794 137 176 2624 5426 0 5294 12217
8 4 sda4 165 1386 1558 331 0 0 0 0 0 320 331
8 5 sda5 167 484 1332 357 0 0 0 0 0 357 357
11 0 sr0 33 0 264 123 0 0 0 0 0 123 123
Note that sr0 is last. In any case, sr0 and loop? and sda are not
partitions. It still looks like a race condition (what is the order of
entries in /proc/diskstats) or just a logic error in the test to me.
-- Bruce
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: [lfs-dev] LFS will need bc.
On Mon, Apr 01, 2013 at 06:49:25PM +0100, Ken Moffat wrote: > I'd seen comments on the kernel list about bc being required in > 3.9, and then forgotten about them (on my desktops I have it anyway, > for xscreensaver). It gets used for kernel/timeconst.h > https://patchwork.kernel.org/patch/2143611/ [snip] > > For the moment I've added it to the end of my chapter 6 build, I > haven't checked dependencies to see how soon it can be built. > Taking a few minutes to look at what it appears to need (I'm assuming that texinfo from /tools will be good enough), the last of them in the build order is 'flex'. Looking at the old idea for an alphabetical sequence, we only really start of get close to that with the autoconf ... vim block of packages, and even there gawk, xz, less are not in order. So I'm going to suggest (when we get to the 3.9 kernel) that we just add it after vim. Dependencies identified are: bison, flex, gawk, ncurses, readline and texinfo. ĸen -- das eine Mal als Tragödie, das andere Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
