Re: udev 171 caching working propely?

[Koen Kooi <koen@dominion.thruhere.net>]

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

On 24-06-11 16:49, Andreas Mueller wrote:
> On Friday, June 24, 2011 08:49:00 AM Koen Kooi wrote:
>> 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-201106
>> 171148.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.
>>
> News from udev-journey: 
> 
> I did modify the udev-init script so that I could see that  
> 
> | udevadm trigger ; udevadm settle 
> 
> lasted for ~10s!
> 
> That made me think (usually that is not my domain..); Why is my board so slow 
> and why refuses udev to work proper for it? Checking all written I fell over 
> udev msg in one of my previous mails
> 
> | insmod /lib/modules/2.6.38.5/kernel/drivers/usb/host/ehci-hcd.ko
> 
> So I decided to change in kernel-config
> -CONFIG_USB_HID=m
> +CONFIG_USB_HID=y
> 
> -CONFIG_USB_EHCI_HCD=m
> +CONFIG_USB_EHCI_HCD=y
> 
> This make the tx28 board now working very similar to my overo board: USB devices 
> are detected at a very early state of boot and udev is much faster now and USB 
> is working as expected. Also hotplugging seems to work.

It does make the kernel boot ±1.5s slower, but that will still give you
a big win in userspace.

> I would say it's 
> partytime but still there is
> 
> | udevd[588]: error: runtime directory '/run/udev' not writable, for now falling 
> back to '/dev/.udev'
> | <30>udevd[589]: starting version 171

We don't support /run in oe.dev yet, the oe-core version of angstrom
does since it's required for systemd support.

regards,

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

iD8DBQFOBLCIMkyGM64RGpERAlYQAJ0fbU+ruFljsfkXcB2x2Uki+T4yzgCgroEa
tDe2l4nnMZAyp+Ag7tQKcEQ=
=w2Xr
-----END PGP SIGNATURE-----