[gentoo-user] KDE and HARD lock ups.

[gentoo-user] KDE and HARD lock ups.

[Dale]

Hi,

Has anyone else had any hard lock ups in KDE?   I'm on kde 4.6.4 which 
was released about a month ago.  For those not in the know, I'm on amd64 
and use kde-meta so it is has the kitchen sink installed here.

What mine does:  It sort of varies but usually when I login, it may last 
a couple minutes, usually less, then the Caps Lock and Scroll Lock LED's 
blink.  The Num Lock key is off if that means anything.  I tried the 
SysReq keys but it doesn't do anything at all.  According to the 
messages at the next boot, it doesn't sync or umount either.  The mouse 
pointer no longer moves either.  At this point, I hit the reset button 
which causes steam to come out my ears.  I HATE using that button.

I'm fairly sure this is not hardware.  Right now, I am in Fluxbox and it 
works fine.  I also booted to single user and compiled a bunch of stuff 
and also tried a different kernel too.  I think if it was hardware, it 
would have had some kind of hick-up during the compile.  I did check 
temps and all is nice and cool, very cool since my A/C is on full 
blast.  I think the oven is outside on full blast instead of in the 
kitchen.  lol  It's HOT here, steamy hot.

I checked messages and the only thing I saw was about a bad option for 
hp-systray.  Surely that wouldn't cause a crash?  I'm going to unmerge 
and test it tho, just to be sure.

Anyone run into something like this?  Ideas?

Thanks much.

Dale

:-)  :-)

Re: [gentoo-user] KDE and HARD lock ups.

[Jesús J. Guerrero Botella]

2011/7/4 Dale <rdalek1967@gmail.com>:
> Hi,
>
> What mine does:  It sort of varies but usually when I login, it may last a
> couple minutes, usually less, then the Caps Lock and Scroll Lock LED's
> blink.  The Num Lock key is off if that means anything.  I tried the SysReq
> keys but it doesn't do anything at all.  According to the messages at the
> next boot, it doesn't sync or umount either.  The mouse pointer no longer
> moves either.  At this point, I hit the reset button which causes steam to
> come out my ears.  I HATE using that button.
>
> I'm fairly sure this is not hardware.

You can never be sure about that.

>  Right now, I am in Fluxbox and it
> works fine.  I also booted to single user and compiled a bunch of stuff and
> also tried a different kernel too.  I think if it was hardware, it would
> have had some kind of hick-up during the compile.  I did check temps and all
> is nice and cool, very cool since my A/C is on full blast.  I think the oven
> is outside on full blast instead of in the kitchen.  lol  It's HOT here,
> steamy hot.

You can try turning off the compositing system altogether. You can do
that by disabling the desktop effects in systemsettings. If lockups
stop then it's probably something to do with your graphics driver and
if that's the case you might have better luck with an alternative
driver.

> I checked messages and the only thing I saw was about a bad option for
> hp-systray.  Surely that wouldn't cause a crash?  I'm going to unmerge and
> test it tho, just to be sure.

I don't think so.


-- 
Jesús Guerrero Botella

Re: [gentoo-user] KDE and HARD lock ups.

[Dale]

Jesús J. Guerrero Botella wrote:
> 2011/7/4 Dale<rdalek1967@gmail.com>:
>    
>> Hi,
>>
>> What mine does:  It sort of varies but usually when I login, it may last a
>> couple minutes, usually less, then the Caps Lock and Scroll Lock LED's
>> blink.  The Num Lock key is off if that means anything.  I tried the SysReq
>> keys but it doesn't do anything at all.  According to the messages at the
>> next boot, it doesn't sync or umount either.  The mouse pointer no longer
>> moves either.  At this point, I hit the reset button which causes steam to
>> come out my ears.  I HATE using that button.
>>
>> I'm fairly sure this is not hardware.
>>      
> You can never be sure about that.
>    

That's why I said "fairly".  One can never be sure but after some 
testing, I don't think it is hardware.  I'm getting more sure of that as 
time goes on too.  ;-)

>    
>>   Right now, I am in Fluxbox and it
>> works fine.  I also booted to single user and compiled a bunch of stuff and
>> also tried a different kernel too.  I think if it was hardware, it would
>> have had some kind of hick-up during the compile.  I did check temps and all
>> is nice and cool, very cool since my A/C is on full blast.  I think the oven
>> is outside on full blast instead of in the kitchen.  lol  It's HOT here,
>> steamy hot.
>>      
> You can try turning off the compositing system altogether. You can do
> that by disabling the desktop effects in systemsettings. If lockups
> stop then it's probably something to do with your graphics driver and
> if that's the case you might have better luck with an alternative
> driver.
>
>    

I don't think I am logged in long enough to change the settings.  I may 
try my test user but I think a file got corrupted or something.  I did 
have a power failure the other day and the relay on my UPS was not quite 
fast enough.  I think the contacts may need some cleaning.  My UPS does 
some odd things at times.  I need a new one but they are pricey.  I had 
forgot about the power failure issue.  That has lead me down a different 
path now.

>> I checked messages and the only thing I saw was about a bad option for
>> hp-systray.  Surely that wouldn't cause a crash?  I'm going to unmerge and
>> test it tho, just to be sure.
>>      
> I don't think so.
>
>    

I have seen this cause my desktop to freeze before.  Usually when it has 
trouble seeing the printer or starting itself then kills itself after a 
few seconds.  Once it dies, the desktop comes back.  This is just a more 
permanent freeze.  I did wait a couple times but it never come back.

Working on a re-emerge to see if it corrects this issue.

Thanks.

Dale

:-)  :-)

Re: [gentoo-user] KDE and HARD lock ups.

[Jesús J. Guerrero Botella]

2011/7/4 Dale <rdalek1967@gmail.com>:
> I don't think I am logged in long enough to change the settings.  I may try
> my test user but I think a file got corrupted or something.  I did have a
> power failure the other day and the relay on my UPS was not quite fast
> enough.  I think the contacts may need some cleaning.  My UPS does some odd
> things at times.  I need a new one but they are pricey.  I had forgot about
> the power failure issue.  That has lead me down a different path now.

You don't need much time. The default shortcut to disable compositing
in kde is shift+alt+f12

You can try the vesa driver, or any alternative that will work with
your card, as well.

I also had the usb issue that others said above, with previous kernel
versions. I haven't seen it lately though, with 2.6.39.x.

-- 
Jesús Guerrero Botella

Re: [gentoo-user] KDE and HARD lock ups.

[Dale]

Jesús J. Guerrero Botella wrote:
> 2011/7/4 Dale<rdalek1967@gmail.com>:
>    
>> I don't think I am logged in long enough to change the settings.  I may try
>> my test user but I think a file got corrupted or something.  I did have a
>> power failure the other day and the relay on my UPS was not quite fast
>> enough.  I think the contacts may need some cleaning.  My UPS does some odd
>> things at times.  I need a new one but they are pricey.  I had forgot about
>> the power failure issue.  That has lead me down a different path now.
>>      
> You don't need much time. The default shortcut to disable compositing
> in kde is shift+alt+f12
>
> You can try the vesa driver, or any alternative that will work with
> your card, as well.
>
> I also had the usb issue that others said above, with previous kernel
> versions. I haven't seen it lately though, with 2.6.39.x.
>
>    

I may try that if this re-emerge doesn't help any.  It doesn't like 
much.  I just hope all the thunder I keep hearing will not force me to 
shutdown my rig.  I think Mother Nature is hungry since the tummy is 
growling a lot.  :/

Hmmm, I use Nvidia for my drivers.  I don't even know if vesa is on here 
or not.  I might add that Fluxbox has been working.  It even plays 
videos fine.  I'm not sure this is a video driver problem, not yet anyway.

I been using 2.6.38 for a while.  I seem to have missed the USB bug.  I 
don't have much that uses it except for my printer and my camera.  I 
don't even have my printer hooked up most of them time.  Maybe I do have 
some good luck after all.  o_O

Thanks.

Dale

:-)  :-)

Re: [gentoo-user] KDE and HARD lock ups.

[Jesús J. Guerrero Botella]

2011/7/5 Dale <rdalek1967@gmail.com>:
> Jesús J. Guerrero Botella wrote:
>>
>> 2011/7/4 Dale<rdalek1967@gmail.com>:
>>
>>>
>>> I don't think I am logged in long enough to change the settings.  I may
>>> try
>>> my test user but I think a file got corrupted or something.  I did have a
>>> power failure the other day and the relay on my UPS was not quite fast
>>> enough.  I think the contacts may need some cleaning.  My UPS does some
>>> odd
>>> things at times.  I need a new one but they are pricey.  I had forgot
>>> about
>>> the power failure issue.  That has lead me down a different path now.
>>>
>>
>> You don't need much time. The default shortcut to disable compositing
>> in kde is shift+alt+f12
>>
>> You can try the vesa driver, or any alternative that will work with
>> your card, as well.
>>
>> I also had the usb issue that others said above, with previous kernel
>> versions. I haven't seen it lately though, with 2.6.39.x.
>>
>>
>
> I may try that if this re-emerge doesn't help any.  It doesn't like much.  I
> just hope all the thunder I keep hearing will not force me to shutdown my
> rig.  I think Mother Nature is hungry since the tummy is growling a lot.  :/
>
> Hmmm, I use Nvidia for my drivers.  I don't even know if vesa is on here or
> not.  I might add that Fluxbox has been working.  It even plays videos fine.
>  I'm not sure this is a video driver problem, not yet anyway.

There's one very important difference and it relates to all the post
I've written in this thread: compositing. Fluxbox doesn't use that.

You will need to start trying something sooner or later, if you
discard problems like that without any further looking you might not
find the problem ever.

> I been using 2.6.38 for a while.  I seem to have missed the USB bug.  I
> don't have much that uses it except for my printer and my camera.  I don't
> even have my printer hooked up most of them time.  Maybe I do have some good
> luck after all.  o_O

A lot of people were hit by a nasty bug that hard locked the pc when
plugging in usb storage devices. Your camera would fit that category.
I remember a thread in the forum where most users affected by this had
a similar motherboard and chipset.

http://forums.gentoo.org/viewtopic-t-882390-highlight-.html

There's been some noise about this in many places, not just that
thread. So you might want to take a look at it if you can't solve your
problem recompiling the tray app.



-- 
Jesús Guerrero Botella

Re: [gentoo-user] KDE and HARD lock ups.

[Dale]

Jesús J. Guerrero Botella wrote:
> 2011/7/5 Dale<rdalek1967@gmail.com>:
>    
>> Jesús J. Guerrero Botella wrote:
>>      
>>> 2011/7/4 Dale<rdalek1967@gmail.com>:
>>>
>>>        
>>>> I don't think I am logged in long enough to change the settings.  I may
>>>> try
>>>> my test user but I think a file got corrupted or something.  I did have a
>>>> power failure the other day and the relay on my UPS was not quite fast
>>>> enough.  I think the contacts may need some cleaning.  My UPS does some
>>>> odd
>>>> things at times.  I need a new one but they are pricey.  I had forgot
>>>> about
>>>> the power failure issue.  That has lead me down a different path now.
>>>>
>>>>          
>>> You don't need much time. The default shortcut to disable compositing
>>> in kde is shift+alt+f12
>>>
>>> You can try the vesa driver, or any alternative that will work with
>>> your card, as well.
>>>
>>> I also had the usb issue that others said above, with previous kernel
>>> versions. I haven't seen it lately though, with 2.6.39.x.
>>>
>>>
>>>        
>> I may try that if this re-emerge doesn't help any.  It doesn't like much.  I
>> just hope all the thunder I keep hearing will not force me to shutdown my
>> rig.  I think Mother Nature is hungry since the tummy is growling a lot.  :/
>>
>> Hmmm, I use Nvidia for my drivers.  I don't even know if vesa is on here or
>> not.  I might add that Fluxbox has been working.  It even plays videos fine.
>>   I'm not sure this is a video driver problem, not yet anyway.
>>      
> There's one very important difference and it relates to all the post
> I've written in this thread: compositing. Fluxbox doesn't use that.
>
> You will need to start trying something sooner or later, if you
> discard problems like that without any further looking you might not
> find the problem ever.
>
>    

I tried it.  It still did the same thing.  It did make things look 
different tho.  Sort of made it look funny in a way.  That would be 
funny as in strange.


>> I been using 2.6.38 for a while.  I seem to have missed the USB bug.  I
>> don't have much that uses it except for my printer and my camera.  I don't
>> even have my printer hooked up most of them time.  Maybe I do have some good
>> luck after all.  o_O
>>      
> A lot of people were hit by a nasty bug that hard locked the pc when
> plugging in usb storage devices. Your camera would fit that category.
> I remember a thread in the forum where most users affected by this had
> a similar motherboard and chipset.
>
> http://forums.gentoo.org/viewtopic-t-882390-highlight-.html
>
> There's been some noise about this in many places, not just that
> thread. So you might want to take a look at it if you can't solve your
> problem recompiling the tray app.
>
>    

I may have found the problem.  It appears openldap has a issue which 
effects some KDE packages as well.  Started a fresh thread for that one.

Thanks.

Dale

:-)  :-)

Re: [gentoo-user] KDE and HARD lock ups.

[Alan McKinnon]

On Monday 04 July 2011 19:12:50 Jesús J. Guerrero Botella did opine 
thusly:
> 2011/7/4 Dale <rdalek1967@gmail.com>:
> > Hi,
> > 
> > What mine does:  It sort of varies but usually when I login, it
> > may last a couple minutes, usually less, then the Caps Lock and
> > Scroll Lock LED's blink.  The Num Lock key is off if that means
> > anything.  I tried the SysReq keys but it doesn't do anything
> > at all.  According to the messages at the next boot, it doesn't
> > sync or umount either.  The mouse pointer no longer moves
> > either.  At this point, I hit the reset button which causes
> > steam to come out my ears.  I HATE using that button.
> > 
> > I'm fairly sure this is not hardware.
> 
> You can never be sure about that.
> 
> >  Right now, I am in Fluxbox and it
> > works fine.  I also booted to single user and compiled a bunch
> > of stuff and also tried a different kernel too.  I think if it
> > was hardware, it would have had some kind of hick-up during the
> > compile.  I did check temps and all is nice and cool, very cool
> > since my A/C is on full blast.  I think the oven is outside on
> > full blast instead of in the kitchen.  lol  It's HOT here,
> > steamy hot.
> 
> You can try turning off the compositing system altogether. You can
> do that by disabling the desktop effects in systemsettings. If
> lockups stop then it's probably something to do with your graphics
> driver and if that's the case you might have better luck with an
> alternative driver.

I get frequent crashes that seem to be related to nouveau.
When I used nvidia drivers, they seemed to have a mind of their own 
when it came to memory usage and segfaults.
And the entire abomination that shall not be suffered to live called 
"kdepim" *definitely* has a mind of it's own.


> 
> > I checked messages and the only thing I saw was about a bad
> > option for hp-systray.  Surely that wouldn't cause a crash?
> >  I'm going to unmerge and test it tho, just to be sure.
> 
> I don't think so.
-- 
alan dot mckinnon at gmail dot com

Re: [gentoo-user] KDE and HARD lock ups.

[Dale]

Alan McKinnon wrote:
> On Monday 04 July 2011 19:12:50 Jesús J. Guerrero Botella did opine
> thusly:
>    
>> 2011/7/4 Dale<rdalek1967@gmail.com>:
>>      
>>> Hi,
>>>
>>> What mine does:  It sort of varies but usually when I login, it
>>> may last a couple minutes, usually less, then the Caps Lock and
>>> Scroll Lock LED's blink.  The Num Lock key is off if that means
>>> anything.  I tried the SysReq keys but it doesn't do anything
>>> at all.  According to the messages at the next boot, it doesn't
>>> sync or umount either.  The mouse pointer no longer moves
>>> either.  At this point, I hit the reset button which causes
>>> steam to come out my ears.  I HATE using that button.
>>>
>>> I'm fairly sure this is not hardware.
>>>        
>> You can never be sure about that.
>>
>>      
>>>   Right now, I am in Fluxbox and it
>>> works fine.  I also booted to single user and compiled a bunch
>>> of stuff and also tried a different kernel too.  I think if it
>>> was hardware, it would have had some kind of hick-up during the
>>> compile.  I did check temps and all is nice and cool, very cool
>>> since my A/C is on full blast.  I think the oven is outside on
>>> full blast instead of in the kitchen.  lol  It's HOT here,
>>> steamy hot.
>>>        
>> You can try turning off the compositing system altogether. You can
>> do that by disabling the desktop effects in systemsettings. If
>> lockups stop then it's probably something to do with your graphics
>> driver and if that's the case you might have better luck with an
>> alternative driver.
>>      
> I get frequent crashes that seem to be related to nouveau.
> When I used nvidia drivers, they seemed to have a mind of their own
> when it came to memory usage and segfaults.
> And the entire abomination that shall not be suffered to live called
> "kdepim" *definitely* has a mind of it's own.
>
>
>    
>>      
>>> I checked messages and the only thing I saw was about a bad
>>> option for hp-systray.  Surely that wouldn't cause a crash?
>>>   I'm going to unmerge and test it tho, just to be sure.
>>>        
>> I don't think so.
>>      

Well, I tried a different kernel.  Same thing.  I tried reseting the 
BIOS and lurking around in there for a bit as well.  Same thing.  So, 
right now I'm chewing on a emerge -e kde-meta.  After I remembered the 
power failure the other day, I suspect a corrupt file somewhere.  I'm 
just glad I have Fluxbox on here.  I'm in it right now and it works OK.  
I just wish the little bar at the bottom was larger.  So far, nothing I 
click changes that.  Tough on my eyes too.  Teeny tiny stuff down 
there.  o_o

Thinking back, I should have booted the CD and run file system checks.  
Crap, the one thing I didn't think of. < sighs >

I still use Nvidia's driver here.  it has worked well for me at least.  
I don't use any fancy hardware or play any serious games so it works 
well, so far at least.  That may change next week.  lol   You know me.  
Something new pretty regular.

I don't guess I use kdepim stuff.  It's installed so who knows.  Any 
relation to pam?

Dale

:-)  :-)

Re: [gentoo-user] KDE and HARD lock ups.

[Dale]

Dale wrote:
>
> Well, I tried a different kernel.  Same thing.  I tried reseting the 
> BIOS and lurking around in there for a bit as well.  Same thing.  So, 
> right now I'm chewing on a emerge -e kde-meta.  After I remembered the 
> power failure the other day, I suspect a corrupt file somewhere.  I'm 
> just glad I have Fluxbox on here.  I'm in it right now and it works 
> OK.  I just wish the little bar at the bottom was larger.  So far, 
> nothing I click changes that.  Tough on my eyes too.  Teeny tiny stuff 
> down there.  o_o
>
> Thinking back, I should have booted the CD and run file system 
> checks.  Crap, the one thing I didn't think of. < sighs >
>
> I still use Nvidia's driver here.  it has worked well for me at 
> least.  I don't use any fancy hardware or play any serious games so it 
> works well, so far at least.  That may change next week.  lol   You 
> know me.  Something new pretty regular.
>
> I don't guess I use kdepim stuff.  It's installed so who knows.  Any 
> relation to pam?
>
> Dale
>
> :-)  :-)
>

Well, I got rid of openldap.  It runs longer but still crashes so I am 
back to Fluxbox again, which works fine.  I also started with a fresh 
.kde4 directory.  That seemed to help more than anything else.  It 
lasted a LOT longer after that.  I don't know if it was a coincidence or 
what but it did lock up once when I logged into Konsole as root.

I started a emerge -e world this time.  This thing has 4 cores so it 
won't take to long.  Any ideas on what else I can try?  If this emerge 
doesn't help, it has to be a config file somewhere.

Again, I'm pretty sure it is not hardware.  It runs fine when compiling 
in a console and I have run from systemrescue stick as well.  Hardware 
seems to work fine.

Ideas?

Dale

:-)  :-)

Re: [gentoo-user] KDE and HARD lock ups.

[Paul Hartman]

On Tue, Jul 5, 2011 at 2:23 PM, Dale <rdalek1967@gmail.com> wrote:
> Dale wrote:
>>
>> Well, I tried a different kernel.  Same thing.  I tried reseting the BIOS
>> and lurking around in there for a bit as well.  Same thing.  So, right now
>> I'm chewing on a emerge -e kde-meta.  After I remembered the power failure
>> the other day, I suspect a corrupt file somewhere.  I'm just glad I have
>> Fluxbox on here.  I'm in it right now and it works OK.  I just wish the
>> little bar at the bottom was larger.  So far, nothing I click changes that.
>>  Tough on my eyes too.  Teeny tiny stuff down there.  o_o
>>
>> Thinking back, I should have booted the CD and run file system checks.
>>  Crap, the one thing I didn't think of. < sighs >
>>
>> I still use Nvidia's driver here.  it has worked well for me at least.  I
>> don't use any fancy hardware or play any serious games so it works well, so
>> far at least.  That may change next week.  lol   You know me.  Something new
>> pretty regular.
>>
>> I don't guess I use kdepim stuff.  It's installed so who knows.  Any
>> relation to pam?
>>
>> Dale
>>
>> :-)  :-)
>>
>
> Well, I got rid of openldap.  It runs longer but still crashes so I am back
> to Fluxbox again, which works fine.  I also started with a fresh .kde4
> directory.  That seemed to help more than anything else.  It lasted a LOT
> longer after that.  I don't know if it was a coincidence or what but it did
> lock up once when I logged into Konsole as root.
>
> I started a emerge -e world this time.  This thing has 4 cores so it won't
> take to long.  Any ideas on what else I can try?  If this emerge doesn't
> help, it has to be a config file somewhere.
>
> Again, I'm pretty sure it is not hardware.  It runs fine when compiling in a
> console and I have run from systemrescue stick as well.  Hardware seems to
> work fine.
>
> Ideas?

It's a long shot, but since you're using nvidia, I had random lockups.
It turned out to be due to faulty handling of the on-by-default
aggressive power savings mode of my Nvidia card. It was solved by
placing this undocumented incantation, pieced together from various
Google searches, in my xorg.conf device section for my video card:

Section "Device"
    Identifier "nVidia GT 240"
    Driver "nvidia"
    Option "RegistryDWords" "PowerMizerEnable=0x1;
PerfLevelSrc=0x3322; PowerMizerDefault=0x1; PowerMizerDefaultAC=0x1"
EndSection

After that, everything works wonderfully.

You can also use nvidia-settings to change the power saving mode at
run-time, but it does not save it and you must do it every time you
log into X, which is annoying. The xorg.conf method above requires no
further action.

Your card may not even support PowerMizer, who knows? I thought I'd
mention it just in case.

Re: [gentoo-user] KDE and HARD lock ups.

[Dale]

Paul Hartman wrote:
> On Tue, Jul 5, 2011 at 2:23 PM, Dale<rdalek1967@gmail.com>  wrote:
>    
>>
>> Well, I got rid of openldap.  It runs longer but still crashes so I am back
>> to Fluxbox again, which works fine.  I also started with a fresh .kde4
>> directory.  That seemed to help more than anything else.  It lasted a LOT
>> longer after that.  I don't know if it was a coincidence or what but it did
>> lock up once when I logged into Konsole as root.
>>
>> I started a emerge -e world this time.  This thing has 4 cores so it won't
>> take to long.  Any ideas on what else I can try?  If this emerge doesn't
>> help, it has to be a config file somewhere.
>>
>> Again, I'm pretty sure it is not hardware.  It runs fine when compiling in a
>> console and I have run from systemrescue stick as well.  Hardware seems to
>> work fine.
>>
>> Ideas?
>>      
> It's a long shot, but since you're using nvidia, I had random lockups.
> It turned out to be due to faulty handling of the on-by-default
> aggressive power savings mode of my Nvidia card. It was solved by
> placing this undocumented incantation, pieced together from various
> Google searches, in my xorg.conf device section for my video card:
>
> Section "Device"
>      Identifier "nVidia GT 240"
>      Driver "nvidia"
>      Option "RegistryDWords" "PowerMizerEnable=0x1;
> PerfLevelSrc=0x3322; PowerMizerDefault=0x1; PowerMizerDefaultAC=0x1"
> EndSection
>
> After that, everything works wonderfully.
>
> You can also use nvidia-settings to change the power saving mode at
> run-time, but it does not save it and you must do it every time you
> log into X, which is annoying. The xorg.conf method above requires no
> further action.
>
> Your card may not even support PowerMizer, who knows? I thought I'd
> mention it just in case.
>
>    

I haven't updated the drivers in a while.  Would something like that 
just up and change even with no upgrade?   I ask because I don't 
honestly know the answer.  Also, would it not cause problems in Fluxbox 
as well?  I played video in Fluxbox last night and it never missed a 
beat.  I use smplayer to play videos just like I do in KDE.

This is what sort of confuses me.  KDE was locking up usually in less 
than a minute after logging in.  After getting rid of openldap, it did 
the same.  After renaming my .kde4 directory, it lasted several minutes 
before locking up.  During one lockup, I even got the SysReq key to work 
and could reboot.  The last time was a HARD lock up complete with the 
flashing lights on my keyboard.

If this still locks up after emerge -e world and a reboot, I'm not sure 
what to do next.  That should eliminate a corrupt file.  Renaming .kde4 
fixed KDE config problems so that doesn't leave much.  I'm going to log 
into my test user and see what if anything it does.  I'm not going to do 
any tinkering with settings, just the default stuff.  I'll post back 
later what it does.

Dale

:-)  :-)

Re: [gentoo-user] KDE and HARD lock ups.

[Dale]

