On Mon, May 23, 2011 at 06:32, Chen Jie wrote:
> 2011/5/20 Kay Sievers :
>> Why is blkid called 11 times? You have that many partitions?
> I guess, sda-sda4 plus loop0-7 and plus ram0-ram15.
What do you need 16 ramdisks for? Not sure if anything today should use them.
> I collect all block dev
2011/5/20 Lennart Poettering :
> On Fri, 20.05.11 17:40, Chen Jie (ch...@lemote.com) wrote:
>
>> 2011/5/19 Chen Jie :
>> > 2011/5/18 Kay Sievers :
>> >>
>> >> Completely different! That's an Intel Core Duo 1.4 GHz laptop:
>> >> systemd-analyze blame | grep udev
>> >> 87ms udev-trigger.service
>>
于 2011年05月21日 00:50, Harald Hoyer 写道:
> Am 20.05.2011 18:49, schrieb microcai:
>> 于 2011年05月20日 23:35, Kay Sievers 写道:
>>> On Fri, May 20, 2011 at 17:32, microcai
>>> wrote:
>>>
Now I've full relized that, the problem is fsck-root.service.
udev.service stay idle as soon as fsck-root
Am 20.05.2011 18:49, schrieb microcai:
于 2011年05月20日 23:35, Kay Sievers 写道:
On Fri, May 20, 2011 at 17:32, microcai wrote:
Now I've full relized that, the problem is fsck-root.service.
udev.service stay idle as soon as fsck-root.service exit.
It is fsck-root.service that took so long to do
于 2011年05月20日 23:35, Kay Sievers 写道:
> On Fri, May 20, 2011 at 17:32, microcai wrote:
>
>> Now I've full relized that, the problem is fsck-root.service.
>>
>> udev.service stay idle as soon as fsck-root.service exit.
>>
>> It is fsck-root.service that took so long to do the job.
>
> Check that t
On Fri, May 20, 2011 at 17:32, microcai wrote:
> Now I've full relized that, the problem is fsck-root.service.
>
> udev.service stay idle as soon as fsck-root.service exit.
>
> It is fsck-root.service that took so long to do the job.
Check that the clock is right, that rtc is set by the kernel:
于 2011年05月20日 12:10, microcai 写道:
> 于 2011年05月20日 18:39, Lennart Poettering 写道:
>> On Fri, 20.05.11 17:40, Chen Jie (ch...@lemote.com) wrote:
>>
>>> 2011/5/19 Chen Jie :
2011/5/18 Kay Sievers :
>
> Completely different! That's an Intel Core Duo 1.4 GHz laptop:
> systemd-analyze bl
于 2011年05月20日 18:39, Lennart Poettering 写道:
> On Fri, 20.05.11 17:40, Chen Jie (ch...@lemote.com) wrote:
>
>> 2011/5/19 Chen Jie :
>>> 2011/5/18 Kay Sievers :
Completely different! That's an Intel Core Duo 1.4 GHz laptop:
systemd-analyze blame | grep udev
87ms udev-trigger.se
On Fri, May 20, 2011 at 11:40, Chen Jie wrote:
> 2011/5/19 Chen Jie :
>> 2011/5/18 Kay Sievers :
>>>
>>> Completely different! That's an Intel Core Duo 1.4 GHz laptop:
>>> systemd-analyze blame | grep udev
>>> 87ms udev-trigger.service
>>> 13ms udev.service
>> I updated systemd(to v26) and udev
On Fri, 20.05.11 17:40, Chen Jie (ch...@lemote.com) wrote:
> 2011/5/19 Chen Jie :
> > 2011/5/18 Kay Sievers :
> >>
> >> Completely different! That's an Intel Core Duo 1.4 GHz laptop:
> >> systemd-analyze blame | grep udev
> >> 87ms udev-trigger.service
> >> 13ms udev.service
> > I updated syste
于 2011年05月20日 17:40, Chen Jie 写道:
> 2011/5/19 Chen Jie :
>> 2011/5/18 Kay Sievers :
>>>
>>> Completely different! That's an Intel Core Duo 1.4 GHz laptop:
>>> systemd-analyze blame | grep udev
>>> 87ms udev-trigger.service
>>> 13ms udev.service
>> I updated systemd(to v26) and udev(to 168), stil
2011/5/18 Kay Sievers :
>
> Completely different! That's an Intel Core Duo 1.4 GHz laptop:
> systemd-analyze blame | grep udev
> 87ms udev-trigger.service
> 13ms udev.service
I updated systemd(to v26) and udev(to 168), still got ~1s startup time
of udev.service plus udev-trigger.service.
May be
于 2011年05月19日 13:24, Canek Peláez Valdés 写道:
> On Wed, May 18, 2011 at 11:58 PM, microcai wrote:
>> 于 2011年05月18日 21:59, Canek Peláez Valdés 写道:
>>> On Wed, May 18, 2011 at 5:14 AM, microcai
>>> wrote:
>>> [...]
I'm not saying to rip-out udev, but speed up the udev.
>>>
>>> It's probably no
On Wed, May 18, 2011 at 11:58 PM, microcai wrote:
> 于 2011年05月18日 21:59, Canek Peláez Valdés 写道:
>> On Wed, May 18, 2011 at 5:14 AM, microcai wrote:
>> [...]
>>> I'm not saying to rip-out udev, but speed up the udev.
>>
>> It's probably not udev fault, but a udev rule in Gentoo (I suppose you
>>
于 2011年05月18日 21:59, Canek Peláez Valdés 写道:
> On Wed, May 18, 2011 at 5:14 AM, microcai wrote:
> [...]
>> I'm not saying to rip-out udev, but speed up the udev.
>
> It's probably not udev fault, but a udev rule in Gentoo (I suppose you
> use Gentoo, you mentioned an overlay) that calls an OpenRC
On Wed, May 18, 2011 at 15:46, Chen Jie wrote:
> 2011/5/18 Kay Sievers :
>> On Wed, May 18, 2011 at 14:18, Chen Jie wrote:
>>> 2011/5/18 Kay Sievers :
>>
udev.service does usually takes no time. It's the settle that may
block for a longer time. In your chart it seems like a side-effect,
On Wed, May 18, 2011 at 5:14 AM, microcai wrote:
[...]
> I'm not saying to rip-out udev, but speed up the udev.
It's probably not udev fault, but a udev rule in Gentoo (I suppose you
use Gentoo, you mentioned an overlay) that calls an OpenRC script.
That slows down the whole boot for whole minute
On Wed, May 18, 2011 at 14:18, Chen Jie wrote:
> 2011/5/18 Kay Sievers :
>> udev.service does usually takes no time. It's the settle that may
>> block for a longer time. In your chart it seems like a side-effect,
>> and the root-fsck seems suspicious. any idea what could take so long
>> here? Car
On Wed, May 18, 2011 at 11:37, microcai wrote:
> udev and systemd are from systemd overlay.
>
> udev is udev-168-r1
> systemd is systemd-26
>
> All compiled with CFLAGS="-Os -march=native"
>
> systemd-analyze plot have problem generationg SVG file, so I change the
> code to make a PDF.
>
>
> Will
于 2011年05月18日 17:54, fykc...@gmail.com 写道:
> Hi,
>
> udev.service doesn't include 'settle' action, it is simplely because
> udev starting/adding spends some time.
>
> Many services depends on udev directly or indirectly, so the boot
> process is serialized when udev starting.
>
> Currently, syst
Hi,
udev.service doesn't include 'settle' action, it is simplely because
udev starting/adding spends some time.
Many services depends on udev directly or indirectly, so the boot
process is serialized when udev starting.
Currently, systemd is deeply integrated with udev, it was not easy to
"First
OK, here is my problem:
udev and systemd are from systemd overlay.
udev is udev-168-r1
systemd is systemd-26
All compiled with CFLAGS="-Os -march=native"
systemd-analyze plot have problem generationg SVG file, so I change the
code to make a PDF.
Will anyone please lookat my boot analyze PDF?
22 matches
Mail list logo
