From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([208.92.234.80] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1Qej2z-0005hR-Kf for garchives@archives.gentoo.org; Thu, 07 Jul 2011 07:30:53 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id C4B1721C07B; Thu, 7 Jul 2011 07:29:21 +0000 (UTC) Received: from mail-yi0-f53.google.com (mail-yi0-f53.google.com [209.85.218.53]) by pigeon.gentoo.org (Postfix) with ESMTP id 96F3F21C07B for ; Thu, 7 Jul 2011 07:29:21 +0000 (UTC) Received: by yic15 with SMTP id 15so376094yic.40 for ; Thu, 07 Jul 2011 00:29:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=qakPQFuFyxH0n1TlGY1APZ892Dpgz1xyl66d3DNeQ+w=; b=mQL7gsoMfg4tpiKUQP1TSn2/7fiHVtUZusIQTm4Dcqp+iVn312buY0ol4u8uvf5B9n MXoUBJRdsLg96zoR9o3zslq4QjnN8da2v9Q0bQhINkBS/lzW3Bau9CqpQN4lQIEWAsR7 RR1k1dFAUx8LCITskCJmvwHsZWFKwA1lTTHKg= Received: by 10.147.86.18 with SMTP id o18mr363820yal.17.1310023760901; Thu, 07 Jul 2011 00:29:20 -0700 (PDT) Received: from [192.168.2.5] (adsl-98-95-147-233.jan.bellsouth.net [98.95.147.233]) by mx.google.com with ESMTPS id x33sm8277241ana.48.2011.07.07.00.29.19 (version=SSLv3 cipher=OTHER); Thu, 07 Jul 2011 00:29:20 -0700 (PDT) Message-ID: <4E15604E.90907@gmail.com> Date: Thu, 07 Jul 2011 02:29:18 -0500 From: Dale User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.19) Gecko/20110705 Gentoo/2.0.14-r1 SeaMonkey/2.0.14 Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-user@lists.gentoo.org Reply-to: gentoo-user@lists.gentoo.org MIME-Version: 1.0 To: gentoo-user@lists.gentoo.org Subject: Re: [gentoo-user] KDE and HARD lock ups. References: <4E11EEF3.70804@gmail.com> <1402354.G0EMuDhieW@nazgul> <4E122A95.7060707@gmail.com> <4E1364B6.3090405@gmail.com> <4E1376E9.6010103@gmail.com> <4E1392D6.2090904@gmail.com> <4E14B72C.6080004@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Archives-Salt: X-Archives-Hash: f8a00651bad575a14c3224eedc0bd4ea Jes=C3=BAs J. Guerrero Botella wrote: > 2011/7/6 Dale: > =20 >> Jes=C3=BAs J. Guerrero Botella wrote: >> =20 >>> 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 giv= e >>> it permissions to do so (kernel bug) or if the hardware is not faulty= . >>> Same goes for tray apps. >>> >>> >>> =20 >> 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 ge= t 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 a= go >> with no recent updates here just broke or just maybe it is something e= lse 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 g= oing >> to show no problems as well. >> =20 > 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. > > =20 >> I did try .39 but it had issues. I got rid of those. >> =20 > 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. > > =20 You have a good point but there is a problem. Some of the kernels I=20 tried ran on this machine with uptimes of several weeks and not one lock=20 up. It could be some upgrade that affected this but who knows what that=20 was since I have updated a lot. As for nvidia, I tried both versions=20 that work with my card that are in portage. I got the same with that no=20 matter what I tried. As for .39 kernels, I mentioned in this mess somewhere that I had=20 upgraded but ran into problems with that series so I deleted them. I=20 may just be adding to the problems I am having if I do upgrade again. =20 But since I got to try something, I'll try the latest .39 and see what=20 it does. I remember having this type of problem once before. It turned out to be=20 a gcc problem if I recall correctly. I went back a version of gcc and=20 then did a emerge -e world. After that, things worked fine. Thing is,=20 I have had the same gcc since I built this rig according to genlop. Weird. Dale :-) :-)