Dale wrote:
> Paul Hartman wrote:
>> On Tue, Jul 5, 2011 at 2:23 PM, Dale<rdalek1967@gmail.com>  wrote:
>>>
>>> Well, I got rid of openldap.  It runs longer but still crashes so I 
>>> am back
>>> to Fluxbox again, which works fine.  I also started with a fresh .kde4
>>> directory.  That seemed to help more than anything else.  It lasted 
>>> a LOT
>>> longer after that.  I don't know if it was a coincidence or what but 
>>> it did
>>> lock up once when I logged into Konsole as root.
>>>
>>> I started a emerge -e world this time.  This thing has 4 cores so it 
>>> won't
>>> take to long.  Any ideas on what else I can try?  If this emerge 
>>> doesn't
>>> help, it has to be a config file somewhere.
>>>
>>> Again, I'm pretty sure it is not hardware.  It runs fine when 
>>> compiling in a
>>> console and I have run from systemrescue stick as well.  Hardware 
>>> seems to
>>> work fine.
>>>
>>> Ideas?
>> It's a long shot, but since you're using nvidia, I had random lockups.
>> It turned out to be due to faulty handling of the on-by-default
>> aggressive power savings mode of my Nvidia card. It was solved by
>> placing this undocumented incantation, pieced together from various
>> Google searches, in my xorg.conf device section for my video card:
>>
>> Section "Device"
>>      Identifier "nVidia GT 240"
>>      Driver "nvidia"
>>      Option "RegistryDWords" "PowerMizerEnable=0x1;
>> PerfLevelSrc=0x3322; PowerMizerDefault=0x1; PowerMizerDefaultAC=0x1"
>> EndSection
>>
>> After that, everything works wonderfully.
>>
>> You can also use nvidia-settings to change the power saving mode at
>> run-time, but it does not save it and you must do it every time you
>> log into X, which is annoying. The xorg.conf method above requires no
>> further action.
>>
>> Your card may not even support PowerMizer, who knows? I thought I'd
>> mention it just in case.
>>
>
> I haven't updated the drivers in a while.  Would something like that 
> just up and change even with no upgrade?   I ask because I don't 
> honestly know the answer.  Also, would it not cause problems in 
> Fluxbox as well?  I played video in Fluxbox last night and it never 
> missed a beat.  I use smplayer to play videos just like I do in KDE.
>
> This is what sort of confuses me.  KDE was locking up usually in less 
> than a minute after logging in.  After getting rid of openldap, it did 
> the same.  After renaming my .kde4 directory, it lasted several 
> minutes before locking up.  During one lockup, I even got the SysReq 
> key to work and could reboot.  The last time was a HARD lock up 
> complete with the flashing lights on my keyboard.
>
> If this still locks up after emerge -e world and a reboot, I'm not 
> sure what to do next.  That should eliminate a corrupt file.  Renaming 
> .kde4 fixed KDE config problems so that doesn't leave much.  I'm going 
> to log into my test user and see what if anything it does.  I'm not 
> going to do any tinkering with settings, just the default stuff.  I'll 
> post back later what it does.
>
> Dale
>
> :-)  :-)
>

I added the line to my xorg file.  Just in case.  ;-)

I logged into my test user with a clean .kde4 directory.  It took a few 
minutes but it did lock up when I opened Konsole again.  I booted my USB 
stick again and did a check on the file systems.  It says everything is 
fine but I'm doing a fresh install on my spare drive.  It was a drive 
that I got along with my video card.  Anyway, I'm going to test the new 
drive here in a little while and see if it still locks up or what.  I 
copied over some files in /etc and my world file plus distfiles.  I'm 
trying not to copy over any more than I have to.

Dale

:-)  :-)

Re: [gentoo-user] KDE and HARD lock ups.

[Jesús J. Guerrero Botella]

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.

-- 
Jesús Guerrero Botella

Re: [gentoo-user] KDE and HARD lock ups.

[Jesús J. Guerrero Botella]

Just to discard some basic things, you could run a SMART check in your
disks and memtest86+ in your RAM. The fact that a memory intensive
desktop locks the computer that flux didn't might mean a thing there
(or not).

-- 
Jesús Guerrero Botella

Re: [gentoo-user] KDE and HARD lock ups.

[Dale]

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.
>
>    

I might add, the last time it locked up, I had a compile process running 
in a console.  I watched the hard drive light, it was blinking away.  
So, the root of the system was running but for some reason, I could not 
get my mouse or keyboard to work.  It appears it is the GUI part that is 
locking up but whatever it is, it is not affecting Fluxbox.  I also 
tried the shift alt F12 to disable composite as well.

It also ran from the my USB stick which is systemrescue.  I didn't start 
a GUI tho.  I just used it to run file system checks and such.

Does that make any sense?  It's not making any here.  I'm just trying to 
nail Jello to the wall.  lol

Dale

:-)  :-)

Re: [gentoo-user] KDE and HARD lock ups.

[Peter Humphrey]

On Wednesday 06 July 2011 01:03:03 Dale wrote:

> I might add, the last time it locked up, I had a compile process running
> in a console.  I watched the hard drive light, it was blinking away.
> So, the root of the system was running but for some reason, I could not
> get my mouse or keyboard to work.  It appears it is the GUI part that is
> locking up but whatever it is, it is not affecting Fluxbox.  I also
> tried the shift alt F12 to disable composite as well.

This is sounding more and more like the lockups I've been experiencing. In 
my case it was every distro other than Gentoo.

I'm trying Fedora with "Asus Express Gate" switched off in the BIOS, and it 
seems to be helping. I know you don't have an Asus motherboard though, so 
I'm not helping :-(

When did you last recompile your kernel? What version is it? (Sorry if 
you've told us already, but if so I missed it.)

-- 
Rgds
Peter

Re: [gentoo-user] KDE and HARD lock ups.

[Mark Knecht]

On Wed, Jul 6, 2011 at 7:44 AM, Peter Humphrey <peter@humphrey.ukfsn.org> wrote:
> On Wednesday 06 July 2011 01:03:03 Dale wrote:
>
>> I might add, the last time it locked up, I had a compile process running
>> in a console.  I watched the hard drive light, it was blinking away.
>> So, the root of the system was running but for some reason, I could not
>> get my mouse or keyboard to work.  It appears it is the GUI part that is
>> locking up but whatever it is, it is not affecting Fluxbox.  I also
>> tried the shift alt F12 to disable composite as well.
>
> This is sounding more and more like the lockups I've been experiencing. In
> my case it was every distro other than Gentoo.
>
> I'm trying Fedora with "Asus Express Gate" switched off in the BIOS, and it
> seems to be helping. I know you don't have an Asus motherboard though, so
> I'm not helping :-(
>
> When did you last recompile your kernel? What version is it? (Sorry if
> you've told us already, but if so I missed it.)
>
> --
> Rgds
> Peter

Speaking as someone who runs 100% (except when I don't) I wonder if
this is driven at all by the use of testing packages?

I have only Asus & Intel MB's and laptops here. They all use the
NVidia closed source testing driver except one which uses the Intel
driver. None of them are experiencing any lockups at any time that I
know of.

This is pretty typical of where I don't run stable:

c2stable ~ # cat /etc/portage/package.keywords
sys-kernel/gentoo-sources ~amd64
sys-apps/portage ~*
app-portage/eix ~amd64
app-emulation/virtualbox ~amd64
app-emulation/virtualbox-modules ~amd64
app-emulation/virtualbox-additions ~amd64
x11-drivers/xf86-video-virtualbox ~amd64
x11-drivers/xf86-input-virtualbox ~amd64
app-emulation/vmware-modules ~amd64
app-emulation/vmware-tools ~amd64
app-emulation/vmware-player ~amd64
x11-libs/libview ~amd64
sci-libs/ta-lib ~amd64
sys-power/cpufrequtils ~amd64
media-libs/tiff ~amd64
dev-util/nvidia-cuda-toolkit ~amd64
dev-util/nvidia-cuda-sdk ~amd64
x11-drivers/nvidia-drivers ~amd64
dev-util/codeblocks ~amd64
x11-misc/read-edid ~amd64
net-im/skype ~amd64
app-forensics/chkrootkit ~amd64
dev-lang/R ~amd64
c2stable ~ #

Cheers,
Mark

Re: [gentoo-user] KDE and HARD lock ups.

[Dale]

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.

This is also the reason I keep old kernels laying around:

root@fireball / # ls -al /boot/bzImage*
-rw-r--r-- 1 root root 4257840 Mar 21 18:39 /boot/bzImage-2.6.38-1
-rw-r--r-- 1 root root 4480304 Mar 22 12:00 /boot/bzImage-2.6.38-2
-rw-r--r-- 1 root root 4493872 Mar 25 13:02 /boot/bzImage-2.6.38-3
-rw-r--r-- 1 root root 4496336 Mar 29 03:25 /boot/bzImage-2.6.38-r1-1
-rw-r--r-- 1 root root 4454480 Apr  7 19:13 /boot/bzImage-2.6.38-r1-2
-rw-r--r-- 1 root root 4451760 May  3 02:16 /boot/bzImage-2.6.38-r3-1
-rw-r--r-- 1 root root 4451536 May 12 06:12 /boot/bzImage-2.6.38-r5-1
root@fireball / #

I did try .39 but it had issues.  I got rid of those.

Dale

:-)  :-)

Re: [gentoo-user] KDE and HARD lock ups.

[Mark Knecht]

On Wed, Jul 6, 2011 at 12:27 PM, Dale <rdalek1967@gmail.com> wrote:
> 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.
>
> This is also the reason I keep old kernels laying around:
>
> root@fireball / # ls -al /boot/bzImage*
> -rw-r--r-- 1 root root 4257840 Mar 21 18:39 /boot/bzImage-2.6.38-1
> -rw-r--r-- 1 root root 4480304 Mar 22 12:00 /boot/bzImage-2.6.38-2
> -rw-r--r-- 1 root root 4493872 Mar 25 13:02 /boot/bzImage-2.6.38-3
> -rw-r--r-- 1 root root 4496336 Mar 29 03:25 /boot/bzImage-2.6.38-r1-1
> -rw-r--r-- 1 root root 4454480 Apr  7 19:13 /boot/bzImage-2.6.38-r1-2
> -rw-r--r-- 1 root root 4451760 May  3 02:16 /boot/bzImage-2.6.38-r3-1
> -rw-r--r-- 1 root root 4451536 May 12 06:12 /boot/bzImage-2.6.38-r5-1
> root@fireball / #
>
> I did try .39 but it had issues.  I got rid of those.
>
> Dale
>

If I had to guess I'd say, since this followed a power failure where
the machine was live and operating (if I've understood the thread
through a quick scan) that some file on disk has gotten corrupted and
it's that corruption that's causing the problem. You've checked
memory. Let's assume that te processor and MB weren't damaged by this
event. If that's the case - and unfortunately I don't know of any way
to ensure it hasn't as it requires one to have a bit-accurate image of
the machine before the power failure - there's probably no way to
eliminate this as a possibility short of an emerge -e @world.

It's not where I'd start. I'd probably look for core dump files or
very carefully do experiment s trying to isolate exactly what part of
KDE is firing off the problem. re-emerging the NVidia driver is a
no-brainer as it takes no more than 1-2 minutes to test things.
Rebuilding the machine is certainly more involved.

If you have lots of disk space you might rsync the whole machine to a
new partition to do the work, then using something other than KDE
which doesn't crash rebuild the copy from a chroot which leaves the
machine usable while the rebuild is going on.

None of this sounds like fun...

- Mark

Re: [gentoo-user] KDE and HARD lock ups.

[Dale]

Mark Knecht wrote:
>
> If I had to guess I'd say, since this followed a power failure where
> the machine was live and operating (if I've understood the thread
> through a quick scan) that some file on disk has gotten corrupted and
> it's that corruption that's causing the problem. You've checked
> memory. Let's assume that te processor and MB weren't damaged by this
> event. If that's the case - and unfortunately I don't know of any way
> to ensure it hasn't as it requires one to have a bit-accurate image of
> the machine before the power failure - there's probably no way to
> eliminate this as a possibility short of an emerge -e @world.
>
> It's not where I'd start. I'd probably look for core dump files or
> very carefully do experiment s trying to isolate exactly what part of
> KDE is firing off the problem. re-emerging the NVidia driver is a
> no-brainer as it takes no more than 1-2 minutes to test things.
> Rebuilding the machine is certainly more involved.
>
> If you have lots of disk space you might rsync the whole machine to a
> new partition to do the work, then using something other than KDE
> which doesn't crash rebuild the copy from a chroot which leaves the
> machine usable while the rebuild is going on.
>
> None of this sounds like fun...
>
> - Mark
>
>
>    

I did something similar at least.  I have two drives in here that are 
for my OS.  I have a third that is for data, videos, audio stuff and 
documents.  The data drive is a 750Gb.  The old main OS drive is a 160Gb 
and the spare OS drive is a 250Gb.  I downloaded a stage3 tarball.  I 
then set up the spare OS drive and mounted the partitions basically 
following the docs.  I then copied over /etc, disfiles and the world 
file.  After that, I did a emerge -e world which installed everything 
that I had before.  It also has a slightly newer kernel as well.

So, after running my memtest this morning while I took a nap, I booted 
into the new install.  I checked with the mount command to make sure I 
was in the new install too.  I deleted EVERYTHING KDE in my home 
directory.  After that, I logged into KDE.  A box popped up that 
composite was disabled.  It said I could hit shift alt F12 to enable.  
After I started Firefox, it locked up complete with my keyboard lights 
blinking again.

What does Fluxbox use as opposed to KDE?  Both use the Nvidia drivers 
right?  I use KDM for my login screen and I think nvidia is loaded when 
it starts and it uses nvidia thereafter.  So, if it was the driver, 
would it not mess up in Fluxbox too?   What makes Fluxbox work and KDE fail?

Could my video card be having issues?  I may take the sides off and 
unplug replug everything and give it all a once over.  Maybe just a bad 
connection or something.  Maybe?

If one of you guys were me, would you order a video card and try that?  
Keep in mind, I have surge protection inside the UPS on the wall side.  
I also have a surge protector strip that my modem, router, puter and 
monitor plugs into.  It's kind of hard to imagine that a surge could 
make it through all that and not at least smell up  the place a bit.  
I'm not saying it couldn't but just hard to imagine.  I got surge 
protection coming out the ears here.

Thoughts?

Dale

:-)  :-)

Re: [gentoo-user] KDE and HARD lock ups.

[Mark Knecht]

On Wed, Jul 6, 2011 at 3:00 PM, Dale <rdalek1967@gmail.com> wrote:
> Mark Knecht wrote:
>>
>> If I had to guess I'd say, since this followed a power failure where
>> the machine was live and operating (if I've understood the thread
>> through a quick scan) that some file on disk has gotten corrupted and
>> it's that corruption that's causing the problem. You've checked
>> memory. Let's assume that te processor and MB weren't damaged by this
>> event. If that's the case - and unfortunately I don't know of any way
>> to ensure it hasn't as it requires one to have a bit-accurate image of
>> the machine before the power failure - there's probably no way to
>> eliminate this as a possibility short of an emerge -e @world.
>>
>> It's not where I'd start. I'd probably look for core dump files or
>> very carefully do experiment s trying to isolate exactly what part of
>> KDE is firing off the problem. re-emerging the NVidia driver is a
>> no-brainer as it takes no more than 1-2 minutes to test things.
>> Rebuilding the machine is certainly more involved.
>>
>> If you have lots of disk space you might rsync the whole machine to a
>> new partition to do the work, then using something other than KDE
>> which doesn't crash rebuild the copy from a chroot which leaves the
>> machine usable while the rebuild is going on.
>>
>> None of this sounds like fun...
>>
>> - Mark
>>
>>
>>
>
> I did something similar at least.  I have two drives in here that are for my
> OS.  I have a third that is for data, videos, audio stuff and documents.
>  The data drive is a 750Gb.  The old main OS drive is a 160Gb and the spare
> OS drive is a 250Gb.  I downloaded a stage3 tarball.  I then set up the
> spare OS drive and mounted the partitions basically following the docs.  I
> then copied over /etc, disfiles and the world file.  After that, I did a
> emerge -e world which installed everything that I had before.  It also has a
> slightly newer kernel as well.
>
> So, after running my memtest this morning while I took a nap, I booted into
> the new install.  I checked with the mount command to make sure I was in the
> new install too.  I deleted EVERYTHING KDE in my home directory.  After
> that, I logged into KDE.  A box popped up that composite was disabled.  It
> said I could hit shift alt F12 to enable.  After I started Firefox, it
> locked up complete with my keyboard lights blinking again.
>
> What does Fluxbox use as opposed to KDE?  Both use the Nvidia drivers right?
>  I use KDM for my login screen and I think nvidia is loaded when it starts
> and it uses nvidia thereafter.  So, if it was the driver, would it not mess
> up in Fluxbox too?   What makes Fluxbox work and KDE fail?
>
> Could my video card be having issues?  I may take the sides off and unplug
> replug everything and give it all a once over.  Maybe just a bad connection
> or something.  Maybe?
>
> If one of you guys were me, would you order a video card and try that?  Keep
> in mind, I have surge protection inside the UPS on the wall side.  I also
> have a surge protector strip that my modem, router, puter and monitor plugs
> into.  It's kind of hard to imagine that a surge could make it through all
> that and not at least smell up  the place a bit.  I'm not saying it couldn't
> but just hard to imagine.  I got surge protection coming out the ears here.
>
> Thoughts?
>
> Dale

And this is your newer machine machine, correct? The one you built a
few months ago IIRC?

Sounds like you've takn the right steps to eliminate lots of problem
sites and it just isn't working. What a drag!

A machine lockup can come from almost anything not working. Bad
software is the easy one, but it could be hardware.

As for fluxbox vs KDE that's apples and oranges. They probably use
totally different parts of X and do it in very different ways. However
if fluxbox works perfectly for weeks then it wouldn't seem likely to
be a hardware issue unless it's a really unlikely corner case, but you
wouldn't think KDE would hit is every time and fluxbox never hits it.

Have you tried the most up to date ~amd64 drivers?

Re: [gentoo-user] KDE and HARD lock ups.

[Dale]

Mark Knecht wrote:
> On Wed, Jul 6, 2011 at 3:00 PM, Dale<rdalek1967@gmail.com>  wrote:
>    
>> Mark Knecht wrote:
>>      
>>> If I had to guess I'd say, since this followed a power failure where
>>> the machine was live and operating (if I've understood the thread
>>> through a quick scan) that some file on disk has gotten corrupted and
>>> it's that corruption that's causing the problem. You've checked
>>> memory. Let's assume that te processor and MB weren't damaged by this
>>> event. If that's the case - and unfortunately I don't know of any way
>>> to ensure it hasn't as it requires one to have a bit-accurate image of
>>> the machine before the power failure - there's probably no way to
>>> eliminate this as a possibility short of an emerge -e @world.
>>>
>>> It's not where I'd start. I'd probably look for core dump files or
>>> very carefully do experiment s trying to isolate exactly what part of
>>> KDE is firing off the problem. re-emerging the NVidia driver is a
>>> no-brainer as it takes no more than 1-2 minutes to test things.
>>> Rebuilding the machine is certainly more involved.
>>>
>>> If you have lots of disk space you might rsync the whole machine to a
>>> new partition to do the work, then using something other than KDE
>>> which doesn't crash rebuild the copy from a chroot which leaves the
>>> machine usable while the rebuild is going on.
>>>
>>> None of this sounds like fun...
>>>
>>> - Mark
>>>
>>>
>>>
>>>        
>> I did something similar at least.  I have two drives in here that are for my
>> OS.  I have a third that is for data, videos, audio stuff and documents.
>>   The data drive is a 750Gb.  The old main OS drive is a 160Gb and the spare
>> OS drive is a 250Gb.  I downloaded a stage3 tarball.  I then set up the
>> spare OS drive and mounted the partitions basically following the docs.  I
>> then copied over /etc, disfiles and the world file.  After that, I did a
>> emerge -e world which installed everything that I had before.  It also has a
>> slightly newer kernel as well.
>>
>> So, after running my memtest this morning while I took a nap, I booted into
>> the new install.  I checked with the mount command to make sure I was in the
>> new install too.  I deleted EVERYTHING KDE in my home directory.  After
>> that, I logged into KDE.  A box popped up that composite was disabled.  It
>> said I could hit shift alt F12 to enable.  After I started Firefox, it
>> locked up complete with my keyboard lights blinking again.
>>
>> What does Fluxbox use as opposed to KDE?  Both use the Nvidia drivers right?
>>   I use KDM for my login screen and I think nvidia is loaded when it starts
>> and it uses nvidia thereafter.  So, if it was the driver, would it not mess
>> up in Fluxbox too?   What makes Fluxbox work and KDE fail?
>>
>> Could my video card be having issues?  I may take the sides off and unplug
>> replug everything and give it all a once over.  Maybe just a bad connection
>> or something.  Maybe?
>>
>> If one of you guys were me, would you order a video card and try that?  Keep
>> in mind, I have surge protection inside the UPS on the wall side.  I also
>> have a surge protector strip that my modem, router, puter and monitor plugs
>> into.  It's kind of hard to imagine that a surge could make it through all
>> that and not at least smell up  the place a bit.  I'm not saying it couldn't
>> but just hard to imagine.  I got surge protection coming out the ears here.
>>
>> Thoughts?
>>
>> Dale
>>      
> And this is your newer machine machine, correct? The one you built a
> few months ago IIRC?
>
> Sounds like you've takn the right steps to eliminate lots of problem
> sites and it just isn't working. What a drag!
>
> A machine lockup can come from almost anything not working. Bad
> software is the easy one, but it could be hardware.
>
> As for fluxbox vs KDE that's apples and oranges. They probably use
> totally different parts of X and do it in very different ways. However
> if fluxbox works perfectly for weeks then it wouldn't seem likely to
> be a hardware issue unless it's a really unlikely corner case, but you
> wouldn't think KDE would hit is every time and fluxbox never hits it.
>
> Have you tried the most up to date ~amd64 drivers?
>
>
>    

Let me add some more confusion.  I'm in KDE right now.  I took the sides 
off and blew out a VERY little bit of dust and replugged things, video 
card, mobo power cables and such as that.  I also booted to the newly 
created .kde directory instead of my old one.  This is the old install 
tho.  I logged in with nothing running, blank session, and then took a 
nap.  I got up a few minutes ago and KDE is still running.  I opened 
Kpat, card game, and played a little of it.  After a few minutes, I 
opened Seamonkey and am typing as you can see.  Same kernel, same 
nvidia, same packages and same hardware.

I did notice something a bit ago but have not posted since I noticed 
it.  It seems to crash when I open Konsole as root.  I have my menu set 
up to run it as root and that is where I do my sync and updates.  As 
soon as the window pops up, my mouse pointer freezes.  I thought it was 
a coincidence until now.  After I send this reply, I'm going to open 
Konsole and nothing else.  I want to see if it does it again.  Since it 
has been running this long with Konsole closed, it would be odd if it 
fails when I open that up here shortly.

I have tried to eliminate things one by one.  I tried a different kernel 
before I ever posted anything but I'm not sure I mentioned it.  Doing 
that is almost like breathing.  If I run into issues, I try a old kernel 
first.  I have also tried both nvidia drivers that are in portage with a 
few different kernels.  As mentioned, I also tried a fresh install as 
well.  This makes me question hardware but since everything has to work 
together, who knows where to start.  Could it be the extra ram that 
Konsole accesses?  Could it be a bad instruction that the CPU doesn't 
like?  Could it be the video card trying to redraw the screen?  Lots of 
questions with few answers.

Well, I'm going to send this then open Konsole.  See if it locks up again.

Dale

:-)  :-)

Re: [gentoo-user] KDE and HARD lock ups.

[Dale]

Dale wrote:
>
> Let me add some more confusion.  I'm in KDE right now.  I took the 
> sides off and blew out a VERY little bit of dust and replugged things, 
> video card, mobo power cables and such as that.  I also booted to the 
> newly created .kde directory instead of my old one.  This is the old 
> install tho.  I logged in with nothing running, blank session, and 
> then took a nap.  I got up a few minutes ago and KDE is still 
> running.  I opened Kpat, card game, and played a little of it.  After 
> a few minutes, I opened Seamonkey and am typing as you can see.  Same 
> kernel, same nvidia, same packages and same hardware.
>
> I did notice something a bit ago but have not posted since I noticed 
> it.  It seems to crash when I open Konsole as root.  I have my menu 
> set up to run it as root and that is where I do my sync and updates.  
> As soon as the window pops up, my mouse pointer freezes.  I thought it 
> was a coincidence until now.  After I send this reply, I'm going to 
> open Konsole and nothing else.  I want to see if it does it again.  
> Since it has been running this long with Konsole closed, it would be 
> odd if it fails when I open that up here shortly.
>
> I have tried to eliminate things one by one.  I tried a different 
> kernel before I ever posted anything but I'm not sure I mentioned it.  
> Doing that is almost like breathing.  If I run into issues, I try a 
> old kernel first.  I have also tried both nvidia drivers that are in 
> portage with a few different kernels.  As mentioned, I also tried a 
> fresh install as well.  This makes me question hardware but since 
> everything has to work together, who knows where to start.  Could it 
> be the extra ram that Konsole accesses?  Could it be a bad instruction 
> that the CPU doesn't like?  Could it be the video card trying to 
> redraw the screen?  Lots of questions with few answers.
>
> Well, I'm going to send this then open Konsole.  See if it locks up 
> again.
>
> Dale
>
> :-)  :-)
>

I forgot to answer one question you had.  Yes, this is my new rig that 
was built a while back.

As I was suspecting, I opened Konsole after sending the last message and 
it locked up real good.  I did manage to get the SysReq keys to work 
tho.  I opened Konsole from the menu, the password window popped up and 
I typed in my root password.  After that, the Konsole window popped up 
and as soon as I touched the mouse, lock up.

After I rebooted and logged in, I wanted to see if it could be a bad 
memory issue or even the video card itself.  I opened a HD video, 
Asteroid Galaxy Tour, and played it back to back.  It never missed a 
beat.  I'm going to avoid Konsole and see what all else I can open until 
it fails again.  I'll post back what happens.

Any of you gurus figure out why my system hates to open Konsole as 
root?  I might add, I used konsole from inside Fluxbox with no problems.

Dale

:-)  :-)

Re: [gentoo-user] KDE and HARD lock ups.

[Dale]

Dale wrote:
> Dale wrote:
>>
>> Let me add some more confusion.  I'm in KDE right now.  I took the 
>> sides off and blew out a VERY little bit of dust and replugged 
>> things, video card, mobo power cables and such as that.  I also 
>> booted to the newly created .kde directory instead of my old one.  
>> This is the old install tho.  I logged in with nothing running, blank 
>> session, and then took a nap.  I got up a few minutes ago and KDE is 
>> still running.  I opened Kpat, card game, and played a little of it.  
>> After a few minutes, I opened Seamonkey and am typing as you can 
>> see.  Same kernel, same nvidia, same packages and same hardware.
>>
>> I did notice something a bit ago but have not posted since I noticed 
>> it.  It seems to crash when I open Konsole as root.  I have my menu 
>> set up to run it as root and that is where I do my sync and updates.  
>> As soon as the window pops up, my mouse pointer freezes.  I thought 
>> it was a coincidence until now.  After I send this reply, I'm going 
>> to open Konsole and nothing else.  I want to see if it does it 
>> again.  Since it has been running this long with Konsole closed, it 
>> would be odd if it fails when I open that up here shortly.
>>
>> I have tried to eliminate things one by one.  I tried a different 
>> kernel before I ever posted anything but I'm not sure I mentioned 
>> it.  Doing that is almost like breathing.  If I run into issues, I 
>> try a old kernel first.  I have also tried both nvidia drivers that 
>> are in portage with a few different kernels.  As mentioned, I also 
>> tried a fresh install as well.  This makes me question hardware but 
>> since everything has to work together, who knows where to start.  
>> Could it be the extra ram that Konsole accesses?  Could it be a bad 
>> instruction that the CPU doesn't like?  Could it be the video card 
>> trying to redraw the screen?  Lots of questions with few answers.
>>
>> Well, I'm going to send this then open Konsole.  See if it locks up 
>> again.
>>
>> Dale
>>
>> :-)  :-)
>>
>
> I forgot to answer one question you had.  Yes, this is my new rig that 
> was built a while back.
>
> As I was suspecting, I opened Konsole after sending the last message 
> and it locked up real good.  I did manage to get the SysReq keys to 
> work tho.  I opened Konsole from the menu, the password window popped 
> up and I typed in my root password.  After that, the Konsole window 
> popped up and as soon as I touched the mouse, lock up.
>
> After I rebooted and logged in, I wanted to see if it could be a bad 
> memory issue or even the video card itself.  I opened a HD video, 
> Asteroid Galaxy Tour, and played it back to back.  It never missed a 
> beat.  I'm going to avoid Konsole and see what all else I can open 
> until it fails again.  I'll post back what happens.
>
> Any of you gurus figure out why my system hates to open Konsole as 
> root?  I might add, I used konsole from inside Fluxbox with no problems.
>
> Dale
>
> :-)  :-)
>

A little more info.  After my last message, I opened Firefox.  It locked 
up.  That runs as a regular user of course.  So, I wanted to test a 
theory.  I logged into Fluxbox after my reboot.  I opened Firefox and it 
locked up.  Nothing else was running.  My first lock up in Fluxbox!!

So, Firefox will lock up in BOTH KDE and Fluxbox.  What do Konsole in 
KDE, Fluxbox in both KDE and Fluxbox have in common?   Keep in mind, 
Konsole works fine in Fluxbox.

I thought of something tho.  I upgraded glibc a while back.  I had some 
KDE updates and a Firefox update just a little bit before this 
happened.  Could this be related somehow?

Also, when Firefox locked up, I went to my old rig and tried to login to 
this rig.  The network connection was dead.  So, that time at least, it 
was a serious lock up.  Sometimes the SysReq keys work, sometimes not.

Thoughts?  Anyone think of anything that could cause this?

Dale

:-)  :-)

Re: [gentoo-user] KDE and HARD lock ups.

[William Kenworthy]

On Wed, 2011-07-06 at 23:01 -0500, Dale wrote:
> Dale wrote:
> > Dale wrote:
> >>
> Thoughts?  Anyone think of anything that could cause this?
> 
> Dale
> 
> :-)  :-)
> 

Hi Dale, I have not been following the thread, but have you tried
starting the problem apps, konsole etc from a basic xterm with strace?

BillK



-- 
William Kenworthy <billk@iinet.net.au>
Home in Perth!

Re: [gentoo-user] KDE and HARD lock ups.

[Dale]

William Kenworthy wrote:
> On Wed, 2011-07-06 at 23:01 -0500, Dale wrote:
>    
>> Dale wrote:
>>      
>>> Dale wrote:
>>>        
>>>>          
>> Thoughts?  Anyone think of anything that could cause this?
>>
>> Dale
>>
>> :-)  :-)
>>
>>      
> Hi Dale, I have not been following the thread, but have you tried
> starting the problem apps, konsole etc from a basic xterm with strace?
>
> BillK
>
>    

That's a thought.  I happened to already have a Konsole open in Fluxbox 
so I typed in Firefox.  It started then locked up Fluxbox.  I could 
still see the Konsole screen and nothing was printed as far as error 
messages.  I'm not sure I can tell anything with strace.  I'm not sure I 
will be able to see the messages enough to see what happens.  Since the 
GUI locks up, I can't move things around or save the errors either.

It's a good idea tho.  I'm just not sure how to skin this little kitty.

Dale

:-)  :-)

Re: [gentoo-user] KDE and HARD lock ups.

[Mark Knecht]

On Wed, Jul 6, 2011 at 9:01 PM, Dale <rdalek1967@gmail.com> wrote:
<SNIP>
> A little more info.  After my last message, I opened Firefox.  It locked up.
>  That runs as a regular user of course.  So, I wanted to test a theory.  I
> logged into Fluxbox after my reboot.  I opened Firefox and it locked up.
>  Nothing else was running.  My first lock up in Fluxbox!!
>
> So, Firefox will lock up in BOTH KDE and Fluxbox.  What do Konsole in KDE,
> Fluxbox in both KDE and Fluxbox have in common?   Keep in mind, Konsole
> works fine in Fluxbox.
>
> I thought of something tho.  I upgraded glibc a while back.  I had some KDE
> updates and a Firefox update just a little bit before this happened.  Could
> this be related somehow?
>
> Also, when Firefox locked up, I went to my old rig and tried to login to
> this rig.  The network connection was dead.  So, that time at least, it was
> a serious lock up.  Sometimes the SysReq keys work, sometimes not.
>
> Thoughts?  Anyone think of anything that could cause this?
>
> Dale
>
> :-)  :-)
>
>

You should continue to investigate the glibc thing. There was a thread
about how it's causing problems for someone running LibreOffice I
think.

You might also look more at what part of Firefox s causing the lockup.
Is it Firefox proper, or is it something caused by your homepage? For
instance, if they make use of Flash or Java it could be one of them
causing the lockup and not specifically Firefox itself. Can yo erase
Firefox preferences so that it opes to a blank page. Does it still
lock up. Have you removed all cookies, etc., to see if one of them is
causing the problems. Since fluxbox doesn't crash as often you might
work there to clean things up and then come back to KDE to see if it
has helped.

Consider an emerge -C on things you don't absolutely need, like Flash
or whatever you're using, to figure out what's involved. Also, are you
using Firefox 3 or 4? Consider trying the other.

As with other apps, try running Firefox from a terminal and see if it
throws any error messages.

Good luck,
Mark

Re: [gentoo-user] KDE and HARD lock ups.

[Dale]

Mark Knecht wrote:
>
> You should continue to investigate the glibc thing. There was a thread
> about how it's causing problems for someone running LibreOffice I
> think.
>
> You might also look more at what part of Firefox s causing the lockup.
> Is it Firefox proper, or is it something caused by your homepage? For
> instance, if they make use of Flash or Java it could be one of them
> causing the lockup and not specifically Firefox itself. Can yo erase
> Firefox preferences so that it opes to a blank page. Does it still
> lock up. Have you removed all cookies, etc., to see if one of them is
> causing the problems. Since fluxbox doesn't crash as often you might
> work there to clean things up and then come back to KDE to see if it
> has helped.
>
> Consider an emerge -C on things you don't absolutely need, like Flash
> or whatever you're using, to figure out what's involved. Also, are you
> using Firefox 3 or 4? Consider trying the other.
>
> As with other apps, try running Firefox from a terminal and see if it
> throws any error messages.
>
> Good luck,
> Mark
>
>
>    


I haven't been ignoring your suggestions but I did try them a bit ago.  
It's in another reply.  Thanks for the suggestions tho.

As for trying to run from a terminal, if I do that, I can't see the 
errors and when the kernel panics, I lose the messages.  Sort of a catch 
22 here.  Would be nice if I could tho.

Thanks.

Dale

:-)  :-)

Re: [gentoo-user] KDE and HARD lock ups.

[William Kenworthy]

firefox --help lists a DISPLAY option.  Start it from a console and set
$DISPLAY elsewhere, even remote if thats what it takes ...


BillK


On Fri, 2011-07-08 at 20:53 -0500, Dale wrote:
> Mark Knecht wrote:
> >
> > You should continue to investigate the glibc thing. There was a thread
> > about how it's causing problems for someone running LibreOffice I
> > think.
> >
> > You might also look more at what part of Firefox s causing the lockup.
> > Is it Firefox proper, or is it something caused by your homepage? For
> > instance, if they make use of Flash or Java it could be one of them
> > causing the lockup and not specifically Firefox itself. Can yo erase
> > Firefox preferences so that it opes to a blank page. Does it still
> > lock up. Have you removed all cookies, etc., to see if one of them is
> > causing the problems. Since fluxbox doesn't crash as often you might
> > work there to clean things up and then come back to KDE to see if it
> > has helped.
> >
> > Consider an emerge -C on things you don't absolutely need, like Flash
> > or whatever you're using, to figure out what's involved. Also, are you
> > using Firefox 3 or 4? Consider trying the other.
> >
> > As with other apps, try running Firefox from a terminal and see if it
> > throws any error messages.
> >
> > Good luck,
> > Mark
> >
> >
> >    
> 
> 
> I haven't been ignoring your suggestions but I did try them a bit ago.  
> It's in another reply.  Thanks for the suggestions tho.
> 
> As for trying to run from a terminal, if I do that, I can't see the 
> errors and when the kernel panics, I lose the messages.  Sort of a catch 
> 22 here.  Would be nice if I could tho.
> 
> Thanks.
> 
> Dale
> 
> :-)  :-)
> 

-- 
William Kenworthy <billk@iinet.net.au>
Home in Perth!

Re: [gentoo-user] KDE and HARD lock ups.

[Jesús J. Guerrero Botella]

2011/7/6 Dale <rdalek1967@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.

-- 
Jesús Guerrero Botella

Re: [gentoo-user] KDE and HARD lock ups.

[Dale]

Jesús J. Guerrero Botella wrote:
> 2011/7/6 Dale<rdalek1967@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

:-)  :-)

Re: [gentoo-user] KDE and HARD lock ups.

[Dale]

Dale wrote:
>
> 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
>
> :-)  :-)
>

I tried the latest .39 kernel.  It does the exact same thing as a .38 
kernel.  I also tried a kernel that was the first one I made when I 
built this rig.  It locked up as well.  It appears to me that either 
every single kernel, including ones that worked fine before, are either 
broke or it is not related to the kernel itself.  I'm starting to bet on 
the last one.

I did notice one thing tho.  When I tried to emerge the nvidia drivers 
for the .39 kernel, emerge wanted to DOWNGRADE glibc.  This ain't my 
first trip to Linux land.  Can someone explain to me why the heck emerge 
wants to do something as crazy as that?  I think every one here knows 
that is a really bad thing to even think of much less actually try.  Is 
it possible that something in glibc is causing trouble and this is 
someone's wet dream to fix it?

Thanks.

Dale

:-)  :-)

Re: [gentoo-user] KDE and HARD lock ups.

[Volker Armin Hemmann]

On Tuesday 05 July 2011 15:41:13 Dale wrote:

update your fucking drivers.

Seriously, no userspace app does something like this. The driver is broken, 
KDE touches the broken part and BOOM.

Don't blame KDE, blame nvidia.

And update the driver.


-- 
#163933

Re: [gentoo-user] KDE and HARD lock ups.

[Dale]

[-- Attachment #1: Type: text/plain, Size: 1393 bytes --]

Volker Armin Hemmann wrote:
> On Tuesday 05 July 2011 15:41:13 Dale wrote:
>
> update your fucking drivers.
>
> Seriously, no userspace app does something like this. The driver is broken,
> KDE touches the broken part and BOOM.
>
> Don't blame KDE, blame nvidia.
>
> And update the driver.
>
>
>    

I don't think a bad video driver would cause this:

*root@fireball / # emerge -av =x11-drivers/nvidia-drivers-270.41.19

These are the packages that would be merged, in order:

Calculating dependencies |

!!! Invalid or corrupt dependency specification:

Invalid atom (????1), token 1

(dev-perl/Net-SSLeay-1.36::unxlngx, installed)

Portage is unable to process the dependencies of the 'dev-perl/Net-
SSLeay-1.36' package. In order to correct this problem, the package
should be uninstalled, reinstalled, or upgraded. As a temporary
workaround, the --nodeps option can be used to ignore all dependencies.
For reference, the problematic dependencies can be found in the *DEPEND
files located in '/var/db/pkg/dev-perl/Net-SSLeay-1.36/'.
... done!
root@fireball / #

Whatever the problems is, things are breaking.  I think something in KDE 
is broke, like corrupt file or some corrupt config somewhere, and it was 
just the first symptom of the problem.  No matter what I try to emerge, 
I get errors like this.

Still think emerging a new video driver is going to help?  ;-)

Dale

:-)  :-)
*

[-- Attachment #2: Type: text/html, Size: 1889 bytes --]

Re: [gentoo-user] KDE and HARD lock ups.

[Paul Hartman]

On Tue, Jul 5, 2011 at 11:16 PM, Dale <rdalek1967@gmail.com> wrote:
>
> Whatever the problems is, things are breaking.  I think something in KDE is
> broke, like corrupt file or some corrupt config somewhere, and it was just
> the first symptom of the problem.  No matter what I try to emerge, I get
> errors like this.

I would definitely run sys-apps/memtest86+ for a few hours (or
more)... Random lockups and corruption sounds like RAM issues.

Re: [gentoo-user] KDE and HARD lock ups.

[Dale]

Paul Hartman wrote:
> On Tue, Jul 5, 2011 at 11:16 PM, Dale<rdalek1967@gmail.com>  wrote:
>    
>> Whatever the problems is, things are breaking.  I think something in KDE is
>> broke, like corrupt file or some corrupt config somewhere, and it was just
>> the first symptom of the problem.  No matter what I try to emerge, I get
>> errors like this.
>>      
> I would definitely run sys-apps/memtest86+ for a few hours (or
> more)... Random lockups and corruption sounds like RAM issues.
>
>
>    

I had a power failure the other day not long before this started.  
Needless to say, this has the potential of leading to problems with 
files, which is what I thought was wrong with KDE.  I don't KNOW that 
this is the problem but it is a possibility.  After the install gets 
done, I do plan to run some tests before even booting into the new install.

I just hope this drive isn't going out on me.  It's not to old but we 
all know how they are.  They break when they are ready, not when it is 
convenient for us.

If the tests fail, then maybe I can fix some things in my old install 
after some repairs.  If it passes the test, I hope the new install does 
better.  I'll report what happens tho.

Thinking about it, I got 16Gbs on here.  That could take a while to 
test.  O_O

Dale

:-)  :-)

Re: [gentoo-user] KDE and HARD lock ups.

[Paul Hartman]

On Wed, Jul 6, 2011 at 12:12 AM, Dale <rdalek1967@gmail.com> wrote:
> Thinking about it, I got 16Gbs on here.  That could take a while to test.
>  O_O

When I'm in a hurry I just run test 5, it seems that 99% of the time
that's the test that finds errors anyway. Best, of course, is to run
them all, but I usually do test 5 only first since it's more likely to
fail sooner and can do passes faster. :) Then if it does NOT fail I'll
run all tests, just to be sure.

Re: [gentoo-user] KDE and HARD lock ups.

[Dale]

Paul Hartman wrote:
> On Wed, Jul 6, 2011 at 12:12 AM, Dale<rdalek1967@gmail.com>  wrote:
>    
>> Thinking about it, I got 16Gbs on here.  That could take a while to test.
>>   O_O
>>      
> When I'm in a hurry I just run test 5, it seems that 99% of the time
> that's the test that finds errors anyway. Best, of course, is to run
> them all, but I usually do test 5 only first since it's more likely to
> fail sooner and can do passes faster. :) Then if it does NOT fail I'll
> run all tests, just to be sure.
>
>
>    

I didn't know that.  I'll start with it then let it run at least a 
couple passes of a full test.  I got some good ram so I sort of think it 
is OK.  I really think the power failure the other day messed up 
something, drive itself, some file or something that is causing this.  I 
just get the sense there is a snowball coming tho.

My current plan, finish this new install.  Test the ram and hope it is 
OK.  Test the new install and see if it holds up.  If it does, I plan to 
test the heck out of the old drive.  If it passes tests then I may copy 
my install over and test it again.  If it fails, door stop most likely.  
Are they even worth shipping back anymore?  It may not even be under 
warranty now tho.  It's about a year old.

I'm just hoping for a fix SOON.

Dale

:-)  :-)

[gentoo-user] Re: KDE and HARD lock ups.

[walt]

On 07/05/2011 10:38 PM, Dale wrote:

> My current plan, finish this new install.  Test the ram and hope it is OK.

I can feel your pain :(  This may not help, but I thought I'd mention it
just because nothing else has helped so far.

I started having random keyboard issues right after the most recent xorg
update on my ~x86 and ~amd64 machines.

Maybe just once/day or so I'll hit a key and the auto-repeat function
starts repeating the keystroke ad infinitum until I hit Backspace.

This is not a lockup like your problem, but it was striking that this
random keyboard problem started right after the recent xorg update.
(Yes, I recompiled all the drivers after the upgrade.)

Since you are recompiling/reinstalling everything anyway, what about
masking the most recent xorg-server/xorg-driver updates so you can test
older versions?  You quad-core speed demon ;p

Re: [gentoo-user] Re: KDE and HARD lock ups.

[Dale]

walt wrote:
> On 07/05/2011 10:38 PM, Dale wrote:
>
>    
>> My current plan, finish this new install.  Test the ram and hope it is OK.
>>      
> I can feel your pain :(  This may not help, but I thought I'd mention it
> just because nothing else has helped so far.
>
> I started having random keyboard issues right after the most recent xorg
> update on my ~x86 and ~amd64 machines.
>
> Maybe just once/day or so I'll hit a key and the auto-repeat function
> starts repeating the keystroke ad infinitum until I hit Backspace.
>
> This is not a lockup like your problem, but it was striking that this
> random keyboard problem started right after the recent xorg update.
> (Yes, I recompiled all the drivers after the upgrade.)
>
> Since you are recompiling/reinstalling everything anyway, what about
> masking the most recent xorg-server/xorg-driver updates so you can test
> older versions?  You quad-core speed demon ;p
>
>    

I'm going to add this to the "to try" list.  That sort of makes sense.  
Most of the time it is a hard lock up.  It won't even let me ssh in from 
my old rig or use the SysReq keys.  Sometimes tho, it acts like things 
are still running but the GUI is locked up.  I didn't get to try to ssh 
in then tho.  I know once I had a compile running and I could see the 
hard drive light blinking as it compiled.  So something was working that 
time at least.   One thing I did learn, if the lights on the keyboard 
are blinking, it's locked up tight.  If they are not blinking, I can use 
the SysReq keys to reboot.

I also thought about just booting Knoppix and seeing if it works.  Maybe 
it is just some weird code that Konsole and Firefox have in common 
somehow.  The only thing is, I'm sure they will use different version of 
all the software.  It may not make any difference except to rule out 
hardware.  I'm pretty sure hardware is OK but we know how hard those are 
to track down.

One more thing on the try list if this doesn't work.

Thanks.

Dale

:-)  :-)

Re: [gentoo-user] Re: KDE and HARD lock ups.

[Mick]

[-- Attachment #1: Type: Text/Plain, Size: 2281 bytes --]

On Friday 08 Jul 2011 05:43:58 Dale wrote:
> walt wrote:
> > On 07/05/2011 10:38 PM, Dale wrote:
> >> My current plan, finish this new install.  Test the ram and hope it is
> >> OK.
> > 
> > I can feel your pain :(  This may not help, but I thought I'd mention it
> > just because nothing else has helped so far.
> > 
> > I started having random keyboard issues right after the most recent xorg
> > update on my ~x86 and ~amd64 machines.
> > 
> > Maybe just once/day or so I'll hit a key and the auto-repeat function
> > starts repeating the keystroke ad infinitum until I hit Backspace.
> > 
> > This is not a lockup like your problem, but it was striking that this
> > random keyboard problem started right after the recent xorg update.
> > (Yes, I recompiled all the drivers after the upgrade.)
> > 
> > Since you are recompiling/reinstalling everything anyway, what about
> > masking the most recent xorg-server/xorg-driver updates so you can test
> > older versions?  You quad-core speed demon ;p
> 
> I'm going to add this to the "to try" list.  That sort of makes sense.
> Most of the time it is a hard lock up.  It won't even let me ssh in from
> my old rig or use the SysReq keys.  Sometimes tho, it acts like things
> are still running but the GUI is locked up.  I didn't get to try to ssh
> in then tho.  I know once I had a compile running and I could see the
> hard drive light blinking as it compiled.  So something was working that
> time at least.   One thing I did learn, if the lights on the keyboard
> are blinking, it's locked up tight.  If they are not blinking, I can use
> the SysReq keys to reboot.
> 
> I also thought about just booting Knoppix and seeing if it works.  Maybe
> it is just some weird code that Konsole and Firefox have in common
> somehow.  The only thing is, I'm sure they will use different version of
> all the software.  It may not make any difference except to rule out
> hardware.  I'm pretty sure hardware is OK but we know how hard those are
> to track down.
> 
> One more thing on the try list if this doesn't work.
> 
> Thanks.
> 
> Dale

I'm stating the obvious here, but have you tried restoring from a back up that 
you made before these problems started?

-- 
Regards,
Mick

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-user] Re: KDE and HARD lock ups.

[Dale]

Mick wrote:
> On Friday 08 Jul 2011 05:43:58 Dale wrote:
>    
>> walt wrote:
>>      
>>> On 07/05/2011 10:38 PM, Dale wrote:
>>>        
>>>> My current plan, finish this new install.  Test the ram and hope it is
>>>> OK.
>>>>          
>>> I can feel your pain :(  This may not help, but I thought I'd mention it
>>> just because nothing else has helped so far.
>>>
>>> I started having random keyboard issues right after the most recent xorg
>>> update on my ~x86 and ~amd64 machines.
>>>
>>> Maybe just once/day or so I'll hit a key and the auto-repeat function
>>> starts repeating the keystroke ad infinitum until I hit Backspace.
>>>
>>> This is not a lockup like your problem, but it was striking that this
>>> random keyboard problem started right after the recent xorg update.
>>> (Yes, I recompiled all the drivers after the upgrade.)
>>>
>>> Since you are recompiling/reinstalling everything anyway, what about
>>> masking the most recent xorg-server/xorg-driver updates so you can test
>>> older versions?  You quad-core speed demon ;p
>>>        
>> I'm going to add this to the "to try" list.  That sort of makes sense.
>> Most of the time it is a hard lock up.  It won't even let me ssh in from
>> my old rig or use the SysReq keys.  Sometimes tho, it acts like things
>> are still running but the GUI is locked up.  I didn't get to try to ssh
>> in then tho.  I know once I had a compile running and I could see the
>> hard drive light blinking as it compiled.  So something was working that
>> time at least.   One thing I did learn, if the lights on the keyboard
>> are blinking, it's locked up tight.  If they are not blinking, I can use
>> the SysReq keys to reboot.
>>
>> I also thought about just booting Knoppix and seeing if it works.  Maybe
>> it is just some weird code that Konsole and Firefox have in common
>> somehow.  The only thing is, I'm sure they will use different version of
>> all the software.  It may not make any difference except to rule out
>> hardware.  I'm pretty sure hardware is OK but we know how hard those are
>> to track down.
>>
>> One more thing on the try list if this doesn't work.
>>
>> Thanks.
>>
>> Dale
>>      
> I'm stating the obvious here, but have you tried restoring from a back up that
> you made before these problems started?
>
>    

I usually have a backup but I got rid of it a month or so ago.  I was 
planning to take the drive out and use it for something else but never 
got around to it.  Before that I played with LVM a bit.

So far, I have upgraded gcc and glibc and the emerge -e world is almost 
finished.  If it still locks up, I'm going to try a different xorg and 
friends.  Someone else mentioned a bug that is pretty close to what I 
have going on.

I'm going to fix this even if I don't know for sure what caused it.  If 
after this emerge it works, it has to be either gcc or glibc.  If it 
still does it and I upgrade/downgrade xorg and friends then it works, 
then I know it was one of those.

I'm just hoping for a fix and glad I got Fluxbox on here.  Fluxbox ain't 
fancy but it works well for a backup..  I have to add, it is pretty 
snappy on a 4 core 3.2Ghz CPU with 16Gbs of ram too.  lol

Dale

:-)  :-)

Re: [gentoo-user] Re: KDE and HARD lock ups.

[Dale]

Dale wrote:
> Mick wrote:
>> I'm stating the obvious here, but have you tried restoring from a 
>> back up that
>> you made before these problems started?
>>
>
> I usually have a backup but I got rid of it a month or so ago.  I was 
> planning to take the drive out and use it for something else but never 
> got around to it.  Before that I played with LVM a bit.
>
> So far, I have upgraded gcc and glibc and the emerge -e world is 
> almost finished.  If it still locks up, I'm going to try a different 
> xorg and friends.  Someone else mentioned a bug that is pretty close 
> to what I have going on.
>
> I'm going to fix this even if I don't know for sure what caused it.  
> If after this emerge it works, it has to be either gcc or glibc.  If 
> it still does it and I upgrade/downgrade xorg and friends then it 
> works, then I know it was one of those.
>
> I'm just hoping for a fix and glad I got Fluxbox on here.  Fluxbox 
> ain't fancy but it works well for a backup..  I have to add, it is 
> pretty snappy on a 4 core 3.2Ghz CPU with 16Gbs of ram too.  lol
>
> Dale
>
> :-)  :-)
>

If you ever see me in person, kick me real hard.  I read your reply then 
had a thought.  I forgot to switch to the new compiler BEFORE I started 
the emerge.  So, I almost recompiled everything with the same gcc.  At 
least your reply made me think of it.  ;-)

< hangs head in shame and sighs >

Dale

:-)  :-)

P. S.  I feel like a idiot.  What a NOOB mistake.

