Hey, guys.
On Sat, Sep 28, 2013 at 11:11:01PM -0400, Wakko Warner wrote:
> [ 493.612957] ata4.00: detaching (SCSI 3:0:0:0)
> [ 516.314095] ata7.00: exception Emask 0x52 SAct 0x0 SErr 0xffffffff action 0xe frozen
> [ 516.314699] ata7: SError: { RecovData RecovComm UnrecovData Persist Proto HostInt PHYRdyChg PHYInt CommWake 10B8B Dispar BadCRC Handshk LinkSeq TrStaTrns UnrecFIS DevExch }
That's the controller going bonkers - all SErr bits are set. It's not
functioning correctly anymore.
> [ 516.315939] ata7.00: failed command: IDENTIFY PACKET DEVICE
> [ 516.316567] ata7.00: cmd a1/00:01:00:00:00/00:00:00:00:00/00 tag 0 pio 512 in
> [ 516.316567] res 40/00:03:00:00:00/00:00:00:00:00/a0 Emask 0x56 (ATA bus error)
> [ 516.317794] ata7.00: status: { DRDY }
> [ 516.318407] ata7: hard resetting link
On non other than IDENTIFY.
> Once this last line was printed, pings stopped working. Computer was
> completely frozen. Keyboard lock keys won't toggle either. SYSRQ non
> functional.
Misbehaving controllers can hang machine without any software way to
recover from it. It could just hang in the middle of memory
transaction. Unless PCI bridge aborts it with timeout, the only way
the system can get out of there is hard reset. Unfortunately,
controllers misbehaving this way weren't too uncommon way back with
controllers with taskfile based interface. Nowadays, it mostly
disappeared but we apparently have one here.
It could be a combination of bugs on the controller and the optical
drive and there probably are some workarounds which can avoid it -
avoid certain command sequence, take certain special steps during
recovery, etc. A good starting point would be finding out which
command from udev makes it go bonkers and see whether we can avoid
that.
Thanks.
--
tejun
--
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
