FF10 shutdown trap 8

[Dave Saville]

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 Yeo]

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]

On Mon, 8 Oct 2012 14:42:28 UTC, Dave Yeo <dave....@gmail.com>
wrote:

Yup whole system. Diags such as? All partitions are JFS and boot
chkdsk runs clean.

--
Regards
Dave Saville

[Dave Yeo]

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

[Dave Saville]

On Mon, 8 Oct 2012 16:15:35 UTC, Dave Yeo <dave....@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

[Lars Erdmann]

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.


Lars



"Dave Saville" <da...@invalid.invalid> schrieb im Newsbeitrag
news:fV45K0OBJxbE-pn2-gnxytVQsMF1S@localhost...

[Peter Brown]

Hi Dave

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.


Regards

Pete

[Dave Saville]

On Mon, 8 Oct 2012 16:59:29 UTC, "Lars Erdmann"
<lars.e...@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.

--
Regards
Dave Saville

[Dave Saville]

On Mon, 8 Oct 2012 18:41:47 UTC, Peter Brown
<losepeteS...@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.


--
Regards
Dave Saville

[Doug Bissett]

On Mon, 8 Oct 2012 19:36:42 UTC, "Dave Saville" <da...@invalid.invalid>
wrote:

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)

[Lewis Rosenthal]

Hi, Dave...

On 10/08/12 03:34 pm, Dave Saville thus wrote :

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

[Dave Saville]

On Tue, 9 Oct 2012 02:48:20 UTC, "Doug Bissett"
<dougb007!SP...@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.
--
Regards
Dave Saville

[Dave Saville]

On Tue, 9 Oct 2012 04:13:37 UTC, Lewis Rosenthal
<lgros...@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.
--
Regards
Dave Saville

[Bob]

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.

[Doug Bissett]

On Tue, 9 Oct 2012 08:44:56 UTC, "Dave Saville" <da...@invalid.invalid>
wrote:

> On Tue, 9 Oct 2012 04:13:37 UTC, Lewis Rosenthal
> <lgros...@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.

[Doug Bissett]

On Tue, 9 Oct 2012 08:35:20 UTC, "Dave Saville" <da...@invalid.invalid>
wrote:

Too bad. That would be the easy fix.

[Steve Wendt]

On 10/09/12 11:36 am, Bob wrote:

> When we install LIBC065 it installs forwarding DLL's for all the
> previous LIBC's. Try installing the actual DLL's from old archives.

There have been tales of that causing strange problems - YMMV.

[Dave Saville]

On Tue, 9 Oct 2012 19:54:54 UTC, "Doug Bissett"
<dougb007!SP...@telus.net> wrote:

<snip>

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

--
Regards
Dave Saville

[Dave Yeo]

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

[Dave Saville]

On Thu, 18 Oct 2012 03:59:03 UTC, Dave Yeo <dave....@gmail.com>
wrote:

<snip>

> 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

Sector Reference Size of area Containing

======== ============ ================= ==========

00000000 none 000001 = 0.5 KiB Fsys boot sector 800000

- Filesystem is marked DIRTY or MOUNTED (in use)

002619C8 none 000008 = 4.0 KiB Unidentified data 000002

- Allocation set but area not in FS-administration



Total errors/warnings detected: 2




--
Regards
Dave Saville