| 1 |
Jesús J. Guerrero Botella wrote: |
| 2 |
> 2011/7/6 Dale<rdalek1967@×××××.com>: |
| 3 |
> |
| 4 |
>> Jesús J. Guerrero Botella wrote: |
| 5 |
>> |
| 6 |
>>> Dale, random hard-lockups are only due to hardware or kerne, it can't |
| 7 |
>>> be otherwisel (drivers count as part of kernel). The fact that |
| 8 |
>>> compilation doesn't lock your system only means that the thing |
| 9 |
>>> (whatever it is) is not bount to intensive I/O operations and/or high |
| 10 |
>>> cpu loads. |
| 11 |
>>> |
| 12 |
>>> Openldap itself can't hard lock up anything if the kernel doesn't give |
| 13 |
>>> it permissions to do so (kernel bug) or if the hardware is not faulty. |
| 14 |
>>> Same goes for tray apps. |
| 15 |
>>> |
| 16 |
>>> |
| 17 |
>>> |
| 18 |
>> OK. I tested this and it doesn't help any. I tried three different |
| 19 |
>> kernels, all of which I have used in the past with no problems, and get the |
| 20 |
>> same thing. I have tried reinstalling nvidia-drivers and a different |
| 21 |
>> versions of nvidia-drivers, same thing. So, either previously working |
| 22 |
>> kernels are now broke, nvidia which was working fine just a few days ago |
| 23 |
>> with no recent updates here just broke or just maybe it is something else we |
| 24 |
>> have yet to figure out yet. I also ran memtest for HOURS with not one |
| 25 |
>> problem reported. |
| 26 |
>> |
| 27 |
>> Given I have tried the above, do you still think it is kernel, nvidia or |
| 28 |
>> hardware? I'm about to run tests on the drive now. I suspect it is going |
| 29 |
>> to show no problems as well. |
| 30 |
>> |
| 31 |
> I can't know what it is, but all the kernels you list are .38, and all |
| 32 |
> of them are affected by the bug I described, so you haven't discarded |
| 33 |
> anything yet. Try 2.6.39.2 if you want to discard that. |
| 34 |
> |
| 35 |
> All the drivers you've tried are also the same nvidia-drivers, so |
| 36 |
> that's a poor attempt as well. Try vesa, as said. |
| 37 |
> |
| 38 |
> All I say is that user land applications CAN'T hard lock the whole OS |
| 39 |
> unless the kernel let's them do so. And that can only happens because |
| 40 |
> of three reasons: |
| 41 |
> |
| 42 |
> a) kernel bug |
| 43 |
> b) drivers |
| 44 |
> c) hardware |
| 45 |
> |
| 46 |
> Unless it's not truly a hard-lock, in which case the title of the |
| 47 |
> thread is misleading. |
| 48 |
> |
| 49 |
> |
| 50 |
>> I did try .39 but it had issues. I got rid of those. |
| 51 |
>> |
| 52 |
> Right, but .38 suffers the bug we are telling you. So you'll have to |
| 53 |
> fix these issues, or you'll never discard the possibility that's the |
| 54 |
> USB bug from .38 bitting you. |
| 55 |
> |
| 56 |
> |
| 57 |
|
| 58 |
You have a good point but there is a problem. Some of the kernels I |
| 59 |
tried ran on this machine with uptimes of several weeks and not one lock |
| 60 |
up. It could be some upgrade that affected this but who knows what that |
| 61 |
was since I have updated a lot. As for nvidia, I tried both versions |
| 62 |
that work with my card that are in portage. I got the same with that no |
| 63 |
matter what I tried. |
| 64 |
|
| 65 |
As for .39 kernels, I mentioned in this mess somewhere that I had |
| 66 |
upgraded but ran into problems with that series so I deleted them. I |
| 67 |
may just be adding to the problems I am having if I do upgrade again. |
| 68 |
But since I got to try something, I'll try the latest .39 and see what |
| 69 |
it does. |
| 70 |
|
| 71 |
I remember having this type of problem once before. It turned out to be |
| 72 |
a gcc problem if I recall correctly. I went back a version of gcc and |
| 73 |
then did a emerge -e world. After that, things worked fine. Thing is, |
| 74 |
I have had the same gcc since I built this rig according to genlop. |
| 75 |
|
| 76 |
Weird. |
| 77 |
|
| 78 |
Dale |
| 79 |
|
| 80 |
:-) :-) |
Archives