[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

HD shutdown revisited



I posted a message regarding this several months ago, got some replies,
among which was to install smartmontools, which I did.  Again, I know
this is OT for Debian, but I'm a bit baffled.

I've again experienced a strange shutdown of my HD. At about 5:30 AM
this morning, my HD suddenly shut down.  It clicked (as it always does
when the computer shuts down), and then the HD light kept blinking and
the computer was totally locked.  I let it continue like this for
perhaps 15 minutes.  I press CTRL-ALT-F2 (holding it for several
seconds) and waited for several minutes after this to give it time to
possibly detect the keystroke, but it never did change to a terminal.

I finally hit the power switch.

I intended to leave it alone till I returned from work this afternoon,
hoping it might cool down, but couldn't resist seeing what it would do.
When I powered it back on (a few minutes later), it booted fine.

There was no entry in kern.log for this incident, but I did have this
one for earlier this morning:

Feb 21 00:46:23 localhost kernel: hda: status timeout: status=0x80 {
    Busy }
Feb 21 00:46:23 localhost kernel: 
Feb 21 00:46:23 localhost kernel: hda: DMA disabled
Feb 21 00:46:23 localhost kernel: hda: drive not ready for command
Feb 21 00:46:23 localhost kernel: Inbound IN=ppp0 OUT= MAC=
    SRC=66.38.104.7 DST=66.38.12.128 LEN=48 TOS=0x00 PREC=0x00 TTL=122
    ID=5164 DF PROTO=TCP SPT=4635 DPT=445 WINDOW=64240 RES=0x00 SYN URGP=0 
Feb 21 00:46:26 localhost kernel: ide0: reset: success

This is a similar thing to what had happened to me previously, ( perhaps
6 months ago), but my kern.logs go back to Sept 17, and no other of
these reports show up in any of them back to then.  I don't run smartmon
as a daemon, but on every run of the tool, the HD returned a clean bill
of health.

One thing that strikes me as being rather peculiar in the log entry
above.  According to the log, the HD "died" at 00:46:23, and was revived
at 00:46:26, but during the interval between the time it died and was
revived, it was able to write the entry for the iptables log?  Or is
this a result of cacheing and written during a sync operation?  Hmmm,
unless it was written after it was revived, how was it able to write to
a "dead" disk that it _was_ dead?  (this log is written on hda, the
"dead" disk).  The fact that the system is frozen during the disk
disablement is a bit confusing, unless the CPU _is_ halted during the
whole thing.



Reply to: