From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [80.91.229.2] (helo=ciao.gmane.org) by linuxtogo.org with esmtp (Exim 4.69) (envelope-from ) id 1L8IEj-0008Dj-N6 for openembedded-devel@openembedded.org; Thu, 04 Dec 2008 18:43:37 +0100 Received: from root by ciao.gmane.org with local (Exim 4.43) id 1L8IBG-0006Ey-EV for openembedded-devel@openembedded.org; Thu, 04 Dec 2008 17:40:02 +0000 Received: from s55917625.adsl.wanadoo.nl ([85.145.118.37]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 04 Dec 2008 17:40:02 +0000 Received: from k.kooi by s55917625.adsl.wanadoo.nl with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 04 Dec 2008 17:40:02 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: openembedded-devel@openembedded.org From: Koen Kooi Date: Thu, 04 Dec 2008 18:35:10 +0100 Message-ID: References: <20081204161543.GT16628@smtp.west.cox.net> Mime-Version: 1.0 X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: s55917625.adsl.wanadoo.nl User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20081130 Shredder/3.0b1pre In-Reply-To: <20081204161543.GT16628@smtp.west.cox.net> Sender: news Subject: Re: invalidating udev cache, how? X-BeenThere: openembedded-devel@lists.openembedded.org X-Mailman-Version: 2.1.11 Precedence: list Reply-To: openembedded-devel@lists.openembedded.org List-Id: Using the OpenEmbedded metadata to build Distributions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Dec 2008 17:43:37 -0000 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 04-12-08 17:15, Tom Rini wrote: > On Thu, Dec 04, 2008 at 05:05:58PM +0100, Koen Kooi wrote: >> Hi, >> >> The udev 124 has cache (/etc/dev.tar) to avoid doing the coldplug udev >> dance that can take a few seconds to a minute depending on machine speed >> and kernel options. It is working a bit too well at the moment: >> >> * user boots image with 2.6.26 kernel on an omap board >> * user gets /dev/fb0 >> * user fixes the bootargs in uboot to enable the overlay >> * user doesn't get /dev/fb1 >> >> so remove /etc/dev.tar and reboot: /dev/fb1 appears. >> >> I also encountered a case where the permissions on /dev/null where wrong >> during first boot (it's a mystery why that happened) and udev cached >> those making ssh daemons fail on boot. >> >> My current ideas: >> >> 1) remove /etc/dev.tar if its> x weeks old >> 2) recreate it on shutdown >> 3) remove it after x times >> >> option 1) breaks on systems without an RTC and/or no /etc/timestamp >> option 2) moves the slowness to shutdown >> option 3) requires extra logic and filesystem access >> >> and all options don't fix the first case I mentioned, they all take a >> while to make /dev/fb1 appear. >> >> The key is that it should be transparent to users, so adding a check for >> .e.g 'ignore_dev.tar=1' in bootargs wouldn't work, since that implies >> that users are aware of the problem and know how to 'fix' it. >> >> Does anyone have other ways to invalidate the cache, and if not, which >> option would get your vote? > > 2 is a different (and perhaps not as) slow. Also, prepopulate the cache > with fb1? Or is this all done on the live system with nothing done > during image creation? It's done during first boot, since as the problem points out everything is highly dependant on bootloader/kernel/moonphase. regards, Koen