After I boot up into 11.4, the desktop/icons appear but then there is a delay of about 20 - 30 seconds before the bottom-right task bar items appear. During that time, I can’t start any applications. This happens on both desktop PC’s, very frustrating and not present with 11.3. Has anybody else seen this? Is there a fix?
I assume that you mean after boot AND login. Does it not happen after a logout and login again? In other words is this bound to the (maybe an automatic) login right after a boot?
I am guessing that you mean the desktop appears but the delay is the time before you are able to use it?
I had the same problem and removed pulse audio and the problem went away - so I would guess that it was that that caused the problem. The simple test is the time it takes from when the desktop appears to when you hear the kde welcome sound. If you want to give it a try open yast and remove all pulse rpm’s besides libpulse, libpulse 32 bit and libpulse mailnloop.
Same problem with me.It delays too long.Everything exept mouse seem to be hang.I try to update kernel to 2.6.38,KDE 4.6.1,still not hang.I’ve post a simular post but not answer.
Opensuse in my laptop also have a problem.Sometimes,when I start up.I received a report Disabling IRQ #17.After,the extend mouse hang (while touchpad is OK),I can’t change volume.
Please help.
I’ve experienced this 20 second delay also. It does seem to be related to sound as the start up sound is also delayed 20 sec. But for me, it doesn’t happen all the time.
When I booted up this morning, sound started at the same time as the desktop appeared.
My saved session includes an open xterm. That xterm appears fairly early, and I can then start applications from the xterm. However, I cannot start them with the mouse until I hear the opening sound, and that does seem to take forever to show up.
Initially, there was an additional complication on my laptop. After the xterm showed up, and I tried to do something in the xterm window, I was interrupted by kdewallet. However, I have since reconfigured the network manager plasmoid to keep the network keys unencrypted, so that kdewallet is not needed during startup.
If I logout from KDE, then login again, everything starts up much faster the second time. There is very little delay.
Here are some logs from my last desktop bootup:
Mar 27 11:48:41 nwr2 kernel: 154.067834] i2c i2c-2: sendbytes: NAK bailout.
Mar 27 11:52:46 nwr2 pulseaudio[7672]: pid.c: Daemon already running.
Mar 27 11:52:46 nwr2 pulseaudio[7683]: pid.c: Daemon already running.
Mar 27 11:52:46 nwr2 pulseaudio[4883]: module.c: Module "module-device-manager" should be loaded once at most. Refusing to load.
You can see the 4 minute delay between an event that happened soon after boot, and the setup of pulseaudio.
It looks to me as if there is something funky about the way that pulseaudio is starting. Why is it generating those logs?
Incidently, those logs come from running xconsole. It is my impression that only warning and above severity is logged to xconsole.
Can you provide a slightly longer output from the desktop bootup than the 3 lines? Make it at least 8 lines in both directions around the 4 minute gap.
Reality is the system just didn’t feel like writing a message for 4 minutes, IOW, the system does write messages every 1 sec. I’m not sure when or why its writing messages but there’s plenty of time gaps in the logs files. Open “L Reality is thatog File Viewer”, add the /var/log/messages file and you can see when the message file is populated.
Output from Dmesg or /var/log/boot.msg might be more helpful.
Please use the [foo] wrappers [/foo] replacing “foo” with code
or
SUSE Paste to paste your output.
As I had said, those messages came from running xconsole, not from a log file. And it was a complete listing of early records on xconsole. However, I have now checked /var/log/messages, so here’s a more complete list from there:
Mar 27 11:48:41 nwr2 kernel: 154.067834] i2c i2c-2: sendbytes: NAK bailout.
Mar 27 11:52:29 nwr2 polkitd(authority=local): Unregistered Authentication Agent for unix-session:/org/freedesktop/ConsoleKit/Session1 (system bus name :1.29, object path /org/kde/PolicyKit1/AuthenticationAgent, locale en_US.UTF-8)
Mar 27 11:52:29 nwr2 kernel: 382.249512] [drm] nouveau 0000:00:05.0: nouveau_channel_free: freeing fifo 1
Mar 27 11:52:29 nwr2 acpid: client 1584[0:0] has disconnected
Mar 27 11:52:29 nwr2 acpid: client connected from 7393[0:0]
Mar 27 11:52:29 nwr2 acpid: 1 client rule loaded
Mar 27 11:52:30 nwr2 kernel: 382.632714] [drm] nouveau 0000:00:05.0: Allocating FIFO number 1
Mar 27 11:52:30 nwr2 kernel: 382.633305] [drm] nouveau 0000:00:05.0: nouveau_channel_alloc: initialised FIFO 1
Mar 27 11:52:35 nwr2 checkproc: checkproc: can not get session id for process 2133!
Mar 27 11:52:46 nwr2 pulseaudio[7672]: pid.c: Daemon already running.
Mar 27 11:52:46 nwr2 pulseaudio[7683]: pid.c: Daemon already running.
Mar 27 11:52:46 nwr2 pulseaudio[4883]: module.c: Module "module-device-manager" should be loaded once at most. Refusing to load.
There were also a bunch of unimportant firewall records, which are only in “/var/log/messages” because of a bug in rsyslogd. I removed those, because they are only clutter. But they do fill in the gaps. The system wasn’t completely idle in that interval.
Output from “dmesg” is mostly firewall records. Output from “dmesg” and records in “boot.msg” do not have time stamps, so it is difficult to correlate them with the delays in login to KDE. What is in boot.msg probably all happened before any of the log records that I posted.
Thank you all for the info. Getting rid of Pulse Audio has done the trick 
I had this problem until i installed proprietary drivers for my graphic card (ati).
@nrickert
Thanks for the explanation.
I see in common
**Mar 27 11:48:41 nwr2 kernel: 154.067834] i2c i2c-2: sendbytes: NAK bailout**
I don’t know i2c-2 or kernel nwr2.
I’m pretty sure that the “kernel” indicates that this is logged by the kernel. And i2c is some sort of bus driver, though I don’t know where it fits in. I see those messages popping up on occasion, but they don’t seem to obviously correlate with anything that I am aware that I am doing.
I originally posted logs just to document that there is a delay. Others seem to be suggesting that it is pulseaudio. Apart from the delay, I am not having problems with pulse. And even the delay would not bother me, except for another problem - if I look at the system tray (which is normally hidden) during that delay, then sometimes the audio icon never shows up there. So I have to avoid using the tray and panel until after the sound has been heard.
I think its your network adapter waiting on an acknowledgment “NAK” from somewhere. The adapter sent a message hasn’t gotten a reply so sent a negative acknowledgment. Could be that manual IFUP, KnetworkManager or NetworkManager is just starting and its waiting for a reply from your router or modem.
If you are referring to the i2c log, then I doubt that it is network related.
The most recent i2c log was at 13:50 today (almost 4 hours ago). The computer was idle at the time, though I was logged into KDE.
Took a glance at wiki, i2c aren’t network adapters, though it’s still waiting on that NAK. That’s all I see in common with your delays.
Maybe those i2c logs you have will tell you more.
I had exactly this problem. As someone else suggested, the problem for me was with pulse audio. I found the simplest solution was to disable pulse in YaST (Sound, “Other” button, Pulse Audio Configuration, Disable Pulse Audio).
To be more specific about the symptoms, the delay was 20-30 seconds, and during that time there is no mixer icon in the tray, and any app buttons clicked do not start the app until after the delay. After they delay, the mixer appears, the welcome sound plays and the launched apps get started. There is no significant CPU activity during the delay (like a timeout).
(This is with a fresh install of SUSE 11.4).
This same (see nick_battle a.o.) problem still persists in a freshly installed openSUSE 12.2.
The solution of uninstalling all pulse related packages except libpulse stuff worked great for me.
the sound still works for everything and my full boot is now down to a mere 13 to 14 seconds.