Re: [gentoo-user] Re: Firefox and kernel panics.

[Dale]

OK.  Back to the original thread.

Here we go again.  Everything seems to work EXCEPT Firefox.  When I log 
into KDE, I can run Seamonkey, Kpat, Konqueror, Konsole, gkrellm and 
such but as soon as I start Firefox, it locks up tight.  Tight enough 
that the kernel panics and it resets since Neil informed me how to set 
that up.  Thanks Neil!

On Firefox, I have unmerged both nspluginwrapper & adobe-flash.  Still 
does the same.  I also tried the unstable version of Firefox 3 and even 
the unstable Firefox 4.  I don't think it is Firefox itself but 
something that Firefox accesses or loads up.  Keep in mind, when I 
upgraded Firefox it also pulled in new xulrunner packages as well.  Is 
there anything else I should unmerge?  Keep in mind, I can't open 
Firefox.  Should I try to run Firefox as root to see if it locks up then 
too?

So, what in the world is it that Firefox does that can cause a kernel 
panic?  Also, I can surf with both Seamonkey and Konqueror and 
everything works just fine.  It seems only Firefox, any version, is 
affected by this.

Now what?  I use Firefox to go to youtube and stuff to get music 
videos.  It just does better than Seamonkey for me.

Dale

:-)  :-)

Re: [gentoo-user] Re: Firefox and kernel panics.

[Mick]

[-- Attachment #1: Type: Text/Plain, Size: 1232 bytes --]

On Saturday 09 Jul 2011 02:49:55 Dale wrote:
> OK.  Back to the original thread.
> 
> Here we go again.  Everything seems to work EXCEPT Firefox.  When I log
> into KDE, I can run Seamonkey, Kpat, Konqueror, Konsole, gkrellm and
> such but as soon as I start Firefox, it locks up tight.  Tight enough
> that the kernel panics and it resets since Neil informed me how to set
> that up.  Thanks Neil!
> 
> On Firefox, I have unmerged both nspluginwrapper & adobe-flash.  Still
> does the same.  I also tried the unstable version of Firefox 3 and even
> the unstable Firefox 4.  I don't think it is Firefox itself but
> something that Firefox accesses or loads up.  Keep in mind, when I
> upgraded Firefox it also pulled in new xulrunner packages as well.  Is
> there anything else I should unmerge?  Keep in mind, I can't open
> Firefox.  Should I try to run Firefox as root to see if it locks up then
> too?

Personally I would not run FF as root.  It should run as plain user and be 
able to access all that it needs to do its job.  What you haven't told us is 
if you have tried the stable FF version 3.6.17 and if you are also getting the 
same problems with the www-client/firefox-bin?
-- 
Regards,
Mick

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-user] Re: Firefox and kernel panics.

[Dale]

Mick wrote:
> On Saturday 09 Jul 2011 02:49:55 Dale wrote:
>    
>> OK.  Back to the original thread.
>>
>> Here we go again.  Everything seems to work EXCEPT Firefox.  When I log
>> into KDE, I can run Seamonkey, Kpat, Konqueror, Konsole, gkrellm and
>> such but as soon as I start Firefox, it locks up tight.  Tight enough
>> that the kernel panics and it resets since Neil informed me how to set
>> that up.  Thanks Neil!
>>
>> On Firefox, I have unmerged both nspluginwrapper&  adobe-flash.  Still
>> does the same.  I also tried the unstable version of Firefox 3 and even
>> the unstable Firefox 4.  I don't think it is Firefox itself but
>> something that Firefox accesses or loads up.  Keep in mind, when I
>> upgraded Firefox it also pulled in new xulrunner packages as well.  Is
>> there anything else I should unmerge?  Keep in mind, I can't open
>> Firefox.  Should I try to run Firefox as root to see if it locks up then
>> too?
>>      
> Personally I would not run FF as root.  It should run as plain user and be
> able to access all that it needs to do its job.  What you haven't told us is
> if you have tried the stable FF version 3.6.17 and if you are also getting the
> same problems with the www-client/firefox-bin?
>    

3.6.17 was what I had if I recall correctly.  I had whatever was the 
stable version.  I then went up to the unstable version of 3 then to the 
4 version.  All did the same.  That's why I don't think it is Firefox 
itself but maybe something it loads or accesses.  Thing is, as I went up 
versions, it pulled in different versions of xulrunner and such that 
Firefox depends on.  I doubt that many versions can all have the same 
problem and it only affect me.  Just sort of sounds odd.

As for running as root, I meant as a test not a permanent thing.  If I 
did open it as root, I would have my router turned off, just to be safe.

This is weird as heck.  A program leading a kernel panic.  It's a head 
scratcher.

Dale

:-)  :-)

Re: [gentoo-user] Re: Firefox and kernel panics.

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 305 bytes --]

On Sat, 09 Jul 2011 04:03:47 -0500, Dale wrote:

> This is weird as heck.  A program leading a kernel panic.  It's a head 
> scratcher.

Do you have CONFIG_BOOTPARAM_HUNG_TASK_PANIC set in your kernel?


-- 
Neil Bothwick

An atheist is someone who feels he has no invisible means of support.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-user] Re: Firefox and kernel panics.

[Dale]

Neil Bothwick wrote:
> On Sat, 09 Jul 2011 04:03:47 -0500, Dale wrote:
>
>    
>> This is weird as heck.  A program leading a kernel panic.  It's a head
>> scratcher.
>>      
> Do you have CONFIG_BOOTPARAM_HUNG_TASK_PANIC set in your kernel?
>
>
>    

I had to search for this one.

│ Symbol: BOOTPARAM_HUNG_TASK_PANIC [=n] │
│ Type : boolean │
│ Prompt: Panic (Reboot) On Hung Tasks │
│ Defined at lib/Kconfig.debug:241 │
│ Depends on: DETECT_HUNG_TASK [=n] │
│ Location: │
│ -> Kernel hacking │
│ -> Detect Hung Tasks (DETECT_HUNG_TASK [=n]) │
│ │
│ │
│ Symbol: BOOTPARAM_HARDLOCKUP_PANIC [=n] │
│ Type : boolean │
│ Prompt: Panic (Reboot) On Hard Lockups │
│ Defined at lib/Kconfig.debug:185 │
│ Depends on: LOCKUP_DETECTOR [=n] │
│ Location: │
│ -> Kernel hacking │
│

Looks like no. Should it be enabled? How does this let some friend of 
Firefox cause a crash like this?

Dale

:-) :-)

Re: [gentoo-user] Re: Firefox and kernel panics.

[András Csányi]

On 9 July 2011 03:49, Dale <rdalek1967@gmail.com> wrote:
> OK.  Back to the original thread.
>
> Here we go again.  Everything seems to work EXCEPT Firefox.  When I log into
> KDE, I can run Seamonkey, Kpat, Konqueror, Konsole, gkrellm and such but as
> soon as I start Firefox, it locks up tight.  Tight enough that the kernel
> panics and it resets since Neil informed me how to set that up.  Thanks
> Neil!
>
> On Firefox, I have unmerged both nspluginwrapper & adobe-flash.  Still does
> the same.  I also tried the unstable version of Firefox 3 and even the
> unstable Firefox 4.  I don't think it is Firefox itself but something that
> Firefox accesses or loads up.  Keep in mind, when I upgraded Firefox it also
> pulled in new xulrunner packages as well.  Is there anything else I should
> unmerge?  Keep in mind, I can't open Firefox.  Should I try to run Firefox
> as root to see if it locks up then too?
>
> So, what in the world is it that Firefox does that can cause a kernel panic?
>  Also, I can surf with both Seamonkey and Konqueror and everything works
> just fine.  It seems only Firefox, any version, is affected by this.
>
> Now what?  I use Firefox to go to youtube and stuff to get music videos.  It
> just does better than Seamonkey for me.
>
> Dale
>
> :-)  :-)

I had a similar problem but regarding Chromium. You can read about in
this list "Chromium and everything" subject. May I ask which kernel do
you use?



-- 
- -
--  Csanyi Andras (Sayusi Ando)  -- http://sayusi.hu --
http://facebook.com/andras.csanyi
--  ""Trust in God and keep your gunpowder dry!" - Cromwell

Re: [gentoo-user] Re: Firefox and kernel panics.

[Dale]

András Csányi wrote:
>
> I had a similar problem but regarding Chromium. You can read about in
> this list "Chromium and everything" subject. May I ask which kernel do
> you use?
>
>    

I remember the thread, even replied a couple times, but this is even 
worse and happens when flash is not even installed.  I unmerged flash 
and it still crashes.  Actually, mine is a kernel panic more than a 
crash.  My system generally locks up tight even when no web page is 
loading.  Just opening Firefox causes the lock up.

Right now, I'm on 2.6.39-r2.  At least this version works better than 
the last .39 I tried.

Dale

:-)  :-)

Re: [gentoo-user] Re: Firefox and kernel panics.

[Mark Knecht]

On Sat, Jul 9, 2011 at 9:18 AM, Dale <rdalek1967@gmail.com> wrote:
> András Csányi wrote:
>>
>> I had a similar problem but regarding Chromium. You can read about in
>> this list "Chromium and everything" subject. May I ask which kernel do
>> you use?
>>
>>
>
> I remember the thread, even replied a couple times, but this is even worse
> and happens when flash is not even installed.  I unmerged flash and it still
> crashes.  Actually, mine is a kernel panic more than a crash.  My system
> generally locks up tight even when no web page is loading.  Just opening
> Firefox causes the lock up.
>
> Right now, I'm on 2.6.39-r2.  At least this version works better than the
> last .39 I tried.
>
> Dale

Exercise all the ideas you are receiving here first, but in my
experience kernel panics are something the LKML folks take pretty
seriously. If nothing else works consider starting a thread there
documenting what you are seeing and asking for inputs. You don't need
to subscribe to the LKML to make the post, but if you do post there
and want to see responses then state clearly that you are not a list
member and ask people to copy you directly on any responses.

Cheers,
Mark

Re: [gentoo-user] Re: Firefox and kernel panics.

[Michael Orlitzky]

On 07/09/11 12:18, Dale wrote:
> András Csányi wrote:
>>
>> I had a similar problem but regarding Chromium. You can read about in
>> this list "Chromium and everything" subject. May I ask which kernel do
>> you use?
>>
>>    
> 
> I remember the thread, even replied a couple times, but this is even
> worse and happens when flash is not even installed.  I unmerged flash
> and it still crashes.  Actually, mine is a kernel panic more than a
> crash.  My system generally locks up tight even when no web page is
> loading.  Just opening Firefox causes the lock up.
> 
> Right now, I'm on 2.6.39-r2.  At least this version works better than
> the last .39 I tried.
> 

Apologies for having deleted most of the thread before I started paying
attention, but did you already run memtest? I had a panic that would
only occur when I was burning DVDs; in reality, I just never used all of
my RAM otherwise and some rarely-touched chunk of it was bad.

Re: [gentoo-user] Re: Firefox and kernel panics.

[Dale]

Michael Orlitzky wrote:
> On 07/09/11 12:18, Dale wrote:
>    
>> András Csányi wrote:
>>      
>>> I had a similar problem but regarding Chromium. You can read about in
>>> this list "Chromium and everything" subject. May I ask which kernel do
>>> you use?
>>>
>>>
>>>        
>> I remember the thread, even replied a couple times, but this is even
>> worse and happens when flash is not even installed.  I unmerged flash
>> and it still crashes.  Actually, mine is a kernel panic more than a
>> crash.  My system generally locks up tight even when no web page is
>> loading.  Just opening Firefox causes the lock up.
>>
>> Right now, I'm on 2.6.39-r2.  At least this version works better than
>> the last .39 I tried.
>>
>>      
> Apologies for having deleted most of the thread before I started paying
> attention, but did you already run memtest? I had a panic that would
> only occur when I was burning DVDs; in reality, I just never used all of
> my RAM otherwise and some rarely-touched chunk of it was bad.
>
>
>    

No worries.  Sometimes when you back up a bit, you may realize you 
missed something.  I did run memtest and it bad about 45 passes I think 
with no errors.  That takes a while when you have 16Gbs.  o_O

Dale

:-)  :-)

Re: [gentoo-user] Re: Firefox and kernel panics.

[Michael Orlitzky]

On 07/09/11 16:56, Dale wrote:
> 
> No worries.  Sometimes when you back up a bit, you may realize you
> missed something.  I did run memtest and it bad about 45 passes I think
> with no errors.  That takes a while when you have 16Gbs.  o_O

Ah, ok. I'd also try a hard drive scan to make sure firefox's stuff
isn't sitting on bad sectors.

Applications shouldn't be able to cause a kernel panic, period. So if it
isn't hardware, it's a kernel bug by definition.

Re: [gentoo-user] Re: Firefox and kernel panics.

[Dale]

Michael Orlitzky wrote:
> On 07/09/11 16:56, Dale wrote:
>    
>> No worries.  Sometimes when you back up a bit, you may realize you
>> missed something.  I did run memtest and it bad about 45 passes I think
>> with no errors.  That takes a while when you have 16Gbs.  o_O
>>      
> Ah, ok. I'd also try a hard drive scan to make sure firefox's stuff
> isn't sitting on bad sectors.
>
> Applications shouldn't be able to cause a kernel panic, period. So if it
> isn't hardware, it's a kernel bug by definition.
>
>    

I'm going to try having a fresh .mozilla directory as soon as I can.  
I'm sort of enjoying having KDE right now.  ;-)

I don't think it is the hard drive.  I did a fresh install on a spare 
drive with the same results.  so, I'm beginning to think it is a kernel 
bug but the thing is, I have tried several versions of that too.

Basically, this is plain confusing.  I can't see how Firefox, or 
something it has to access, can cause a kernel panic.  Thing is, I can't 
think of anything else that could be the problem but trying different 
versions of a kernel makes me think it is not the kernel either.

< sighs >

Dale

:-)  :-)

Re: [gentoo-user] Re: Firefox and kernel panics.

[Mark Knecht]

On Sat, Jul 9, 2011 at 3:26 PM, Dale <rdalek1967@gmail.com> wrote:
> Michael Orlitzky wrote:
>>
>> On 07/09/11 16:56, Dale wrote:
>>
>>>
>>> No worries.  Sometimes when you back up a bit, you may realize you
>>> missed something.  I did run memtest and it bad about 45 passes I think
>>> with no errors.  That takes a while when you have 16Gbs.  o_O
>>>
>>
>> Ah, ok. I'd also try a hard drive scan to make sure firefox's stuff
>> isn't sitting on bad sectors.
>>
>> Applications shouldn't be able to cause a kernel panic, period. So if it
>> isn't hardware, it's a kernel bug by definition.
>>
>>
>
> I'm going to try having a fresh .mozilla directory as soon as I can.  I'm
> sort of enjoying having KDE right now.  ;-)
>
> I don't think it is the hard drive.  I did a fresh install on a spare drive
> with the same results.  so, I'm beginning to think it is a kernel bug but
> the thing is, I have tried several versions of that too.
>
> Basically, this is plain confusing.  I can't see how Firefox, or something
> it has to access, can cause a kernel panic.  Thing is, I can't think of
> anything else that could be the problem but trying different versions of a
> kernel makes me think it is not the kernel either.
>
> < sighs >
>
> Dale

And this is exactly why you should consider posting any information
your can find on LKML to let the heavy weight guys figure it out. As I
said earlier, I believe they will take you quite seriously. In general
I would also say that Firefox should be able to cause a kernel panic,
and since it is I know the kernel developers are going to be
interested in what's the root cause.

I don't remember from earlier why you said it was a kernel panic, but
clearly it must be. How are you determining this? Do you have info in
a terminal? For a few problems I've had I've posted digital photos
I've taken and uploaded to FlickR. You might consider doing something
similar.

Cheers,
Mark

Re: [gentoo-user] Re: Firefox and kernel panics.

[Dale]

Mark Knecht wrote:
>
> And this is exactly why you should consider posting any information
> your can find on LKML to let the heavy weight guys figure it out. As I
> said earlier, I believe they will take you quite seriously. In general
> I would also say that Firefox should be able to cause a kernel panic,
> and since it is I know the kernel developers are going to be
> interested in what's the root cause.
>
> I don't remember from earlier why you said it was a kernel panic, but
> clearly it must be. How are you determining this? Do you have info in
> a terminal? For a few problems I've had I've posted digital photos
> I've taken and uploaded to FlickR. You might consider doing something
> similar.
>
> Cheers,
> Mark
>
>
>    

The reason I said kernel panic is because someone else posted that when 
the keyboard lights blink, that is a kernel panic.  Sure enough, when 
Neil told me how to set it up so that it would automatically reboot when 
the kernel panics, it does just that.  I have no reason to think it is 
anything other than a kernel panic based on nothing but the kernel doing 
the reboot and the lights blinking.

I would like to report this but I wouldn't even know where to start.  If 
I had a lot more knowledge on how to help track it down, then that would 
be different.  I'm not sure I can help much other than telling them 
Firefox causes a kernel panic but I have no clue how or why.

Then again, if one of the dev would hold my hand a little, I could copy 
a install over to my spare drive and then not have to worry about 
messing up my main install.  Fluxbox is OK but I like my KDE better.  ;-)

My old rig was in the middle of a update and we just had a nasty little 
thunderstorm here.  It was OOo of course.  It was 7 hours into a 9 hour 
compile when the lights blinked.  My old rig isn't on a UPS anymore.  
Neat huh?  I'm glad for the rain tho.  My garden needs it really really 
bad.

Dale

:-)  :-)

Re: [gentoo-user] Re: Firefox and kernel panics.

[Mark Knecht]

On Sat, Jul 9, 2011 at 4:55 PM, Dale <rdalek1967@gmail.com> wrote:
> Mark Knecht wrote:
>>
>> And this is exactly why you should consider posting any information
>> your can find on LKML to let the heavy weight guys figure it out. As I
>> said earlier, I believe they will take you quite seriously. In general
>> I would also say that Firefox should be able to cause a kernel panic,
>> and since it is I know the kernel developers are going to be
>> interested in what's the root cause.
>>
>> I don't remember from earlier why you said it was a kernel panic, but
>> clearly it must be. How are you determining this? Do you have info in
>> a terminal? For a few problems I've had I've posted digital photos
>> I've taken and uploaded to FlickR. You might consider doing something
>> similar.
>>
>> Cheers,
>> Mark
>>
>>
>>
>
> The reason I said kernel panic is because someone else posted that when the
> keyboard lights blink, that is a kernel panic.  Sure enough, when Neil told
> me how to set it up so that it would automatically reboot when the kernel
> panics, it does just that.  I have no reason to think it is anything other
> than a kernel panic based on nothing but the kernel doing the reboot and the
> lights blinking.
>
> I would like to report this but I wouldn't even know where to start.  If I
> had a lot more knowledge on how to help track it down, then that would be
> different.  I'm not sure I can help much other than telling them Firefox
> causes a kernel panic but I have no clue how or why.
>
> Then again, if one of the dev would hold my hand a little, I could copy a
> install over to my spare drive and then not have to worry about messing up
> my main install.  Fluxbox is OK but I like my KDE better.  ;-)
>
> My old rig was in the middle of a update and we just had a nasty little
> thunderstorm here.  It was OOo of course.  It was 7 hours into a 9 hour
> compile when the lights blinked.  My old rig isn't on a UPS anymore.  Neat
> huh?  I'm glad for the rain tho.  My garden needs it really really bad.
>
> Dale

Yeah, if you can't report good clear info then it's just a waste of
everyone's time. No need to do that.

Not sure if it would work or even apply but there are some kernel
features, mostly I think used around boot time, that send kernel info
over either a serial port or more recently an Ethernet link to another
computer which then stays alove and captures whatever data gets
transmitted. If you were interested in learning about that (I am but
haven't had time. I used it years ago to give some LKML guys info they
needed to get an ATI chipset to work better) then we might be able to
dig into that off line.

On the other hand, if you're machine is working then it ain't broke, right? ;-)

Cheers,
Mark

Re: [gentoo-user] Re: Firefox and kernel panics.

[Dale]

Mark Knecht wrote:
> On Sat, Jul 9, 2011 at 4:55 PM, Dale<rdalek1967@gmail.com>  wrote:
>    
>> Mark Knecht wrote:
>>      
>>> And this is exactly why you should consider posting any information
>>> your can find on LKML to let the heavy weight guys figure it out. As I
>>> said earlier, I believe they will take you quite seriously. In general
>>> I would also say that Firefox should be able to cause a kernel panic,
>>> and since it is I know the kernel developers are going to be
>>> interested in what's the root cause.
>>>
>>> I don't remember from earlier why you said it was a kernel panic, but
>>> clearly it must be. How are you determining this? Do you have info in
>>> a terminal? For a few problems I've had I've posted digital photos
>>> I've taken and uploaded to FlickR. You might consider doing something
>>> similar.
>>>
>>> Cheers,
>>> Mark
>>>
>>>
>>>
>>>        
>> The reason I said kernel panic is because someone else posted that when the
>> keyboard lights blink, that is a kernel panic.  Sure enough, when Neil told
>> me how to set it up so that it would automatically reboot when the kernel
>> panics, it does just that.  I have no reason to think it is anything other
>> than a kernel panic based on nothing but the kernel doing the reboot and the
>> lights blinking.
>>
>> I would like to report this but I wouldn't even know where to start.  If I
>> had a lot more knowledge on how to help track it down, then that would be
>> different.  I'm not sure I can help much other than telling them Firefox
>> causes a kernel panic but I have no clue how or why.
>>
>> Then again, if one of the dev would hold my hand a little, I could copy a
>> install over to my spare drive and then not have to worry about messing up
>> my main install.  Fluxbox is OK but I like my KDE better.  ;-)
>>
>> My old rig was in the middle of a update and we just had a nasty little
>> thunderstorm here.  It was OOo of course.  It was 7 hours into a 9 hour
>> compile when the lights blinked.  My old rig isn't on a UPS anymore.  Neat
>> huh?  I'm glad for the rain tho.  My garden needs it really really bad.
>>
>> Dale
>>      
> Yeah, if you can't report good clear info then it's just a waste of
> everyone's time. No need to do that.
>
> Not sure if it would work or even apply but there are some kernel
> features, mostly I think used around boot time, that send kernel info
> over either a serial port or more recently an Ethernet link to another
> computer which then stays alove and captures whatever data gets
> transmitted. If you were interested in learning about that (I am but
> haven't had time. I used it years ago to give some LKML guys info they
> needed to get an ATI chipset to work better) then we might be able to
> dig into that off line.
>
> On the other hand, if you're machine is working then it ain't broke, right? ;-)
>
> Cheers,
> Mark
>
>
>    

It works as long as I don't open Firefox.  If I open Firefox, poof!!  No 
more trapped smoke.  lol

Dale

:-)  :-)

Re: [gentoo-user] Re: Firefox and kernel panics.

[Mark Knecht]

On Sat, Jul 9, 2011 at 6:36 PM, Dale <rdalek1967@gmail.com> wrote:
<SNIP>
>
> It works as long as I don't open Firefox.  If I open Firefox, poof!!  No
> more trapped smoke.  lol
>
> Dale

So I had suggested running it in gdb and someone else suggested
running it in strace. Did you have a chance to try either of those?

Not sure how much info you'll get from either but might be worth a try.

- Mark

Re: [gentoo-user] Re: Firefox and kernel panics.

[Dale]

Mark Knecht wrote:
> On Sat, Jul 9, 2011 at 6:36 PM, Dale<rdalek1967@gmail.com>  wrote:
> <SNIP>
>    
>> It works as long as I don't open Firefox.  If I open Firefox, poof!!  No
>> more trapped smoke.  lol
>>
>> Dale
>>      
> So I had suggested running it in gdb and someone else suggested
> running it in strace. Did you have a chance to try either of those?
>
> Not sure how much info you'll get from either but might be worth a try.
>
> - Mark
>
>
>    

I don't know what gdb is.  If my machine locks up, I won't be able to 
see what strace does.  I'm not sure that will help.

Dale

:-)  :-)

Re: [gentoo-user] Re: Firefox and kernel panics.

[Joshua Murphy]

On Sat, Jul 9, 2011 at 11:31 PM, Dale <rdalek1967@gmail.com> wrote:
> Mark Knecht wrote:
>>
>> On Sat, Jul 9, 2011 at 6:36 PM, Dale<rdalek1967@gmail.com>  wrote:
>> <SNIP>
>>
>>>
>>> It works as long as I don't open Firefox.  If I open Firefox, poof!!  No
>>> more trapped smoke.  lol
>>>
>>> Dale
>>>
>>
>> So I had suggested running it in gdb and someone else suggested
>> running it in strace. Did you have a chance to try either of those?
>>
>> Not sure how much info you'll get from either but might be worth a try.
>>
>> - Mark
>>
>>
>>
>
> I don't know what gdb is.  If my machine locks up, I won't be able to see
> what strace does.  I'm not sure that will help.
>
> Dale
>
> :-)  :-)
>
>

gdb is the GNU Debugger. As for the usability of strace in your case,
if you can see the last few calls before the lock-up occurs, it could
help narrow things down a bit. Also, if you SSH into the machine and
run firefox through strace via that (drawing to the machine's local
screen, not the SSH client's), you will have anything it can give in a
workable form, even after the system hangs. You might also test
whether it crashes while running Firefox via SSH and drawing to a
different machine, which (if it does) would allow you to sit on a real
terminal on the main system and see the kernel's output in the instant
of the crash or (if it doesn't) would narrow it down to X being a key
factor.

-- 
Poison [BLX]
Joshua M. Murphy

Re: [gentoo-user] Re: Firefox and kernel panics.

[Dale]

Joshua Murphy wrote:
> On Sat, Jul 9, 2011 at 11:31 PM, Dale<rdalek1967@gmail.com>  wrote:
>    
>> Mark Knecht wrote:
>>      
>>> On Sat, Jul 9, 2011 at 6:36 PM, Dale<rdalek1967@gmail.com>    wrote:
>>> <SNIP>
>>>
>>>        
>>>> It works as long as I don't open Firefox.  If I open Firefox, poof!!  No
>>>> more trapped smoke.  lol
>>>>
>>>> Dale
>>>>
>>>>          
>>> So I had suggested running it in gdb and someone else suggested
>>> running it in strace. Did you have a chance to try either of those?
>>>
>>> Not sure how much info you'll get from either but might be worth a try.
>>>
>>> - Mark
>>>
>>>
>>>
>>>        
>> I don't know what gdb is.  If my machine locks up, I won't be able to see
>> what strace does.  I'm not sure that will help.
>>
>> Dale
>>
>> :-)  :-)
>>
>>
>>      
> gdb is the GNU Debugger. As for the usability of strace in your case,
> if you can see the last few calls before the lock-up occurs, it could
> help narrow things down a bit. Also, if you SSH into the machine and
> run firefox through strace via that (drawing to the machine's local
> screen, not the SSH client's), you will have anything it can give in a
> workable form, even after the system hangs. You might also test
> whether it crashes while running Firefox via SSH and drawing to a
> different machine, which (if it does) would allow you to sit on a real
> terminal on the main system and see the kernel's output in the instant
> of the crash or (if it doesn't) would narrow it down to X being a key
> factor.
>
>    

I'm like Peanut on the Jeff Dunham comedy skit.  Take your hand and go 
over your head and say whoooosh.  I better wait on a fix because I may 
break more than I learn.  O_O

LOL

Dale

:-)  :-)

