Jesús J. Guerrero Botella wrote:
2011/7/6 Dale<rdalek1...@gmail.com>:
Jesús J. Guerrero Botella wrote:
Dale, random hard-lockups are only due to hardware or kerne, it can't
be otherwisel (drivers count as part of kernel). The fact that
compilation doesn't lock your system only means that the thing
(whatever it is) is not bount to intensive I/O operations and/or high
cpu loads.
Openldap itself can't hard lock up anything if the kernel doesn't give
it permissions to do so (kernel bug) or if the hardware is not faulty.
Same goes for tray apps.
OK. I tested this and it doesn't help any. I tried three different
kernels, all of which I have used in the past with no problems, and get the
same thing. I have tried reinstalling nvidia-drivers and a different
versions of nvidia-drivers, same thing. So, either previously working
kernels are now broke, nvidia which was working fine just a few days ago
with no recent updates here just broke or just maybe it is something else we
have yet to figure out yet. I also ran memtest for HOURS with not one
problem reported.
Given I have tried the above, do you still think it is kernel, nvidia or
hardware? I'm about to run tests on the drive now. I suspect it is going
to show no problems as well.
I can't know what it is, but all the kernels you list are .38, and all
of them are affected by the bug I described, so you haven't discarded
anything yet. Try 2.6.39.2 if you want to discard that.
All the drivers you've tried are also the same nvidia-drivers, so
that's a poor attempt as well. Try vesa, as said.
All I say is that user land applications CAN'T hard lock the whole OS
unless the kernel let's them do so. And that can only happens because
of three reasons:
a) kernel bug
b) drivers
c) hardware
Unless it's not truly a hard-lock, in which case the title of the
thread is misleading.
I did try .39 but it had issues. I got rid of those.
Right, but .38 suffers the bug we are telling you. So you'll have to
fix these issues, or you'll never discard the possibility that's the
USB bug from .38 bitting you.
You have a good point but there is a problem. Some of the kernels I
tried ran on this machine with uptimes of several weeks and not one lock
up. It could be some upgrade that affected this but who knows what that
was since I have updated a lot. As for nvidia, I tried both versions
that work with my card that are in portage. I got the same with that no
matter what I tried.
As for .39 kernels, I mentioned in this mess somewhere that I had
upgraded but ran into problems with that series so I deleted them. I
may just be adding to the problems I am having if I do upgrade again.
But since I got to try something, I'll try the latest .39 and see what
it does.
I remember having this type of problem once before. It turned out to be
a gcc problem if I recall correctly. I went back a version of gcc and
then did a emerge -e world. After that, things worked fine. Thing is,
I have had the same gcc since I built this rig according to genlop.
Weird.
Dale
:-) :-)
