Please keep me in CC.
Tejun Heo wrote:
> 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.
I noticed there were alot of bits there, I didn't know that it was every one
of them.
> > [ 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.
Honestly, I didn't pay any attention to this part.
> > 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.
Does it matter if it's PCIe?
> 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.
Since hard drives and optical drives are all I have, I can't test anything
else. I can try another optical drive, but it appears that others have the
same problem with optical drives on this controller. Hard drives do not
have any problems on this controller.
If I add libata.atapi_passthru16=0 (as mentioned by another), I do not have
any errors and I can use the drive w/o problems. I burned and verified a
disc on this controller with this parameter set to 0. I'm not sure if a
quirk can be added for this controller or not. Seems that this disables for
all libata controllers. I'm not sure what the impact would be though.
--
Microsoft has beaten Volkswagen's world record. Volkswagen only created 22
million bugs.
--
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