Re: [gentoo-user] Re: Firefox and kernel panics.

[Willie Wong]

On Sun, Jul 10, 2011 at 01:46:08AM -0500, Dale wrote:
> Joshua Murphy wrote:

> >gdb is the GNU Debugger. As for the usability of strace in your case,
> >if you can see the last few calls before the lock-up occurs, it could
> >help narrow things down a bit. Also, if you SSH into the machine and
> >run firefox through strace via that (drawing to the machine's local
> >screen, not the SSH client's), you will have anything it can give in a
> >workable form, even after the system hangs. You might also test
> >whether it crashes while running Firefox via SSH and drawing to a
> >different machine, which (if it does) would allow you to sit on a real
> >terminal on the main system and see the kernel's output in the instant
> >of the crash or (if it doesn't) would narrow it down to X being a key
> >factor.
> >
> 
> I'm like Peanut on the Jeff Dunham comedy skit.  Take your hand and
> go over your head and say whoooosh.  I better wait on a fix because
> I may break more than I learn.  O_O
> 

I second what Joshua says. It can help narrow down the cause. 

One question: when Firefox causes the panic, does the Firefox window
appear, or does it not? If not, then it would cover up the terminal
emulator your are running `strace firefox` from, so you can still copy
down the few lines of output. 

What Joshua is suggesting is to give your machine another way to show
its outputs. So take another box (a laptop or a desktop on your LAN)
and SSH into your problem box.

 (1) Starting Firefox from the remote box. 
    i. On your problem box, open up console and issue `xhost +` (eh...
you probably want to be behind a firewall when you do this)
    ii. ssh from your other box to the problem box
    iii. issue now, in the ssh terminal `export DISPLAY=:0`
    iv. issue `strace firefox`
  This should let you start firefox on your problem box while having
the strace output sent to your other box. Maybe you'd be able to see
something there. 

 (2) Starting Firefox remotely. There are two versions of this. 
    (a) Run firefox on problem box.
     i. ssh from your other box to the problem box, with the `-Y`
option set to allow X forwarding
     ii. run `firefox` from the SSH console (this should run firefox
on the problem box and have it draw the display on your other box; if
this doesn't cause your problem box to lock up, it should tell us
something. What exactly I am not sure)
    (b) Run firefox on other box.
     i. ssh from your problem box to the other box, again with the
`-Y` option to allow X forwarding
     ii. run `firefox` from the SSH console (if this doesn't crash,
then it is likely something funny with your local firefox; if it does
crash, then something real strange is going on)

Can you report on those experiments?

Good luck, 

W
-- 
Willie W. Wong                                     wwong@math.princeton.edu
Data aequatione quotcunque fluentes quantitae involvente fluxiones invenire 
         et vice versa   ~~~  I. Newton

Re: [gentoo-user] Re: Firefox and kernel panics.

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 586 bytes --]

On Sat, 09 Jul 2011 18:55:01 -0500, Dale wrote:

> My old rig was in the middle of a update and we just had a nasty little 
> thunderstorm here.  It was OOo of course.  It was 7 hours into a 9 hour 
> compile when the lights blinked.

It won't have reached the install stage, so the only filesystem being
written to would have been the one holding $PORTAGE_TMPDIR. It would be
advisable to restart the emerge though :)


-- 
Neil Bothwick

Procedure: (n.) a method of performing a program sub-task in an
inefficient way by extensively using the stack instead of a GOTO.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-user] Re: Firefox and kernel panics.

[Dale]

Neil Bothwick wrote:
> On Sat, 09 Jul 2011 18:55:01 -0500, Dale wrote:
>
>    
>> My old rig was in the middle of a update and we just had a nasty little
>> thunderstorm here.  It was OOo of course.  It was 7 hours into a 9 hour
>> compile when the lights blinked.
>>      
> It won't have reached the install stage, so the only filesystem being
> written to would have been the one holding $PORTAGE_TMPDIR. It would be
> advisable to restart the emerge though :)
>
>
>    

I know it didn't hurt anything as for as the system goes.  My deal was 
the lost compile time.  If I had started it about 3 hours earlier or the 
lights would have blinked a few hours later then not so much would have 
been lost.  I guess we can all dream tho.

Still haven't got the nerve up to open Firefox again.  Maybe soon.

Dale

:-)  :-)

[gentoo-user] Re: Firefox and kernel panics.

[walt]

On 07/10/2011 12:40 PM, Dale wrote:
> Neil Bothwick wrote:
>> On Sat, 09 Jul 2011 18:55:01 -0500, Dale wrote:
>> 
>> 
>>> My old rig was in the middle of a update and we just had a nasty
>>> little thunderstorm here.  It was OOo of course.  It was 7 hours
>>> into a 9 hour compile when the lights blinked.
>>> 
>> It won't have reached the install stage, so the only filesystem
>> being written to would have been the one holding $PORTAGE_TMPDIR.
>> It would be advisable to restart the emerge though :)
>> 
>> 
>> 
> 
> My deal was the lost compile time.  If I had started it about 3 hours
> earlier or the lights would have blinked a few hours later then not
> so much would have been lost.

That's when I use ebuild instead of starting the emerge from scratch.
Let's say I'm emerging libreoffice and the machine goes down (shudder).

After fixing the problem I would try the following:
#cd /usr/portage/app-office/libreoffice/
#ebuild ./libreoffice-3.3.3.ebuild install

That should pick up where the previous emerge stopped, although the
patches may be reapplied before continuing the compile/install phase.

But, hold on.  The "install" phase does only a temporary install in
the portage build directory, not the 'real' install in /usr.

That final step is very easy, though:

#ebuild ./libreoffice-3.3.3.ebuild qmerge

For more detail see man ebuild and search on 'qmerge'.  Pretty nifty
for situations like yours.  Never hurts to use fsck beforehand. even
if the journal was "recovered" during your first reboot after the
disaster.

Re: [gentoo-user] Re: Firefox and kernel panics.

[Dale]

walt wrote:
> On 07/10/2011 12:40 PM, Dale wrote:
>    
>> Neil Bothwick wrote:
>>      
>>> On Sat, 09 Jul 2011 18:55:01 -0500, Dale wrote:
>>>
>>>
>>>        
>>>> My old rig was in the middle of a update and we just had a nasty
>>>> little thunderstorm here.  It was OOo of course.  It was 7 hours
>>>> into a 9 hour compile when the lights blinked.
>>>>
>>>>          
>>> It won't have reached the install stage, so the only filesystem
>>> being written to would have been the one holding $PORTAGE_TMPDIR.
>>> It would be advisable to restart the emerge though :)
>>>
>>>
>>>
>>>        
>> My deal was the lost compile time.  If I had started it about 3 hours
>> earlier or the lights would have blinked a few hours later then not
>> so much would have been lost.
>>      
> That's when I use ebuild instead of starting the emerge from scratch.
> Let's say I'm emerging libreoffice and the machine goes down (shudder).
>
> After fixing the problem I would try the following:
> #cd /usr/portage/app-office/libreoffice/
> #ebuild ./libreoffice-3.3.3.ebuild install
>
> That should pick up where the previous emerge stopped, although the
> patches may be reapplied before continuing the compile/install phase.
>
> But, hold on.  The "install" phase does only a temporary install in
> the portage build directory, not the 'real' install in /usr.
>
> That final step is very easy, though:
>
> #ebuild ./libreoffice-3.3.3.ebuild qmerge
>
> For more detail see man ebuild and search on 'qmerge'.  Pretty nifty
> for situations like yours.  Never hurts to use fsck beforehand. even
> if the journal was "recovered" during your first reboot after the
> disaster.
>
>
>
>    


I just had to do some of that with KDE.  Some things were still buggy in 
the tree.  It may work but I won't be needing the machine while it 
compiles anyway.  It's my spare rig.  I learned not to let it go to long 
between updates tho.  Funny thing is, I was still trying to dodge storms 
and update the last KDE.  It wasn't even finished with it yet and there 
is a new release of KDE.

I always boot, let it clean up a little then reboot again.  If no errors 
are found, I'm good to go.  I've gotten pretty good at cleaning up after 
a power fail or hard reset.  Sort of had some experience here lately.  :-(

Thanks.

Dale

:-)  :-)

Re: [gentoo-user] Re: Firefox and kernel panics.

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 1083 bytes --]

On Sun, 10 Jul 2011 16:10:15 -0700, walt wrote:

> > My deal was the lost compile time.  If I had started it about 3 hours
> > earlier or the lights would have blinked a few hours later then not
> > so much would have been lost.  
> 
> That's when I use ebuild instead of starting the emerge from scratch.
> Let's say I'm emerging libreoffice and the machine goes down (shudder).
> 
> After fixing the problem I would try the following:
> #cd /usr/portage/app-office/libreoffice/
> #ebuild ./libreoffice-3.3.3.ebuild install
> 
> That should pick up where the previous emerge stopped, although the
> patches may be reapplied before continuing the compile/install phase.

It will also mean that any files corrupted by the unclean shutdown will be
used by the compile/install. This may mean it falls over later or it may
install broken software. In this case, restarting from scratch is the
safer option, it's not like it is using 6 hours of your time, only the
computers. Fixing problems is what uses your time.


-- 
Neil Bothwick

There's no place like ~

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-user] Re: Firefox and kernel panics.

[Alex Schuster]

walt writes:

[interrupted emerges]

> That's when I use ebuild instead of starting the emerge from scratch.
> Let's say I'm emerging libreoffice and the machine goes down (shudder).
> 
> After fixing the problem I would try the following:
> #cd /usr/portage/app-office/libreoffice/
> #ebuild ./libreoffice-3.3.3.ebuild install
> 
> That should pick up where the previous emerge stopped, although the
> patches may be reapplied before continuing the compile/install phase.
> 
> But, hold on.  The "install" phase does only a temporary install in
> the portage build directory, not the 'real' install in /usr.
> 
> That final step is very easy, though:
> 
> #ebuild ./libreoffice-3.3.3.ebuild qmerge

I like to do this, too. But I use
    FEATURES=keepwork emerge libreoffice
in cases where an emerge was aborted.

Although Neil may have a point when he says that an unclean shutdown could 
have corrupted things. I was under the impression that with a journaling 
file system this should be safe, but I do not know much bout this.

Remember to remove the $PORTAGE_TMPDIR/portage/<category>/<package> 
directory afterwards, with FEATURES=keepwork stuff there is neither removed 
before nor after emerging.

	Wonko

Re: [gentoo-user] Re: Firefox and kernel panics.

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 588 bytes --]

On Mon, 11 Jul 2011 18:42:06 +0200, Alex Schuster wrote:

> Although Neil may have a point when he says that an unclean shutdown
> could have corrupted things. I was under the impression that with a
> journaling file system this should be safe, but I do not know much bout
> this.

Journalling normally only protects the filesystem metadata, file contents
can be affected. Look at that lovely XFS bug of old that filled files
with zeros on a power outage, wile keeping the filesystem intact :(


-- 
Neil Bothwick

Vuja De: the feeling that you've never been here before.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

[gentoo-user] Re: Firefox and kernel panics.

[walt]

On 07/11/2011 09:42 AM, Alex Schuster wrote:

> Although Neil may have a point when he says that an unclean shutdown could 
> have corrupted things. I was under the impression that with a journaling 
> file system this should be safe, but I do not know much bout this.

I agree with Neil so (if I'm awake enough) I'll force an fsck by doing:

#touch /forcefsck in the root directory of any filesystem you might
be worried about, and then reboot.

Do this before resuming any emerge, of course, so you don't screw up
the fs any more than it already is.  (BTW I still use only ext3, so I
can't say anything about reiser, ext4, etc.)

Re: [gentoo-user] Re: Firefox and kernel panics.

[Dale]

walt wrote:
> On 07/11/2011 09:42 AM, Alex Schuster wrote:
>
>    
>> Although Neil may have a point when he says that an unclean shutdown could
>> have corrupted things. I was under the impression that with a journaling
>> file system this should be safe, but I do not know much bout this.
>>      
> I agree with Neil so (if I'm awake enough) I'll force an fsck by doing:
>
> #touch /forcefsck in the root directory of any filesystem you might
> be worried about, and then reboot.
>
> Do this before resuming any emerge, of course, so you don't screw up
> the fs any more than it already is.  (BTW I still use only ext3, so I
> can't say anything about reiser, ext4, etc.)
>
>
>    

I think the point of the journal is not to preserve the files but the 
file system.  There is a huge difference.  The journal may fix the file 
system but a corrupt file will still be a corrupt file.

The only thing worse than loosing a few hours of compiling, resuming a 
compile only to find out you have to start over anyway.

Just saying.  ;-)

Dale

:-)  :-)

Re: [gentoo-user] Re: Firefox and kernel panics.

[pk]

On 2011-07-10 00:26, Dale wrote:

> Basically, this is plain confusing.  I can't see how Firefox, or
> something it has to access, can cause a kernel panic.  Thing is, I can't
> think of anything else that could be the problem but trying different
> versions of a kernel makes me think it is not the kernel either.

My apologies for not paying attention to this thread but have you
considered this being a graphics driver problem? I would suggest trying
a different driver version first... It may also be  driver/kernel
mismatch thing (i.e. if it's a proprietary driver which have been
written & tested for specific versions of the kernel and you're running
one which is not one of those).

Best regards

Peter K

Re: [gentoo-user] Re: Firefox and kernel panics.

[Dale]

pk wrote:
> On 2011-07-10 00:26, Dale wrote:
>
>    
>> Basically, this is plain confusing.  I can't see how Firefox, or
>> something it has to access, can cause a kernel panic.  Thing is, I can't
>> think of anything else that could be the problem but trying different
>> versions of a kernel makes me think it is not the kernel either.
>>      
> My apologies for not paying attention to this thread but have you
> considered this being a graphics driver problem? I would suggest trying
> a different driver version first... It may also be  driver/kernel
> mismatch thing (i.e. if it's a proprietary driver which have been
> written&  tested for specific versions of the kernel and you're running
> one which is not one of those).
>
> Best regards
>
> Peter K
>
>
>    

Yea, done tried that.  I tried different kernels, different nvidia 
drivers and all with no change.

At least I got a .39 kernel that works now tho.  My previous .39 kernel 
had some sort of a bug in it.  Dang I can't remember what it did tho.  I 
need to start taking notes on this stuff.  I'm getting to old or to much 
stuff on my plate one.  lol

Dale

:-)  :-)

Re: [gentoo-user] Re: Firefox and kernel panics.

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 348 bytes --]

On Sun, 10 Jul 2011 14:42:50 -0500, Dale wrote:

> Yea, done tried that.  I tried different kernels, different nvidia 
> drivers and all with no change.

WAG - have you tried the nv drivers?


-- 
Neil Bothwick

The human mind ordinarily operates at only ten per cent of its
capacity ... the rest is overhead for the operating system.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-user] Re: Firefox and kernel panics.

[Dale]

Neil Bothwick wrote:
> On Sun, 10 Jul 2011 14:42:50 -0500, Dale wrote:
>
>    
>> Yea, done tried that.  I tried different kernels, different nvidia
>> drivers and all with no change.
>>      
> WAG - have you tried the nv drivers?
>
>
>    

I did but I couldn't get X to even start.  I guess something is not set 
right somewhere.  I have nv in make.conf and been there since I built 
this thing so sort of clueless on why it don't work.

Maybe it's because I don't use the latest greatest cards but I don't 
think I have ever really had trouble with nvidia drivers.  Surely it 
can't be good luck.  ;-)

While I am at it, what is the syntax to mask a package higher than a 
certain version in package.mask?  I tired =>package.name.version and 
tried >= package.name.version but the former doesn't work and seems to 
ignore it and the later makes emerge print a boo boo message.  On my old 
rig, I want to mask anything above the 173 series.   So far, I haven't 
had the light bulb moment and never can remember how to do this.

Thanks.

Dale

:-)  :-)

Re: [gentoo-user] Re: Firefox and kernel panics.

[Mark Knecht]

On Sun, Jul 10, 2011 at 5:27 PM, Dale <rdalek1967@gmail.com> wrote:
> Neil Bothwick wrote:
>>
>> On Sun, 10 Jul 2011 14:42:50 -0500, Dale wrote:
>>
>>
>>>
>>> Yea, done tried that.  I tried different kernels, different nvidia
>>> drivers and all with no change.
>>>
>>
>> WAG - have you tried the nv drivers?
>>
>>
>>
>
> I did but I couldn't get X to even start.  I guess something is not set
> right somewhere.  I have nv in make.conf and been there since I built this
> thing so sort of clueless on why it don't work.
>
> Maybe it's because I don't use the latest greatest cards but I don't think I
> have ever really had trouble with nvidia drivers.  Surely it can't be good
> luck.  ;-)
>
> While I am at it, what is the syntax to mask a package higher than a certain
> version in package.mask?  I tired =>package.name.version and tried >=
> package.name.version but the former doesn't work and seems to ignore it and
> the later makes emerge print a boo boo message.  On my old rig, I want to
> mask anything above the 173 series.   So far, I haven't had the light bulb
> moment and never can remember how to do this.
>
> Thanks.
>
> Dale

May I ask exactly what NVidia card you are using and why you are using
(if I understood you correctly) the nv driver and not the nvidia
driver?

This page at NVidia will point you at the right driver. I've got a
little bit of every NVidia technology here and they haven't treated me
wrong yet.

http://www.nvidia.com/Download/index.aspx?lang=en-us

My make.conf files all say

VIDEO_CARDS="nvidia"

and then I typically use the beta driver ala:

mark@slinky ~ $ cat /etc/portage/package.keywords | grep nvidia
x11-drivers/nvidia-drivers ~amd64
dev-util/nvidia-cuda-toolkit ~amd64
dev-util/nvidia-cuda-sdk ~amd64
mark@slinky ~ $

You won't need the CUDAstuff.

It's always the NVidia driver in /etc/X11/xorg.conf, not the older nv driver:

mark@slinky ~ $ cat /etc/X11/xorg.conf | grep nvidia
        Driver      "nvidia"
mark@slinky ~ $

- Mark

Re: [gentoo-user] Re: Firefox and kernel panics.

[Mark Knecht]

DAle,
   PLEASE look at bullet item #3 in this NVidia release:

http://www.nvidia.com/object/linux-display-amd64-275.09.07-driver.html

<QUOTE>

Fixed a bug that caused freezes and crashes when resizing windows in
KDE 4 with desktop effects enabled using X.Org X server version 1.10
or later.
<QUOTE>

Sure sounds familiar to me...

- Mark

On Sun, Jul 10, 2011 at 7:05 PM, Mark Knecht <markknecht@gmail.com> wrote:
> On Sun, Jul 10, 2011 at 5:27 PM, Dale <rdalek1967@gmail.com> wrote:
>> Neil Bothwick wrote:
>>>
>>> On Sun, 10 Jul 2011 14:42:50 -0500, Dale wrote:
>>>
>>>
>>>>
>>>> Yea, done tried that.  I tried different kernels, different nvidia
>>>> drivers and all with no change.
>>>>
>>>
>>> WAG - have you tried the nv drivers?
>>>
>>>
>>>
>>
>> I did but I couldn't get X to even start.  I guess something is not set
>> right somewhere.  I have nv in make.conf and been there since I built this
>> thing so sort of clueless on why it don't work.
>>
>> Maybe it's because I don't use the latest greatest cards but I don't think I
>> have ever really had trouble with nvidia drivers.  Surely it can't be good
>> luck.  ;-)
>>
>> While I am at it, what is the syntax to mask a package higher than a certain
>> version in package.mask?  I tired =>package.name.version and tried >=
>> package.name.version but the former doesn't work and seems to ignore it and
>> the later makes emerge print a boo boo message.  On my old rig, I want to
>> mask anything above the 173 series.   So far, I haven't had the light bulb
>> moment and never can remember how to do this.
>>
>> Thanks.
>>
>> Dale
>
> May I ask exactly what NVidia card you are using and why you are using
> (if I understood you correctly) the nv driver and not the nvidia
> driver?
>
> This page at NVidia will point you at the right driver. I've got a
> little bit of every NVidia technology here and they haven't treated me
> wrong yet.
>
> http://www.nvidia.com/Download/index.aspx?lang=en-us
>
> My make.conf files all say
>
> VIDEO_CARDS="nvidia"
>
> and then I typically use the beta driver ala:
>
> mark@slinky ~ $ cat /etc/portage/package.keywords | grep nvidia
> x11-drivers/nvidia-drivers ~amd64
> dev-util/nvidia-cuda-toolkit ~amd64
> dev-util/nvidia-cuda-sdk ~amd64
> mark@slinky ~ $
>
> You won't need the CUDAstuff.
>
> It's always the NVidia driver in /etc/X11/xorg.conf, not the older nv driver:
>
> mark@slinky ~ $ cat /etc/X11/xorg.conf | grep nvidia
>        Driver      "nvidia"
> mark@slinky ~ $
>
> - Mark
>

Re: [gentoo-user] Re: Firefox and kernel panics.

[Dale]

Mark Knecht wrote:
> DAle,
>     PLEASE look at bullet item #3 in this NVidia release:
>
> http://www.nvidia.com/object/linux-display-amd64-275.09.07-driver.html
>
> <QUOTE>
>
> Fixed a bug that caused freezes and crashes when resizing windows in
> KDE 4 with desktop effects enabled using X.Org X server version 1.10
> or later.
> <QUOTE>
>
> Sure sounds familiar to me...
>
> - Mark
>
>    

Yea, that does sound familiar.  Trying to recall who could have had that 
problem.  Hmmmm.  Oh, it was me !!  lol  This is my card info:

01:00.0 VGA compatible controller: nVidia Corporation GT200 [GeForce GT 
220] (rev a2)

Drivers:

x11-drivers/nvidia-drivers-270.41.19

That is the latest for my card that is in the tree.  Now keep in mind, 
going back to the older xorg fixed the Konsole and resizing issue I 
had.  So far, I'm not sure Firefox has its problem fixed.  I'm going to 
try it here in a few.  Just close everything I can, type in sync and 
open the thing and see if the smoke gets out.  Oh, got to install it 
again too.  Almost forgot that.

It's funny in a way.  I haven't been to the nvidia website in ages.  I 
just sort of guess at a version, try it and see if it works.  If not, 
try another one until I find one that does.  There isn't that many in 
the tree.  I never use the latest because I have never had that new of a 
card.  :/

Thanks.

Dale

:-)  :-)

Re: [gentoo-user] Re: Firefox and kernel panics.

[Bill Kenworthy]

On Mon, 2011-07-11 at 00:03 -0500, Dale wrote:
> Mark Knecht wrote:
> > DAle,

Hi Dale, not quite the same but something else to check - after my
6monthly update round, I had two systems where FF refused to run - just
flashed up died.  Erase .mozilla allowed one restart where I got a
window, any attempt to configure it killed FF.

This is on gnome, not KDE so while symptoms differ, it may still be the
same root cause - some of the underlying packages needed rebuilding - it
was (maybe) nss and dev-lang/spidermonkey.  Sorry, had a lot going on so
cant be more specific - it was strace that tipped me off (how I cant
remember).

BillK

Re: [gentoo-user] Re: Firefox and kernel panics.

[Dale]

Bill Kenworthy wrote:
> On Mon, 2011-07-11 at 00:03 -0500, Dale wrote:
>    
>> Mark Knecht wrote:
>>      
>>> DAle,
>>>        
> Hi Dale, not quite the same but something else to check - after my
> 6monthly update round, I had two systems where FF refused to run - just
> flashed up died.  Erase .mozilla allowed one restart where I got a
> window, any attempt to configure it killed FF.
>
> This is on gnome, not KDE so while symptoms differ, it may still be the
> same root cause - some of the underlying packages needed rebuilding - it
> was (maybe) nss and dev-lang/spidermonkey.  Sorry, had a lot going on so
> cant be more specific - it was strace that tipped me off (how I cant
> remember).
>
> BillK
>
>    

I'm going to try a clean directory for it here in a minute.  I'm going 
to back up my whole home directory for good measure.

I'm not holding my breath but I'll cross my fingers just in case.

Dale

:-)  :-)

Re: [gentoo-user] Re: Firefox and kernel panics.

[Dale]

Dale wrote:
> Bill Kenworthy wrote:
>> On Mon, 2011-07-11 at 00:03 -0500, Dale wrote:
>>> Mark Knecht wrote:
>>>> DAle,
>> Hi Dale, not quite the same but something else to check - after my
>> 6monthly update round, I had two systems where FF refused to run - just
>> flashed up died.  Erase .mozilla allowed one restart where I got a
>> window, any attempt to configure it killed FF.
>>
>> This is on gnome, not KDE so while symptoms differ, it may still be the
>> same root cause - some of the underlying packages needed rebuilding - it
>> was (maybe) nss and dev-lang/spidermonkey.  Sorry, had a lot going on so
>> cant be more specific - it was strace that tipped me off (how I cant
>> remember).
>>
>> BillK
>>
>
> I'm going to try a clean directory for it here in a minute.  I'm going 
> to back up my whole home directory for good measure.
>
> I'm not holding my breath but I'll cross my fingers just in case.
>
> Dale
>
> :-)  :-)
>

