Bug 143231

Summary:	Software management application take a long time to start
Product:	[openSUSE] SUSE LINUX 10.0	Reporter:	Mark Haverkamp <markh>
Component:	Hotplug	Assignee:	Jiri Srain <jsrain>
Status:	RESOLVED DUPLICATE	QA Contact:	E-mail List <qa-bugs>
Severity:	Major
Priority:	P5 - None	CC:	ihno
Version:	unspecified
Target Milestone:	---
Hardware:	PowerPC-64
OS:	SuSE Linux 10.0
Whiteboard:
Found By:	Other	Services Priority:
Business Priority:		Blocker:	---
Marketing QA Status:	---	IT Deployment:	---

Description Mark Haverkamp 2006-01-13 22:45:59 UTC

Hotplug as a component is just a guess.

This seems to be related to having a large number of devices configured.
I have an emulex lp10000 fibrechannel controller connected to 16000 fibrechannel LUNs on a netapp filer. Normally if I run the yast2 program and select Software Management the window opens in a few seconds. Once I have loaded the lpfc module and have the 16000 devices configured, selecting the "Software Management" option takes hours to open the window. The last time I tried, I went home after two hours and when I came in the next morning the window had opened. So far today I have been waiting four hours.

Here is all that I know so far:

Once I probe the 16000 devices hald is using 95+% of a CPU all of the time. There is continous access to the fibrechannel devices (I am monitoring the switch). When I click on "software management" I start seeing this in the window where I started yast2:

===
4911: arguments to dbus_message_new_method_call() were incorrect, assertion "_dbus_check_is_valid_path (path)" failed in file dbus-message.c line 796.
This is normally a bug in some application using the D-BUS library.
libhal.c 360 : Couldn't allocate D-BUS message
4911: arguments to dbus_message_new_method_call() were incorrect, assertion "_dbus_check_is_valid_path (path)" failed in file dbus-message.c line 796.
This is normally a bug in some application using the D-BUS library.
libhal.c 360 : Couldn't allocate D-BUS message
4911: arguments to dbus_message_new_method_call() were incorrect, assertion "_dbus_check_is_valid_path (path)" failed in file dbus-message.c line 796.
This is normally a bug in some application using the D-BUS library.
libhal.c 360 : Couldn't allocate D-BUS message
====
this pretty much continues all the time.

I had to update my kernel to 2.6.15 and the udev to 080. The kernel and udev that came with the distribution wouldn't reliably probe all the devices.

If you need my .config I can send it. But it is based on config-2.6.13-15.7-ppc64 which was the original installed kernel.

Comment 1 Ihno Krumreich 2006-02-15 11:43:15 UTC

Have a look at /var/log/YaST/y2log. You woill see that the libstorage of yast will look which devices are there. This of course need some time for 16000
devices. So its a known Problem.

Comment 2 Ihno Krumreich 2006-03-14 15:14:45 UTC

Any Comments?

Comment 3 Mark Haverkamp 2006-03-14 15:25:47 UTC

I'm not sure what I can say.  
If I had a system with a large number of disks attached, I'd find the system unusable in its current state.

Comment 4 Ihno Krumreich 2006-03-23 12:12:38 UTC

Just looked with Thomas Fehr at the code.
The basic problem is that the libstorage is called to find out how much space in the different filesystems is.
At installation time there is no other way.
But if the module is called in running system df could be used to get the relevant information.

Comment 5 Thomas Fehr 2006-03-23 12:58:26 UTC

Jiri, the call to Storage::GetTargetMap() is pretty expensive on system with
many disks since libstorage needs to detect all block devices. 

The call is unavoidable during installation (since the filesystems are not yet
mounted or even existing) but in an installed System you could get the active
mount points and the available space also by a simple call to "df". So you would
not need to call GetTargetMap() at all which would speed up Software selection a 
lot in a running system (where software selection is called mostly).

I changed Storage.ycp to lazy initialisation so that libstorage does not get
initialized in the constructor but during the first call to GetTargetMap(). 
So if you change anything be sure to use Storage.ycp from SVN for testing.

Comment 6 Jiri Srain 2006-05-11 13:32:07 UTC

There is nothing I could do about it in the SLE10 timeframne. Will treat it as an enhancement for 10.2, resp. SP1.

*** This bug has been marked as a duplicate of 159888 ***