Initializing hardware... slow

[Bojan Smojver]

Is that just my box, or did this part of the boot become painfully slow 
as of recent? It takes around half a minute to do "storage hardware 
audio" thingy. Has anyone else noticed something like that?

-- 
Bojan

[G.Wolfe Woodbury]

On Fri, Nov 25, 2005 at 02:31:09PM +1100, Bojan Smojver wrote:
>  Is that just my box, or did this part of the boot become painfully
> slow 
>  as of recent? It takes around half a minute to do "storage hardware 
>  audio" thingy. Has anyone else noticed something like that?
>  
>  -- 
>  Bojan 
Yes, I've noticed it recently too.

-- 
G.Wolfe Woodbury     `- -'
RHCT                   U
The Line Eater is a boojum!

[Clyde E. Kunkel]

Bojan Smojver wrote:
>  Is that just my box, or did this part of the boot become painfully
> slow 
>  as of recent? It takes around half a minute to do "storage hardware 
>  audio" thingy. Has anyone else noticed something like that?
>   
Yep...very slow.  As is hal (already noted elsewhere).

-- 
Regards,

Old Fart

[Paul Ionescu]

On Fri, 25 Nov 2005 14:31:09 +1100, Bojan Smojver wrote:

>  Is that just my box, or did this part of the boot become painfully
> slow as
>  of recent? It takes around half a minute to do "storage hardware audio"
>  thingy. Has anyone else noticed something like that?
>  
>  -- 
>  Bojan 
Yeap, slow here too.

[Harald Hoyer]

Bojan Smojver wrote:
>  Is that just my box, or did this part of the boot become painfully
> slow 
>  as of recent? It takes around half a minute to do "storage hardware 
>  audio" thingy. Has anyone else noticed something like that?
>   
could you please try:

ftp://people.redhat.com/harald/udev/udev-075-5.src.rpm

[Nicolas Mailhot]

Le vendredi 25 novembre 2005 à 13:10 +0100, Harald Hoyer a écrit :
>  Bojan Smojver wrote:
>  > Is that just my box, or did this part of the boot become painfully slow 
>  > as of recent? It takes around half a minute to do "storage hardware 
>  > audio" thingy. Has anyone else noticed something like that?
>  > 
>  
>  could you please try:
>  
>  ftp://people.redhat.com/harald/udev/udev-075-5.src.rpm 
Everything is slow not just boot there. Just like if someone stole the
CPU one night and replaced it with a slower one. And this version of
udev does not change anything.

(sharpest difference in firefox : clicking on any link takes several
seconds instead of being almost instantaneous before)

I suspect the kernel more than anything else.

-- 
Nicolas Mailhot

[Rahul Sundaram]

Hi

> Everything is slow not just boot there. Just like if someone stole
> the
> CPU one night and replaced it with a slower one. And this version of
> udev does not change anything.
>
> (sharpest difference in firefox : clicking on any link takes several
> seconds instead of being almost instantaneous before)
>
> I suspect the kernel more than anything else.
>
>   
>  
Would you try running bootchart on it (http://bootchart.sf.net) and 
produce the output? . That might help

regards
Rahul

[Nicolas Mailhot]

Le samedi 26 novembre 2005 à 01:03 +0530, Rahul Sundaram a écrit :
>  Hi
>  
>  >Everything is slow not just boot there. Just like if someone stole the
>  >CPU one night and replaced it with a slower one. And this version of
>  >udev does not change anything.
>  >
>  >(sharpest difference in firefox : clicking on any link takes several
>  >seconds instead of being almost instantaneous before)
>  >
>  >I suspect the kernel more than anything else.
>  >
>  >  
>  >
>  Would you try running bootchart on it (http://bootchart.sf.net) and 
>  produce the output? . That might help 
I doubt it would help - the slowdown is not limited to the boot process.
Do you think it will find anything useful ?

-- 
Nicolas Mailhot

[Rahul Sundaram]

Hi

> I doubt it would help - the slowdown is not limited to the boot process.
> Do you think it will find anything useful ?
>
>   
>  
Its worth trying. Just a suggestion.

regards
Rahul

[Nicolas Mailhot]

Le samedi 26 novembre 2005 à 02:25 +0530, Rahul Sundaram a écrit :
>  Hi
>  
>  >
>  >I doubt it would help - the slowdown is not limited to the boot process.
>  >Do you think it will find anything useful ?
>  >
>  >  
>  >
>  Its worth trying. Just a suggestion. 
Seems related to network calls

ntp startup is sloooow
httpd startup -> same
gaim startup -> anemic (btw the latest arts is missing lnusertemp, which
exposes the well-documented stupidity of having gnome sound depend on
kde subsystems)

I'll try bootstart tomorrow - rawhide today is so broken I'm pretty
disgusted (gaim/arts/mcop, gdm, selinux, slow startup) If I don't do
something else now I'll start writing rude things on the list.

I don't mind a new bug a day but several in a row like this before I've
even finished investigating the first one is too much for me. You got to
love the destabelizing effect of test 1 - every Red Hat packager seems
to have postponed his experimental packages for after test1 was
released.

-- 
Nicolas Mailhot

[Rahul Sundaram]

Hi

> I don't mind a new bug a day but several in a row like this before
> I've
> even finished investigating the first one is too much for me. You got to
> love the destabelizing effect of test 1 - every Red Hat packager seems
> to have postponed his experimental packages for after test1 was
> released.
>   
>  
If they did that, I wouldnt be too suprised with it as long as we 
managed to resolve any regressions before the next test release. Anyone 
up for a bug triaging day to ensure that?

http://fedoraproject.org/wiki/BugZappers.

regards
Rahul

[Bojan Smojver]

On Fri, 2005-11-25 at 22:13 +0100, Nicolas Mailhot wrote:

>  Seems related to network calls
>  
>  ntp startup is sloooow
>  httpd startup -> same
>  gaim startup -> anemic (btw the latest arts is missing lnusertemp, which
>  exposes the well-documented stupidity of having gnome sound depend on
>  kde subsystems) 
How's your DNS? This could all be related to invalid DNS servers
in /etc/resolv.conf.

>  I'll try bootstart tomorrow - rawhide today is so broken I'm
> pretty
>  disgusted (gaim/arts/mcop, gdm, selinux, slow startup) If I don't do
>  something else now I'll start writing rude things on the list.
>  
>  I don't mind a new bug a day but several in a row like this before I've
>  even finished investigating the first one is too much for me. You got to
>  love the destabelizing effect of test 1 - every Red Hat packager seems
>  to have postponed his experimental packages for after test1 was
>  released. 
If things like this make you upset, maybe you shouldn't be running
Rawhide. It is (unfortunately) not possible to find bugs without
delivering software to users.

-- 
Bojan

[Nicolas Mailhot]

Le samedi 26 novembre 2005 à 13:33 +1100, Bojan Smojver a écrit :
>  On Fri, 2005-11-25 at 22:13 +0100, Nicolas Mailhot wrote:
>  
>  > Seems related to network calls
>  > 
>  > ntp startup is sloooow
>  > httpd startup -> same
>  > gaim startup -> anemic (btw the latest arts is missing lnusertemp, which
>  > exposes the well-documented stupidity of having gnome sound depend on
>  > kde subsystems)
>  
>  How's your DNS? This could all be related to invalid DNS servers
>  in /etc/resolv.conf. 
Thanks, should have thought of it, the first entry was dead.
Though nscd was running, and some of the side-effects were distinctly
weird (why should dns slow down gnome-term startup when there is a local
cache on the system ?)

>  > I'll try bootstart tomorrow - rawhide today is so broken
> I'm pretty
>  > disgusted (gaim/arts/mcop, gdm, selinux, slow startup) If I don't do
>  > something else now I'll start writing rude things on the list.
>  > 
>  > I don't mind a new bug a day but several in a row like this before I've
>  > even finished investigating the first one is too much for me. You got to
>  > love the destabelizing effect of test 1 - every Red Hat packager seems
>  > to have postponed his experimental packages for after test1 was
>  > released.
>  
>  If things like this make you upset, maybe you shouldn't be running
>  Rawhide. It is (unfortunately) not possible to find bugs without
>  delivering software to users. 
Things are not black and white. I don't mind new bugs. I do mind hitting
bugs/problems reported since before FC4 (making gnome depends on arts)
or discussed on the list in the days before packages are released (the
long thread about people not wanting core fonts mandatory didn't stop
mharris from releasing a modular X that crashed because of core font
stuff) or obvious checks the maintainer skipped before inflicting
breakage on everyone (arts changelog reads "4 nov fix lnusertemp
problem", "14 nov fix lnusertemp", and on the 24th a new version with
broken lnusertemp is released - how difficult would it have been to
check lnusertemp before puching a new package ?)

So yes it's RawHide. Yes it's not supposed to be perfect and some
breakage is acceptable. But no that does not mean packagers don't have
to check their stuff and make sure it's dogfoodable. If only out of
respect to the scores of poor loosers like me that try do do serious
testing and bug reporting. Because I can say too 'it's rawhide, it's
supposed to be broken, I won't spend time reporting anything' and
complain loudly when the stuff I didn't report appears in FC/RHEL.

So you see this cuts both ways. If Red Hat wants free QA and testing Red
Hat has to deliver something that can be tested. Writing "Raw hide will
eat your brainz" is a bit too easy. Easy and convenient, but false.
Especially when a release is entering its testing phase.

And BTW I don't have any axe to grind with the people who made the
mistakes I listed. Everyone makes mistakes now and then. But I won't let
write that because it's RawHide there is no need to acknowledge any
problem, and testers should not be upset when well-known issues are
pushed to rawhide. There are enough new bugs to find without having to
report the same stuff again and again.

-- 
Nicolas Mailhot

[Bojan Smojver]

On Fri, 2005-11-25 at 13:10 +0100, Harald Hoyer wrote:

>  could you please try:
>  
>  ftp://people.redhat.com/harald/udev/udev-075-5.src.rpm 
This one is better _and_ worse. The "Initialising hardware" phase is
quick, but "Starting udev" takes about a minute. I'm attaching my dmesg,
lsmod and lspci output, if that helps at all.

This seems a bit worrying (from dmesg):
--------------------------
AC'97 1 does not respond - RESET
AC'97 1 access is not valid [0xffffffff], removing mixer.
ali mixer 1 creating error.
--------------------------

-- 
Bojan