OK.  This is better. It seems to work.  Can someone explain how a bad 
config file in Firefox can cause a kernel panic?  I thought things like 
this was not possible?  This sounds so windowish.  o_O

Thanks for all the help.  It seems we had not one but two problems.  If 
it wasn't for bad luck . . . . . .

Dale

:-)  :-)

Re: [gentoo-user] Re: Firefox and kernel panics.

[Jesús J. Guerrero Botella]

2011/7/11 Dale <rdalek1967@gmail.com>:
> Dale wrote:
>>
>> Bill Kenworthy wrote:
>>>
>>> On Mon, 2011-07-11 at 00:03 -0500, Dale wrote:
>>>>
>>>> Mark Knecht wrote:
>>>>>
>>>>> DAle,
>>>
>>> Hi Dale, not quite the same but something else to check - after my
>>> 6monthly update round, I had two systems where FF refused to run - just
>>> flashed up died.  Erase .mozilla allowed one restart where I got a
>>> window, any attempt to configure it killed FF.
>>>
>>> This is on gnome, not KDE so while symptoms differ, it may still be the
>>> same root cause - some of the underlying packages needed rebuilding - it
>>> was (maybe) nss and dev-lang/spidermonkey.  Sorry, had a lot going on so
>>> cant be more specific - it was strace that tipped me off (how I cant
>>> remember).
>>>
>>> BillK
>>>
>>
>> I'm going to try a clean directory for it here in a minute.  I'm going to
>> back up my whole home directory for good measure.
>>
>> I'm not holding my breath but I'll cross my fingers just in case.
>>
>> Dale
>>
>> :-)  :-)
>>
>
> OK.  This is better. It seems to work.  Can someone explain how a bad config
> file in Firefox can cause a kernel panic?  I thought things like this was
> not possible?  This sounds so windowish.  o_O

We already explained you above in the other thread. That shouldn't be
possible in a sane system. You haven't found the root of the problem,
just the way to avoid it. The problem is in either the kernel (or one
of its modules) or the hardware. Firefox (or any other userland
program) has not the power to do this if the kernel doesn't allow it
or a hardware failure doesn't screw up something.


-- 
Jesús Guerrero Botella

Re: [gentoo-user] Re: Firefox and kernel panics.

[Dale]

Jesús J. Guerrero Botella wrote:
> 2011/7/11 Dale<rdalek1967@gmail.com>:
>    
>> Dale wrote:
>>      
>>> Bill Kenworthy wrote:
>>>        
>>>> On Mon, 2011-07-11 at 00:03 -0500, Dale wrote:
>>>>          
>>>>> Mark Knecht wrote:
>>>>>            
>>>>>> DAle,
>>>>>>              
>>>> Hi Dale, not quite the same but something else to check - after my
>>>> 6monthly update round, I had two systems where FF refused to run - just
>>>> flashed up died.  Erase .mozilla allowed one restart where I got a
>>>> window, any attempt to configure it killed FF.
>>>>
>>>> This is on gnome, not KDE so while symptoms differ, it may still be the
>>>> same root cause - some of the underlying packages needed rebuilding - it
>>>> was (maybe) nss and dev-lang/spidermonkey.  Sorry, had a lot going on so
>>>> cant be more specific - it was strace that tipped me off (how I cant
>>>> remember).
>>>>
>>>> BillK
>>>>
>>>>          
>>> I'm going to try a clean directory for it here in a minute.  I'm going to
>>> back up my whole home directory for good measure.
>>>
>>> I'm not holding my breath but I'll cross my fingers just in case.
>>>
>>> Dale
>>>
>>> :-)  :-)
>>>
>>>        
>> OK.  This is better. It seems to work.  Can someone explain how a bad config
>> file in Firefox can cause a kernel panic?  I thought things like this was
>> not possible?  This sounds so windowish.  o_O
>>      
> We already explained you above in the other thread. That shouldn't be
> possible in a sane system. You haven't found the root of the problem,
> just the way to avoid it. The problem is in either the kernel (or one
> of its modules) or the hardware. Firefox (or any other userland
> program) has not the power to do this if the kernel doesn't allow it
> or a hardware failure doesn't screw up something.
>
>
>    

Then I ask again, how does it do it?  I have opened things, even things 
I have NEVER opened before, and the only program that causes this that I 
can find is Firefox.  Is there something in the kernel that Firefox uses 
that nothing else does and that thing is broken?  If not, then it is 
something besides the kernel.  I have no idea myself what it is.

Might I add, Firefox has been running since before my last message last 
night.  No problems at all.  I was sort of careful to try one thing at a 
time whenever possible.  The only thing I did this last time was to 
start with a empty Firefox directory.  Nothing else changed.

Still open to ideas tho.

Dale

:-)  :-)

Re: [gentoo-user] Re: Firefox and kernel panics.

[Dale]

I'm baaaaaacccckkkkkk.  Anybody want to guess why?  Come on, guess.  
First one doesn't count.

OK.  This thing ran for a while with no problems.  I'm downloading a 
video while I am watching TV.  I use Firefox for that because it has 
that download helper tool and I like it.  I couldn't find it for 
Seamonkey.  Anyway, I'm watching TV when I here my puter beep like it 
does when it is booting up the BIOS.  I look over and sure enough, it 
was rebooting.  This is what I am using at the moment:

root@fireball / # equery list *xorg* firefox nvidia*
  * Searching for *xorg* ...
[IP-] [  ] x11-base/xorg-drivers-1.10:0
[IP-] [  ] x11-base/xorg-server-1.10.3:0

  * Searching for firefox ...
[IP-] [  ] www-client/firefox-3.6.17:0

  * Searching for nvidia* ...
[IP-] [  ] media-video/nvidia-settings-260.19.29:0
[IP-] [  ] x11-drivers/nvidia-drivers-275.09.07:0
root@fireball / #


There was a bump in xorg-server so I let it upgrade.  I also noticed the 
nvidia and updated it as well.  I don't recall seeing that the last time 
I looked.  Anyway, Could this be xorg, Nvidia, Firefox or something else 
or a combination of a couple of them?  I'm on the latest of everything 
that is in the tree.  I'm thinking about going back to the older xorg, 
just to test.

While I am at it, it ran fine before I let it upgrade xorg.  Maybe I 
didn't let it run long enough or something but it never crashed on me.

Any more thoughts on this mess?

Dale

:-)  :-)

Re: [gentoo-user] Re: Firefox and kernel panics.

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 549 bytes --]

On Thu, 14 Jul 2011 00:31:00 -0500, Dale wrote:

>   * Searching for nvidia* ...
> [IP-] [  ] media-video/nvidia-settings-260.19.29:0
> [IP-] [  ] x11-drivers/nvidia-drivers-275.09.07:0
> root@fireball / #

> I'm on the latest of everything that is in the tree.

No you're not. You are mixing ~amd64 drivers and amd64 settings. It is
unlikely to be the cause of your crashes, but you've tried all the likely
causes.


-- 
Neil Bothwick

"There are some ideas so idiotic that only an intellectual could believe
them" George Orwell

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-user] Re: Firefox and kernel panics.

[Dale]

Neil Bothwick wrote:
> On Thu, 14 Jul 2011 00:31:00 -0500, Dale wrote:
>
>    
>>    * Searching for nvidia* ...
>> [IP-] [  ] media-video/nvidia-settings-260.19.29:0
>> [IP-] [  ] x11-drivers/nvidia-drivers-275.09.07:0
>> root@fireball / #
>>      
>    
>> I'm on the latest of everything that is in the tree.
>>      
> No you're not. You are mixing ~amd64 drivers and amd64 settings. It is
> unlikely to be the cause of your crashes, but you've tried all the likely
> causes.
>
>
>    

I agree.  I don't think it is the settings one either but guess what, 
I'm going to try them too.  I did nvidia for the drivers but never 
checked the settings part.  Thanks for pointing that out.

I'm going to beat this dead horse a little more.  BRB

Dale

:-)  :-)

Re: [gentoo-user] Re: Firefox and kernel panics.

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 248 bytes --]

On Thu, 14 Jul 2011 03:28:38 -0500, Dale wrote:

> I'm going to beat this dead horse a little more.  BRB

You could try switching to Chromium ;-)


-- 
Neil Bothwick

"Self-explanatory": technospeak for "Incomprehensible & undocumented"

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-user] Re: Firefox and kernel panics.

[Mick]

[-- Attachment #1: Type: Text/Plain, Size: 337 bytes --]

On Thursday 14 Jul 2011 10:09:18 Neil Bothwick wrote:
> On Thu, 14 Jul 2011 03:28:38 -0500, Dale wrote:
> > I'm going to beat this dead horse a little more.  BRB
> 
> You could try switching to Chromium ;-)

Is that much different (other than the GUI) from running Konqueror with the 
WebKit browser engine?
-- 
Regards,
Mick

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-user] Re: Firefox and kernel panics.

[Daniel da Veiga]

[-- Attachment #1: Type: text/plain, Size: 1181 bytes --]

On Thu, Jul 14, 2011 at 05:28, Dale <rdalek1967@gmail.com> wrote:

> Neil Bothwick wrote:
>
>> On Thu, 14 Jul 2011 00:31:00 -0500, Dale wrote:
>>
>>
>>
>>>   * Searching for nvidia* ...
>>> [IP-] [  ] media-video/nvidia-settings-**260.19.29:0
>>> [IP-] [  ] x11-drivers/nvidia-drivers-**275.09.07:0
>>> root@fireball / #
>>>
>>>
>>
>>
>>> I'm on the latest of everything that is in the tree.
>>>
>>>
>> No you're not. You are mixing ~amd64 drivers and amd64 settings. It is
>> unlikely to be the cause of your crashes, but you've tried all the likely
>> causes.
>>
>>
>>
>>
>
> I agree.  I don't think it is the settings one either but guess what, I'm
> going to try them too.  I did nvidia for the drivers but never checked the
> settings part.  Thanks for pointing that out.
>
> I'm going to beat this dead horse a little more.  BRB
>


Have you tried a generic video drive to see if the problem is really related
to video/kernel? Whenever the video was going crazy because kernel
modules/settings/xorg and driver change, I just switch to VESA and see if it
works as it should. Then I can blame video drivers. VESA and no xorg.conf
was my way of testing it.

-- 
Daniel da Veiga

[-- Attachment #2: Type: text/html, Size: 1928 bytes --]

Re: [gentoo-user] Re: Firefox and kernel panics.

[Mark Knecht]

On Wed, Jul 13, 2011 at 10:31 PM, Dale <rdalek1967@gmail.com> wrote:
> I'm baaaaaacccckkkkkk.  Anybody want to guess why?  Come on, guess.  First
> one doesn't count.
>
> OK.  This thing ran for a while with no problems.  I'm downloading a video
> while I am watching TV.  I use Firefox for that because it has that download
> helper tool and I like it.  I couldn't find it for Seamonkey.  Anyway, I'm
> watching TV when I here my puter beep like it does when it is booting up the
> BIOS.  I look over and sure enough, it was rebooting.  This is what I am
> using at the moment:
>
> root@fireball / # equery list *xorg* firefox nvidia*
>  * Searching for *xorg* ...
> [IP-] [  ] x11-base/xorg-drivers-1.10:0
> [IP-] [  ] x11-base/xorg-server-1.10.3:0
>
>  * Searching for firefox ...
> [IP-] [  ] www-client/firefox-3.6.17:0
>
>  * Searching for nvidia* ...
> [IP-] [  ] media-video/nvidia-settings-260.19.29:0
> [IP-] [  ] x11-drivers/nvidia-drivers-275.09.07:0
> root@fireball / #
>
>
> There was a bump in xorg-server so I let it upgrade.  I also noticed the
> nvidia and updated it as well.  I don't recall seeing that the last time I
> looked.  Anyway, Could this be xorg, Nvidia, Firefox or something else or a
> combination of a couple of them?  I'm on the latest of everything that is in
> the tree.  I'm thinking about going back to the older xorg, just to test.
>
> While I am at it, it ran fine before I let it upgrade xorg.  Maybe I didn't
> let it run long enough or something but it never crashed on me.
>
> Any more thoughts on this mess?
>
> Dale

A complete reboot like that might be software jumping to the wrong
address but, if so, it seems to me that it's more likely caused by how
you've built the machine and not the software itself having a bug. KDE
& Firefox are very widely used. Why should you hit this bug and not
everyone else? None the less publish everything required for people to
hep, emerge --info, contents of all /etc/portage/package.* files,
/var/lib/portage/world, rc-update show results, etc. Maybe someone
will see it when you haven't. I don't think it's the nvidia-settings
stuff if you haven't run nvidia settings.

On the other hand, it's new hardware which is where I'd put my bet. A
flaky power supply. A funky motherboard. Bad CPU cooling causing
overheating. Memory problems that are as of yet uncovered by
memtest86.

Bummer...

- Mark

Re: [gentoo-user] Re: Firefox and kernel panics.

[Willie Wong]

On Thu, Jul 14, 2011 at 06:52:12AM -0700, Mark Knecht wrote:
> A complete reboot like that might be software jumping to the wrong
> address but, if so, it seems to me that it's more likely caused by how
> you've built the machine and not the software itself having a bug. 

If this is a continuation of Dale's previous problems, it is most
likely that the reboot is caused by him having enabled the kernel
option to reboot on panic. The question then is, what is causing the
kernel to panic?

W

-- 
Willie W. Wong                                     wwong@math.princeton.edu
Data aequatione quotcunque fluentes quantitae involvente fluxiones invenire 
         et vice versa   ~~~  I. Newton

Re: [gentoo-user] Re: Firefox and kernel panics.

[Dale]

Willie Wong wrote:
> On Thu, Jul 14, 2011 at 06:52:12AM -0700, Mark Knecht wrote:
>    
>> A complete reboot like that might be software jumping to the wrong
>> address but, if so, it seems to me that it's more likely caused by how
>> you've built the machine and not the software itself having a bug.
>>      
> If this is a continuation of Dale's previous problems, it is most
> likely that the reboot is caused by him having enabled the kernel
> option to reboot on panic. The question then is, what is causing the
> kernel to panic?
>
> W
>
>    

This is correct.  When the kernel panics, it waits 10 seconds or so then 
reboots itself.  I was concerned that whatever locks it up may make the 
CPU run at 100% or something and cause damage down the road.  So, when 
Neil posted how to set it to do this, I set it up.  It works.

Dale

:-)  :-)

Re: [gentoo-user] Re: Firefox and kernel panics.

[Mark Knecht]

On Thu, Jul 14, 2011 at 7:54 AM, Willie Wong <wwong@math.princeton.edu> wrote:
> On Thu, Jul 14, 2011 at 06:52:12AM -0700, Mark Knecht wrote:
>> A complete reboot like that might be software jumping to the wrong
>> address but, if so, it seems to me that it's more likely caused by how
>> you've built the machine and not the software itself having a bug.
>
> If this is a continuation of Dale's previous problems, it is most
> likely that the reboot is caused by him having enabled the kernel
> option to reboot on panic. The question then is, what is causing the
> kernel to panic?
>
> W

Ah, yes. I forgot that he talked about turning that on. I've never
used the option myself so it didn't enter my thinking.

OK, so I guess we're down to thinking this is just the same old
problem with this machine? What a drag to do all this stuff and then
make no headway!

I think it would be helpful at this point to see emerge --info and the
sort of stuff I outlined earlier. What else can we do?

There still exists the possibility of a bad piece of hardware. A
defective GPU, thermal issues on a motherboard in a system built at
home, etc.

I also think that a network debug console of some time might be
instructive if Dale is up to getting it operating.

- Mark

Re: [gentoo-user] Re: Firefox and kernel panics.

[Peter Humphrey]

On Thursday 14 July 2011 16:39:03 Mark Knecht wrote:

> I think it would be helpful at this point to see emerge --info and the
> sort of stuff I outlined earlier. What else can we do?
> 
> There still exists the possibility of a bad piece of hardware. A
> defective GPU, thermal issues on a motherboard in a system built at
> home, etc.
> 
> I also think that a network debug console of some time might be
> instructive if Dale is up to getting it operating.

I think it would be a good idea to start a new thread, Dale. It's long since 
the tree disappeared off the right side of the kmail window.

-- 
Rgds
Peter

Re: [gentoo-user] Re: Firefox and kernel panics.

[Mark Knecht]

On Thu, Jul 14, 2011 at 9:06 AM, Peter Humphrey
<peter@humphrey.ukfsn.org> wrote:
> On Thursday 14 July 2011 16:39:03 Mark Knecht wrote:
>
>> I think it would be helpful at this point to see emerge --info and the
>> sort of stuff I outlined earlier. What else can we do?
>>
>> There still exists the possibility of a bad piece of hardware. A
>> defective GPU, thermal issues on a motherboard in a system built at
>> home, etc.
>>
>> I also think that a network debug console of some time might be
>> instructive if Dale is up to getting it operating.
>
> I think it would be a good idea to start a new thread, Dale. It's long since
> the tree disappeared off the right side of the kmail window.
>
> --
> Rgds
> Peter
>

I tend to agree.Time to start over, from the beginning, which new
clean data. Machine hardware, full Gentoo configuration, xorg.conf
files, etc., along with the problem statement, so that we can get a
clean view of what's what. (As if we don't know...) ;-)

A side note... A friend just built his first new Gentoo machine based
on the Sandy Bridge processor. To get it to work it turned out we had
to choose specific CFLAGS due to problems with gcc on that processor.
Dale's problems might be of that nature - new hardware and very slight
incompatibilities causing fairly major problems...

Cheers,
Mark

Re: [gentoo-user] Re: Firefox and kernel panics.

[William Kenworthy]

On Mon, 2011-07-11 at 02:21 -0500, Dale wrote:
> Dale wrote:
> > Bill Kenworthy wrote:
> >> On Mon, 2011-07-11 at 00:03 -0500, Dale wrote:
> >>> Mark Knecht wrote:
> >>>> DAle,
> >> Hi Dale, not quite the same but something else to check - after my
> >> 6monthly update round, I had two systems where FF refused to run - just
> >> flashed up died.  Erase .mozilla allowed one restart where I got a
> >> window, any attempt to configure it killed FF.
> >>
> >> This is on gnome, not KDE so while symptoms differ, it may still be the
> >> same root cause - some of the underlying packages needed rebuilding - it
> >> was (maybe) nss and dev-lang/spidermonkey.  Sorry, had a lot going on so
> >> cant be more specific - it was strace that tipped me off (how I cant
> >> remember).
> >>
> >> BillK
> >>
> >
> > I'm going to try a clean directory for it here in a minute.  I'm going 
> > to back up my whole home directory for good measure.
> >
> > I'm not holding my breath but I'll cross my fingers just in case.
> >
> > Dale
> >
> > :-)  :-)
> >
> 
> OK.  This is better. It seems to work.  Can someone explain how a bad 
> config file in Firefox can cause a kernel panic?  I thought things like 
> this was not possible?  This sounds so windowish.  o_O
> 
> Thanks for all the help.  It seems we had not one but two problems.  If 
> it wasn't for bad luck . . . . . .
> 
> Dale
> 
> :-)  :-)
> 

For me it wasnt the config file itself - but something the config did
that dragged in another library that caused the grief.  Once I fixed
that I copied ythe old config back from the last backup and it kept
working.

BillK

Re: [gentoo-user] Re: Firefox and kernel panics.

[Dale]

Dale wrote:
>
> Yea, that does sound familiar.  Trying to recall who could have had 
> that problem.  Hmmmm.  Oh, it was me !!  lol  This is my card info:
>
> 01:00.0 VGA compatible controller: nVidia Corporation GT200 [GeForce 
> GT 220] (rev a2)
>
> Drivers:
>
> x11-drivers/nvidia-drivers-270.41.19
>
> That is the latest for my card that is in the tree.  Now keep in mind, 
> going back to the older xorg fixed the Konsole and resizing issue I 
> had.  So far, I'm not sure Firefox has its problem fixed.  I'm going 
> to try it here in a few.  Just close everything I can, type in sync 
> and open the thing and see if the smoke gets out.  Oh, got to install 
> it again too.  Almost forgot that.
>
> It's funny in a way.  I haven't been to the nvidia website in ages.  I 
> just sort of guess at a version, try it and see if it works.  If not, 
> try another one until I find one that does.  There isn't that many in 
> the tree.  I never use the latest because I have never had that new of 
> a card.  :/
>
> Thanks.
>
> Dale
>
> :-)  :-)
>

OK.  Here is the info:

root@fireball / # equery list *xorg* *nvidia*
  * Searching for *xorg* ...
[IP-] [  ] x11-base/xorg-drivers-1.9:0
[IP-] [  ] x11-base/xorg-server-1.9.5:0

  * Searching for *nvidia* ...
[IP-] [  ] media-video/nvidia-settings-260.19.29:0
[IP-] [  ] x11-drivers/nvidia-drivers-270.41.19:0
root@fireball / #

I closed all I could and did a couple syncs to sort of minimize the 
damage.  I opened Firefox, it opened it's home page and about 2 or 3 
seconds later, poof, the smoke got out.  So, after all this, Firefox 
still locks it up tight.  I didn't touch the window, mouse or keyboard.  
After I clicked to open Firefox, I let it do its thing until the lights 
on the keyboard starting to blink.

Firefox I tested was the stable version in the tree.

Can I shoot it now ??

Dale

:-)  :-)

Re: [gentoo-user] Re: Firefox and kernel panics.

[Mark Knecht]

On Sun, Jul 10, 2011 at 10:03 PM, Dale <rdalek1967@gmail.com> wrote:
> Mark Knecht wrote:
>>
>> DAle,
>>    PLEASE look at bullet item #3 in this NVidia release:
>>
>> http://www.nvidia.com/object/linux-display-amd64-275.09.07-driver.html
>>
>> <QUOTE>
>>
>> Fixed a bug that caused freezes and crashes when resizing windows in
>> KDE 4 with desktop effects enabled using X.Org X server version 1.10
>> or later.
>> <QUOTE>
>>
>> Sure sounds familiar to me...
>>
>> - Mark
>>
>>
>
> Yea, that does sound familiar.  Trying to recall who could have had that
> problem.  Hmmmm.  Oh, it was me !!  lol  This is my card info:
>
> 01:00.0 VGA compatible controller: nVidia Corporation GT200 [GeForce GT 220]
> (rev a2)
>
> Drivers:
>
> x11-drivers/nvidia-drivers-270.41.19
>
> That is the latest for my card that is in the tree.

No! It is not the latest. It's just what portage is offering you. The
link I sent you clearly (!?) stated that you need to be running the
latest 'Certified' driver revision 275.09.07 to get this fix. Just
because the Gentoo devs haven't marked it as stable does (to me) mean
that I should take their word for it. The company that makes the GPU
AND designed the driver says to upgrade, so in this case I do what
NVidia tells me.

mark@c2stable ~ $ eix nvidia-drivers
[I] x11-drivers/nvidia-drivers
     Available versions:  96.43.19!s 173.14.28!s 173.14.30!s
(~)256.53!s 260.19.44!s 270.41.06!s (~)270.41.19!s (~)275.09.07!s
{acpi custom-cflags gtk kernel_linux multilib}
     Installed versions:  275.09.07!s(10:21:39 AM 06/24/2011)(acpi gtk
kernel_linux multilib -custom-cflags)
     Homepage:            http://www.nvidia.com/
     Description:         NVIDIA X11 driver and GLX libraries

mark@c2stable ~ $

Do the right thing for your machine. Keep it up to date as per
portage, not downgrading to old Xorg stuff, and use the driver NVidia
tells you to use.

Happy, happy.

> Now keep in mind, going
> back to the older xorg fixed the Konsole and resizing issue I had.  So far,
> I'm not sure Firefox has its problem fixed.  I'm going to try it here in a
> few.  Just close everything I can, type in sync and open the thing and see
> if the smoke gets out.  Oh, got to install it again too.  Almost forgot
> that.
>
> It's funny in a way.  I haven't been to the nvidia website in ages.  I just
> sort of guess at a version, try it and see if it works.  If not, try another
> one until I find one that does.  There isn't that many in the tree.  I never
> use the latest because I have never had that new of a card.  :/

New drivers AREN'T only for new cards. They are also for old cards
that develop new problems. I.e. - a resizing problem in KDE4 with a
new Xorg package.

In this one case of NVidia hardware, if I'm going to use the closed
source driver then it seems to me the controlling authority of what to
use is NVidia and a Gentoo dev who doesn't have this problem. I
suspect if a Gentoo dev had the problem you're having this driver
would have been marked stable weeks ago!

Cheers,
Mark

Re: [gentoo-user] Re: Firefox and kernel panics.

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 640 bytes --]

On Mon, 11 Jul 2011 05:47:28 -0700, Mark Knecht wrote:

> > That is the latest for my card that is in the tree.  
> 
> No! It is not the latest. It's just what portage is offering you. The
> link I sent you clearly (!?) stated that you need to be running the
> latest 'Certified' driver revision 275.09.07 to get this fix. Just
> because the Gentoo devs haven't marked it as stable does (to me) mean
> that I should take their word for it.

Gentoo devs don't mark software as stable, they mark ebuilds as stable.
This has no direct link to the usability of the software itself.


-- 
Neil Bothwick

Loose bits sink chips.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-user] Re: Firefox and kernel panics.

[Michael Orlitzky]

On 07/11/11 09:45, Neil Bothwick wrote:
> 
> Gentoo devs don't mark software as stable, they mark ebuilds as stable.
> This has no direct link to the usability of the software itself.
> 
> 

Nuh uh. From http://devmanual.gentoo.org/keywording/index.html,

arch (x86, ppc-macos)
    Both the package version and the ebuild are widely tested, known to
    work and not have any serious issues on the indicated platform.

...

Moving from ~arch to arch

Moving a package from ~arch to arch is done only by the relevant arch
teams. If you have access to non-x86 hardware but are not on the arch
teams, you may wish to make individual arrangements — the arch teams are
happy for help, so long as they know what is going on. Please note that
x86 is now no longer an exception and stabilisation must be done through
the x86 arch team unless you have individual arrangements — see GLEP 40
for further details.

For a package to move to stable, the following guidelines must be met:

    * The package has spent a reasonable amount of time in ~arch first.
      Thirty days is the usual figure, although this is clearly only a
      guideline. For critical packages, a much longer duration is
      expected. For small packages which have only minor changes
      between versions, a shorter period is sometimes appropriate.
    * The package must not have any non-arch dependencies.
    * The package must not have any severe outstanding bugs or issues.
    * The package must be widely tested.
    * If the package is a library, it should be known not to break any
      package which depends upon it.

