Bugzilla – Bug 143231
Software management application take a long time to start
Last modified: 2006-05-11 13:32:07 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.
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.
Any Comments?
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.
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.
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.
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 ***