FF crashed my system last night when I shut FF down. A number of files
ended up as zero length which made the start up this morning a bit of a surprise as all customisation had gone.
-rw-rw-rw- 1 root 0 0 Oct 7 18:55 session.rdf
-rw-rw-rw- 1 root 0 0 Oct 7 18:55 prefs.js
-rw-rw-rw- 1 root 0 0 Oct 7 18:55 NoScriptSTS.db
-rw-rw-rw- 1 root 0 0 Oct 7 18:55 localstore.rdf
Luckily all was backed up. :-)
Sorry I did not record the trap info.
-- Regards
Dave Saville
Dave Saville wrote:
> FF crashed my system last night when I shut FF down. A number of files
> ended up as zero length which made the start up this morning a bit of
> a surprise as all customisation had gone.
> -rw-rw-rw- 1 root 0 0 Oct 7 18:55 session.rdf
> -rw-rw-rw- 1 root 0 0 Oct 7 18:55 prefs.js
> -rw-rw-rw- 1 root 0 0 Oct 7 18:55 NoScriptSTS.db
> -rw-rw-rw- 1 root 0 0 Oct 7 18:55 localstore.rdf
> Luckily all was backed up. :-)
> Sorry I did not record the trap info.
You mean you're whole system trapped? Sounds like hardware issues with your Hard drive, which would also explain your shutdown problems. I'd suggest running some diagnostics on it.
Dave
> Dave Saville wrote:
> > FF crashed my system last night when I shut FF down. A number of files
> > ended up as zero length which made the start up this morning a bit of
> > a surprise as all customisation had gone.
> You mean you're whole system trapped? Sounds like hardware issues with > your Hard drive, which would also explain your shutdown problems. I'd > suggest running some diagnostics on it.
Yup whole system. Diags such as? All partitions are JFS and boot chkdsk runs clean.
Dave Saville wrote:
> On Mon, 8 Oct 2012 14:42:28 UTC, Dave Yeo<dave.r....@gmail.com>
> wrote:
>> Dave Saville wrote:
>>> FF crashed my system last night when I shut FF down. A number of files
>>> ended up as zero length which made the start up this morning a bit of
>>> a surprise as all customisation had gone.
>>> -rw-rw-rw- 1 root 0 0 Oct 7 18:55 session.rdf
>>> -rw-rw-rw- 1 root 0 0 Oct 7 18:55 prefs.js
>>> -rw-rw-rw- 1 root 0 0 Oct 7 18:55 NoScriptSTS.db
>>> -rw-rw-rw- 1 root 0 0 Oct 7 18:55 localstore.rdf
>>> Luckily all was backed up. :-)
>>> Sorry I did not record the trap info.
>> You mean you're whole system trapped? Sounds like hardware issues with
>> your Hard drive, which would also explain your shutdown problems. I'd
>> suggest running some diagnostics on it.
> Yup whole system. Diags such as? All partitions are JFS and boot
> chkdsk runs clean.
There are a couple of smart programs, notably the one that comes with danis506.add, SmartCtl.exe. You might need to enable smart in your bios.
Dave
On Mon, 8 Oct 2012 16:15:35 UTC, Dave Yeo <dave.r....@gmail.com> wrote:
<snip>
> There are a couple of smart programs, notably the one that comes with > danis506.add, SmartCtl.exe. You might need to enable smart in your bios.
> Dave
Was enabled.
smartctl -a hdo
Clean. The only errors are to do with security at boot:
SECURITY UNLOCK
IDENTIFY DEVICE
Ran both short and long tests and they ran clean.
-- Regards
Dave Saville
disable "Quick boot" in BIOS (that is: go through lengthy boot with some memory read/write tests being executed by BIOS).
At one point in time I did this change on my system and that seemed to help some strange HW problems I was experiencing.
> FF crashed my system last night when I shut FF down. A number of files
> ended up as zero length which made the start up this morning a bit of
> a surprise as all customisation had gone.
> -rw-rw-rw- 1 root 0 0 Oct 7 18:55 session.rdf
> -rw-rw-rw- 1 root 0 0 Oct 7 18:55 prefs.js
> -rw-rw-rw- 1 root 0 0 Oct 7 18:55 NoScriptSTS.db
> -rw-rw-rw- 1 root 0 0 Oct 7 18:55 localstore.rdf
> Luckily all was backed up. :-)
> Sorry I did not record the trap info.
> -- > Regards
> Dave Saville
Dave Saville wrote:
> On Mon, 8 Oct 2012 14:42:28 UTC, Dave Yeo<dave.r....@gmail.com>
> wrote:
>> Dave Saville wrote:
>>> FF crashed my system last night when I shut FF down. A number of files
>>> ended up as zero length which made the start up this morning a bit of
>>> a surprise as all customisation had gone.
>>> -rw-rw-rw- 1 root 0 0 Oct 7 18:55 session.rdf
>>> -rw-rw-rw- 1 root 0 0 Oct 7 18:55 prefs.js
>>> -rw-rw-rw- 1 root 0 0 Oct 7 18:55 NoScriptSTS.db
>>> -rw-rw-rw- 1 root 0 0 Oct 7 18:55 localstore.rdf
>>> Luckily all was backed up. :-)
>>> Sorry I did not record the trap info.
>> You mean you're whole system trapped? Sounds like hardware issues with
>> your Hard drive, which would also explain your shutdown problems. I'd
>> suggest running some diagnostics on it.
> Yup whole system. Diags such as? All partitions are JFS and boot
> chkdsk runs clean.
If by "boot chkdsk" you mean the standard chkdsk at boot then you cannot rely on that. I think it simply checks the logs and if they are clean it presumes that disk is OK. If you have had a system crash there is a good chance that the logs show as clean but the filesystem is dirty.
I suggest changing the ifs=jfs... line to force a chkdsk at boot eg:-
IFS=L:\OS2\JFS.IFS /LW:5,20,4 /AUTOCHECK:+*
The above will force a full chkdsk on every jfs drive at boot.
> disable "Quick boot" in BIOS (that is: go through lengthy boot with some > memory read/write tests being executed by BIOS).
> At one point in time I did this change on my system and that seemed to help > some strange HW problems I was experiencing.
> If by "boot chkdsk" you mean the standard chkdsk at boot then you cannot > rely on that. I think it simply checks the logs and if they are clean it > presumes that disk is OK. If you have had a system crash there is a good > chance that the logs show as clean but the filesystem is dirty.
> I suggest changing the ifs=jfs... line to force a chkdsk at boot eg:-
> IFS=L:\OS2\JFS.IFS /LW:5,20,4 /AUTOCHECK:+*
> The above will force a full chkdsk on every jfs drive at boot.
I tried that once. Given the number of times I have to reboot every day it takes too long. :-) In any case SMART reports no significant errors - see other reply.
> On Mon, 8 Oct 2012 18:41:47 UTC, Peter Brown > <losepeteSPAM-ME-...@ntlworld.com> wrote:
> <snip>
> > If by "boot chkdsk" you mean the standard chkdsk at boot then you cannot > > rely on that. I think it simply checks the logs and if they are clean it > > presumes that disk is OK. If you have had a system crash there is a good > > chance that the logs show as clean but the filesystem is dirty.
> > I suggest changing the ifs=jfs... line to force a chkdsk at boot eg:-
> > IFS=L:\OS2\JFS.IFS /LW:5,20,4 /AUTOCHECK:+*
> > The above will force a full chkdsk on every jfs drive at boot.
> I tried that once. Given the number of times I have to reboot every > day it takes too long. :-) In any case SMART reports no significant > errors - see other reply.
I agree with peter. You can do it his way (once, then put it back to the way it is), or you can use an alternate boot system, and do it that way. You cannot always depend on the "normal" boot time CHKDSK with JFS. It does work good, almost always, but there are times when it misses problems, and this sounds like it is probably one of those times, and you need to force a full CHKDSK to run (one way or another).
SMART is something completely different. All that does, is return the hardware monitor data that is held in the drive. It knows nothing about file systems, and problems that may develop in the data that is written to the disk. All it knows is that the data got written, not that it was the proper data.
-- From the eComStation of Doug Bissett
dougb007 at telus dot net
(Please make the obvious changes, to e-mail me)
> On Mon, 8 Oct 2012 16:59:29 UTC, "Lars Erdmann" > <lars.erdm...@arcor.de> wrote:
>> Just a guess,
>> disable "Quick boot" in BIOS (that is: go through lengthy boot with some >> memory read/write tests being executed by BIOS).
>> At one point in time I did this change on my system and that seemed to help >> some strange HW problems I was experiencing.
> Memtest86 runs clean.
This is good news. Sometimes, these things just happen. Don't rule out
other boards/devices which may have had interrupts left hot, as these
can cause trap 8's.
I'm not sure of your current partition layout, but on the web server
over here, to speed booting, I specifically bypass chkdsk on unessential
volumes (unessential = not necessary to restore normal web services),
and then run a regular chkdsk /f pass against each volume from the
Startup folder. This allows the system to get started without waiting
for an agonizingly (usually) long chkdsk during boot (because when the
server crashes, usually the JFS journal is trashed, leading to a 5-7
step chkdsk pass - doing that on one necessary volume is bad enough (the
boot volume is HPFS, and considerably smaller; this leads to a faster
chkdsk pass on that than on the much larger JFS "apps" volume).
Anyway, none of this will fix your problem (if you actually do have
one). You might want to just do the regular routine of reseating memory,
drive, and so forth (I know the diagnostics have been clean). Of course,
you know all of this stuff, anyway. I'm just thinking out loud, wasting
electrons. ;-)
I do hope it's nothing serious.
GL
-- Lewis
-------------------------------------------------------------
Lewis G Rosenthal, CNA, CLP, CLE, CWTS
Rosenthal & Rosenthal, LLC www.2rosenthals.com Need a managed Wi-Fi hotspot? www.hautspot.com visit my IT blog www.2rosenthals.net/wordpress -------------------------------------------------------------
> I agree with peter. You can do it his way (once, then put it back to > the way it is), or you can use an alternate boot system, and do it > that way. You cannot always depend on the "normal" boot time CHKDSK > with JFS. It does work good, almost always, but there are times when > it misses problems, and this sounds like it is probably one of those > times, and you need to force a full CHKDSK to run (one way or > another).
> SMART is something completely different. All that does, is return the > hardware monitor data that is held in the drive. It knows nothing > about file systems, and problems that may develop in the data that is > written to the disk. All it knows is that the data got written, not > that it was the proper data.
Well after a 5 minute boot time - clean as I thought it would be.
-- Regards
Dave Saville
> This is good news. Sometimes, these things just happen. Don't rule out
> other boards/devices which may have had interrupts left hot, as these
> can cause trap 8's.
> I'm not sure of your current partition layout, but on the web server
> over here, to speed booting, I specifically bypass chkdsk on unessential
> volumes (unessential = not necessary to restore normal web services),
> and then run a regular chkdsk /f pass against each volume from the
> Startup folder. This allows the system to get started without waiting
> for an agonizingly (usually) long chkdsk during boot (because when the
> server crashes, usually the JFS journal is trashed, leading to a 5-7
> step chkdsk pass - doing that on one necessary volume is bad enough (the
> boot volume is HPFS, and considerably smaller; this leads to a faster
> chkdsk pass on that than on the much larger JFS "apps" volume).
This is my laptop. With all the crashes I have ever had on all systems
I don't recall ever getting a long chkdsk pass on reboot. Disk completely dead yes, but that's a whole different problem. :-)
> Anyway, none of this will fix your problem (if you actually do have
> one). You might want to just do the regular routine of reseating memory,
> drive, and so forth (I know the diagnostics have been clean). Of course,
> you know all of this stuff, anyway. I'm just thinking out loud, wasting
> electrons. ;-)
Drive has been out before I ran all the tests as I split a drink! No damage, it did not get past the keyboard. I very quickly turned the laptop upside down and killed the power. And being a laptop there is not a lot to reseat anyway.
I don't think it is hardware. In fact I suspect a screw up in the C runtime. So many programs seem to have problems since LIBC065 came along. Steve L does not agree with me, but I don't recall having the kind of problems I see now when LIBC063 was at the end of the chain.
Like Apache always dumping when you kill it, hangs, unkillable programs etc.
-- Regards
Dave Saville
When we install LIBC065 it installs forwarding DLL's for all the previous LIBC's. Try installing the actual DLL's from old archives. Of course that won't affect any LIBC065 calls. I have certainly been caught by stray DLL's in the past so an audit of the disk for LIBC's would certainly be worthwhile. Maybe use PSTAT to see what's loaded. Watch out for interaction between different Moz products, they will share DLL's if you let them.
Dave Saville wrote:
> On Tue, 9 Oct 2012 04:13:37 UTC, Lewis Rosenthal > <lgrosent...@2-de-sp-am-2rosenthals.com> wrote:
> <snip>
>> This is good news. Sometimes, these things just happen. Don't rule out
>> other boards/devices which may have had interrupts left hot, as these
>> can cause trap 8's.
>> I'm not sure of your current partition layout, but on the web server
>> over here, to speed booting, I specifically bypass chkdsk on unessential
>> volumes (unessential = not necessary to restore normal web services),
>> and then run a regular chkdsk /f pass against each volume from the
>> Startup folder. This allows the system to get started without waiting
>> for an agonizingly (usually) long chkdsk during boot (because when the
>> server crashes, usually the JFS journal is trashed, leading to a 5-7
>> step chkdsk pass - doing that on one necessary volume is bad enough (the
>> boot volume is HPFS, and considerably smaller; this leads to a faster
>> chkdsk pass on that than on the much larger JFS "apps" volume).
> This is my laptop. With all the crashes I have ever had on all systems
> I don't recall ever getting a long chkdsk pass on reboot. Disk > completely dead yes, but that's a whole different problem. :-)
>> Anyway, none of this will fix your problem (if you actually do have
>> one). You might want to just do the regular routine of reseating memory,
>> drive, and so forth (I know the diagnostics have been clean). Of course,
>> you know all of this stuff, anyway. I'm just thinking out loud, wasting
>> electrons. ;-)
> Drive has been out before I ran all the tests as I split a drink! No > damage, it did not get past the keyboard. I very quickly turned the > laptop upside down and killed the power. And being a laptop there is > not a lot to reseat anyway.
> I don't think it is hardware. In fact I suspect a screw up in the C > runtime. So many programs seem to have problems since LIBC065 came > along. Steve L does not agree with me, but I don't recall having the > kind of problems I see now when LIBC063 was at the end of the chain.
> Like Apache always dumping when you kill it, hangs, unkillable > programs etc.
> On Tue, 9 Oct 2012 04:13:37 UTC, Lewis Rosenthal > <lgrosent...@2-de-sp-am-2rosenthals.com> wrote:
> <snip>
> > This is good news. Sometimes, these things just happen. Don't rule out
> > other boards/devices which may have had interrupts left hot, as these
> > can cause trap 8's.
> > I'm not sure of your current partition layout, but on the web server
> > over here, to speed booting, I specifically bypass chkdsk on unessential
> > volumes (unessential = not necessary to restore normal web services),
> > and then run a regular chkdsk /f pass against each volume from the
> > Startup folder. This allows the system to get started without waiting
> > for an agonizingly (usually) long chkdsk during boot (because when the
> > server crashes, usually the JFS journal is trashed, leading to a 5-7
> > step chkdsk pass - doing that on one necessary volume is bad enough (the
> > boot volume is HPFS, and considerably smaller; this leads to a faster
> > chkdsk pass on that than on the much larger JFS "apps" volume).
> This is my laptop. With all the crashes I have ever had on all systems
> I don't recall ever getting a long chkdsk pass on reboot. Disk > completely dead yes, but that's a whole different problem. :-)
I see a long CHKDSK, about once in 200 crashes, depending on what went
wrong -AHCI crashing, was the worst, but that problem is fixed now (AHCI 1.24).
> > Anyway, none of this will fix your problem (if you actually do have
> > one). You might want to just do the regular routine of reseating memory,
> > drive, and so forth (I know the diagnostics have been clean). Of course,
> > you know all of this stuff, anyway. I'm just thinking out loud, wasting
> > electrons. ;-)
> Drive has been out before I ran all the tests as I split a drink! No > damage, it did not get past the keyboard. I very quickly turned the > laptop upside down and killed the power. And being a laptop there is > not a lot to reseat anyway.
True, but it depends on what the keyboard design is, whether liquids will get past it, or not. If there is a membrane behind it, it would probably stop almost everything. If there isn't, and you got unlucky, the fan may not be turning at full speed, when necessary, or a ball of
dust will be stuck onto something that is getting hot. Some laptops (notably IBM, or Lenovo) suck cool air in through the keyboard, and there is no membrane. Others like Toshiba, suck cool air through the bottom of the machine, which is easy to block by simply placing the machine on a table cloth (not sure if it has a membrane, or not). A friend of mine had a Toshiba (using windows Vista), and it spent a lot
of time crashing. It was also very slow. After doing some investigating, it was obvious that the fan was roaring away, but everything (including the keyboard), was HOT to the touch after a while. There is an air channel to direct the hot air from the processor, to the outside of the box. That was blocked by dust (one relatively small dust bunny), and it was not easy to clean it out. The
machine ran a whole lot better after cleaning it though.
> I don't think it is hardware. In fact I suspect a screw up in the C > runtime. So many programs seem to have problems since LIBC065 came > along. Steve L does not agree with me, but I don't recall having the > kind of problems I see now when LIBC063 was at the end of the chain.
> Like Apache always dumping when you kill it, hangs, unkillable > programs etc.
To be honest, I have seen fewer problems with LIBC065, than I did with
LIBC064. LIBC063 seemed to work pretty good, and LIBC065 seems to be about the same, for me. My second guess (since the disk passes CHKDSK), would be that something is overheating. Most laptops have automatic slowdown to stop it from melting down in hot weather, but they can still get hot enough to cause trouble if the air flow is partly blocked.
-- From the eComStation of Doug Bissett
dougb007 at telus dot net
(Please make the obvious changes, to e-mail me)
> On Tue, 9 Oct 2012 02:48:20 UTC, "Doug Bissett" > <dougb007!S...@telus.net> wrote:
> <snip>
> > I agree with peter. You can do it his way (once, then put it back to > > the way it is), or you can use an alternate boot system, and do it > > that way. You cannot always depend on the "normal" boot time CHKDSK > > with JFS. It does work good, almost always, but there are times when > > it misses problems, and this sounds like it is probably one of those > > times, and you need to force a full CHKDSK to run (one way or > > another).
> > SMART is something completely different. All that does, is return the > > hardware monitor data that is held in the drive. It knows nothing > > about file systems, and problems that may develop in the data that is > > written to the disk. All it knows is that the data got written, not > > that it was the proper data.
> Well after a 5 minute boot time - clean as I thought it would be.
Too bad. That would be the easy fix.
-- From the eComStation of Doug Bissett
dougb007 at telus dot net
(Please make the obvious changes, to e-mail me)
> To be honest, I have seen fewer problems with LIBC065, than I did with
> LIBC064. LIBC063 seemed to work pretty good, and LIBC065 seems to be > about the same, for me. My second guess (since the disk passes > CHKDSK), would be that something is overheating. Most laptops have > automatic slowdown to stop it from melting down in hot weather, but > they can still get hot enough to cause trouble if the air flow is > partly blocked.
New fan actually - old one was starting to make a noise.
> On Mon, 8 Oct 2012 16:15:35 UTC, Dave Yeo<dave.r....@gmail.com>
> wrote:
> <snip>
>> There are a couple of smart programs, notably the one that comes with
>> danis506.add, SmartCtl.exe. You might need to enable smart in your bios.
>> Dave
> Was enabled.
> smartctl -a hdo
> Clean. The only errors are to do with security at boot:
> SECURITY UNLOCK
> IDENTIFY DEVICE
> Ran both short and long tests and they ran clean.
Possibly related. The other day Thunderbird threw up an error about not being able to write to my profile. Couldn't see anything wrong so I ran chkdsk which removed my inbox (forget the actual error).
So I restored from a backup, losing a few mails :( and continued on.
Over the next couple of days Thunderbird seemed slow and now and again it would throw up an error about filtering messages to folders, suggesting that I delete inbox.msf which I would do.
Eventually it hung bad forcing a reboot, I ran chkdsk again and once again it deleted inbox. Smart didn't find anything wrong with the disk, chkdsk only ever complained about inbox the 2 times so I used DFsee to check the JFS partition. It found 600+ errors that it didn't fix. So at this point I long formatted the partition, restored the profiles and Thunderbird has been behaving since.
You might want to backup and long format your profile partition to see if that helps.
Dave
> Possibly related. The other day Thunderbird threw up an error about not > being able to write to my profile. Couldn't see anything wrong so I ran > chkdsk which removed my inbox (forget the actual error).
> So I restored from a backup, losing a few mails :( and continued on.
> Over the next couple of days Thunderbird seemed slow and now and again > it would throw up an error about filtering messages to folders, > suggesting that I delete inbox.msf which I would do.
> Eventually it hung bad forcing a reboot, I ran chkdsk again and once > again it deleted inbox. Smart didn't find anything wrong with the disk, > chkdsk only ever complained about inbox the 2 times so I used DFsee to > check the JFS partition. It found 600+ errors that it didn't fix. So at > this point I long formatted the partition, restored the profiles and > Thunderbird has been behaving since.
> You might want to backup and long format your profile partition to see > if that helps.
Hi Dave
No cigar :-(
Display Sector Lookup Table in verbose format.
114967 of 399456 at 0 show Errors matching: 0xFFFFFF