For security fixes, the "reasonable amount of time" guideline may be
relaxed. See the Vulnerability Treatment Policy

Re: [gentoo-user] Re: Firefox and kernel panics.

[Mark Knecht]

On Mon, Jul 11, 2011 at 7:17 AM, Michael Orlitzky <michael@orlitzky.com> wrote:
> On 07/11/11 09:45, Neil Bothwick wrote:
>>
>> Gentoo devs don't mark software as stable, they mark ebuilds as stable.
>> This has no direct link to the usability of the software itself.
>>
>>
>
> Nuh uh. From http://devmanual.gentoo.org/keywording/index.html,
>
> arch (x86, ppc-macos)
>    Both the package version and the ebuild are widely tested, known to
>    work and not have any serious issues on the indicated platform.
>
> ...
>
> Moving from ~arch to arch
>
> Moving a package from ~arch to arch is done only by the relevant arch
> teams. If you have access to non-x86 hardware but are not on the arch
> teams, you may wish to make individual arrangements — the arch teams are
> happy for help, so long as they know what is going on. Please note that
> x86 is now no longer an exception and stabilisation must be done through
> the x86 arch team unless you have individual arrangements — see GLEP 40
> for further details.
>
> For a package to move to stable, the following guidelines must be met:
>
>    * The package has spent a reasonable amount of time in ~arch first.
>      Thirty days is the usual figure, although this is clearly only a
>      guideline. For critical packages, a much longer duration is
>      expected. For small packages which have only minor changes
>      between versions, a shorter period is sometimes appropriate.
>    * The package must not have any non-arch dependencies.
>    * The package must not have any severe outstanding bugs or issues.
>    * The package must be widely tested.
>    * If the package is a library, it should be known not to break any
>      package which depends upon it.
>
> For security fixes, the "reasonable amount of time" guideline may be
> relaxed. See the Vulnerability Treatment Policy
>
>

Thanks for posting this.

- Mark

Re: [gentoo-user] Re: Firefox and kernel panics.

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 1572 bytes --]

On Mon, 11 Jul 2011 10:17:28 -0400, Michael Orlitzky wrote:

> > Gentoo devs don't mark software as stable, they mark ebuilds as
> > stable. This has no direct link to the usability of the software
> > itself.
> > 
> >   
> 
> Nuh uh. From http://devmanual.gentoo.org/keywording/index.html,
> 
> arch (x86, ppc-macos)
>     Both the package version and the ebuild are widely tested, known to
>     work and not have any serious issues on the indicated platform.

Yeah, I put that badly. The important point here is "and the ebuild".
The software could be as reliable as hell, but that does not mean the
ebuild has been sufficiently tested. arch means package and ebuild are
well tested, but that doesn't imply that ~arch means both are untested.
That's why software marked as stable by upstream doesn't always have an
~arch keyword.

You've cut the context of my reply, but it was 

> > No! It is not the latest. It's just what portage is offering you. The
> > link I sent you clearly (!?) stated that you need to be running the
> > latest 'Certified' driver revision 275.09.07 to get this fix. Just
> > because the Gentoo devs haven't marked it as stable does (to me) mean
> > that I should take their word for it.  

If Nvidia say to use the later version because they know the current
arch version is broken, you should follow their advice and not ignore it
simply because of a keyword setting in the ebuild.


-- 
Neil Bothwick

A printer consists of three main parts: the case, the jammed paper tray
and the blinking red light.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-user] Re: Firefox and kernel panics.

[Mark Knecht]

On Mon, Jul 11, 2011 at 2:00 PM, Neil Bothwick <neil@digimed.co.uk> wrote:
<SNIP>
>
>> > No! It is not the latest. It's just what portage is offering you. The
>> > link I sent you clearly (!?) stated that you need to be running the
>> > latest 'Certified' driver revision 275.09.07 to get this fix. Just
>> > because the Gentoo devs haven't marked it as stable does (to me) mean
>> > that I should take their word for it.
>
> If Nvidia say to use the later version because they know the current
> arch version is broken, you should follow their advice and not ignore it
> simply because of a keyword setting in the ebuild.
>
>
> --
> Neil Bothwick

And of course I would screw up my response by writing

[QUOTE]
Just because the Gentoo devs haven't marked it as stable
does (to me) mean that I should take their word for it.
[/QUOTE]

instead of what I meant, which would have been

[SUBSTITUTE]
Just because the Gentoo devs haven't marked it as stable
***DOESN'T*** (to me) mean that I should take their word for it.
[/SUBSTITUTE]

Sorry!

- Mark

Re: [gentoo-user] Re: Firefox and kernel panics.

[Dale]

Mark Knecht wrote:
> On Mon, Jul 11, 2011 at 2:00 PM, Neil Bothwick<neil@digimed.co.uk>  wrote:
> <SNIP>
>    
>>      
>>>> No! It is not the latest. It's just what portage is offering you. The
>>>> link I sent you clearly (!?) stated that you need to be running the
>>>> latest 'Certified' driver revision 275.09.07 to get this fix. Just
>>>> because the Gentoo devs haven't marked it as stable does (to me) mean
>>>> that I should take their word for it.
>>>>          
>> If Nvidia say to use the later version because they know the current
>> arch version is broken, you should follow their advice and not ignore it
>> simply because of a keyword setting in the ebuild.
>>
>>
>> --
>> Neil Bothwick
>>      
> And of course I would screw up my response by writing
>
> [QUOTE]
> Just because the Gentoo devs haven't marked it as stable
> does (to me) mean that I should take their word for it.
> [/QUOTE]
>
> instead of what I meant, which would have been
>
> [SUBSTITUTE]
> Just because the Gentoo devs haven't marked it as stable
> ***DOESN'T*** (to me) mean that I should take their word for it.
> [/SUBSTITUTE]
>
> Sorry!
>
> - Mark
>
>    

WOW !!!  I'm not the only one that leaves out the word NOT.  Funny how 
that three letter word can change the meaning of a sentence so much.  It 
seems to turn things on its head so to speak.  ;-)

Dale

:-)  :-)

Re: [gentoo-user] Re: Firefox and kernel panics.

[Peter Humphrey]

On Monday 11 July 2011 23:30:40 Dale wrote:

> WOW !!!  I'm not the only one that leaves out the word NOT.  Funny how
> that three letter word can change the meaning of a sentence so much.  It
> seems to turn things on its head so to speak.  ;-)

Is that why I seem only to see the word 'not' in capitals these days?

-- 
Rgds
Peter

Re: [gentoo-user] Re: Firefox and kernel panics.

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 379 bytes --]

On Mon, 11 Jul 2011 17:30:40 -0500, Dale wrote:

> WOW !!!  I'm not the only one that leaves out the word NOT.  Funny how 
> that three letter word can change the meaning of a sentence so much.
> It seems to turn things on its head so to speak.  ;-)

That is more or less the idea of the word :P


-- 
Neil Bothwick

Always be sincere... whether you mean it or not!

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-user] Re: Firefox and kernel panics.

[Mark Knecht]

On Mon, Jul 11, 2011 at 6:45 AM, Neil Bothwick <neil@digimed.co.uk> wrote:
> On Mon, 11 Jul 2011 05:47:28 -0700, Mark Knecht wrote:
>
>> > That is the latest for my card that is in the tree.
>>
>> No! It is not the latest. It's just what portage is offering you. The
>> link I sent you clearly (!?) stated that you need to be running the
>> latest 'Certified' driver revision 275.09.07 to get this fix. Just
>> because the Gentoo devs haven't marked it as stable does (to me) mean
>> that I should take their word for it.
>
> Gentoo devs don't mark software as stable, they mark ebuilds as stable.
> This has no direct link to the usability of the software itself.

Very true and while I don't think my post disagreed with you your
clarification is timely. It's unclear to me whether there is a
specific dev policy about exactly what has to happen to have an ebuild
marked as stable but my understanding has been that then Gentoo devs
do different things like wait for some number of users to download it
and/or watch bug reports for some period of time ensuring there aren't
too many problems, etc., before marking the ebuild as stable. Is that
roughly correct?

- Mark

Re: [gentoo-user] Re: Firefox and kernel panics.

[Dale]

Mark Knecht wrote:
> On Sun, Jul 10, 2011 at 10:03 PM, Dale<rdalek1967@gmail.com>  wrote:
>    
>> Mark Knecht wrote:
>>      
>>> DAle,
>>>     PLEASE look at bullet item #3 in this NVidia release:
>>>
>>> http://www.nvidia.com/object/linux-display-amd64-275.09.07-driver.html
>>>
>>> <QUOTE>
>>>
>>> Fixed a bug that caused freezes and crashes when resizing windows in
>>> KDE 4 with desktop effects enabled using X.Org X server version 1.10
>>> or later.
>>> <QUOTE>
>>>
>>> Sure sounds familiar to me...
>>>
>>> - Mark
>>>
>>>
>>>        
>> Yea, that does sound familiar.  Trying to recall who could have had that
>> problem.  Hmmmm.  Oh, it was me !!  lol  This is my card info:
>>
>> 01:00.0 VGA compatible controller: nVidia Corporation GT200 [GeForce GT 220]
>> (rev a2)
>>
>> Drivers:
>>
>> x11-drivers/nvidia-drivers-270.41.19
>>
>> That is the latest for my card that is in the tree.
>>      
> No! It is not the latest. It's just what portage is offering you. The
> link I sent you clearly (!?) stated that you need to be running the
> latest 'Certified' driver revision 275.09.07 to get this fix. Just
> because the Gentoo devs haven't marked it as stable does (to me) mean
> that I should take their word for it. The company that makes the GPU
> AND designed the driver says to upgrade, so in this case I do what
> NVidia tells me.
>
> mark@c2stable ~ $ eix nvidia-drivers
> [I] x11-drivers/nvidia-drivers
>       Available versions:  96.43.19!s 173.14.28!s 173.14.30!s
> (~)256.53!s 260.19.44!s 270.41.06!s (~)270.41.19!s (~)275.09.07!s
> {acpi custom-cflags gtk kernel_linux multilib}
>       Installed versions:  275.09.07!s(10:21:39 AM 06/24/2011)(acpi gtk
> kernel_linux multilib -custom-cflags)
>       Homepage:            http://www.nvidia.com/
>       Description:         NVIDIA X11 driver and GLX libraries
>
> mark@c2stable ~ $
>
> Do the right thing for your machine. Keep it up to date as per
> portage, not downgrading to old Xorg stuff, and use the driver NVidia
> tells you to use.
>
> Happy, happy.
>
>    
>> Now keep in mind, going
>> back to the older xorg fixed the Konsole and resizing issue I had.  So far,
>> I'm not sure Firefox has its problem fixed.  I'm going to try it here in a
>> few.  Just close everything I can, type in sync and open the thing and see
>> if the smoke gets out.  Oh, got to install it again too.  Almost forgot
>> that.
>>
>> It's funny in a way.  I haven't been to the nvidia website in ages.  I just
>> sort of guess at a version, try it and see if it works.  If not, try another
>> one until I find one that does.  There isn't that many in the tree.  I never
>> use the latest because I have never had that new of a card.  :/
>>      
> New drivers AREN'T only for new cards. They are also for old cards
> that develop new problems. I.e. - a resizing problem in KDE4 with a
> new Xorg package.
>
> In this one case of NVidia hardware, if I'm going to use the closed
> source driver then it seems to me the controlling authority of what to
> use is NVidia and a Gentoo dev who doesn't have this problem. I
> suspect if a Gentoo dev had the problem you're having this driver
> would have been marked stable weeks ago!
>
> Cheers,
> Mark
>
>    

Since I only use portage to install things, if it isn't in portage, I 
don't see it.  Yea, I could most likely download and install it manually 
from Nvidia but I like the way portage does it.  That's why I use Gentoo 
to begin with.  Even when I used Mandrake, I didn't like installing 
things outside of what Mandrake installed itself.  Nvidia was one of 
those but I don't think they put the drivers in their list of packages 
anyway.  Sort of had no choice with them.  I just wonder why no one has 
updated this in the tree yet?

As for xorg, if going to a older version will fix something, then a 
older version it is.  It's no different than me running something 
masked/keyworded to fix a issue.  Heck, I have ran several packages that 
were masked/keyworded because it had a fix for some problem.  I suspect 
most all of us have done that at some time or other.

Also, I do know that drivers get updated even for older cards.  They are 
always coming out with some fix, new feature or just a new bug.  lol   I 
upgrade them sometimes on my old rig with a FX-5200 card.  It happens 
often enough.

Dale

:-)  :-)

Re: [gentoo-user] Re: Firefox and kernel panics.

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 923 bytes --]

On Sun, 10 Jul 2011 19:27:32 -0500, Dale wrote:

> > WAG - have you tried the nv drivers?

> I did but I couldn't get X to even start.  I guess something is not set 
> right somewhere.  I have nv in make.conf and been there since I built 
> this thing so sort of clueless on why it don't work.

Did you remove the nvidia drivers and xorg.conf?

> While I am at it, what is the syntax to mask a package higher than a 
> certain version in package.mask?  I tired =>package.name.version and 
> tried >= package.name.version but the former doesn't work and seems to 
> ignore it and the later makes emerge print a boo boo message.  On my
> old rig, I want to mask anything above the 173 series.   So far, I
> haven't had the light bulb moment and never can remember how to do this.

>category/package-version


-- 
Neil Bothwick

Never wrestle with a pig. You both get dirty but only the pig enjoys it.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-user] Re: Firefox and kernel panics.

[Dale]

Neil Bothwick wrote:
> On Sun, 10 Jul 2011 19:27:32 -0500, Dale wrote:
>
>    
>>> WAG - have you tried the nv drivers?
>>>        
>    
>> I did but I couldn't get X to even start.  I guess something is not set
>> right somewhere.  I have nv in make.conf and been there since I built
>> this thing so sort of clueless on why it don't work.
>>      
> Did you remove the nvidia drivers and xorg.conf?
>
>    

You mean emerge -C the nvidia drivers?  The last time I used the nv 
drivers, I just had to change it from nvidia to nv in xorg.conf.
>> While I am at it, what is the syntax to mask a package higher than a
>> certain version in package.mask?  I tired =>package.name.version and
>> tried>= package.name.version but the former doesn't work and seems to
>> ignore it and the later makes emerge print a boo boo message.  On my
>> old rig, I want to mask anything above the 173 series.   So far, I
>> haven't had the light bulb moment and never can remember how to do this.
>>      
>    
>> category/package-version
>>      

Let me try and explain this way.  This is the list of drivers in the tree:

[-P-] [  ] x11-drivers/nvidia-drivers-96.43.19:0
[-P-] [  ] x11-drivers/nvidia-drivers-173.14.28:0
[-P-] [  ] x11-drivers/nvidia-drivers-173.14.30:0
[-P-] [  ] x11-drivers/nvidia-drivers-256.53:0
[-P-] [  ] x11-drivers/nvidia-drivers-260.19.44:0
[-P-] [  ] x11-drivers/nvidia-drivers-270.41.06:0
[IP-] [  ] x11-drivers/nvidia-drivers-270.41.19:0
[-P-] [ ~] x11-drivers/nvidia-drivers-275.09.07:0

I want my old rig to be able to upgrade to whatever gets released in the 
173 series but no to anything above that, since they don't work with my 
card.  I was thinking I used to do it like this:

 >=x11-drivers/nvidia-drivers-173.99.99 or something to that effect.  I 
just can't recall how to do it at the moment but each time I do a emerge 
-uvDNa world, it wants to upgrade the nvidia drivers to the 275 series 
or something.

See what I am running into?  I don't think I was to clear before.  One 
of those days.

Dale

:-)  :-)

[gentoo-user] Re: Firefox and kernel panics.

[walt]

On 07/11/2011 02:30 PM, Dale wrote:
>> =x11-drivers/nvidia-drivers-173.99.99 or something to that effect.
>> I just can't recall how to do it at the moment but each time I do a
>> emerge -uvDNa world, it wants to upgrade the nvidia drivers to the
>> 275 series or something.

I've had the same problem many times -- and so far it's always been my
bad typing skills :)

I have exactly the same needs on my old machine, and here's what I have:

#grep nvidia /etc/portage/package.mask 
>=x11-drivers/nvidia-drivers-177.80
<=x11-drivers/nvidia-drivers-173.14.27  (can't remember why I did this)

In my experience the disadvantage of using the older drivers is that
nVidia is slow to fix build breakage introduced by Linus et al.

I test Linus's daily kernel updates (because I like pain, that's why)
and I've had to fudge all kinds of stuff to get the 173.x.x drivers
to build against the new kernel headers.  You'd think I could find
something better to do with my time -- but no...

Re: [gentoo-user] Re: Firefox and kernel panics.

[Alex Schuster]

Dale asks:

> While I am at it, what is the syntax to mask a package higher than a
> certain version in package.mask?  I tired =>package.name.version and
> tried >= package.name.version but the former doesn't work and seems to
> ignore it and the later makes emerge print a boo boo message.  On my old
> rig, I want to mask anything above the 173 series.   So far, I haven't
> had the light bulb moment and never can remember how to do this.

This should do it: >=x11-drivers/nvidia-drivers-174

	Wonko

Re: [gentoo-user] Re: Firefox and kernel panics.

[Dale]

Alex Schuster wrote:
> Dale asks:
>
>    
>> While I am at it, what is the syntax to mask a package higher than a
>> certain version in package.mask?  I tired =>package.name.version and
>> tried>= package.name.version but the former doesn't work and seems to
>> ignore it and the later makes emerge print a boo boo message.  On my old
>> rig, I want to mask anything above the 173 series.   So far, I haven't
>> had the light bulb moment and never can remember how to do this.
>>      
> This should do it:>=x11-drivers/nvidia-drivers-174
>
> 	Wonko
>
>
>    


I'll try that.  I thought it had to be the whole version part.  I guess 
it changed at some point which is why it is complaining on my old rig now.

Thanks.

Dale

:-)  :-)

Re: [gentoo-user] Re: Firefox and kernel panics.

[Dale]

Alex Schuster wrote:
> Dale asks:
>
>    
>> While I am at it, what is the syntax to mask a package higher than a
>> certain version in package.mask?  I tired =>package.name.version and
>> tried>= package.name.version but the former doesn't work and seems to
>> ignore it and the later makes emerge print a boo boo message.  On my old
>> rig, I want to mask anything above the 173 series.   So far, I haven't
>> had the light bulb moment and never can remember how to do this.
>>      
> This should do it:>=x11-drivers/nvidia-drivers-174
>
> 	Wonko
>
>
>    

I don't boot that machine often so it took me a bit to get around to 
testing it.  This setting worked great.  portage does what I want and we 
are both happy.

Thanks much.

Dale

:-)  :-)

Re: [gentoo-user] Re: Firefox and kernel panics.

[Peter Humphrey]

On Sunday 10 July 2011 20:42:50 Dale wrote:

> Yea, done tried that.  I tried different kernels, different nvidia
> drivers and all with no change.

Yes, but what about xorg-server? I think that's what Peter was suggesting.

-- 
Rgds
Peter

Re: [gentoo-user] Re: Firefox and kernel panics.

[Dale]

Peter Humphrey wrote:
> On Sunday 10 July 2011 20:42:50 Dale wrote:
>
>    
>> Yea, done tried that.  I tried different kernels, different nvidia
>> drivers and all with no change.
>>      
> Yes, but what about xorg-server? I think that's what Peter was suggesting.
>
>    

I did back up a version of xorg.  Firefox still causes the panic tho.  
That said, Konsole works now so it fixed that problem.

I just upgraded KDE and am trying to get the nerve up to install Firefox 
again.  I had KDE set to start with a saved session which would include 
starting Firefox.  I unmerged Firefox so it wouldn't start up and cause 
me to crash as soon as I logged in.  One thing about a fast machine, 
can't close something before it causes a problem.  lol

Dale

:-)  :-)

[gentoo-user] Re: Firefox and kernel panics.

[Nikos Chantziaras]

On 07/09/2011 04:49 AM, Dale wrote:
> OK. Back to the original thread.
>
> Here we go again. Everything seems to work EXCEPT Firefox. When I log
> into KDE, I can run Seamonkey, Kpat, Konqueror, Konsole, gkrellm and
> such but as soon as I start Firefox, it locks up tight.

Try to temporarily remove your .mozilla directory:

   mv ~/.mozilla ~/mozilla-backup

And then start FF.  This is just to see if some setting is at fault.

[gentoo-user] Re: Firefox and kernel panics.

[Nikos Chantziaras]

On 07/09/2011 08:16 PM, Nikos Chantziaras wrote:
> On 07/09/2011 04:49 AM, Dale wrote:
>> OK. Back to the original thread.
>>
>> Here we go again. Everything seems to work EXCEPT Firefox. When I log
>> into KDE, I can run Seamonkey, Kpat, Konqueror, Konsole, gkrellm and
>> such but as soon as I start Firefox, it locks up tight.
>
> Try to temporarily remove your .mozilla directory:
>
> mv ~/.mozilla ~/mozilla-backup
>
> And then start FF. This is just to see if some setting is at fault.

Btw, before you move the directory back later, always remove the newly 
created directory (rm -r ~/.mozilla), or else "mv ~/mozilla-backup 
~/.mozilla" will not do what you think it will do.

Re: [gentoo-user] Re: KDE and HARD lock ups.

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 419 bytes --]

On Thu, 07 Jul 2011 23:43:58 -0500, Dale wrote:

> One thing I did learn, if the lights on the keyboard 
> are blinking, it's locked up tight.

That's a kernel panic. You can have the system reboot itself after a
panic by adding kernel.panic=N to /etc/sysctl.conf, where N is the number
of seconds to wait before rebooting.


-- 
Neil Bothwick

Synonym: a word you use when you can't spell the other one.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-user] Re: KDE and HARD lock ups.

[Dale]

Neil Bothwick wrote:
> On Thu, 07 Jul 2011 23:43:58 -0500, Dale wrote:
>
>    
>> One thing I did learn, if the lights on the keyboard
>> are blinking, it's locked up tight.
>>      
> That's a kernel panic. You can have the system reboot itself after a
> panic by adding kernel.panic=N to /etc/sysctl.conf, where N is the number
> of seconds to wait before rebooting.
>
>
>    

Kewl !!!  I just saw that in the file but it is commented out.  Like this:

# When the kernel panics, automatically reboot in 3 seconds
#kernel.panic = 3

So, I uncomment this and the system will reboot in 3 seconds?  Does it 
sync and unmount or just do the same as me hitting the reset button?  
I'm going to uncomment this either way.  If it is locked up, does it 
matter if it is it or me that resets it?  lol

Is there a way to set this without rebooting?

Thanks.  Why wouldn't that be a default I wonder?

Dale

:-)  :-)

Re: [gentoo-user] Re: KDE and HARD lock ups.

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 1133 bytes --]

On Fri, 08 Jul 2011 04:19:46 -0500, Dale wrote:

> > That's a kernel panic. You can have the system reboot itself after a
> > panic by adding kernel.panic=N to /etc/sysctl.conf, where N is the
> > number of seconds to wait before rebooting.

> Kewl !!!  I just saw that in the file but it is commented out.  Like
> this:
> 
> # When the kernel panics, automatically reboot in 3 seconds
> #kernel.panic = 3
> 
> So, I uncomment this and the system will reboot in 3 seconds?  Does it 
> sync and unmount or just do the same as me hitting the reset button?  

The kernel is dead, it's all it can manage to reboot with it's last gasp.

> Is there a way to set this without rebooting?

You can set it with sysctl on the command line, or add it to the file and
reload the config with sysctl -p

> Thanks.  Why wouldn't that be a default I wonder?

Because it causes reboot loops if there's a basic error that causes a
panic when you boot.

You can also give it as a kernel option in GRUB, add "panic=N" to the
kernel options.


-- 
Neil Bothwick

Of all the people I've met you're certainly one of them.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-user] Re: KDE and HARD lock ups.

[Dale]

Neil Bothwick wrote:
> On Fri, 08 Jul 2011 04:19:46 -0500, Dale wrote:
>
>    
>>> That's a kernel panic. You can have the system reboot itself after a
>>> panic by adding kernel.panic=N to /etc/sysctl.conf, where N is the
>>> number of seconds to wait before rebooting.
>>>        
>    
>> Kewl !!!  I just saw that in the file but it is commented out.  Like
>> this:
>>
>> # When the kernel panics, automatically reboot in 3 seconds
>> #kernel.panic = 3
>>
>> So, I uncomment this and the system will reboot in 3 seconds?  Does it
>> sync and unmount or just do the same as me hitting the reset button?
>>      
> The kernel is dead, it's all it can manage to reboot with it's last gasp.
>
>    
>> Is there a way to set this without rebooting?
>>      
> You can set it with sysctl on the command line, or add it to the file and
> reload the config with sysctl -p
>
>    
>> Thanks.  Why wouldn't that be a default I wonder?
>>      
> Because it causes reboot loops if there's a basic error that causes a
> panic when you boot.
>
> You can also give it as a kernel option in GRUB, add "panic=N" to the
> kernel options.
>
>    

Thanks.  I'm hoping not to need this feature anytime soon.  ;-)

Dale

:-)  :-)

Re: [gentoo-user] KDE and HARD lock ups.

[Volker Armin Hemmann]

On Tuesday 05 July 2011 23:16:21 Dale wrote:
> Volker Armin Hemmann wrote:
> > On Tuesday 05 July 2011 15:41:13 Dale wrote:> 
> > update your fucking drivers.> 
> > Seriously, no userspace app does something like this. The driver is
> > broken, KDE touches the broken part and BOOM.> 
> > Don't blame KDE, blame nvidia.> 
> > And update the driver.
> I don't think a bad video driver would cause this:
> *root@fireball / # emerge -av =x11-drivers/nvidia-drivers-270.41.19
> These are the packages that would be merged, in order:
> Calculating dependencies |
> !!! Invalid or corrupt dependency specification:
> Invalid atom (????1), token 1
> (dev-perl/Net-SSLeay-1.36::unxlngx, installed)
> Portage is unable to process the dependencies of the 'dev-perl/Net-
SSLeay-1.36' package. In order to correct this problem, the packageshould be 
uninstalled, reinstalled, or upgraded. As a temporaryworkaround, the --nodeps 
option can be used to ignore all dependencies.For reference, the problematic 
dependencies can be found in the *DEPENDfiles located in '/var/db/pkg/dev-
perl/Net-SSLeay-1.36/'.... done!root@fireball / #
> Whatever the problems is, things are breaking.  I think something in KDEis 
broke, like corrupt file or some corrupt config somewhere, and it wasjust the 
first symptom of the problem.  No matter what I try to emerge,I get errors 
like this.
> Still think emerging a new video driver is going to help?  ;-)
> Dale
> :-)  :-)
> *

