[oe] udev 171 caching working propely?

[Koen Kooi]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 24-06-11 00:52, Andreas Mueller wrote:
> On Thursday, June 23, 2011 11:58:53 PM Koen Kooi wrote:
>> On 23-06-11 22:58, Andreas Mueller wrote:
>>> On Tuesday, June 21, 2011 11:31:45 PM Tom Rini wrote:
>>>> On 06/20/2011 03:47 PM, Tom Rini wrote:
>>>>> On 06/20/2011 02:16 PM, Andreas Mueller wrote:
>>>>>> Dear OE-folks,
>>>>>>
>>>>>> Working with lastest classic oe master and angstrom it seems udev
>>>>>> caching is not
>>>>>>
>>>>>> working as expected. On *every* boot I get:
>>>>>>> Remounting root file system...
>>>>>>> Caching udev devnodes
>>>>>>> Populating dev cachemv: can't rename '/dev/shm/uname': No such file
>>>>>>> or directory
>>>>>>
>>>>>> I don't know why this change came in but there was a change of storage
>>>>>> location in Tom's commit few days ago [1]. To me it seems that
>>>>>>
>>>>>> 1. The files created by udev (init) get lost at remount so udev-cache
>>>>>> (cache) is unable to find
>>>>>> 2. Since this error occures not only at first boot the recipe's
>>>>>> pkg_postinst_udev_append() seems never being executed. To check I
>>>>>> added a simple echo 'foo text'
>>>>>> in this function but 'foo text' is not found in log of first boot.
>>>>>>
>>>>>> Suggestions welcome
>>>>>
>>>>> Did udev change behaviors at some point then?  I've been using an older
>>>>> udev and didn't run into that problem.  I changed from /tmp to /dev/shm
>>>>> since we don't know that /tmp is writable at that point so we were
>>>>> instead getting errors there.  I wonder if we should just switch to
>>>>> re-creating the contents for that step?
>>>>
>>>> I've gone with this change and some quick testing on a board.
>>>
>>> Hi Tom,
>>>
>>> thanks for taking care and sorry for late response - yesterday I had one
>>> of these nightmares at the job...
>>>
>>> Now I tested the patch for two machines and sorry I am afraid to waste
>>> your time again:
>>>
>>> First machine is overo with linux-omap-psp-2.6.32 and a hub connected to
>>> the OTG connector. The kernel detects USB devices at a very early boot
>>> state long before udev starts (see end of file 'overo' attached). udev
>>> caching seems to work without errors.
>>>
>>> Second machine is tx28 with linux-2.6.38.5 (freescale imx28 based - I
>>> will send patches when stable). This shows different behaviours on first
>>> and all further boots (see udev-*boot attached). Problem is that after
>>> second boot nothing connected to USB is detected / working. By deleting
>>> /etc/udev/saved.* and rebooting all USB devices work fine and log looks
>>> similar as first boot.
>>>
>>> Before I merged your patch I know the USB devices were working properly
>>> on tx28. Don't misunderstand me: I think before your patch cache was
>>> never read. Now you fixed this and it seems reading the cache does not
>>> work (on my half cooked machine only?).
>>>
>>> I will have further investigations on this...
>>
>> With 171 you shouldn't need caching anymore, triggering has been sped up
>> considerably, could you try disable caching and see how much it impacts
>> your boot time?
> Uncached feels slower. Populating all devices takes 5-10s. Is there a simple way 
> to create time stamps for boot messages? 

Another test would be to unload the kernel modules and do:

killall udevd ; time ( udevadm trigger ; udevadm settle )

That takes about 1s on my beagleboard and 3.5s on my hawkboard.

Systemd keeps a track of it, have a look at the bright red portions of
the graphs:

http://dominion.thruhere.net/koen/angstrom/systemd/beagleboardC5-ubi-201106171148.svg
http://dominion.thruhere.net/koen/angstrom/systemd/hawkboard.svg

I my case the caching wasn't needed, but if it starts taking >4s on
'slow' systems and >2s on 'fast' systems it is worth considering.

regards,

Koen
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFOBDNcMkyGM64RGpERAi2nAKCMs41YobWWtBg0SqT6RGLVeH2z0QCfTkN1
hvCaKPRpAR4HhvuHLWKRPRY=
=Uy6Y
-----END PGP SIGNATURE-----