Okay, I just got done upgrading to Slack 12 on my Inspiron 8200 using the Upgrade.txt instructions.

Everything went more or less okay, and the system boots, but once up and running it is seriously slow. The boot process itself seems to go along at a reasonable clip (although the first time it went through it also seemed really slow).

But tasks when it's up and running are unbearable. For instance, starting X (even just to get to get the server running; let alone starting KDE) and compiling the NVIDIA kernel module take an age, and /sbin/ldconfig (which I have running at shutdown) takes 10+ minutes. Seriously.

Same problem with both the SMP and non-SMP generic versions of the kernel. I haven't reverted to the huge kernel yet as I can't see how it would help.

I've run hdparm and confirmed the disk is using DMA.

Anyone experienced similar or have tips on where else to start looking? Is it possible HAL is just too taxing? Seems to me it must be something more fundamental.

Okay. More problem definition.

Having played around a bit more, it appears that applications are very, very slow to run the first time (with lots of apparent HD activity), but then if exited and run again, go very quickly. Have confirmed this with X, KDE, and Office Calc.

I don't know much about shared libraries and such, but that makes me think there's some kind of issue causing the initial linking of the shared libraries to be painfully slow. I guess once run, the linked binaries stay cached somehow?

I haven't tried running HD timings (and don't have written down what they were before to compare with), but could it be some kind of HD throughput issue peculiar to this kernel/configuration/etc?

I tried another distro once years ago that acted exactly like this, but gave up on it before I found any resolution. Given my history with Slackware (6+ years now) I'm willing to try a little longer this time around. Hopefully I'll get some help from the gurus here along the way.

Oh, and I lied about ldconfig. It takes 5+ minutes, not 10+ minutes (actually timed it).

can you expand on your HW setup? I have a inspiron 8500 I did a full slack12 install on yesterday, and its not screaming (yet - still setting things up) but its definitely not taking too long to do anything either.

my i8500 has P4 2.4GHz, 2GB RAM, 100GB travelstar HD, ati radeon 200m (?)

I8200, 2GHz, 384MB RAM, 60G HD (can't remember the details offhand), NVIDIA GeForce4 440 Go

I realize the 384GB is probably less than ideal, but I wouldn't expect it to be such an impediment for just firing up X or a single application, and it's never caused perceptible issues in 11.0

Okay,

I discovered that /etc/ld.so.conf still had the legacy /opt/kde lib directory and not the new /usr/lib/kde3 location, plus for whatever reason, there were still a bunch of libs in /opt/kde. Once I blew away /opt/kde and changed the entry in ld.so.conf, the /sbin/ldconfig step is very quick.

So, that part is sorted. However, I am concerned by the fact that I wasn't presented with an ld.so.conf.new after the upgrade to address this. Not sure if I accidentally deleted it instead of merging it, or of if this is a miss somewhere in the upgrade/instructions.

Since there may be other less glaring problems with my ld.so.conf, can someone who did a fresh Slack12 install please post theirs for me to check against?

Also, do I need to flush the ld cache in some way to optimize it after significant changes to ld.so.conf, or should it sort itself out?

Running applications is still very slow. I still wonder if this may be related to dynamic linking in some way, but I am not so sure as examining the NVIDIA binary installer with ldd shows that it is not dynamically linked, and yet it is very, very slow (to the point that I have not managed to let it complete yet). However, maybe it is calling things that *are* dynamically linked?

Thanks,

Dave

Well, I fooled myself on the ldconfig thing.

When I rebooted and then shutdown, /sbin/ldconfig took forever again.

After I altered /etc/ld.so.conf earlier I ran /sbin/ldconfig right away which took a long time, but I assumed it was because it had to update a lot of stuff (which is what I was figuring was happening with all the duplicated libraries in the old kde location). When it shutdown that time it was very quick.

It didn't dawn on me at the time that this was just the same issue that's dogging everything else (that the second time something gets run it's quick, but the first time is really slow).

So, I think the ld.so.conf thing is a red herring. Plus, I went back and looked in the packages and found ld.so.conf.new which is only two lines (/local/lib and /lib/i486-slackware-lib/ or something) and which I had in fact merged into mine.

So, what's going on? What would cause programs to be agonizingly slow the first time after a reboot and then run fine in subsequent invocations?

Dave

Almost 24 hours and no ideas yet? That's not a good sign...

I have a 3 year old P4, and found that even without anything running (not even X!) my CPU usage was ALWAYS around 25% with the default Slackware 12 kernels. This happened with the generic and huge kernels.

The "top" command showed me that it was a kernel process taking up all the CPU time (For the lif eof me, I can't remember what that process was called now). I compiled a custom kernel, and that behaviour no longer occurs.

Thanks for the reply. Actually, I just logged in to say I think I've found the problem. After reading through a few Ubuntu related posts it seems that something about the way the CD-ROM and HD are configured on the IDE bus in some Dell laptops causes the hard drive throughput to tank if HAL is running and polling the CD for media insertion. I disabled HAL (chmod -x rc.hald) and everything seems to run as I'd expect. Running hdparm -t I get ~10-15 MB/sec while HAL is running and ~20 MB/sec without. The difference in machine speed in use is about an order of magnitude more noticeable.

That's somewhat disappointing as HAL functionality was part of the motivation for upgrading, but maybe there's a way to tweak HAL that maintains most of the functionality without causing that particular issue.

I did look at top early on and didn't see anything untoward, but I'll have a closer look now that the HAL thing appears to be corrected.