kde does not corrupt /var/db and does not lock up machines.

Bad video drivers do lock up machines

And machines locking up are prone to damage their file systems.

-- 
#163933

Re: [gentoo-user] KDE and HARD lock ups.

[Dale]

Volker Armin Hemmann wrote:
> On Tuesday 05 July 2011 23:16:21 Dale wrote:
>    
>> Volker Armin Hemmann wrote:
>>      
>>> On Tuesday 05 July 2011 15:41:13 Dale wrote:>
>>> update your fucking drivers.>
>>> Seriously, no userspace app does something like this. The driver is
>>> broken, KDE touches the broken part and BOOM.>
>>> Don't blame KDE, blame nvidia.>
>>> And update the driver.
>>>        
>> I don't think a bad video driver would cause this:
>> *root@fireball / # emerge -av =x11-drivers/nvidia-drivers-270.41.19
>> These are the packages that would be merged, in order:
>> Calculating dependencies |
>> !!! Invalid or corrupt dependency specification:
>> Invalid atom (????1), token 1
>> (dev-perl/Net-SSLeay-1.36::unxlngx, installed)
>> Portage is unable to process the dependencies of the 'dev-perl/Net-
>>      
> SSLeay-1.36' package. In order to correct this problem, the packageshould be
> uninstalled, reinstalled, or upgraded. As a temporaryworkaround, the --nodeps
> option can be used to ignore all dependencies.For reference, the problematic
> dependencies can be found in the *DEPENDfiles located in '/var/db/pkg/dev-
> perl/Net-SSLeay-1.36/'.... done!root@fireball / #
>    
>> Whatever the problems is, things are breaking.  I think something in KDEis
>>      
> broke, like corrupt file or some corrupt config somewhere, and it wasjust the
> first symptom of the problem.  No matter what I try to emerge,I get errors
> like this.
>    
>> Still think emerging a new video driver is going to help?  ;-)
>> Dale
>> :-)  :-)
>> *
>>      
> kde does not corrupt /var/db and does not lock up machines.
>
> Bad video drivers do lock up machines
>
> And machines locking up are prone to damage their file systems.
>
>    

But again, it didn't lock up until AFTER I had a power failure.  That 
was when all this started.  If I hadn't had the power failure, I may not 
have had the lock ups to begin with.  The root of this problem is what I 
am hoping to find.

Dale

:-)  :-)

Re: [gentoo-user] KDE and HARD lock ups.

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 489 bytes --]

On Wed, 06 Jul 2011 02:27:21 -0500, Dale wrote:

> But again, it didn't lock up until AFTER I had a power failure.  That 
> was when all this started.  If I hadn't had the power failure, I may
> not have had the lock ups to begin with.  The root of this problem is
> what I am hoping to find.

It sounds like you need to start with qcheck -aBT and trawl through the
output, re-emerging anything questionable.


-- 
Neil Bothwick

Every morning is the dawn of a new error...

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-user] KDE and HARD lock ups.

[Dale]

Neil Bothwick wrote:
> On Wed, 06 Jul 2011 02:27:21 -0500, Dale wrote:
>
>    
>> But again, it didn't lock up until AFTER I had a power failure.  That
>> was when all this started.  If I hadn't had the power failure, I may
>> not have had the lock ups to begin with.  The root of this problem is
>> what I am hoping to find.
>>      
> It sounds like you need to start with qcheck -aBT and trawl through the
> output, re-emerging anything questionable.
>
>
>    
This is what I got:

root@fireball / # qcheck -aBT
app-office/openoffice
sys-auth/consolekit
sys-auth/polkit
net-nds/openldap
app-misc/screen
net-print/cups
net-print/hplip
sys-apps/dbus
sys-apps/openrc
dev-db/mysql
kde-base/kdm
root@fireball / #

That hplip makes me wonder.  I had issues with that thing before causing 
freezes, not lock ups tho.  I should have expected openoffice to be on 
there tho. lol

Hmmm.  What you think about that list?  Anything look suspicious?

Dale

:-)  :-)

Re: [gentoo-user] KDE and HARD lock ups.

[Dale]

Dale wrote:
> Neil Bothwick wrote:
>> On Wed, 06 Jul 2011 02:27:21 -0500, Dale wrote:
>>
>>> But again, it didn't lock up until AFTER I had a power failure.  That
>>> was when all this started.  If I hadn't had the power failure, I may
>>> not have had the lock ups to begin with.  The root of this problem is
>>> what I am hoping to find.
>> It sounds like you need to start with qcheck -aBT and trawl through the
>> output, re-emerging anything questionable.
>>
>>
> This is what I got:
>
> root@fireball / # qcheck -aBT
> app-office/openoffice
> sys-auth/consolekit
> sys-auth/polkit
> net-nds/openldap
> app-misc/screen
> net-print/cups
> net-print/hplip
> sys-apps/dbus
> sys-apps/openrc
> dev-db/mysql
> kde-base/kdm
> root@fireball / #
>
> That hplip makes me wonder.  I had issues with that thing before 
> causing freezes, not lock ups tho.  I should have expected openoffice 
> to be on there tho. lol
>
> Hmmm.  What you think about that list?  Anything look suspicious?
>
> Dale
>
> :-)  :-)
>

OK.  I rebuilt all that . . . stuff plus a few others portage was 
pitching a fit about.  That would exclude openldap.  See one of the 
other threads on what happens when I try to compile that    stuff.   I'm 
getting like Alan here.  I'm tired and my nice shiny puter has a low 
gloss spot.  Grrrr.  Anyway, I can compile again at least.

Let's think here.  polkit, hplip really raises my eyebrows, dbus, mysql 
are things that KDE uses and Fluxbox don't.  I just wonder if one of 
those could be corrupt or something.  I use a slideshow for my 
background.  It usually locks up while setting up that thing.  It scans 
ALL the picture files or something.  I assume it builds some sort of 
data base which may use mysql.  Still giving that hplip the evil eye 
tho.  I know for sure that caused issues in the past.  I have had times 
where I wanted to shoot that little . . . thing.  lol

Still trying to finish the new install.  I my not need it but still.  
After it gets done, going to run memtest and try out that option 5.  I 
dunno either but I'm going to try it.

Dale

:-)  :-)

Re: [gentoo-user] KDE and HARD lock ups.

[Urs Schutz]

On Wed, 06 Jul 2011 03:53:23 -0500
Dale <rdalek1967@gmail.com> wrote:

snipped

> >>
> > This is what I got:
> >
> > root@fireball / # qcheck -aBT
> > app-office/openoffice
> > sys-auth/consolekit
> > sys-auth/polkit
> > net-nds/openldap
> > app-misc/screen
> > net-print/cups
> > net-print/hplip
> > sys-apps/dbus
> > sys-apps/openrc
> > dev-db/mysql
> > kde-base/kdm
> > root@fireball / #
> >
> > That hplip makes me wonder.  I had issues with that
> > thing before causing freezes, not lock ups tho.  I
> > should have expected openoffice to be on there tho. lol
> >
> > Hmmm.  What you think about that list?  Anything look
> > suspicious?
> >
> > Dale

Just a hint without further proof:
I had soffice -quickstart (from LibreOffice) running as
panel app, and had kernel crashes. Since I do not start the
LibreOffice quickstarter anymore, i have a stable system
again.
This is with LibreOffice 3.3.2; OOO330m19 (Build:202) and
WMaker wmsystemtray.

Urs 

Re: [gentoo-user] KDE and HARD lock ups.

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 789 bytes --]

On Wed, 06 Jul 2011 03:08:03 -0500, Dale wrote:

> > It sounds like you need to start with qcheck -aBT and trawl through
> > the output, re-emerging anything questionable.

> This is what I got:
> 
> root@fireball / # qcheck -aBT
> app-office/openoffice
> sys-auth/consolekit
> sys-auth/polkit
> net-nds/openldap
> app-misc/screen
> net-print/cups
> net-print/hplip
> sys-apps/dbus
> sys-apps/openrc
> dev-db/mysql
> kde-base/kdm
> root@fireball / #
> 
You need to check the full output for each package, some of them may be
configuration file changes and re-emerge anything doubtful.

I take it you have done a full fsck and smartctl check of the filesystem
and drive.


-- 
Neil Bothwick

An expert is nothing more than an ordinary person away from home.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-user] KDE and HARD lock ups.

[Peter Ruskin]

On Wednesday 06 July 2011 08:35:04 Neil Bothwick wrote:
> It sounds like you need to start with qcheck -aBT and trawl
> through the output, re-emerging anything questionable.

I don't think I trust the output of that:

# qcheck -aBT
mail-mta/postfix
app-shells/bash
net-fs/nfs-utils
net-fs/samba
app-text/gtkspell
app-text/gnome-doc-utils
app-text/dictd
net-nntp/pan
x11-misc/lineakd
x11-misc/shared-mime-info
x11-themes/hicolor-icon-theme
x11-themes/baghira
sys-fs/udev
dev-libs/libIDL
dev-libs/rasqal
dev-libs/libusb
dev-libs/atk
app-misc/ca-certificates
app-portage/cfg-update
media-fonts/font-alias
x11-libs/libwnck
x11-libs/libXrender
x11-libs/libXdamage
x11-libs/gtksourceview
gnome-base/libgnome-keyring
gnome-base/gnome-keyring
gnome-extra/libgsf
gnome-extra/polkit-gnome
kde-base/networkstatus
kde-base/arts
kde-base/lisa
kde-base/libkdegames
kde-base/akregator
kde-base/ksim
kde-base/kdesdk-kfile-plugins
kde-base/kdepasswd
kde-base/kmenuedit
kde-base/kdepim-kresources
kde-base/libkcal
kde-base/kpf
kde-base/ktnef
kde-base/kdict
kde-base/libkdepim
kde-base/kaddressbook-plugins
kde-base/kdeartwork-styles
kde-base/libkscan
kde-base/karm
kde-base/kworldclock
kde-base/kdm
kde-base/libkmime
kde-base/librss
kde-base/kicker-applets
kde-base/kdemultimedia-kfile-plugins
kde-base/kdemultimedia-kioslaves
kde-base/libkholidays
kde-base/kdvi
kde-base/kate
kde-base/libkpimexchange
kde-base/kfax
kde-base/khexedit
kde-base/khelpcenter
kde-base/libkdenetwork
kde-base/kxkb
kde-base/kdenetwork-kfile-plugins
kde-base/kdf
kde-base/kdegraphics-kfile-plugins
kde-base/konqueror
kde-base/konsole
kde-base/knewsticker
kde-base/kdeadmin-kfile-plugins
kde-base/krfb
kde-base/kget
kde-base/kedit
kde-base/kode
kde-base/ksmserver
kde-base/kmid
kde-base/kompare
kde-base/kviewshell
kde-base/kweather
kde-base/kdenetwork-filesharing
kde-base/kfind
kde-base/kdesdk-misc
kde-base/kate-plugins
kde-base/kdeartwork-kwin-styles
kde-base/kdemultimedia-arts
kde-base/kghostview
kde-base/kregexpeditor
kde-base/mimelib
kde-base/kfilereplace
kde-base/konq-plugins
kde-base/kcharselect
kde-base/konqueror-akregator
kde-base/kdepim-l10n
kde-base/certmanager
kde-base/kdeaddons-kfile-plugins
kde-base/libkpimidentities
kde-base/renamedlg-images
kde-base/kview
kde-base/kdm
kde-base/kdepim-kioslaves
kde-base/libksieve
kde-base/kontact
kde-base/libkonq
kde-base/quanta
media-video/vcdimager
app-office/libreoffice
media-plugins/kipi-plugins
net-print/cups
net-print/hplip
net-print/gutenprint
sys-apps/dbus
sys-apps/usbutils
sys-apps/pciutils
sys-apps/shadow
sys-apps/openrc
sys-apps/baselayout
net-nds/openldap
sys-libs/gdbm
sys-libs/glibc
sys-devel/gcc
sys-devel/binutils
sys-devel/gcc
net-misc/wget
net-misc/ntp
net-misc/openssh
net-libs/libktorrent
dev-db/mariadb
app-cdr/k3b
app-admin/sudo
app-admin/logrotate
app-admin/webmin
app-admin/sysklogd
app-editors/kxmleditor
app-editors/vim-core
sys-auth/polkit-kde-agent
sys-auth/polkit
sys-auth/consolekit
media-gfx/kuickshow
media-gfx/kphotoalbum
media-sound/vorbis-tools
media-sound/awesfx
media-sound/normalize
media-sound/alsa-utils
dev-games/ggz-client-libs
x11-base/xorg-server
media-libs/libexif
media-libs/alsa-oss
media-libs/liblqr
media-libs/fontconfig
media-libs/t1lib
media-libs/libdvdnav
sys-block/gparted

-- 
Peter
========================================================================
Gentoo Linux: Portage 2.2.0_alpha28		kernel-2.6.38-gentoo-r2
AMD Phenom(tm) 9950 Quad-Core Processor		gcc(Gentoo: 4.5.2)
KDE: 3.5.10					Qt: 3.3.8b
========================================================================

Re: [gentoo-user] KDE and HARD lock ups.

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 509 bytes --]

On Wed, 6 Jul 2011 10:36:40 +0100, Peter Ruskin wrote:

> > It sounds like you need to start with qcheck -aBT and trawl
> > through the output, re-emerging anything questionable.  
> 
> I don't think I trust the output of that:
> 
> # qcheck -aBT
[big snip]

It produces false positives and you need to look at the output for each
affected package, but do you know a better way of detecting corruption
of installed files?


-- 
Neil Bothwick

My brain's in gear, neutral's a gear ain't it?

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-user] KDE and HARD lock ups.

[Mick]

[-- Attachment #1: Type: Text/Plain, Size: 754 bytes --]

On Wednesday 06 Jul 2011 10:51:20 Neil Bothwick wrote:
> On Wed, 6 Jul 2011 10:36:40 +0100, Peter Ruskin wrote:
> > > It sounds like you need to start with qcheck -aBT and trawl
> > > through the output, re-emerging anything questionable.
> > 
> > I don't think I trust the output of that:
> > 
> > # qcheck -aBT
> 
> [big snip]
> 
> It produces false positives and you need to look at the output for each
> affected package, but do you know a better way of detecting corruption
> of installed files?

I wasn't familiar with qcheck (yes, I know, I lead a sheltered life!) but 
adding --verbose does not reveal additional info.  When you say "look at the 
output", do you mean the output of emerge -1aDv <package> ?
-- 
Regards,
Mick

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-user] KDE and HARD lock ups.

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 824 bytes --]

On Wed, 6 Jul 2011 11:37:54 +0100, Mick wrote:

> > It produces false positives and you need to look at the output for
> > each affected package, but do you know a better way of detecting
> > corruption of installed files?  
> 
> I wasn't familiar with qcheck (yes, I know, I lead a sheltered life!)
> but adding --verbose does not reveal additional info.  When you say
> "look at the output", do you mean the output of emerge -1aDv <package> ?

The -B option restricts the output to just the names of packages with
changed files. If you feed this list back to qcheck with just the -T
option, you'll get a list of affected files.

qcheck -aBT >foo
qcheck -T $(cat foo)

You may want to pipe the output from the second through grep -v /etc/


-- 
Neil Bothwick

Who messed with my anti-paranoia shot?

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-user] KDE and HARD lock ups.

[Mick]

[-- Attachment #1: Type: Text/Plain, Size: 976 bytes --]

On Wednesday 06 Jul 2011 12:38:22 Neil Bothwick wrote:
> On Wed, 6 Jul 2011 11:37:54 +0100, Mick wrote:
> > > It produces false positives and you need to look at the output for
> > > each affected package, but do you know a better way of detecting
> > > corruption of installed files?
> > 
> > I wasn't familiar with qcheck (yes, I know, I lead a sheltered life!)
> > but adding --verbose does not reveal additional info.  When you say
> > "look at the output", do you mean the output of emerge -1aDv <package> ?
> 
> The -B option restricts the output to just the names of packages with
> changed files. If you feed this list back to qcheck with just the -T
> option, you'll get a list of affected files.
> 
> qcheck -aBT >foo
> qcheck -T $(cat foo)
> 
> You may want to pipe the output from the second through grep -v /etc/

Very useful Neil, thanks!  Most of these files had lockfiles hanging around, 
or some changed config file.
-- 
Regards,
Mick

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-user] KDE and HARD lock ups.

[Tanstaafl]

On 2011-07-06 3:27 AM, Dale wrote:
> But again, it didn't lock up until AFTER I had a power failure. That 
> was when all this started. If I hadn't had the power failure, I may
> not have had the lock ups to begin with. The root of this problem is
> what I am hoping to find.

More than once I have seen power failures damage power supplies, causing
fluctuating voltages that can cause all kinds of weird problems...

I'd try dropping in a new power supply if the memory tests pass, before
giving up...

Re: [gentoo-user] KDE and HARD lock ups.

[Alan McKinnon]

On Wednesday 06 July 2011 03:52:54 Volker Armin Hemmann did opine 
thusly:
> On Tuesday 05 July 2011 15:41:13 Dale wrote:
> 
> update your fucking drivers.

Upset with nVidia perhaps?

> Seriously, no userspace app does something like this. The driver is
> broken, KDE touches the broken part and BOOM.
> 
> Don't blame KDE, blame nvidia.
> 
> And update the driver.

I had reasonable shit with nvidia drivers, especially the bit where it 
doesn't do 2 screens the way I want.

So I switched to -9999 nouveau and now I have endless shit with 
crashes. But I can tolerate that and not whinge.

I freely admit to being biased.


-- 
alan dot mckinnon at gmail dot com

[gentoo-user] Re: KDE and HARD lock ups.

[walt]

On 07/06/2011 01:11 AM, Alan McKinnon wrote:

> 
> So I switched to -9999 nouveau and now I have endless shit with 
> crashes. But I can tolerate that and not whinge.

Just today I tried the nouveau driver again after almost a year, and
found no change.  The test was on my elderly machine with an ancient
GeForce FX 5200.  I'm sure the nouveau devs lost interest in that chip
long ago, so no surprise.

When I run glxgears with the proprietary nvidia driver I get 3000 FPS.
With nouveau I get 54 FPS.

No, that's not a typo.  The proprietary driver is 55 times faster than
nouveau.

What results are you seeing?

Re: [gentoo-user] Re: KDE and HARD lock ups.

[Alan McKinnon]

On Thursday 07 July 2011 14:59:11 walt did opine thusly:
> On 07/06/2011 01:11 AM, Alan McKinnon wrote:
> > So I switched to -9999 nouveau and now I have endless shit with
> > crashes. But I can tolerate that and not whinge.
> 
> Just today I tried the nouveau driver again after almost a year, and
> found no change.  The test was on my elderly machine with an
> ancient GeForce FX 5200.  I'm sure the nouveau devs lost interest
> in that chip long ago, so no surprise.
> 
> When I run glxgears with the proprietary nvidia driver I get 3000
> FPS. With nouveau I get 54 FPS.
> 
> No, that's not a typo.  The proprietary driver is 55 times faster
> than nouveau.
> 
> What results are you seeing?

About 850 FPS or so with glxgears.

IIRC the nVidia driver could go to 2000+ FPS.

This is on a GeForce 8600M GT (NV50 generation). Outright performance 
isn't my main interest, I don't do gaming or video rendering, I hardly 
even watch movies at all on this notebook - YouTube twice a day is 
about the most video stress I exert on it. And the fancy KDE candy 
effects are disabled.

What I'm after is Free Software with KMS. And stable suspend/resume, I 
consider that important. In that regard nouveau easily matches the 
nVidia driver so I'm happy.


-- 
alan dot mckinnon at gmail dot com

Re: [gentoo-user] Re: KDE and HARD lock ups.

[Sebastian Beßler]

[-- Attachment #1: Type: text/plain, Size: 336 bytes --]

Am 07.07.2011 23:59, schrieb walt:

> When I run glxgears with the proprietary nvidia driver I get 3000 FPS.
> With nouveau I get 54 FPS.

That looks for me that nouveau has vsync on and the proprietary is not.
Such a difference should not be if everything is configured and
installed right.

Greetings

Sebastian Beßler


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 900 bytes --]

Re: [gentoo-user] KDE and HARD lock ups.

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 430 bytes --]

On Tue, 5 Jul 2011 15:07:44 -0500, Paul Hartman wrote:

> You can also use nvidia-settings to change the power saving mode at
> run-time, but it does not save it and you must do it every time you
> log into X, which is annoying.

Can't you put nvidia-settings -l in xinitrc or autostart?

That's the official way of loading the settings at login.


-- 
Neil Bothwick

I wouldn't be caught dead with a necrophiliac.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-user] KDE and HARD lock ups.

[Paul Hartman]

On Tue, Jul 5, 2011 at 6:04 PM, Neil Bothwick <neil@digimed.co.uk> wrote:
> On Tue, 5 Jul 2011 15:07:44 -0500, Paul Hartman wrote:
>
>> You can also use nvidia-settings to change the power saving mode at
>> run-time, but it does not save it and you must do it every time you
>> log into X, which is annoying.
>
> Can't you put nvidia-settings -l in xinitrc or autostart?
>
> That's the official way of loading the settings at login.

If I remember, this option could not be set by commandline, only by
the nvidia-settings GUI. Maybe it has been added since then.

Re: [gentoo-user] KDE and HARD lock ups.

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 868 bytes --]

On Tue, 5 Jul 2011 18:14:52 -0500, Paul Hartman wrote:

> > Can't you put nvidia-settings -l in xinitrc or autostart?
> >
> > That's the official way of loading the settings at login.  
> 
> If I remember, this option could not be set by commandline, only by
> the nvidia-settings GUI. Maybe it has been added since then.

When you quit the GUI, the settings are supposed to be saved to
~/.nvidia-settings-rc and loaded from there when you load the GUI. The -l
switch tells nvidia-settings to load the settings from that file and
quit, so it should do what you need.

The settings file is plain text, so it's easy to see whether the setting
you want is saved there, it may even be possible to add it manually,
although that rather defeats the object of a GUI.


-- 
Neil Bothwick

Eye of newt, toe of frog, regular Coke and fries to go, please.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-user] KDE and HARD lock ups.

[Paul Hartman]

On Tue, Jul 5, 2011 at 6:49 PM, Neil Bothwick <neil@digimed.co.uk> wrote:
> On Tue, 5 Jul 2011 18:14:52 -0500, Paul Hartman wrote:
>
>> > Can't you put nvidia-settings -l in xinitrc or autostart?
>> >
>> > That's the official way of loading the settings at login.
>>
>> If I remember, this option could not be set by commandline, only by
>> the nvidia-settings GUI. Maybe it has been added since then.
>
> When you quit the GUI, the settings are supposed to be saved to
> ~/.nvidia-settings-rc and loaded from there when you load the GUI. The -l
> switch tells nvidia-settings to load the settings from that file and
> quit, so it should do what you need.
>
> The settings file is plain text, so it's easy to see whether the setting
> you want is saved there, it may even be possible to add it manually,
> although that rather defeats the object of a GUI.

Unfortunately those settings are not saved in the file by the GUI, but
if they were it would have been easy as you described. :)

Re: [gentoo-user] KDE and HARD lock ups.

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 1011 bytes --]

On Tue, 5 Jul 2011 23:19:00 -0500, Paul Hartman wrote:

> > When you quit the GUI, the settings are supposed to be saved to
> > ~/.nvidia-settings-rc and loaded from there when you load the GUI.
> > The -l switch tells nvidia-settings to load the settings from that
> > file and quit, so it should do what you need.
> >
> > The settings file is plain text, so it's easy to see whether the
> > setting you want is saved there, it may even be possible to add it
> > manually, although that rather defeats the object of a GUI.  
> 
> Unfortunately those settings are not saved in the file by the GUI, but
> if they were it would have been easy as you described. :)

So the man page should be updated to state "When nvidia-settings exits,
it queries the current settings from the X server and saves SOME OF them
to the configuration file." :(


-- 
Neil Bothwick

Programming Language: (n.) a shorthand way of describing a series of bugs
                      to a computer or a programmer.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-user] KDE and HARD lock ups.

[Volker Armin Hemmann]

On Monday 04 July 2011 11:48:51 Dale wrote:
> Hi,
> Has anyone else had any hard lock ups in KDE?   I'm on kde 4.6.4 whichwas 
released about a month ago.  For those not in the know, I'm on amd64and use 
kde-meta so it is has the kitchen sink installed here.
> What mine does:  It sort of varies but usually when I login, it may lasta 
couple minutes, usually less, then the Caps Lock and Scroll Lock LED'sblink.  
The Num Lock key is off if that means anything.  I tried theSysReq keys but it 
doesn't do anything at all.  According to themessages at the next boot, it 
doesn't sync or umount either.  The mousepointer no longer moves either.  At 
this point, I hit the reset buttonwhich causes steam to come out my ears.  I 
HATE using that button.
> I'm fairly sure this is not hardware.  Right now, I am in Fluxbox and 
itworks fine.  I also booted to single user and compiled a bunch of stuffand 
also tried a different kernel too.  I think if it was hardware, itwould have 
had some kind of hick-up during the compile.  I did checktemps and all is nice 
and cool, very cool since my A/C is on fullblast.  I think the oven is outside 
on full blast instead of in thekitchen.  lol  It's HOT here, steamy hot.
> I checked messages and the only thing I saw was about a bad option forhp-
systray.  Surely that wouldn't cause a crash?  I'm going to unmergeand test it 
tho, just to be sure.
> Anyone run into something like this?  Ideas?
> Thanks much.
> Dale
> :-)  :-)

I only had lockups thanks to USB which haven't occured since I switched to 
2.6.39.2

-- 
#163933