On Friday 27 January 2006 18:35, Martin Soltau wrote:
Well, currently I'm a little reluctant to change the PSU or look into hardware
Even if the system were only 1 month old, it could still be the memory, the PSU or a flaky drive. You have to focus on the symptoms.
- The problem occured during "restarts" (no cold boot) as well.
I thought it also locked up when you attempted disk to disk large file transfers? That stresses the memory, the hard drives *and* the PSU. Before you tinker with the software, you first need to rule out these possibilities. That is the logical troubleshooting sequence.
- The CD/DVD-Drives are as well 10 months "young" (as the rest of the box) - IF circuits are starved during POST, then there should (to my understanding) be NO difference regarding their behaviour, no matter which Runlevel I boot to.
Not true. There are many POSTs, not just the primary one built into the mainboard. Each device with built-in logic and a controller has it's own capabilities and requirements for successfully initializing. If one detects insufficient voltage immediately after power-on (fails it's internal POST) it can reset itself many times over until the problem it is detecting has passed. The question is, does it sometimes take too long and cause the device (or the whole sequence) to error out? This is one kind of scenario that could explain the *randomness* of the freezes after boot.
Even with booting to Lv 3 and then switching to 5 the hardware should then be out of normal operating and cause a hang on KDE startup. Shouldn't it? I mean: POST is WAY before and whatever would go wrong there should remain so, regardless of the initial runlevel...
10.0 uses a preloading technique that is designed to dramatically reduce boot times. When booting directly to run level 5, I suspect your primary system drive is undertaking a sustained high bandwidth transfer rate... one that is lasting long enough to freeze the system in *exactly the same way* that it is freezing when you test large file disk to disk transfers. I repeat: this can easily be the memory, the PSU or a flaky hard drive.
ATI x300 is a passively cooled low level entry card that should be one of the easiest to handle for the PSU - I think.
Agreed.
So I still think it is a race condition between KDE and the not comlpletely startet modules like ALSA, ACPI, HAL daemon, keymap or something like these.
*Except* for two considerations: These kinds of modules are usually pretty flexible with respect to timing... they have to be, since they deploy into all kinds of environments (new and old hardware, all kinds of brands and quality.) Cooperating with each other during boot is a fundamental design consideration. Secondly, I would really expect a software problem to leave *some* kind of evidence in the logs. But there *is* no such evidence and what you describe is a sudden hard lock... this is the signature of a hardware problem. FYI, Martin, I've been doing this a veeeery long time. I first went to Heald Engineering College to become an electronics engineering technician when we were transitioning from tubes to transistors... then, again, when we were transitioning from transistors to ICs (still pre-microprocessor.) I know my Ohm's Law and Thevenin's Theorum and Kirchoff's Law circuit calculations... I run a mean oscilloscope and high impedance DVM, too. Take my word for it... this "smells" a great deal more like flaky hardware than a "race" condition. I could be wrong, but that's definitely how I'd approach it.
Therefor I am still looking for a way to serialize the process of loading modules making sure, that even with default runlevel 5 KDE only starts, when everything else has finished. Do you have an idea about how to schieve this?
I've never needed to do this... not once... so, I have to put on my thinking cap and do some reading and research. It's pretty late at the moment, so I'll try to catch up with you sometime tomorrow. regards, - Carl