Re: [gentoo-user] Re: Firefox and kernel panics.
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 signature.asc Description: PGP signature
Re: [gentoo-user] Re: Firefox and kernel panics.
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.
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 signature.asc Description: PGP signature
Re: [gentoo-user] Re: Firefox and kernel panics.
On Wed, Jul 13, 2011 at 10:31 PM, Dale rdalek1...@gmail.com wrote: I'm baakk. 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.
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 ww...@math.princeton.edu Data aequatione quotcunque fluentes quantitae involvente fluxiones invenire et vice versa ~~~ I. Newton
Re: [gentoo-user] Re: Firefox and kernel panics.
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.
On Thu, Jul 14, 2011 at 7:54 AM, Willie Wong ww...@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.
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 signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] Re: Firefox and kernel panics.
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.
On Thu, Jul 14, 2011 at 05:28, Dale rdalek1...@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
Re: [gentoo-user] Re: Firefox and kernel panics.
On Thu, Jul 14, 2011 at 9:06 AM, Peter Humphrey pe...@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.
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.
I'm baakk. 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.
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 wrote: Yea, that does sound familiar. Trying to recall who could have had that problem. H. 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.
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 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.
2011/7/11 Dale rdalek1...@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.
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 ~ signature.asc Description: PGP signature
Re: [gentoo-user] Re: Firefox and kernel panics.
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. signature.asc Description: PGP signature
Re: [gentoo-user] Re: Firefox and kernel panics.
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.
On Sun, Jul 10, 2011 at 10:03 PM, Dale rdalek1...@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. H. 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.
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. signature.asc Description: PGP signature
Re: [gentoo-user] Re: Firefox and kernel panics.
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.
On Mon, Jul 11, 2011 at 6:45 AM, Neil Bothwick n...@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.
On Mon, Jul 11, 2011 at 7:17 AM, Michael Orlitzky mich...@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.
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.
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.
Jesús J. Guerrero Botella wrote: 2011/7/11 Dalerdalek1...@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.
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. signature.asc Description: PGP signature
Re: [gentoo-user] Re: Firefox and kernel panics.
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. signature.asc Description: PGP signature
Re: [gentoo-user] Re: Firefox and kernel panics.
Mark Knecht wrote:
On Sun, Jul 10, 2011 at 10:03 PM, Dalerdalek1...@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. H. 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 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 :-) :-)
Re: [gentoo-user] Re: Firefox and kernel panics.
On Mon, Jul 11, 2011 at 2:00 PM, Neil Bothwick n...@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.
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 :-) :-)
[gentoo-user] Re: Firefox and kernel panics.
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.
Mark Knecht wrote: On Mon, Jul 11, 2011 at 2:00 PM, Neil Bothwickn...@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.
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.
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.
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! signature.asc Description: PGP signature
[gentoo-user] Re: Firefox and kernel panics.
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.
Joshua Murphy wrote: On Sat, Jul 9, 2011 at 11:31 PM, Dalerdalek1...@gmail.com wrote: Mark Knecht wrote: On Sat, Jul 9, 2011 at 6:36 PM, Dalerdalek1...@gmail.comwrote: 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 whsh. 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.
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 whsh. 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 ww...@math.princeton.edu Data aequatione quotcunque fluentes quantitae involvente fluxiones invenire et vice versa ~~~ I. Newton
Re: [gentoo-user] Re: Firefox and kernel panics.
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.
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. signature.asc Description: PGP signature
Re: [gentoo-user] Re: Firefox and kernel panics.
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 :-) :-)
Re: [gentoo-user] Re: Firefox and kernel panics.
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.
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. signature.asc Description: PGP signature
Re: [gentoo-user] Re: Firefox and kernel panics.
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
[gentoo-user] Re: Firefox and kernel panics.
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.
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.
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 :-) :-)
Re: [gentoo-user] Re: Firefox and kernel panics.
On Sun, Jul 10, 2011 at 5:27 PM, Dale rdalek1...@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, 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 markkne...@gmail.com wrote: On Sun, Jul 10, 2011 at 5:27 PM, Dale rdalek1...@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 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. H. 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.
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.
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.
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 signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] Re: Firefox and kernel panics.
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.
On 9 July 2011 03:49, Dale rdalek1...@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.
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. signature.asc Description: PGP signature
Re: [gentoo-user] Re: Firefox and kernel panics.
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 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 :-) :-)
[gentoo-user] Re: Firefox and kernel panics.
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.
Re: [gentoo-user] Re: Firefox and kernel panics.
On Sat, Jul 9, 2011 at 9:18 AM, Dale rdalek1...@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
[gentoo-user] Re: Firefox and kernel panics.
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: Firefox and kernel panics.
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.
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.
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.
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.
On Sat, Jul 9, 2011 at 3:26 PM, Dale rdalek1...@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.
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.
On Sat, Jul 9, 2011 at 4:55 PM, Dale rdalek1...@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.
Mark Knecht wrote: On Sat, Jul 9, 2011 at 4:55 PM, Dalerdalek1...@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.
On Sat, Jul 9, 2011 at 6:36 PM, Dale rdalek1...@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.
Mark Knecht wrote: On Sat, Jul 9, 2011 at 6:36 PM, Dalerdalek1...@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.
On Sat, Jul 9, 2011 at 11:31 PM, Dale rdalek1...@gmail.com wrote: Mark Knecht wrote: On Sat, Jul 9, 2011 at 6:36 PM, Dalerdalek1...@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
