All of lore.kernel.org
 help / color / mirror / Atom feed
From: Koen Kooi <koen@dominion.thruhere.net>
To: openembedded-devel@lists.openembedded.org
Subject: Re: udev 171 caching working propely?
Date: Thu, 23 Jun 2011 23:58:53 +0200	[thread overview]
Message-ID: <iu0cut$d9l$1@dough.gmane.org> (raw)
In-Reply-To: <201106232258.06911.schnitzeltony@gmx.de>

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

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?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFOA7cdMkyGM64RGpERAub2AJ47tGaHALda34rOoO0MGNDr89lbmQCbBalb
+VSu74kvsk3SAmOPqELwutE=
=sK95
-----END PGP SIGNATURE-----




  reply	other threads:[~2011-06-23 22:02 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-06-20 21:16 udev 171 caching working propely? Andreas Mueller
2011-06-20 22:47 ` Tom Rini
2011-06-21 21:31   ` Tom Rini
2011-06-23 20:58     ` Andreas Mueller
2011-06-23 21:58       ` Koen Kooi [this message]
2011-06-23 22:52         ` Andreas Mueller
2011-06-24  6:49           ` Koen Kooi
2011-06-24 14:49             ` Andreas Mueller
2011-06-24 15:43               ` Koen Kooi

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='iu0cut$d9l$1@dough.gmane.org' \
    --to=koen@dominion.thruhere.net \
    --cc=openembedded-devel@lists.openembedded.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.