1 |
On Wed, Jul 6, 2011 at 12:27 PM, Dale <rdalek1967@×××××.com> wrote: |
2 |
> Jesús J. Guerrero Botella wrote: |
3 |
>> |
4 |
>> Dale, random hard-lockups are only due to hardware or kerne, it can't |
5 |
>> be otherwisel (drivers count as part of kernel). The fact that |
6 |
>> compilation doesn't lock your system only means that the thing |
7 |
>> (whatever it is) is not bount to intensive I/O operations and/or high |
8 |
>> cpu loads. |
9 |
>> |
10 |
>> Openldap itself can't hard lock up anything if the kernel doesn't give |
11 |
>> it permissions to do so (kernel bug) or if the hardware is not faulty. |
12 |
>> Same goes for tray apps. |
13 |
>> |
14 |
>> |
15 |
> |
16 |
> OK. I tested this and it doesn't help any. I tried three different |
17 |
> kernels, all of which I have used in the past with no problems, and get the |
18 |
> same thing. I have tried reinstalling nvidia-drivers and a different |
19 |
> versions of nvidia-drivers, same thing. So, either previously working |
20 |
> kernels are now broke, nvidia which was working fine just a few days ago |
21 |
> with no recent updates here just broke or just maybe it is something else we |
22 |
> have yet to figure out yet. I also ran memtest for HOURS with not one |
23 |
> problem reported. |
24 |
> |
25 |
> Given I have tried the above, do you still think it is kernel, nvidia or |
26 |
> hardware? I'm about to run tests on the drive now. I suspect it is going |
27 |
> to show no problems as well. |
28 |
> |
29 |
> This is also the reason I keep old kernels laying around: |
30 |
> |
31 |
> root@fireball / # ls -al /boot/bzImage* |
32 |
> -rw-r--r-- 1 root root 4257840 Mar 21 18:39 /boot/bzImage-2.6.38-1 |
33 |
> -rw-r--r-- 1 root root 4480304 Mar 22 12:00 /boot/bzImage-2.6.38-2 |
34 |
> -rw-r--r-- 1 root root 4493872 Mar 25 13:02 /boot/bzImage-2.6.38-3 |
35 |
> -rw-r--r-- 1 root root 4496336 Mar 29 03:25 /boot/bzImage-2.6.38-r1-1 |
36 |
> -rw-r--r-- 1 root root 4454480 Apr 7 19:13 /boot/bzImage-2.6.38-r1-2 |
37 |
> -rw-r--r-- 1 root root 4451760 May 3 02:16 /boot/bzImage-2.6.38-r3-1 |
38 |
> -rw-r--r-- 1 root root 4451536 May 12 06:12 /boot/bzImage-2.6.38-r5-1 |
39 |
> root@fireball / # |
40 |
> |
41 |
> I did try .39 but it had issues. I got rid of those. |
42 |
> |
43 |
> Dale |
44 |
> |
45 |
|
46 |
If I had to guess I'd say, since this followed a power failure where |
47 |
the machine was live and operating (if I've understood the thread |
48 |
through a quick scan) that some file on disk has gotten corrupted and |
49 |
it's that corruption that's causing the problem. You've checked |
50 |
memory. Let's assume that te processor and MB weren't damaged by this |
51 |
event. If that's the case - and unfortunately I don't know of any way |
52 |
to ensure it hasn't as it requires one to have a bit-accurate image of |
53 |
the machine before the power failure - there's probably no way to |
54 |
eliminate this as a possibility short of an emerge -e @world. |
55 |
|
56 |
It's not where I'd start. I'd probably look for core dump files or |
57 |
very carefully do experiment s trying to isolate exactly what part of |
58 |
KDE is firing off the problem. re-emerging the NVidia driver is a |
59 |
no-brainer as it takes no more than 1-2 minutes to test things. |
60 |
Rebuilding the machine is certainly more involved. |
61 |
|
62 |
If you have lots of disk space you might rsync the whole machine to a |
63 |
new partition to do the work, then using something other than KDE |
64 |
which doesn't crash rebuild the copy from a chroot which leaves the |
65 |
machine usable while the rebuild is going on. |
66 |
|
67 |
None of this sounds like fun... |
68 |
|
69 |
- Mark |